写点什么

敏捷是局部优化的吗?

  • 2012-03-15
  • 本文字数:2218 字

    阅读完需:约 7 分钟

据我对敏捷社区中人们扩张敏捷边界的建议的审视,我认为敏捷正逐渐进入到局部优化的危险之中。

在继续下去之前,让我先回顾一下对优化系统和局部优化系统的定义:

“优化系统是在整个系统的价值流之上对系统的优化或对浪费的消除的系统。”

“局部优化系统是在系统的部分价值流对系统的优化或对浪费的消除的系统。这有可能会导致整个系统效率降低。”

项目价值流

敏捷专注于项目价值流,这很正确,我认为没人会质疑:以敏捷的方式执行项目时项目价值流是最大化的。

那项目之外的价值呢?项目集和公司价值呢?

项目集价值流

如果我通过所听到的被最频繁提及的一致的意见来遵循敏捷,那么就会缺乏下面两种项目信息:

项目记忆 —— 关于项目是如何规划和执行的信息。

解决方案记忆 —— 关于项目的技术或功能的解决方案

如果我在便条上写用户故事,通过看板进行管理,我的回顾记录、应用程序和自动化测试用例是最后主要的文档,那我能回答一下这些问题么?

  1. 我怎么才能查找之前的项目以充分利用机会?我非得先通读代码和测试,然后再通过某种方法才能决定如何充分利用机会么?
  2. 我怎样才能回顾之前的项目历史,查看之前是怎样进行估算的,以帮助我这次作出更好的估算?
  3. 既然我们认识到永远也没有足够的时间去创建出所有的自动化测试用例,我怎么才能知道如果一个新需求变更是否正在实现某种设计之外的功能,并将产生我无法预期的副作用呢?因为我还没有自动化测试来确保这个需求变更当前的正确性。
  4. 我怎样才能确保我的解决方案能够符合多个相互没有高层认识的项目呢?
  5. 如果公司雇员已经完全换血,我有足够的文档在未来十年中来维护这些应用程序么?
  6. 如果部门中的现实是,在项目进行时部门中许多人都不能专注在项目上。那我怎样才能管理这样的部门呢?对于这类情况我需要更多的文档么?

从本质上说,敏捷软件开发项目是独立的项目,主要由全职成员组成,且几乎没有跨越项目的监管。这导致了对项目集价值流关注的更大的需求。

公司价值流

或许最近最麻烦的倾向之一是这样的说法:不应再进行任何估算了,因为它们必然是错误且浪费时间的。建议直接启动项目,在项目进行两三个迭代之后就可以确认速度了,据此速度给出完成项目的精确估算,并通知客户。

这一说法是从整个项目的角度来看的。每个启动的项目都需要商业案例的支持:投入 X 美元将获得价值 Y 的回报,并且这在商业上是可接受的。如果我们不再对项目进行估算,我们将会冒后面这些风险:启动错误的项目;消耗项目的投资,直到我们确定花太多钱了,或是回报的价值太小了。

如果我们真的关心公司长远的生存能力,那么宣称我们不再需要进行估算是荒谬的。这其中隐含了我的信念:用户故事点必须转换为小时数。在我与开发人员的讨论中,他们要求每个用户故事都有小时数,以确保他们走在正轨上。

虽然我喜欢拿用户故事和用户故事点数来进行估算,但如果我们不把用户故事点转换为小时数,那我们就是局部优化的。我们在把开发过程置于满足商业案例之前。不把与项目的商业案例相关的估算的上下文告诉开发人员,就相当于我们在商业案例和开发人员之间形成一个隔离层。我们会让项目迭代更加高效,但同时也可能牺牲了满足商业案例的能力。

但商业案例不正是项目存在的理由吗?

三种确保敏捷项目不是局部优化的方法

  1. 对项目进行估算 —— 确保对项目进行了估算,确保估算被纳入了让项目有存在的理由的商业案例之中。这些估算必须给予它们应有的关心和关注,而不仅仅是为了让项目通过审批而估算。我对如何对敏捷项目进行估算的建议改天另行探讨。
  2. 创建轻量级的解决方案架构交付物 —— 确保项目的解决方案架构的定义在高层次上进行,确保所有人都对这一解决方案有统一的认识。而后,这些交付物能用于项目监管,确保一致性并能充分利用项目集中跨项目的机会。
  3. 把用户故事估算转换为小时数并对时间进行追踪 —— 将用户故事转换为小时数,与开发人员一起设定预期时长,也为业务案例提供信息以确保项目走在正规之上。追踪时间,这可能会给每个人的日常工作生活带来不便,但实际上确实对项目集和公司有很大的价值。虽然了解项目的速度可以很好地进行预测和规划,但无法让我了解下面这些:
  • 何种类型的工作是我们估算不充分的或是花了比预期更长时间的?
  • 何种类型的工作是我们估算良好或是只花了比预期更短时间的?
  • 何种类型的工作是我们忘了估算的?
  • 我们遇到的什么问题增加了我们完成任务的时间?

