什么是敏捷？ 通过实践发展的哲学

最初是为软件开发团队设想的，敏捷现在是世界各地行业和公司的首要项目管理方法。 吸引力在于它的简单性和灵活性：敏捷的缺乏规范性实践使其高度可采用。 然而，在指导几家公司的敏捷转型时，我发现这种灵活性也会导致对敏捷意味着什么的误解。 许多公司优先考虑遵循敏捷衍生的框架，而不是理解哲学本身。

相反，组建和指导敏捷团队的项目经理和教练应该从培训他们采用敏捷思维开始，从本质上将哲学的核心价值观和原则内化。 只有这样，他们才应该根据最能满足项目需求的方式组合、定制或省略敏捷框架中的实践。

通过追溯敏捷的历史发展，并将其创始原则与公司和团队的具体需求联系起来，本文可以帮助项目经理为敏捷转型创造一个最佳的未来。 正如以下案例所示，敏捷不应被严格地视为一种项目管理方法，而是一种在实践中不断发展的产品开发理念。

敏捷的前因

2001 年首次编写的“敏捷软件开发宣言”是四个核心价值观和 12 条原则的简洁集合，是对包含规则和大量文档的线性、流程繁重的方法的激进回应。 但敏捷的历史起源于几十年前的一种简化工业制造的方法。

1930 年代，贝尔实验室的物理学家和统计学家 Walter Shewhart 开发了 Plan-Do-Study-Act 模型，它是专注于迭代改进的哲学的前身。 二战后，他的门生 W. Edwards Deming 将其用于培训丰田的管理人员。 该方法是丰田生产系统开发不可或缺的一部分，它是精益思维的主要来源，具有高效的构建-测量-学习循环。

在 1970 年代，当 Barry Boehm 提出宽带 Delphi 技术时，这一概念得到了进一步发展，该技术使用迭代过程来准确客观地估计开发软件所需的劳动力和时间。

随着 1980 年代中期个人电脑的普及，很明显，软件作为一种产品和服务将成为人们开展业务的方式的基石。 随着专业人士开始认真关注软件工程的增量、迭代方法，敏捷超越了瀑布流程，成为了卓越的开发和管理方法。

研究人员发现，与竞争对手相比，创新速度更快的制造商正在采用多学科、以团队为导向的方法来推动产品通过其生命周期。 这被广泛认为是 Jeff Sutherland 于 1993 年发明 Scrum 框架的灵感，这使他能够按时并在预算内完成表面上不可能的项目，并且错误最少。

理论上的敏捷价值观——源于这些先例——在我在实践中使用敏捷时得到了证实，强调迭代开发、协作团队合作和准确估计。

什么是理论上的敏捷？

随着公司继续采用敏捷的工作方式，他们冒着使其比哲学的制定者所预期的更具规范性的风险。 根据我的经验，希望采用敏捷的领导者过多地关注框架——或特定实践集及其相关术语——而不是价值观和原则。

正如在传授敏捷原则方面先进的从业者所熟知的那样，每个寻求进行敏捷转型的组织都必须找到并采用适合他们的方法。 我通过向团队展示如何遵循宣言的价值观和原则，然后从 Scrum、看板和极限编程 (XP) 等框架中汲取灵感，在实践中实施它们，从而促进了这一学习过程。

宣言的原则现在是敏捷项目经理的第二天性：

1. 个人和交互超过流程和工具
2. 综合文档之上的工作产品
3. 合同谈判中的客户协作
4. 响应变化而不是遵循计划

然而，宣言中遵循这些原则的警告经常被忽视：“也就是说，虽然右边的项目有价值，但我们更看重左边的项目。” 许多敏捷实践者最终会忽视右边的价值，只关注左边的价值。 结果？ 与盲目遵循流程繁重的框架相反：根本没有流程，这同样是有问题的。

在左右项目之间取得适当的平衡已成为我指导敏捷转型的关键。 Apple、Google、Amazon、Facebook 和 Netflix 的管理方法也体现了这一点，它们都没有订阅单一的敏捷框架。 他们首先体现了宣言的原则，同时根据最适合他们的方式遵循或更改不同框架的部分； 因此，他们已经适应了市场变化并能够快速交付新产品。

什么是实践中的敏捷？

