会让敏捷失败的六种情况

关键启示

• 敏捷需要自适应架构。如果没有正式的设计过程，代码会堆叠在旧的代码之上，最终得到一个不灵活的设计结果。
• 工具被创造时，软件和业务敏捷度并非完全相同，这两种敏捷需要单个工具来满足所有用户的需要。
• “孤狼”开发者的时代已经过去，证据表明，更多样化的团队通过协作能够产出更好的成果，协作已然成为成功关键的因素。
• 将大规模敏捷项目扩大涉及团队间的和更多的跨职能间的协作和可见性
• 因为当今的项目可能一开始时并没有明确固定的需求，所以项目经理必须计划设立一条持续的规划和反馈循环。

数字转型要求 IT 组织成为提供差异化​​客户体验的业务推动者，从而获得投资回报。为了跟上创新步伐、立即取得成果，许多 IT 团队采用敏捷开发方法，其发布间隔以天为单位，而不是季度，从而使质量得以保证。

这样的目标可能是软件开发界的圣杯，但它并非总是可行。从理论上讲，敏捷开发具有所有正确的要素，但它并不适合所有项目。让我们考虑一下它在最佳情况下是什么样子。

敏捷开发能加速初始业务价值的交付，并采用持续的规划和反馈流程。由于采用了这种迭代规划和反馈循环，团队不仅能将交付的软件与所需的业务需求保持一致，而且能轻松适应整个流程中不断变化的需求。状态的测量和评估基于利益相关者对于项目所有阶段实际进展情况的准确了解。由于遵循了敏捷流程，在项目结束时，软件系统更好地满足了业务和客户需求。

一切听起来都很合乎逻辑且合理，但敏捷项目的现实往往会有所不同。敏捷方法并不总是能获得预期的结果。

以下是敏捷项目失败的六种常见情况。

1. 不可持续的系统架构：《敏捷宣言》指出，“良好的设计和卓越的技术能提高敏捷”，并且人们一直在推动“适应性架构”。保持敏捷的诀窍在于提前做好足够的设计。但问题在于如何知道什么样的设计能被称为足够的设计。如果设计过程变更太少，且没有正式的设计过程，代码堆叠在旧代码之上，最终得到的会是一个不够灵活的设计。敏捷架构与传统的瀑布架构不同，瀑布架构中的系统架构在前期即被准确定义，开发是一次性活动，具有明确开始和结束日期。敏捷的软件架构则是一个持续的过程，它使开发人员能够持续地在必要时对架构进行更改。设计在 sprint 计划会议期间可能是连贯的，但它可能缺乏可以赋予其长期可持续性的正式架构模型。

2. 现有工具的局限性：敏捷方法常受到现有工具的限制。当今的企业应用程序生命周期管理（ALM）市场由整体式和企业内置的解决方案主导，由于这些方案是根据“瀑布”交付方式设计的，它们缺乏敏捷交付的关键要素。虽然软件开发行业已经在采用最佳的敏捷工具（如 Jenkins、VersionOne 和 RallyDev），但这些工具并非针对企业 IT 组织的需求而设计。相反，它们设计的目的是被专业软件工程师使用，而不是业务用户。这些用户不愿意、不能、亦不应该被要求参加培训课程，以学习如何进行功能测试并提供反馈。另外，由于这些系统包含太多功能，而且这些功能拥有过高且不必要的硬件和计算要求，所以购买和维护它们也可能很昂贵。

3. 文化鸿沟：一些习惯了独立工作的开发人员可能会发现敏捷开发所需的所有协作均会减慢自己的速度。对许多人来说，如果习惯了大量的自由，他们就会反对改变工作方式以适应高度协作的方法。那些创造力强又聪明的人通常只希望你给他们想要的工具，然后让他们干自己最擅长的事。尽管最终，敏捷项目团队的每个人都需要变得更加灵活。据 Gartner 的《 2016 年度应用测试服务魔力象限》估计，到 2020 年，60％的测试人员将需要测试、应用开发、业务流程或行业技能的组合而不是某个单一的技能。考虑到当今项目发生变化的程度，“孤狼”开发人员单独坐在某处，不与别人交流的做法已经毫无意义，因为协作已然成为成功的一个关键因素。很多证据表明，更多样化的团队可以取得更好的成果，所以个人开发者是否应该“顺应潮流”并学习一些社交技能呢？

4. 难以扩大规模：敏捷是一种传统意义上受到中小型企业欢迎的方法，但最近在大型企业中它也已变得更加主流。小项目对于敏捷开发较为理想，因为大项目需要更多的协调。将敏捷应用于大项目遇到的一个特殊问题就是如何处理团队间的协调。大规模敏捷涉及与其它组织单位（如人力资源、营销、销售以及产品管理）间的沟通。因为敏捷方法很大程度上依赖于紧密的工作关系和大量的用户反馈，随着项目的增长，通信流也会呈指数倍增。另外，随着企业拓展到新的地域，或与其他组织合并，项目也会因此分散在不同地点的多个团队中。如果在不同的地点和协作工具之间没有一致的方法，人员不能看到分布在多个开发和测试团队中的测试周期的实时状态，那么可能会导致瓶颈，进而导致项目延迟和成本超支。

