成功实施敏捷之十荐-InfoQ

我并不是第一个写“高效的敏捷实施之十大习惯”此类文章的人，我也肯定不会是最后一个。事实上我并不想又创建出这么个长长的列表，因为有太多类似的列表充斥着敏捷实施的世界。

曾有人报道 Ken Schwaber 说过在所有试图实施 Scrum 的团队中大约只有 30% 的团队能够成功。但 Ken 在他的博客上说他并不记得这么说过，反而指出大约只有 30% 的团队能够成为“出色的开发组织”。

而我认为这条引用有趣之处在于它符合众多变更管理的案例。正如变更专家哈佛教授 John Kotter 经常提到的有 70% 的重大变更将会以失败而告终。

然而当你真正研究下数据，你会发现这个预测并不乐观。有一天当我授完课，有人问我：“我们能做些什么来保证我们能成为那 30% 成功的团队之一？”——那个时刻我知道我会创建这个列表。并不是说 10 这个数字有什么魔力，这个列表也可以是 7 项或 12 项，这个列表的数目可以是这三个数字中的任意一个。但当我真正把所有的列表项放在一起时，我发现比起其他我能想到的，或者那些不那么有效的项，10 项是不多也不少。

因此，这个世界又多了一个“十大”列表。

1) 找一块真正的白板

“我把霰弹枪装进阿迪达斯运动包，又往里塞了四双网球袜，把包包填实在。这完全不是我的风格，可我要的正是这种效果：如果他们觉得你是个凶悍家伙，就跟他们玩技术；如果他们觉得你是个技术型，就跟他们玩凶悍。我是技术型，所以我决定凶悍点，越凶越好。”William Gibson 的短篇故事——Johnny Mnemonic 中如是说。

我非常确定的是，成功实施敏捷的团队与没能完成敏捷实施的团队之间最简单最大的区别就在于，他们使用了一块真正的实体白板。

我明白有些团队觉得搞一块真正的白板很难做到，我也明白有些团队分散在不同地域以至于无法共用实体白板，我也明白可以通过计算机技术（电子白板）来实现白板功能，但我仍然坚持我的观点。如果你能搞来一块真正的白板，让大多数但不一定全部团队成员都能看到，那你就会接近成功。

这似乎很难解释我这么建议的理由，但你必须去亲自尝试它，体会它。我个人感觉当抽象的、理论的软件世界遇见真正白板和卡片时会发生奇妙的事情。

让你的工作具体化仅仅是个开始，学会如何看懂白板上的内容并根据这些开始工作则更为重要。

2) 启动数据收集并使用统计数据

开发速率、燃尽图、发现的 Bug、记录的 Bug 等等。在软件开发的很多情况下，度量数据的名声都不好，但这是由于人们并未很好地选择合适的度量数据，或者收集与使用的不当所造成，并不能代表度量数据是无用的。你至少需要度量你的开发速率并创建一个燃尽图或一个累计流量图。

敏捷的优雅之处在于你只需去度量它的一些简单的度量数据。一旦度量太过复杂以至于人们无法理解，那就无法从中受益了。正如白板，度量数据只因自身价值而变得有用，切勿变成一种学习仪器。

3) 聘用一位教练或顾问

虽然我必须承认你完全可以自己实施敏捷模式，我仍然愿意冒着被大家指控为自己揽活的风险，如此建议。你可以看书、做实验、看一些课程。但这样做将使得整个敏捷模式的流程变得缓慢并且增加了风险以至于你无法成为那 30% 成功的团队。更糟的是敏捷实施将变得冗长并引入更多的风险。

个人而言，很难区分敏捷实施教练和敏捷实施顾问，一般来说他们有能力完成以下各项：

观察、检验、询问并质疑你所正在进行的活动的想法
对选择何种实践和流程并对如何更好地实施它们提供建议
提供他们所见的成功或失败案例，以及其他团队是如何解决类似的问题

