Scrum简要描述

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


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


首先我们先了解一下其大致结构。请看下图。
[img]/upload/attachment/75958/7f535ba6-bdb1-35ef-a28b-807c6b7d84f6.jpg[/img]
其中我们可以看出的几点应该是：
一个Product（产品或项目）将由多个sprint（阶段）组成，每个sprint中包含一个backlog（可认为是特性清单），每个backlog包含了多个story（故事、功能点、需求），而每个story中又包含了多个task（比story更细，更小的故事）
组成结构非常简单，具体每个节点的含义请继续阅读。

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

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


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


[b]story（故事）：[/b]
有时候也叫backlog条目，故事是产品负责人所关心的。其中用一些字段来描述，如：
[list]
[*][b]ID：[/b]统一标识符，就是个自增的数字而已。防止重名的故事。不过我想故事如果重名了最好还是改一改。与其去记一串数字不如记这个数字的内在含义简单。
[*][b]Name（名称）：[/b]简短的、描述性的故事名。比如“查看自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是个什么东西，跟其他故事区分开。一般由2到10个字组成。
[*][b]Importance（重要性）：[/b]产品负责人评出的一个数值，指示这个故事有多重要，比如10或150.分数越高越重要。但这个数值并不代表150分值的故事就比10分值的故事重要15倍。
[img]/upload/attachment/75868/dcf8a3dc-b439-31f8-8d42-ff2666312220.png[/img]
[*][b]Initial estimate（初始估算）：[/b]团队的初步估算，标识与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天(man-day)”。“把3个人关在一起，大约需要4天时间来完成这个故事”那么初始估算的结果就是12个故事点。
[img]/upload/attachment/75870/29f8a598-706b-323a-bbdc-b674d45f9abb.png[/img]
[*][b]How to demo（如何做演示）：[/b]它大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到....的结果”。
[*][b]Notes（注解）：[/b]相关信息、解释说明和对其他资料的引用等等。一般都非常简短。
[/list]
故事不能太长，也不能太短，太短可能会使你成为微观管理的受害者，而太长则可能导致故事只能部分完成。一般可控制在2至8个人天之间（1个有效的人-天=6个有效的人-小时）。
下面一张索引卡，对应一个故事，可利用这个卡片可在sprint会议上进行交流。
[img]/upload/attachment/75832/d95ae337-a7bd-3700-b7d2-f9e9b44acf0a.png[/img]


[b]task（任务）：[/b]任务是用来更详细的描述story，也就是说story下面可以有N个任务，也就是说，把故事拆分成更小的故事。如何拆分就需要经验的支持了。如果你是TDD的实践者，那么你的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”：）
[img]/upload/attachment/75808/102b3980-7cd1-3db4-9d98-59291302d4b1.png[/img]


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

[b]1.[/b]首先你需要建立这样一块任务板，至少2×2平方米，大团队可能需要3×2平方米。
[img]/upload/attachment/75840/3401b69c-898d-3bf4-803e-809789221b46.png[/img]

[b]2.[/b]下面的图描绘了这个任务板各个区域的用处，再次提醒，务必保持简单，你可能会想在上面加几个你认为合适的区域，但在那么做之前请先问问“自己真的有必要吗？”
[img]/upload/attachment/75842/e16b2828-2a4c-3205-a36b-18c4c4276296.png[/img]

[b]3.[/b]下面是每日例会之后的任务板，注意到其中已经有3个任务被“Checked out”
[img]/upload/attachment/75846/9ddc186a-6712-3c4e-996d-02ef9036c75d.png[/img]

[b]4.[/b]几天后，任务板可能变成了这样，特别注意，在任务板的右下角有3个未经过计划的条目。进行sprint回顾的时候应当记住这一点。
[img]/upload/attachment/75848/3f5b2a8d-26e4-3a48-9bff-e33f8f3ce51e.png[/img]


接下来我们来看看燃尽图。也就是任务板最右边那个大家伙。
[img]/upload/attachment/75854/f39f0d12-6744-334a-90d5-e9ed2f5e3be7.png[/img]
这张图包含的信息：
[list]
[*]Sprint第一天，8月1号，团队估算出剩下的70个故事点要完成。这实际上就是整个sprint的估算生产率。
[*]在8月16号，团队估算的还剩下15个故事点的任务要做。跟表示趋势的虚线相比，团队的工作状态还是差不多沿着正轨的。
[/list]
注意，这里没有把周末放到时间轴上，因为这两天可能大家都没干活或者是只有几个人在，那么会导致这两天的曲线是平的，看上去就像是警告sprint出了问题，这就让人看着不爽了。

下面来看看几组出现问题的sprint
[b]1.[/b]出现问题的燃尽图，上面的出现了工作超期，而下面的则出现了工作提早完成，这都是不健康的sprint，团队需要立刻进行调整。
[img]/upload/attachment/75856/fa6b4338-a436-384e-879e-932ca19f6e49.png[/img]

[b]2.[/b]没有按照重要重要性来安排工作的sprint
[img]/upload/attachment/75860/15b25110-e1ba-38a1-a958-26ceae42ed1b.png[/img]

[b]3.[/b]过多的未计划条目
[img]/upload/attachment/75862/5518c5cd-676e-3db8-bef2-57f554e755f4.png[/img]


如何更新任务板？
当估算与实际工作时间产生差距的时候怎么办？很简单，像这样:
[img]/upload/attachment/75864/127c423f-fb29-3cff-a45a-b93bdaa2e486.png[/img]


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