5. 项目类型不对：传统方法（如瀑布）对于范围两端的项目最有效，即：1）已经建立了明确和固定要求的项目，或者 2）之前没有可以提供有效反馈的用户群的新技术或方法。尽管事实上，长期的项目越来越不普遍。当今的业务环境具有 VUCA 性（不稳定性、不确定性、复杂性和模糊性），这意味着一个为期 12 个月的项目中 60% 以上的需求将会发生变化，所以几乎不存在一个“固定”的项目终点。当今的业务系统中已经没有“明确和固定的需求”这一说了。技术变化非常迅速，客户需求非常紧急，法律变化非常频繁。“只有看到了，我才知道要什么”（即 IKIWISI - 摘自 1986 年《快速应用开发》）才是用户需求的真正写照。项目经理必须评估项目，来判断少量开发人员独立工作的做法是否是介于 1 和 2 之间的项目是更合适和更具性价比的解决方案。与矩阵管理结构中的多个不同用户组进行对接的项目或许不适用敏捷方法。例如，使用金字塔结构时，通常一起工作的团队数量大于项目实际需要的数量。当这些团队成员被部分分配给项目时，问题变得更糟，因为投入度较低。

6. 因为协作问题陷入僵局：为了从敏捷方法中获得最大收益，软件开发团队成员需要每天看到、感觉到和听到用户身上发生的情况。但现在大多数项目的现实是，不同的团队成员距离较远，或者无法面对面沟通。依靠手动的电子邮件通信可能会减慢通信速度，并且容易出错。根据我自己在企业组织方面的经验，超过 50％的组织正在使用 Microsoft Office 产品，如 Word 或 Excel，有的组织甚至是通过纸和笔来管理应用交付的某一方面，比如测试。当来自不同地点、不同地域的团队开始使用通信工具来获取所有不同类型的信息并加快信息流动时，他们常常会得到过程的优化和最终结果的改进，从而使团队更强大、更高效。当一个测试组落后，或涉及用户验收测试的业务用户因休假而忘了运行程序时，工具可有效防止流程卡住。项目内部人员和与客户之间的沟通和协调常常由于物流、位置和时间安排变得很困难，所以建立方便敏捷团队协作的端到端通信框架对于帮助人们更有效地合作至关重要。

当敏捷开发有效的时候，组织能够发布高质量、迅速变更的软件，推动企业向前发展。但它并非任何时候都有效。要想成功，需要协作、透明度和实时了解项目风险和质量。

尝试用户故事映射、思维导图和用户故事切分技术能够更好地将大型复杂的解决方案拆分为更小、更独立的部分，从而快速进行实施并更快地获得用户反馈。你肯定希望看到更远的未来，想知道当下你需要做什么来创造价值，并在将来交付这些价值。

所以请保持交流的通畅，并将所有反馈的消息自动化，包括测试结果、变更单和重新测试，以便使一切流畅进行。同时请承认该方法论的局限性，如果你的专家坚持独立工作，而且矩阵管理过于臃肿使得所有的反馈线路难以管理，请不要羞于承认敏捷的局限性，回到瀑布方法吧，虽然它有些过时，但它毕竟是经过验证的方法论。

最终，我们正在构建的是客户可以使用而且喜欢的产品。根据客户的反馈频繁添加新功能能使他们更满意。对于软件客户来说，有什么比投资一个毫无用处的产品，它不能满足我的需求，而且我看不到一条能让它变得更好的出路更糟糕的事情？ 如果我知道某个首次迭代的产品会随着时间的推移变得更好，我肯定会购买它。事实上，当采用敏捷方法时，随着开发团队不断改进产品，客户看着产品不断改进是很快乐的事情。敏捷帮助我们与客户建立这种伙伴关系，使我们能够与他们一起努力解决问题。

尽管敏捷开发方法有其复杂性，但如果具备正确的条件和工具，IT 团队绝对可以实施敏捷开发方法、推动业务发展、并巩固持久和忠实的客户关系。

作者简介

Ronit Eliav是 Panaya 的产品营销总监，她的邮箱是 Reliav@panaya.com。Ronit 是 IT 数字化转型主题（如敏捷、持续交付、DevOps 和业务流程优化）方面经验丰富的思想领袖，她还是 IT 现代化、动员和系统集成等项目的项目负责人。此外，她还是 Panaya 公司产品组合营销方面的论题专家和端到端负责人，负责产品战略、分析一直到推向市场。

查看英文原文： Six Ways Agile Can Turn Static

感谢罗远航对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。