你可能需要和不同的顾问一起工作，因为很少有人可以了解所有的流程、实践、技术、产品及战略基准。对非常大的团队而言，有必要找一个全职顾问。尽管我所经历的大部分成功项目所采用的模式是“轻触型教导”结合之后章节所讲到的“引导”变更模式。

我并不认为你需要聘用一个全职顾问对敏捷模式进行教导但我建议把这项工作做成可持续性的。之前我曾实践过并写过有关“轻触型教导”，在这种模式下我间隔地回公司进行敏捷模式的教导，有时候可能每个月去一次或者更频繁，有时候少一些，但讨论一直持续着。

4) 别光说不练

请别光说不练，行动永远比空谈有效，你无法预见将发生的所有困难与问题直到你真正开始去做敏捷模式。你花在空谈如何去做却从不开始的时间越长，越可能建立起不切实际的期望，最终使之变成又一个管理层的噱头。

你可以无时无刻地谈论它，并为之做计划，但除了亲身投入进去并开始进行敏捷模式别无他法。边做边学习边改善，使用一些度量手段去了解正在发生的事情。切勿浪费大好时间去寻找成功案例，而应该自己去完成一个成功案例。

特别不要花时间困扰究竟是做极限编程（XP）还是 Scrum，精益（Lean）还是特性驱动开发（FDD），动态系统开发方式（DSDM）还是看板（Kanban）。这些几乎都大同小异，最终你不得不创建一种属于自己的混合模式。

5) 为每个人提供培训并进行小组讨论

团队并不会因为管理层认为“这就应该是敏捷”而变得敏捷起来，但很不幸，现实中这还是会发生。有些团队成员会阅读相关书籍，但大多数人不会，或者看后就忘记。

花点时间告诉人们什么是敏捷模式很值得 ——或者至少告诉他们敏捷模式对你们的组织意味着什么。现今大多数技术人员对“敏捷模式”都不陌生，但他们能记住多少，结果是好是坏却是天差地别的，团队必须开始形成共识。

但千万不要仅限于此，花点时间让人们说说敏捷模式对他们而言意味着什么，什么是他们喜欢的，什么是他们不喜欢的，什么是他们会做的，而什么是他们不会去做的。敏捷模式是一项团体项目，除非他们形成共识，不然他们只会各顾各地做。这项讨论必须始于培训初级阶段，以有助于团队形成自身特有的共同认识。

6) 要激励、要引导、不要生拉硬拽

任何一名在公司工作过几年的员工总能不幸地见证管理层自上而下地硬拽最新的变更方案：业务流程重组（BPR）、ISO 9000、Sig Sigma、CRM 等等。某些人拍脑瓜想到某些点子，然后开动变更机器将点子推行下去。

我们生活在一个后现代、后 BPR、后裁员、后萧条，后一切的世界里。别把员工当作小孩子，他们能洞察一切。最常见的是在管理层启动变更前，特别是有顾问参与的变更，已经与敏捷和精简背道而驰了。如果你想精简人员那就裁掉他们，启动敏捷模式吧。

就一条简单原则：要引导、不要生拉硬拽。

当有人说“变更管理”的时候，他已经不知不觉地在硬拽变更，所以请慎用“变更管理”这个词。

如果你身处管理层，那你需要营造一股合力来推动变更：一方面员工对于变更的热情自下而上，另一方面来自管理层的支持自上而下，一拍即合。笔者觉得自上而下地硬拽敏捷模式无异于失败，员工自然而然地会去质疑自上而下的强制变更。

相反，尝试去寻找一种方法激励每个员工和团队，让他们反过来向你建议采用敏捷模式，这远比强调变更自上而下要好得多。管理者必须首先培养并点燃人们的好奇心，然后等着人们主动来问问题并寻求帮助，最后创建出自下而上的变更方案并给予支持。

