成功实施敏捷之十荐

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

　　曾有人报道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等等。某些人拍脑瓜想到某些点子，然后开动变更机器将点子推行下去。

原文转自：http://www.ltesting.net