几个软件研发管理的问题.doc

几个软件研发管理的问题.doc:..几个软件研发团队管理的小问题最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:“我们公司最大的问题是项目不能按时完成,总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始,在随后的交谈屮,又引出他一连串在软件研发管理中的遇到的问题,包括:•现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?.重构会造成回退,怎样避免?・有些开发人员水平相对不高,如何保证他们的代码质量?・软件研发到底需不需要文档?•要求提交代码前做CodeReview,而开发人员不做,或敷衍了事,怎么办?・当有开发人员在开发过程中遇到难题,工作无法继续,因而拖延进度,怎么解决?.如何提高开发人员的主观能动性?其实,每个软件研发团队的管理者都而临着或曾经面临过这些问题,也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。,总要一拖再拖,怎么改变?找解决办法前,当然要先知道问题为什么会出现。这位总经理说:“总会不断地有需求要改变和新需求提出来,使原来的开发计划不得不延长。”原来如此。知道根源,当然解决办法也就有了,那就是“敏捷”。敏捷开发因其迭代(Iterative)和增量(Incremental)的思想■实践,正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念,特别是Scrum的框架后,总经理也表示了对“敏捷”的认同。其实仔细想想,这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间,往往由高级管理层根据市场情况决策和确定。在很多软件企业屮,这些决策者在决策时往往忽略了一个垂要的参数,那就是团队的生产率(Velocity)o生产率需要量化,而不是“拍脑门子”感觉出來的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷,在估算产品交付时间或项目完成时间时,是相对较准确的。Scrum创始人Z—的JeffSutherland说,他在一个风险投资团队做敏捷教练时,团队中的资深合伙人会向所有的待投资企业问同一个问题:“你们是否清楚团队的生产率?”而这些企业都很难做岀明确的答复。软件企业要想给产品定一个较实际的交付日期,就首先要弄清楚自己的软件生产率。,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?这可能是很多软件开发工程师都有过的体验,在接手別人的代码时,看不懂、无法加新功能,读代码读的头疼。这说明什么?排除接手人个人水平的因索,这说明旧代码可读性、可扩展性比较差。怎么办?这时,也许重构是i种两全其美的办法。接手人重构代码,既能改善ILI代码的可读性和可扩展性,又不至于因重写代码带來的时间上的风险。从接手人心理的角度看,垂构还有一个好的副作用,就是代码重构之后,接手人觉得那些原來的“烂”代码被修改成为自己引以自彖的新成就。《Scrum敏捷软件开发》的作者MikeCohn写到过「我的女儿们画了一幅特别令人赞叹的杰作后,她们会将它从学校带回家,并想把它展示在一个明显的位置,也就是冰箱上面。有一天,在工作中,我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西,所以我就将它放上去了。