Scrum简要描述

本文大部分内容摘自InfoQ《硝烟中的Scrum和XP》该书介绍了应用Scrum的经验，很值得一读。
本文主要摘选Scrum其中的一些名词概念作为记录参考。其中可能因个人理解出现错误，也还希望各位能指正。
关于Scrum团队的概念尚未总结记录。待续。

前言 写道

Scrum不是方法学，而是框架。
                 -------- Ken Schwaber

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。Scrum于1995年由Advanced Development Methodologies,Inc提出，并在2001年“敏捷联盟（Agile Alliance）”形成后受到了更多欢迎。这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来，比如说RUP。 


首先我们先了解一下其大致结构。请看下图。

其中我们可以看出的几点应该是：
一个Product（产品或项目）将由多个sprint（阶段）组成，每个sprint中包含一个backlog（可认为是特性清单），每个backlog包含了多个story（故事、功能点、需求），而每个story中又包含了多个task（比story更细，更小的故事）
组成结构非常简单，具体每个节点的含义请继续阅读。

Product：
当然你可能认为用Project（项目）更为合适，随便吧。

Sprint：
这是有一个开始时间和一个结束时间的日期段。可以称为阶段，比如“sprint-1”，用来约定从08-12-01到08-12-15这个时间段。阶段需要尽可能短。这样才能保证每个阶段之后遇到的BUG不会一下扎堆全冒出来。以下是一个划分好的product sprints，你可以先看完后面的再来看这个表。



backlog：
Backlog是Scrum的核心，也是一切的起源。它就是一个由Story（需求、或故事、或特性）组成的列表。
务必保持backlog停留在业务上，也就是避免出现“给events表添加索引”这样的story，改成这样“提高在后台系统中搜索事件表单的响应速度”，因为Scrum团队里可能会出现客户，所以要避免出现这样的技术字眼。否则会出现沟通困难的情况。。



story（故事）：
有时候也叫backlog条目，故事是产品负责人所关心的。其中用一些字段来描述，如：

• ID：统一标识符，就是个自增的数字而已。防止重名的故事。不过我想故事如果重名了最好还是改一改。与其去记一串数字不如记这个数字的内在含义简单。
• Name（名称）：简短的、描述性的故事名。比如“查看自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是个什么东西，跟其他故事区分开。一般由2到10个字组成。
• Importance（重要性）：产品负责人评出的一个数值，指示这个故事有多重要，比如10或150.分数越高越重要。但这个数值并不代表150分值的故事就比10分值的故事重要15倍。

• Initial estimate（初始估算）：团队的初步估算，标识与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天(man-day)”。“把3个人关在一起，大约需要4天时间来完成这个故事”那么初始估算的结果就是12个故事点。

• How to demo（如何做演示）：它大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到....的结果”。
• Notes（注解）：相关信息、解释说明和对其他资料的引用等等。一般都非常简短。

故事不能太长，也不能太短，太短可能会使你成为微观管理的受害者，而太长则可能导致故事只能部分完成。一般可控制在2至8个人天之间（1个有效的人-天=6个有效的人-小时）。
下面一张索引卡，对应一个故事，可利用这个卡片可在sprint会议上进行交流。



task（任务）：任务是用来更详细的描述story，也就是说story下面可以有N个任务，也就是说，把故事拆分成更小的故事。如何拆分就需要经验的支持了。如果你是TDD的实践者，那么你的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”：）





接下来。我们用一个更直观的例子。。下面的图片虚拟出了一个任务板，这个任务板你可以布置在一块白板或直接是在墙壁上，至于你该选用哪种做法，你就尽可能选不会给你造成麻烦的那一个，在这里你可以看到怎么把上面描述的那些东西都组合起来。

1.首先你需要建立这样一块任务板，至少2×2平方米，大团队可能需要3×2平方米。


2.下面的图描绘了这个任务板各个区域的用处，再次提醒，务必保持简单，你可能会想在上面加几个你认为合适的区域，但在那么做之前请先问问“自己真的有必要吗？”


3.下面是每日例会之后的任务板，注意到其中已经有3个任务被“Checked out”


4.几天后，任务板可能变成了这样，特别注意，在任务板的右下角有3个未经过计划的条目。进行sprint回顾的时候应当记住这一点。



接下来我们来看看燃尽图。也就是任务板最右边那个大家伙。

这张图包含的信息：

• Sprint第一天，8月1号，团队估算出剩下的70个故事点要完成。这实际上就是整个sprint的估算生产率。
• 在8月16号，团队估算的还剩下15个故事点的任务要做。跟表示趋势的虚线相比，团队的工作状态还是差不多沿着正轨的。

注意，这里没有把周末放到时间轴上，因为这两天可能大家都没干活或者是只有几个人在，那么会导致这两天的曲线是平的，看上去就像是警告sprint出了问题，这就让人看着不爽了。

下面来看看几组出现问题的sprint
1.出现问题的燃尽图，上面的出现了工作超期，而下面的则出现了工作提早完成，这都是不健康的sprint，团队需要立刻进行调整。


2.没有按照重要重要性来安排工作的sprint


3.过多的未计划条目



如何更新任务板？
当估算与实际工作时间产生差距的时候怎么办？很简单，像这样:



Scrum很强大，也会令人痛苦，因为你不得不根据自己的具体情况来对它进行调整。

评论

4 楼 shgen 2011-06-23  

那个brundown chart的竖轴是不是错了，应该是小时，而不是故事点。

3 楼 贫嘴男孩 2009-02-16  

讲的还算可以，只是有一些部分还需要解释

2 楼 全冠清 2009-02-16  

引用

Product：
当然你可能认为用Project（项目）更为合适，随便吧。

是
我还是觉得Product合适，如果说Scrum框架，填充这个框架的一切行为都是Product

1 楼 全冠清 2009-02-16  

引用

Scrum不是方法学，而是框架。
                 -------- 风花雪月饼

过程框架？？？具体所做的就是向这个过程中填加的东东？？？
是不是这样