敏捷学习笔记【一】——硝烟中的Scrum和XP(上)【产品backlog、sprint计划】

路庆华的博客

于 2019-01-31 15:44:39 发布

阅读量1.3k

点赞数

分类专栏：项目管理文章标签： Scrum spring

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/lqh4188/article/details/86711435

版权

项目管理专栏收录该内容

12 篇文章 6 订阅

订阅专栏

图书封面

Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。

产品backlog

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

Initial estimate（初始估算） ——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。

sprint 计划

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

只能有一个产品 backlog 和一个产品负责人（对于一个产品而言）
所有重要的 backlog 条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。
产品负责人应当理解每个故事的含义

注意：产品负责人之外的人也可以向产品 backlog 中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。

Sprint 计划会议非常关键，应该算是 Scrum 中最重要的活动
举办 Sprint 计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。
Sprint计划会的产出成果：

sprint 目标。
团队成员名单（以及他们的投入程度，如果不是 100%的话）。
sprint backlog（即 sprint 中包括的故事列表）。
确定好 sprint 演示日期。
确定好时间地点，供举行每日 scrum 会议。

为什么产品负责人必须参加
	范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在 sprint 计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。

会议启动以后，产品负责人一般会先概括一下希望在这个 sprint 中达成的目标，还有他认为最重要的故事。接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。在这个过程中，他们会针对范围提出些重要问题：“‘删除用户’这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答复会让他们感到惊讶，促使他们调整估算。
在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法不太一样。这可能会让他调整故事的重要性；或者修改故事的范围，导致团队重新估算，然后一连串诸如此类的后续反应。这种直接的协作形式是 Scrum 的基础，也是所有敏捷软件开发的基础。
注意：如果产品负责人不能参加：

让产品指定替代人员，且产品负责人在会议前与替代人员充分沟通到位。
推迟spring的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。

为什么不能在质量上让步

外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等

一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。松散的沙滩上怎么可能建起精美的楼阁？

经验告诉我：牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。
Scrum 中的一切事情都有时间盒。

确定 sprint 长度

Sprint 演示日期是 sprint 计划会议的产出物，它被确定下来以后，也就确定了 sprint 的长度。
不过，确定了自己最喜欢的长度之后，就要在长时间内坚持住。

确定 sprint 目标

Sprint 目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？”要想从产品负责人的口中
哄骗出 sprint 目标，你不妨一字不差的问他这个问题看看。

决定 sprint 要包含的故事

决定哪些故事需要在这个 sprint 中完成，是 sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从产品 backlog 拷贝到sprint backlog 中。

注意：在 sprint 中包含多少故事由团队决定，而不是产品负责人或其他人。

产品负责人如何对 sprint 放哪些故事产生影响？

假设在 sprint 计划会议中我们遇到下面的情况。产品负责人很失望，因为故事 D 不会被放到 sprint 里面。那他在sprint 计划会议上能做些什么?

那么如何才能把D放入当前迭代呢？

虽然产品负责人在正常情况下不能控制团队的估算生产率，他依然有很多种方式，对 sprint 中放入哪些故事施加影响


如果产品负责人想把D放入到sprint,那他在sprint 计划会议上能做些什么?	首先，他可以重新设置优先级。如果他给故事 D 赋予最高的重要级别，团队就不得不把它先放到 sprint 里面来	其次，他可以更改范围——缩小故事 A 的范围，直到团队相信故事 D 能在这个 sprint 里完成为止。	最后，他还可以拆分故事。产品负责人判断出故事 A 中某些方面实际并不重要，所以他把 A 分成两个故事 A1 和 A2，赋给它们不同的重要级别。

团队怎样决定把哪些故事放到 sprint 里面？

我们在这里使用两个技术：

1. 本能反应
2. 生产率计算

用生产率计算来估算
这项技术包括两步：
1. 得出估算生产率
2. 计算在不超出估算生产率的情况下可以加入多少故事。
生产率是“已完成工作总量”的一个衡量方式，其中每一个条目都是用它的原始估算进行衡量的。

下图中，左边是 sprint 启动时的估算生产率，右边是 sprint 结束时的实际生产率。每个矩形都是一个故事，里面的数字表示这个故事的原始估算。

为什么我们在实际生产率里面没把它的部分故事点数算进来？这就突出表现了 Scrum 的要求（实际上也是敏捷软件开发和精益制造的要求）：把事情完全做完！达到可以交付的状态！事情只做了一半，它的价值就是 0（也许还会是负数）。

资源计算：

假设我们在计划一个4人团队3个星期的sprint（15个工作日）。Lisa 会休假两天。 Dave只能投入 50%的时间，另外还会休假一天。把这些加到一起……

这个 sprint 一共有 50 个可用的人-天。我们估算的单位是故事点，差不多可以对应于“理想化的人-天”。一个理想化的人-天是完美、高效、不受打扰的一天，但这种情况太少见了。我们还必须考虑到各种因素，例如要把未计划到的工作添加到 sprint 中、人们患病不能工作等等。
那我们的估算生产率肯定要比 50 少了。少多少呢？我们引入“投入程度（focus factor）”这个词来看一下。

投入程度（focus factor）= 实际生产率(actval velocity)(完成的故事点数) / 可用人天（Available Man-days）

投入程度用来估算团队会在 sprint 中投入多少精力。投入程度低，就表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太过理想化。要想得出一个合理的投入程度，最好的办法就是看看上一个 sprint的值（对前几个 sprint 取平均值自然更好）。

假设在上个 sprint 里面，由 Tom， Lisa 和 Sam 组成的 3 人团队在 3个星期内工作了 45 个人-天，一共完成 18 个故事点。现在我们要为下一个 sprint 估算一下生产率。新伙计 Dave 的加入让情况更复杂了。把假期和新成员算上，我们在下个 sprint 中一共有 50 个人-天。