Scrum团队的持续集成之路（1）

       每到项目接近尾声的时候，项目经理往往是心里最没数的时候。项目经理最头痛的问题是，越到项目后期，程序员交付的模块越来越多，联调测试起来bug也越来越多，什么时候能交付？说不清楚。

       下面的问答是几乎每个项目都会出现的：

        老板：按进度的计划，我们能否按时发布产品？

        经理：没法评估，这一轮测试完成的时间我和测试主管可以估算完，但发现了那么多bug，要多少时间修改，要评估过才能知道，就算改完了，后面还要做多少轮测试，我心里也没数。

       老板：那看起来，这次项目的测试时间留得很不充分了。

      经理：是呀，一方面原来预留的测试时间被开发时间挤占了，另一方面，开发的时间也很难估算。新来的那几个工程师提交的模块质量很差，要来回几次测试才能达到集成的水平。这都是原先没有遇见到的。

      老板：开发计划中，模块是分阶段提交的，对已提交模块的测试也并行开展了，为什么到后期的集成测试还有那么多的问题呢？

      经理：初期提交的模块，由于集成度较低，测试工程师测试得不够充分，即使测试过了，随着项目的开展，已经测试过的模块也会有修改，修改过后，原来测试过的功能仍然要测试一遍才放心，越到项目后期，越不可能将原来所做过的测试再测一遍，因此，心里越来越没底。

     老板：那怎么办？加人手，赶紧调人，这个项目不容有失，必须如期完工。

     经理：这个时候加人已经来不及了，新来的人还要老人培训，反而添乱。况且，所有团队都忙，能调谁来啊？

     老板：那怎么办？

     经理：没办法，只好赶兄弟们加班了，到了这个时候，死也要死出来啊。但只能保证东西基本能用，bug是免不了的了。用户投诉有多严重，只能等发布后才知道了。

    

     在我经历的十多年的软件开发项目中，类似的情形或多或少都会出现，只是拼命的程度高低不同而已。跟很多同行交流，这也是行业通病。据调查，软件开发工程师最不满意的就是长期的加班。但这种加班总是难以避免，我们之前也学习和应用了不少软件开发过程管理的方法，试图优化开发组织方式、提升开发计划估算精确度、规范开发流程，提高开发质量，但效果总是不够好，有个长期从事海外项目外包开发管理的朋友甚至跟我说，他尝试了十多种软件规模估算模型，也应用了CMMI等组织方法论，还是没法改变这种项目后期混乱忙碌的局面，很灰心，真想转行了事。

     作为一家软件公司，必须将追求卓越作为企业发展的宗旨，而这一点要获得客户和员工的认同，必须生产出优秀的高质量产品，与此同时，快速到达市场的能力又是竞争制胜的关键。因此，为了做到开发过程又快又好，今年，我的公司整个技术部门进行了敏捷转型，全面拥抱敏捷开发Scrum模式。

     经过了半年多实践，团队已经建立起了像模像样的Scrum运作机制：

     (1) 追求Sprint成功已经成为团队共识

     (2) 每日站会沟通机制

    (3) 成员积极自愿领取任务

    (4) 约定成俗的Sprint计划和总结会议

     我们敏捷了吗？好像是的。但实际上，上述机制除了促进了团队成员之间的交流，提升开发效率和融合工作氛围起到一定的作用外，对产品的质量提升和缩短开发周期并没有很明显的变化，文章开头提到的问答仍然出现。

     道理很简单，要真正做到产品质量提高和缩短开发周期，仅仅在价值观和行为方式上下功夫是不够的，归根结底还是要提高团队的工程实践能力。而突破口就在于推行持续集成技术。

 

     （待续）