敏捷不仅仅是小瀑布吗？

Question

我在我的项目中主要使用了瀑布方法，但现在我正在将我的视野扩展到敏捷方法。从我目前所读到的，也许我读错了东西，敏捷意味着小瀑布。而不是一个大瀑布散布在一到两年，你有小瀑布，持续几个星期，也许最多几个月。

我的理解是正确的还是有更多的？敏捷哲学是什么？

Answer 1

简单地说，是的。简单地说是每两周执行一次瀑布并不能使你变得敏捷。，但是它是迭代的(这是敏捷的一半)。

瀑布模型定义了阶段--需求、架构、设计、实现、验证(测试)、验证(验收测试)和发布。在任何迭代方法中，您都会在每个迭代过程中经历这些阶段。它们之间可能存在重叠，但您可以引出和捕获需求，采用系统的体系结构和设计来允许实现，开发新特性或修复缺陷，测试新模块，然后将其提交给客户进行验收测试和部署。

然而，敏捷不仅仅是迭代和增量的。敏捷的租户在敏捷软件开发宣言中被捕获。“宣言”提出了四个要点：

过程和工具上的个人和交互

你经常涉及到个别的人。许多实现都是围绕自组织和自指导团队进行的。几乎所有的人都与客户或拥有客户声音的人进行频繁的互动。与其使用一套正式的过程和工具，不如让项目的工作人员来驱动如何完成项目，从而让项目以最好的方式完成。

基于综合文档的工作软件

在软件项目中，主要目标是交付软件。然而，在一些项目中，浪费的文件生产没有增加任何价值。斯科特·安布勒在敏捷/精益文档上写了一篇很好的文章。这不是不生成文档，而是选择能为您的团队、未来开发人员、客户或用户增加价值的文档。您的软件工程师不是生产不增加价值的文档，而是生产软件和相关的测试。

合同谈判中的客户协作

它不是预先定义条款、时间表和成本，而是与客户进行持续的努力。例如，您可以以用户故事的形式捕获您的需求，并为它们分配点数。经过几次迭代之后，您确定了一个速度(点/迭代)，并可以确定您的团队可以在一个迭代中实现多少特性。当您的客户提供关于哪些功能增加了最大价值的反馈时，他们可以决定项目何时完成。通过频繁的交付和客户交互，任何事情都可能发生--这些需求已经得到满足，项目最终进入了维护阶段，最终结束了生命，客户发现他们并不需要他们认为的所有东西，所以决定结束项目，项目失败了，客户看到了这一点，可以提前取消it...the列表。

响应按计划进行的变更

您没有一个大的设计或最终的计划预先，并必须执行返工时，该设计或计划必须改变。您将根据您所拥有的信息不断地估计和修改估计值。您可以仔细选择度量标准，以便深入了解项目的健康状况以及何时进行内部更改。您经常与客户一起添加、删除和重新确定需求的优先级。最终，你会明白变化是唯一不变的。

敏捷意味着专注于人，通过快速交付高质量、增值的软件来满足他们的需求。随着客户需求的变化，您需要适应这些需求，将重点放在增值上。敏捷方法有一些具体的实现，但它们都以人员为中心，及时交付工作软件，并适应快速变化的环境。

Answer 2

是和不是--实际的过程可以被看作是一系列的小瀑布，但区别在于，在回顾过程中，整个团队(开发、qa、业务等)的投入会对过程进行进化和改进，这将导致一个更紧密的单元，能够对问题做出反应，并能够准确地计划和交付。我完全不想在这里简化它，还有很多，但我不认为这是一个糟糕的起点。

Answer 3

我想说，这是一种简单化的说法。是的，当你深入到它，它是小的水流，但有更多的背后，使它工作。整个方法改变了你对待项目的方式..。更不用说它所需要的心态了。

如果您是认真对待敏捷的，下面是您可能感兴趣的一系列很好(而且很长)的网络广播：

http://autumnofagile.net/