敏捷软件开发方法及其应用

引言

本文是敏捷软件开发方法及其应用的基础介绍。它关乎如何共同努力以实现共同目标。这不仅适用于软件开发人员，也适用于团队领导、项目经理、产品经理、开发经理、测试人员、QA经理、QA工程师、技术文档撰写人员、UX设计师，以及任何参与软件交付的人员。本文重点介绍技术团队如何齐心协力规划、构建和交付软件。它不讨论代码或具体技术，也不仅限于Microsoft工具。希望这能改善您的职业生涯和团队的效率。

专业行为的必要性：我们的行业是否知道如何行事？软件开发人员的定义：坐在房间里，花些时间，代码就出来了。我们对截止日期、日期、估算以及我们应该做的一切感到非常困惑，而且我们做得不好。现在这并不罕见。我们的行业还很年轻。

背景

温斯顿·罗伊斯的瀑布模型

“摘自1970年IEEE论文《大型软件系统开发管理》”

无论规模或复杂程度如何，所有计算机程序开发都包含两个基本步骤。首先是分析步骤，然后是编码步骤。然后我们引入了最重要的五个步骤

步骤1：程序设计优先

分配处理、功能，设计数据库，定义数据库处理，分配执行时间，定义与操作系统之间的接口和处理模式，描述输入和输出处理，并定义初步操作程序。编写一份易于理解、信息丰富且最新的概述文档。

步骤2：记录设计

管理软件开发的第一条规则是无情地执行文档要求。

步骤3：重复两次

成功的第二个最重要的标准取决于产品是否完全原创。如果所讨论的计算机程序是首次开发，请安排好，以便最终交付给客户进行操作部署的版本在关键设计/操作领域实际上是第二个版本。

步骤4：计划、控制和监控测试

这是在美元和进度方面风险最大的阶段。它发生在时间表的最后一点，此时备用选项最少，甚至没有。

步骤5：让客户参与

重要的是以正式的方式让客户参与进来，以便他在早期就已经做出承诺，并在最终交付之前。

仔细阅读Royce 的论文会发现：

• 每个阶段都应迭代地传递到下一个阶段
• 在发布前应执行整个过程两次
• Royce 知道单次通过会失败

不幸的是，对于所说明的过程，设计迭代从未局限于连续的步骤。

这一切都是什么意思？

答案是

敏捷开发本身并不是一种方法论。它是一个总称，描述了几种敏捷方法。在2001年签署《敏捷宣言》时，这些方法包括Scrum、XP、Crystal、FDD和DSDM。自那时以来，精益实践也已成为一种有价值的敏捷方法论，因此在后续的说明中也包括在敏捷开发的总称下。

• 欲了解更多，请阅读 Jeff Sutherland 的《敏捷原则与价值观》。

原始签署人

• 参考：agilemanifesto.org

敏捷软件开发宣言

• 参考：agilemanifesto.org

通过实践和帮助他人实践，我们正在发现更好的软件开发方式。通过这项工作，我们认识到

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

也就是说，尽管右侧各项有其价值，但我们更看重左侧各项。

《敏捷宣言》背后的十二项原则

• 参考：agilemanifesto.org

我们遵循这些原则

1. 我们最优先考虑的是通过早期和持续交付有价值的软件来满足客户。
2. 欢迎变化的需求，即使是在开发后期。敏捷流程利用变化来为客户带来竞争优势。
3. 频繁交付可工作的软件，周期从几周到几个月不等，倾向于较短的周期。
4. 在整个项目期间，业务人员和开发人员必须一同工作。
5. 围绕积极主动的个人建立项目。给他们所需的环境和支持，并信任他们能够完成工作。
6. 向开发团队以及团队内部传递信息最有效的方法是面对面交谈。
7. 可工作的软件是衡量进展的主要标志。
8. 敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够长期保持稳定的步伐。
9. 持续关注技术卓越和良好设计可以增强敏捷性。
10. 简洁——最大化未做工作量的艺术——至关重要。
11. 最佳的体系结构、需求和设计源于自组织的团队。
12. 团队定期反思如何提高效率，然后相应地调整其行为。

请点击这里了解更多关于敏捷宣言的详细信息。

许多开发人员都经历过一个没有指导实践的项目所带来的噩梦。缺乏有效的实践会导致不可预测性、重复性错误和浪费精力。客户因项目延期、预算超支和质量低下而感到失望。开发人员因长时间工作却交付质量更差的软件而感到沮丧。

DSDM

DSDM（动态软件开发方法）是为了弥补RAD方法的一些不足而开发的，它提供了一个考虑整个开发周期的框架。DSDM方法的主要特点如下：

