AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

敏捷采纳中的死亡计划

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

评论

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

2025杭州国际智慧城市展览会

AIOTE智博会

智慧城市展览会 智慧城市展会 智慧城市博览会

这个是我的测试编辑器的内容

网站,小程序,APP开发定制

华为账号“一键登录”能力让美团用户尽享安全便捷的登录体验

HarmonyOS SDK

HarmonyOS

独家为《白蛇:浮生》提供云渲染服务,腾讯云助力追光动画再现东方美学

ToB行业头条

腾讯云

事业-最佳实践-个人-做事原则

南山

社区胜于代码,我们在阿帕奇软件基金会亚洲大会聊了聊开源中间件的未来

阿里巴巴云原生

Apache 阿里云 云原生

TIANCHI工业 AI- 第 10 名思路分享

阿里云天池

虚拟滚动 - 从基本实现到 Angular CDK

PingCode研发中心

大数据 虚拟滚动

一文讲清 API 接口的概念、设计和实现

Noah

AI大模型快速生成题库-助力业务人效提升10+倍

京东科技开发者

阿里巴巴拍立淘API返回值:商品搜索与社交媒体的融合

技术冰糖葫芦

API Explorer API boy API 接口 API 测试

Web3 游戏周报(8.11 - 8.17)

Footprint Analytics

链游

阿里云2024云栖大会,来了!

MasterInTech

海外直播对网络的要求有哪些?

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 海外直播网络

公链大变局:ETH老态龙钟,SOL势如破竹

区块链软件开发推广运营

交易所开发 dapp开发 区块链开发 NFT开发 公链开发

数字货币发行项目开发基本要求及模式创建与海外宣发策略

区块链软件开发推广运营

交易所开发 dapp开发 区块链开发 NFT开发 公链开发

事业-最佳实践-个人-拥抱变化

南山

AI 实时通话视频生成产品 Tavus:能听说看且有形象;Anthropic 推出 API 长文本缓存功能丨 RTE 开发者日报

声网

大航杯智造扬中电力AI大赛RANK6思路总结

阿里云天池

数智重庆.全球产业赋能创新大赛总决赛极客奖队伍比赛攻略_球球君

阿里云天池

网速慢影响海外业务?全球应用加速可以解决!

Ogcloud

网络加速 全球应用加速 企业网络加速 网络加速服务

Meetup 回顾:存算引擎一体化建设

Databend

必看!时序大模型的发展、玩家与效果对比

Apache IoTDB

【YashanDB知识库】生成迁移报告失败,"报错未知类型错误异常:"

YashanDB

yashandb 崖山数据库 崖山DB

电商搜索革命:大模型如何重塑购物体验?

京东科技开发者

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