想办法点燃人们对于敏捷模式的好奇心，当他们来问的时候，给予帮助，并提供他们所需的东西：同意书本花费的支出，对讲师、培训师和教练提供预算，对会议说“是”。总之一句话，支持，全力地去支持！别置身事外，即使你都了解，你也需要去学习，当团队在形成共识时你需要在场。并且你也需要改变，学着改变你自身的行为去适应它。

7) 实施敏捷模式的动机

抛开你在敏捷体系中属于哪个阶层，工程师，测试，项目经理还是主管，问一问自己，你想要敏捷模式为你解决什么问题？搞清楚为何你想要改变并且明确你从中期望获得什么。

不要因为赶时髦而去实施敏捷模式，让敏捷模式帮你实现更重要的东西。去理解每个成员想要从敏捷模式中获得什么，以至于让他们的生活变得更美好。理解组织下想要从敏捷模式得到什么 ——是创新？是可靠的日程表？还是更少的 Bug 数？

问问你的团队，问问你的老板，问一问“你认为你的老板想要获得什么？”如果每个人都能从中受益，那每个人都愿意帮助实施敏捷模式。反过来，当人们看不到利益，变更将变得异常困难。

当你的敏捷模式进行实施的时候，你需要依靠这些问题的答案来选择你的工具，优化你的流程并衡量你的成败。

8) 流程与技术，兼而有之

千万别认为你只要改变下流程，所有情况都会变得好起来。你必须同时考虑技术层面，你必须改进质量，并支持你的工程师，测试人员以及其他进行编码实施工作的人。

我曾遇到过那些认为忽视技术层面的大公司：他们的态度似乎是“那只是技术”或者“他们将弄脏他们的手”或者“我们可以外包给低成本国家做”。如果你是这样的态度，那你必将失败。

“弄脏”你的手，跟工程师们谈话，实施测试驱动的开发模式，实施重构，避免大规模的前端设计架构，学着接受粗略设计和演化架构，这些才是真正的反馈循环。

9) 使需求更清晰、更干净

敏捷模式要解决的不仅仅是编程方面的问题，还包括需求分析的改进。特别是在有专职业务分析员的产品负责人或者产品经理，与开发团队之间保持通畅的途径。更深层次的谈判将首先发生在“什么”上，然后再是“何时”上。必须有人有与需求相关业务的授权，能够拍板儿。

太多公司没能对此引起足够重视，敏捷模式使需求理解更刻不容缓，需求上的瓶颈将对之后的开发产生连锁反应。

自己跟自己做个智力测试吧：如果敏捷模式将开发人员的生产率提高一倍将发生什么？答案是你将需要在需求分析上花两倍多的精力。首先你可能会干掉一个长长的 backlog，但你这样做之后，你的余额价值（Marginal value）也将减少。

10) 结构变更——功能组

以功能组的方式，将所负责工作不同的员工构建成不同的团队——例如：将数据库开发和用户界面开发分成独立的团队。这仅仅是你所要做的结构变更的第一步。但如果你在这里失败了，你就不可能再做一次了。

但带来的问题是团队之间请求特殊技能支持或所需的授权将受到影响，因为其他组有另外的优先级。尽量减少这些，因为这将会拖整个团队的后腿，影响团队士气，让你的敏捷实施更为困难。

就是这样

就这些了，其实这每一项都可以再写一篇文章去深入讨论，也许有一天我会那么做，但现有内容已足够改变现状。

如果说还有第十一项，那就是：忘记过去，改变无时不在，敏捷也不单纯只是添加剂。如果你不勇敢地停止一些你现在正在做的事情，你永远不会知道这样做的后果。但你完全可以等到你有了成功的资本后，再开始转变。

关于作者

**** 胜任过软件开发领域的似乎所有职位，从系统管理员到开发经理。如今他帮助团队实施敏捷模式并将其发挥到极致，他在如何与软件产品公司打交道及如何调整企业产品与流程使之符合公司长远战略上有着专长。他最新的著作《软件开发人员的业务模式（Business Patterns for Software Developers）》已由 Wiley 于今年年初发行。他的 Twitter 是 @allankellynet .