[Scrum对话1]橄榄球和软件开发有什么关系？

真正的大师，给我们讲述一个高深的理论的时候，往往让你感觉不到他是在给你讲一个理论，更像是在讲故事，深入浅出。
大学的时候，曾经遇到一位讲《政治经济学》的教授，当时大家听他的课，着迷到一定要占座，这样好坐到前面几排。
工作后，读了《最后期限》，再次产生这种共鸣。几年前，读了《TOC》系列后，就再没发现这样的大师。

今天，偶然遇到了这个Scrum对话系列的网文，该文作者通过对话的方式介绍了在微软软件开发中一种流行的项目管理方式。万幸！终于又让我碰到了一位大师！

---敏捷精灵

马特里：争球？你是说要我们的开发团队成员拿只橄榄球在走廊上相互冲撞吗？

美芬；"争球（scrum）" 是一种符合敏捷开发模式的敏捷的项目管理方式。她的基本流程就是先建立一个产品"订单"(backlog)，做一个“冲刺”(sprint)计划，执行它，每天开会讨论它，定期演示工作成果，对上一阶段工作做反省，接着再重复以上流程。

马特里一直以来在思考如何将敏捷开发原则应用到整个项目计划中去。

马特里：我们上次谈了敏捷开发，这次我试着想如何将她运用到管理一个项目中去。我们曾经聊过用测试驱动开发方式(test-driven development)来作为开发模式，但是整个项目的计划该怎么办？有什么针对项目计划的敏捷方式吗？

美芬：是的，实际上，有一个非常著名的敏捷项目管理方式，她的名字就叫“争球（scrum）”

马特里：“争球（scrum）”这不就成了一个橄榄球队了吗？橄榄球和软件开发有什么关系阿？

美芬：恩，没有护垫，很多人会受伤。

马特里：哈，美芬也有幽默感了。我一直以为你唯一好玩的地方就是你的发型了。

美芬：我的发型怎么啦？！没关系。不管怎样，Scrum是一种敏捷的项目管理方式，她遵循我们上次谈到的敏捷原则。简而言之，短时间的迭代，不断的改善和反馈，并且相互合作。她是一种简单，轻量级的流程，能带来很多好处。

马特里：那大家都要带只橄榄球在走廊上跑来跑去吗？

美芬：不是必需的哦，但是你要是感觉这样做能提高工作效率的话，那就这么做好了。慢着，我想了想还是不要做的好。或许这样做不利于大家的健康。我有很多Scrum的经验，感觉用它来管理各种类型的项目都超好。

马特里：这种敏捷开发确实听上去挺酷的，有点好处。好吧，那么我会问，我很好奇我们是怎么使用它的。什么是“Scrum”。

美芬：Scrum其实就是用敏捷的方式来管理项目。她不是关于如何开发程序。首先，我们来看看Scrum是如何符合我们先前提到的敏捷开发原则的：
保持简单：Scrum本身就是很简单轻量级的流程，她能使我们的开发流程简单化。

接受变化：Scrum鼓励将工作细分成小块。我们关注的是一小段一小段时间，但是在这些时间段的中间我们可以重新安排我们工作的优先级。

不断迭代：我们需要在小于30天的一次次迭代中构建应用程序。

不断的反馈和改善：在每一次迭代的末尾，我们总是回顾我们以前是怎么做的，并且思考我们下次可以做哪些不同的事来改善流程。

协作：Scrum强烈鼓励团队成员的协作和沟通。如果没有这些，Scrum就一点用都没有。

减少浪费：Scrum帮助我们识别做那些只对客户或者团队有价值的事情。

马特里：好，我已经记住了这些原则。你还是没有谈得很详细。我应该怎么实施Scrum?

美芬：Scrum可以分为好几个关键步骤。在此之前，我需要讲一下几个关键的定义。
产品"订单" (product backlog)：你 可以把产品订单想象成为你想构建产品所需做的所有事情一个高层次的，按优先级排列的列表。列表中的内容可以是类似在极限编程中使用的用户故事，或者就是一 行行简单的功能说明。这里面重要的部分是工作的优先级。当你从这张列表中抽出一项项的工作任务时，你总是挑到的是最重要的任务。

"冲刺"（sprint）：一个sprint就是一小段迭代的单元时间，最长是30天。每一个sprint都有一个目标和他对应。

"冲刺"订单（sprint backlog)：就是一张sprint的工作任务列表。一个"冲刺"订单开始于产品订单的一些任务以及在此之上细分的一些更具体的任务，每一个任务都应该有一个明确的“完成”的定义。

