敏捷和其他开发方法

引言

敏捷方法已经发展到可以快速适应开发过程中的变化。这种方法与传统的计划驱动方法相反。敏捷方法的主要重点是通过协作技术、代码重构、测试驱动开发和客户参与，及时响应规范的变化，从而尽早发布可工作的软件。

正如《敏捷宣言》所 stated (http://www.agilemanifesto.org)

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

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

敏捷方法遵循这些原则 (http://agilemanifesto.org/principles.html)

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

每种敏捷方法都试图遵循这些基本原则，以克服在任何软件和项目开发期间及之后发生的常见问题。每种敏捷方法都基于上述原则定义自己的一套实践。这些方法演进的目的是更好地为客户服务，并使开发过程更简单。在本文中，我们将讨论敏捷方法，并将其与更传统的开发方法进行比较。

背景

一般来说，我们遵循两种软件开发方法

• 传统的、计划驱动的方法（瀑布、螺旋、迭代等），以及
• 未定义的方法（我们将其视为没有正式流程）。

以下各节将讨论在软件项目开发期间及之后遇到的一些最常见问题。

客户频繁变更

在传统的开发模型中，我们首先根据与客户的讨论收集并冻结需求，然后进行开发和测试，最后将版本发送给客户。然而，在大多数情况下，我们发现当软件交付时，客户的期望已经发生了变化，因此我们努力将期望与批准的需求进行匹配，然后试图说服客户放弃所有超出范围的功能。有时我们能够说服他们将额外功能包含在下一个开发阶段，有时我们则会进行更改以使客户满意。

在某些情况下，我们收到客户频繁的小额变更，几乎不可能应用经典的流程，因此我们会在交付后进行临时性的变更。渐渐地，这会造成混乱的局面，项目最终会变得几乎难以管理。

对资源的依赖

由于不同的团队负责开发的不同阶段，因此对各自资源有更多依赖。

文档编写耗时

我们经常发现文档编写耗费大量时间。对于短期项目或截止日期很紧的项目，创建和更新文档非常困难。

影响分析非常复杂

我们总是强调创建必须包含所有重要信息的文档，当所有相关内容都包含在内时，文档就会变得非常庞大。因此，尽管我们创建了所有必需的文档，但在进行影响分析时，它变成了一项繁琐的工作。

所有这些问题都促使我们考虑其他可能的替代方案。

与其他现有方法的比较

	瀑布	螺旋	迭代语句	敏捷
已定义流程	必需	必需	必需	仅计划和收尾
最终产品	计划期间确定	计划期间确定	项目期间设定	项目期间设定
项目成本	计划期间确定	部分可变	项目期间设定	项目期间设定
项目完成日期	计划期间确定	部分可变	项目期间设定	项目期间设定
对环境的响应能力	仅计划	主要为计划	在每次迭代结束时	贯穿始终
团队灵活性、创造力	有限，按部就班的方法	有限，按部就班的方法	有限，按部就班的方法	迭代期间无限
知识转移	项目前培训	项目前培训	项目前培训	项目期间的团队合作
成功概率	低功耗	中低	媒体	高

（来源：Ken Schwaber 的 SCRUM 开发过程）

敏捷方法的局限性

对分布式环境的支持有限

面对面沟通是敏捷过程的一个基本特征。敏捷过程提倡的集中办公不适合某些行业向全球分布式软件开发环境发展的趋势。团队成员和客户在物理上分离的开发环境可能无法适应敏捷过程所提倡的面对面沟通。在这种情况下，可以使用视频会议等技术来模拟面对面沟通，但这些技术有时价格昂贵，并且不如预期有效。

我的评论：Martin Fowler，一位著名的软件架构作者和国际演讲者，专注于面向对象分析和设计、UML、模式和敏捷软件开发方法（包括极限编程），他已经考虑了这个问题，并在本文中分享了他的经验：https://martinfowler.com.cn/articles/agileOffshore.html。我们所需要做的就是定制并创造性地使用现有的敏捷实践来弥补。

对构建可重用资源的支持有限

反对敏捷过程的一个论点是，它们针对软件中的特定问题，而对生产通用解决方案则不足。

我的评论：构建可重用资源是一个非常有争议的话题。开发出真正可重用的东西非常困难。仅仅声明某物可重用是不够的。在我参与的项目中，我曾多次遇到所谓的“可重用资源”，并且需要进行大幅修改，以至于按照我自己的需求创建新资源会更容易。

对开发安全关键软件的支持有限

据说敏捷质量控制机制（如结对编程、非正式评审、代码重构等）不足以向用户保证最终产品的安全性。

我的评论：我使用过 TDD、结对编程、非正式评审和代码重构，并在最终产品中取得了巨大的成功。我想再次强调，我们可以根据需要自由定制或修改现有流程。

对涉及大型团队的开发支持有限

这是敏捷过程一个众所周知的局限性。人们认为敏捷过程更适合小型集中团队。

我的评论：这只不过是一个假设。我见过许多人在大型项目和大型、分布式团队中成功地使用过敏捷方法。

我们现在做什么？我们需要它吗？

正如最初讨论的，目前大多数组织遵循计划驱动的方法，或者什么都不遵循。通常，对于大型项目，我们会遵循流程，但我们都理解这项工作的局限性。有时我们会有小型项目，或者项目有频繁的小型变更，因此我们会不自觉地搁置流程，以期及时交付成果并让客户满意。

一个显而易见的问题随之而来：使用敏捷方法会解决这些问题吗？

我的回答是：我不能说。我不确定。

那么，这次讨论的意义何在？?

首先，这次讨论的目的不是为你提供一个对所有项目都有效的解决方案。而是让你了解现有的替代方案。我们不需要对所有项目使用相同的方法。相反，在考虑每个项目的性质时，我们必须从现有列表中选择一种方法。

此外，通过基于经验研究和比较不同的开发方法，我们还可以遵循一些混合实践。以下是一些敏捷过程的最佳实践：

• 单元测试和测试驱动开发可确保 bugs 和错误能够快速、早期地发现，从而更容易修复。
• 现场客户和功能测试可确保系统分析和规范是最新的，并符合业务需求。
• 结对编程允许两名开发人员在一台计算机上协同工作，这增加了发现 bug 的机会，并带来更简单的设计。
• “一次且仅一次”的代码重构可提高设计一致性，使结构更简单、更灵活。这可确保系统设计良好且易于更改。
• 定期发布可向客户提供反馈，并迫使团队尽可能廉价地完成“发布到生产环境”和维护阶段。
• 每日小型状态会议可确保进度按计划进行。
• 使用 UML 图有助于解决困难的文档和任何设计变更的繁琐影响分析。

我们应该始终可以根据每个项目的性质来定制开发方法。可以将 SCRUM 和 XP 的实践以及其他敏捷方法混合使用，然而，快速采用定制的敏捷方法并不总是那么简单。事实上，这需要良好的创造力、深入的分析和开放的心态。

采纳敏捷方法的挑战

尽管敏捷方法如今备受追捧，但在许多组织中采纳起来并非易事。思想保守或封闭、不易适应和学习新方法的人是任何地方的一大挑战。在某些情况下，专注于单一技能的人可能会带来问题。敏捷方法需要每个人的参与，因此拥有多项专业技能的团队成员可能更容易采纳敏捷方法。一些组织遵循特定的方法集，不愿意改变。其他组织可能仅仅害怕改变。

有时我觉得拥有过时技能的人也会带来问题，同样，那些喜欢为项目的每个部分创建详细文档的人也会带来问题。由于设计文档可以通过 UML 设计方法来处理，而敏捷方法侧重于代码开发而不是创建 UML 设计，因此大部分文档可以减少，喜欢长篇文档的个人或组织对此并不喜欢。

最重要的问题可能是试图一次性、 abrupt 地采纳敏捷实践。最后，我们也应该记住，办公室政治也可能在采纳和使用敏捷方法中发挥重要作用。总之，以下是采纳敏捷方法的挑战：

• 害怕改变
• 专业技能
• 过时技能
• 重视文档的思维模式
• 一次性完成一切的态度
• 串行思维
• 思想封闭
• 办公室政治
• 非黑即白的思维模式

结论

如果您对组织目前使用的开发方法没有遇到任何问题，或者对此感到满意，那么就没有必要改用敏捷方法。最终目标是满足客户的期望和满意度。使用敏捷方法的目的应该是快速响应变化，即使在开发后期，并在交付任何软件或项目时都能获得完全满意。