几个软件研发团队管理的小问题

最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“咱们公司最大的问题是项目不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的遇到的问题，包括：

 

. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不肯意看别人留下的“烂”代码，怎么办？

. 重构会形成回退，怎样避免？

. 有些开发人员水平相对不高，如何保证他们的代码质量？

. 软件研发到底需不须要文档？

. 要求提交代码前作Code Review，而开发人员不作，或敷衍了事，怎么办？

. 当有开发人员在开发过程当中遇到难题，工做没法继续，于是拖延进度，怎么解决？

. 如何提升开发人员的主观能动性？

 

其实，每一个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着本身的管理“套路”来应对这些问题。我把个人“套路”再此絮叨絮叨。

 

1. 项目不能按时完成，总要一拖再拖，怎么改变？

 

找解决办法前，固然要先知道问题为何会出现。这位总经理说：“总会不断地有需求要改变和新需求提出来，使原来的开发计划不得不延长。”原来如此。知道根源，固然解决办法也就有了，那就是“敏捷”。敏捷开发因其迭代（Iterative）和增量（Incremental）的思想与实践，正好适合“需求常常变化和增长”的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷”的认同。

 

其实仔细想一想，这里面还有一个很是广泛的问题。对于产品的交付时间或项目的完成时间，每每由高级管理层根据市场状况决策和肯定。在不少软件企业中，这些决策者在决策时每每忽略了一个重要的参数，那就是团队的生产率（Velocity）。生产率须要量化，而不是“拍脑门子”感受出来的。敏捷开发中有关于如何估算生产率的方法。因此使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的Jeff Sutherland说，他在一个风险投资团队作敏捷教练时，团队中的资深合伙人会向全部的待投资企业问同一个问题：“大家是否清楚团队的生产率？”而这些企业都很难作出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚本身的软件生产率。

 

2. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不肯意看别人留下的“烂”代码，怎么办？

 

这多是不少软件开发工程师都有过的体验，在接手别人的代码时，看不懂、没法加新功能，读代码读的头疼。这说明什么？排除接手人我的水平的因素，这说明旧代码可读性、可扩展性比较差。怎么办？这时，也许重构是一种一箭双鵰的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写代码带来的时间上的风险。

 

从接手人心理的角度看，重构还有一个好的反作用，就是代码重构以后，接手人以为那些原来的“烂”代码被修改为为本身引以自豪的新成就。《Scrum敏捷软件开发》的做者Mike Cohn写到过：“个人女儿们画了一幅特别使人赞叹的杰做后，她们会将它从学校带回家，并想把它展现在一个明显的位置，也就是冰箱上面。有一天，在工做中，我用C++代码实现了某个特别有用的策略模式的程序。由于我认定冰箱门适合展现咱们引觉得豪的任何东西，因此我就将它放上去了。若是咱们一直对本身工做的质量特别自豪，能够骄傲地将它和孩子的艺术品同样展现在冰箱上，那不是很好吗？”因此这个积极的促进做用，将使得接手人感受修改的代码是本身的了，并且指望可以找到更多的能够重构的东西。

 

3. 重构会形成回退，怎样避免？

 

重构确实很容易形成回退（Regression）。这时，重构会起到与其初衷相反的做用。因此咱们应该尽量多地增长单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但咱们至少要在重构前，增长对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循如下的原则（见《重构》第4章：构筑测试体系）：

- 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，因此不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。

- 考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那一部分，积极思考如何破坏代码。

- 当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。

- 不要由于“测试没法捕捉全部Bug”，就不撰写测试代码，由于测试的确能够捕捉到大多数Bug。

- “花合理时间抓出大多数Bug”要好过“穷尽一辈子抓出全部Bug”。由于当测试数量达到必定程度以后，测试效益就会呈现递减态势，而非持续递增。

说到《重构》这本书，其实在每一个重构方法中都有“做法（Mechanics）”一段，在重构的实践中按照上面所述的步骤进行是比较稳妥的，同时也能避免不少不经意间制造的回退出现。

 

4. 要求提交代码前作Code 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. 软件研发到底需不须要文档？

 

软件研发须要文档的起原可能有2种，一是比较原始的，须要文档是为了当开发人员离职后，企业须要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业听从ISO9001质量管理体系或CMMI。

 

对于第一种，根源可能来自于两个方面：

- 原开发人员设计编码水平不高，其代码可读性较差。

- 设计思想和代码只有一我的了解，此人一旦离职，无人知道其细节。

在编码前写一些简单的设计文档，有助于理清思路，尤为是辅以一些UML图，在交流时也是有好处的。但同时，咱们也应该提升开发人员的编码水平增长其代码的可读性，好比加强其变量命名的可读性、用一些被你们所了解的设计模式来替代按本身某些独特思路编写的代码、增长和改进注释等等，以减小没必要要的文档。另外推行代码的集体全部权（Collective Ownership），避免某些代码只被一我的了解，这样能够减小以此为目的而编写的文档。

 

对于第二种，状况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“能够工做的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来势不两立。可是，它们的宗旨是一致的，即：构建高质量的产品。

 

