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

软件项目研发人员的团队建设与管理软件项目研发人员的团队建设与管理 最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目 不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈 中，又引出他一连串在软件研发管理中的遇到的问题，包括： . 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办 ? . 重构会造成回退，怎样避免? . 有些开发人员水平相对不高，如何保证他们的代码质量? . 软件研发到底需不需要文档? . 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办? . 当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决? . 如何提高开发人员的主观能动性? 其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路”来应 对这些问题。我把我的“套路”再此絮叨絮叨。 1.1. 项目不能按时完成，总要一拖再拖，怎么改变项目不能按时完成，总要一拖再拖，怎么改变? ? 找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有需求要改变和新需求 提出来，使原来的开发计划不得不延长。”原来如此。知道根源，当然解决办法也就有了，那就是“敏捷”。 敏捷开发因其迭代(Iterative)和增量(Incremental)的思想与实践，正好适合“需求经常变化和增加”的项 目和产品。在我讲述了敏捷的一些概念，特别是Scrum 的框架后，总经理也表示了对“敏捷”的认同。 其实仔细想想，这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间，往往由高级 管理层根据市场情况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那 就是团队的生产率(Velocity)。生产率需要量化，而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何 估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。 Scrum 创始 人之一的 Jeff Sutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投 资企业问同一个问题： “你们是否清楚团队的生产率?”而这些企业都很难做出明确的答复。 软件企业要想给 产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。 2.2. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办? ? 这可能是很多软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读 的头疼。这说明什么?排除接手人个人水平的因素，这说明旧代码可读性、可扩展性比较差。怎么办?这时， 也许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写 代码带来的时间上的风险。 从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂” 代码被修改成为自己引以自豪的新成就。《Scrum 敏捷软件开发》的作者 Mike Cohn 写到过：“我的女儿们 画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个明显的位置，也就是冰箱 上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展 示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲 地将它和孩子的艺术品一样展示在冰箱上， 那不是很好吗?”所以这个积极的促进作用， 将使得接手人感觉修 改的代码是自己的了，而且期望能够找到更多的可以重构的东西。 3.3. 重构会造成回退，怎样避免重构会造成回退，怎样避免? ? 重构确实很容易造成回退(Regression)。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能 多地增加单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前， 增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则 (见《重构》第4 章：构 筑测试体系)： - 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以 不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。 - 考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那 一部分，积极思考如何破坏代码。 - 当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。 - 不要因为“测试无法捕捉所有Bug”，就不撰写测试代码，因为测试的确可以捕捉到大多数Bug。 - “花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。 因为当测试数量达到一定程度之后， 测试效益就会呈现递减态势，而非持续递增。 说到《重构》这本书，其实在每个重构方法中都有“作法(Mechanics)”一段，在重构的实践中按照上面 所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。 4.4. 要求提交代码前做要求提交代码前做 Code ReviewCode Review，而开发人员不做，或敷衍了事，怎么办，而开发人员不做，或敷衍了事，怎么办? ? 如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢?团队管理者需要一 些手段促使其有效地进行Code Review。 首先， 我们采用的 Code Review 有 2 种形式， 一是 Over-the-shoulder， 也就是 2 个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator 来进行。无论哪种形式， 在提交代码时，必须注明关于审查的信息，比如：审查者(Reviewer)的名字或审查号(Review ID，Code Collaborator 自动生成)，每天由一名专职人员来检查Checklist 中的每一条，看是否有人漏写这些信息， 如果发现会提醒提交的人补上。另外，某段提交的代码出问题， 提交者和审查者都要一起来解决出现的问题， 以最大限度避免审查过程敷衍了事。 博主 Inovy 在某个评论说的很形象：“木(没)有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦 屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查就提交，或审查 时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人 会因为多次被查出没有做Code Review 就提交代码，而到年底加薪时比别人少涨500 块钱。 5.5. 软件研发到底需不需要文档软件研发到底需不需要文档? ? 软件研发需要文档的起原可能有2 种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要 接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001 质量管理体系 或 CMMI。 对于第一种，根源可能来自于两个方面： - 原开发人员设