请及时sign off用户故事吧

敏捷项目以迭代划分增量式工作周期，以用户故事划分可被独立开发并交付的任务，以点数衡量交付工作量的大小。

Showcase不能取代客户sign off用户故事

迭代中的用户故事会经历“分析－开发－QA认可－用户认可”的pipeline，交付团队的目标就是按期计划并完成迭代内的故事。我们常常强调的是迭代计划、迭代内按优先级完成开发、及时的QA测试、及时地沟通问题和完美的showcase，但似乎最后那点睛一笔没有落在让全部故事得到用户sign off上。我想原因有几。

1. 迭代内任务到QA测试通过就为止了，之后的工作是用户的，时间他们看着安排；
2. 我们完成了故事的QA测试，才能轮到用户开始signing off这个故事，常常这时已经到当前迭代的尾声了，交付团队把重心移向了下一迭代的内容；
3. 交付团队常常在迭代结束会做详细的showcase，展示完成的故事给用户来看，用户的称赞给了交付团队定心丸，我们也就不急着让客户sign off那些故事了。

在敏捷项目中，showcase可以作为向客户展示新开发的功能和周期性交流的手段，作为对这段时间完成工作的汇报，但它不能代替用户sign off，因为后者才是用户对完成故事的正式肯定。用户在看到showcase时的点头满意和用户自己详细测试之后sign off了故事的满意是不同的。sign off是故事在pipeline上的收尾，它里程碑式地标志着故事所描述的功能被如意完成并认可，未来任何时候返回头来看，这白纸黑字都是不会变的；而showcase或平时言语的讨论，说难听了都算不上是最终定音啊。

不及时sign off故事会直接影响交付

即便是双方信任度很高的团队，不能及时由用户sign off前面迭代的用户故事都是带来未来风险的因素。迭代式开发不同于瀑布模型的开发方式，前者籍以达到及时交付用户价值的优点，在于不断得到要求与反馈并及时交付部分的用户需求；而后者则试图在最开始就通过深思熟虑谈妥用户需求，并在最终一并交付它们。可见如果不在迭代结束就及时请客户承认需求的交付，拖到后来地新需求被实现时，旧的需求就将被历史无情地掩埋，而那时开发的故事在今看来则失去了意义。好在目前为止碰到的客户都很诚信，并信赖我们的交付工作，所以一切正常地前进着。

不过，在项目即将结束时，那些没有及时被sign off的用户故事带来了新一轮问题。在即将停止迭代、进入UAT阶段前，我们发现竟然有大量故事仍没有被客户sign off，交付项目眼看就到了开发结束但无法交出手的地步，因为客户不仅要sign off这些剩余的故事，还要进行全面的UAT，这样一来测试将很花时间。而我们当初只为UAT阶段预留了一周时间，也就是说，我们做回归测试之余只有等待用户的测试结果，而这个结果客户在这有限的一周内是很难拿得出来了；即便拿了出来，我们修defect的时间也所剩无几。这就是各迭代中没有及时催促客户sign off故事的恶果，我们自己将品尝它！

不幸如此了，有何良策

当客户不得不在最后一并signing off大量历史迭代的故事时，问题又来了，如何测试？要知道，最终的feature都是随各个迭代增量式开发出来的，历史过程中完成的故事所描述的feature已经很难从当前版本的应用中看到了全貌了，难道要一个个版本回滚去测试一个个悠久的故事么？那不行，也不值得。最终交付的是当前版本，岂有回滚到从前去测试之理？最终交付的是当前版本的feature，何必回到以前验证已经被更改或移除的东西？既然已经到了如今的境地，我们要向背负着大量未sign off故事的客户提建议，及时地，建议他们按feature来测试当前版本的各个功能模块，我们提供给他们最新版feature对应的故事列表以及收集起来的feature表述和测试用例。这样为客户省下处理历史问题的时间，并确保他们将注意力集中在最终交付的那些需求上，客户当然更愿意接受。

总结一下

• 用户sign off用户故事是对交付团队工作的正式肯定，showcase不能取代它；
• 及时sign off故事能及时确认交付的需求，增加交付团队迎接新需求的信心；
• 及时sign off故事能节省项目收尾时验收的工作量和难度，为UAT腾出时间；
• 在迭代结束时应及时地催促客户去sign off该迭代完成的故事，不惜有迫切感地push客户；
• 当大量未sign off的故事遗留到项目收尾阶段时，向客户建议以feature为粒度来sign off，集中注意力到当前版本同时也避免浪费时间。