重新发明敏捷：从价值到解决方案

Jean-Jacques Dubray是一位作家、评论家和InfoQ编辑，他撰写了一篇题为《重新发明敏捷：从价值到解决方案》的博客文章，在其中质疑了敏捷用户故事的架构。他写道：

有这样一种观点：用户故事是敏捷开发中最重要的工件，因为作为一个容器，它主要将价值流带给用户，而敏捷开发完全是关于快速价值交付的。

然而，接下来他说道：

在实践中，鲜有人专注于用户故事中的收益部分。我所见到的全部用户故事都是推进项目状态所需要的，我们习惯称之为 “需求”（措辞略有不同但意思相当）或“任务”。

以及：

然而，即使恰当地编写，用户故事的构建中仍然有一个根本性缺陷，因为它们以某种方式做出了关于解决方案形态的假设，并驱动作者几乎立即转入解决方案模式，而没有为创造和跳出定式的思维留下空间。

他使用BOLT 表示法追踪了业务问题和用户故事之间的关系。 最常见的识别用户故事的方法是作为层级结构，不过他对此并不认同：

最终，问题与解决方案之间的关系是一幅图（状态、转变代表问题、动作代表解决方案），然而正是这样，问题空间和解决方案空间在用户故事层面的结合变得令人遗憾。这意味着用户故事不能够有效嵌套，而且显然也不能够适应层级架构（层级架构在大部分我所知道的敏捷工具中都很常见）。这一问题非常严重，因为团队都在奋力将业务层面的用户故事，以及系统层面或解决方案层面的用户故事关联起来。单一父节点的概念直接与以下情况冲突：拥有多种可能进入一状态的转换的可能性，以及分解原则——相同的问题出现在若干更高层面问题的分解中。

他提出了一种对敏捷中“需求”的表达方式的改变：

要想利用这个新的概念性框架，我建议对敏捷做一个非常简单和容易的改变，并将“用户故事”替换为“问题陈述”。而每个问题都必须“找到解决方案”——将其分解为更简单的问题，或是直接找到解决方案。价值则仍旧可以用来划定优先级，以判断哪些问题将首先被解决。可以说，敏捷和精益运动非常宝贵，而专注于问题及解决方案则带来新的灵活性：我们在启用最高等级的创造性并最终与组织机构的IQ直接融合的同时，如何处理解决方案的长效性。

他继续介绍了表达问题陈述的建议（同时谨慎地避免提供“固定法”），并且宣称存在一份丰富的词汇表用于表达问题陈述，因为：

对问题暨解决方案的新的关注，提供了丰富的概念性框架，用于有效地组织团队的工作。毕竟，数千年以来我们一直在创新，也就是在创造问题的解决方案。

查看英文原文：Reinventing Agile: From Value to Solutions

感谢李彬对本文的审校。

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