写点什么

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

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

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

关注

评论

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

2024 BOE(京东方)全球供应商合作伙伴大会举行 开启全球显示产业融合共生新篇章

爱极客侠

2024运维堡垒机品牌排名看这里!

行云管家

运维 堡垒机 IT运维 运维堡垒机 网咯安全

IO模型介绍(select、poll、epoll)

京东科技开发者

百度智能云千帆,产业创新新引擎

百度Geek说

AI 百度智能云 千帆大模型平台

XPath攻略:从入门到精通,告别查找困难!

测试人

软件测试

solana链土狗抢单机器人

区块链技术

咸鱼翻身啦!咸鱼之王完美内购版架设教程

echeverra

咸鱼之王

独立站如何做好移动端的优化处理呢?

技术冰糖葫芦

API 接口

BOE(京东方)国内首条第8.6代AMOLED生产线奠基 推动中国OLED显示产业再飞跃

爱极客侠

java线程池原理浅析

京东科技开发者

火山引擎发布ByteHouse性能白皮书,揭秘OLAP性能突破的关键技术

字节跳动数据平台

数据库 大数据 云原生 数仓 企业号 3 月 PK 榜

京东商品列表数据接口

tbapi

京东 京东API接口 京东商品列表数据接口

网络空间测绘系统的商业应用

郑州埃文科技

网络空间测绘技术

2024南京国际自动驾驶技术展览会

AIOTE智博会

自动驾驶展 智能驾驶展

2024陕西省等级保护测评机构一览表【新】

行云管家

等保 等保测评

IPQ9574 vs. IPQ8074: A comparison and selection guide between the two chips

wifi6-yiyi

IPQ8074 ipq9574

"线程池中线程异常后:销毁还是复用?"

京东科技开发者

Python数据库编程全指南SQLite和MySQL实践

华为云开发者联盟

Python MySQL 开发 华为云 华为云开发者联盟

大型IM工程重构实践:企业微信Android端的重构之路

JackJiang

即时通讯;IM;网络编程

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

bin的技术小屋

jdk Linux Kenel FileChannel mmap内存映射

《自动机理论、语言和计算导论》阅读笔记:p49-p67

codists

编译原理

AI能代替软件工程师吗?

小魏写代码

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