敏于思，捷于行――从零开始推行团队级敏捷.docVIP

敏于思，捷于行――从零开始推行团队级敏捷 　　[摘 要]越来越多的软件开发团队将敏捷开发方法应用到软件开发中，但是大部分企业中的团队都没有接触过敏捷，不论是思想上还是流程上都是传统瀑布式的软件开发模式。虽然也想做团队级敏捷开发，却不知道从何入手，如何开展。本文对某项目团队从零开始推行敏捷开发的经验进行介绍，以期望对想要开始引入敏捷开发的团队有所借鉴 　　[关键词]敏捷；团队；改进 　　中图分类号：TP311 文献标识码：A 文章编号：1009-914X（2015）13-0382-01 　　引言 　　传统软件开发方法越来越不能够满足日益复杂和多变的软件需求.敏捷软件开发方法由于具有高度迭代、重视沟通和客户反馈的特性，有效地解决了传统软件方法的不足，因此越来越多的软件开发团队将敏捷开发方法应用到软件开发中。敏捷开发方法正逐渐成为软件开发的新模式。但是很多团队在引入敏捷开发方法的过程中，碰到了各种问题，无法顺利开展敏捷开发。针对这种情况，本文详细介绍了某项目团队从零开始推行敏捷开发的过程，以期望对想要开始引入敏捷开发的团队有所借鉴。 　　1.项目背景分析 　　团队在传统瀑布型开发模式中处于“开发”阶段，上游是SE的方案文档，下游是测试工程师。项目团队成员为20人。 　　1.1 项目的特点 　　该项目团队开发的软件系统的组网场景非常复杂，需要同时支持多种组网、应用场景和多种语言环境的组合： 　　（1）组网场景：单层、双层 　　（2）语言环境：中文、日文、英文 　　（3）应用场景：全新安装、旧版本升级 　　上述组合后共有2*3*2=18种场景。 　　由于组网的复杂和多样以及原始架构不合理，一个小的需求改动经常需要修改非常多的代码文件，例如： 　　（1）新增配置：15～25个文件 　　（2）新增参数：10～20个文件 　　（3）改配置名称：20个文件 　　这就造成一旦有需求或改动，非常容易出现代码漏改、场景验证不全的情况。 　　1.2 项目团队的痛点 　　基于该软件系统的特点，加上不断的需求改动，团队面临着深陷泥潭的局面： 　　（1）需求不断，开发之后还来不及仔细验证就要提交版本，导致版本质量差； 　　（2）系统复杂，改动之后总有验证不全的情况，导致系统测试出现低级错误； 　　（3）开发人员整天现在需求和故障单中无法自拔，团队士气低落，无积极性； 　　（4）版本质量差导致业务测和下游测试抱怨甚多，更加深了团队的抵触情绪； 　　（5）团队内出现破罐子破摔的现象，成员无法认清自己的问题，怨天尤人； 　　在这种情况下，如果不能打破局面，那么最终可能导致项目版本越做越差。如何打破局面，改变现状，成了团队迫在眉睫需要解决的问题。 　　1.3 敏捷推行实践 　　针对上述问题，团队决定开始正式引入敏捷开发。但是团队没有敏捷实践的基础和经验，如何开始实施呢？ 　　1.4 敏捷推进者 　　首先，必须有一个团队敏捷推进者。在整个从零开始推行敏捷开发的过程中，敏捷推进者始终需要发挥推进、教练的作用，一方面为大家实施敏捷指明方向，另一方面需要解答大家在实施过程中的疑惑。这是一个非常重要的角色。 　　这个推进者的最佳人选就是Team Leader。Team Leader结合团队的现状分析制定出推进计划，并带领团队一步步实施、达到目标，团队才有可能最终实现敏捷开发，并走向良性循环发展的道路。 　　1.5 第一个敏捷实践活动 　　敏捷实践从大的方面分为两部分：管理实践和技术实践。一般的管理实践包括：迭代开发模式、澄清估算会、每日立会、演示会、回顾会、防火墙、故事墙、结对编程、任务自认领等；技术实践包括：持续集成、故事拆分等。当然分类也不限于此，有些实践同属于技术和管理两方面。 　　持续集成的第一步是自动测试，自动测试的第一步是编写和补充测试用例，分步骤操作，每个步骤都要花费很长的时间，要做好长期战斗的准备，不要做做觉得花费时间太多就放弃了。 　　2 如何培养“多面手” 　　有了初步的持续集成环境，接下来就要想办法成为“多面手”了。 　　在敏捷的各类书籍和课程中，最推崇的使团队成员成为“多面手”的实践，有条件的团队建议实施。 　　对于没有条件实施结对编程的团队，还可以从“防火墙”开始培养。团队经过多次防火墙成员的轮换，人员能力有了一定提高，为后面任务自认领打下基础。 　　当然，“多面手”不是十天半个月，做个防火墙队员就能培养成的。在后续Scrum的操作过程中，也需要将人员培养考虑进去，逐步实现多人熟悉多模块。 　　在持续集成初见成效的基础上，我们开始了Scrum的逐渐引入。 　　第一批引入的活动包括：每日立会、回顾会。 　　这两个会操作最简单，有现成的套路，可以在走形式中逐渐发现