Scrum学习小记

Scrum学习小记

这几天看了《硝烟中的Scrum和XP》,感觉不错，做下备忘。

 

一.          什么是Scrum

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

 

二.         Scrum名词

Backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

Sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

Sprint backlog:一个sprint周期内所需要完成的任务。

Scrum Master: 负责监督整个Scrum进程，修订计划的一个团队成员。

time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

Sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块,  决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目：今天完成了什么？是否遇到了障碍？即将要做什么？通过该会议，团队成员可以相互了解项目进度。

Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。

Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。

 

三.         Scrum角色和职责

产品负责人 – 定义开发目标，需要实现的feature和优先级

Scrum Master – 保证团队高效而不受打扰地工作，优化工作条件、过程

团队 – 自组织地完成项目开发，使用一切可行手段保证进度和质量

 

四.         Scrum过程

前期：产品负责人整理业务需求，形成Product Backlog库

执行：以Sprint为单位迭代式地完成Sprint Backlog。每个Sprint以Sprint Planning开始，通过每日例会跟踪进度和issue。Sprint结束时交付可运行的产品

后期：每个Sprint完成后，通过Sprint回顾发现问题和改进点，制定下个Sprint要引入的新的实践

 

 

五.         Scrum的精髓

Scrum是一个“检查并适应”的框架，在三个角色（产品负责人/Scrum Master/团队）、三种仪式（Sprint计划/Sprint回顾/每日例会）和三种制品（产品Backlog/Sprint Backlog/燃尽图）的基础上，你可以根据公司或者项目的情况，因地制宜引入任何有利于缩短开发周期、提高产品质量的实践

六.         实施过程

实施Scrum—Sprint前

产品负责人（PM）收集整理产品需求，形成产品Backlog

产品Backlog按照统一格式定义，比较重要属性有：名称、重要性、估算时间、简单描述、如何演示等，详细的需求细节可以在其他需求文档中定义

产品负责人可以通过任何渠道、方式获取和确认需求

 

实施Scrum—Sprint

产品负责人、Scrum Master和团队成员（包括QA）召开Sprint会议，Scrum Master主持会议

Sprint会议上详细沟通产品负责人选定的重要性高的产品Backlog细节，确保团队对需求的理解无误

团队就对需求的理解将Backlog拆分成任务，并给出每个Backlog的估算时间

产品负责人和团队根据Sprint内可用的人天和Backlog的时间估算，选定需要排入本次Sprint的Backlog

Scrum Master和团队分派任务，制定Sprint计划

一个Sprint的周期是两周到四周；一次Sprint会议时间大约一个下午

整理一面任务墙，将Sprint内的Backlog和任务按照未开始、进行中、已完成等状态进行归类；同时展示Sprint的燃尽图

Scrum Master每日早上固定时间组织团队的每日例会，确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的issue，并更新任务墙

任何需求变更都进行实时评估，超过规划人天的Backlog视情况进行拆分或者推迟其他重要性低的Backlog

任何完成的Backlog都需要演示给产品负责人和QA后才能提交测试

 

实施Scrum—Sprint后

Scrum Master召集、组织Sprint回顾会议

回顾会议以头脑风暴的方式Review Sprint过程和结果，发现和列举存在的问题

与会人员投票决定需要在下个Sprint中解决的1-3个问题， 探讨解决方案，确定实践方式

 

七.         Scrum精神

团队目标重于岗位职责

团队工作优于独立作战

高效沟通强于标准化的文档

高能动性的、自组织的团队胜于角色划分清晰的流水线

务实的解决问题的方法好于经典理论

快速实践，快速反馈，持续优化

 

八.         软件开发的目标

在资源一定的情况下，尽可能快地完成高质量的软件开发

 

 

九.          附：《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

 

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

 

在每对比对中，后者并非全无价值，但我们更看重前者。

 

十.         附：《敏捷宣言》的12准则

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

项目过程中，业务人员与开发人员必须在一起工作。

要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

可用的软件是衡量进度的主要指标。

敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

对技术的精益求精以及对设计的不断完善将提升敏捷性。

要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

最佳的架构、需求和设计出自于自组织的团队。

团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

十一.           参考资料

参考文档：《硝烟中的Scrum和XP》及导读PPT

相关地址：http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches