移动端菜单栏icon
研发管理

瀑布与敏捷的区别


瀑布模式

上世纪70年代,温斯顿·罗伊斯(Winston Royce)借鉴传统工业生产的预设性方法提出了一种软件开发模式:将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六项基本活动;

规定了它们自上而下、相互衔接的固定次序,项目必须严格遵循预先计划的顺序进行,开发进程只有通过上一个阶段的验收审核,才能“流动”到下一个阶段

这种模式如同瀑布流水,逐级下落,故而得名“瀑布模式(Waterfall Model)”。

00 Why Agile 为什么敏捷.png

较之瀑布模式,敏捷是“适应性的”,而非“预设性的”,主要体现在

1、敏捷欢迎变化,接受客观存在的未知和不确定,将软件开发视为适应变化的过程。

敏捷开发团队采取高频迭代的方式,不再将项目划分为只能线性推进的若干阶段,而是基于整体目标将项目分解为多个尺寸较小的“小项目”,每部分能够在远比瀑布模式短得多的周期内,快速而独立地走完计划、设计、构建、测试、发布的过程。

这样一方面可持续为终端用户交付有增量感的产品,另一方面也可避免瀑布模式难以“回头”的窘境。随着产品由简入繁,之前不够清晰明确的需求会不断清晰明确,而未知的需求也会逐渐显现出来。

2、敏捷不再像瀑布模式那样“黑箱”操作,让用户等着见到一个“全部完成”的产品之后,才能判断是否符合预期。

敏捷从最重要、最明确、能够开发完成并达到使用标准的少量需求开始迭代,尽早把可用的产品交给用户,让用户加入产品开发过程,和开发团队一道确定每个迭代最主要的任务,并根据产品使用的实际体验给予反馈。

如此,敏捷能将需求错位的风险降到很低,同时又能让产品在正确的方向上不断完善。

3、敏捷更强调团队协作,而非固化的各司其职。

在传统的软件开发项目中,项目团队的每位成员被视为资源,分配给特定的角色和工作,开发过程没到自己负责的环节时不需要介入。这样容易造成开发人员各自对项目需求有不同的理解却得不到有效和充分的沟通,由此产生的问题在开发后期阶段才能被发现。

而敏捷则是建立一个技能重叠、持续互动、信息高度共享的项目团队,这样既使每位开发者在任一时间都有任务,无须等待前置环节而闲置人力,又能让这个团队对产品需求和开发进度的理解保持一致,避免信息不对称所带来的隐患。

4、敏捷是“以人为本”的,更注重开发者在产品开发中的重要性,而非依靠流程来保证产品开发的质量和效率。

敏捷认为“自组织”是提升团队成员彼此间的信任和自适应能力的有效途径。“自组织”形成的开发团队可以自己决定如何完成工作,并伴随开发过程在实践中不断反思、优化,探索最适合团队、最能发挥成员特点和自主性的工作方式。

也就是说,敏捷开发团队本身就是迭代内容的一部分,只有使团队自身不断适配外部变化,才能让产品跟随变化为用户创造更大价值。

00 Why Agile 为什么敏捷-1.png

根据最近一次全球最大规模的敏捷调查报告(13th Annual State of Agile Report)统计显示,企业引入敏捷开发的主要动机包括加速软件交付、提高管理变革能力、提升生产力、改善业务和IT的协调性等,而应用敏捷除了能为企业带来上述预期收益以外,还能在项目的能见性、可预测性、风险和成本管控,以及团队士气等方面有所贡献。

敏捷框架中涵盖的功能

(每个敏捷团队的形态各不相同,下面列出的项目可能并不完整)

  • 关注人:敏捷专注于专业人士,以及如何能够以最佳方式运用他们的专业精神来创造高品质。
  • 工作软件:Agile旨在提供高质量的工作(具有所需功能的功能)软件产品。
  • 灵活性:严格来说灵活性与敏捷性不同。灵活性是适应不断变化的条件的能力,这是敏捷的一个重要因素。
  • 客户参与:客户或用户代表经常参与并被要求提供他们的意见和帮助以确定优先顺序。
  • 多学科,合作团队:具有不同专业的不同专业人员将成为Scrum团队的一员,共同提供请求产品。
  • 信任:这是能够提供所需质量的基本要素。
  • 迭代:从最少的所需功能开始,在额外的冲刺中逐渐扩展。
  • 增量:首先确立核心功能,然后围绕功能建立架构。
  • 时间盒:敏捷团队在时间框内工作。时间框的最大长度(通常不是最小值!)

使用PingCode 学习敏捷