软件开发管理建议

1、公司开发管理建议本文的目的1希望工作氛围有所改善2希望工作效率得到提高回答如下问题1为什么疲惫2工作如何分工3代码版本控制4工作环境文档化5新人的培训与成长6当前该怎么做为什么疲惫什么样的工作容易疲惫？不是加班， 有时加班往往带来的不是疲惫， 而是充实 和成就感；导致疲惫的元凶是工作中的不确定性和琐碎。不确定性源于自身能力与所做工作的差异，说白了就是不会；可是EDA行业到哪里找那么多会的人呢，优秀人才大都在现有公司有一定地位，很难撬到，正确 的做法是搞好分工，让适当的人做适当的事，这样就不会面临招人难的困境了， 优秀公司的人才都不是挖来的，而是自己培养起来的。琐碎源于分工的交叉或是工作多。 工

2、作琐碎不仅仅是导致开发人员的疲惫， 对 产品质量的影响很大，容易制造Bug,而新的Bug又导致工作更繁琐，陷入恶性循 环。我并不是反对压力，对某些人来讲，压力是促进成长的催化剂，但新一代年轻人承受压力的能力越来越差。最重要的是：如果我们能够轻松的做完事情，何必选择压力呢。轻松代表了游刃有余，也暗示了我们能做更多的事情，如果已经绷 紧了，就没有回旋余地了。工作的愉悦性是能留住人的重要砝码。工作如何分工软件开发的迭代流程是：需求分析，概要设计，详细设计，编码调试，测试维护。需求分析 ：不管做什么事，开头都是最重要的，所以需求分析是最重要的，它贯穿整个开发流程，当工作进展到测试阶段时，突然发现需求没

3、有弄清楚，等于是整个工作 从头再来，这不光降低了工作效率，而且对于开发人员的情绪打击很大。重要的事情自然要由重要的人来做， 应当安排经验丰富能力强的人来做需求分 析。新人考虑问题不周全，势必增加返工的次数，对软件质量危害很大，而且还会干扰其他人的工作，进而影响到整个公司的效率。必须加强对需求的跟踪，我们的需求零散的分布在 Bug Tracer ，文档， Email 里，对QA工作和工作交接都很不利。每一次需求变更会影响到整个软件过程， 所以在定义需求时要充分考虑， 定义 需求的工作自然也应该由经验丰富的人来做。概要设计：概要设计跟需求分析关联很大， 需求分析要做的工作就是理清需求， 决定由哪

4、些模块协同完成，需求分析和概要设计由一个人来做会更方便。概要设计包含了接口定义，一旦接口定下来，软件的框架就确定了，从而约束 了后面的风险。接口变更带来的附加工作很多，接口制定的重要性是很明显的， 还是那句话：重要的事情由重要的人做。详细设计 / 编码调试：在接口定义下来之后， 接下来就是实现了， 详细设计描述基本的实现算法和模 块的子结构。概要设计的输出就是详细设计的需求， 这个需求是开发人员容易理解的。 详细设计和编码应该有一个人来完成，因为这两部分结合紧密。详细设计的目的：1 评审，概要设计人员和同行可以对详细设计进行评审，以控制风险。2. 维护，当需求发生变更，或有 Bug,详细设计可

5、以给与指导。3 交接，在人事变动和工作变更时，有详细设计文档可以方便的交接代码。打铁要趁热，编码之后要立即进行调试和测试，一些明显的Bug应该在这个阶段被发现。测试维护：测试的核心价值是发现 Bug，是以写CASE为主。对CASE的整理很重要，CASE和需求是相关的，有必要将 CASE与需求点对应并编写成文档，方便查找，在后续的修改中，开发人员可以通过这个文档找到相应CASE对修改进行验证。很多公司要求在需求确立后编写测试计划， 这听上去很完美， 但如果需求总是 变更，很多工作将被浪费，所以我建议在开发进入到一定阶段的时候开始进行相 关测试，因为这个时候需求相对稳定，而且符合打铁趁热的观念。写