对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能经过ISO9001的审核的，但当把它们复印、拍照、增长序号、保存后，能够经过审核。每次都是成功的Daily Build和Auto Test报告没法证实它们是否真正被执行并真正成功，因此不能经过ISO9001的审核。但添加一个断言失败（相似assert(false)的断言）的测试后，则能够经过审核。

 

CMMI与敏捷也是互补的，前者告诉组织在整体条款上作什么，可是没有说如何去作，后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已经过CMMI5级评估的组织。不少企业忘记了最终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。

 

因此敏捷开发在过程当中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”做为主要目标的质量体系文档要求并不矛盾。在实践中，咱们能够按如下方法作，在实现SCRUM的同时，符合审核和评估的要求：

 

- 制做格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片一样有效。

- 将监管须要的文档工做也放入Backlog。除了能够确保它们不被忘记，还能使监管要求的成本是可见的。

- 使用检查列表，以向审核员或评估员证实活动已执行。团队对“完成”的定义(Definition of “Done”)能够很容易转变为一份检查列表。

- 使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。

 

总而言之，软件研发须要文档（但文档的形式能够是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时咱们只需写够用的文档。

 

6. 当有开发人员在开发过程当中遇到难题，工做没法继续，于是拖延进度，怎么解决？

 

这也是个常遇到的问题。若是管理者对于某个工程师的具体问题进行指导，就会陷入过分微观管理的境地。咱们须要找到宏观解决办法。一，咱们基于Scrum的“团队有共同的目标”这一规则，利用前面提到的集体全部权，当出现这些问题时，用团队中全部可使用的力量来帮助其摆脱困境，而不是任其余人袖手旁观。固然这里会牵扯到绩效评定的问题，好比：提供帮助的人会以为，他的帮助无助于本身绩效评定的提升，为何要提供帮助。这须要人力资源部门在使用Scrum开发的团队的绩效评估中，尽可能消除那些倾向我的的因素，还要包含团队协做的因素，普遍听取个方面的意见，更频繁地评估绩效等等。

 

二，即便动用全部可使用的力量，若是某个难题真的没法逾越，为了减小不能按时交付的风险，产品负责人应当站出来，并有所做为。要么从新评估Backlog的优先级，使没法继续的Backlog迟一点交付，先作一些相对较低优先级的Backlog，以保证总体交付时间不至于延长；要么减小部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率降低，产品负责人必须做出取舍。

 

7. 有些开发人员水平相对不高，如何保证他们的代码质量？

 

固然首先让较有经验的人Review其要提交的代码，这几乎是全部管理者会作的事。除此以外，管理者有责任帮助这些人（也包括水平较高的人）提升水平，他们能够看一些书，上网看资料，读别人的代码等等，途经仍是不少的。但问题是你如何去衡量其是否真正有所收获。咱们的经验是，在每一年大约3月份为每一个工程师制定整个年度的目标，每一个人的目标包括产品上的，技术上的，我的能力上的等4到5项。半年后和一年后，要作两次Performance Review，目标是否实现，也会跟绩效评定挂钩。咱们在制定目标时，遵循SMART原则，即：

 

Specific（明确的）：目标应该按照明确的结果和成效表述。

Measurable（可衡量的）：目标的完成状况应该能够衡量和验证。

Aligned（结盟的）：目标应该与公司的商业策略保持一致。

Realistic（现实的）：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。

Time-Bound（有时限的）：目标应该包括一个实现的具体时间。

 

好比：某我的制定了“初步掌握本地化技术”的目标，他要肯定实现时间，要描述学习的途经和步骤，要经过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化做一些探索，并制做Presentation给团队演示他的成果，并准备回答其余人提出的问题。团队还为了配合其实现目标，组织Tech Talk的活动，供你们分享每一个人的学习成果。经过这些手段，提升开发人员的自学兴趣，并逐步提升开发人员的技术水平。

 

8. 如何提升开发人员的主观能动性？

 

提升开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年之后的他和如今比不会有什么进步。你要让他感到他所从事的是一个职业（Career），而不仅是一份工做（Job）。不然，他们是不会主动投入到工做中的。咱们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类（Managerial Path）和技术类（Technical Path），6个职业级别（1-3级是Entry/Associate，Intermediate，Senior。4级管理类是Manager/Senior Manager，技术类是Principal/Senior Principal。5级管理类是Director/Senior Director，技术类是Fellow/Architect。6级是Executive Management）。每一个级别都有13个方面的具体要求，包括：范围（Scope）、跨职能（Cross Functional）、层次（Level）、知识（Knowledge）、指导（Guidance）、问题解决（Problem Solving）、递交成果（Delivering Result）、责任感（Responsbility）、导师（Mentoring）、交流（Communication）、自学（Self-Learning），运做监督（Operational Oversight），客户响应（Customer Responsiveness）。每一年有2次提升级别的机会，开发人员一旦具有了升级的条件，他的Supervisor将会提出申请，一旦批准，他的头衔随之提升，薪水也会有相对较大提升。从而使每一个开发人员以为“有奔头”，天然他们的主观能动性也就提升了。

 

上面的“套路”涉及了软件研发团队管理中的研发过程、技术实践、文档管理、激励机制等一些方面。但只是九牛一毛，研发团队管理涵盖的内容还有不少不少，还须要管理者在不断探索和实践的道路上学习和掌握。