敏捷实施路线图

　　实施敏捷是一个组织长期自我改善的过程。根据实际情况往往可以分为三个阶段来帮助一个组织实施敏捷（参见图2）。

            

　　实施敏捷的过程中，组织管理者往往非常关心怎样去评估一个组织的敏捷程度。由于IT企业的多样性，评估一个组织的“敏捷成熟度”不能用一刀切的标准。图3展示了我们评估一个企业敏捷实施情况的一系列维度。红条为现状，蓝条为设定的目标。每一个维度实际又从不同的角度来考查。比如“测试质量”，我们考查使用测试的种类、测试环境、自动化程度、测试运行频率及测试用户。到达尺标5则要求各种层级的测试（单元、功能、集成等）都被分级自动化，并且融入到一个故事的开发周期中由不同人员（开发、测试、客户等）实施。

                

　　这里值得提起大家注意的是: 我们的目标是不是要所有维度都达到最优化（即到达尺度5）？或者说是不是只有各个维度最优化才能说敏捷实施成功了？答案是否定的。首先，要提高一个维度的指标必然需要一定的投入，比如想要更多地自动化测试，就会涉及选用或购买新工具，对相关人员进行培训。运用敏捷思想，衡量是否需要的标准就是价值，如果我们开发一个简单的网络应用，自动化所有测试带来的质量提高也许就远远小于我们的投入。所以，评估一个组织的敏捷程度绝对不能一概而论，一定要结合开发项目的实际情况。

　　下面让我们看看这三个阶段实施过程中需要做些什么。

　　敏捷激活第一步:

　　让大家了解敏捷

　　敏捷在软件开发业界已经成为主流。我们经常听到不少组织说我们用Scrum了，我们“敏捷”了。事实上Scrum也仅仅是敏捷思想下的一种比较流行的采用迭代式开发方式的管理实践。这样的说法暴露出不少人对敏捷的误解。敏捷是一种思想，有着很强的包容性。如何定义敏捷是一个比较困难的问题。笔者倾向于用敏捷宣言及原则来衡量一个流程、一个实践是否敏捷。

　　第一步是要争取组织领导者对实施敏捷的支持，我们必须认识到敏捷的全面实施是会涉及到部分组织变革的，而组织变革要求上下一心方能成功。

　　在了解过程中，我们希望给组织的成员传达正确的敏捷思想，让大家了解敏捷的思维方式，学会用价值来衡量日常开发工作。当思想得到统一后，即进入分角色培训阶段，一般情况会分为三组: 项目管理人员、业务分析人员组; 开发人员组; 质量管理人员组。项目管理和业务分析在敏捷中其实是分开的两个职能，但很多时候我们发现传统IT企业或小型开发团队中一般业务分析是由项目经理来完成的，项目经理因此对这两类活动负责。

　　培训过程中我们常展示一张“敏捷生态图”（见图4），它包含了敏捷常见的一些实践。生态图大致按三圈（即个人、团队、组织）来绘制。个人实践主要还是面向开发人员，吸取了XP的精华。团队和组织实践结合了不少Scrum的实践，并且强调了客户及统一团队的重要性。

              

　　敏捷激活第二步:

　　让大家相信敏捷

　　支持是建立在了解的基础上的。怎样让组织的成员相信敏捷的应用能够帮助大家提高工作效率、保证工作质量是这个阶段的重点。比较成熟的实践是由一个较为资深的敏捷组织和准备实施敏捷的组织共同组建一个项目团队，并且拿出一个试点的项目由这个联合团队开发。联合团队将采用结对的工作方式，即每个团队角色都由资深敏捷组织出人与新实施敏捷组织中同职能人员一起工作。试点项目一般要求是一个全新或相对独立的系统以避免遗留系统带来的技术难题分散了我们实施敏捷的主题。试点项目的选取一般会有两种形式: 假想一个相关系统或一个真实的项目系统。

　　使用假想的系统好处是可以方便地隔离很多外部干扰，比如对其他没有实施敏捷团队的依赖。缺点是真实性不足，不是很容易让人员全身心投入，而且不能充分暴露出真实开发过程中可能出现的问题。另一方面，采用真实项目团队很可能要承受交付压力，对一个在学习敏捷实施的团队，压力会产生很多负面作用。

　　联合团队开发过程中我们一般会采用各种物理手段来增加项目的可视性。这里最值得一提的是故事墙（在一面墙上以一些小纸条展示各个部分的进度及相关问题）。通过使用故事墙，我们可以很好地达到统一团队的目的。人员的日常工作通过故事墙展现出来，项目管理者及客户可以通过故事墙来了解一个团队的进度及表现。围绕故事墙，还可以使用各种辅助图表来跟踪整个项目、一个迭代或一个功能的进度并快速发现可能的问题。

　　敏捷激活第三步:

　　让大家用敏捷思考

　　通过试点项目，整个团队应该对敏捷开发过程有了实际的理解。这个时候需要用敏捷思想来总结项目中的各个环节，找出适合组织、团队的敏捷实践。这个阶段大家往往会希望回顾一下试点项目是否是成功的。这时一个不可避免的问题就是怎样来衡量成功呢？

　　本文开始我们探讨价值时对比了两个项目，那么试点项目的价值是什么？项目按时、高质量交付固然是有价值的，然而，更重要的应该是试点的目的: 我们希望通过实际操作来找到适合组织、团队的开发方式，我们希望学会用敏捷的方式来思考和判断问题。一般在提高软件质量和提高团队凝聚力上，大家都能达成共识。但常见的结论中也有敏捷开发方法加大了工作量，开发中的结对编程增加了人力成本，或是拖长了开发周期等。这些结论的得出很大程度上忘记了我们试点的目的。工作量的加大是必然的，因为团队在学习新的流程、新的方法。结对实际是最有效的学习手段，在2008年全球网上发起的开发人员就测试驱动开发学习方法有效性的投票中，与有经验的开发者结对学习被选为最有效的学习手段。在我们推行“结对”的过程中，也惊喜地发现不少组织成员已经开始将“结对”灵活使用到日常工作中，比如两个团队人员共同的技术问题很快就由双方的技术人员结对进行了统一解决。因此，衡量试点项目的成功更多的是要从团队成员能否通过项目实战学会从用敏捷思想考虑问题入手。

　　这个阶段很多的组织会尝试推广敏捷，各个组织的做法更多的是根据自己的实际情况出发。值得一提的是，敏捷的组织应该向一个知识型、自组织型的组织努力。打造这样的组织我们需要提供多方面的支持，比如，对相关人员，特别是各项目管理者的培训; 尽量让项目组能够集中办公，增强人员的团队意识; 成立敏捷学习兴趣小组，鼓励大家互相学习分享经验等等。

　　作者简介

　　肖然 ThoughtWorks咨询师, 计算机科学博士。在国际一流学术期刊杂志发表多篇学术论文，并在多个国际学术会议中演讲。加入ThoughtWorks后, 肖然致力于研究、实践如何将敏捷思想融入于国内软件开发项目中。