发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

通过由瀑布到敏捷的转换来减少浪费

  • 2013-10-14
  • 本文字数:1764 字

    阅读完需:约 6 分钟

组织为什么要转向敏捷?一个原因是它可以使组织处理变化的能力更强。项目进行过程中,用户需求会经常变化,这就需要开发团队能够适应产品需求。敏捷帮助团队交付满足用户需要的产品;这些产品不包含不需要(而且没有用)的特性。精益软件开发使用术语“浪费”:一切不增加用户价值的特性都视为浪费。由瀑布到敏捷软件开发的转换是如何帮助组织减少浪费的呢?

Ron Lichty 写了一篇关于“由瀑布转换到敏捷的最具说服力的理由”的博文。如 Ron 所言,该理由与浪费有关:

但是对我而言,真正起决定作用的——使我发生了由对敏捷的热衷到对瀑布的绝望这一转变——是浪费。浪费资源,浪费开发时间,浪费精力。

他问开发人员和开发经理,当收到一份 400 页的需求规格说明书的时候,他们实际上能交付百分之几。他描述了问答过程,得到的答案如下:

(……)答案很少超过 45%——最典型的是 15% 到 25%——最少会交付需求规格说明书上 10% 的需求。

在确定交付内容的方式上,Ron 看到了敏捷与瀑布的主要区别,这一点影响了交付价值:

每次 Sprint,产品经理都会与开发负责人一起对 Backlog 顶部的事项进行协商排序,以保证团队总是致力于最有价值的需求。这是我喜欢敏捷的一点。

另一方面,在瀑布场景中,答案是几乎从不进行评估。针对我的问题,答案包括“对最简单的需求进行编码”、“我们最感兴趣的需求”(最引人注意的需求!)、“阅读需求的过程中出现的想法”或者“最有趣的需求”。一份 400 页的瀑布需求,其需求的优先级几乎普遍是由开发人员而不是产品经理来确定。

在网站“精益思维”上,Mary 和 Tom Poppendieck 描述了精益软件开发的原则。其中一项原则是“减少浪费”:

在产品开发过程中,三项最大的浪费是:

构建了错误的程序包

“没有什么跟高效地做根本不需要做的工作一样没有用处。”——Peter Drucker

程序包构建错误

如果看上去没有足够的时间进行正确的构建,那么当然也没有足够的时间进行不正确的构建。

批处理和队列思想

工作在开展过程中隐藏缺陷、超出时限、导致任务切换以及延迟价值交付。

Mike Cudemo 写了一篇名为“敏捷与瀑布——什么是关键?”的博文。在文章的开头,他解释了瀑布与敏捷处理需求的不同方式:

在蓝图设计完成后,瀑布过程试图“冻结需求”。可想而知,这不现实。需求问题发现的越晚(……),修复成本就越高。在某些情况下,都不可能进行修复。(……)敏捷方法不会试图预先一次性“确定和冻结需求”。它假设,随着用户开始可视化自己的需求,需求会发展和变化。

关于敏捷软件开发中的迭代是如何提供引导结果的可能性,他给出了自己的观点:

敏捷方法试图将需求、设计、编码和测试集中到规模较小的迭代开发阶段。本质上,敏捷方法是一系列规模较小的包含在敏捷过程之中的瀑布。最终用户和企业的利益相关人员可以在系统开发的过程中看到和体验系统。过程修正变得更明显和更易于操控。

根据 Mike 的总结,瀑布项目浪费 IT 预算:

许多 CFO 发现自己置身于一部降低运营成本和进行技术投资的复杂而又需要娴熟技巧的戏中。CFO 对 CIO 施加压力,使他们提出可以充分利用现有投资的计划,同时还要求他们发展快速响应经济增长和竞争变化的能力。项目结果没有失败选项,但根据统计,瀑布方法浪费了公司 IT 项目预算的 60%。