1. 用户参与
2. 迭代和增量开发
3. 提高交付频率
4. 每个阶段都集成测试
5. 已交付产品的验收直接取决于是否满足需求

FDD

FDD是一种包装方法论，因为它允许您在非常高的层次上管理项目，同时仍然允许您在较低的层次上使用其他方法论。FDD的重点在于能够设置估算和进度，并报告项目整体或非常细粒度的状态，但它不规定用于创建进度的具体方法，由您自己决定。其理念是，您可以查看您的项目并确切地知道项目状态，无论是按时、延期、提前等。

精益

精益思维是一种系统优化方法，侧重于减少浪费和改善系统整体的价值流动。精益在制造业有着悠久的历史，近年来在软件开发领域日益普及。

精益源于精益制造，是一套实现质量、速度和客户一致性的原则。精益软件开发的七项原则是：

1. 消除浪费
2. 内建质量
3. 创造知识
4. 延迟承诺
5. 快速交付
6. 尊重人
7. 优化整体

将这些原则应用于软件产品交付工作并非最终目标。不能说“做精益”；而是使用精益原则来指导决策并选择能整体改进系统的技术。例如，TDD（测试驱动开发）通过在创建时进行检查来构建软件的完整性，从而支持精益原则在创建过程中构建完整性。

计划

在计划驱动开发中，如果项目按计划进行，则项目就是成功的，因此在软件开发中，这取决于需求稳定性，拥有清晰固定的需求。正如您可能知道的那样，大多数软件项目都无法享受到这种奢侈。

在计划驱动方法中，在设计阶段更改需求成本较低，而在施工开始后适应变化成本较高。因此，在规划阶段投入了大量精力。但软件开发是不同的。良好的设计并不能保证施工的可预测性。

“只要两者都冻结，在水上行走和根据规范开发软件就很容易。” - Edward V. Berard

敏捷方法是通过打破对需求稳定性的依赖，并提出一种考虑变化的流程来实现的。它通过使用适应性规划和进化设计来实现这一点。

适应性规划意味着多次经历项目周期，经常重新规划和重新适应。

通过像自助测试代码、持续集成、重构和简单设计等实践可以实现进化设计。

一个是以价值为导向（敏捷），另一个是以计划为导向（传统）。这并不是说计划驱动方法没有价值；而是说在敏捷中，我们明确它们并经常讨论它们。

敏捷和计划驱动方法都有依赖情况的缺点，如果处理不当，可能导致项目失败。挑战在于平衡这两种方法，以在特定情况下利用它们的优点，同时弥补它们的缺点。

计划 vs. 敏捷

计划驱动开发和敏捷驱动开发之间的根本区别在于两个显著差异。第一，在计划驱动模型中，团队将在项目结束时部署一个软件增量。但在敏捷中，团队将更频繁地部署非常小的软件变更。第二是顺序活动与并发活动。在计划驱动开发中，一个过程是在另一个过程成功完成后开始的。但在敏捷中，我们一直都在计划。

“计划你的工作，然后执行你的计划” - Martin Fowler 和 Neal Ford

• 两者都提供流程、工具和技术
• 两者都需要有纪律的软件开发方法
• 每个都有优点和缺点
• 敏捷方法解决了计划驱动方法不适合的许多情况
• 敏捷仍然是一种有纪律的软件开发方法，但侧重于流程的不同方面！
• 计划驱动强调正式沟通和控制
• 敏捷强调持续沟通和适应变化及不确定性的能力
• 高度迭代以通过大量关卡实现质量控制
• 在工作中检查，而不是在产品完成后检查
• 以满足需求为目标开始，而不是以预测将交付什么为开始

应对变化的能力

 

Visibility

• 通过快速、持续交付有价值的软件来满足客户。
• 重视人际互动而非流程和工具。
• 客户、开发人员和测试人员之间不断互动。
• 频繁交付可工作的软件（几周而不是几个月）。
• 面对面交流是最佳沟通方式。
• 业务人员和开发人员之间密切、日常的合作。
• 持续关注技术卓越和良好设计。
• 定期适应不断变化的环境。
• 即使是需求后期更改也受到欢迎。

与计划驱动方法配合良好的管理团队也倾向于与敏捷方法配合良好。

然而，与计划驱动方法配合不佳的管理团队可能缺乏敏捷所需的专注度。 

敏捷

敏捷软件开发的原则和价值观的形成是为了帮助团队打破流程膨胀的循环，并主要关注简单的技术来实现目标。那么目标是什么？目标是什么？

好的，每个软件开发人员和每个开发团队的主要目标是为雇主和客户提供最高价值。然而，我们的项目失败了，或者未能交付价值。

