作者：(瑞典)克里伯格（Kniberg,H.）
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
硝烟中的Scrum和XP：我们如何实施Scrum试读：
序1——Jeff Sutherland
开发团队需要了解一些Scrum的基础知识。该怎样创建产品backlog，对它进行估算？怎样把它转化成sprint backlog？怎样管理燃尽图（burndown chart），计算团队的生产率（velocity）？Henrik的书可以用作一些基础实践的入门指南，帮助团队从试用Scrum中成长，最终成功地实施Scrum
当前，良好的Scrum执行过程对需要风险投资的团队正变得日益重要。我现在是一个风险投资团队的敏捷教练；为了帮助他们达成目标，我给出的建议是：只给敏捷实践实施情况良好的敏捷公司投资。团队中的资深合伙人（Senior Partner）在向所有的待投资企业问同一个问题：你们是否清楚团队的生产率？目前他们都很难做出明确的答复。要想在将来得到投资，开发团队就必须清楚自己的软件生产率。
为什么这一点如此重要呢？如果团队不清楚自己的生产率，那么产品负责人（product owner）就无法用可靠的发布日期来创建产品路线图。如果没有可靠的发布日期，公司的产品就可能会失败，投资人的钱就有可能化为乌有！
无论公司规模大小，创办时间长短，或者是否有资金注入，这个问题都是它们所要面对的。在最近在伦敦举办的一个大会上，我们曾讨论过Google内部的Scrum实施状况，当时的听众有135个人，我问他们中有多少人在使用Scrum，只有30个举手。我又接着问他们是否在根据Nokia标准来做迭代开发。迭代开发是敏捷宣言的基本原则——在早期频繁地交付可工作的软件。Nokia用了几年时间，对上百个Scrum团队的工作进行了回顾，总结出迭代开发的基本需求：
* 迭代要有固定时长（被称为“时间盒”，即timebox），不能超过六个星期；
* 在每一次迭代的结尾，代码都必须经过QA的测试，能够正常工作。
使用Scrum的30个人里面，只有一半人说他们遵守了Nokia标准，符合敏捷宣言的首要原则。我又问他们是否遵守了Nokia的Scrum标准：
* Scrum团队必须要有产品负责人，而且团队都清楚这个人是谁；
* 产品负责人必须要有产品backlog，其中包括团队对它进行的估算；
* 团队必须要有燃尽图，而且要了解他们自己的生产率；
* 在一个sprint中，外人不能干涉团队的工作。
仅有的30个实践Scrum的在场人士中，只有3个能够通过Nokia的Scrum测试。看来只有这几个团队才有可能在将来得到我的风险投资伙伴的钱了。
如果按照Henrik列出的实践执行，那么你就会拥有如下产物：产品backlog、对于这个backlog的估算、燃尽图；你会了解团队的生产率，并掌握在切实有效的Scrum过程中所包含的众多基础实践。这些收获就是本书的价值所在。你将会通过Nokia的Scrum测试，对工作的投资也会物有所值。如果你的公司还正处于创业阶段，也许还会收到风险投资团队的资金注入。你也许会塑造软件开发的未来，成为下一代软件产品中领军产品的创建者。Jeff Sutherland, Ph.DScrum共同创始人
序2——Mike Cohn
Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的部分工作成果。迭代要短，有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。实际上，Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错，但是他们明白：要投入实践中，动手去构建产品，这才是找出错误的最好方式；不要只是停留在理论层次上对软件进行分析和设计。
注重实践而非理论研究，这正是本书的独到之处。Henrik Kniberg很清楚，初涉门径的人更需要这种书籍。他没有对“什么是Scrum”进行冗长的描述，只是给出了一些网站作为参考。从一开始他就在讲他的团队如何管理产品backlog，并基于它进行工作。接着他又讲述了成功的敏捷项目中包含的所有元素和实践。没有理论，没有引用，没有脚注，没有废话。Henrik的书没有从哲学角度上分析为什么Scrum可以工作，没有分析为什么你可能会尝试不同的选择。它描述的是一个成功敏捷团队的工作过程。
所以本书的副标题——“我们如何实施Scrum”——才显得格外贴切。这也许不是你实施Scrum的方式，这是Henrik的团队实施Scrum的方式。你也许会问：“为什么我需要关心别的团队怎样实施Scrum？”这是因为通过关注其他团队的实施过程，尤其是成功的案例，我们就可以学到更好的实施方式。这不是，也永远不会是“Scrum最佳实践”的罗列，因为团队和项目的真实场景要比其他一切都重要得多。我们应该了解的是优秀实践及其应用范围，而不是最佳实践。在读过足够多的成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻。
Henrik提供了很多优秀实践，还有对应的使用场景；通过它们，我们能够更好地掌握如何在自己的项目中，在战壕里使用Scrum和XP。Mike Cohn《用户故事与敏捷方法》与《Scrum敏捷软件开发》作者
译者序
孙子兵法有云：兵无常势，水无常形，能因敌变化而取胜者谓之神。很多人都向往用兵如神的境界，想必也知道读万卷书不如行万里路，纸上谈兵的故事更是耳熟能详；但偏偏不能举一反三。
且看风清扬的一段话：“……你将这华山派的三四十招融会贯通，设想如何一气呵成，然后全部将它忘了，忘得干干净净，一招也不可留在心中。待会便以什么招数也没有的华山剑法，去跟田伯光对打。”如果有人说，既然“无招胜有招”是武学的最高境界，那干脆什么招数都不要学，拿把剑乱挥乱舞，处处破绽，也就处处无破绽，便是天下第一了。听到这话的人肯定会笑他太缺心眼。
我在这里不想解释为什么上面那种说法缺心眼，因为只要不是缺心眼的读者就肯定能够理解说他缺心眼的理由。但有句话叫 “不识庐山真面目，只缘身在此山中”。对待离自身尚远的事物时，人们可以把它分析得淋漓尽致；但到了自己身上，就往往成了当局者迷，旁观者清。譬如青春，譬如爱情，譬如敏捷软件开发。
我想，这本书的读者大概都知道，现如今敏捷开发是何等炙手可热，但潮流一起，跟风者势必有之。虽然没法在这篇短短的序中逐一批驳，大家也可以仔细思索一下，在周边是否存在缺心眼的做法。比如，把bad smells背下来以后就大谈重构的好处；版本控制、缺陷跟踪、配置管理等一无所有，便一味追求持续集成；单元测试还不会写，就疯狂宣传测试驱动开发……这些都还好，只要没有把敏捷等同于迭代，等同于又敏又捷，又快又爽；这也无所谓，只要没有在实际上对敏捷一无所知、对想要达到的目标不甚了了、对项目中存在的问题视若无睹的情况下宣传敏捷、推行敏捷就可以了。但如果前面那些条件都吻合，最后这一点还能不满足么？
其实，敏捷不是说出来的，是干出来的。
是为序。李剑
前言——嘿，Scrum 成了!
Scrum成了！至少对我们来说它已经成功了（这里指的是我当前在斯德哥尔摩的客户，名字略过不提）。希望它对你们也一样有用！也许这本书会对你们实施Scrum的过程有所助益。
这是我第一次看到一种开发方法论（哦，对不起，Ken，它是一种框架）可以脱离开书本成功运作。它拿来就能用。所有人——包括开发人员、测试人员和经理——都为此而高兴。它帮助我们走出了艰难的境地，而且让我们在剧烈的市场动荡和大规模的公司裁员中依然能够集中精力在项目上。
我不该说我为此感到惊讶，但实情确实如此。在一开始我大致翻了几本讲Scrum的书，它们把Scrum描述得挺不错，却给我留下了一种太过美好以致不太真实的感觉（我们都知道“某些东西看上去太好了……”这类说法的含义）。所以我没法不对它有点怀疑。但在使用Scrum一年以后，先前的零星疑虑早已烟消云散。我被它深深地震撼了（我们团队中的大部分人都和我一样），以后只要没有充分的理由来阻止我，我都会继续使用Scrum。
致谢
本书初稿完成仅用了一个周末，但很显然：那是一个超高强度工作的周末！投入程度高达150% :o)
感谢我的妻子Sophia和两个孩子Dave与Jenny，我那个周末扔下她们独自工作，她们对此表示了宽容；还应该感谢Sophia的父母——Eva和Jörgen，在我忙碌的时候，他们过来一起照看整个家庭。
同时，还应该感谢在斯德哥尔摩Crisp工作的同事，还有scrumdevelopment yahoo 讨论组的成员，他们一起校稿，提出了很多改进意见。
最后，我要深深感谢所有的读者，从你们长期的反馈中我收获颇丰。尤其要指出，能够通过本书点燃许多人尝试敏捷软件开发的热情，这让我感到特别开心！
第1章 简介
■
免责声明
■
撰写本书的原因
■
Scrum到底是什么
你即将在组织中开始使用Scrum。或者你已经用过了几个月。你已经了解了基本概念，读过了几本书，也许你还已经通过了ScrumMaster认证。先恭喜一下！
但是你仍会感到迷茫。
用Ken Schwaber的话说，Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。靠！
下面有一个好消息和一个坏消息。好消息是我即将和你们分享我使用Scrum的经验，还有种种恼人的细节。而坏消息是，这只是我个人的经历。你不应该完全仿照我的做法。实际上如果换个不同的场景，我也许就会换种实践方式了。
Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。
过去的一年中，我在一个大约40人的开发团队里面试验性地使用了Scrum。当时公司正处于困境，没日没夜地加班，产品质量低下，很多人都忙着四处救火，交付日期也一再拖延。公司已经决定了使用Scrum，但是并没有完全落实，剩下的部分就是我的工作了。在那个时候，对团队中的大多数人来说，“Scrum”就只是一个陌生的、时时能够从走廊上听到回音的时髦词汇；仅此而已，和他们日常的工作没有丝毫的关系。
一年过去了，我们在公司里从上到下都实现了Scrum。我们试过多种团队规模（3～12人）、sprint长度（2～6个星期）；定义“完成”的不同方式；不同形式的产品backlog和sprint backlog（Excel、Jira、索引卡）；多种测试策略、演示方式、多个Scrum团队的信息同步方式……我们还试验了XP实践——各种各样的每日构建，结对编程，测试驱动开发，等等；还试过把XP和Scrum进行结合。
这是一个持续学习的过程，所以故事尚未结束。我相信，如果公司能够保持做sprint回顾的良好习惯，他们就会不断得到新的收获，重新领悟到怎样在他们特有的场景中，恰如其分地应用Scrum。免责声明
这篇文档讲述的不是“正确”实现Scrum的方式！它只是表明了一种方式，是我们在一年内不断修正调整后的结果。你也可以认为我们的做法是完全错误的。
本文中所说的一切都是我个人的观点，不代表Crisp或者我当前客户的任何意见。因此我将避免提到任何特定的产品或者人名。撰写本书的原因
在学习Scrum的过程中，我读过Scrum和敏捷方面的书，浏览了许多有关Scrum的网站和论坛，通过了Ken Schwaber的认证，用各种问题刁难他，还花了大量的时间跟同事进行讨论。但在纷乱芜杂的信息中，我感到最有价值的就是那些荷枪实弹的故事。它们把“原则与实践”变成了……嗯……“如何真正动手去做的过程”，同时还帮我意识到（有时候会帮我避免）Scrum新丁容易犯的典型错误。
所以，现在轮到我做出一些回报了。下面就是我以Scrum为枪的战斗经历。
希望本书对有同样经历的读者起到抛砖引玉的作用，给我反馈，向我开炮！Scrum到底是什么
哦，对不起，你完全不了解Scrum或者XP？那你最好先去看一下这几个链接：
* http://agilemanifesto.org/
* http://www.mountaingoatsoftware.com/scrum
* http://www.xprogramming.com/xpmag/whatisxp.htm
要是你真没耐心去访问这些网站，也没关系。随便翻翻看看吧。大多数Scrum的相关术语都会在书中慢慢讲到，你会感兴趣的。
第2章 我们怎样编写产品backlog
■
额外的故事字段
■
我们如何让产品backlog停留在业务层次上
产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求或故事或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。
我们叫它故事（story），有时候也叫做backlog条目（事项）。
我们的故事包括这样一些字段。
* ID 统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
* Name（名称） 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
* Importance（重要性） 产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
* 我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？
* Initial estimate（初始估算） 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天”（man-day）。
* 问一下你的团队，“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
* 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）。
* How to demo（如何做演示） 它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果。”
* 如果你在使用TDD（测试驱动开发），那么这段描述就可以作为验收测试的伪码表示。
* Notes（注解） 相关信息、解释说明和对其他资料的引用等等。一般都非常简短。
我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。
通常我们会把backlog存放在共享的Excel文档里面（是为了多个用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。
基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放到了共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会导致锁操作或是合并冲突，这是最简单的方式。
但是基本上其他所有的制品都放在版本控制仓库中。额外的故事字段
有时为了便于产品负责人判断优先级别，我们也会在产品backlog中使用一些其他字段。
* Track（类别） 当前故事的大致分类，例如“后台系统”或“优化”。这样产品负责人就可以很容易选出所有的“优化”条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。
* Components（组件） 通常在Excel文档中用“复选框”实现，例如“数据库，服务器，客户端”。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。
* Requestor（请求者） 产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
* Bug tracking ID（Bug跟踪ID） 如果你有个bug跟踪系统，就像我们用的Jira一样，那么了解一下故事与bug之间的直接联系就会对你很有帮助。我们如何让产品backlog停留在业务层次上
如果产品负责人有技术相关的背景，那他就可能添加这样一个故事：“给Events表添加索引”。他为啥要这么做？真正的潜在目标也许是“要提高在后台系统中搜索事件表单的响应速度”。
到后面我们可能会发现：索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。
只要发现这种面向技术的故事，我一般都会问产品负责人“但是为什么呢”这样的问题，一直问下去，直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事（“提高在后台系统中搜索并生成表单的响应速度”）。最开始的技术描述只会作为一个注解存在（“为事件表添加索引可能会解决这个问题”）。
第3章 我们怎样准备sprint计划
Sprint计划的这一天很快就要到来了。有个教训我们一再体会：在sprint计划会议之前，要确保产品backlog的井然有序。
但这到底是什么意思？所有的故事都必须定义得完美无缺？所有的估算都必须正确无误？所有的先后次序都必须固定不变？不，不，绝不是这样！它的意思是“产品backlog必须存在。”（你能想象到这一点么？）
* 只能有一个产品backlog和一个产品负责人（对于一个产品而言）。
* 所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。
* 其实，重要程度比较低的backlog条目，评分相同也没关系，因为它们在这次sprint计划会议上可能根本不会被提出来。
* 无论任何故事，只要产品负责人相信它会在下一个sprint实现，那它就应该被划分到一个特有的重要性层次。
* 分数只是用来根据重要性对backlog条目排序。假如A的分数是20，而B的分数是100，那仅仅是说明B比A重要而已，绝不意味着B比A重要五倍。如果B的分数是21而不是100，含义也是一样的！
* 最好在分数之间留出适当间隔，以防后面出现一个C，比A重要而不如B重要。当然我们也可以给C打一个20.5分，但这样看上去就很难看了，所以我们还是留出间隔来！
* 产品负责人应当理解每个故事的含义（通常故事都是由他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序）。他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里。
注意
产品负责人之外的人也可以向产品backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。
我们还曾经尝试过或者评估过其他方式。
* 使用Jira（我们的bug跟踪系统）存放产品backlog。但是大多数产品负责人都觉得这东西操作起来太繁琐了。Excel操作起来简单方便，直截了当。你可以使用不同的颜色、重新组织条目、在特定情况下添加列、添加注解和导入导出数据等。
* 使用VersionOne、ScrumWorks、XPlanner这种敏捷过程工具。我们还没有测试过它们，不过以后可能会吧！
第4章 我们怎样制定sprint计划
■
为什么产品负责人必须参加
■
为什么不能在质量上让步
■
无休止的sprint计划会议……
■
sprint 计划会议日程
■
产品负责人如何对sprint放哪些故事产生影响
■
团队怎样决定把哪些故事放到sprint里面
■
定义“完成”
■
使用计划扑克做时间估算
■
明确故事内容
■
定下每日例会的时间地点
■
最后界限在哪里
■
bug跟踪系统 vs.产品 backlog
■
sprint计划会议终于结束了
Sprint计划会议非常关键，应该算是Scrum中最重要的活动（这当然是我的主观意见）。要是它执行得不好，整个sprint甚至都会被毁掉。
举办sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。
OK，这么说可能比较模糊。其实，sprint计划会议会产生一些实实在在的成果：
* sprint目标
* 团队成员名单（以及他们的投入程度，如果不是100%的话）
* sprint backlog（即sprint中包括的故事列表）
* 确定好sprint演示日期
* 确定每日Scrum会议的时间和地点为什么产品负责人必须参加
有时候产品负责人会不太情愿跟团队一起花上几个小时制定sprint计划。“嘿，小伙子们，我想要的东西已经列举出来了，我没时间参加你们的计划会议。”这可是个非常严重的问题。
为什么整个团队和产品负责人都必须要参加sprint计划会议？原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖。
下图中的范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。
会议启动以后，产品负责人一般会先概括一下希望在这个sprint中达成的目标，还有他认为最重要的故事。接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。在这个过程中，他们会针对范围提出些重要问题：“‘删除用户’这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答复会让他们感到惊讶，促使他们调整估算。
在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法不太一样。这可能会让他调整故事的重要性；或者修改故事的范围，导致团队重新估算，然后一连串诸如此类的连锁反应。
这种直接的协作形式是Scrum的基础，也是所有敏捷软件开发的基础。
如果产品负责人还是坚持没时间参加怎么办？一般我会按顺序尝试下面的策略。
* 试着让产品负责人理解，为什么他的直接参与事关项目成败，希望他可以改变想法。
* 试着在团队中找到某个人，让他在会议中充当产品负责人的代表。告诉产品负责人，“既然你没法来开会，我们这次会让Jeff代表你参加。他会替你在会议中行使权利，改变故事的优先级和范围。我建议，你最好在会议开始前尽可能跟他沟通到位。如果你不喜欢Jeff当代表，也可以推荐其他人，只要他能全程参加我们的会议就行。”
* 试着说服管理团队为我们安排新的产品负责人。
* 推迟sprint的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。为什么不能在质量上让步
在上面的三角形中，我有意忽略了第四个变量——质量。
我尽力把内部质量和外部质量分开。
* 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
* 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。松散的沙滩上怎么可能建起精美的楼阁？
我把外部质量也看作范围的一部分。有时出于业务考虑，可能会先发布一个系统版本，其用户界面给人的感觉可能比较简陋，而且反应也很慢；不过随后会发布一个干净的版本。我都是让产品负责人做权衡，因为他是负责定义项目范围的人。
不过内部质量就没什么好说的了。不管什么时候，团队都要保证系统质量，这一点毋庸置疑，也没有任何回施余地。现在如此、将来如此、一直如此，直到永远。（嗯，好吧，差不多直到永远）
那么我们怎样区分哪些问题属于内部质量，哪些属于外部质量呢？
假设产品负责人这样说，“好吧，你们把它估算成6个故事点也行。但我相信：一定能够找到些临时方案，节省一半时间。你们只要稍稍动下脑子就行。”
啊哈！他想把内部质量当作变量来处理。我是怎么知道的？因为他想让我们缩减故事的估算时间，但不想为缩减范围“买单”。“临时方案”这个词应当在你脑中敲响警钟……
为什么不允许这样干？
经验告诉我：牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。
碰到这种状况，我就会试着把话题转回到范围上来。“既然你想尽早得到这个特性，那我们能不能把范围缩小一点？这样实现时间就能缩短。也许我们可以简化错误处理的功能，把‘高级错误处理’当作一个单独的故事，放到以后再实现。或者也可以降低其他故事的优先级，好让我们集中处理这一个。”
一旦产品负责人弄清楚内部质量是不可能让步的，他一般都会处理好其他变量。无休止的sprint计划会议……
在sprint计划会议中最困难的事情是：
1.人们认为他们花不了多长时间；
2.……但他们会的！
Scrum中的一切事情都有时间盒。我喜欢这条简单如一的规则，并一直力求贯彻到底。
假如sprint计划会议接近尾声，但仍然没有得出sprint目标或者sprint backlog，这时该怎么办？我们要打断它么？还是再延长一个小时？或者到时间就结束会议，然后明天继续？
这种事情会一再发生，尤其是在新团队身上。你会怎么做？我不知道。但我们的做法是什么？嗯……我通常会直接打断会议，中止它，让这个sprint给大家点儿罪受吧。具体一点，我会告诉团队和产品负责人：“这个会议要在10分钟以后结束。我们到目前为止还没有一个真正的sprint计划。是按照已经得出的结论去执行，还是明早8点再开4小时的会？”你可以猜一下他们会怎么回答…… :o)
我也试过让会议延续下去。但一般都没啥效果，因为大家都很累了。如果他们在2到8个小时（不管多久，只要你固定好时间长度就可以）内都没整理出一个还说得过去的sprint计划，那么再来一个小时他们仍然得不出结论。我们也可以明天再安排一次会议——但大家都已经完全失去耐心，只想启动这个sprint，不想再花一个小时做计划。如果可以罔顾这个事实，那这个选择也确实不错。
所以我会打断会议。是的，这个sprint让大家不太好过。但我们应该看到它的正面影响，整个团队都从中获益匪浅，下个sprint计划会议会更有效率。另外，如果他们从前还觉得你定下的会议时间过长的话，下次他们的抵制情绪就会少一些了。
学会按照时间盒安排工作，学会制定合乎情理的时间盒，这对会议长度和sprint长度同样有帮助。sprint 计划会议日程
在sprint计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。
下面来看一下我们用到的一个典型的时间表。
sprint计划会议：13:00 - 17:00（每小时休息10分钟）
* 13:00 - 13:30 产品负责人对sprint目标进行总体介绍，概括产品backlog。确定演示的时间和地点。
* 13:30 - 15:00 团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。
* 15:00 - 16:00 团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
* 16:00 - 17:00 为每日scrum会议（以下简称每日例会）安排固定的时间和地点（如果和上次不同的话）。把故事进一步拆分成任务。
这个日程绝不是强制执行的。ScrumMaster根据会议进程的需要，可以对各个阶段的子进程时间安排进行调整。
确定sprint长度
sprint演示日期是sprint 计划会议的产出物，它被确定下来以后，也就确定了sprint的长度。
那sprint应该多长才好？
嗯，时间短就好。公司会因此而变得“敏捷”，有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而来。
但是，时间长的sprint也不错。团队可以有更多时间充分准备、解决发生的问题、继续达成sprint目标，你也不会被接二连三的sprint 计划会议、演示等等压得不堪重负。
产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们最终总结出了最喜欢的长度：三个星期。绝大部分团队的sprint长度都是三周。它不长不短，既让我们拥有足够的敏捷性，又让团队进入[1]“流”的状态，同时还可以解决sprint中出现的问题。
此外我们还发现：刚开始要试验sprint的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。
不过，确定了自己最喜欢的长度之后，就要在长时间内坚持不变。经过几个月的实验后，我们发现3个星期是个不错的长度，于是我们就把sprint固定为3个星期，进行了一段时间。有的时候会稍稍感觉有点长，有的时候感觉有点短。但保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。这段时间内也无需讨论发布日期之类的事情，因为大家都知道：每过三周都会有一个发布。
确定sprint目标
几乎每次sprint计划会议都要确定sprint目标。在sprint 计划会议进行中，我会选某个时刻问一个问题，“这个sprint的目标是什么？” 每个人都目光空洞地看着我，产品负责人也皱起眉头，开始挠下巴。
出于某些原因，制定sprint目标确实很困难。但我发现即使是像挤牙膏一样把它挤出来，那也是值得的。半死不活的目标也比啥都没有强。这个目标可以是“挣更多的钱”，或者“完成优先级排到最前面的三个故事”，或“打动CEO”，或“把系统做得足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。它必须用业务术语表达，而不是技术词汇，让团队以外的人也能够理解。
sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？”要想从产品负责人的口中诱导出sprint目标，你不妨一字不差地问他这个问题看看。
sprint目标应该是尚未达成的。“打动CEO”这个目标不错，可如果这个系统已经给他留下了深刻印象，那就算了。这种状况下大家都可以放假回家，sprint目标依然能完成。
制订sprint计划的时候，这个目标可能看上去既愚蠢又勉强，但它在sprint中常常会被用到，到那时大家就会开始对他们应该做啥感到困惑。如果有多个Scrum团队（像我们一样）开发不同产品，你可以在一个wiki页面（或其他东西）上列出所有团队的sprint目标，然后把它们放到一个显著位置上，保证公司所有人（不只是顶级管理层）知道公司在干什么，目的又是什么！
决定sprint要包含的故事
决定哪些故事需要在这个sprint中完成，是sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从产品 backlog拷贝到sprint backlog中，如下图所示。
试读结束[说明：试读内容隐藏了图片]