方法与策略

敏捷宣言的历史

几乎任何关于敏捷的书籍都会从敏捷宣言开始，本课程也是如此。宣言对敏捷的核心原则进行了精炼的总结。它于2001年在犹他州的一个周末由一群在软件开发创新方法方面有丰富经验的人共同起草。这些方法大多指向同一个方向：摆脱繁琐、流程导向的瀑布式开发模式。

尽管这群人观点各异，但宣言强调了他们方法中的共同价值观。每个人都亲身体验过新型协作方式，这些方式在实践中明显优于传统方法。

敏捷宣言的价值观

宣言包含四个有力的陈述，传达了新一代方法的共同价值观：

• 个体与互动胜过流程与工具。
• 可工作的软件胜过详尽的文档。
• 客户协作胜过合同谈判。
• 响应变化胜过遵循计划。

这并不意味着详尽的文档或合同谈判被禁止。它们仍然重要，只是优先级较低。

当然，在项目中遵循某种流程并无坏处。然而，机械地照搬任何方法或流程往往过于僵化。灵活的流程才是更优选择。

个体与互动

敏捷宣言特别强调团队以及人们如何协作来推动项目成功。敏捷方法提供了多种协作技术，尤其适用于项目中不同角色之间的协作。

什么是“方法”与“方法论”的区别？方法是对流程或程序的简要描述，不提供所有活动、角色和产出的具体定义。因此，方法具有广泛的适用性。例如Scrum、Kanban、极限编程（XP），甚至PRINCE都属于此类。Scrum通常自称为一种框架。使用方法或框架能赋予项目更大的自由度，但也可能让团队陷入困惑。

方法论同样描述流程或程序，但会明确给出活动、技术、角色和产出的具体指导原则与最佳实践。因此，方法论的适用范围较窄，但支持更充分。有时甚至支持过度。例如SDM或IBM的统一过程（RUP）。

敏捷项目的特征是不拘泥于某一特定方法或方法论，而是专注于持续改进工作方式。由于每个项目都不同，其工作方式也各不相同。尽管某些敏捷社区存在极端化的言论，规定哪些行为被允许、哪些被禁止——比如认为在Scrum中不允许建模，或在Kanban中必须始终使用在制品限制——但这种倾向并不可取。

这种极端主义在流行的敏捷方法中尤为明显。大量新认证人员涌入，导致真正理解精神的人越来越少。不幸的是，新手往往只按字面执行规则，而非领会其本质，从而形成教条式的应用。请记住：在敏捷中，人及其互动永远比流程和工具更重要！

可工作的软件

在传统项目中，人们主要产出的是纸质文档。事实上，分析师和设计师往往在代码和测试编写之前就已经离开项目。作为分析师或设计师，你甚至看不到自己辛勤工作的成果。而在敏捷中则完全不同。

在敏捷中，所有角色协同工作，包括分析师和设计师。这些角色通常被视为领域专家，而客户和用户也一同参与。不是前后相继，而是同步进行。这样每个人都能立即看到自己工作的成果。因此，团队需要找到最合适的文档方式。请记住：即使是敏捷团队也需要文档！

敏捷团队仅记录足够确定架构的内容，足够用于测试，并足以交付给维护团队。敏捷项目致力于寻找实现目标所需的最小文档集。明智的做法是让维护团队参与目标设定，因为他们同样是项目利益相关者。

协作与合同

在传统项目中，通常会在项目初期就确定范围、截止日期和预算。这种模式被称为固定价格。本质上意味着价格、范围和日期都是固定的。固定价格有助于明确客户与承包商之间的协议。公共招标常基于这一理念。这看似合理。但对于每个阶段仅执行一次的项目而言，每一阶段都需要完整且彻底完成。这实际上可能很难实现。

在敏捷中，范围并非事先完全确定。这为客户在项目过程中调整需求提供了空间，从而促进渐进式认知的深化。虽然这并不容易，但敏捷项目更注重建立客户与承包商之间的信任，而不是将一切固化。

应对变化

在传统的固定价格项目中，一旦出现意外情况，就会引发问题。常见的意外包括：

• 分析师无法按时交付需求。
• 在开发过程中发现新的关键需求。
• 在验收测试中暴露出需求或软件的重大错误。

随着项目推进，我们对变化的理解逐渐加深。

越晚获得这种渐进式认知，将其融入项目所需的努力就越大。传统做法通常是不立即实施变更，而是将其列入变更请求清单。项目结束后再决定是否采纳。这种方式实际上消除了渐进式认知的价值。弊端在于：项目最终交付的是最初约定的软件，而非真正需要的软件。

在敏捷中，渐进式认知是常态。这是日常工作的一部分。因为团队会逐步深入了解领域、需求、所用技术和协作方式。敏捷提供了机制，确保一旦出现新的认知，就能及时纳入项目。这是因为渐进式认知能提升产品和流程的质量。

细心观察会发现，敏捷项目的范围始终处于动态变化之中。这一点在瀑布式项目中也同样存在。平均而言，项目范围会增长20%到25%。区别在于：传统项目试图避免变更，而敏捷项目则主动欢迎变更。