迭代瀑布不是敏捷

作者：Mike Cohn (已获授权翻译）

原文：https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile?from=groupmessage

        在过去两年里，我注意到一种很让我纠结的状况。这种状况在我咨询过的全球各地的团队中都存在。这是一种创造迭代式的瀑布流程然后称之为敏捷的趋势。

        迭代式的瀑布看起来是这样：在一个迭代中，某人（也许是一位和PO一起工作的业务分析师）弄清需要做什么。因为他们想要敏捷，所以他们使用了用户故事。但是他们不是把用户故事当作一个简短的记录来用于将来的交流，相反每一个用户故事都变成了迷你规格说明书，也许有三到五页。而我还看到过更长的。

        这些迷你规格书/用户故事记录了这个用户故事的几乎所有可能的细节。

        因为这样的文档需要占用一整个迭代来澄清和文档化，所以第二个迭代用来设计这个故事的UI。有时团队会尝试在迷你文档完全写完之前就启动设计工作，来让自己更加敏捷（自认为的）一些。

        团队的另一些人会认为这么做很危险，因为规格说明书还没有完全写完。但是，管他呢，在这不就是敏捷的用武之地吗。

        然后，一堆文档就给到了程序员。其中之一会说明这个故事实现完后是什么样子的，其他的文档提供了故事行为的全部细节。

        只要这两种文档没有准备好就不可能开始编码工作。在某些公司，程序员要求按照这样的方式工作。他们抱着一种你让我做什么我就做什么的态度，但是你需要在迭代一开始就要告诉他们切切实实的需求。

        一些组织会进一步扩展，他们让测试跟在编码后的一个迭代。之所以发生这样这样的状况是因为在编码之前需要包含一个迷你规格说明书和一份完整的UI设计队的用户故事变得越来越大。

        幸运的是，大多数团队意识到程序猿和测试媛需要在同一个迭代内共同工作，但是还没有扩展到作为一个完整团队共同工作。这导致了下面的工作模式。

图片发自App

        这张图显示了第一个迭代被用于分析。第二个迭代（也许和第一个迭代稍有重叠）被用来进行用户体验设计。然后第三个迭代被用来编码和测试

        这不是敏捷。这可能是你的组织迈向敏捷的第一步。但它不是敏捷。

        我们在这个图中看到的是迭代式瀑布。

        在传统的完整的瀑布开发模式下，团队首先会完成整个项目的所有分析工作。然后他们再进行所有的设计工作。然后他们进行全部的编码工作。然后他们进行全部的测试工作。

        在上面示意图中的迭代式瀑布中，团队在做一模一样的事情，只不过他们把每一个用户故事当成了一个小项目。他们完成一个故事的分析然后开始这个故事的设计然后进行这个故事的编码和测试工作。这就是迭代瀑布开发过程，而不是敏捷过程。

        理想状况下，在真正的敏捷过程中，所有类型的工作应该在几乎相同的时间完成。团队会在完成问题分析的同时完成设计工作。而与之同时团队会完成编码和测试工作。所有这四类工作（包括没有包含在这个例子中的其他类型的工作）都会在同样的时间完成。

        虽然假设团队总能这么做看起来有点天真（有时候是能达到的），但是它可以作为一个团队为之奋斗的目标。

        团队应该尽可能的重叠工作。前期思考（分析、设计和其他类似工作）应该尽可能晚得完成，并以保证工作在迭代内完成的前提下尽可能少得提供细节。

        如果你正在把用户故事当作迷你规格文档，请停止。请开始考虑把每一个用户故事当作一个对话交谈的承诺。

        你可以往故事中随意添加一些想在交谈中提出的内容。但是增加这些注释应该是一个可选步骤，而不是工作流程中的必选步骤。

        将这样的步骤作为可选项可以避免把工作流程变成迭代式瀑布，并且保持过程敏捷。

Mike Cohn

翻译：Jeri Shi