软件综合项目研发人员的团队建设与管理.doc

软件项目研发人员团体建设和管理 　　最近在和一位总经理交流时候，她谈到她们企业软件研发管理，说：“我们企业最大问题是项目不能按时完成，总要一拖再拖。”她问我有什么措施能改变这个境况。从这么一个问题开始，在随即交谈中，又引出她一连串在软件研发管理中碰到问题，包含： 　　. 现有代码质量不高，新来开发人员接手时宁愿重写，也不愿意看她人留下“烂”代码，怎么办? 　　. 重构会造成回退，怎样避免? 　　. 有些开发人员水平相对不高，怎样确保她们代码质量? 　　. 软件研发到底需不需要文档? 　　. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办? 　　. 当有开发人员在开发过程中碰到难题，工作无法继续，所以拖延进度，怎么处理? 　　. 怎样提升开发人员主观能动性? 　　其实，每个软件研发团体管理者全部面临着或曾经面临过这些问题，也全部有着自己管理“套路”来应对这些问题。我把我“套路”再此絮叨絮叨。 　　1. 项目不能按时完成，总要一拖再拖，怎么改变? 　　找处理措施前，当然要先知道问题为何会出现。这位总经理说：“总会不停地有需求要改变和新需求提出来，使原来开发计划不得不延长。”原来如此。知道根源，当然处理措施也就有了，那就是“灵敏”。灵敏开发因其迭代(Iterative)和增量(Incremental)思想和实践，恰好适合“需求常常改变和增加”项目和产品。在我讲述了灵敏部分概念，尤其是Scrum框架后，总经理也表示了对“灵敏”认同。 　　其实仔细想想，这里面还有一个很普遍问题。对于产品交付时间或项目标完成时间，往往由高级管理层依据市场情况决议和确定。在很多软件企业中，这些决议者在决议时往往忽略了一个关键参数，那就是团体生产率(Velocity)。生产率需要量化，而不是“拍脑门子”感觉出来。灵敏开发中有相关怎样估算生产率方法。所以使用灵敏，在估算产品交付时间或项目完成时间时，是相对较正确。Scrum创始人之一Jeff Sutherland说，她在一个风险投资团体做灵敏教练时，团体中资深合作人会向全部待投资企业问同一个问题：“你们是否清楚团体生产率?”而这些企业全部极难做出明确回复。软件企业要想给产品定一个较实际交付日期，就首先要搞清楚自己软件生产率。 　　2. 现有代码质量不高，新来开发人员接手时宁愿重写，也不愿意看她人留下“烂”代码，怎么办? 　　这可能是很多软件开发工程师全部有过体验，在接手她人代码时，看不懂、无法加新功效，读代码读头疼。这说明什么?排除接手人个人水平原因，这说明旧代码可读性、可扩展性比较差。怎么办?这时，可能重构是一个两全其美措施。接手人重构代码，既能改善旧代码可读性和可扩展性，又不至于因重写代码带来时间上风险。 　　从接手人心理角度看，重构还有一个好副作用，就是代码重构以后，接手人认为那些原来“烂”代码被修改成为自己引以自豪新成就。《Scrum灵敏软件开发》作者Mike Cohn写到过：“我女儿们画了一幅尤其令人赞叹杰作后，她们会将它从学校带回家，并想把它展示在一个显著位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个尤其有用策略模式程序。因为我认定冰箱门适合展示我们引认为豪任何东西，所以我就将它放上去了。假如我们一直对自己工作质量尤其自豪，能够骄傲地将它和孩子艺术品一样展示在冰箱上，那不是很好吗?”所以这个主动促进作用，将使得接手人感觉修改代码是自己了，而且期望能够找到更多能够重构东西。 　　3. 重构会造成回退，怎样避免? 　　重构确实很轻易造成回退(Regression)。这时，重构会起到和其初衷相反作用。所以我们应该尽可能多地增加单元测试。有些老产品，旧代码，可能没有或没有那么多单元测试。但我们最少要在重构前，增加对要重构部分代码单元测试。基于重构目标单元测试，应该遵照以下标准(见《重构》第4章：构筑测试体系)： 　　- 编写未臻完善测试并实际运行，好过对完美测试无尽等候。测试应该是一个风险驱动行为，所以不要去测试那些仅仅读写一个值域访问函数，应为它们太简单了，不大可能犯错。 　　- 考虑可能犯错边界条件，把测试火力集中在哪儿。饰演“程序公敌”，纵容你心智中比较促狭那一部分，主动思索怎样破坏代码。 　　- 当事情被公认应该会犯错时，别忘了检验是否有异常准期被抛出。 　　- 不要因为“测试无法捕捉全部Bug”，就不撰写测试代码，因为测试确实能够捕捉到大多数Bug。 　　- “花合理时间抓出大多数Bug”要好过“穷尽一生抓出全部Bug”。因为当测试数量达成一定程度以后，测试效益就会展现递减态势，而非连续递增。 　　说到《重构》这本书，其实在每个重构方法中全部有“作法(Mechanics)”一段，在重构实践中根据上面所述步骤进行是比较稳妥，同时也能避免很多不经意间制造