产品特色

内容简介

　　短短几年时间，Scrum跃升为敏捷优选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书结合故事、模型和成功秘诀三大要素，透彻讲解确保Scrum取得成功的基本要素。全书4部分30章。在简单介绍Scrum知易行难之后，在一、中阐述导入Scrum之前的准备工作。接着，二、重点介绍实战基础。三、提出急救包的概念，讨论如何使每日站会富有成效，如何提出Scrum的第四个问题，如何让人们在结对编程时保持专注，增加团队新成员时应该怎么办，发生文化冲突时应该怎么办，冲刺应急过程等。四、则锁定八大主题，重点介绍高级生存指南。在附录中概述Scrum框架，以帮助读者快速入门。
　　针对如何用好、用巧这个看似简单的框架，本书结合故事、模型和成功秘诀三大要素，透彻讲解确保Scrum取得成功的基本要素。本书适合打算实现敏捷转型并导入Scrum的所有人员阅读，比如开发人员、架构师、测试人员、经理和项目负责人，是帮助他们顺利度过Scrum理想参考书。
　　

作者简介

　　Mitch Lacey，敏捷实践者和培训师，Mitch Lacey & Associates公司创始人。他拥有16年项目管理经验，现在的主要身份为敏捷讲师和敏捷教练，指导过许多计划性项目和敏捷项目。在微软工作期间，Mitch曾运用敏捷相关知识成功发布了Windows Live里的核心企业级服务。Mitch在微软的第一个敏捷团队由Ward Cunningham（维基之父、极限编程的创始人之一）、Jim Newkirk（nUnit创始人）和David Anderson（看板倡导者）所指导。他是认证Scrum讲师(CST)和PMI项目管理专家(PMP)，也经常出席全球大会发表主题演讲。他是Scrum联盟和敏捷联盟的委员会成员，曾经担任Agile 2012大会的主席。

　　傅勃，瀑布和敏捷的见证者和实践者。从事多年软件开发工作之后，在一个CMMI五级的组织里开始承担项目管理工作。经历过混乱到依赖严格流程来控制软件开发过程的转变，有成功，也有失败，因而也对传统软件开发与项目管理的过程与方法有诸多存疑和困惑。到2007年，初次接触Scrum之后，感觉曙光乍现，尽管最初有些难受，但另一扇希望之门已经缓缓开启。到2009年年初，组织内部已经全面推广学习、尝试敏捷开发实践（Scrum与XP）。

目录

第1章 Scrum：知易行难
故事
Scrum
什么是Scrum
实施Scrum
Scrum适合我吗
变化是困难的
实践与集成
新的现状
成功秘诀
引用
第Ⅰ部分 战 前 准 备

精彩书摘

