章法在敏捷开发中的重要性

  • Ben Linders
  • 徐涵

2014 年 10 月 18 日

话题:敏捷语言 & 开发文化 & 方法

敏捷软件开发,有时被认为是一种没有章法的工作方式。一些机构以此作为不采纳敏捷的理由;而在另一些人看来,敏捷其实是一种比瀑布式开发更有章可循的软件开发方法。下面,我们就来考察章法在敏捷开发中的职责,以及为什么章法对敏捷的成功实施如此重要。

Norberto Gaona 在Nearshore Americas上发表了一篇题为《不可低估章法的重要性:敏捷开发的关键》的文章。他就敏捷软件开发中章法的重要性采访了一些人。他总结道:

大家一致赞成的是,必须了解敏捷宣言,并透彻理解敏捷开发的 12 条原则。软件开发专业人士们都同意这一点,即无论采用什么框架(SCRUM、看板、精益、XP 或敏捷建模等等),都存在着误读或偏离这些原则的风险;从而造成了没有章法的局面。

Norberto 解释道,对敏捷软件开发来说,在敏捷宣言中的各条之间找到一个恰当的平衡是很重要的,这就需要一定章法:

根据敏捷宣言,个体及他们之间的互动高于所采用的工具和流程。Juan Diego Vasco 解释说,“尽管这并不是说流程和工具没有用”。“敏捷开发方法其实是需要文档的,只是不过度文档化”,他说。“如果你认为敏捷意味着无章可循,那就大错特错了。事实上,由于敏捷采用自管理团队,它对章法的要求是高于平均水平的。”

正如 Scott Shipp 在《敏捷不是边写边改》一文中提到的,敏捷不能成为你采取无章法的边写边改(code-and-fix)的做法的借口。他解释了为什么敏捷是一种更强、更有章法的软件开发方法:

许多传统开发方法给人以一种虚假的有章法的感觉。敏捷强调个体与协作,可工作的软件、客户协作和响应变化。有些人认为,敏捷不重视遵守计划或采用流程与工具等方面。而实际上,敏捷是重视的,只不过更重视其他方面。换句话说,敏捷不是提倡无章法的工作方式,而是强调章法。

Eric Bristow 发表在CIO 杂志上的《关于敏捷的九大误解》解释了为什么关于“敏捷流程相对瀑布式开发缺少章法与结构“的神话是错误的:

成熟的敏捷开发框架规定了一个有章可循的、可重复的软件开发方法。成功的敏捷方法比传统的瀑布开发模型更讲究流程驱动与协作性。从范围管理(通过排列用户故事优先级)到项目管理(通过定义好的职责与时间),敏捷需要更多章法,因为从规划到启动,项目范围是被积极管理的,同时有涉众定期检查项目进展,并在每一阶段提供反馈。敏捷流程的弹性是有内在保障的(例如禁止在 sprint 期间新增需求或用户故事),从而可以防止无休止的发布周期。

Felipe Brito 在IT Business Edge上的一个演讲稿里提出了在企业里推行敏捷的五种方法。他说,组织学习和章法对于企业推行敏捷是必要的。

自组织团队的概念告诉我们,敏捷解决过去规定性软件开发方法的不足,正是依靠更多(而不是更少)的章法。而且,随着敏捷在企业中的推广,章法也肯定会得到扩展。给团队一些自由度,但务必让团队受到训练和利用经过考验的方法与工具。在团队级自主和组织级一致之间找到精密平衡,是致胜的关键。同时,你必须建立起实践社区,为分布式团队设立协作工具,并坚持寻求和提供反馈。

Jurgen Appelo 在他的博客文章《敏捷和章法真能相容吗?》里解释了为什么有章可循的工作方式与敏捷不矛盾。他举了几个例子来说明他是如何用检查列表(checklists)和打标签(tagging)的方式来处理写书时用到的信息的:

上周,我请一个人检查自己的故事,因为我的新书里包含了他的故事。他答道:“哇,这是我两年前发给你的故事,你居然现在还记得!”好吧,老实说,并不是我的记性好,而是我老老实实地按章做事。我把人们发给我的故事和记录保存在 Gmail 和 Evernote 里,并给它们打上标签。另外,我为书里的每一章都设了一个检查列表项,提醒我必须在将各章书稿发给文字编辑之前“把故事加到 Gmail 和 Evernote 里去”。我的另一个检查列表项,告诉我在书稿从文字编辑处返回后,先做“把修改过的故事发给故事原作者确认”这件事,然后再发给校对者。(…) 认真地说,如果没有检查列表,我将无法按敏捷的方式拿出一本高质量的书。

在你经历的敏捷软件开发过程中,章法的重要性如何?

查看英文原文:The Importance of Discipline in Agile

敏捷语言 & 开发文化 & 方法