敏捷方法论的优缺点

20 世纪 90 年代末，软件开发公司的工作人员开始认识到“一切照旧”对他们来说并不有效。传统的商业模式需要冗长的计划、僵化的结构和官僚主义的障碍，这些都阻碍了创造力，并使适应不断变化的情况或应对不可预测性变得几乎不可能。因此，软件开发人员开始将旧的理念与新的理念相结合，直到他们找到一个适合他们特定情况的解决方案。

这种灵活的方法对他们来说非常成功，以至于他们决定创造一种方法来帮助其他人受益于一个基于协作和灵活性的过程。这些思想的传播是自发的，导致了人们可以在他们的项目中使用各种不同的框架。2001 年，正是这种缺乏一致性导致 17 人在犹他州雪鸟镇聚集，以发现他们的方法之间的共同点。

人们发现，只有少数几件事情是所有人都能达成一致的，这些最终演变成了《敏捷软件开发宣言》及其 12 条原则，这些原则由敏捷联盟起草，用于“指导有助于团队流畅实施和运行的实践”。

什么是敏捷模型？

敏捷是一个宽泛的术语，用于描述《敏捷宣言》中所述的最佳实践。它是一套准则和原则，强调灵活性、协作以及自组织团队。它认识到并非所有情况都适用相同的策略，并且快速响应变化和不确定性的能力也可能有所不同。正如敏捷联盟所说，敏捷的本质是应对生活不确定性的一种方法。

• 坦然面对未知。
• 找到一个你可以合作并进行测试的解决方案。
• 获取反馈。
• 根据需要进行调整。

敏捷方法论是团队愿意遵守的、用于特定项目或情境的惯例、实践、方法和准则的框架。这些实践可能因团队和项目而异。然而，所有团队都将遵循敏捷原则和价值观。

不同的敏捷方法论类型

这些框架成为团队扩展、采纳相同原则然后根据自身需求进行调整的基础。目前，无论是在软件开发领域内外，都有许多广泛使用的敏捷方法。

1. 敏捷 Scrum 方法论

Scrum 是最基本和最广泛使用的敏捷方法论之一。《数字项目经理》杂志指出，Scrum 方法论的主要目的是“提高协作、团队合作以及开发速度”。Scrum与其说是一种项目管理方法，不如说是一种维护和创建项目的工具。

与其他敏捷方法论类似，Scrum 在设计时就考虑了软件开发。当涉及到适应其他行业时，会进行调整，特别是对于有固定预算和时间表限制的项目。由于这些挑战以及 Scrum 方法论被用于软件开发之外的领域，项目经理通常会利用该框架内的特定概念，并以适合他们需求的方式实施这些概念，例如自组织的小型团队、定期的站会和项目评审。

2. 精益

在《数字项目经理》的精益部分，精益方法的主要目标是效率。与不同的敏捷方法论相比，精益方法管理方法是一套既定的规则，而不是需要遵循的流程。它从确定每种情况下的增值之处开始，并不断努力突出积极因素，同时消除任何消极因素。

这种方法可以应用于项目管理，通过审视团队管理项目的流程，然后将其精简为最重要的方面。根据《精益之道》，精益的三项原则最初是在日本开发的。它们是：Muda（无駄，浪费）、Mura（斑、不均衡）和 Muri（無理，过度负荷）。这三项原则通常被称为“3M”。

• Muda：消除浪费。任何不为客户带来价值的东西都应被移除。
• Mura：减少变化。标准化流程并消除过度变化。
• Muri：减少过度负荷。超出 60%-70% 的容量增加实际上会减慢工作速度。

3. eXtreme Programming (极限编程)

这种软件开发方法与 Scrum 有许多相似之处，特别是对沟通的强调。它与 Scrum 的不同之处在于，它有关于设计和测试代码的一套规范性规则。由于其特定的原则，极限编程方法很难应用于其他类型的项目管理。以下是一些适用于软件开发的规则，它们强制执行以下内容：

用户故事是小型功能的描述，应包含在内。

• TDD（测试驱动开发）——在软件开发之前，将软件需求转换为测试用例。
• 结对编程——这是一种两个程序员在一个工作站工作的技术。
• 持续集成——代码定期上传并在整个项目中进行测试，以便及早发现潜在问题。

4. Kanban (看板)

