如何解决软件研发团队管理的问题

如何解决软件研发团队管理的问题如何解决软件研发团队管理的问题最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目不能按时完成，总要一拖再拖。〞他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的碰到的问题，包括：∙现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂〞代码，怎么办？∙重构会造成回退，怎样避免？∙有些开发人员水平相对不高，如何确保他们的代码质量？∙软件研发到底必需不必需要文档？∙要求提交代码前做CodeReview，而开发人员不做，或敷衍了事，怎么办？∙当有开发人员在开发过程中碰到难题，工作无法继续，因而拖延进度，怎么解决？∙如何提升开发人员的主观能动性？其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路〞来应对这些问题。我把我的“套路〞再此絮叨絮叨。1.项目不能按时完成，总要一拖再拖，怎么改变？找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有必需求要改变和新必需求提出来，使原来的开发计划不得不延长。〞原来如此。知道根源，当然解决办法也就有了，那就是“敏捷〞。敏捷开发因其迭代〔Iterative〕和增量〔Incremental〕的思想与施行，正好合适“必需求常常变化和增加〞的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷〞的认同。其实仔细想想，这里面还有一个非常普遍的问题。关于产品的交付时间或项目的完成时间，往往由高级管理层依据市场状况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那就是团队的生产率〔Velocity〕。生产率必需要量化，而不是“拍脑门子〞感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的JeffSutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投资企业问同一个问题：“你们是否清楚团队的生产率？〞而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。2.现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂〞代码，怎么办？这可能是很多软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读的头疼。这说明什么？排除接手人个人水平的因素，这说明旧代码可读性、可扩大性比较差。怎么办？这时，或许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩大性，又不致于因重写代码带来的时间上的风险。从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂〞代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的MikeCohn写到过：“我的女儿们画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个显然的位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门合适展示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲地将它和孩子的艺术品一样展示在冰箱上，那不是很好吗？〞所以这个积极的促进作用，将使得接手人感觉修改的代码是自己的了，而且期望能够找到更多的可以重构的东西。3.重构会造成回退，怎样避免？重构确实很容易造成回退〔Regression〕。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前，增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则〔见《重构》第4章：构筑测试体系〕：-编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。-合计可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌〞，纵容你心智中比较促狭的那一部分，积极思索如何破坏代码。-当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。-不要因为“测试无法捕捉所有Bug〞，就不撰写测试代码，因为测试确实可以捕捉到大多数Bug。-“花合理时间抓出大多数Bug〞要好过“穷尽一生抓出所有Bug〞。因为当测试数量达到一定程度之后，测试效益就会浮现递减态势，而非继续递增。说到《重构》这本书，其实在每个重构方法中都有“作法〔Mechanics〕〞一段，在重构的施行中按照上面所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。4.要求提交代码前做CodeReview，而开发人员不做，或敷衍了事，怎么办？如果每个开发人员都是积极主动的，CodeReview的作用能落到实处。但如果不是呢？团队管理者必需要一些手段促使其有效地进行CodeReview。首先，我们采纳的CodeReview有2种形式，一是Over-the-shoulder，也就是2个人座在一起，一个人讲，另一个人检察。二是用工具CodeCollaborator来进行。无论哪种形式，在提交代码时，必需注明关于检察的信息，比如：检察者〔Reviewer〕的名字或检察号〔ReviewID，CodeCollaborator自动生成〕，天天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和检察者都要一起来解决出现的问题，以最大限度避免检察过程敷衍了事。博主Inovy在某个评论说的很形象：“木〔没〕有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦屁股了。〞没有奖惩制度作确保，当然上面的要求没有什么效力。所以，当有人常常不检察就提交，或检察时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做CodeReview就提交代码，而到年底加薪时比别人少涨500块钱。5.软件研发到底必需不必需要文档？软件研发必需要文档的起原可能有2种，一是比较原始的，必需要文档是为了当开发人员离职后，企业必需要接手的人能依据文档了解他所接手的代码或模块的制定。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。关于第一种，根源可能来自于两个方面：-原开发人员制定编码水平不高，其代码可读性较差。-制定思想和代码只有一个人了解，此人一旦离职，无人知道其细节。在编码前写一些简单的制定文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提升开发人员的编码水平增加其代码的可读性，比如加强其变量命名的可读性、用一些被大家所了解的制定模式来替代按自己某些独特思路编写的代码、增加和改善解释等等，以减少不必要的文档。另外推行代码的集体所有权〔CollectiveOwnership〕，避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。关于第二种，状况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档〞。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。关于敏捷，使用手写用户故事来记录必需求和优先级的方法，以及在白板上写画的非正式制定，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、储存后，可以通过审核。每次都是成功的DailyBuild和AutoTest报告无法证实它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败〔类似assert(false)的断言〕的测试后，则可以通过审核。CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套最正确施行。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改善他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关怀这些变化是否能改善过程或产品。所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享〞作为主要目标的质量体系文档要求并不矛盾。在施行中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：-制作格式优良的、被细化的、被储存的和能跟踪的Backlog。复印和照片同样有效。-将监管必需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。-使用检查列表，以向审核员或评估员证实活动已执行。团队对“完成〞的定义(Definitionof“Done〞)可以很容易转变为一份检查列表。-使用敏捷项目管理工具。它其实就是开发程序和记录的电子浮现方式。总而言之，软件研发必需要文档〔但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，储存在QualityCenter中的测试用例也是文档〕，同时我们只必需写够用的文档。6.当有开发人员在开发过程中碰到难题，工作无法继续，因而拖延进度，怎么解决？这也是个常碰到的问题。如果管理者关于某个工程师的具体问题进行指导，就会陷入过度微观管理的境地。我们必需要找到宏观解决办法。一，我们基于Scrum的“团队有共同的目标〞这一规则，利用前面提到的集体所有权，当出现这些问题时，用团队中所有可以使用的力量来帮助其摆脱困境，而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题，比如：提供帮助的人会觉得，他的帮助无助于自己绩效评定的提升，为什么要提供帮助。这必需要人力资源部门在使用Scrum开发的团队的绩效评估中，尽量消除那些倾向个人的因素，还要包涵团队协作的因素，广泛听取个方面的看法，更频繁地评估绩效等等。二，即使动用所有可以使用的力量，如果某个难题真的无法逾越，为了减少不能按时交付的风险，产品负责人应当站出来，并有所作为。要么重新评估Backlog的优先级，使无法继续的Backlog迟一点交付，先做一些相对较低优先级的Backlog，以确保整体交付时间不致于延长；要么减少部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降，产品负责人必需作出取舍。7.有些开发人员水平相对不高，如何确保他们的代码质量？当然首先让较有经验的人Review其要提交的代码，这几乎是所有管理者会做的事。除此之外，管理者有责任帮助这些人〔也包括水平较高的人〕提升水平，他们可以看一些书，上网看资料，读别人的代码等等，途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是，在每年大约3月份为每个工程师制定整个年度的目标，每个人的目标包括产品上的，技术上的，个人能力上的等4到5项。半年后和一年后，要做两次PerformanceReview，目标是否实现，也会跟绩效评定挂钩。我们在制定目标时，遵循SMART原则，即：Specific〔明确的〕：目标应该按照明确的结果和成效表述。Measurable〔可衡量的〕：目标的完成状况应该可以衡量和验证。Aligned〔结盟的〕：目标应该与公司的商业策略坚持一致。Realistic〔现实的〕：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。Time-Bound〔有时限的〕：目标应该包括一个实现的具体时间。比如：某个人制定了“初步掌握本地化技术〞的目标，他要确定实现时间，要描述学习的途经和步骤，要通过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化作一些探究，并制作Presentation给团队演示他的成果，并准备回答其他人提出的问题。团队还为了配合其实现目标，组织TechTalk的活动，供大家分享每个人的学习成果。通过这些手段，提升开发人员的自学兴趣，并逐步提升开发人员的技术水平。8.如何提升开发人员的主观能动性？提升开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业〔Career〕，而不只是一份工作〔Job〕。否则，他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类〔ManagerialPath〕和技术类〔TechnicalPath〕，6个职业级别〔1-3级是Entry/Associate，Intermediate，Senior。4级管