敏捷迭代就是小瀑布吗？为什么创业团队更敏捷？_敏捷是瀑布的微型

作者：盐析白兔 | 2024-07-09 00:41:30

踩

敏捷是瀑布的微型

我的答案是：No. 敏捷迭代不是小瀑布。为什么呢？

简单的答案就是管理机制不同，瀑布在研发的每个阶段都是不同的团队来完成的，而敏捷团队会自己完成从需求分析到交付的所有任务。

瀑布开发模式是怎么组织软件开发管理工作的？

一个典型的瀑布开发模式会把软件开发工作分成5个阶段：

在这里插入图片描述

每个阶段由一个独立的团队或者专家来完成。比如需求分析由 BA (Business Analyst) 来完成。BA完成需求分析以后会提交详细的需求分析文档。架构师团队会根据需求分析文档来做详细设计。开发团队根据详细设计文档完成开发工作。在开发工作完成以后。测试团队开始测试工作，测试工作可能包括功能测试、集成测试、性能测试等。测试完成以后交给交付团队完成打包发布工作。

每一个阶段都会有一个评审会，在完成评审以后才能进入下一阶段的工作。这些工作往往是跨部门的，因此沟通成本比团队内直接沟通成本高。这种跨部门合作的另一个问题是很难保证每个团队工作都是饱满的，因为团队之间工作有依赖性，一个团队需要另一个团队任务完成以后才能开始工作。一个典型的情况是测试团队需要等待开发完成以后才能开始测试工作，而当测试团队开始测试以后，开发团队的任务就是等着修 Bug。

这种跨团队的合作方式决定了瀑布开发模式的产品研发周期必然很长，时间范围往往以月为单位。使用这种方式不可能做到以周为单位的迭代周期。

只有能为自己的决策负责的团队才能做到敏捷

要做到以周为单位的迭代周期，不是说就不需要上面提到的5个开发阶段，而是这5个开发阶段都需要在一个规模可控的团队里完成。最佳实践证明比较理想的敏捷团队由3-9个人组成，很多研发经理认为理想的团队由7个人组成。为了沟通的高效，敏捷实践推荐团队成员坐在一起，最好能面对面的沟通。

和瀑布模式不同的是敏捷团队在团队内完成5个开发阶段的所有工作，这就意味着团队自己做从需求分析、详细设计直到产品是否能交付的决策和执行。为了避免团队成员因为等待其他人的任务成果而浪费时间，团队成员需要一专多能，积极主动地去承担任务，为每次交付尽力做出自己的贡献。
在这里插入图片描述
上图是使用 Scrum 框架的敏捷团队在一个迭代（Sprint）里的工作流程。在迭代开始时做计划 (Sprint Planning)，在迭代结束时跟客户一起总结成果获取反馈 (Sprint Review)，最后在团队内部开反思会（Retrospective）总结经验教训期待改进。在整个迭代周期每天开站会根据迭代计划跟踪进展。团队每周做一次用户的修剪（User Story Grooming），为迭代计划打好基础。所有会议都是全体成员一起参加一起决策。整个会议时间大约占到工作时间的10%左右，也就是团队90%的时间都在开发工作上。

实际上随着敏捷开发的演进，一个新的概念被提了出来，这就是DevOps。它把整个软件开发分成了交付和反馈两个主要阶段。交付阶段包含了构建、测试和发版，而反馈阶段包含了监控和计划。DevOps的目标就是提高软件的交付速度，从而达到提高研发效能的目的。
在这里插入图片描述
要做到这一点团队需要充分地自治，这样成员才会因为自己能够说了算，为自己的决策负责，有自驱力去完成交付任务，达到自己设定的各种目标。

为什么创业团队往往更敏捷？

创业团队一般规模更小，一个搞软件开发的创业公司开发团队90%会在10人以下。由于人手有限因此“分工”往往不是很明确，一个人得当好几个人用。前端、后端、开发、测试、打包交付运维都得自己负责。这点和敏捷开发的团队管理方式是非常相似的，所以看到创业团队更敏捷、产出效率更高不足为奇。

创业团队还有一个特点是那种按阶段分工合作开发模式的大规模团队不具备的，那就是对软件研发各阶段决策和执行的自治。创业团队大部分研发问题可以自己解决，也必须自己解决，这大幅提高了决策效率，降低了沟通成本。

2006年亚马逊 CTO Werner 提出的"You build it. You run it."的口号就是要让亚马逊的开发团队组织地跟创业团队一样，高度自治，贴近客户，自己负责。

结论

敏捷迭代不是周期缩短的小瀑布。瀑布模式在软件的各个阶段都由不同的团队来完成的，而敏捷开发要求一个较小团队完成从需求分析到交付的所有工作。敏捷团队是一个高度自治的团队。

参考资料

关注公众号更方便

查找公众号: agileddd 关注我。

本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】