02-Scrum初步与产品backlog

Scrum理论

Scrum是以经验过程控制理论为依据，简单，但高度的纪律性；采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。
Scrum 是一种工作管理的方法，不仅仅限于软件开发， 可以用来管理其它活动。 Scrum 不包含技术方法或实践。
第一大支柱是高透明度
第二大支柱是检验
第三大支柱是适应

Scrum的backlog

 在XP（极限编程）中叫用户故事（user story），在

Scrum中叫backlog（条目）。
Sprint中的backlog每一项都是一个用户故事。

需求本身需要分类

史诗Epic
故事Story
增强Enhancement
缺陷Defect
技术债务TechDebts
重构Refactor

不同时期的客户提出需求关注点不一样
“史诗”只是我们对大的用户故事的标签而已

其实各种“用户故事”中，大致可以分为史诗Epic、故事Story、增强Enhancement、缺陷Defect、技术债务TechDebts、重构Refactor等几种。
其中史诗和故事大致形成树状结构，很容易勾勒出产品或项目的结构，是最需要展示给用户的；
增强和缺陷在一定程度上需要展示给用户，但除了评审中或交付后客户提出来的之外，都可以不展示给用户，而且即使展示，“展示”的层次也应该不同于史诗和故事；
而技术债务和重构由于太技术化，不适合直接展示给用户，而更适合展示给Product Owner及开发团队。

用户故事的组成

Card –卡片一般来说用户故事是写在记事卡片上，卡片上可能包括了一些说明和估算的信息

Conversation –对话有关的具体信息是通过和产品拥有者的交谈沟通得出的

Confirmation –验证用验收测试来确认实现的正确性

我们 为什么 要使用用户故事？

促进沟通 持续交付 开发敏捷
客户最终需要的并不是文档
而是通过软件帮助其完成业务价值
短小精悍的故事可以帮助我们推进沟通，挖据客户的真实需求
关注商业价值而不是功能实现，更敏捷的交付产品

如何编写故事清单

步骤:

建立用户故事树
确定业务边界
初步划分业务板块
绘制用户故事树

绘制用户故事树:
故事分解是自上而下的
故事树的完善是自下而上的
跟客户沟通的是整个故事树
开发的永远是最底层的故事

界定业务边界

如何编写故事清单

1. 建立用户角色
   明确使用对象
   确定各场景角色职责
   建立用户角色职责
   编写用户故事
   三段论
   用户沟通
   可接受条件

编写用户故事

如何编写用户故事

  用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：

更新用户角色

更新故事树

故事树的完善是自下而上的，根据对业务的理解深入需要改变上级故事。

总结:
敏捷是什么？
SCRUM 开发流程
产品backlog
用户故事的组成
用户故事的规范