每到项目接近尾声的时候,项目经理往往是心里最没数的时候。项目经理最头痛的问题是,越到项目后期,程序员交付的模块越来越多,联调测试起来bug也越来越多,什么时候能交付?说不清楚。
下面的问答是几乎每个项目都会出现的:
老板:按进度的计划,我们能否按时发布产品?
经理:没法评估,这一轮测试完成的时间我和测试主管可以估算完,但发现了那么多bug,要多少时间修改,要评估过才能知道,就算改完了,后面还要做多少轮测试,我心里也没数。
老板:那看起来,这次项目的测试时间留得很不充分了。
经理:是呀,一方面原来预留的测试时间被开发时间挤占了,另一方面,开发的时间也很难估算。新来的那几个工程师提交的模块质量很差,要来回几次测试才能达到集成的水平。这都是原先没有遇见到的。
老板:开发计划中,模块是分阶段提交的,对已提交模块的测试也并行开展了,为什么到后期的集成测试还有那么多的问题呢?
经理:初期提交的模块,由于集成度较低,测试工程师测试得不够充分,即使测试过了,随着项目的开展,已经测试过的模块也会有修改,修改过后,原来测试过的功能仍然要测试一遍才放心,越到项目后期,越不可能将原来所做过的测试再测一遍,因此,心里越来越没底。
老板:那怎么办?加人手,赶紧调人,这个项目不容有失,必须如期完工。
经理:这个时候加人已经来不及了,新来的人还要老人培训,反而添乱。况且,所有团队都忙,能调谁来啊?
老板:那怎么办?
经理:没办法,只好赶兄弟们加班了,到了这个时候,死也要死出来啊。但只能保证东西基本能用,bug是免不了的了。用户投诉有多严重,只能等发布后才知道了。
在我经历的十多年的软件开发项目中,类似的情形或多或少都会出现,只是拼命的程度高低不同而已。跟很多同行交流,这也是行业通病。据调查,软件开发工程师最不满意的就是长期的加班。但这种加班总是难以避免,我们之前也学习和应用了不少软件开发过程管理的方法,试图优化开发组织方式、提升开发计划估算精确度、规范开发流程,提高开发质量,但效果总是不够好,有个长期从事海外项目外包开发管理的朋友甚至跟我说,他尝试了十多种软件规模估算模型,也应用了CMMI等组织方法论,还是没法改变这种项目后期混乱忙碌的局面,很灰心,真想转行了事。
作为一家软件公司,必须将追求卓越作为企业发展的宗旨,而这一点要获得客户和员工的认同,必须生产出优秀的高质量产品,与此同时,快速到达市场的能力又是竞争制胜的关键。因此,为了做到开发过程又快又好,今年,我的公司整个技术部门进行了敏捷转型,全面拥抱敏捷开发Scrum模式。
经过了半年多实践,团队已经建立起了像模像样的Scrum运作机制:
(1) 追求Sprint成功已经成为团队共识
(2) 每日站会沟通机制
(3) 成员积极自愿领取任务
(4) 约定成俗的Sprint计划和总结会议
我们敏捷了吗?好像是的。但实际上,上述机制除了促进了团队成员之间的交流,提升开发效率和融合工作氛围起到一定的作用外,对产品的质量提升和缩短开发周期并没有很明显的变化,文章开头提到的问答仍然出现。
道理很简单,要真正做到产品质量提高和缩短开发周期,仅仅在价值观和行为方式上下功夫是不够的,归根结底还是要提高团队的工程实践能力。而突破口就在于推行持续集成技术。
(待续)