在博文“敏捷成本更低,对吗?”中,Kenny Grant 描述了敏捷方法是如何帮助团队识别和处理浪费的。据 Kenny 说,在开发软件的时候,敏捷软件开发本身并不比瀑布成本更低。使敏捷成本更低的是其处理范围变更和项目调整的方式:

因此,比较瀑布和敏捷就像比较苹果和桔子。在我看来,这是因为,与使用瀑布型开发方法实现相同的业务需求相比,遵循敏捷原则和过程几乎总是生产出不同的产品。(……)项目范围内几乎总是有些部分可以视为浪费,或者其价值不值得以那样的成本交付。敏捷总是不懈地专注于业务价值,并通过恰如其分的工作鉴别浪费——或者是投资回报率(ROI)不佳的需求——从而给团队改变它或者一起放弃它的机会。

考虑到业务需要和需求会在项目进行的过程中发生变化,Kenny 重新表述了问题“是否‘敏捷成本更低?’”:

“对于特定的业务需要,遵循敏捷原则和过程能够使我们开发出满足需要(不多也不少)的产品,而又比使用瀑布型开发方法成本更低吗?”在这种情况下,答案是“是的,绝对!”

查看英文原文: Reduce Waste by Changing from Waterfall to Agile

2013-10-14 02:121619
用户头像

发布了 256 篇内容, 共 81.1 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

5分钟速读之Rust权威指南(六)

wzx

rust

亚马逊云科技宣布在上海设立生命健康行业数字化赋能中心

亚马逊云科技 (Amazon Web Services)

Flink的广播变量

大数据技术指南

大数据 flink 5月日更

博睿数据多点开花,数据链DNA加速走进金融、医疗、政企行业

博睿数据

数据链DNA

从外包跳槽到大厂,我用了55天成功逆袭。

Java 程序员 架构 面试

医疗数字化:区块链或成最强辅助

CECBC

医疗

一款开源小工具,提升K8S资源管理幸福感!

Rancher

【epoll】epoll多路复用和Reactor设计思想

Linux服务器开发

后端 网络编程 C/C++ epoll Linux服务器开发

全面隔绝虚拟货币暴涨暴跌风险

CECBC

NetCore配置文件使用全过程

happlyfox

520单身福利

数据挖掘从入门到放弃(七):TensorFlow和keras实现线性回归LinearRegression

数据社

机器学习 5月日更

API网关才是大势所趋?SpringCloud Gateway保姆级入门教程

Zhendong

Java spring API 网关

【偶尔一道ctf】xctf adword mobile easy-apk

Thrash

为什么“放弃”?

Nydia

学习

区块链技术在数字农业领域的应用挑战

CECBC

ArrayList vs LinkedList

ltc

ArrayList linkedlist

IPFS与 Filecoin的区别是什么?

meio

IPFS Filecoin

SWOT分析模型

石云升

创业 战略 职场经验 5月日更

夺魁!亚马逊云科技荣膺中国数据管理解决方案领导者!

亚马逊云科技 (Amazon Web Services)

造车潮

ES_her0

5月日更

产品思维

lenka

5月日更

【签约计划】试用期规则

InfoQ写作社区官方

签约计划 热门活动

发布两小时,Github访问量破百万,阿里内部首次公布的 Java10W 字面经有多强?

Java 程序员 架构 面试

520,珍惜眼前人

数据社

520 520单身福利 520 单身福利

写给大神

小梨蕊

情人节 520单身福利 520 单身福利

线程与线程池的那些事之线程篇

秦怀杂货店

Java 线程 多线程 进程 并发

架构学习笔记:复杂度来源

风翱

5月日更 架构复杂度

Dubbo 延迟与粘滞连接

青年IT男

dubbo

数字货币与加密货币、虚拟货币的区别

meio

比特币 数字货币 加密货币 虚拟货币

破茧成蝶,如何用数据之力重塑您的业务?| 云途专栏

亚马逊云科技 (Amazon Web Services)

数据预处理&特征工程

Qien Z.

Python 5月日更

通过由瀑布到敏捷的转换来减少浪费_精益_Ben Linders_InfoQ精选文章