关键在于敏捷技术将传统软件开发方法——称为瀑布模型——的五个序列压缩到一个星期的周期。它通过反复的周期（迭代）和更小的部分（增量）来开发系统，使开发人员能够在开发过程中进行测试和审查。速度、成本降低和灵活性是关键优势。

Forrester 副总裁兼研究总监 Phil Murphy 在 2011 年的一份报告中说：“IT 部门的采用率正在加速。”

敏捷流程的参与者不怕变化。他们将需求的变化视为好事，因为这些变化意味着团队对如何满足客户的需求有了更多的了解。敏捷团队成员一起参与项目的各个方面。每个成员都有权对整体提出意见。没有哪个团队成员仅负责架构、需求或测试。团队共同承担这些责任，每个团队成员都对它们有影响力。

有许多敏捷流程：SCRUM、Crystal、行为驱动开发（BDD）、测试驱动开发（TDD）、功能驱动开发（FDD）、适应性软件开发（ADP）、极限编程（XP）等等……然而，绝大多数成功的敏捷团队都从所有这些流程中汲取经验，来调整他们自己特定的敏捷风格。这些调整似乎随着 SCRUM 和 XP 的结合而出现，其中 SCRUM 实践用于管理使用 XP 的多个团队。

极限编程（XP）

作为开发人员，我们需要记住，XP 并非唯一的选择。- Pete McBreen 

极限编程强调团队合作。包括经理、客户和开发人员。它在五个基本方面改进软件项目：沟通、简洁、反馈、尊重和勇气。

根据 Wiki 定义：“极限编程（XP）是一种旨在提高软件质量和响应客户需求变化能力的软件开发方法。作为一种敏捷软件开发，它提倡在短开发周期内频繁“发布”，旨在提高生产力并引入新的客户需求可以被采纳的检查点。”

极限编程是一套简单具体的实践，它们结合在一起形成一种敏捷开发流程。XP 是一种良好的通用软件开发方法。许多项目团队可以按原样采用它。许多其他人可以通过添加或修改实践来适应它。

• 大多数敏捷方法学的祖先
• Kent Beck 在 20 世纪 90 年代末和 21 世纪初引起了巨大的轰动
• 融合了流程和实践

Kent Beck 的基本思想

• 采用观察到的有效团队实践
• 将其推向极致

说“将其推向极致”是什么意思？这是否意味着类似下面的图片？

 还是

 

不，那不是 XP 的意思。让我们看看它意味着什么。

XP 是一套符合敏捷价值观和原则的实践。XP 是一种离散的方法，而敏捷是一种分类。有许多敏捷方法，XP 只是其中一种。

话虽如此，没有其他敏捷方法像 XP 那样定义清晰或范围广泛。例如，Scrum 大致相当于 XP 的规划游戏实践，并包含整体团队的元素。虽然细节上存在差异，但可以说 Scrum 是 XP 的一个子集。事实上，许多 Scrum 团队通过添加许多 XP 实践来增强他们的流程，例如验收测试、结对编程、持续集成，尤其是测试驱动开发。

在所有敏捷方法中，XP 是唯一一种为开发人员日常工作方式提供深入而深刻的纪律的方法。其中，测试驱动开发是最具革命性的。以下是一些好的 XP 实践。下次我会尝试详细介绍。

Scrum

Scrum 是一种迭代和增量的敏捷软件开发框架，用于管理软件项目和产品或应用程序开发。它侧重于“一种灵活的、整体的产品开发策略，开发团队作为一个单元来达成共同目标”，而不是“传统的、顺序的方法”。Scrum 问道，为什么做事情要花费这么长的时间和大量的精力？为什么我们如此不擅长估算事情需要多长时间和多少精力。Scrum 拥抱不确定性和创造力。因为人们就是这样工作的。它为学习过程提供了结构，使团队能够评估他们所创造的东西，以及同样重要的是，他们是如何创造它的。

• Scrum 最初于 1986 年由 Hirotaka Takeuchi 和 Ikujiro Nonaka 定义为“一种灵活的、整体的产品开发策略”。
• 1995 年，Sutherland 和 Schwaber 共同发表了一篇描述 Scrum 方法的论文。首次公开演讲。

Scrum 角色

以下是产生产品的核心角色：

1. 产品负责人
2. 开发团队
3. ScrumMaster
4. 利益相关者
5. 经理

产品负责人

• 产品负责人代表利益相关者，是客户的代言人。
• 负责确保为企业创造价值。
• 编写（或由团队编写）以客户为中心的条目（用户故事），对其进行优先级排序，并将其添加到产品待办事项列表中。
• Scrum 团队应该有一个，也可以是开发团队的一员。
• 不能与 ScrumMaster 的角色合并。

