3种样式：迭代，增量和进化敏捷（第1部分）

当我教培训课程时（就像我本周在Skills Matter上一样 ）或在软件开发的需求方面为客户提供建议（我现在正在做很多事情）时，我谈论的模型是“ 3种敏捷风格” ”。 令人难以置信的是，尽管该模型多年来隐藏在几篇文章中，但我从来没有写过博客。

所以现在已经到了……我不认为“ 3种样式”应该是应该的样子，我只是声称这是我找到世界的方法。

尽管软件开发在代码方面的“敏捷”总是回到相同的方面（独立会议，测试/行为驱动的开发，代码审查/对编程，故事，开发板等），但需求方面却非常变量。 所提供的建议是非常可变的，并且该建议与公司结构和工作的兼容程度是可变的。

但是，我发现需求方进行操作并与开发交互的三种重复出现的样式。 我将这些样式称为“迭代”，“增量”和“渐进式”，通常会绘制此图：

我说风格是因为我在寻找中性的词。 我认为您可以使用这三种样式中的任何一种来使用Scrum，XP和看板（或任何其他方法）。 就是说，我相信看板更适合于进化，而Scrum / XP更适合于迭代和增量。

我尽量不要凭空判断，我知道很多敏捷人士会认为Evolutionary是卓越的，他们甚至可能认为Evolutionary是唯一的True Agile，但实际上我并不总是这样。 有时其他样式是“正确的”。

让我描述三种样式：

迭代式

开发团队采用这种风格来做很多事情，例如：站起来的会议，计划会议，短期迭代或看板流程，测试驱动的开发，代码审查，重构，持续集成等等。 我说他们正在做，最好说“我希望他们正在做”，因为常常会遗漏一些东西。 那对于这个模型并不重要。 关键是开发团队正在这样做！

在此模型中，需求以质量形式到达需求文档中。 实际上，组织的其余部分好像没有任何变化一样进行下去，确实这可能是组织想要的。 在此模型中，您会听到人们说“敏捷是一种交付机制”和“敏捷是针对开发人员的”之类的事情。

需求文档甚至可能是由已经消失的顾问或分析师撰写的。 该文档被“扔在篱笆上”交给另一位分析师或项目经理，他们希望在一定的固定时间内以一定的预算交付所有内容（范围，功能）。 在项目结束时（团队可能解散时），交付很可能是一个“大爆炸”。

为此，他们使用培根切片机。 我之前写过这篇文章，并将其称为Salami Agile 。 存在需求文档，“产品负责人”的工作是将小块切成薄片，以便团队进行每次迭代。

开发团队与组织的其余部分保持隔离。 可能仍然有一个变更审核委员会，任何增加的范围都被视为一个问题。

我之所以称其为“迭代”，是因为团队正在迭代，仅此而已。 这是大型公司，具有年度预算的公司，不了解IT知识的高级管理人员（尤其是银行）的自然风格。

增加的

这种样式与Iterative大致相同，一开始看起来很相似。 团队仍然（希望）做得很好并且不断迭代。 仍然有大量的需求文档，组织仍然希望所有文档都已交付，并且仍在切香​​肠。

但是，在这种模型中，团队正在向客户交付软件。 至少是为了演示软件并倾听反馈。 他们更有可能正在部署软件，并且（潜在）用户可以立即开始使用它。

结果，客户/用户就他们想要的软件给出了反馈。 有时，这是额外的功能和特性（范围爬行！），有时是关于删除请求的内容（范围撤退！）。 按照传统意义上的“项目”仍是完成的，文档中的所有内容都是“完成”的，但是现在有些事情已经删除，而不是打勾。 另外，除了需求文档之外，还可能需要执行其他一些操作。

我之所以称其为增量，是因为客户/用户/利益相关者看到的事情正在以增量的方式增长-并希望早日实现价值。

我实际上认为这是软件开发的最常见样式–无论该工作称为敏捷，瀑布式还是其他形式。 但是，在某些环境中，这被视为是错误的，错误的，因为前期要求是“错误的”，或者是因为需要进行多次交付，或者是因为团队没有交付最初要求交付的一切。

进化的

在这里，开发团队再次像以前一样进行迭代。 但是，这一次没有需求文档。 工作只是从一个想法开始的。 理想情况下，我希望看到一个目标，一个目标，一个目标，该目标将指导工作并帮助告知应该执行的操作–并且该目标应以单句话（最多为一个段落）陈述。 但有时甚至会丢失，无论好坏。

在此模型中，需求专家和开发人员都从一开始就开始。 他们集思广益，并选择要做的事情。 当Requires先生开始与客户和利益相关者讨论问题是什么以及需要什么时，技术团队（也许只有一个人）就开始了迄今为止最好的想法。

很快（两周高位）他们回到了一起。 Requirements先生谈论他所发现的东西，然后开发人员展示他们所建造的东西。 他们谈论更多，然后决定下一步要做什么。

完成此任务后，开发人员继续进行构建，Requirements先生再次骑上自行车，他展示了已构建的结构并与人们进行了交谈-一些人又是一些新人。 团队尽快开始将软件推向用户和客户使用。 这带来了价值并提供了反馈。

顺其自然。 当目标达成后，组织就决定在其他地方使用其资源。

帕洛阿尔托（Palo Alto），山景城（Mountain View）和其他任何新兴企业都采用了进化风格。 实际上，进化论比公认的普遍得多，但它被称为维护或“错误修复”，被视为不应该存在的东西。

设定了三种样式后，我将讨论如何使用模型以及为什么将每种样式用于另一个条目。 如果您想了解每种模型的更多信息以及如何看待敏捷频谱，请查看我的ACCU Overload的 2011年“敏捷频谱”或最近修订（扩展但未完成）的版本，标题为“敏捷频谱”（我想是2013版 ，仅在线）。

参考： 3种样式：来自JCG合作伙伴 Allan Kelly的“迭代式，增量式和进化式敏捷”（第1部分） ，位于“ 敏捷，精益，模式”博客中。

翻译自: https://www.javacodegeeks.com/2013/09/3-styles-iterative-incremental-and-evolutionary-agile-part-1.html