Agile VS PMP -- Part 4 User Story

Agile的最后一个关键词，use cases (user stories)。
实践Agile以来我们开始更多的使用Story这个词。有很多人问我Use Case和User Story到底有什么区别，我实在说不清。还专门发帖子在论坛里问过，也直接请教过一些牛人，不过还是没能理解他们的本质区别。个人感觉他们说的就是一个东西，就像Iteration和Sprint本来就是一个东西。如果哪位朋友很清楚他们的区别，请告诉我们吧，不胜感谢！同时，笔者个人感觉对Story的理解还不是特别明晰，因此本文如有不对之处，欢迎指正！

 

User Story是什么？
PMP里边提到WBS（Work Breakdown Structure, 工作分解结构）。我理解的User Story很像WBS里的Package（工作包）。
WBS就是按树型分解你要执行的项目范围。比如，你要做一个特洛伊木马，你会对木马做类似下图的分解。

 

分解到不必再分解的那些叶子节点，就是工作包；在Agile里边，就是Story。
这个Story就是StakeHoder对产品特性的真实期待，而不是实现这些产品特性而所需采取的工作。简单地说，有点像Story1 = “马鼻子”， 而不是等于伐木，设计图纸, 雕刻木材等工作。 这个看上去有点像我们以前说的需求分析。

User Story长什么样子？
WBS的工作包通常被认为是名词，Agile里的Story其实本质也是名词。同时，Agile作为PM应用的实践，被实例化为以下的样子。

“As a <Role>, I want to <Goal> so I can <Business value>.”
  For example
“As a DBA, I want to be able to compress a table so that I can reduce my storage consumption”

 Agile的Product Backlog，Release（project）Backlog，以及Sprint Backlog就是由千百个这样的小Stories组成的。这东西看起来有点像一张张卡片，实践中还真有很多人把它们做成了卡片，就像扑克牌一样。
当然，这是一个单个的、相对独立的例子。如果项目比较复杂，有时候还需要适当的维护这些Stories之间的关系。

如何使用Story
诚如工作包在PMP中的重要性一样，Story在Agile项目中也是无时无处不在的，项目的每个Role，每个过程组，每个要素要依据story展开的。
以PMP为例，我曾经go through了PMP的5个过程组和9大知识领域，的确，每一项都会和Story挂上钩。细说起来够写半本PMBOK的了，所以这里就略过吧。如果谁对某一项感兴趣，给我留言啊，我们详细讨论。
Agile Scrum里的一些roles也都围绕Story展开工作。关于Scrum及其Scrum的Roles, 我会在后面详述，这里强调Story与Agile 项目的每个人都息息相关。比如:
StakeHolder的需求往往是Story的源泉和起点。StakeHolder的确认是Story的终点。而StakeHolder的反馈又是新Story的终点。
Porduct Owner，Scrum Master还有team member会与Stakeholder紧密合作，挖掘并确定Stories。Porduct Owner还要对Story制定优先级和取舍。而Scrum Master将协同Stakeholder, Porduct Owner，Team Member围绕具体的Story展开项目，并依据Stories完成情况Trace项目。
对Team Member，设计肯定也是基于Story来写。然后Code Developer按照Story写code，改defect; Tester 按照Story写和跑Test Scenario， Execution Record（ER）。同时， Info Document Developer将Story实现的需求，及story间的逻辑关系写到User Guide中去。

可见，大家都离不开Story，都要Work on Story，只是大家使用Story的方式略有差异。各个Role一般会按上述思路将Story分解成具体的Task去从不同的角度去Sizing和完成Story。这个Task就好像PMP里的活动。

 

好的Story的标准
既然Story在Agile项目中如此基础，因此，写好Story对项目执行的成败至关重要。那么怎样的Story才算好呢？著名的山羊公司给出了这样的答案。

1 Independent（独立的）
Story之间最好可以保持独立，减少依赖关系。
还记得一道PMP考题是这样的。活动A成功的概率是80%，活动B成功的概率是80%， AB的关系是Finish-Start的关系，那么完成A->B的概率就是80%×80%啦。
2 Negotiable （可谈判的）
Story不是合同，而是用来在不同Role之间交流的。因此Story可以有些灵活性。
3 Valuable（有价值的）
有价值就是真的能够满足用户的需求，给用户带来好处。这并不容易做到，但如前面文章所述，Agile可以帮我们不断调整这个方向达到这一目标。
4　Estimatable(可估算的)
由于Plan是base on在Stories上的，所以我们希望Stories都可以被估算
5 Size Appropriately（合适的size）
Agile的Stories一般Size都很小，这样很操作更精确，而且使我们行动更敏捷。因此Agile的标准一般要求Stories至少要小到1个Sprint可以完成的细度。
6 Testable（可测试的）
Story因该很容易的被测试，这样你才能方便的用Stories trace项目进度。