开发团队

 

• 负责在每个 Sprint 结束时交付潜在可发货的产品增量。
• 由 3-9 名具有跨职能技能的人员组成，他们从事实际工作（分析、设计、开发、测试、技术沟通、文档记录等）。
• 自组织，即使他们可能与项目管理组织（PMO）进行交互。

ScrumMaster

 

• 负责消除阻碍团队实现 Sprint 目标/可交付成果的障碍。
• 不是团队领导，而是作为团队和任何干扰因素之间的缓冲。
• 确保 Scrum 流程按预期使用。
• 规则的执行者。团队的保护者，使其专注于当前的任务。
• 也称为服务型领导者，以强化这两种观点。
• 与项目经理不同，后者可能有与 ScrumMaster 角色无关的人员管理职责。
• 不包含任何此类额外的个人职责。

待办事项

产品待办事项列表是为产品维护的“需求”的有序列表。它包括功能、错误修复、非功能性需求等——任何成功交付可工作软件系统所需的内容。在 Scrum 中，不需要在项目开始时进行冗长的、预先的努力来记录所有需求。这个敏捷产品待办事项列表几乎总是足够第一个 Sprint 使用。然后，随着对产品及其客户的了解增多，Scrum 产品待办事项列表会增长和变化。

Sprint 待办事项列表是开发团队在下一个 Sprint 中必须处理的工作列表。该列表是通过从产品待办事项列表的顶部选择故事/功能，直到开发团队认为他们有足够的工作来完成 Sprint 而得出的。这是由开发团队提出的“我们还能做这个吗？”并添加故事/功能到 Sprint 待办事项列表中完成的。

概念上，团队从优先级最高的 Scrum 待办事项列表顶部开始，并在他们认为可以完成的最高优先级项目下划一条线。在实践中，团队选择例如前五个项目，然后是列表下方与最初五个相关的两个项目是很常见的。

敏捷开发调查

该调查于 2012 年 8 月 9 日至 11 月 1 日进行。由 VersionOne 赞助，调查对象是来自软件开发社区各种渠道的 4,048 名个人。数据由独立的调查咨询公司 Analysis.Net Research 进行分析并整理成一份摘要报告。

谁了解敏捷？

敏捷失败的原因

进一步采用敏捷的障碍

采纳敏捷的最大担忧

结论

一个优秀的敏捷团队会选择最适合他们的管理和技术实践。在尝试采用敏捷实践时，会有大量的借口说明为什么它行不通。那些理解该方法真正好处的人——并且真正想实现转变的人——很可能会成功。那些寻找它为何会失败的原因的人——好吧，他们很可能会找到它们，并完全放弃这项努力，或者最终实践 Elisabeth Hendrickson 所说的“假敏捷”。

为了支持这一结论，我想引用一些话（收集自 Robert C. Martin）

“在准备战斗时，我总是发现计划毫无用处，但规划本身是不可或缺的。” - 艾森豪威尔将军

最好不要固定于任何特定的方法论，因为公司和项目的需求/条件很可能会定期变化，如果你想让项目成功，就需要灵活地管理项目。没有一种方法论是万能的银弹，所以诀窍在于确定哪些方法适合你，并调整你的方法论以适应你的个人需求。这正是“敏捷”的根本所在。

不是敏捷。重要的是要记住，Scrum 和敏捷方法论不是对公司流程的一次性审视，而是一种基于持续改进的 Ongoing 哲学。

参考文献

• 敏捷软件开发宣言
• C# 敏捷原则、模式和实践 Robert C. Martin, Micah Martin
• 敏捷联盟
• msdn.microsoft.com
• Martin Fowler
• pluralsight

历史

• 2013 年 12 月 5 日：更新了下一篇文章链接
• 2013 年 9 月 12 日：添加了内容
• 2013 年 7 月 25 日：添加了内容
• 2013 年 7 月 16 日：添加了内容
• 2013 年 7 月 6 日：添加了内容
• 2013 年 6 月 27 日：添加了内容
• 2013 年 6 月 24 日：添加了内容
• 2013 年 6 月 20 日：添加了计划驱动开发和计划 vs. 敏捷部分的内容
• 2013 年 6 月 17 日：添加了 DSDM、FDD 和 Lean
• 2013 年 6 月 16 日：添加了内容
• 2013 年 6 月 13 日：添加了内容
• 2013 年 6 月 12 日：添加了图像
• 2013 年 6 月 11 日：添加了内容和图像
• 2013 年 6 月 10 日：图像对齐和标签

下一篇文章

• 敏捷软件开发项目的需求、估算和规划