写点什么

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

  • 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:121944
用户头像

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

关注

评论

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

高性能对象池实现

C++后台开发

后端开发 高性能服务器 内存池 对象池 C++开发

极狐GitLab Helm Chart 已上线,玩转云原生极狐GitLab!

极狐GitLab

DevOps gitlab 云原生 Helm Kubernetes, 云原生, eBPF

了解数字机器人最新发展动向,不要错过华为数字机器人秋季发布会​

王吉伟频道

RPA 机器人流程自动化 智慧政务 机器人开发 华为数字机器人

预训练模型在金融 NLP场景下的应用

澜舟孟子开源社区

人工智能 自然语言处理 大规模预训练模型

基于预训练模型的金融事件分析及应用

澜舟孟子开源社区

人工智能 自然语言处理 金融科技 大规模预训练模型

使用FeatureAbility模块启动其他Ability

白晓明

OpenHarmony应用开发 FeatureAbility

盘点适合中小企业的文档管理工具

Baklib

浅谈 SAP ABAP 系统里的 ALV 输出方式实现

汪子熙

前端开发 SAP abap 9月月更 ALV

重拾面向对象软件设计

阿里巴巴中间件

阿里云 技术 中间件 技术代码

搭建自己的以图搜图系统 (一):10 行代码搞定以图搜图

Zilliz

Python 机器学习 深度学习 相似度分析 以图搜图

2022 云原生编程挑战赛启动!看导师如何拆解边缘容器赛题?

阿里巴巴中间件

阿里云 云原生编程挑战赛

当你的老板站在你背后,看你处理故障......

嘉为蓝鲸

运维 IT 故障 上班

到底什么样的数字化才是企业需要的?用2个数字化案例告诉你

优秀

数字化转型

​孟子轻量化技术迈上新台阶:登顶 ZeroCLUE 和 FewCLUE 榜单,已开源并提供 SDK

澜舟孟子开源社区

人工智能 自然语言处理 后端 大规模预训练模型

设计模式的艺术 第二十一章备忘录设计模式练习(设计一款RPG网游,为了给玩家提供更多方便,在游戏过程中可以设置一个恢复点,用于保存当前的游戏场景。如果在后续游戏过程中玩家角色“不幸牺牲”,可以返回到先前保存的场景,从所设恢复点开始重新游戏)

代廉洁

设计模式的艺术

百余位顶级投资人齐聚无锡,DEMO CHINA创新中国峰会即将揭幕

创业邦

Java编程之语法结构

魏铁锤

Nacos 企业版如何提升读写性能和可观测性

阿里巴巴中间件

阿里云 微服务 云原生 中间件 可观测

Apache Kyuubi 在小米大数据平台的应用实践

网易数帆

Java hive Apache Spark Thrift kerberos

数字藏品系统开发,NFT数字藏品开发说明

开源直播系统源码

软件开发 NFT 数字藏品 数字藏品软件开发 数字藏品系统

主流定时任务解决方案全横评

阿里巴巴中间件

阿里云 云原生 定时任务

【8.26-9.2】写作社区精彩技术博文回顾

InfoQ写作社区官方

优质创作周报

在数字时代,如何选择企业的知识管理软件

Baklib

SpringCloud 注册中心(Nacos)快速入门

nacos SpringCould 9月月更

数据赋能智慧重庆,巴适得很!

云计算

优秀的产品手册有助于留住你的客户

Baklib

中移链DDC-SDK技术对接全流程(一)

BSN研习社

建木持续集成平台v2.5.4发布

Jianmu

DevOps 持续集成 gitops 持续部署 Gitea

看了深入Java虚拟机:JVMG1GC的算法与实现文档,我悟了

程序知音

Java JVM 垃圾回收 java架构 后端技术

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