总结

“我们以敏捷方式运作项目,是否在牺牲企业长远目标?”我认为没人会认为敏捷不是最好的执行项目的方式。但我确实认为有时敏捷仅仅关注项目和项目内的客户的价值,这可能会导致缺乏对项目集和公司价值的关注。

在对过程进行优化时,我们要确保时刻把整个价值流铭记于心。否则,会有一堆非常成功的项目存在于许多失败的公司之中。

关于作者

Terry Bunio目前是 Protegra 的首席顾问。Terry 从未想过成为一名项目经理。他的主要职业生涯都是在数据架构方面。随着时间的推移,Terry 发现他喜欢上了帮助建立团队,增加客户信赖,促进个人成长,从事项目工作和帮助指导解决方案。这些似乎就是一些人眼中的项目管理。作为一名有实践经验的项目经理,Terry 以挑战惯性思维和打破书本上理论的敏捷和现实世界的方法间的平衡而为大家所熟知。Terry 致力于遵循精益原则来实现敏捷。


感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012-03-15 00:002403

评论

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

叮咚买菜自建MongoDB上云实践

MongoDB中文社区

mongodb

当游戏爱上MongoDB–参会赢Kindle!

MongoDB中文社区

mongodb

公安重点人员动态预警管控系统建设,警务情指一体可视化决策系统

电微13828808271

云脑启智 开源赋能 | 2021新一代人工智能院士高峰论坛暨启智开发者大会顺利举办

OpenI启智社区

人工智能 院士峰会 启智社区

1300亿次!百度地图发布生态全景3.0 日均位置服务请求次数再创新高

百度开发者中心

人工智能

手把手教你配置php的redis扩展

恒生LIGHT云社区

php redis php扩展

IAST 在去哪儿 Q-SDL 体系中的应用

火线安全

信息安全 DevSecOps IAST

重启iptables为啥内核参数不对了?

BUG侦探

Linux iptables

为什么孩子会有拖延症?

Tiger

28天写作

toB企业的客户续约提醒

明道云

OPPO大数据离线计算平台架构演进

安第斯智能云

大数据 spark YARN

Spring Boot开发,有这个包就够了!

sleeper

Java DevOps springboot 框架

【年度评选】让我们为2021留下浓墨重彩的一笔

InfoQ写作社区官方

2021年度评选 热门活动

作业三

施正威

如何突破浏览器12px限制

云小梦

CSS JavaScript html Vue transform

恒源云(GPUSHARE)_云GPU服务器如何使用OpenCV?

恒源云

OpenCV 计算机视觉 图像识别

20个提升效率的JS简写技巧

CRMEB

教你用Camtasia简单几步制作精美片头

淋雨

Camtasia

【MongoDB学习笔记】-使用 MongoDB 进行 CRUD 操作(下)

恒生LIGHT云社区

数据库 mongodb

公安大数据合成作战平台建设,合成作战指挥中心平台开发

电微13828808271

DongTai 社区双周报 | v1.1.4 版本新功能解析来啦!

火线安全

盘点 2021|代码之外:人生最大的幸运就是努力没有白费 -- 我的2021年度总结

宇宙之一粟

职场成长 生活记录 12月日更 盘点2021 代码之外

【等保小知识】等保一级二级三级哪个要求更高?

行云管家

网络安全 等保 等级保护 等保20

详解 Rainbond Ingress 泛解析域名机制

北京好雨科技有限公司

【AI最前线】精准优质-资讯|分享|热议第45期

百度大脑

人工智能「

Dubbo框架学习笔记九

风翱

dubbo 12月日更

百度王海峰:深耕自然语言处理近30年,推进AI融合创新

百度大脑

人工智能

CRM系统如何帮助企业改进销售流程

低代码小观

低代码 销售管理 CRM 无代码 CRM系统

【CSS 学习总结】第二篇 - HTML 扩展简介

Brave

CSS 12月日更

区块链数字藏品平台开发助力潮玩行业新发展

电微13828808271

52 K8S之Harbor项目

穿过生命散发芬芳

k8s 28天写作 12月日更

敏捷是局部优化的吗?_研发效能_Terry Bunio_InfoQ精选文章