当企业采用敏捷,并开始配置自组织团队的时候,管理层会感到对事情失去控制。流程、评审委员会和咨询机构,在转型到敏捷方式的时候这些都成了多余的东西,但他们却不自知,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 )关注我们,并与我们的编辑和其他读者朋友交流。
评论