6、到这儿，我对比一下两种开发方法，从而说明上述软件过程的必要性。 当前公司的开发模式有点类似于下图：在这种模式里，每一项工作几乎从头至尾由一个人来完成。在这种模式下，人 员之间的协同很少，高级员工和普通员工在工作性质上没有本质差别，由于工作 不一样，高级员工不方便给与帮助，软件的质量由员工个人能力决定。由于能力 差异，开发进度也很难控制。在这种开发模式里，看不到开发团队的影子。而且， 到哪里招能独立开发的人员呢，招人难，用人难的问题突出。软件规模受到限制， CMM认为，这种幵发模式的人员极限是十几个人，源笙这么些年来，幵发人员规模一直在十人左右停步不前甚至萎缩，恐怕就是这个原因。当人员离职时，

7、接手那一部分工作的人恐怕能做的就是祈祷别出问题了。 因为 从头到尾只有他一个人知道，他不需要写文档，所以没有文档留下来，他的代码 没有人跟踪，所以质量如何根本不知道。我建议的开发模式图如下：从上图中可以看到， 每一项工作都是由一个 团队协同 完成的， 开发人员根据能 力资历的不同在团队中担任不同的任务，高级员工和普通员工共同开发，高级员 工可以方便的给与普通员工帮助，促进普通员工成长为高级员工，从而促进团队 成长。软件的质量由团队的质量决定。因为概要设计的输出就是下一步的需求，所以这种模式不受软件规模的限制， 当软件规模扩大时，可以想象成由子需求形成的一个个小项目逐级开发。越是高 层的概要设计

8、越重要，称之为架构师，微软最重视的就是架构师，据说微软有一 个架构师拥有 7 部豪华跑车。用人问题得到解决，高级员工把需求分析成开发需求，在高级员工的帮助下， 普通员工可以完成开发，并在其中成长为高级员工，团队得到成长。那是不是说，高级员工就不需要作编码了呢，一些涉及流程控制，模块间交互 的代码可以由高级员工掌握，这些模块的开发模式看上去跟前一种一样，从头至 尾都由一个人完成，但本质是不同的，这属于高级员工的多角色担当，对于小型 软件是很普遍的。显然， 高级员工就是一个工作团队的老大， 一项工作是由高级员工带领一个团 队完成的。代码版本控制我们当前方式， 所有人都往一个 Branch 里 ch

9、eck in 代码，这会造成相互干扰， 所以每天检查 regression 成为一项繁重的工作。 Regression 每天都跑， 服务器负 担大， Regression 的邮件从早到晚几乎都没有停过， 而且大部分的是 Fail 的，而 检查这些 Fail 的工作量大部分是浪费的，因为很可能 Fail 只是一个人造成的。更好的做法是：开发人员在一个基准版本的基础上开发， 隔一段时间做一次整合， 生成一个新 的基准颁布，开发人员再更新基准版本，每次集成测试都建立在基准版本上。开 发人员在开发过程中进行单元测试，保证集成单元的质量。基准版本不是频繁更 新，Regression不需要天天跑，没有更新

10、就不需要跑，QA人员可以把精力用在写CASE上。这样，不管是单元测试还是集成测试，都遵循有更新就测试的原则，同 意个CASE在同一个代码上跑一次就行了。严格杜绝一个源文件多个人写的情况发生， 一旦有人操作不当， 对工作的干扰很大。事实上，采用上述的分工方式，也不会发生这种情况。这样的话，我们需要如下几个 Branch ：1. 工作Bra nch ,幵发人员在这个 Bran ch里幵发，这个Branch不Make,只是用来保存所有的代码历史，不同开发人员拥有不同的源文件；除了自 己拥有的文件外其他的文件可以从基准版本里 Link 过来或者直接复制 在用户目录，因为基准版本不是频繁变更的，所以每次

11、基准版本变更时 更新一次就可以了， 这就杜绝了因为他人导致的编译不通过的情况发生。与他人发生交互而要更新别人的代码时，开发人员协同完成，这是可控 制的。工作人员在开发时， 要进行单元测试， 保证单元内部的软件质量。2. 集成Branch ,集成时，由负责人统一将工作 Branch中的Code更新到集成 Branch 中，这个工作没有难度却不容出错， 不建议新员工做， 这时负 责人还可以通过比较工具检查代码，对于较小的改动，很少的CodingReview工作非常有价值。集成 Branch有了之后，由QA进行集成测试， 开发人员在这个时间集中解决问题。3. 集成 Branch 测试稳定之后， 生成

