《软件开发管理建议》由会员分享，可在线阅读，更多相关《软件开发管理建议（6页珍藏版）》请在金锄头文库上搜索。
1、公司开发管理建议本文的目的1 希望工作氛围有所改善2 希望工作效率得到提高回答如下问题1 为什么疲惫2 工作如何分工3 代码版本控制4 工作环境文档化5 新人的培训与成长6 当前该怎么做为什么疲惫什么样的工作容易疲惫？不是加班，有时加班往往带来的不是疲惫，而是充实和成就感；导致疲惫的元凶是工作中的不确定性和琐碎。不确定性源于自身能力与所做工作的差异，说白了就是不会；可是EDA行业到哪里找那么多会的人呢，优秀人才大都在现有公司有一定地位，很难撬到，正确的做法是搞好分工，让适当的人做适当的事，这样就不会面临招人难的困境了，优秀公司的人才都不是挖来的，而是自己培养起来的。琐碎源于分工的交叉或是工作多
2、。工作琐碎不仅仅是导致开发人员的疲惫，对产品质量的影响很大，容易制造Bug，而新的Bug又导致工作更繁琐，陷入恶性循环。我并不是反对压力，对某些人来讲，压力是促进成长的催化剂，但新一代年轻人承受压力的能力越来越差。最重要的是：如果我们能够轻松的做完事情，何必选择压力呢。轻松代表了游刃有余，也暗示了我们能做更多的事情，如果已经绷紧了，就没有回旋余地了。工作的愉悦性是能留住人的重要砝码。工作如何分工软件开发的迭代流程是：需求分析，概要设计，详细设计，编码调试，测试维护。需求分析：不管做什么事，开头都是最重要的，所以需求分析是最重要的，它贯穿整个开发流程，当工作进展到测试阶段时，突然发现需求没有弄清
3、楚，等于是整个工作从头再来，这不光降低了工作效率，而且对于开发人员的情绪打击很大。重要的事情自然要由重要的人来做，应当安排经验丰富能力强的人来做需求分析。新人考虑问题不周全，势必增加返工的次数，对软件质量危害很大，而且还会干扰其他人的工作，进而影响到整个公司的效率。必须加强对需求的跟踪，我们的需求零散的分布在Bug Tracer，文档，Email里，对QA工作和工作交接都很不利。每一次需求变更会影响到整个软件过程，所以在定义需求时要充分考虑，定义需求的工作自然也应该由经验丰富的人来做。概要设计：概要设计跟需求分析关联很大，需求分析要做的工作就是理清需求，决定由哪些模块协同完成，需求分析和概要设
4、计由一个人来做会更方便。概要设计包含了接口定义，一旦接口定下来，软件的框架就确定了，从而约束了后面的风险。接口变更带来的附加工作很多，接口制定的重要性是很明显的，还是那句话：重要的事情由重要的人做。详细设计/编码调试：在接口定义下来之后，接下来就是实现了，详细设计描述基本的实现算法和模块的子结构。概要设计的输出就是详细设计的需求，这个需求是开发人员容易理解的。详细设计和编码应该有一个人来完成，因为这两部分结合紧密。详细设计的目的：1 评审，概要设计人员和同行可以对详细设计进行评审，以控制风险。2 维护，当需求发生变更，或有Bug，详细设计可以给与指导。3 交接，在人事变动和工作变更时，有详细设
5、计文档可以方便的交接代码。打铁要趁热，编码之后要立即进行调试和测试，一些明显的Bug应该在这个阶段被发现。测试维护：测试的核心价值是发现Bug，是以写CASE为主。对CASE的整理很重要，CASE和需求是相关的，有必要将CASE与需求点对应并编写成文档，方便查找，在后续的修改中，开发人员可以通过这个文档找到相应CASE，对修改进行验证。很多公司要求在需求确立后编写测试计划，这听上去很完美，但如果需求总是变更，很多工作将被浪费，所以我建议在开发进入到一定阶段的时候开始进行相关测试，因为这个时候需求相对稳定，而且符合打铁趁热的观念。写到这儿，我对比一下两种开发方法，从而说明上述软件过程的必要性。当
6、前公司的开发模式有点类似于下图：在这种模式里，每一项工作几乎从头至尾由一个人来完成。在这种模式下，人员之间的协同很少，高级员工和普通员工在工作性质上没有本质差别，由于工作不一样，高级员工不方便给与帮助，软件的质量由员工个人能力决定。由于能力差异，开发进度也很难控制。在这种开发模式里，看不到开发团队的影子。而且，到哪里招能独立开发的人员呢，招人难，用人难的问题突出。软件规模受到限制， CMM认为，这种开发模式的人员极限是十几个人，源笙这么些年来，开发人员规模一直在十人左右停步不前甚至萎缩，恐怕就是这个原因。当人员离职时，接手那一部分工作的人恐怕能做的就是祈祷别出问题了。因为从头到尾只有他一个人知
7、道，他不需要写文档，所以没有文档留下来，他的代码没有人跟踪，所以质量如何根本不知道。我建议的开发模式图如下：从上图中可以看到，每一项工作都是由一个团队协同完成的，开发人员根据能力资历的不同在团队中担任不同的任务，高级员工和普通员工共同开发，高级员工可以方便的给与普通员工帮助，促进普通员工成长为高级员工，从而促进团队成长。软件的质量由团队的质量决定。因为概要设计的输出就是下一步的需求，所以这种模式不受软件规模的限制，当软件规模扩大时，可以想象成由子需求形成的一个个小项目逐级开发。越是高层的概要设计越重要，称之为架构师，微软最重视的就是架构师，据说微软有一个架构师拥有7部豪华跑车。用人问题得到解决
8、，高级员工把需求分析成开发需求，在高级员工的帮助下，普通员工可以完成开发，并在其中成长为高级员工，团队得到成长。那是不是说，高级员工就不需要作编码了呢，一些涉及流程控制，模块间交互的代码可以由高级员工掌握，这些模块的开发模式看上去跟前一种一样，从头至尾都由一个人完成，但本质是不同的，这属于高级员工的多角色担当，对于小型软件是很普遍的。显然，高级员工就是一个工作团队的老大，一项工作是由高级员工带领一个团队完成的。代码版本控制我们当前方式，所有人都往一个Branch里check in代码，这会造成相互干扰，所以每天检查regression成为一项繁重的工作。Regression每天都跑，服务器负担
9、大，Regression的邮件从早到晚几乎都没有停过，而且大部分的是Fail的，而检查这些Fail的工作量大部分是浪费的，因为很可能Fail只是一个人造成的。更好的做法是：开发人员在一个基准版本的基础上开发，隔一段时间做一次整合，生成一个新的基准颁布，开发人员再更新基准版本，每次集成测试都建立在基准版本上。开发人员在开发过程中进行单元测试，保证集成单元的质量。基准版本不是频繁更新，Regression不需要天天跑，没有更新就不需要跑，QA人员可以把精力用在写CASE上。这样，不管是单元测试还是集成测试，都遵循有更新就测试的原则，同意个CASE在同一个代码上跑一次就行了。严格杜绝一个源文件多个人
10、写的情况发生，一旦有人操作不当，对工作的干扰很大。事实上，采用上述的分工方式，也不会发生这种情况。这样的话，我们需要如下几个Branch：1 工作Branch，开发人员在这个Branch里开发，这个Branch不Make，只是用来保存所有的代码历史，不同开发人员拥有不同的源文件；除了自己拥有的文件外其他的文件可以从基准版本里Link过来或者直接复制在用户目录，因为基准版本不是频繁变更的，所以每次基准版本变更时更新一次就可以了，这就杜绝了因为他人导致的编译不通过的情况发生。与他人发生交互而要更新别人的代码时，开发人员协同完成，这是可控制的。工作人员在开发时，要进行单元测试，保证单元内部的软件质量
11、。2 集成Branch，集成时，由负责人统一将工作Branch中的Code更新到集成Branch中，这个工作没有难度却不容出错，不建议新员工做，这时负责人还可以通过比较工具检查代码，对于较小的改动，很少的Coding Review工作非常有价值。集成Branch有了之后，由QA进行集成测试，开发人员在这个时间集中解决问题。3 集成Branch测试稳定之后，生成新的基准版本，发布，通知所有开发人员更新基准版本。只有发生严重Bug才需要临时更新基准版本。另外，使用Label而不是最新版本来获取代码，通过Label，可以在CVS里取得以往的所有版本。进行集成时，开发人员的代码也是以Label的形式提
12、交的，当开发人员编码完成，经过充分测试，对代码标一个Label，然后进入下一阶段开发，集成时就取这个Label，这样就不影响后续的开发，后续开发其实不用急于做，不妨等基准发布之后再做，因为这中间的改动可能性很大，一旦开发了新的，要进行代码的差分修改，稍不留神，麻烦很大，欲速则不达。Label的重用作用是记住了历史，当发生错误了，我们知道在哪个版本上错了，利于Bug的复现和定位。有的Bug，一看最新的代码不发生了，就不了了之了，其实还是被隐藏了。工作环境文档化基本上每个公司都有类似的文档，但质量的差别就大了。这些文档必须具备两个条件：1 能够方便的找到文档的位置2 文档中可以迅速查到想要的内容内
13、容当包括日常工作中相关的操作。包括公司服务器网络配置，软件位置，工具设置，基本命令。就这么多了。但在这儿我想郑重地提一下使用中文文档的事情。我们公司没有看不懂中文的，而简体繁体也可以通过Word方便的转换，所以使用中文没有什么障碍。民族主义和国际化企业是很虚的，不在此浪费唇舌了，我关注的是效率。首先，人的思维很奇妙，我们还不能做到用英文的方式思维和记忆，所以每一份英文文档我们都必须先翻译成中文意思，然后记忆。当记忆模糊需要重新看时，需要再次的翻译，这就是为什么第二次看同一份英文文档似曾相识感很弱，而中文文档第二次看时速度会快很多，因为我们都是用中文来进行记忆和思维的。第二，大家的英文水平差异明
14、显，几乎是各说各的英文，造成很大的沟通障碍。用英文写的人能表达几成自己的想法，阅读英文的人又能看懂几成，两个折扣一打，文档沟通能力丧失殆尽。第三，从文字上来说，中文是二维的图像文字，英文是一维的编码文字，二维比一维能表达更多的信息，所以中文的阅读速度是英文所不能比的，联合国的每份文档，中文的那份总是最短的。可以预见，不远的将来，中文才是通行世界的语言。我们在舍长取短啊。我可以推测，我们之所以选择了一种错误的开发模式，很大原因是使用英文，因为文档沟通的障碍，自然地拒绝了文档，这就自然而然的促成了单人开发模式，因为这种模式需要最少的文档。团队开发是离不开文档的。使用中文，是当下公司最容易做到，也是
15、对效率产生最大提高的方法。如果真有英文的必要，找个翻译都是划算的，还是分工问题。华为也是跨国公司，开发团队不用英文。新人的培训与成长对小公司，这是个大问题。当前公司分配给新人的工作多少有点赶鸭子上架的意味，这种揠苗助长的方式对新人没有好处，有的干脆不堪压力阵亡了，有的养成了做工作一知半解的习惯。开发人员必须获得自己的核心，然后在这个基础上往外扩展，才是健康的成长方式。对于一些告知性的知识，在入职时组织培训，训练一下基本操作，告诉他们哪里有文档可以获得帮助。新人成长的同时，还要达到解放老员工的目的，这样才能在开发团队体现出层次结构来。一个很好的办法是让新人接手老员工开发的模块，这个好处很多：1， 让新人在阅读代码中获得常规的编程思想，优秀的程序员都是读代码读出来的；我们公司新来的几个员工，读的代码很少，他们做事不能让人放心的。2， 老员工能被解放出来，得到提升；3， 风险可控，新人的流动性强，不用担心他留下一堆麻烦；4， 老员工方便对新人进行指导也许读代码对公司不能创造什么价值，但迫不及待的让新人开发，更大的可能是创造负价值。培养出的人才才是公司的人才。新人在掌握一个模块之后，就像有了一片自己的领地，以后的成长就少了很多迷茫。这样，我们只要招合格的C语言工程师就可以了，不需要为额外的条件买单。当前该怎么做说了这么多，该从哪里入手
