写点什么

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

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

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

关注

评论

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

解读重要功能特性:新手入门 Apache SeaTunnel CDC

Apache SeaTunnel

CDC 数据变更捕获

时序数据库 TDengine 3.0 参数体系使用方式汇总

TDengine

数据库 tdengine 时序数据库

架构实战 3 - 外包学生管理详细架构

架构实战营 「架构实战营」

ES Client性能测试初探

FunTester

澳鹏中国第三年,缘何成为AI训练数据服务行业领头羊?

澳鹏Appen

人工智能 数据采集 数据安全 数据标注 AI向善

深入解读Netty 底层核心源码,全面分析Netty特新

程序知音

Java Netty io java架构 后端技术

北京大数据开发技术培训机构怎么样

小谷哥

TiCDC 源码阅读(二)TiKV CDC 模块介绍

PingCAP

#TiDB

大数据培训机构该如何选择?

小谷哥

TiCDC 在大单表场景下的性能优化:我们如何将吞吐量提升 7 倍?

PingCAP

#TiDB

web前端培训前景怎么样?

小谷哥

得物染色环境落地实践

得物技术

测试 研发效能 测试环境 流量预测 企业号 1 月 PK 榜

九科信息超级自动化平台前景广阔——Gartner:超级自动化是RPA行业未来发展的必然趋势

九科Ninetech

JVM 如何获取当前容器的资源限制?

阿里巴巴云原生

Java 阿里云 容器 云原生

什么?比 MySQL 性价比更高的 TiDB Cloud Serverless Tier 来了?

PingCAP

#TiDB

极光笔记 | 当前最佳实践:Header Bidding 与瀑布流混合请求技术

极光GPTBots-极光推送

后端 营销 运营

PingCAP 与 Wisconsin-Madison 大学建立科研合作,探索 Key-Value 存储系统的智能管理与自动调整

PingCAP

TiDB

TiCDC 源码阅读(一)TiCDC 架构概览

PingCAP

TiCDC

更稳定!Apache Doris 1.2.1 Release 版本正式发布|版本通告

SelectDB

数据库 大数据 数据分析 bug 版本发布

如何把可观测需求落地为业务大盘?

云布道师

阿里云

Nydus 镜像扫描加速

SOFAStack

SOFA

TiDB 首批通过信通院 HTAP 数据库基础能力评测

PingCAP

#TiDB

事件总线 + 函数计算构建云上最佳事件驱动架构应用

阿里巴巴云原生

阿里云 云原生 函数计算 事件总线

探索工业互联网领域中的设备通信协议

JustYan

物联网 工业互联网 物联网协议

基于低代码平台构筑金融行业IT运维服务体系

明道云

如何学习大数据开发技术

小谷哥

2023春招最全Java面试八股文,已经帮助512人进入大厂

程序知音

Java java面试 Java面试八股文 后端面试

web前端开发课程怎么样

小谷哥

数益工联 x TiDB丨如何运用 HTAP 挖掘工业数据价值?

PingCAP

#TiDB

欢迎来到,个人数据安全“世界杯”

脑极体

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