在下面的概述中，我修改了宣言价值观的原始措辞。 对语义的更改有助于阐明我在实践中如何应用敏捷价值观。

在第一个值中，我将“个人”一词替换为“人”，因为敏捷意味着以团队为导向。 至于第二个，很明显软件必须“工作”，所以现在的重点是成功和及时的“交付”。 第三个价值就是“协作”，因为它同样适用于一起工作的同事和与客户一起工作的团队。 最后，“框架”取代了“遵循计划”，因为这防止了人们认为应该完全放弃计划的误解。

人胜于流程

敏捷转型很困难，主要是因为大多数企业都习惯于严格遵循流程。 使用特定的工具集完成一定数量的步骤，而不是开发创新产品，成为最终目标。

看到这种心态催生了一个有利可图的“敏捷行业”，我感到很沮丧。 正如敏捷创始人 Ward Cunningham 和 Jon Kern 解释的那样，许多企业销售他们声称将帮助公司“走向敏捷”的软件。 但是，敏捷意味着采用一种哲学，而不是使用软件并遵循它规定的程序。

实现正确的平衡不是要消除程序，而是要找到最能支持每个团队的开发目标的程序。 对于我的一个客户，一家大型企业技术组织，我实施了 Disciplined Agile，这是 IBM 开发的一种方法。 它结合了来自多个框架的许多实践，包括 Scrum 和看板。 它利用了迭代开发，但比传统敏捷更需要流程，尤其是在开始阶段，因为它旨在填补 Scrum 留下的空白。 纪律严明的敏捷为该客户工作，因为该组织非常注重流程。 它让我能够与团队进行中途会面，获得他们的支持，并说服他们采用 Scrum 工作流程。

我合并了待办事项细化会议、审查会议和每日例会，以促进团队内部和团队间的协作。 待办事项细化是 Scrum 指南的一部分，但细化会议不是。 我添加这些是为了让我们能够就我们计划在即将到来的 sprint 中实现特定功能的原因进行健康的对话，这对敏捷新手很有帮助。 我还选择了命名法“里程碑”——瀑布项目管理中使用的一个术语——因为它对客户来说更熟悉。 评审和每日 Scrum 交互是 Scrum 指南中的常规元素，但我在日程安排、持续时间和流程方面使它们更加结构化。

此外，虽然严格遵守 Scrum 会使每个人都完全致力于 Scrum 指南中列出的角色之一，但我客户团队中的某些人的技能组合并不能完全适应一个角色。 使用有纪律的敏捷方法，我可以将这些职位的职责分配给多个团队成员，并创建一个能够发挥所涉人员优势的流程。

软件交付优于文档

我更喜欢定制的 Scrum 或看板工作流程而不是严格遵守任何一个框架的另一个原因是，它们让我有机会将最小可行产品 (MVP) 作为目标添加到计划中。 源自精益，创建 MVP 的做法与迭代开发一致，并已成为敏捷从业者中流行的技术。 它允许团队有效地向用户交付高质量的软件和其他商品，然后根据反馈对其进行改进。 将其作为主要基于 Scrum 或看板的混合方法的一部分应用，增强了我的团队创建满足客户需求的产品的能力。

我目前正在与一家美国初创公司合作，并采用这种方法为 NFT 构建加密货币市场。 我们专注于创建 MVP，因此我们只编写目前所需的最少文档。 虽然这种方法对广泛的产品都有效，但它对加密货币和 NFT 尤其有用，它们属于一个新的、实验性的类别，并且正在迅速变化。 无需起草完整的规范和功能，也不必在发布前反复更改它们，我们可以花时间整合用户反馈来增强我们的市场开发。

合同合作

上述大型企业技术组织在许多固定成本项目中严重依赖合同。 合同概述了他们将用于完成工作的方法，以及负责每项任务的具体人员。 一旦签署，如果没有冗长的请求过程，就无法更改合同。

在我领导的转型中，合作优先于这些僵化的协议。 我们实施的计划用一页文件代替了合同。 每个人都表示，我们同意在指定的开始和结束日期之间使用敏捷与我们的客户以及来自不同团队的团队成员和同事进行协作。 合作产生的任何结果都会是结果。 我没有详细说明成品可能是什么。 因为我们要求客户反馈并将其纳入我们的产品开发中，所以从我们的计划文件中删除规范使我们更容易接受他们的回应，并激励他们更积极地与我们合作。