看板与 Scrum 和精益方法相似。这种项目管理方法强调效率（如同精益）和协作（如同 Scrum）。看板的方法不那么僵化，这使得它更具灵活性，并能更快地获得可交付成果。看板方法论的目标是以更好的质量更快地交付工作。以下是看板的核心原则：

• 可视化工作流程。
• 限制在制品数量。
• 衡量前置时间。
• 明确流程策略。
• 持续评估改进机会。

与瀑布模型对比

瀑布模型是一种传统的项目管理方法，比敏捷方法更常见，是现代工作场所目前最流行的项目管理方法。据 Workfront 称，瀑布模型是一种自顶向下的方法，可确保在下一阶段开始之前完成项目的每个阶段。它的名字来源于自顶向下的方法。

这种方法在有实际最终产品（如建筑）时最为有效。瀑布模型的成功取决于项目开始前进行了多少研究。这种计划有助于更好地进行项目估算，例如项目需要何种资源，并更容易预测项目需要多长时间。

瀑布模型可以在某些情况下使用，但它也有僵化之处，使其难以适应变化和不确定性。这就是为什么敏捷方法论和其他灵活的方法如此吸引人的原因。它们允许团队轻松调整方向并改变路线。

敏捷方法论的优点

1. 敏捷联盟定义的《敏捷原则》12 条是敏捷方法论如此吸引人的原因。
2. 它们将客户满意度放在首位。因此，它们定期向客户交付有价值的软件。客户满意度和高质量的可交付成果是它们的主要关注点。
3. 欢迎需求变更，即使在开发后期。敏捷过程利用变化来增加竞争性客户优势。与其抗拒变化，不如学会拥抱它。
4. 频繁交付可工作的软件。这可能从几周到几个月不等。它们偏好较短的时间框架。在项目过程中持续提供结果，而不仅仅是在项目结束时。
5. 项目期间，开发人员和业务人员必须每天协作。协作至关重要。
6. 创建由有动力的人驱动的项目。给他们所需的 and 支持 and 环境，并相信他们能完成工作。不要妨碍他们，聘请勤奋、有才华的团队成员。
7. 面对面交流是与开发团队交流信息的最佳方式。尽可能减少沟通不畅。
8. 软件是衡量进展的最重要指标。它不必完美；它只需要有效。
9. 敏捷流程促进可持续发展。用户、开发人员和赞助商应该能够长期保持稳定。慢而稳者胜。
10. 良好的设计和卓越的技术是敏捷的关键。关注细节。
11. 简洁至关重要。它是最大限度地减少未完成工作的艺术。去除冗余。
12. 自组织团队能够产生最佳的架构、需求和设计。与第五条原则相关，如果团队能够确定自己的角色，你将获得团队的最佳工作成果。
13. 团队定期回顾如何提高其有效性非常重要。然后，它会根据反馈调整其行为。接收反馈并根据需要进行调整。

敏捷方法论的缺点

1. 敏捷与所有项目管理方法论一样，并不完美。如果使用不当，敏捷固有的优势可能会对团队造成损害。《Inc.》杂志列出了一些敏捷方法论的最大缺点。
2. 可预测性较低。敏捷的灵活性意味着可预测性较低。准确预测项目持续时间或量化所需工作量和资源可能很困难。这种不确定性是团队常见的恐惧，会导致沮丧和糟糕的决策。
3. 需要更多的承诺和时间。尽管协作和沟通很好，但持续的互动需要所有相关人员投入更多精力和时间。
4. 客户和开发人员的期望更高。有效的敏捷方法论要求每个人都投入。任何不配合的人都可能对项目质量产生负面影响。
5. 文档不足。由于敏捷方法，任务通常会很快完成，因此文档可能不够详细，这可能导致日后出现误解和问题。
6. 项目很容易偏离轨道。敏捷方法论的结构不如传统方法，因此项目很容易丢失或超出其原始范围。

结论

敏捷方法是软件开发及其他领域中一种流行的项目管理方法。由于其灵活性和对变化的适应性，它是 21 世纪理想的项目管理方法。尽管它有其局限性，但敏捷方法论是管理项目的有力工具。

如果由愿意遵守其原则的团队正确使用，敏捷方法论可以带来许多好处。COVID-19 大流行凸显了在不确定性面前适应能力的重要性。而且未来似乎越来越不确定。尽管敏捷方法论并非适合所有项目和情况，但它可以选择性地应用于任何项目，以使团队保持敏捷并为不可预见的事件做好准备。