写点什么

敏捷采纳中的死亡计划

  • 2014-09-23
  • 本文字数:1767 字

    阅读完需:约 6 分钟

当企业采用敏捷,并开始配置自组织团队的时候,管理层会感到对事情失去控制。流程、评审委员会和咨询机构,在转型到敏捷方式的时候这些都成了多余的东西,但他们却不自知,Marcel Heijmans 如此评论道。试图通过增加额外的计划来重新获得控制权,这只会让事情更糟糕,造成“死亡计划((Death by planning))”的结果。

Marcel Heijmans 是一名在 Mnemonics 名义下工作的独立软件工程师,他将在敏捷与软件架构研讨会2014 上发表名为死亡计划的演讲。这是在荷兰召开的为期一天的会议,软件架构师、开发工程师、需求工程师和信息分析师在一起分享软件架构知识。

InfoQ 采访了 Marcel,就敏捷项目计划、规模化敏捷、以及对于那些想做更小、更频繁交付的企业而言,在敏捷采纳和实践当中架构的作用等问题进行了讨论。

InfoQ: 你演讲的标题是《死亡计划》。你能阐述一下这是什么意思吗?

Marcel: “死亡计划”是一个项目管理反模式,描述了软件项目中由于过度计划导致的问题。对于确定性的、线性扩展的过程,详细地计划是很恰当的。当过程表现出更多的随机行为,详细计划的复杂度会大幅增加。许多软件项目,其本质上就包含了未知的、无序的活动。

InfoQ: 计划在敏捷和瀑布式项目中有什么不同?

Marcel: “项目”受限于固定期限、固定成本、以及 / 或固定范围。瀑布式方法提供了一种结构来规划和控制这些参数。我认为“敏捷式项目”是一种自相矛盾的说法。如果放宽“计划”的定义,你可以认为对产品待办事项列表的排序是一种计划。当然,Scrum 里的 Sprint 是典型的计划行为,Sprint 受限于时间和范围。因为一个 Sprint 的周期足够小,详细的计划是有用的。

InfoQ: 你认为软件开发是系统工程(Engineering)。这意味着什么?

Marcel: 工程(Engineering)是(工作中)用于解决问题的部分,先于制造环节,并且难以计划。在很多领域里,有大量工作都需要很精确地执行,但只执行一次,工程只是这些工作中的一小部分。但工程贯穿于软件开发始终,因此对软件开发过程做详细的计划是不太适合的。

InfoQ: 对于企业采纳敏捷,你的观点是怎样的?你能使敏捷开发规模化吗,如果能的话你是怎么做的?

Marcel: 企业接纳敏捷,因为它能带来成功。敏捷(Scrum)中的很多方面都很容易被企业所接受。而那些不容易被接受的、基本的方面,则常常被忽视掉。“用户反馈”部分(以及对应的产品负责人角色)对于大型组织而言确实很难接受。讽刺的是,敏捷广受好评的成功,主要来源于这一部分。此外,敏捷中那些容易被接纳的部分是可以被规模化的,例如创建团队、迭代式工作、每日站会、Sprint 回顾,而且有许多框架可以帮助做到。“用户反馈”决定了产品是否准备就绪;规模化“用户反馈”循环的难度,与企业在敏捷上的文化共识度成反比。

InfoQ: 企业采纳敏捷的过程中,架构在计划里扮演了什么角色?

Marcel: 软件开发的工程性质、加上大型组织里固有的复杂性、以及企业无法始终如一地实施敏捷,导致了不可预测性。当管理层感觉失去控制的时候,会祭出“标准”计划管理工具,以期重新获得控制权。但是详细的计划对于工程活动是不合适的;架构师的作用是为手头的问题提供技术解决方案。因此,对于一些问题而言,架构设计不是最好的解决方案。

InfoQ: 从你的经验看来,对于想要更小、更频繁交付的企业,有什么实践可以推荐一下吗?

Marcel: 许多企业即便采纳了敏捷,也会保留发布频率很低的发布时间表。这种方法为管理层的过度计划提供了完美的温床。系统环境的复杂性、系统间相互依赖是导致发布问题的主要原因。频繁发布是需要通过技术手段解决的。通过“计划”在十多个互相依赖的系统上同步发布时间表,这是一种时间上的巨大浪费。

运用类似 Fowler 描述的“功能开关(Feature Toggle)”机制,可以解耦提供者和消费者之间的发布依赖性。这样用一个很小的额外努力(构建“功能开关”),就能减少发布的复杂性。

另一种实践是做到自动化部署。我发现用工具将发布变得更可靠、更自动化,这将提高发布频率。尽管系统间仍然存在依赖关系,较高的发布频率依然可以降低对发布时间表同步的压力。

查看英文原文: Death by Planning in Agile Adoption


感谢曹知渊对本文的审校。

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

2014-09-23 08:49928

评论

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

互联网架构演变

爱好编程进阶

Java 程序员 后端开发

【直播回顾】OpenHarmony知识赋能五期第四课——子系统音频解读

OpenHarmony开发者

OpenHarmony 多媒体

三大特性,多个场景,Serverless 应用引擎 SAE 全面升级

阿里巴巴云原生

阿里云 Serverless SAE 阿里云云原生 应用引擎

C++搭建集群聊天室

爱好编程进阶

Java 程序员 后端开发

Java---多态

爱好编程进阶

Java 程序员 后端开发

Java面试比较---谈谈你对面向对象的理解,什么是面向对象?

爱好编程进阶

Java 程序员 后端开发

JMH性能测试,试试你代码的性能如何

爱好编程进阶

程序员 后端开发

Spring Boot 青睐的数据库连接池HikariCP为什么是史上最快的?

爱好编程进阶

Java 程序员 后端开发

探讨企业知识管理的困惑

小炮

企业知识管理

Elasticsearch聚合学习之一:基本操作

爱好编程进阶

Java 程序员 后端开发

maven 管理工具学习使用 ——

爱好编程进阶

Java 程序员 后端开发

Java 四种线程池

爱好编程进阶

Java 程序员 后端开发

租房开放源码

源字节1号

租房小程序

Java8--Lambda表达式对List集合操作

爱好编程进阶

Java 程序员 后端开发

Nginx免费证书申请构建Https域名

爱好编程进阶

Java 程序员 后端开发

java培训Nginx 快速入门

@零度

JAVA开发

IntelliJ IDEA创建基于maven的springboot项目

爱好编程进阶

Java 程序员 后端开发

基于Saga的分布式事务调度落地

百度Geek说

微服务

LeetCode - Easy - 107

爱好编程进阶

Java 程序员 后端开发

Talent Plan TinyKV Project1 StandaloneKV

爱好编程进阶

Java 程序员 后端开发

Apache ShardingSphere 遇上得物“彩虹桥”

SphereEx

数据库 开源 ShardingSphere SphereEx apache 社区

20年清华扫地僧,整理的Storm、Spark学习笔记

爱好编程进阶

Java 程序员 后端开发

2022“星课堂”直播课,开课啦!

星环科技

LeetCode - Easy - 104

爱好编程进阶

Java 程序员 后端开发

Sharding-Jdbc实现读写分离、分库分表,妙

爱好编程进阶

Java 程序员 后端开发

一文读懂架构整洁之道

爱好编程进阶

Java 程序员 后端开发

不容忽视的35点代码优化细节

爱好编程进阶

Java 程序员 后端开发

Java Review(三十九、类加载机制与反射

爱好编程进阶

Java 程序员 后端开发

java 中异常类

爱好编程进阶

Java 程序员 后端开发

JSON和JSONP对比

爱好编程进阶

Java 程序员 后端开发

一篇文章彻底学会BOM

爱好编程进阶

Java 程序员 后端开发

敏捷采纳中的死亡计划_架构_Ben Linders_InfoQ精选文章