12、新的基准版本， 发布， 通知所有开发人员更新基准版本。只有发生严重Bug才需要临时更新基准版本。另外，使用Label而不是最新版本来获取代码，通过Label，可以在CVS里取Label 的重用作用是记得以往的所有版本。进行集成时，开发人员的代码也是以 Label 的形式提交的， 当开发人员编码完成， 经过充分测试， 对代码标一个 Label ，然后进入下一阶段开 发，集成时就取这个 Label ，这样就不影响后续的开发， 后续开发其实不用急于做， 不妨等基准发布之后再做，因为这中间的改动可能性很大，一旦开发了新的，要 进行代码的差分修改，稍不留神，麻烦很大，欲速则不达 住了历史，当发生错误了，

13、我们知道在哪个版本上错了，利于 Bug 的复现和定位。有的Bug, 看最新的代码不发生了，就不了了之了，其实还是被隐藏了。工作环境文档化基本上每个公司都有类似的文档， 但质量的差别就大了。 这些文档必须具备两 个条件：1 能够方便的找到文档的位置2 文档中可以迅速查到想要的内容内容当包括日常工作中相关的操作。包括公司服务器网络配置，软件位置，工 具设置，基本命令。就这么多了。但在这儿我想郑重地提一下使用中文文档的事情。我们公司没有看不懂中文的，而简体繁体也可以通过Word方便的转换，所以使用中文没有什么障碍。民族主义和国际化企业是很虚的，不在此浪费唇舌了，我关注的是效率。首先，人的思维很奇妙，

14、我们还不能做到用英文的方式思维和记忆，所以每一 份英文文档我们都必须先翻译成中文意思，然后记忆。当记忆模糊需要重新看时， 需要再次的翻译，这就是为什么第二次看同一份英文文档似曾相识感很弱，而中 文文档第二次看时速度会快很多，因为我们都是用中文来进行记忆和思维的。第二，大家的英文水平差异明显， 几乎是各说各的英文， 造成很大的沟通障碍。用英文写的人能表达几成自己的想法，阅读英文的人又能看懂几成，两个折扣一 打，文档沟通能力丧失殆尽。第三，从文字上来说，中文是二维的图像文字，英文是一维的编码文字，二维 比一维能表达更多的信息，所以中文的阅读速度是英文所不能比的，联合国的每 份文档，中文的那份总是最

15、短的。可以预见，不远的将来，中文才是通行世界的 语言。我们在舍长取短啊。我可以推测，我们之所以选择了一种错误的开发模式，很大原因是使用英文， 因为文档沟通的障碍，自然地拒绝了文档，这就自然而然的促成了单人开发模式， 因为这种模式需要最少的文档。团队开发是离不开文档的。使用中文， 是当下公司最容易做到， 也是对效率产生最大提高的方法。 如果真 有英文的必要，找个翻译都是划算的，还是分工问题。华为也是跨国公司，开发 团队不用英文。新人的培训与成长对小公司， 这是个大问题。 当前公司分配给新人的工作多少有点赶鸭子上架的意味，这种揠苗助长的方式对新人没有好处，有的干脆不堪压力阵亡了，有的养 成了做工作

16、一知半解的习惯。开发人员必须获得自己的核心， 然后在这个基础上往外扩展， 才是健康的成长 方式。对于一些告知性的知识，在入职时组织培训，训练一下基本操作，告诉他们哪 里有文档可以获得帮助。新人成长的同时， 还要达到解放老员工的目的， 这样才能在开发团队体现出层次结构来。一个很好的办法是让新人接手老员工开发的模块，这个好处很多：1， 让新人在阅读代码中获得常规的编程思想，优秀的程序员都是读代码读出来的；我们公司新来的几个员工，读的代码很少，他们做事不能让人放心2， 老员工能被解放出来，得到提升；3， 风险可控，新人的流动性强，不用担心他留下一堆麻烦；4， 老员工方便对新人进行指导也许读代码对公司不能创造什么价值， 但迫不及待的让新人开发， 更大的可能 是创造负价值。培养出的人才才是公司的人才。新人在掌握一个模块之后， 就像有了一片自己的领地， 以后的成长就少了很多 迷茫。这样，我们只要招合格的 C语言工程师就可以了，不需要为额外的条件买单。当前该怎么做说了这么多，该从哪里入手呢，很多时候，事情总是容易越来越糟，本来够忙 的，又来了一堆事情，所以应该先从忙碌中