敏捷开发-故事与估算

## 创建故事的时机

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的时间过长，也不利于控制。
* 独立的，避免故事之间的相互依赖，如果过大，按第一条拆分。
* 可测试的，表示对用户有价值的一个流程，而不是通过页面来划分，很容易陷入这种模式，一个或几个设计界面组成一个故事，这种看是明确的东西，其实隐藏了需求关联性，也容易在开发中容易造成功能遗漏，比方说页面之间的关联功能。故事描述格式可以写作，作为用户，需要什么功能，以便做什么事情。比方说，作为用户需求登录功能进入后台管理。

## 时间预估

扑克牌，每人根据自己情况得出一个天数
如果估算不一致，通过最多和最少估算人说出自己的估算方式，避免遗漏，也避免考虑过多
不需要把故事的需求细节了解的太细，而且不要把细节或实现方式放到估算会上，故事细节由用户和开发人员讨论得出。

预估是估算，不可能每个故事都特别准确，但最终的整体时间是可参考的

使用文件故事做估算时的工作量包含

1. 需求分析/架构设计/编码/测试/部署（至初验款结帐），所包含范围的工作量大约是纯编码期的两倍略多

2. 需求模糊所需的讨论/测试/返工/修改缺陷/响应客户提出变更/乃至部署后提出的变更（在初验结账前），所包含的范围大约是“一次完成”的1～N倍。

4. 由于有多个人参与项目，所以由分工造成的文档/交流/沟通时间/修改别人Bug/人员离职时阅读别人的代码……等时间。

国内的20多个数据表明，若将团队控制在2人，生产率就能达到业界水平的2倍。但很可惜，“2人团队”一般需要至少一个业务和技术均过硬的高手参加，而除非一家公司1/2的人都具备这个素质，否则不可能全部变成2人团队。

5. 人员尽管定编在此项目中，但需要参加其他日常会议/领导前来打搅/紧急缺陷的修复/闲聊/上网……一切最终实际上会被填报在日志中的工时。某些时间看上去很不应该参与到生产率计算中（比如“闲聊/上网”），但因为永远不会有人单独填报“闲聊/上网”时间，所以它们实际上都被填报到日报中参加计算了；“领导前来打搅”的工作量，也不可能计算到其他项目中，所以也计算在人员所定编的项目中。

6. ……