为了让管理层参与进来，我要求他们让我领导一个与一个小客户合作的小团队进行概念验证，该小客户甚至在任何必要的更改使问题复杂化之前就表示担心开发时间太长。 通过让该客户直接与我们的产品负责人合作，我们能够在开发过程中进行更改并显着缩短交付时间。

这些结果说服管理层让我将计划推广到更多团队。 总体而言，简化的合同和我们的敏捷工作流程减少了开发和将产品功能推向市场所需的时间。

对框架的适应性

我的另一个客户，一家健康科技公司，也未能在认识到敏捷价值双方的重要性方面取得平衡，即响应变化而不是遵循计划。 然而，在这种情况下，它犯了与我的企业技术客户所犯的错误相反的错误：它没有过于严格地遵循流程，而是过度关注灵活性，而在很大程度上忽视了流程。 工程师很少知道他们应该做什么，因为没有优先级或时间表。 他们每天都在试图弄清楚这一点，并在更重要的任务之前完成了不太重要的任务，从而浪费了时间和生产力。

我向 CEO 和 CTO 提议实施 Scrum，并解释说 sprint 将迫使工程师遵守纪律并以两周为增量进行计划，而不是决定每天做什么。 另外，我建议他们聘请产品负责人，这将解决团队缺乏产品责任的问题。 我要求高管们给我三到四个月的时间与他们的团队一起工作，然后他们才能期望看到结果。

在得到他们的认可后，我首先介绍了敏捷的价值观和原则，然后对团队进行了产品待办列表和安排它的不同技术的培训，包括制作史诗和用户故事，以及创建子任务。 我们在工作流程中包含的技术和会议与传统的 Scrum 不同，因为它们没有出现在 Scrum 指南中。 我将它们整合到计划中，因为史诗、故事和子任务在培训期间与团队产生了共鸣，并且会议促进了富有成效的讨论。

我还包括了速度的概念，它是 XP 的一个后期补充，用于测量每个产品迭代中所有用户故事的总努力估计。 然而，我使用了“能力”这个词，我更喜欢这个词，因为它强调团队成员可以完成多少工作，而不是他们完成任务的速度。

为了估算，我从 T 恤尺码开始，这是一种衡量项目和任务大小的技术； 随着团队的进展，我转向了故事点，这是一种更传统的估计技术。 故事点经常被不熟悉敏捷的团队滥用，他们试图将它们转换为工作时间或天数，过度关注时间框架，并根据他们在截止日期前的能力来判断人们。

T 恤尺码更加抽象，让团队更容易避免这个陷阱。 但是，它也不太精确。 因此，一旦团队了解了如何进行相对估计，我就将它们转换为更复杂的技术。

当团队完成两个冲刺时，高级管理人员能够看到他们的员工更高效地工作和更有效地沟通。 开发人员第一次与利益相关者和执行管理层接触。 他们会见了客户支持团队，并了解他们实施的功能如何改善用户的生活。

这种方法很快提高了公司软件的质量，并将新功能的交付时间从几个月缩短到几周。

敏捷的未来是什么？

COVID-19 大流行创造了一个新的现实，即团队不再可以在同一地点办公，这是在敏捷构思时首选的工作方式。 然而，它必须保持这种方式的想法是一个神话：随着远程工作变得司空见惯，很明显，使用视频会议软件完全可以实现密切通信。 我现在合作的团队是完全分布式的，我正在远程提供培训。 一些团队甚至选择异步工作，使用 Notion 和 Loom 等工具，以及 Standuply 等 Slack 插件。

分布式协作模型是新的工作世界，其核心是敏捷性。 为远程团队提供的工作与生活平衡对士气和心理健康有积极影响，从而提高生产力和质量； 它将人员置于流程之上，灵活且适应性强，使其成为典型的敏捷。

敏捷教练、Scrum 大师和项目经理应该回到哲学的根源，并像宣言的制定者那样呈现它：一套灵活且动态的开发和交付指南。 他们应该教导高管和团队领导者，虽然他们可以从项目管理中获得灵感，但他们并没有真正管理敏捷中的任何事情——他们是在指导团队并让他们自由地去做最好的工作。