Scrum and xp study notes(one)

Scrum and xp study notes

本文通过学习InfoQ的《scrum-and-xp-chinese-version》总结而得，感谢原书作者。

 

 

1章 简介

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

Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。 　　在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工作的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。

角色

1.产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。 　　

2.Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。

3.开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。

工件

1.产品订单 Product Backlog：按照优先级排序的高层需求。

2.冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。

3.冲刺燃尽图 Burndown Chart：在冲刺长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。

活动

1.计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。

2.每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。

3.评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。

4.反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。

其他

　　冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。

2章 产品backlog

产品backlog是Scrum的核心，也是一起的起源。从根本上说，他就是一个需求或故事或特性等组成的列表，按照重要等级排序。

故事（story），也称backlog条目。

故事包含以下字段：

1.ID，统一标识符，唯一标识故事。

2.Name，名称，简短的、描述性的故事名。

3.Importance，重要性，用分数表示且仅表示重要性的高低，没有数字或成倍的重要性。

4.Initial estimate，初始估算工作量，最小的单位时间在不同的团队则不同，一般是0.5天一个单位。

5.How to demo，如何做演示，大略描述故事应该如何在sprint演示上做师范，本质就是一个简单的测试规范。

6.Notes，注解，相关信息、解释说明和对其它资料的引用等等。

实例

上述6个字段是比较重要而常用的。通常，我们会把Backlog存放到共享的Excel中，多个用户可以同时编辑它。

额外的故事字段

7.Track，类别，对故事大致的分类。

8.Components，组件，通常在Excel文档中用“复选框”实现。

9.Requestor，请求者，产品负责人可能需要记录是哪个客户或相关干系人最先提出这项需求，在后续开发过程中向他提供反馈。

10.Bug rracking ID，BUG跟踪ID。

产品Backlog应该停留在业务层次上。

3章 sprint计划

在sprint会议之前，确保产品Backlog的井然有序。

 

1.产品Backlog必须存在。

2.对于一个产品而言，只能有一个产品Backlog和一个产品负责人。

3.所有重要的Backlog条目都已经根基重要性呗评分，不同的重要程度对应不同的分数。

注意：产品负责人之外的人也可以想产品Backlog中添加故事。

Sprint计划会议非常关键，它是scrum中最重要的活动。如果执行不好，整个sprint甚至会被毁掉。

举办sprint计划会议的目的是为了让团队获取足够的信息，能够在sprint周期内不受干扰地工作，也是为了让产品负责人能够对此有充分的信心。

Sprint会议产生的成果：

1.sprint目标

2.团队成员名单

3.Sprint Backlog

4.确定好sprint演示日期

5.确定好时间地点，供举行每日scrum会议

每个story都含有三个变量：范围（scope）、重要性（importance）、估算（estimate）。

 

范围（scope）和重要性（importance）由产品负责人设置，估算由团队设置。

Sprint会议流程：

1.产品负责人先概述一下希望团队在sprint中达成的目标和最总要的故事；

2.团队从最重要的故事逐一开始讨论，一一估算时间；

质量

除范围、重要性、估算外，还有一个重要而密不可分的指标“质量”，我们应该尽力把质量分成外部质量和内部质量。外部质量是系统用户可以感知的，系统响应速度、用户体验等。内部质量是用户看不到的，它们对系统可维护性有深远影响。可维护性指系统设计的一致性、测试覆盖率、代码可读性和重构等。

避免无休止的sprint计划会议，sprint会议开多久，需要明确哪些内容都应该有一个清晰的明确定规定。

实例 Sprint会议日程：

Sprint计划会议，13:00~17:00（每小时休息10分钟）

13：00~13：30 产品负责人对sprint目标进行总体介绍，概括产品Backlog，定下演示时间地点。

13：30~15：00 团队估算事件，在必要的情况下拆分Backlog。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。

15：00~16：00 团段选择要放入sprint中的故事。计算生存率，作用核查工作安排的基础。

16：00~17:00 为每日scrum会议（每日例会）安排固定的事件地点。把故事进一步拆分。

 

<!--EndFragment-->