Jean-Jacques Dubray 是一位作家、评论家和 InfoQ 编辑,他撰写了一篇题为《重新发明敏捷:从价值到解决方案》的博客文章,在其中质疑了敏捷用户故事的架构。他写道:
有这样一种观点:用户故事是敏捷开发中最重要的工件,因为作为一个容器,它主要将价值流带给用户,而敏捷开发完全是关于快速价值交付的。
然而,接下来他说道:
在实践中,鲜有人专注于用户故事中的收益部分。我所见到的全部用户故事都是推进项目状态所需要的,我们习惯称之为 “需求”(措辞略有不同但意思相当)或“任务”。
以及:
然而,即使恰当地编写,用户故事的构建中仍然有一个根本性缺陷,因为它们以某种方式做出了关于解决方案形态的假设,并驱动作者几乎立即转入解决方案模式,而没有为创造和跳出定式的思维留下空间。
他使用 BOLT 表示法追踪了业务问题和用户故事之间的关系。 最常见的识别用户故事的方法是作为层级结构,不过他对此并不认同:
最终,问题与解决方案之间的关系是一幅图(状态、转变代表问题、动作代表解决方案),然而正是这样,问题空间和解决方案空间在用户故事层面的结合变得令人遗憾。这意味着用户故事不能够有效嵌套,而且显然也不能够适应层级架构(层级架构在大部分我所知道的敏捷工具中都很常见)。这一问题非常严重,因为团队都在奋力将业务层面的用户故事,以及系统层面或解决方案层面的用户故事关联起来。单一父节点的概念直接与以下情况冲突:拥有多种可能进入一状态的转换的可能性,以及分解原则——相同的问题出现在若干更高层面问题的分解中。
他提出了一种对敏捷中“需求”的表达方式的改变:
要想利用这个新的概念性框架,我建议对敏捷做一个非常简单和容易的改变,并将“用户故事”替换为“问题陈述”。而每个问题都必须“找到解决方案”——将其分解为更简单的问题,或是直接找到解决方案。价值则仍旧可以用来划定优先级,以判断哪些问题将首先被解决。可以说,敏捷和精益运动非常宝贵,而专注于问题及解决方案则带来新的灵活性:我们在启用最高等级的创造性并最终与组织机构的 IQ 直接融合的同时,如何处理解决方案的长效性。
他继续介绍了表达问题陈述的建议(同时谨慎地避免提供“固定法”),并且宣称存在一份丰富的词汇表用于表达问题陈述,因为:
对问题暨解决方案的新的关注,提供了丰富的概念性框架,用于有效地组织团队的工作。毕竟,数千年以来我们一直在创新,也就是在创造问题的解决方案。
查看英文原文: Reinventing Agile: From Value to Solutions
感谢李彬对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论