敏捷激活三步曲:素颜三部曲多少钱

　　在敏捷正在成为软件开发主流思想的今天，如何有效地在一个组织实施敏捷却才刚刚起步。从了解敏捷起步到相信敏捷，最后用敏捷的方式思考，本文提出了一种非常有效的让敏捷开发落地的策略。
　　
　　“敏捷”是时下的IT圈子里一个非常吸引眼球的词汇。很多人误认为敏捷就是一种软件开发的流程或者实践，而其实敏捷是一组开发流程和实践的方法论。这种方法论的背后是2001年由17位资深软件开发专家在美国犹他州的一个会议上总结出的敏捷思想。时至今日，敏捷思想激活逐渐成为了软件开发业的主流。全球不同规模、模式的IT组织已经从实施敏捷开发流程及实践中取得了巨大的成功。而我国不少的IT组织也开始了解、学习敏捷思想，希望自己的组织能从实施敏捷中获益。
　　然而，一个组织要接受一种新的开发模式并不容易。笔者对近期参与的一些敏捷项目进行了总结，在此与大家分享组织实施敏捷的方法以及组织实施敏捷过程中需要注意的一些问题。
　　为帮助大家理解，文中使用的敏捷词汇简单解释如下。
　　●故事: 描述一个有价值的需求的文档。
　　●迭代: 一个开发周期，往往是一组故事完成的周期。
　　●XP: 敏捷倡导者Kent Beck提出的一组软件开发的方法。
　　●Scrum: 一种敏捷项目管理方法
　　
　　组织保证
　　在谈论怎样在一个IT组织、企业实施敏捷之前，首先从组织架构上予以保证。那么，什么样的组织架构最适合敏捷？
　　很多IT企业采用矩阵式组织结构，其中既有按职能划分的垂直领导系统，又有按产品（项目）划分的横向领导关系。一个项目团队的成员来自不同部门，隶属关系仍在原单位。很多时候一人同时参加数个项目，其中尤以质量管理人员（质量分析师、测试员等）最为普遍。这样的组织结构下，每个项目成员一般受双重管理（所在项目及隶属部门），这种组织结构存在的问题是明显的: 首先，双重管理容易破坏项目团队的整体性，部门领导和项目管理者容易产生步调上的不一致; 其次，由于团队管理的复杂化，项目透明度不高，很少有融入客户（业务部门）的机制，其后果是不能围绕客户和市场的真实需求来展开开发工作。
　　对比上面提到的矩阵式组织结构，敏捷组织需要弱化职能部门的划分，更多由跨职能、面向价值交付的团队构成。大家可能会立刻问: 这样的组织结构价值在哪里？下面我们就从三个方面来分析其价值。
　　敏捷组织价值一:
　　统一的团队
　　在传统结构下，团队采取“会战”方式组成，人员之间很容易因职能隔离，导致团队内垂直划分，从而不能成为一个统一团队。各职能成员容易各自为政、目标不一。一个典型的现象是，开发人员常常在内心抵触质量管理人员提出的要求，而质量管理人员又总是对开发的系统缺乏信心，项目管理者很多时候感到力不从心，不能激励团队成员，更无法谈到融入客户、拥抱变化了。
　　由于敏捷组织弱化了职能部门，敏捷团队成员全职投入到项目组中，增加了每人的团队归属感。原来一个人同时被分派多个项目的做法显然是不利于团队建设的，与之相反，敏捷组织要求员工积极参加到自己团队的日常活动中，鼓励员工参与不同职能的工作。
　　
　　图1简单展示了一个迭代过程中业务分析人员、开发人员、质量管理人员及项目管理人员的日常工作。我们可以看到，除了每个职能例行的工作之外（如质量管理人员要完成上个迭代的故事测试，然后投入到这个迭代新故事的测试工作中），作为一个团队，大家要共同参与如“迭代开题”、“上迭代回顾”等集体活动。以“下个迭代计划”为例，项目管理人员需要安排组织会议、控制会议时间; 业务分析人员要解释下一个迭代故事的选择; 开发人员及质量管理人员则要了解相关需求，同时提出可能要进一步细化或要求重新评估的故事。通过这样一系列的活动，项目管理达到了高度的透明。同时我们可以看到客户（客户代表）被融入到团队中。远离客户的团队不可能是一个敏捷的团队，客户的参与是保证最终价值交付的关键。
　　从上面的讨论中，不难想象如果不是具有高度自组织能力、统一的团队，是无法贯彻敏捷开发思想的。这样的参与度，也让每一个团队成员很快拥有项目的主人翁精神。一言以蔽之，敏捷组织通过强调集体共有及发挥每个成员主观能动性来打造统一团队。
　　敏捷组织价值二:
　　价值驱动
　　谈到价值，首先就要明确什么是价值。对于软件开发项目而言，答案其实就在下面这个问题里。
　　假设在两个项目开发过程中市场都在不停变化: 项目A按时、按预算交付所有计划功能，不幸的是项目本身未能给客户带来任何帮助; 项目B因为响应变化，所以延时、超出预算交付了部分功能，但却帮助客户取得了盈利。传统项目管理方式下我们说项目A是成功的，项目组完成了计划。现实却恰恰相反，项目A没有带来任何的价值，因为它对使用者没有帮助。在现今IT市场需求快速变化的时代，按时、按预算交付已经不能成为衡量项目成败的唯一标准。
　　然而，要用价值作为驱动力就必须先有感知价值变化的能力。一个团队要有感知价值变化的能力就必须是一个有高度协作精神、步调统一的团队。正如GE前总裁韦尔奇所说: “如果我们穿着四件毛衣，那么我们就感觉不到寒冷了。”传统组织下的团队就像穿上了一件件“职能”的“毛衣”，很难感受到价值的所在。更无从谈起将客户（或业务部门）的需求转换为团队共识的价值、拥抱需求的变化了。
　　敏捷团队在项目管理上的高度透明及全程的客户融入实际是将最终的客户需求植入到了每一个成员的心里，让不同职能的团队成员都能用价值来衡量自己的工作，从而使价值成为我们各种开发活动的驱动力。
　　敏捷组织价值三:
　　减少浪费
　　时下很流行把敏捷与精益制造相对比，这里我们无意讨论精益，但精益的一个重要原则“减少浪费”在敏捷的组织结构里却得到了体现。
　　韦尔奇在20世纪80年代曾经用“零管理层”、“无边界行动”等理念将GE打造成美国最伟大的公司之一。在GE一个8000名员工的航空发动机工厂，只有一个厂长和全厂职工两个阶层，没有任何中间管理层。一般工厂常见的车间、工段、班组、工会、人事、财务、计划、技术、材料、供销等所有部门全部取消。在生产过程中所必需的管理职务由工人轮流担任。而一些临时性的工作，如招收新工人，就由各岗位老工人临时组成人事部门，完成之后即解散。这种扁平组织的思想与敏捷组织结构不谋而合！当我们弱化职能划分的时候，相应地那些为职能部门设立的各种烦琐的管理细节也被同时精简; 当我们打造一个统一的敏捷团队时，相应地按职能来管理人员的机制也就不再需要了。
　　在参与的敏捷项目中，我们经常听到传统组织团队中资深开发领导者这样说: “我很喜欢技术，真想跟大家一起开发。可惜日常的上下汇报、文档邮件占去了我所有的时间。根本没法参与开发！”我们不由得慨叹这种人员上的双重浪费。由于烦琐的管理细节，扼杀了团队宝贵技术资源的使用，同时也扼杀了资深人员进一步学习的可能。要消除烦琐的管理工作就必须打造有自组织能力的统一团队，这正是敏捷思想所追求的。
　　
　　敏捷实施路线图
　　实施敏捷是一个组织长期自我改善的过程。根据实际情况往往可以分为三个阶段来帮助一个组织实施敏捷（参见图2）。
　　
　　实施敏捷的过程中，组织管理者往往非常关心怎样去评估一个组织的敏捷程度。由于IT企业的多样性，评估一个组织的“敏捷成熟度”不能用一刀切的标准。图3展示了我们评估一个企业敏捷实施情况的一系列维度。红条为现状，蓝条为设定的目标。每一个维度实际又从不同的角度来考查。比如“测试质量”，我们考查使用测试的种类、测试环境、自动化程度、测试运行频率及测试用户。到达尺标5则要求各种层级的测试（单元、功能、集成等）都被分级自动化，并且融入到一个故事的开发周期中由不同人员（开发、测试、客户等）实施。
　　
　　这里值得提起大家注意的是: 我们的目标是不是要所有维度都达到最优化（即到达尺度5）？或者说是不是只有各个维度最优化才能说敏捷实施成功了？答案是否定的。首先，要提高一个维度的指标必然需要一定的投入，比如想要更多地自动化测试，就会涉及选用或购买新工具，对相关人员进行培训。运用敏捷思想，衡量是否需要的标准就是价值，如果我们开发一个简单的网络应用，自动化所有测试带来的质量提高也许就远远小于我们的投入。所以，评估一个组织的敏捷程度绝对不能一概而论，一定要结合开发项目的实际情况。
　　下面让我们看看这三个阶段实施过程中需要做些什么。
　　敏捷激活第一步:
　　让大家了解敏捷
　　敏捷在软件开发业界已经成为主流。我们经常听到不少组织说我们用Scrum了，我们“敏捷”了。事实上Scrum也仅仅是敏捷思想下的一种比较流行的采用迭代式开发方式的管理实践。这样的说法暴露出不少人对敏捷的误解。敏捷是一种思想，有着很强的包容性。如何定义敏捷是一个比较困难的问题。笔者倾向于用敏捷宣言及原则来衡量一个流程、一个实践是否敏捷。
　　第一步是要争取组织领导者对实施敏捷的支持，我们必须认识到敏捷的全面实施是会涉及到部分组织变革的，而组织变革要求上下一心方能成功。
　　在了解过程中，我们希望给组织的成员传达正确的敏捷思想，让大家了解敏捷的思维方式，学会用价值来衡量日常开发工作。当思想得到统一后，即进入分角色培训阶段，一般情况会分为三组: 项目管理人员、业务分析人员组; 开发人员组; 质量管理人员组。项目管理和业务分析在敏捷中其实是分开的两个职能，但很多时候我们发现传统IT企业或小型开发团队中一般业务分析是由项目经理来完成的，项目经理因此对这两类活动负责。
　　培训过程中我们常展示一张“敏捷生态图”（见图4），它包含了敏捷常见的一些实践。生态图大致按三圈（即个人、团队、组织）来绘制。个人实践主要还是面向开发人员，吸取了XP的精华。团队和组织实践结合了不少Scrum的实践，并且强调了客户及统一团队的重要性。
　　
　　敏捷激活第二步:
　　让大家相信敏捷
　　支持是建立在了解的基础上的。怎样让组织的成员相信敏捷的应用能够帮助大家提高工作效率、保证工作质量是这个阶段的重点。比较成熟的实践是由一个较为资深的敏捷组织和准备实施敏捷的组织共同组建一个项目团队，并且拿出一个试点的项目由这个联合团队开发。联合团队将采用结对的工作方式，即每个团队角色都由资深敏捷组织出人与新实施敏捷组织中同职能人员一起工作。试点项目一般要求是一个全新或相对独立的系统以避免遗留系统带来的技术难题分散了我们实施敏捷的主题。试点项目的选取一般会有两种形式: 假想一个相关系统或一个真实的项目系统。
　　使用假想的系统好处是可以方便地隔离很多外部干扰，比如对其他没有实施敏捷团队的依赖。缺点是真实性不足，不是很容易让人员全身心投入，而且不能充分暴露出真实开发过程中可能出现的问题。另一方面，采用真实项目团队很可能要承受交付压力，对一个在学习敏捷实施的团队，压力会产生很多负面作用。
　　联合团队开发过程中我们一般会采用各种物理手段来增加项目的可视性。这里最值得一提的是故事墙（在一面墙上以一些小纸条展示各个部分的进度及相关问题）。通过使用故事墙，我们可以很好地达到统一团队的目的。人员的日常工作通过故事墙展现出来，项目管理者及客户可以通过故事墙来了解一个团队的进度及表现。围绕故事墙，还可以使用各种辅助图表来跟踪整个项目、一个迭代或一个功能的进度并快速发现可能的问题。
　　敏捷激活第三步:
　　让大家用敏捷思考
　　通过试点项目，整个团队应该对敏捷开发过程有了实际的理解。这个时候需要用敏捷思想来总结项目中的各个环节，找出适合组织、团队的敏捷实践。这个阶段大家往往会希望回顾一下试点项目是否是成功的。这时一个不可避免的问题就是怎样来衡量成功呢？
　　本文开始我们探讨价值时对比了两个项目，那么试点项目的价值是什么？项目按时、高质量交付固然是有价值的，然而，更重要的应该是试点的目的: 我们希望通过实际操作来找到适合组织、团队的开发方式，我们希望学会用敏捷的方式来思考和判断问题。一般在提高软件质量和提高团队凝聚力上，大家都能达成共识。但常见的结论中也有敏捷开发方法加大了工作量，开发中的结对编程增加了人力成本，或是拖长了开发周期等。这些结论的得出很大程度上忘记了我们试点的目的。工作量的加大是必然的，因为团队在学习新的流程、新的方法。结对实际是最有效的学习手段，在2008年全球网上发起的开发人员就测试驱动开发学习方法有效性的投票中，与有经验的开发者结对学习被选为最有效的学习手段。在我们推行“结对”的过程中，也惊喜地发现不少组织成员已经开始将“结对”灵活使用到日常工作中，比如两个团队人员共同的技术问题很快就由双方的技术人员结对进行了统一解决。因此，衡量试点项目的成功更多的是要从团队成员能否通过项目实战学会从用敏捷思想考虑问题入手。
　　这个阶段很多的组织会尝试推广敏捷，各个组织的做法更多的是根据自己的实际情况出发。值得一提的是，敏捷的组织应该向一个知识型、自组织型的组织努力。打造这样的组织我们需要提供多方面的支持，比如，对相关人员，特别是各项目管理者的培训; 尽量让项目组能够集中办公，增强人员的团队意识; 成立敏捷学习兴趣小组，鼓励大家互相学习分享经验等等。
　　作者简介
　　肖然 ThoughtWorks咨询师, 计算机科学博士。在国际一流学术期刊杂志发表多篇学术论文，并在多个国际学术会议中演讲。加入ThoughtWorks后, 肖然致力于研究、实践如何将敏捷思想融入于国内软件开发项目中。