User Story应该是可估算的（Estimatable）。所谓的可估算的，即指能够大致地估算出实现这个user story所需要花费的时间、人力等资源（resource）。本文是我在阅读User Stroy Should Be *Estimatable*一文后的心得，也是对该文的一个总结。
不可估算的user story，其问题所在大致有几种：
1. 太大了...
解决方案：把大的user story分解成若干个小的、可估算的（最好是能够符合全部INVEST特性的）user story。
2. 缺乏足够多的信息，或者需要领域知识
解决方案：
a) 与Product Owner和/或用户代表讨论需求。讨论必须是以整个团队为单元进行讨论的。不要试图在信息还不够多的时候就估算。
b) 试着将user story分解成若干个任务（task），每个任务的工作量不超过一天。任务的工作量不超过一天，则对于user story的估算更加精确。
以上两个解决方案应该在sprint plan meeting上做好，全体团队成员都应该参与进来。只有这样，才能保证团队中的每一个人都理解这些user story和task，同时当这些user story和task到了团队成员的手上的时候，他们对其还有着新鲜的印象。
3. 对于新的技术缺乏了解，或者团队对某一特定的技术缺乏经验
解决方案：在掌握这个技术之前，不应该贸然对user story进行估计。应该让某个团队成员就这个技术做一个粗略的研究。这个研究任务应该是有固定的时间的，不需要深入研究技术的特性，只需要对这个技术有足够的了解，能够对user story做合理的估算就好。
这个研究任务最好是在sprint planning cycle进行，或者如果研究需要较长的时间，可以在sprint早期进行；在研究结束之前，不应该把user story放入sprint backlog。
众所周知，在计划一个sprint的时候，应该留出一定的工作量以应对各种意想不到的情况。如果研究显示，这个user story不需要花费很长的时间来完成，那么在条件允许的情况下，可以临时将其加入到当前的Sprint来。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
