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

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

\\

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