十条敏捷开发失败之路
本文面向初学者以及那些质疑敏捷实施的敏捷怀疑论者。
本文提出了10条敏捷开发失败之路，旨在说明采用相反的做法可以提高敏捷性和成功几率。
1）缺少领导支持
管理层必须参与和投入。
在NASA，工程师知道密封圈有缺陷。显然，不管是他们，还是管理层，都不想看到灾难发生。让我们回归根本，敏捷宣言告诉我们，“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。”“必须”一词是经过慎重选择的。如果管理层最终代表业务，就意味着他们应该花时间到开发人员中间去工作，感觉就像公司里的一名工程师。参与和投入意味着在同一个战壕里——拿着项目自己的“O型圈”，了解工程师们正在谈论的内容。
在一家独立的软件公司，研发部门副总裁引入了一家敏捷顾问公司帮助组织转型。在最初培训期间，该副总裁表达了对Scrum概念的怀疑。她不想将自己的观点强加给团队，就花时间和工程团队呆在一起，观察他们如何工作。她第一次看到，测试人员和程序员如何一起实现每周的增量价值。“我不明白”，她告诉我们，“但每个人，包括客户，都很高兴，像这样，到了最后，与我无关了。”从那以后，她开始放弃她的命令式风格，这种风格在组织中非常普遍。
2）转型目的缺失或不明确
企业必须明确希望从敏捷得到什么。
“变得敏捷（Becoming agile）”是一项艰苦的工作。它需要不断地实践，打破旧习惯，采用新思维，这仅仅是其中的部分挑战。它意味着组织需要投入大量的精力调整文化。
如果你连正在努力解决的问题都不清楚，那么就需要更多的精力来保持动力。首先定义好你希望从敏捷得到什么，并不断地改进那些目标。还有，是的——每个人都那样做并不足以成为采用敏捷的理由。你必须眼睛盯着自己的问题，弄清楚为什么希望作出改变。
在大型企业中，最高管理层选择敏捷是为了缩短上市时间、改进质量、加强沟通以及更好地适应变化。但管理层并没有给这些目标指定一个优先级，TTM和质量相互矛盾，会妨碍沟通改善。由于变革目标不条理，一段时间之后，这四个目标就被人们完全遗忘了。
3）组织结构与角色和敏捷不相容
现有的团队结构必须不会妨碍“完工”。管理角色必须不会妨碍服务型领导/学习文化。
敏捷宣言告诉我们，“最好的架构、需求和设计出自于自组织的团队。”过分依赖其他团队的团队无法实现自组织——例如，如果开发团队依赖于测试团队来推动工作“完工”，那么该团队可能会表现出对他人无益的行为，如归咎文化或冷漠。
同样地，强力或高压领导很可能会导致对领导者的依赖，留给创新和创造力的空间很小。由于我们的行业依赖于创新和创造力，所以我们希望团队成为它们生长的沃土。团队角色和任务的多样性是关键。
根据你希望创造的价值建立组织结构，这样，人们就可以更独立地工作，减少对管理人员的依赖——反过来，管理人员可以帮助那些人提高。
一个大型的政府组织在他们的软件研发部门实施Scrum。软件QA、BI和DBA分属不同的部门。每当研发团队需要其他部门的支持，研发团队负责人就不得不接洽其他部门的负责人，请求他们腾出时间。研发团队的成员觉得，他们必须尊重其他非敏捷团队，这让他们觉得被推入了一种瀑布式文化。
4）破“构建”理论
不修复问题释放了允许质量糟糕的信号。
上世纪80年代的 破窗理论 指出，忽视像破坏公物这样的小罪会向人们释放更严重的犯罪也会被忽视的信号。后来，纽约市市长Rudy Giuliani采纳了这种方法，应对轻微犯罪。被破坏公物的人打碎的窗户会及时得到修复。警察接受训练，对付罪犯，帮助社区处理轻微犯罪行为，而不是忽视它们。结果难以置信。纽约市臭名昭著的危险区域成了最安全的区域之一。虽然有人批评这一研究不科学，但这种方法在其他城市也得到了成功应用。
类似地，对于软件组织而言，这几乎是不言而喻的：如果你忽视了有问题的构建，如Bug或者拼写错误，那么你就释放出了可以不编写单元测试、不重构，或者不按照需求开发的信号。标准就是这样形成的。
另一种选择？不要厌烦查找问题原因，确保问题得到修复。成为你希望达到的标准的榜样，并赞扬那些追随你的步伐的人。其他人也会这样做。
一个软件开发团队不断地抱怨其他团队的工作如何导致他们失败并偏离目标：“当他们改善了他们的工作，我们就可以开始着眼于自己的工作了。”有一天，Scrum管理员（SM）安装了Jenkins，并借了一块大屏幕展示构建状态。
第二天，构建变红了。SM和一名工程师开始调查原因，不到一个小时，他们就在另一个团队的代码中发现了Bug。不到三个小时，Bug就修复了，在安装Jenkins之前，这可能需要数周。
几周之后，SM开始试验JUnit。等那一完成，他试验了RESTful API自动化（此前仅仅是测试人员的职责）。逐步地，这个团队的成员不断打破界限，修复他们的破窗，增强他们的敬业精神。沮丧日益成为一种偶然，而不是一种心态。
5）严格把关的过程
传统方法妨碍了任务完成。
这一条要追溯到17世纪或者更早的时候。“ 我思故我在 ”是笛卡尔二元论的一个来源，该理论认为，精神和肉体是分离的；你要么想，要么做。19世纪末，科学管理之父Frederick Taylor将笛卡尔的观点解释为，思考和计划应该从体力劳动中分离出来。在软件开发中，这些观点告诉你，你要么考虑设计、编码和测试，要么就做——但不能同时。你应该计划如何以及何时做每一件事。这并不是真正的敏捷。
敏捷宣言指出，“敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度”——不是一个阶段接一个阶段，而是一直。
“僵化的关口（Rigid gates）”，如市场（MRR）、需求（BRR）、测试（TRR）等，支持项目不同层面的“完工”。这里，敏捷与传统存在冲突，有时候还很严重。
由于传统通常不容易改变，所以只能一次处理一个关口。通往敏捷失败的第一条路是缺少领导支持，因此，组织领导必须参与并投入消除无用的关口，一次一个。
政府组织已经使用包含需求、分析、实现、测试和GA关口的关口系统很长时间了。软件研发团队已经在他们的流程中实现了Scrum，并在每个冲刺中交付可以工作的软件。但团队仍然需要和测试冲刺同步，在通过公司约定的审批关口之前，不能正式发布。
6）培训不足
有时候，公司希望一次培训就让所有人都知道如何实施敏捷。
比如你希望完成一次马拉松。那需要能够跑完42.2公里。假如你不是一名正式的运动员。你是从零起步。经过一个为期三天的速成课程培训后，你能做好跑马拉松的准备吗？你怎么可能在那三天里学习到所有可能的问题和情况呢？
从非敏捷到敏捷参与者的情况类似。在为期两天的课程里变成一名专家的可能性几乎为零。你必须投入更多的精力和资源来提高敏捷性。
“我们只有一次机会，预算就那么多，因此，我们能做的事情并不多。”这句话描述了一场面向多个团队的初步培训会议的背景，这些团队正着手开始他们的Scrum之旅。管理层决定举办一场为期一天的会议来教授Scrum，由发起敏捷并了解Scrum的常务副总授课。先不说人们在理解Scrum的作用、仪式和人工制品方面存在差异，实际上，每个人都将Scrum视为另外一种项目管理技术，并不理解诸如自组织这样的概念以及迭代工作的实证方法。通过努力，只有两三个团队开始过渡到敏捷思维，但对于大多数团队而言，敏捷仍然只是微观管理的一种新方法。
7）“敏捷只为圣诞节”的实施方法
敏捷不仅仅是待办事项清单上的另一个项目。变得敏捷是一次旅行，不是一个一次性的项目，也不仅仅是另外一次实践学习。
相当直白地讲，对于许多组织而言，变得敏捷意味着改变运营系统。是的，“达成敏捷（being agile）”意味着采用新的运营方法，但更重要的变化是理念。许多组织的运营都遵循泰勒学派或笛卡尔的理念：管理层负责结果；其他员工负责执行。
让敏捷被接受需要自律和毅力。可能需要花费数年的时间才能达到组织可以号称自己敏捷的转折点——并不是说那时你就可以停止那样的工作方式。到那时，你们甚至不会再考虑其他的可选方案。你们已经调整了文化。
有家大型的国际化企业踏上了敏捷之旅。工作现场会有一名教练，帮助团队和管理人员应对他们每天的挑战，并根据他们的成长和兴趣逐步实行Scrum。在这个过程进行到大约两个月的时候，一些痛苦的问题开始浮现：例如程序员不想测试，座位安排妨碍了有效工作，团队责备其他团队。接着，预算用完了。留给公司的是残缺的Scrum和很多的失望。六个月之后，人们开始自己组织学习敏捷，这次没有现场支持，为了获得期望的结果，他们更加努力。
8）与兄弟部门目标不一致
所有参与的部门必须遵循同样的游戏规则。
在物理学中，当波形产生一个恒定的相位差时，波源就是相干的。当波源的频率或方向不同，或者两者都不一致时，它们不相干。在音乐方面，我们立即就可以知道我们听到的声音是否协调——可能只是听错了。
对于组织团队而言，亦是如此。
如果组织的一个部分关注交付速度，另一部分专注质量，即使他们步调一致，结果也不会一致。当相互依赖的团队努力的方向不一致时，结果就会不一致。
成功的团队会统一他们的时间表、目标和宗旨。
譬如，那不是说所有的团队都要统一他们的工作程序。只有当兄弟部门需要统一他们的价值、标准和成功定义时，才需要进行这种调整。如果那让你想起了领导支持，说明你逐步理解敏捷了！
两个从事同一款产品开发的部门已经在他们的工作流程中实现了Scrum。一个部门正在开发提供产品KPI的度量工具。他们关注度量质量。另一个部门正在增加新的产品特性。他们关注特性交付速度。两个部门互相依赖：提供KPI需要调用产品特性的API；没有KPI，新特性就没有“完工”。两个部门都对自己的敏捷实施以及敏捷对他们实现价值的助益感到满意。但也只有当两个部门在一两个冲刺中试验性地交换了专家，这两个部门才真的弥补了他们之间的差距，制定出了包含对方需求的“完工定义”。
9）缺少足够的适应性指标
使用虚荣指标会导致失败。
敏捷宣言的第七条“可工作的软件是首要的进度度量标准，”因此，不管你选择了什么指标，都应该能够度量工作如何对功能性产品有所贡献。
打开或关闭的缺陷数量、速度、速度趋势、“承诺-完工比（committed-versus-done ratio）”，诸如这些指标都可以度量贡献，但并不适应于一个可工作的产品。
The Organisation Within一书的作者的Larry Hirschhorn将这种指标称为“偶像”。它们或许可以代表实情，但基本上没有。
相反，客户满意度、员工幸福感或者媒体报道可能是更好的指标。
不过，按照Mark Twain的说法，指标和尿不湿一样，应该经常换。每个指标都可能失效，因为人们会根据你度量他们的方式行事。因此，不要试图寻找一个可以裁定所有人的指标。你度量的东西应该和产品及团队的成熟度有关，而且你应该尽可能经常地替换它。
一家大型企业利用一系列工具来帮助敏捷实施，并且自己在上层构建了一个报表工具。该工具已经逐步发展成为一个BI平台，可以随意处理各种数据：速度、连续运转效率、WIP随时间的变化（即CFD）、承诺准确性，等等。于是，一种新的文化形成了：临近每个季度末的时候，项目经理花费几天时间，进行周密地过滤，把最好的报表展示给利益相关者。不管车间里实际上发生了什么，只要报表看上去好看。
10）“将Scrum和敏捷等量齐观”的实施方法
当“技术性的”Scrum意味着“完工”的时候，这是成立的。
敏捷的范畴比Scrum要大得多。Scrum是最流行的开发周期框架，只处理一个方面：一个或多个团队接受一个需求积压列表，并用一个较短的反馈循环完成它们。Scrum本身并不涉及工程卓越、总体目标、扩展（ LeSS 使用Scrum优雅地处理了扩展）或者长期规划，等等。
优秀的Scrum管理员知道那些，并帮助他们的团队、产品经理和利益相关者实现多方面的改善。
就是说，优秀的Scrum管理员并没有真正的践行Scrum。他们是在Scrum环境里操作的敏捷实践者。
一个中型组织希望实施Scrum。一场组织分析澄清了这个过程：从改善工程实践入手，因为组织第一个可能遇到的问题会和代码有关。尽管出现了发布过程痛苦冗长、怪罪文化盛行等症状，但在接下来的多次会议中，组织领导者还是坚持继续推进Scrum。这段旅程使得团队成员之间的关系不断恶化，直到组织完全放弃了Scrum。
接下来做什么？
现在轮到你逆向分析这篇文章了。
这篇文章不是要让你放弃敏捷之旅。
相反，它是要让你坚持下去。
如果你发现自己陷入了这里提到的一个或多个反模式，那么问下自己，你可以做点什么来改变它。你可以做点什么不同的事情，以一种你可以操作的方式，变得更加敏捷呢？哪里是你忽略了的O型圈，什么反模式促成了它，如何摆脱它？
一家大型企业在他们其中一个研发部门实施了Scrum和看板。接下来，产品经理和团队之间的关系变得紧张，组织引入了一家外部供应商就团队工作协议组织召开一场研讨会。虽然预备会议表明团队层面存在一些挑战，但更大的挑战来自领导者。例如，虽然管理者相信敏捷，但他们没有为团队工作树立好榜样。
团队研讨会被一场管理团队组建会议所取代。研讨会的结果是一份待变革事项列表：正式确定部门的目的和价值；澄清管理团队成员的角色；定义并拥有标准，尤其是对于外部依赖，等等。通过设置自己的变革看板及承认运转问题，管理层开始消除导致敏捷失败的方式，并代之以渐进的步骤，为敏捷团队树立一个榜样。
文章来自： InfoQ