产品负责人：这个人是负责维护产品订单和定义功能优先级的。产品负责人通常在一个sprint实施过程中处于配角的地位。

马特里：你现在讲的，对我来说，太技术了。这么多的新名词有什么用？为什么不来点简单的像“功能列表”之类的词？这样不就更加符合敏捷的原则吗？

美芬: 恩。。不知道该说什么。我猜“产品”强调的是列表的长期性，“订单”就是我们还没有得到的东西。有道理吧。有了"sprint"，我们就可以跑一个马拉松，但是在休息点和休息点之间，可以来几次冲刺（就是迭代）。

马特里：好吧，好吧。我会习惯的。那流程是怎样的呢？

美芬：非常简单。就是这样的。
1.构建一个产品的订单（product backlog)。
2.计划一个冲刺(sprint)。
3.执行它，每天开会。
4.演示完成的工作。
5.做反省工作。
6.休息一下，然后重复。

马特里：就是这样吗？听上去好简单。显然我需要这些步骤的更细节的一些东西。

美芬：你要我做什么我就做什么。

马特里：那给我一个汉堡吧。

美芬：不是你要我做的一切我都会做的！让我们回到Scrum。我先给你很快的介绍一下这个流程中的每一步。然后在以后的交流中，我们可以详细讨论一下每一步的一些最佳做法。觉得怎么样？

马特里：听起来比灌肠好点。继续吧。

美芬：当你构建产品订单时，你的团队和你的产品负责人决定哪些功能是对客户重要的，同时要创建一个按优先级排列的所有功能的列表。最重要的功能出现在列表的最前面。

马特里：这需要一些远见性的思考，这样不就和敏捷的原则相悖吗？

美芬：这时候的计划是非常非常高层次的。他只是我们对户从今天开始想要的那些功能的粗略的认识。明天认识就有可能变化。下一步就是要计划“冲刺”。我们从产品订单中抽出优先级最高的项目，然后计划将这些项目完成。那么我该抽多少呢？你认为在这次迭代中你可以做多少你就抽多少。我们接着将产品订单细分成冲刺订单的一些具体任务并且开始执行它们。

马特里：酷。听上去挺简单的。但是我怎么知道我下一步要做什么？

美芬：每个人都会在计划阶段被委派一项任务，所以他们都应该清楚自己该做什么。在这个之后，当你完成了一项任务，你就可以去抽下一个还没有被委派，且是最高优先级的任务。我们有了这样一个计划后，我们就执行它，每天开会。我们会过一遍sprint的任务单，每天我们都会估计在某一任务上还要做多长时间。我们应该客观实际的估计每项任务到底需要多长时间完成，如果他们比计划的花的时间长，我们就从最低优先级的任务开始取消任务。我们每天都会开一次碰头会。

马特里：好吧。现在你是真疯了。你每天都想开一次碰头会。一周开一次已经够痛苦的。I think you have been into the glue again.

美芬：我承认。听上去很疯狂。但会议很短，对5个人的小组来说只要花10来分钟。如果你喜欢的话，我会谈怎么让会议尽量短。在sprint完成之后，我们会展示一下完成的工作。这时候的短会会让每个成员庆祝自己完成的工作，并且让负责人知道完成的工作。

马特里：我猜想客户，或则客户的代表如产品负责人会出现在那里，对吧？他们会对完成的工作很好奇。

美芬：当然啊。每个和项目有重要关系的人，包括客户，都应该参加到演示过程中。一个sprint是以反省作为结束的。对于小组而言，这是一个来审视我们什么做的好（应该继续做），和决定下一次应该做些什么不同来改善的好机会。

马特里：哈，不断的提高。真是一个很直接的流程。我喜欢。

美芬：在这一个sprint做完之后，你需要重新设定一次订单，然后开始留一段计划的时间，然后就是从新再来，为客户创造更多价值。

马特里：好吧。让我回去和我的小组成员试试，做一个两周的sprint。或许你和我可以过几周来做一次反省，到时候你可以给我一些建议。

美芬：哇，看太阳从西边出来了。你真的需要我的帮助吗？！？

马特里：。。。。。。

美芬观点：正如步骤中第六点所言，在“冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，赶一些非sprint计划中的事情。这段时间是一个很好的用来解决一些技术或者工具问题的机会。你会发现你慢一下后，会变得更有效率。这就是为什么叫“sprint”的一个理由，你不可能无休止的冲刺。