在敏捷项目中协作

瀑布模型中的协作

除了在短周期内工作之外，敏捷开发与瀑布模型的另一项关键区别在于不同角色之间如何协作。

在瀑布模型中，角色与阶段一一对应。分析师提供需求，设计师完成功能和系统设计，开发者将设计转化为代码，测试人员验证代码是否满足需求。当应用开发完成后，交付给维护团队。由于每个阶段仅执行一次，最终产出被称为一个里程碑，因此各角色的工作是按顺序进行的。各阶段之间的过渡发生在前一阶段的成果交付给下一阶段负责人时。

一家大型国际银行曾请我们指导一个项目的开发阶段。第一天，我们收到厚厚一叠文件。“拿去吧，”经理严肃地说，“这就是功能设计。”在他看来，这已经涵盖了全部内容——团队应该清楚需要构建什么。然而，当我们艰难地读完七百页文档后，依然一头雾水。我们的第一反应是去找这份文档的作者——设计师们。但很遗憾，这并不可能：一位设计师正在银行另一个办公室的其他项目上工作；另一位已辞职，现在为竞争对手效力。

通常情况下，这种模式看似实际且易于管理。在任何阶段，只存在一个活跃的角色。它也显得成本较低：因为在某一阶段，其他角色无需参与，他们已完成工作并转投下一个项目。然而，这种模式也存在一些弊端。

在每个阶段中，角色会积累大量关于项目、客户领域以及项目实施组织的知识。尽管这些知识在阶段结束时尽可能被记录下来，但无法完全通过文字传递。每当一个阶段结束，部分知识便留在了离开项目人员的脑海中。

敏捷流程中的协作

敏捷方法中的协作方式截然不同。无论采用何种方法或框架，敏捷项目都强调团队中不同角色之间的紧密协作。不是依次进行，而是共同推进。这种方式能立即带来附加价值。

聚焦

团队中所有角色都集中于同一小部分待实现的工作项，这些工作项将在一个迭代周期内完成。这种聚焦使团队运作高效。

反馈

团队对有限数量工作项的协同工作，确保来自各个角色的反馈能在几天内得到处理。而在瀑布项目中，这一过程往往需要数月。

多角度视角

团队中每个角色对工作项的看法各不相同。分析师对用户故事或智能用例的理解，与开发者完全不同。测试人员则关注异常情况和验收标准。这样，同一工作项能够同时从多个角度被审视。

交接

不会出现“甩锅式”交接——即文档交付后就不再参与。不同角色会同步协作处理同一工作项。