【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

敏捷采纳中的死亡计划

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

评论

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

Flink CDC 系列 - 构建 MySQL 和 Postgres 上的 Streaming ETL

Apache Flink

大数据 flink 编程 后端 实时计算

Linux学习方法《Linux一学就会》Linux系统进程管理

侠盗安全

Linux linux运维 运维工程师 云计算架构师

高校企业双向赋能,首届飞桨启航菁英计划圆满结束

百度大脑

人工智能 百度 飞桨

「Spark从精通到重新入门(一)」Spark 中不可不知的动态优化

尔达Erda

云计算 大数据 spark 开发者 感悟

后端开发实战总结 | 签约计划第二季|后端

阿Q说代码

内容合集 签约计划第二季 技术专题合集

科技热点周刊|PHP 基金会成立、Rust 内讧、Amazon Linux 2022 预览版发布

青云技术社区

云计算

语法糖甜不甜?巧用枚举实现“状态”转换限制

阿Q说代码

枚举 签约计划第二季 语法糖 订单状态转换

还在用BeanUtils拷贝对象?MapStruct才是王者!【附源码】

阿Q说代码

Java MapStruct 签约计划第二季 深拷贝与浅拷贝

实战篇:断点续传?文件秒传?手撸大文件上传

阿Q说代码

断点续传 签约计划第二季 文件秒传 文件分块 文件合并

『上线』OpenSEC SIGs 终于成立了!

SphereEx

开源社区 ShardingSphere SphereEx 中文开源 OpenSEC

长连接网关技术专题(六):石墨文档单机50万WebSocket长连接架构实践

JackJiang

websocket 即时通讯 IM 网关

秒过!度目智慧通行让常态化防疫更高效

百度大脑

人工智能 人脸识别

IoT Stack 2.0升级物模型及数据交互协议, 大幅提升物联网方案交付速度

百度大脑

人工智能 百度 物联网

博文推荐|使用 Pulsar IO 打造流数据管道

Apache Pulsar

Java 开源 架构 云原生 Apache Pulsar

WeTest小程序质量专项方案推出,小程序异常监控内测招募中

WeTest

如果还不懂如何使用 Consumer 接口,来公司我当面给你讲!

阿Q说代码

函数式接口 签约计划第二季 consumer 实战讲解 supplier

用户登录设计之双token设计

CRMEB

【量化】股市技术分析利器之TA-Lib(二)

恒生LIGHT云社区

量化投资 量化

大数据中不同文件格式的比较

DisonTangor

大数据 云存储

实战篇:Security+JWT组合拳 | 附源码

阿Q说代码

spring security JWT 签约计划第二季 权限验证

PackML从会到不会——标签(3)

陈的错题集

标准化 PackML

ZEGO 即构科技首发适配鸿蒙系统的 Express SDK 1.0 版本,并正式启动公测!(内附源码)

ZEGO即构

音视频 HarmonyOS 鸿蒙开发 即构科技

【活动报名】Apache ShardingSphere Dev Meetup 重启!

SphereEx

开源项目 开源社区 ShardingSphere Meetup SphereEx

看了这么多年西游记,你可知道孙悟空是如何召唤土地公公的吗?

阿Q说代码

Java 观察者模式 签约计划第二季 事件通知机制

Flink 是如何统一批流引擎的

编程江湖

大数据 flink

恒源云(GPUSHARE)_GPU白嫖大法来袭!

恒源云

深度学习 gpu 算力加速

看了同事写的代码,我竟然开始默默的模仿了。。。

阿Q说代码

策略模式 多态 签约计划第二季 自定义参数解析器 统一验签

Spark从入门到精通

冇先生

【量化】股市技术分析利器之TA-Lib(一)

恒生LIGHT云社区

量化投资 量化

如何设置Activity背景颜色与ProgressBar进度条颜色

Changing Lin

12月日更

四步做好Code Review

百度开发者中心

Code Review

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