悟空的Scrum学习笔记

2016-12-16 10:09:52来源:oschina作者:悟空太多啦人点击



# INFO
Latest Status:
- [Finished] CH01.Scrum入门# 1. Scrum入门## 1.1. 15分钟Scrum扫盲### 1.1.1. scrum是什么意思
以足球为例,足球比赛为半计划状态的的游戏。赛前会制定计划,如阵型(343、442),打法(全攻全守、边路突破)。赛中可能会遭遇一些意想不到的情况,比如说预定的核心人员被看死无法发挥作用,有球员受伤,客场遭遇不利因素,有一种没有预料过的情况不知道谁来处理等。
Scrum中既有计划会、每日立会、评审会等计划和管理活动,又有迭代期内的灵活应变活动,是一种轻重结合的敏捷过程。
> 有可执行的计划,同时还要有一定灵活应变的能力。这就是Scrum的思路。
### 1.1.2. 其他的一些过程
敏捷过程较早出现的极限编程(XP),适用于小团队、创业初期,与客户/产品经理共同办公的情况。没有整体计划,在混沌中找到秩序。与客户在每日的沟通中确定下阶段要做的工作,然后执行,有问题随时沟通。比如一天的工作上午混沌沟通,下午逐渐明细,形成成果,客户check结果看可执行的软件。当团队规模越来越大,这种方式就可能变得越来越无法接受。### 1.1.3. Scrum敏捷方法一分钟扫盲
> 流程:角色 & 动作 & 流转#### 1.1.3.1. Product Backlog
产品负责人建立条目化的产品待开发项,并进行优先级排序。
**要点1:两个概念**
- Product Owner(产品负责人)
- Product Backlog(产品待开发项)
**要点2:需求要给PO而不是直接发给开发团队**
- 一般情况下,开发团队的输入缺乏全局观,只有是什么没有为什么,导致开发团队只能去解构输入,完成功能。
- 到底要做什么样的产品?产品有没有市场有多大市场?我们要花多大的价值去做?客户是真的想要特性A还是仅仅是一个想法,可以在一年后再排上日程?提出的需求是关键客户的想法还是一个细枝末节的功能?
- 在沟通的过程中,如果两端都产生误差,那做出来的产品将大相径庭**要点3:Backlog的特点**
- 采用条目化需求。传统的整体需求分析(及设计)中条目并不重要,所有的需求都会被分析。但现在互联网时代的产品在初期可能没有人说得清楚需求,需求也可能随时在变,无法一次性把所有需求都分析出来。
- 方便优先级排序。对于优先级相对低的,暂不实现的可以推后分析。
- 可以根据内外部情况(市场反馈,内部资源)去调整方向、内容。没有发生的工作就没有成本,可以不用作为变更去管理。#### 1.1.3.2. Sprint Planning Meeting & 故事&任务
在迭代计划会上,产品负责人(给Team)讲解本迭代要开发的条目(而不是写一篇巨长的文档),团队进行估算并放入下一个迭代(直到达到上线)。
**要点1:PO主动讲业务而非开发主动****要点2:完整需求文档 vs PO讲解**
- 需求方面:很难找到一个需求人员能把所有的需求都写出来,即使写出来了,时间成本也很高。
- 开发方面:很难找到一个开发人员能把所有文档都准确理解,一般有了文档仍然需要大量的沟通
- 言不尽意。沟通本身就有失真,思想转化成文字再转化成思想,失真更大。讲解的成本会比文字的时间人力成本都底。
**要点3:开发人员估算工时**
**要点4:Sprint周期**
一般scrum的周期在2-6周,理想的周期一般在一个月。因为1个月足够长,可以做一些基础设计等奠基工作;一个月也足够短,方便控制。一年12个月,12个sprint,可以比较清晰的看出我们做了哪些重要的事情。
**要点4:PO和TEAM的相互承诺**
- PO尽量不在sprint中途增加任务,如果有意外发生,尽量配合开发调整总工作量。
- TEAM应按照迭代计划约定完成sprint中的工作,如果有意外发生,应尽早主动提出风险和问题,以便项目组做好应对。
- 过程中出现的问题应该在反思会上做分析改进。##### Sprint中的一些工具
- 敏捷扑克。工作量估算。
- 每日立会。进度监控,发现问题,协调处理。
- 燃尽图。进度监控。#### 1.1.3.3. Working Software#### 1.1.3.4. 评审会(Review Meeting)
针对交付产品#### 1.1.3.5. 反思会(Retrospective Meeting)
针对交付过程### 1.1.4. FAQ##### 1.1.4.1. PO可以在迭代中加需求吗?##### 1.1.4.2. TEAM可以调整计划(交付时间、内容)吗?## 1.2. Scrum中的工作产品### 1.2.1. Product Backlog(产品功能列表)
列出整个产品需要完成的功能。### 1.2.2. Sprint Backlog(迭代功能列表)
**要点1:PO在排Backlog时最好多排1-2个sprint**
因为这样可以让开发人员知道下一个sprint可能会有什么工作,在做设计和开发的时候可以预先考虑到,降低损耗,提高产出。这一点与XP会稍有不同,XP更像是“只做眼前事”,所以叫极限编程不是白叫的。。。。
**要点2:故事拆分的颗粒度**
- 如果已经拆分到增加XX,修改XX,可以考虑不再拆分了。
- 对于有些混杂前后台工作的故事,比如web系统和后台(两个系统),或者软件硬件等等,应该拆成不同的任务
- 如果一件事情只有一个人做,只要颗粒度是可以管理的(如1-5天),也可以考虑不再拆分了。
**要点3:注意拆分任务间的关系**
- 尽量避免串行。避免有人需要等待他人完成才能开工。
- 尽量避免高手只做设计,不写代码。避免迭代开始一堆人闲着,最后一堆人闲着。不便于跨职能团队的形成。### 1.2.3. Working Software(可工作软件)
可交付在不同场景下可能意味着不同的状态。有可能是放到生产环境运行(如微信),也有可能不是。当项目没有中间节点的交付要求时,很可能可交付软件并不是真正的可交付软件,而是保留一个可工作状态的软件,在这种情况下,经常在最后保留几个迭代做最后的性能测试、代码优化等等。### 1.2.4. 其他
可以关注下QUML:量化UML,分层级的用户故事。## 1.3. Scrum中的角色
- PO
- Team
- Scrum Master
### 1.3.1. Product Owner
#### 1.3.1.1. PO做什么
1. Sprint前:编写用户故事,确定用户故事优先级。
2. Sprint中:解释用户故事。
3. Sprint后:验收“可工作软件”。#### 1.3.1.2. PO是谁
- 产品总监。负责决策、预测、定义产品。
- 产品经理(对外)。负责需求调研、分析、市场活动、竞争对手分析、评审需求等。
- 产品经理(对内)。负责描述、跟进、细化需求。
**要点1:设其责而不设其职**
根据产品定位、团队规模等因素来设定职责对应的人。
### 1.3.2. Team
所有的设计、开发、测试、UI/UE、脚本编制、现场实施等等角色都算Team中的人。
### 1.3.3. Scrum Master
#### 1.3.3.1. SM做什么
- 维持Scrum各种活动的秩序
- 帮助团队解决非技术问题
- 发现过程中的问题#### 1.3.3.2. SM是谁
> 大多数情况下由项目经理担当。##### 1.3.3.2.1. 要求
- 能用心帮助团队拜托困难
- 不会沉迷于团队自身的技术问题
- 对scrum过程理解深刻
- 经常与团队在一起###### 1.3.3.2.2. 从PM到ScrumMaster
> 注意:不要简单把PM替换成ScrumMaster,而是PM转换为PM2.0
- 管理 vs 领导
- 过程 vs 文化
- 指令 vs 目标
- 领导压力 vs 同行压力###### 1.3.3.2.3. 管理vs领导
传统计划:估算和安排任务时间,只排任务负责人。
敏捷计划:组织小组估算任务时间,激励任务领取,协调任务分配。
传统日常活动:监督任务执行情况。
敏捷日常活动:协调团队工作,保障任务执行,揭示并解决潜在的问题。
> 管理的最高境界是不再区分管理者和被管理者## 1.4. Sprint Planning Meeting & Sprint
迭代的第一天,全员参加,完成故事编写及工作量估算,直到达到工时上限。
### 1.4.1. 一个小寓言
**寓言:**
鸡与猪的故事
**思考:**
- 鸡:轻松,简单说说。
- 猪:投入,付出全部。
**意义:**
- 换位思考
- 角色平衡
**敏捷中的猪与鸡:**
```
/* *********************************************************************** */
------
SM
------
------ | 客户需求 || 实现方法 | ------
PO | 优先级 | <<<<<< 平衡 >>>>>> | 所需时间 |TEAM
------ | 实现标准 || 人员安排 | ------
/* *********************************************************************** */
```### 1.4.2. 故事沟通#### 1.4.2.1. 如何讲故事
> 故事应该是有层次的。
传统敏捷方法喜欢用列表结构。这是有问题的,无法表达出故事/功能项之间的关联和层次。最好是利用层次做好分类,有助于从整体上来把握整体的需求,明确各个层次直到细节。
> 阅读:见书《百度阅读:QUML》。建立分层级的用户故事。#### 1.4.2.2. 如何听故事
开发人员要做什么,不要做什么### 1.4.3. 迭代计划会的整体过程
**两种估算方法:**
- bad way:讲完所有故事,完成所有估算。
- good way2:讲1个故事,估算1个故事。**执行步骤:**
1. PO讲解故事1,TEAM估算故事1;
2. PO讲解故事2,TEAM估算故事2;
3. ……
4. PO讲解故事n,TEAM估算故事n;
5. 达到Sprint交付极限。**好处**
1. 加强互动
2. 避免PO溜号,在估算过程中很有可能发现还需要共同讨论的问题### 1.4.4. 计算有效工作日
举个栗子:
```
22day - 2day// 计划会1day,评审会&反思会1day
= 20day -5day // 培训出差请假5day
= 15day * 0.5~0.7// 修改bug、现场问题处理、额外任务等占用30%~50%
= 7.5day ~ 10day
结论:若团队有10人,则有效工作日有75-105人日(迭代最大工作量)。
注意:一般刚成立的团队或刚实施敏捷的团队,取最低值75人日。
```
### 1.4.5. 团队做什么
**团队要做的:**
- 对不清晰的需求提出疑问
- 通过疑问帮助PO分解需求
- 通过疑问弄清楚何为当前最急迫的需求
- 帮助PO分析哪些需求会影响到架构
**团队不要做的:**
- 执意提出新需求
- 执意安排优先级### 1.4.6. “任务估算”的行为模式
- PO。解答需求争议问题。澄清需求实现程度。
- Team。讨论,估算。就需求争议提问。
> 注:PO必须在估算现场。### 1.4.7. 一些工具
#### 1.4.7.1. 敏捷扑克
> 其实就是delphi变体,基于专家判断和共同估算
**执行步骤**
1. 各自估算
2. 最高值与最低值讨论
3. 新一轮估算
4. ……
5. 达到近似一致#### 1.4.7.2. 每日“立”会
1. 一般3-7人,很少有超过10人。
2. 5-15分钟。
3. 向团队所有团队汇报而非向PO/SM/PM汇报
4. 三个问题:昨天做了什么。今天准备做什么。在工作当中遇到哪些困难。
5. 更新进度。完善check-list和work-list**关键点1:为什么不是向领导汇报**
- 领导一般无动于衷,写了也不知道我们在做什么,无法对具体问题起到什么帮助。大家会认为写了也白写,应付工作。
- 汇报对象是同行,是有互动,有共鸣,有交集,有关联的。#### 1.4.7.3. 故事板/看板
**方法要点:**
1. 用board区分三类故事:待开发、开发中、开发完毕。
2. 记录不同状态故事的工时、总工时、剩余总工时。
3. 尽量减少开发状态的用户故事数量(WIP)。
4. 每个人最好同时只开工1-2个任务。**最重要的作用:**
可以随时看到进行中的任务有哪些。在迭代结束的时候,最理想的情况是,没有任何开发中的故事,要么是待开发项,要么是开发完毕项。
**辅助的作用:**
工作进展透明化。#### 1.4.7.4. 燃尽图
为数不多的度量工具。用曲线计划会后的总工时。然后按照实际剩余时间去标记## 1.5. 敏捷生态——工具应用成功的关键
> 如果只做每日立会,其他的活动都不开展,能够成功吗?
这是生态问题。敏捷过程中的每一种活动都有它的意义,都是能够对其他某些活动起到帮助作用,或者需要其他某些活动的支撑,这就是敏捷开发生态系统。## 1.6. 评审会与反思会
### 1.6.1. 评审会
#### 1.6.1.1. 主要工作内容
1. 小组向产品负责人展示迭代工作结果。
2. 产品负责人给出评价和反馈。
3. 以用户故事是否能成功交付来评价任务完成情况。#### 1.6.1.2. 如何开评审会**要点1:使用Time Boxing(时间盒)**
采用时间盒(Time Boxing)的方法,即限定时间而不限定范围。所以迭代不会延期,因为在迭代终点将放弃未完成的故事。
它隐含的意义在于,告诉每个人迭代最重要的目标并不是完成所有工作,而是尽快交付以便实现商业价值。
这种方式的好处在于:
1. 对于开发团队来说,可以避免不出承诺的情况。不是说有任务没有完成就可以再往后拖几天。
2. 对客户来说,尽早发布就可以尽早产生商业价值。Scrum的Sprint交付成果Working Software可以被形象地称作Scrum的心跳,如果心跳紊乱,无疑并不是好事。
评审会将只评审已经完成的工作,未完成的会被放到下一轮Sprint中。这里可能存在一个问题:当前Sprint未完成的工作,在下轮Sprint中是否一定是高优先级的?也未必,PO需要去对比。**要点2:评审的标准是整个故事是否已经达到交付标准**
如果一个故事处在“差一点就完成了”的状态,也算没有完成。常常发生很多故事都已经开始开发,但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。一般总是优先开发MoSCoW方法中必须完成和应该完成的故事,再考虑可以完成的故事。
另外,可以通过设置恰当的故事的大小来提高交付效果。如果一个故事小一些,就会比较容易完成。**要点3:可工作软件是指可在生产环境正常工作而非研发环境**
举个栗子,一个OLTP的场景,一个B2C商品交易的史诗故事应该包括挑选、购买、物流、评价、退货等故事。当我们在一个sprint中只完成了购买的测试,并不能证明已经达到working Software的标准,正确的做法是完成整套测试。**要点4:Sprint Planning应该给故事做设好优先级**
优先级不仅包括排序,还应该明确该故事是“必须”的(sprint核心故事),还是“应该”的(根据sprint可用工时来说可以完成),还是“可选”的(根据情况选择是否完成,如果进度快就多做一点)。**要点5:Sprint Planning设定每个故事的完成标准**
如是否需要测试,是否需要考虑性能,是否需要说明文档等等。这些标准一般由项目组
提前列好,每个故事只需要选中是否需要即可。
有的故事的标准应该是不同的。有些故事是需要科学计算绝对准确的,有些本身就是尝试做看看效果的,交付标准就不会一样。**要点6:可以选择渐进式评审**
尽管有正式的评审会,但很多团队习惯在单个故事完成时,就让产品负责人进行单个故事评审,以确保交付时不会有“惊喜”。**要点7:评审发现的问题如何处理**
评审会上发现的问题或改进将被累积到Product Backlog,也不会马上或在下一个迭代中开发,而是由优先级排序决定何时开发。### 1.6.2. 反思会
#### 1.6.2.1. 主要工作内容
1. 每个迭代末尾召开简短的反思会。
2. 总结哪些事做的好,哪些事做的不好。
3. 选择最多三件可改进的事情,制定改进计划。#### 1.6.2.2. 如何开反思会
> 反思会是Scrum(传统瀑布项目也一样)是最难以实施的活动之一**要点1:不要让反思会编程抱怨会**
项目中经常出现一些无法控制的事情,比如最典型的客户临时加需求。这些显然会对交付进度和质量以及团队带来一些负面的影响,这些可能并不是反思会能够解决的(总有一些问题是无法处理的),这种都是效果不好的反思会。好的反思会应该是去反思那些我们能够改变的问题。如果还是觉得很不爽,可以想想天朝的房价,看看开反思会有没有意义。
> 发现问题、持续改进、取得效果才是反思会的目标。**要点2:避免经常出现一些多次被提到但却始终没有解决的问题**
应该每次仅就1~3个关键问题做出可行的解决方案,在下一个迭代执行改进。“可行”的概念包括两个含义:第一是方法简单,影响面小,见效快;第二个是目标不要激进,而要现实可行,积少成多。
> 避免去找客户的茬、老板的茬、企业文化的茬。**要点3:**
如果必要可以执行领导回避制度,即具有管理职能的人不参加反思会,即使这些人是产品负责人,项目经理,乃至Scrum Master。## 1.7. 敏捷开发的历史,现状与未来
### 1.7.1. 软件生命周期模型对比
![image](/2014th7cj/d/file/p/20161216/3m0rrrtvvub.jpg)### 1.7.2. 不定周期开发——看板
不定周期开发:纯看板开发模式(流模式)。
非常适合维护已有软件### 1.7.3. 可变周期开发——QUML+Scrum模式
适合持续交付。### 1.7.4. 未来动向:企业级敏捷框架SAFe
Scaled Agile Framework 3.0# 9. 阅读资料
1. 《敏捷软件开发工具——精益开发方法》 —— Mary Poppendieck & Tom Poppendieck
2. 《火星人敏捷开发手册》 —— 陈勇
3. 《Scrum介绍》 —— Scrum中文网
4. 《Scrum指南》 —— Scrum中文网
5. 《用户故事与敏捷方法》 —— Mike Cohn & Kent Beck
6. 《持续交付——发布可靠软件的系统方法》 —— Jez Humble & David Farley

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台