50万奖金+官方证书,深圳国际金融科技大赛正式启动,点击报名 了解详情
写点什么

敏捷是局部优化的吗?

  • 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:002539

评论

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

欧拉的奇异之旅·风暴来临与欧拉初诞

白洞计划

基于RestTemplate的在线武器库

网络安全学海

黑客 网络安全 信息安全 渗透测试 WEB安全

2022-02微软漏洞通告

火绒安全

微软 网络安全 终端安全 漏洞修复

2022年的元宇宙,你该知晓些什么?

CECBC

5种阿里常用代码检测推荐 | 阿里巴巴DevOps实践指南

阿里云云效

阿里云 云原生 软件开发 研发 DevOps实践指南

redis 面试总结

yuexin_tech

redis 面试

设计模式【14】-- 从智能音箱中学习命令模式

秦怀杂货店

Java 设计模式

从小样本学习出发,奔向星辰大海

百度大脑

springcloud五大核心组件

编程江湖

2022年1月云主机性能评测报告,移动云升至第三

博睿数据

声网AI降噪测评系统初探

声网

音视频 RTE 技术详解

浅谈OKR(12/100)

hackstoic

OKR

一文让你彻底搞懂Python中__str__和__repr__

宇宙之一粟

Python 2月月更

亚信科技AISWare AntDB数据库在运营商核心业务系统的联合实践分享

亚信AntDB数据库

5G AntDB intel 亚信科技

Linux修改drop_caches内核参数来清理缓存的一些笔记

山河已无恙

Linux 2月月更

元宇宙里办年会,听演讲、看产品、抽大奖一件不落

Meta 小元

数字孪生 元宇宙

总结 XSS 与 CSRF 两种跨站攻击

喀拉峻

网络安全

[JAVA冷知识]什么是逆变(contravariant)与协变(covariant)?数组支持协变&逆变吗?泛型呢?

山河已无恙

Java 2月月更

在阿里,我们如何管理测试环境

阿里云云效

阿里云 DevOps 云原生 敏捷开发 研发提效

Java自定义DNS解析器负载均衡实现

FunTester

负载均衡 性能测试 接口测试 DNS FunTester

Hango Rider:网易数帆开源 Envoy 企业级自定义扩展框架

网易数帆

开源 云原生 envoy Hango Rider

开源最佳实践

LinuxSuRen

开源 最佳实践

netty系列之:channel,ServerChannel和netty中的实现

程序那些事

Java Netty nio 程序那些事 2月月更

Web Components系列(四) —— 认识 Shadow DOM

编程三昧

前端 组件化 HTML5, CSS3 2月月更

征文投稿丨使用云服务器ECS快速搭建halo博客

阿里云弹性计算

征文投稿 玩转ECS halo博客

语义级代码克隆检测数据集的评估与改进

华为云开发者联盟

软件工程 代码克隆检测 代码克隆 语义代码克隆 BigCloneBench

我与Android的故事|社区征文

Changing Lin

android 移动开发 新春征文

阿里云服务器搭建halo博客从0到1

乌龟哥哥

阿里云 2月月更 halo博客

巧用这几种文本检索工具,节省80%的时间!

优麒麟

Linux 操作系统 grep 检索 优麒麟

虚拟空间引领 数字化转型拉开银行差距

CECBC

PingCode Wiki 权限设计之ACL

PingCode研发中心

项目管理 开发 acl PingCode 页面权限

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