探讨敏捷的用户故事如何定稿

这个貌似是很多项目在实施敏捷中的痛，因为用户故事可以很快的写出来，但是对项目团队来说，似乎永远没有定稿。总有再改一次的想法。

假设我们现在有一个用户故事A，第一次改版是因为需求需要明确，所以称为了A1。那么A1能发表出去给团队吗？明显还是不行。为什么？因为我们需要有人审批呀？按照惯例，我们都会需要一些SME或者业务领导来审批，说明这个需求可以进行投产并发布。所以当SME审核过之后，其实就有了A2版本，因为必定会再次修改。试想，现在的A2离当时的A1有多远呢？

这里我们会面临以下几个问题

• A，A1，A2的版本如何有效管理？
• A，A1修改，定稿谁做，谁review
• A1，A2审核是SME，定稿之后，还可能改，怎么办？

这些都是很头疼的问题，但是不得不去面对。

如何解决

面对第一个问题，有效管理还是挺方便的，利用目前市场上的需求管理工具，可以看到每次修改的变动。例如JIRA里的历史记录。另一种方法就是关闭前一个版本，create一个新版本。然后associate到前一个close的版本。这样我们就看到故事是在不断的演变的。并且也可以看到演变的记录。

第二个问题的定稿就很清晰了，A到A1的时候，就是PO去和end users，team交流沟通得到一个结果就可以了。然后上去修改，或者委托BA代为修改。

第三个问题的答案，其实就回归到了第一个问题了，定稿了再改，首先在流程上来说，就是不对了。那么如果真要修改，也应该是再开一个故事，然后associate到刚才的一个故事上。作为一个故事的补充。同时在第一个故事上，写清楚新的变更被link到了哪个故事。

总结一下，今天我们来讨论的是如何定稿，因为我们做的是敏捷的用户故事。所以一次是不可能定稿的，也不可能定稿，也永远允许变更（按照价值观）。我们的原则永远是允许变更，但是需要不断在用户故事上做associate，作为用户故事的补充。

如果喜欢，也欢迎访问我的个人wordpress，以获得更多咨询

http://www.agilep365.com/