[原]敏捷开发-故事与估算

## 建立故事的时机

1. 由Scrum Master和Product Ower来写故事。敏捷虽然是要提升你们的积极度或参与度，可是故事建立并不须要每一个成员都参与，若是都参与写故事会形成故事风格不统一，对总体评估和说明反而不利。

2. 故事建立要提早。Scrum Master须要提早安排好下次迭代开发的故事，并把需求转化为故事，产品需求文档和故事基本能够同时送到团队开发成员。咱们上次开发是，一块儿过需求，而后给你们需求分析时间，而后列故事，对故事进行评估。这样就形成一点很差，Scrum Master和开发人员同时拿到需求，都须要时间分析，而Scrum Master建立故事的时候，你们是没事干的，这个时间至少须要半天。因此Scrum Master须要提早把下次迭代的故事列到backlog里面，下次迭代直接选取优先级高的故事开发，更有利也更合理。

## 如何建立故事

编写好的故事，关注六大特征 INVEST：独立的 (Independent)，可讨论的 (Negotiable)，对用户或客户有价值的 (Valuable to Purchasers or Users)，可估计的 (Estimatable)，小的 (Small)，可测试的(Testable)。咱们开发中的经验是更注重，小的，独立的，可测试的。
* 大的故事必定要拆分，别超过5天，不然故事到Done的时间过长，也不利于控制。
* 独立的，避免故事之间的相互依赖，若是过大，按第一条拆分。
* 可测试的，表示对用户有价值的一个流程，而不是经过页面来划分，很容易陷入这种模式，一个或几个设计界面组成一个故事，这种看是明确的东西，其实隐藏了需求关联性，也容易在开发中容易形成功能遗漏，比方说页面之间的关联功能。故事描述格式能够写做，做为用户，须要什么功能，以便作什么事情。比方说，做为用户需求登陆功能进入后台管理。

## 时间预估

扑克牌，每人根据本身状况得出一个天数
若是估算不一致，经过最多和最少估算人说出本身的估算方式，避免遗漏，也避免考虑过多
不须要把故事的需求细节了解的太细，并且不要把细节或实现方式放到估算会上，故事细节由用户和开发人员讨论得出。
预估是估算，不可能每一个故事都特别准确，但最终的总体时间是可参考的