阅读笔记06

                                                             阅读笔记06--用户故事与敏捷方法

第12章：故事不是什么

不管预想得多么全面，我们都无法事先完全定义一个完整的具有相当规模的系统。在定义需求和用户早期频繁接触软件之间，有一个有价值的反馈循环。考虑用户的目标比列出方案的特性更重要。用户故事与用例场景类似。但用例往往仍然比单个故事要大，更容易包含关于用户界面的嵌入式假设。此外，用户故事与用例的完整度和寿命不同。用例比用户故事完整得多。用例存在于整个开发过程中。用户故事往往只是暂时的，它们的生命周期仅仅限于开发它们的迭代中。

 

第13章：用户故事的优势

用户故事促使我们重视口头交流。与其他完全依赖书面文档的需求方法不同，用户故事认为开发人员与用户之间的交谈有重大的意义。重视口头交流这一转变提供了迅速的反馈周期，往往能促成对需求的充分理解。对于不太重要的或者一开始不会被开发的需求，我们可以选择先用史诗故事来代表，而其他故事包含有更多的细节。故事鼓励随机应变的开发。在此方式中，随着不断地发现机会，团队视线能迅速地在高层及低层细节思考间来回切换。

 

第14章：用户故事不良征兆一览

在本章中，我们了解了以下一些不良症兆：故事太小、故事互相依赖、镀金、故事中包含太多的细节、过早包含用户界面细节、想得太远、故事划分太过频繁、很难为故事安排优先级、客户不愿意写用户故事，为故事安排优先级。

 

第15章：Scrum与用户故事

Serum 每30天一轮迭代，称为 Sprint。

ScrumMaster 相当于传统的项目经理，但更像是领导者和组织者，而不是经理。一般的 Scrum 团队包括 4～7 个开发人员。

产品 Backlog 是一个待开发的功能需求列表，里面的条目要么还没有实现到产品中，要么还没有计划在当前 Sprint 中开发。

Sprint Backlog 是一个团队承诺在当前 Sprint 完成的任务列表。

在极限编程里面的客户角色，在 Serum 中称为产品负责人。

产品负责人负责给产品 Backlog 排列优先级。

在 Sprint 的开始，团队从产品 Backlog 中选择下一个 Sprint 要完成的任务。

在每日Scrum简会中，每个团队成员需要回答三个问题：我昨天完成了什么？今天我要做什么？我碰到了哪些问题？

每个 Sprint 都要完成一部分可以潜在交付的产品功能增最。

在 Sprint 结束时，团队在 Sprint 评审会议上演示所完成的功能。