敏捷项目的治理实践和重要性

敏捷治理会议把治理&＃xff08;governance&＃xff09;定义为&＃xff1a;\u0026#xD;\n

\u0026#xD;\n

让初创的项目、方案或产品开发同组织的目标一致从而创造价值。治理定义了初创业务如何被设置、管理和控制。

在5月13日阿姆斯特丹的敏捷治理会议上&＃xff0c;思想领袖和实践者展示了治理如何能够支持自组织团队和敏捷项目&＃xff0c;从而为利益干系人交付价值。\u0026#xD;\n

Andrew Craddock在会议上发表了有关正确治理的敏捷项目的发言。InfoQ对他进行了采访&＃xff0c;探讨了什么是敏捷治理&＃xff0c;以及为什么需要把治理实践嵌入到敏捷开发流程里。\u0026#xD;\n

InfoQ&＃xff1a;您能分享下在你看来什么是敏捷治理吗&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew &＃xff1a;对我来说&＃xff0c;治理是关于两件事。 第一是确保我们正在执行正确的项目&＃xff0c;即这些项目是和投资业务的需求是一致的&＃xff0c;而且项目都有正当的理由。第二个是关于确保项目所交付的是符合有关法律和公司政策的。敏捷治理专注于这在敏捷项目中如何实现--以某种真正有效又同敏捷方式互不干扰的方式。

InfoQ&＃xff1a;是什么让敏捷治理显得重要&＃xff1f;它能带来什么好处&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew &＃xff1a;如果我们承认治理是重要的&＃xff0c;在某些情况下更是必不可少的&＃xff0c;而且如果我们想以敏捷的方式来工作&＃xff0c;那么把治理调整到敏捷方式就非常必要。在大多数组织中&＃xff0c;治理习惯和实践呈现出了传统“瀑布式”的开发风格&＃xff0c;让治理与支持这种传统方式的人工文书产物一致起来。事实上&＃xff0c;这在非敏捷项目中往往只是部分有效&＃xff0c;并与敏捷理念根本不相容。利用敏捷治理&＃xff0c;我们可以改变焦点&＃xff0c;从原来只是一个克服官僚主义障碍的锻炼转变为真正地帮助项目变得更加成功&＃xff0c;这些项目以一种及时和渐进的方式为业务交付真正的价值。

InfoQ&＃xff1a;您能举些例子&＃xff0c;说明治理实践有助于敏捷项目成功吗&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew &＃xff1a;至于一般的项目治理——相关项目从投资回报的角度看是否&＃xff08;并保持&＃xff09;切实可行——把审批和持续监控同一些敏捷理念和概念结合起来是很重要的&＃xff0c;例如尽量保持文档精简&＃xff0c;还有需求和解决方案的细节随着时间会越来越清楚。DSDM为此提供了一个很好的框架&＃xff0c;这是我在5月13日敏捷治理会议上演讲主题的一部分。\u0026#xD;\n

至于治理同监管或其他相关标准的联系——将治理和开发团队正在做的事情在当时直接地结合起来&＃xff0c;这很重要&＃xff1a;也就是制定符合需要的迭代式开发过程的一部分。

InfoQ&＃xff1a;您能阐述一下企业做敏捷治理的不同方式吗&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew &＃xff1a;敏捷治理与传统治理之间最大的区别是&＃xff0c;敏捷治理同敏捷软件开发宣言中的核心价值有更加紧密的联系&＃xff1a;个体和交互胜过流程和工具&＃xff1b;奏效的解决方案&＃xff08;不只是可工作的软件]胜过详尽的文档&＃xff1b;与客户协作胜过合同谈判&＃xff1b;应对变化胜过遵循计划。

InfoQ&＃xff1a;企业要如何监管从而使得他们的项目将会坚持敏捷宣言而不是成为官僚&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew &＃xff1a;我看到过Jim Highsmith在十年或更久之前的一次演讲。他提出了两点&＃xff0c;被我真正地记在了心里&＃xff1a;1&＃xff09;“文档”和“理解”是不一样的东西&＃xff1b; 2&＃xff09;“形式”和“纪律”是不一样的东西。近年来我自己增加了一个3&＃xff09;“官僚”和“质量”不是一样的东西。你所指的企业需要真正地了解这三样东西。他们需要从来自于官僚的虚假的安全感中摆脱出来&＃xff0c;并真正开始对项目和他们相关的问题负起全部责任来。希望我在13日的演讲能具体地展示如何能实现它&＃xff0c;而不至于让人感觉受惊吓似地跳进个未知领域。

InfoQ&＃xff1a;有人说&＃xff0c;他们宁愿做敏捷而不是成为敏捷&＃xff1f; 你对此有何看法&＃xff1f; 治理更多是关于成为敏捷&＃xff0c;做敏捷&＃xff0c;或两者兼而有之&＃xff1f;\u0026#xD;\n

\u0026#xD;\n

Andrew&＃xff1a;老实说&＃xff0c;如果你的治理习惯、实践和工作方式没有一致起来&＃xff0c;我不认为你可以有效地“做敏捷”。一个项目团队可以去“做敏捷”&＃xff0c;但是却得非常努力地证明他们所建议做的&＃xff08;或正在做的&＃xff09;是对业务有价值的&＃xff0c;并且证明他们正在生产的产品均符合公司和监管的标准。“成为敏捷”是超越构建软件的详细机制&＃xff0c;超越单个项目的范围&＃xff0c;把问题带进更广的领域&＃xff0c;在这个领域里能够真正地把敏捷理念利用到更广的业务范围。“做敏捷”可能是在“成为敏捷”旅程中的一个良好的开端&＃xff0c;但它只是唯一的第一步。

原文链接&＃xff1a;Governance for Agile Projects

感谢杨赛对本文的审校。

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