读书笔记4——《用户故事与敏捷方法》之Scrum

——有关于Scrum

Scrum是一个迭代和递增的过程。

一轮迭代的过程是一种持续改进的过程；

一个递增的过程是指按照功能点开发和发布软件。每一个功能点（功能增量），代表一个完整的功能子集。每一个功能增量都能被完整地实现以及测试通过。

Scrum和极限编程都是基于递增和迭代方式的过程。这两种过程都在一轮新的迭代开始之前为迭代做计划。并在后续迭代中改进以前的交付，而且总是在每轮迭代中把当前迭代所计划的工作做完，贯穿整个项目总是可以持续地交付。

实施Scrum过程的项目往往采用30天为周期的迭代，称为Sprint。

在每个Sprint开始时，团队需要确定这个Sprint需要完成的工作;所有的工作内容放在一个称为产品Backlog的排好优先级的列表中;团队根据自己的经验从产品Backlog中选择下个Sprint能够完成的任务放入一个称为Sprint Backlog的列表中；团队每天会有一个简单会议，称为Daily Scrum。

(http://www.controlchaos.com/)

一个Scrum团队通常游4~7个开发人员组成。团队里通常没有区分角色的说法，二是根据实际情况，自主决定怎样完成剩余的任务。另外，团队里还有两个特殊角色人员，产品负责人和ScrumMaster。产品负责人主要负责管理Product Backlog的内容以及排列优先级。ScrumMaster 的只能类似于项目经理，不过这个角色不是管理者，更像一个领导者。但由于scrum团队本身是自组织方式，由团队成员自己决定如何完成当前任务，因此ScrumMaster更多的是为团队服务，排除障碍保证团队按照scrum的规则进行开发。

产品Backlog，是所有待开发产品功能的列表。在项目初期，不需要投入大量精力写出所有功能。

Sprint计划会议流程：产品负责人把待开发的高优先级功能介绍给团队，团队成员针对这些功能提出问题，对于有足够把握的某一个功能就可以将其从产品Backlog移到Sprint Backlog。

（注意点：

1.产品负责人只需要在此会议上，根据产品Backlog内容的多少和团队的速率（一个Sprint能够完成的工作量），介绍高优先级的条目，较低优先级条目放到以后的Sprint计划会议中讨论。

2.sprint开始时，召开sprint计划会议。

3.每个sprint必须发布可以巩固走到，经过测试的代码，这些代码能够完成对最终客户有价值的一些功能。

4.管对一起决定一轮迭代完成多少故事。

5.在任何时候都可以向产品Backlog中添加故事，或重新排列优先级。

6.在sprint结束时的sprint评审会议中，团队会演示完成的成果。

7.团队演示的是可以工作的软件，而不是幻灯片。

8.准备sprint评审会议的时间不得超过两小时。

9.只有在团队觉得自己已经把Sprint中承诺的所有任务都完成的前提下，才可以向sprint中增加新故事。此时，由团队向产品负责’询问要求添加一两个用户故事。

10.如果有十分重要的事情发生，组织发现需要做出调整，则是重新开sprint计划会议，启动一个新的sprint，取消现在的sprint。

）

Sprint评审会议，通常是演示在sprint中完成的工作，是新功能的演示。需要有意保持其非正式会议性质，尽量不用幻灯片，准备时间不要超过两小时，以免让团队感觉它是一种干扰或负担。

每日Scrum简会，每个团队成员要求回答：①你昨天做了什么②你今天打算做什么③有什么困难；该会议的一个重要目的是让成员在团队面前作出承诺，同时也让团队成员了解到项目的进展。

如何在Scrum中使用用户故事？

比如Scrum的Backlog条目用用户故事进行描述。Scrum和极限编程一样，产品负责人不需要一开始就确定所有需求，也不建议尽早维护很大的产品Backlog，不过尽可能记录更多的故事还是有一定好处。所以，首先确定用户角色，然后根据角色来收集故事，在Scrum中应用十分有效。

又比如在sprint计划会议中使用用户故事，团队讨论产品backlog中的高优先级条目，然后确定在下一个sprint需要完成的条目，记下来，然后把这些故事划分成晓得任务，方便程序员认领。

又比如在sprint评审会议使用用户故事，好处就是容易评估sprint中哪些部分已经完成。因为用户故事本身的描述方式就是对客户有价值的，同时也不涉及什么技术任务、需求问题、缺陷这些细节的描述方式，所以也很容易向产品负责人演示。

又比如每日scrum简会中使用用户故事，能够帮助团队确定是否已经完成某一个特定故事的足够功能