《硝烟中的Scrum和XP》导读及笔记

导读大部分文字来自ohmygodlzl 的PPT （http://www.iteye.com/topic/468525 ） ，其实 应该叫做导读的导读.

 

 

文字描述还是过于平淡，动动手才能加深Scrum过程的印象，greenhopper是一个不错的工具，周末再整理一个Greenhopper实施Scrum过程的文档。

 

 

导读：

---------

 

 

scrum不能解决问题，解决问题靠开发团队自己

出色的团队最重要的是有良好素质的团队，这些素质包括进取心、责任心、良好的习惯、热情，其次才是技术、流程

scrum提供了一套实践方法，帮助软件团队养成良好的习惯

 

scrum原理 ：

1.目标驱动，在统一的软件交付目标下组织团队

2.依靠团队的智慧做项目评估、计划乃至设计、开发、测试（？）

3.抓住项目的最基本开发属性：周期+质量

周期用T表示，质量用B表示（bug数目量化），scrum有助于T*B 尽量小，

 

scrum的角色和职责

1.产品负责人(product owner)，定义开发目标、需要实现的features和优先级

2.scrum master，保证团队高效而不受打扰的工作，优化工作条件、过程

3.团队(team)，自组织的完成项目开发,使用一切可行手段保证进度和质量

外围有user,customer,Management

 

scrum过程：

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

执行：以sprint为单位进行迭代完成sprint backlog，每日例会+issues，sprint结束时交付可运行的产品

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

 

scrum的精髓：

以上过程也没什么特别的，和UP的迭代几乎一样。

精髓在于“检查并适应”，在三个角色、三种仪式（sprint计划、sprint回顾、每日例会）、三种制品（backlog、sprint backlog、燃尽图）的基础上，可以根据公司和项目情况，因地制宜的引入任何有利于缩短开发周期、提高产品质量的实践。

 

具体细节：

sprint前： 产品负责人收集需求，形成backlog，backlog以统一格式定义，重要的属性有：名称、重要性、估算时间、简单描述、如何演示等，详细的需求可以在其他需求文档中定义。产品负责人可以通过任何渠道、方式获取和确认需求。

sprint启动会议： 一个sprint周期为两周，一次sprint会议约一个下午，参与人员为3个角色都参加，scrum master主持会议。会议内容详细沟通产品负责人选定的重要性高的产品backlog细节，确保团队对需求的理解无误。团队根据需求理解将backlog拆分成任务，并给出每个backlog的估算时间，产品负责人和团队根据sprint内可用的人天和backlog的时间估算，选定需要排入本次sprint的backlog，scrum master和团队分派任务，制定sprint计划。

sprint中： 整理一面任务墙，将sprint内的backlog和任务按照未开始、进行中、已完成等状态进行归类（任务单位以小于等于1天为宜），同时展示sprint的燃尽图

scrum master每天早上固定时间组织团队的每日例会 （站立会议，控制时间为10-15分钟），确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的问题、并更新任务墙。任何需求变更都进行实时评估，超过规划人天的backlog视情况进行拆分或者推迟其他重要性低的backlog。任何完成的backlog都需要演示给产品负责人和QA后才能提交测试。

sprint后：

scrum master召集、组织sprint回顾会议。回顾会议以头脑风暴的方式review sprint过程和结果，发现和列举存在的问题，与会人员投票决定需要在下个sprint中解决1-3个问题，探讨解决方案，确定实践方式。

 

scrum精神

1.团队目标终于岗位职责

2.团队工作优于独立作战

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

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

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

6.快速实践、快速反馈、持续优化

 

 

笔记

--------

 

 

2.我们怎样编写产品backlog

 

backlog：需求、故事、特性组成的列表，按重要性排序，包含了客户想要的东西，用客户的术语加以排序

backlog条目 的要素：ID，name，重要性，初始评估的工作量，how to demo（类似use case中的场景描述，按步骤描写，test case可以以此为基础编写），注释。

 

如何让产品backlog停留在业务层次上：

“给Events表添加索引” 应该 被 “提高后台系统中搜索事件的响应速度” 代替

添加索引只是一种解决方案，而且还未必能真正解决问题，回归到问题的原始出发点，这个可以用《你的灯亮着吗》来指导

 

3.我们怎样准备sprint计划

在 sprint 计划会议之前，要确保产品 backlog 的井然有序。

 产品 backlog必须存在（你能想象到这一点么？）。 

 只能有一个产品 backlog和一个产品负责人（对于一个产品

而言）。 

 所有重要的 backlog 条目都已经根据重要性被评过分，不同

的重要程度对应不同的分数。

 

其他人也可以添加backlog条目，但重要性必须由产品负责人决定。

 

4.怎样制定sprint计划

scrop,importance,estimate 三个维度，但质量是前提，特别是内部质量（系统设计的一致性，测试覆盖率，代码可读性等）

sprint会议要是没达成全部sprint的目标则按已达成的部分开始sprint（这也行？）

sprint会议开始前需要定一个大致的时间计划，

每个sprint的目标要有一个概要的描述，

团队成员名单以及每个人的投入程度，

一个sprint包含多少故事由团队决定，而不是产品负责人或其他人，产品负责人只能通过修改故事范围、优先级来让团队选择哪些故事进入sprint，

定义完成：放入测试环境可以测试

时间估算：团队所有成员对故事进行估算，包括测试人员、开发人员，集合大家的估算确定最终确定

故事力求在1-5人天完成

故事拆分成任务，故事是可以交付的，任务是不可交付的

技术故事：需要完成但又是不可交付的东西，比如安装持续集成服务器，编写系统设计概览。

技术故事不由产品负责人管理，如果产品负责人可以对技术故事的优先级进行评估为什么都交给他呢？

bug: 如果开发完的功能被测试出bug，bug用jira进行了管理，也有优先级，建议将bug当做是sprint backlog的一部分，按照优先级进行评估是否进入sprint，

 

5.怎样让别人了解我们的sprint

我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。 

使用sprint信息页，将sprint列举出来，将sprint信息放到wiki上，邮件通知到家

 

6.怎样编写sprint backlog

一块白板，记录没开始的故事，今天开始的故事，这个sprint完成的故事。故事用白纸，任务用黄色贴纸，

燃尽图：横坐标是日期（去掉非工作日），竖坐标是工作量，story point，可以用人*时表示，

 

7.怎样布置团队房间

让团队坐在一起，

 

8.怎样进行每日例会

团队每个人自觉更新sprint backlog的状态，

 

9.怎样进行sprint演示

所有sprint都结束于演示

快速演示，演示我们实现了什么而不是我们怎么实现的，

 

10.怎样做sprint回顾

这是改进的最佳时机，

你不需要在回顾会议上得到什么好点子，在家中的浴盆里就能做得到！

轮流发言，scrum master最后总结

哪些做法可以保持，哪些做法可以改进，具体改进的想法，

 

11.sprints之间的休整片刻，

在启动新的 sprint 之前，每个人都应该至少度过一个不需要考虑 sprint 的夜晚。更好的是sprint结束在周五，这样就一个周末，最好结束在周四，周五大家搞一个LAB Day，（lab day也是要准备的。。）

 

12.如何制定发布计划，处理固定价格的合同

 

13.我们怎样组合使用 Scrum和 XP

Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。

CI：把这一切搭建起来需要大量工作，但付出的每一分钟都物有所值。

 

14.怎样做测试

把测试人员加入到Scrum团队中，测试人员就是验收先生，