10 月 23 - 25 日,QCon 上海站即将召开,现在购票,享9折优惠 了解详情
写点什么

敏捷采纳中的死亡计划

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

评论

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

立即报名|3 月 8 日北京,稳定性 & 可观测沙龙来了!

阿里巴巴云原生

阿里云 容器 微服务 云原生

文生视频Sora模型发布,是否引爆AI芯片热潮

申公豹

人工智能

奇点云:SAFe框架下,我们对平台软件工程生产线做了4项改造

奇点云

大数据平台 制造业 奇点云

比特币价格突破62000美元,近一个月涨幅超过40%

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

OpenMLDB v0.8.5 发布:认证功能完善,安全升级全面实施

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

大模型+搜索:构建完整技术栈,为企业定制化注入新活力

百度开发者中心

数字 大模型 人工智能、

7万张H100打造的Open AI文生视频Sora功能原理详解|Sora注册全攻略

GPU算力

『双向奔赴,绿动未来』 ——能效电气2024新品发布会

极客天地

请求示例JAVA获取淘宝商品详情数据API接口item_get-获得淘宝商品详情(按关键词搜索商品列表)

Anzexi58

API 文档

IDC 中搭建 Serverless 应用平台:通过 ACK One 和 Knative 玩转云资源

阿里巴巴云原生

阿里云 云原生 容器服务

可用于智能客服的完全开源免费商用的知识库项目

不在线第一只蜗牛

架构 开源项目 技术栈 智能客服

JAVA请求示例获取1688商品详情数据API接口item_get-获得阿里巴巴商品详情(按关键词搜索商品列表)

Anzexi58

API 文档

盘点6个最受欢迎的 Vue.js UI 库

秃头小帅oi

对比传统主机,云主机贵吗?是否值得购买?

一只扑棱蛾子

云主机

骚操作之 持有 ReadOnlySpan 数据

八苦-瞿昙

C#

iPaaS如何实现安全通信保障

谷云科技RestCloud

信息安全 ipaas

探索基于Stable Diffusion的智能绘画大模型

百度开发者中心

人工智能 深度学习 图像 大模型

商用AI PC,能帮企业带来什么?

E科讯

互联网大厂面试题解析之大疆一面

派大星

Java 面试题 互联网大厂面试

抢占市场先机:利用API商品数据接口激活您的数据资产

Noah

京东商品详情数据获取item_get-获得JD商品详情,Java请求示例API接口

Anzexi58

干货!Windbg 在 TDengine 内存泄漏调试中的应用与实践分享

TDengine

tdengine 时序数据库 内存泄漏 windbg

用户使用433MHz无线模块时,出现偶尔无法收发数据的原因?

Geek_ab1536

J17资本合伙人SKY LAI确认出席Hack .Summit() 2024区块链开发者盛会

TechubNews

什么是渗透测试?有哪些类型?

小齐写代码

BEANZ NFT 概览与数据分析

Footprint Analytics

blockchain NFT

L2 网络 Mint Blockchain 正式对外发布测试网

NFT Research

blockchain NFT 测试网络

多种方式获取淘宝商品详情数据,关键词搜索商品列表,店铺ID获取店铺所有商品,按图搜索获取商品详情数据

Anzexi58

API 文档

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