　　第1章
　　Scrum：知易行难
　　Scrum优雅得具有欺骗性。它是最容易理解的框架之一，同时也是最难以实施好的框架之一。我说“实施好”是因为Scrum固有的简单性容易诱导我们认为使用Scrum很容易，然而在现实中可能需要很多年才能把它做好。Scrum似乎与我们过去多年以来瀑布式开发中所习得的完全对立。显而易见，我们需要一些时间来忘记我们的旧习惯，并调整到一个新的现实中。
　　在本书的附录中，我解释了Scrum的机制。如果你对Scrum以及如何使用它还不熟悉的话，我建议你从那里开始。如果已经了解Scrum的一些背景，你就知道它的机制是十分简单直接的。事实上正因为它如此简单直接，才导致很多人误以为自己已经掌握了Scrum，可以立即开始修改Scrum以更好地适应他们的现状。太过寻常的是，他们反而发现自己迷失了方向或者受了伤而需要帮助，这就是这本书的作用。后面的故事阐述一点：如果不能理解或者缺乏这些使Scrum有效的核心敏捷概念中的坚实基础，应用Scrum会很快陷入困境。
　　故事
　　Jeff是一名敏捷教练，他在一家大型软件公司内部帮助团队应用Scrum。一天，他收到部门的项目群经理Suzy的一封电子邮件。
　　“Jeff，请帮个忙。我们已经做了六个月的Scrum，但是我们的代码质量还是没有像我希望的那样提高。我想我们需要你过来和我们讨论结对编程。下周一就是我们计划周的开始，你能来吗？”
　　Jeff坐在椅子上。讨论结对编程相对简单，他可以带上他的朋友Julie，一个优秀的开发人员和经验丰富的敏捷实践者，没有问题。但是电子邮件中的两个字一直浮现在他的脑海中，计划周？Scrum要求有两个Sprint计划会议，每个不超过四个小时。这个团队要做一周？他感到不仅是结对编程，还有其他更多的事情需要他去做。下周一会比较有趣。
　　星期一，Jeff和Julie到达会议现场，发现Suzy和她的八人团队一起已经在会议室里就位了。Suzy做了一个简短的介绍以后，Jeff和Julie进行自我介绍，然后开始就Suzy告诉他们的代码质量问题进行询问。
　　团队很快就开始回答。首席测试员Mike首先说道：“我们的代码质量差是因为我们没有时间做测试。开发人员直到我们四周Sprint的最后一天还在写代码。‘编码与测试Sprint’应该既做编码，也要做测试。但是我们的测试要么被挤到Sprint的末尾，要么就演变为‘集成Sprint’。”
　　Julie打断他说道：“抱歉，Mike，你刚才说‘集成Sprint’？”她看着Suzy，Suzy点点头。
　　“哦，我还没有解释我们的修改，是吧？”Suzy说道，“我们知道Scrum要求每四周有一个发布，但是对于我们做的这种工作，这是不可能的。我的意思是，在我们尝试Scrum之前，我们努力按照季度来发布，这完全是一场灾难！所以我们所做的就是修改Scrum使其更好地融入我们的流程和现实。”Suzy走到白板前开始在上面写。
　　“首先，我们有一周来做Sprint计划；然后在四周的实际Sprint中，开发人员写代码，测试人员写测试用例；在这之后，我们就做集成，然后部署。当然，我也常常增加一周作为缓冲应急，以防万一。”Suzy说道。
　　她话音刚落就已经在白板上写好了以下内容。
　　Jeff和Julie相互看了一眼，然后又看着Suzy。团队的其他人则显得很无聊。Jeff问了一个很显然的问题：“Suzy，你们的Sprint真的是八九周吗？”
　　“对，”Suzy回答道，“你觉得很意外。我知道这不是正宗的Scrum，但这对我们是适用的。我想我们可能还需要增加一周，你知道吗，写规范和测试计划，把它加进去还有点麻烦。现在我们是在缓冲的那周来做，但是我真的讨厌占用我们的缓冲。”
　　“好，我们过会儿再讨论这个，”Julie说道。她看着Jeff，Jeff举着手好像在说：“我们该怎么办？”Julie继续问道：“Mike，你说你们没有时间做测试？”
　　Wyatt抢在Mike前面说：“别听Mike的。他们有很多的时间来做测试。我们才永远没有足够的时间。我们每个Sprint都费尽力气尽可能完成我们所能完成的代码。为什么我们需要整整四周？真的就需要这么长时间。”Wyatt看着Mike接着说，“自从我们开始使用Scrum以来，你和所有测试人员就一直做抱怨你们没有时间做测试。也许Scrum才是问题根源。”
　　Jeff和Julie交换了一下眼神。
　　Suzy插话说：“各位，我们在这里不是抱怨Scrum的。我们是来提高代码质量的。”她暂停了一下，深深吸了一口气，“我说这个已经有六个月了。”她对Jeff和Julie说并很快无奈地翻了翻眼珠。
　　Jeff点点头说：“我知道你很沮丧，我也知道Mike和Wyatt也很沮丧。我能够和团队深入一点讨论这个问题吗？看看我能不能找到问题的根源？”Suzy热切地点点头。
　　Jeff以他标准的第一个评估问题开始：“好的，Scrum和极限编程（XP）都要求每日有检查点。在Scrum中，就是每日Scrum站会。你们怎么评价你们的每日Scrum站会？”Jeff对团队提问。
　　Mike笑道：“每日会议？你开玩笑吗？我们没有时间做这些。我们每周开两次会，一共一个小时，这已经很花时间了。”
　　“好的，Mike，给我讲讲你们是怎么开这些会议的。”Jeff问道。
　　“首先，我们每次开会都说同样的事情，开发人员说他们在完成任务，我们说我们在写测试用例，这是大新闻吧。然后我们大概花20分钟左右的时间对缺陷列表进行分类，总结来说就是把缺陷列表挨个过一遍，分为‘设计造成的’和‘在下一个Sprint修改’。当然，我们从来就没有修改这些缺陷。这纯粹就是功能失调所引起的混乱。”Mike说道。
　　看得出，Suzy很生气，所以Jeff也给机会让她来说。
　　“谢谢Mike。Suzy，你的看法是什么呢？”
　　“Mike说对了一件事情。每日站会的确对我们不适用。我们只有每两天开一次会。我的日程太忙了，没有办法每天开会；而有些团队成员还在其他的项目上。我知道这不是理想的状况，但是我们只能这样做。让我头疼的是，即使我们每周开两次会议，团队仍然和我争论，他们认为负担太重。你听见了刚才Mike是怎么说的。他们都抱怨这些会议、时间安排以及没有足够时间！但是我也无法拒绝管理层要求我们更快发布。更何况，就像我一直告诉他们的那样，这是我的项目。我制定计划，我组织团队。告诉他们，Jeff，我是ScrumMaster。他们应该按照我说的去做，对吧？”Suzy迫切期待着Jeff的肯定。
　　Jeff不置可否地耸耸肩，保持沉默。他开始意识到他们对Scrum的了解是多么的贫乏。他看了一下Julie，给她一个表示他们还不懂的表情。Julie轻轻点头回答。Jeff继续他的评估。
　　“好的，我听见了。我们先讨论我们现在的问题。看上去一个潜在的问题是你们的每日站会没有每天都开，没有生产力，持续时间太长。我们可以纠正它。让我们先把这个问题放一放，把我们的思考过程提高一个水平。告诉我，你们为什么会采用8周的Sprint？”
　　Wyatt发话了：“我在这里已经有十年了，我见过这里所有流行过的东西，它们瞬息即逝。但是这次我是一个盲从者，我真的认为Scrum可能不一样，这是不是有点不可思议！整个事情起源于管理层要求我们更快发布。我们已经做到了按季度发布。让我告诉你，从年度发布到季度发布，真的很困难，但是我们实现了。但是对于管理层，这还不够快，是吧？”Wyatt会儿停了一会儿，环视了一下会议室，希望得到回应。
　　他继续说道：“所以，有一天我和Suzy坐在一起吃午饭，刚好遇到在另外一个部门工作的我的一个同事。他告诉我们他的团队正在使用Scrum，他们如何每四周就交付一次，而且他们如何高兴。他说他们突破了质量的天花板，管理层已经很多年没有这样满意过，客户也很欣喜。你知道吗，这个人和我一样是个怀疑论者。所以我想如果他都说Scrum有效果，就肯定有效果。Suzy和我就花了一个下午的时间向他学习Scrum。Scrum看上去非常简单，但是也有一些问题。首先就是那些每日站会，谁有这么多时间呢？我们就简单改为每周两次。然后四周为一个周期显然对我们不适用，毕竟我们几乎不能做到以季度为周期，所以我们决定加倍成为八周为一个周期。以此为基础，我们就把我们的工作流分解到八周里面，就是把所有的事情都压缩下来。毕竟，Scrum只是另外一种增量开发的流程而已。”
　　Jeff和Julie又相互看了一眼。
　　Wyatt继续说：“我看见你们的表情了。但是我告诉你们，我们了解自己的团队和产品。原汁原味的Scrum我们可能用不上，所以我们做了任何一个软件团队都会做的事情，那就是根据我们自己的需要对Scrum进行修改，按照最符合我们过去做事方法进行组织。”
　　“对，”Suzy确认道：“我的意思是，Scrum是项目经理管理工作的一种方法，只不过周期更短而已。”
　　Jeff往后坐了一下，他准备的评估问题不是为这种情况而设计的，他还不确定现在该说什么。Julie挺身帮助他：“你们有一个通用的‘完成定义’吗，Wyatt？”
　　“我们当然有啊。第一周后，我们有设计评审会；然后在第五周结束的时候，我们有代码完成的里程碑；在集成结束的时候，我们有完成测试和集成。一旦我们完成这些里程碑，我们就发布上线。这真的不难理解。”Wyatt说道。
　　“对，这很简单，我明白。”Julie安慰道，“团队，刚才Wyatt、Mike和Suzy解释了你们的流程。我的理解是你们有每周两次的站会，八周（有时候九周）的Sprint，而且在特定的关键时期也有检查点，这样你们就知道你们完成了。这样的工作方式你们感觉怎么样？你们感觉工作有乐趣吗？代码质量提高很多了吗？”Julie问道。
　　“嗯，还不错，”Wyatt回答道。
　　“不错？！”Suzy问道，“简直糟糕透了。”
　　“这样糟糕不是我们的过错！我们试图做测试，但是就像我讲的那样，我们没有时间做！”Mike高声叫道。团队的其他人盯着桌子，没有参与这个争论。
　　“Mike，虽然我可以，但是我没有指责你，没有。真正的问题是Scrum，”Wyatt说道，“这是一个愚蠢的流程，它根本就不适用。”
　　“不要又讲这个，”Suzy说道，“这个问题我们要争论多少次？每次回顾会议我们都在争论这个问题。”
　　“回顾会议？”Wyatt插话说：“这只是一个名字听着好听的两天一次的垃圾会议。回顾会议不能改变任何事情。Scrum不能改变任何事情。我收回这句话。Scrum的确改变了一件事情，就是使得我们都很悲摧。”
　　“Wyatt，使用Scrum也是你的主意。既然你所做的就是破坏这个流程，当初你为什么要首先发起呢？”Suzy激动地问道。
　　Jeff站出来了。现在应该是停止提问并开始让团队面对真相的时候了。
　　“瞧，这不是那一个人的过错，也不是Scrum的过错。对于我来说，我相信Julie也会同意，看上去你们并没有真正在做Scrum。你们所做的和过去做的是一样的，只是压缩到八周的一个周期中。你们把这个就称为Scrum。”
　　Wyatt和Suzy准备开始争辩，但是Julie举手制止了他们。“让我问一个问题，是问团队的。Wyatt、Suzy和Mike，请你们不要回答。”Julie在先看了看会议桌团队的每一个人，然后继续说道，“这种新的工作方式使得你们的工作更糟糕呢，还是一直就是这样，可能只是没有这么明显？”Julie问道。
　　每个人都低着头，看得出他们陷入了沉思。
　　“过去也很糟糕。”会议室后面传来了一个声音。
　　“对，”另外一个团队成员说：“我只是没有意识到过去有这么的糟糕。”
　　随着团队的自我觉醒开始萌芽，会议室陷入一阵沉寂。
　　Wyatt叹气一声说道：“你说的对。过去也没有比现在好多少，只是没有现在这么明显。我们原来是每个季度感受一次痛苦，现在是每八周感受一次。”
　　Mike插话说：“知道吗？看看过去的六个月，我们发现了很多应该而且能够解决的问题，但是我们什么也没有做，真的没有。”
　　Suzy打断了他。
　　“伙计们，我真的累了。我们能够推迟几天再来讨论吗，下周？”她问道。
　　团队点头同意，他们也累了。
　　Suzy离开会议，意识到事情很糟糕。她花了一个周末以及下一周的前半段来思考如何推进工作。她召开了另外一个会议并把Jeff和Julie也邀请回来，她希望以此为团队确定一个新的基调。
　　“各位，我感到很抱歉。”她以此开始会议，“我知道事情有些糟糕，但是我不知道是那么糟糕。我原来是请Jeff和Julie来帮助我们做结对编程，我以为那样可以解决我们的质量问题。显然，我没有意识到我们真正的需求，为此我向大家道歉。我们把一切都搞错了，不是Scrum失败了，而是我们错误使用了Scrum。我想问问你们所有人，我们是不是可以重新开始，我觉得Jeff和Julie可以帮助我们具体实施。”
　　Wyatt点点头看着团队说：“我知道我有时候有点犯浑。我在这里的时间太长了，以至于我有时候都觉得我拥有这个地方，但是我没有。我知道我可以做得更好，我会停止抱怨，真正尝试Scrum，但是有一个条件。”
　　“什么条件？”Jeff问道。
　　“就是我们要做就做真正的Scrum，”Wyatt说道：“不要再修改Scrum。而且我们需要一个教练来告诉我们应该怎么做，这并没有看上去那么容易。”
　　Mike抬头说：“我也有一个条件。我们要修复那些缺陷，真的修复它们，而且不能为此相互指责。”他把手伸向Wyatt，“我们能做到吗？”
　　Wyatt看着Mike，看着他的手，然后握手说：“我觉得我们可以迎接挑战了。如果Jeff还会帮助我们，这就行了。”Wyatt玩笑式地朝着Jeff挤眉弄眼。
　　团队都笑了，他们作为一个团队很久都没有这样开怀大笑了。这是一个好的开始。他们围绕着会议桌，各自口头承诺使用Scrum，这次真正使用Scrum。过了一会，Jeff和Julie离开会议，他们感觉完成了很多工作，但是还有更多的事情等着他们去做。
　　“你准备怎么做，Jeff？”Julie问道。
　　“我准备做的第一件事情就是教他们Scrum是什么，包括它的价值、框架以及他们需要经历的思维方式的转变。”Jeff回答道。
　　“不要忘记告诉他们Scrum是怎么管理风险和如何帮助发现问题的。”Julie说道。
　　“肯定的。我会从基础开始并随着问题的出现逐个解决。肯定会经常出现困难，但是他们能够做到。没有痛苦，就没有收获，对吧？”
　　Scrum
　　Scrum看上去很基本，但是很多人不能明白的是，要做好Scrum，就必须从根本上改变原来开发软件的方式，而这并不容易做到。你会挣扎，你会遇到障碍。我们故事中的团队以其所经历的艰难历程发现了这一点。如果你拿起这本书，你可能也已经意识到了这个问题。为了理解为什么这么简单的事情做起来居然可以这么困难，让我们深入探究一下Scrum。
　　什么是Scrum
　　《危险边缘》（Jeopardy） 是我最喜欢的电视游戏节目之一。我一直希望有一个类似的关于软件开发的版本，其中有这样一些类别：方法和框架、导致软件故障的常见原因、著名的软件架构师以及聪明人说的傻话。我可以想出一大堆符合这些类别的问题，比如，“说出是谁，据说他说过‘对书呆子要友善’；‘你可能到头来会为我工作’。”我设想在“方法与框架”这个类别里面，可以有这样一个问题：“说出一个美式橄榄球的术语，这个项目管理框架可以每两到四周就交付可工作的软件。”一个可以接受的答案，当然是以问题的形式，就是“什么是Scrum？”
　　那么究竟什么是Scrum？Scrum不是一个方法或者一套工程实践。它其实是一个轻量级的框架，设计初衷是管理软件和产品开发。Ken Schwaber和Jeff Sutherland [Schwaber 01]是这样描述的：
　　Scrum是一个框架，在这个框架中人们可以解决复杂的适应性问题，同时以高效生产力、创造性方式交付价值最大化的产品。Scrum有以下三大属性：
　　？ 轻量的
　　？ 简单易懂的
　　？ 十分难以掌握的
　　Scrum是一个流程框架，从二十世纪九十年代早期就被用来管理复杂产品的开发。Scrum不是产品制造流程或者技术；相反，它是一个框架，在这个框架里面，你可以使用各种流程与技术。Scrum把产品管理和开发实践的效率清楚展现出来，以便于后期持续改进。
　　Scrum依赖于固定节奏的迭代周期，称为Sprint。每个Sprint以计划会议开始，以对潜在可交付产品的演示而结束。Scrum的特征是团队内外的反馈和透明。它的短周期和协同的本质使其相当适用于快速变化或者有紧急需求的项目。
　　Scrum建立在五个核心价值之上，它有三个不同的角色、三个工件以及三四个会议。关于Scrum机制的更多细节，可以参见附录“Scrum框架”。
　　实施Scrum
　　尽管Scrum看上去可能很容易实施，它实际上很有挑战性。为什么？因为它的实施不仅局限于设置好正确的机制，然后按一下按钮。正确实施Scrum需要团队愿意做出以下改变。
　　？ 理解Scrum的价值观。
　　？ 往往要经历巨大的思维方式的转变。
　　？ 准备变化的发生并适应变化。
　　？ 处理新暴露出来或新冒出来的问题。
　　？ 引入敏捷工程实践。
　　Scrum的基本价值观
　　任何有使用价值的框架都是建立在一些原则与价值之上的。每一个原始的敏捷实践：XP、Scrum、DSDM、Crystal、FDD以及看板和精益，都有一套核心价值。这些价值给我们指明方向；在我们困惑的时候进行澄清；最重要的是，帮助我们理解我们为什么要这样做。就像你从前面开篇故事中读到的那样，这个团队试图使用Scrum，但是他们不理解为什么要这么做。他们 Scrum实战：故事、模型与成功秘诀 电子书 下载 mobi epub pdf txt

敏捷开发的实战原理。

一直想买的，终于入手了。对于带项目带团队很有参考价值哦！

做敏捷必备书籍，很多丰富的实例，具有代表性。

书脊处有破损 有些页的印刷好像还是歪的 纸张还可以 还没阅读 不知内容如何

很好，准备好好学习学习。敏捷软件开发，未来的趋势。

给团队买的书，都是大家推荐阅读的内容，书本身质量不错。

书脊处有破损 有些页的印刷好像还是歪的 纸张还可以 还没阅读 不知内容如何

还没看。。。。

书写的不错 系统学习了一把