敏于思,捷于行――从零开始推行团队级敏捷

[摘 要]越来越多的软件开发团队将敏捷开发方法应用到软件开发中，但是大部分企业中的团队都没有接触过敏捷，不论是思想上还是流程上都是传统瀑布式的软件开发模式。虽然也想做团队级敏捷开发，却不知道从何入手，如何开展。本文对某项目团队从零开始推行敏捷开发的经验进行介绍，以期望对想要开始引入敏捷开发的团队有所借鉴

[关键词]敏捷；团队；改进

中图分类号：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的逐渐引入。

第一批引入的活动包括：每日立会、回顾会。

这两个会操作最简单，有现成的套路，可以在走形式中逐渐发现问题并不断适应。

每日立会在最开始的时候一定会被开成汇报会，但只要坚持开、每天开，慢慢地就会对反馈、风险等起到作用，只要是1～2分钟的可以解决疑虑和问题的讨论是允许的，需要做的是控制发散而不是杜绝讨论。

另外，在回顾会上，大家一定会把“立会走形式”这个问题提出来，这样对立会如何改进也就有了讨论和举措，这也是把回顾会和立会同时引入的原因之一。

回顾会按照Scrum中的套路走就可以了，关键几点注意的是：

（1）问题的提出要靠大家而不是领导；

（2）措施的提出和讨论也要靠大家，主持人可以进行归纳汇总；

（3）措施一定是要可以具体执行的、有责任人的，也可以明确具体的执行时间点。

在每日立会和回顾会实行半年之后，第二批引入角色分工、澄清会、product backlog、sprint backlog、故事墙。

最开始的角色分工是有要求的，一定要选择合适的人担任合适的角色：

（1）SM的基本要求：接受敏捷的思想、责任心强、有耐心、细致、有一定的组织能力；

（2）BA的基本要求：对需要分析的需求来说，是团队内的“专家”，责任心强；

（3）QA的基本要求：对需求的理解能力强，责任心强，细致；

人员角色定下来之后，需要定义每个角色的具体工作内容。

特别需要说明的是，只要条件允许，最好刚开始实施角色分工的时候，就实现任务自认领。我们需要做的应该是加强代码走查、加强BA、QA等验收环节，而不是限制开发人员的认领范围。

在澄清会上，SM需要把控澄清不会发散讨论，同时还需要确确实实澄清清楚：没讲清楚的就不要开发，时间来不及就不要硬挤时间而草草澄清。

Product backlog最重要的是列清楚需求的优先级，sprint backlog需要记录每张故事卡的状态和实际工作量信息。

上述几个活动实行一段时间后，经过多次回顾改进并让团队形成习惯，最后可以将演示会和燃烧图放进来。

3 实践总结

根据该项目团队实践的过程，结合项目的现状，总结了如下的实施步骤

（1）团队的TeamLeader学习了解敏捷思想和经验，为敏捷推进和团队教练打基础；

（2）团队研究实施自动化测试，搭建最简单的持续集成环境；

（3）引入防火墙，有条件可以针对特定功能引入结对编程试点；

（4）在开发过程中见缝插针实现用例补充、代码重构、问题修改（根据实际项目特点从无到有大约要花费几个月到一年多的时间，一定要坚持下来，积少成多就是质变）；

（5）在补充用例和完善持续集成的过程中可以开展团队内的敏捷导入培训，引入每日立会和回顾会（注意不要因为立会走形式就放弃它，回顾会的措施一定要可实施并落实责任人）；

（6）持续集成初见成效（完成70%以上的用例补充，测试框架比较成熟），防火墙至少轮值一轮之后，引入角色分工、故事墙、澄清会、产品backlog和迭代backlog（注意要始终保持防火墙和需求开发两个团队，保证需求开发人员不受外界干扰）；

（7）当流程被大家试行并接受之后，引入演示会；

（8）流程在不断的回顾改进后走顺畅，大家逐渐行程习惯，开始进一步加深技术实践，包括持续集成用例（各种级别的：模块测试用例、集成测试用例、静态代码检查工具等）、重构提升内部质量。

特别需要提出的就是：对于从零开始推行团队级敏捷，技术实践一定要先行，这个是成功的关键。

参考文献

[1] Mike Cohn著.《用户故事与敏捷方法》 清华大学出版社，2010.03

[2] Henrik Kniberg著.《硝烟中的Scrum和XP：我们如何实施Scrum》 清华大学出版社，2010.12.