敏捷用户故事，需求世界的小探针

easthomeRT

应用敏捷项目管理的项目需求始于用户故事的收集和整理，用户故事不同于传统项目管理的需求规格说明书，它以更快的速度、更少的消耗应对现实世界需求的快速变化。

用户故事是从用户的角度来描述用户渴望得到的功能。每个故事必须清晰，且能展示价值。一般应用用户故事卡片来具体体现这种价值，用户故事具体描述对用户、系统或软件购买者有价值的功能。故事可以通过卡片的形式被分发、排列、整理或贴在白板上。

通常用户故事的格式如下：

      作为一个  {角色}， 我想要  {潜在的需求}， 所以  {商业价值}

比如，作为一个医院的监管部门领导，我想要一套用药监控的指标体系，对医生用药情况进行跟踪监控，（所以）从而实现对医院非常态化用药现象的及时发现、提示、预警、纠错和规范，以期达到把大处方等问题解决在萌芽状态。

用户故事不能等同于我们通常所熟知的UML语言中用例的概念。用户故事比用例规模小，不包括用例那么多细节。用户故事只在开发用户故事的当前迭代有用，而用例常常用作项目的永久性的工件。

那么我们应该如何弥补用户故事关于需求细节的缺失问题呢？答案是更多的沟通和确认。为了确保用户故事的有效性，敏捷一般秉承3C原则如下：

1、一份书面的故事描述，用来做计划和作为提示（Card）；

2、有关故事的对话，用于具体化故事细节（Conversation）；

3、测试，用于表达和编档故事细节，且可用于确定故事何时完成（Confirmation） 。

以上沟通和确认的动作一般发生在开发（测试）人员和产品经理（客户）之间，通过对话的方式明确故事细节，并进一步确认故事的验收条件。验收测试条件或测试方法应该在每次开发迭代中尽早编写，编写的内容可以体现在故事卡背面。

理想的情况，故事卡由客户团队编写，按照故事对客户的价值来安排故事的优先级顺序。所写的用户故事能够在一次敏捷开发的迭代中完成，如果不能就需要考虑进行进一步分解。最好把一个用户故事控制在由1到2名开发人员花半天到两周时间完成代码，即完成从开发到测试的全过程。

在每一轮开发迭代时需要估计开发团队的速率，速率代表团队可以完成的工作量，通常以故事点数来计量。故事点数是一个相对度量方法，可以在拟定迭代计划时转成具体的人天数。

值得我们注意的一个原则是：放入每一轮迭代中待完成的故事所估计的故事点数总和不能超过事先开发团队所估计的团队工作速率。这个原则与看板方法中提到的限制在制品数量的原则是一致的。

本文出自东方瑞通刘通老师，转载请注明！

更多行业干货、技术文章，请关注公众号：东方瑞通IT培训（easthome_1998）