硝烟中的Scrum和XP.jpg
第1章 简介
- Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。P1
第2章 我们怎样编写产品backlog
- 产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。P4
- 我们的故事包括这样一些字段：P4
- ID——统一标识符，就是个自增长的数字而已。
- Name（名称）——简短的、描述性的故事名。
- Importance（重要性）——产品负责人评出一个数值，指示这个故事有多重要。
- Initial estimate（初始估算）——团队的初步估算，表示与其他故事相比，完成该故事所需要的工作量。
- How to demo（如何做演示）——它大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
- Notes（注解）——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。
- 额外的故事字段。P6
- Track（类别）——当前故事的大致分类。
- Components（组件）——例如“数据库，服务器，客户端”。
- Requestor（请求者）——产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
- Bug tracking ID（Bug跟踪ID）——如果你有个bug跟踪系统，就像我们用的Jira一样，那么了解一下故事与bug之间的直接联系就会对你很有帮助。
- 我们如何让产品backlog停留在业务层次上？P7
只要发现这种面向技术的故事，我一般都会问产品负责人“但是为什么呢”这样的问题，一直问下去，知道我们发现内在的目标为止。然后再用真正的目标改写这个故事。最开始的技术描述只会作为一个注解存在。
第3章 我们怎样准备sprint计划
- 在sprint计划会议之前，要确保产品backlog的井然有序。它表示的意思是：P8
- 产品backlog必须存在。
- 只能有一个产品backlog和一个产品负责人（对于一个产品而言）。
- 所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不用的分数。
- 其实，重要程度比较低的backlog条目，评分相同也没关系，因为他们再这次sprint计划会议上可能根本不会被提出来。
- 无论任何故事，只要产品负责人相信它会在下一个sprint实现，那它就应该被划分到一个特有的重要性层次。
- 分数只是用来根据重要性对backlog条目排序。
- 最好在分数之间留出适当间隔。
- 产品负责人应当理解每个故事的含义。
第4章 我们怎样制定sprint计划
- Sprint计划会议会产生一些实实在在的成果：P10
- sprint目标。
- 团队成员名单。
- sprint backlog。
- 确定好sprint演示日期。
- 确定好时间地点，供举行每日scrum会议。
- 每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖。范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。P11
- 我们尽力把内部质量和外部质量分开。P12
- 外部质量是系统用户可以感知的。运行缓慢、让人米糊的用户界面就属于外部质量低劣。
- 内部质量一般指用户看不到的要素，他们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
内部质量没什么好说的了。不管什么时候，团队都要保证消停质量，这一点毋庸置疑，也没有折扣可讲。现在如此、将来如此、一直如此，知道永远。
- Scrum中的一切事情都有时间盒。我喜欢这条简单如一的规则，并一直力求贯彻到底。P13
- 在sprint计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。P14
- 产品负责人对sprint目标进行总体介绍，概括产品backlog。定下演示的时间地点。
- 团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。
- 团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
- 为每日scrum会议安排固定的时间地点。把故事进一步拆分成任务。
- sprint时间短就好。公司会因此而变得“敏捷”，有利于随机应标。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而来。P15
- 刚开始要实验sprint的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。P16
- 决定哪些故事需要在这个sprint中完成，是sprint计划会议的一个主要活动。P17
- 团队怎样决定把哪些故事放到sprint里面。P20
- 本能反应。
- 生产率计算。
- 得出估算生产率。
- 计算在不超出估算生产率的情况下可以加入多少故事。
- 创建一些索引卡，把它们放到墙上（或一张大桌子上）。原因是：P27
- 大家站起来四处走动——它们可以更长时间地保持清醒，并留心会议进展。
- 他们有更多的个人参与感（而不是只有那个拿着键盘的家伙才有）。
- 多个故事可以同时编辑。
- 重新划分优先级变得易如反掌——挪动索引卡就行。
- 会议结束后，索引卡可以拿出会议室，贴在墙上的任务板上。
- 我们不会让任务拆分出现在产品backlog中，原因有二：P29
- 任务拆分的随机性比较强，在sprint进行中， 它们常常会发生变化，不断调整，所以保持产品backlog的同步很让人头大。
- 产品负责人不需要关心这种程度的细节。
- 定义“完成”。P30
产品负责人和团队需要对“完成”有一致的定义。“随时可以上线”，不过有时候我们也这样说：“已经部署到测试服务器上，准备进行验收测试”。 - 使用计划纸牌做时间估算。P30
- 在计划的时候，我们一般都不还不知道到底谁会来实现哪个故事的哪个部分。
- 每个故事一般有好几个人参与，也包括不同类型的专长（用户界面设计、编程、测试、等等）。
- 团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础，也有助于故事中的重要问题被尽早发现。
- 如果要求每个人都对故事做估算，我们就会常常发现两个人对同一个故事的估算结果差异很大。我们应该尽早发现这些问题并就此进行讨论。
- 把故事拆分成任务。P34
故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。我们会看到一些很有趣的现象：- 新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法。
- 有些故事，大家都理解得很清楚，那么预先拆分还是随后拆分都一样简单。
- 这种类型的拆分常常可以发现一些会导致时间估算增加的工作，最后得出的sprint计划会更贴近现实。
- 这种预先拆分可以给每日例会的效率带来显著提高。
- 即使拆分不够精确，而且一旦开始具体工作，事先的拆分结果也许会发生变化，但我们依然可以得到以上种种好处。
- 定下每日例会的时间地点。我喜欢早上开会。P36
- 在下午开每日例会的缺点：早上来工作的时候，你必须试着记起来你昨天对别人说过今天要做什么。
- 在上午开每日例会的缺点：早上来工作的时候，你必须试着记起来你昨天做了什么，这样才能跟别人讲。
我的看法是，第一个缺点更糟，因为最重要的事情是你打算干什么，而不是已经干了什么。
- 优先级列表。P36
- 优先级1：sprint目标和演示日期。
- 优先级2：经过团队认可、要添加到这个sprint中的故事列表。
- 优先级3：Sprint中每个故事的估算值。
- 优先级4：Sprint中每个故事的“如何演示”。
- 优先级5：生产率和资源计算，用作sprint计划的现实核查。包括团队成员的名单及每个人的承诺。
- 优先级6：明确每日例会固定举行的时间地点。这只需要花几分钟，但如果时间不够用，Scrum master可以在会后直接定下来，邮件通知所有人。
- 优先级7：把故事拆分成任务。这个拆分也可以在每日例会上做，不过这会稍稍打乱sprint的流程。
- 对于技术故事，我们采取了下面这些做法：P38
- 试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人作出正确的权衡。
- 如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。
- 如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。产品负责人能看到它，但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商，从sprint里拔出一些时间来完成这些技术故事。
- 怎么把Jira上的issue带到sprint计划会议上来呢？我们试过几种方法。P40
- 产品负责人打印出Jira中优先级最高的一些条目，带到sprint计划会议中，跟其他故事一起贴到墙上（因此就暗暗地指明了这些issue相对其他故事的优先级）。
- 产品负责人创建一些指向Jira条目的故事。
- 修复bug被当做sprint以外的工作，也就是说，团队会保持一个足够低的投入程度，从而保证他们有时间来修复bug。然后我们就可以简单假设，在每一个sprint中，团队都会用一些时间来修复Jira上报告的bug。
- 把产品backlog放到Jira上。把bug与其他故事同等看待。
第5章 我们怎样让别人了解我们的sprint
- sprint信息页。P42
- Sprint goal
- Sprint backlog
- Estimated velocity
- Schedule
- Team
第6章 我们怎样编写sprint backlog
- 我们发现管理sprint backlog最有效的形式——挂在墙上的任务板。注意，如果你用贴纸来记录任务，别忘了用真正的胶带把它们粘好，否则有一天你会发现所有的贴纸都在地方堆成一堆。P45
第7章 我们怎样布置团队房间
- “设计墙”只是一块大白板，上面画着最重要的设计草图，还有打印出来的、最重要的设计文档（顺序图，GUI原型，领域模型等等）。P57
- 让团队坐在一起。“一起”意味着：P58
- 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
- 互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
- 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。
第8章 我们怎样进行每日例会
- 一般我们都是开站立会议，以防止持续时间超过15分钟。P61
- 我们曾经试过让Scrum master自己维护sprint backlog，他就不得不每天都去询问大家各自剩余的工作估算时间。这种做法的缺点是：P62
- Scrum master把太多时间用在了管理之类的工作上，而不是为团队提供支持，消除他们的障碍。
- 因为团队成员不再关心sprint backlog，所以他们就意识不到sprint的状态。缺少了反馈，团队整体的敏捷度和精力的集中程度都会下降。
- 处理迟到的家伙。有些团队会弄个存钱罐。如果你来晚了，即使只迟到一分钟，也必须往里面投入定额的钱。P62
- 处理“我不知道今天干什么”的情况，我会对觉得自己没事可干的人说，“我们已经过了一遍任务板，你们现在对今天要做的事情有想法了么”。希望他们有点儿概念了。P63
- 如果团队还没有达成目标，一般我会尝试下面的某种策略（这些都不怎么让你愉快，但已经是无可奈何之计了）：P64
- 羞辱式做法：“如果你不知道怎么帮助团队，我建议你还是回家去，或者看书，或者怎么都行。要不也可以找个地方坐下，等比人需要帮助的时候你就过去”。
- 守旧式做法：简单给他们分配个任务了事。
- 施加同事压力的做法：对他们说，你们两个可以放松点，我们会站在这里慢慢等，直到你们找到帮助我们完成目标的事情为止。
- 奴役式做法：对他们说，“你们今天可以给大伙儿干干杂活”。
如果一个人常常逼得你要这样做，那就应该考虑是不是把他单独找出来做辅导。如果他不是太重要，就试着把他从你的团队中挪走。如果他确实重要，就试着让他跟别人结对，另一个人充当他的“牧羊人”。
第9章 我们怎样进行sprint演示
- 为什么我们坚持所有的sprint都结束于演示。一次做得不错的演示，即使看上去很一般，也会带来深远影响。P65
- 团队的成果得到认可。他们会感觉很好。
- 其他人可以了解你的团队在做些什么。
- 演示可以吸引相关干系人的注意，并得到重要反馈。
- 演示是一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。
- 做演示会迫使团队真正完成一些工作，进行发布。如果没有演示，我们就会总是得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但他们是真正完成的。这比得到一堆貌似完成的工作要好得多，而且后者还会污染下一个sprint。
- Sprint演示检查列表。P66
- 确保清晰阐述了sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
- 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。
- 节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
- 让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。
- 可能的话，让观众自己试一下产品。
- 不要演示一大堆细碎的bug修复和微不足道的特性。你可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事。
第10章 我们怎样做sprint回顾
- 我认为回顾是Scrum中第二重要的事情（最重要的是sprint计划会议），因为这是你做改进的最佳时机。P68
- 我们如何组织回顾。P69
- 根据要讨论的内容范围，设定时间为1至3个小时。
- 参与者：产品负责人，整个团队还有我自己。
- 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好。
- 我们一般不会再团队房间中进行回顾，因为这往往会分散大家的注意力。
- 指定某人当秘书。
- Scrum master向大家展示sprint backlog，在团队的帮助下对sprint做总结。包括重要事件和决策等。
- 我们会轮流发言。每个人都有机会在不被人打断的情况下进出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个sprint中改变。
- 我们对预估生产率和实际生产率进行比较。如果差异比较大的话，我们会分析原因。
- 快结束的时候，Scrum master对具体建议进行总结，得出下个sprint需要改进的地方。
- 我们怎样才能在下个sprint中做的更好。P70
- Good：如果我们可以重做同一个sprint，哪些做法可以保持。
- Could have done better：如果我们可以重做同一个sprint，哪些做法需要改变。
- Improvements：有关将来如何改进的具体想法。
每个人都有三块小磁铁，投票决定下个sprint所要采取措施的优先级。
- Scrum回顾会议，充当“知识桥梁”的人需要服从一些重要规则：P71
- 他应当是一个很好的倾听者。
- 如果回顾会议过于沉寂，他应该问一些简单而目标明确的问题，以刺激团队展开讨论。例如“如果时间可以倒流，从第一天重新开始这个sprint，那你觉得哪些事情会用其他方式来做？”
- 他应该自愿花时间参加所有团队的全部回顾。
- 他们应该有一定的行政权力，如果出现一些团队无法控制的改进建议，他可以帮助推进实施。
第11章 Sprints之间的休整时刻
- 在实际生活中，你不可能一直像上紧了发条一样始终高速工作。你需要在冲刺的间歇休息。如果弦总是绷得那么紧，实际上收到的成效反而不好。P74
第12章 怎样制定发布计划，处理固定价格的合同
- 一般来讲，制定发布计划是在尝试回答这个问题：“最晚到什么时候为止，我们可以交付这个新系统的1.0版本？”P77
- 定义你的验收标准。P77
产品负责人还会定义一系列的验收标准，它从合同的角度将产品backlog中重要性级别的含义进行了简单分类。下面是验收标准规则的一个例子：- 所有重要性>=100的条目都必须在1.0版本中发布，不然我们就会被罚款到死翘翘。
- 所有重要性在50-99之间的条目应该在1.0中发布，不过也许我们可以在紧接着的一个快速发布版中完成这些。
- 重要性在25-49之间的条目也都是需要的，不过可以在1.1版本中发布。
- 重要性<25的条目都是不确定的，也许永远不会用到。
- 对最重要的条目进行时间估算。P78
对制定发布计划，产品负责人需要进行时间估算，至少是要估算在合同中包含的故事。跟sprint计划会议一样，这是产品负责人和团队协作共同完成的——团队进行估算，产品负责人描述条目内容，回答问题。
如果时间估算最后被证明接近正确结果，那它就是有价值的；如果结果有所偏离，例如偏差30%，价值则有所降低了；如果它跟实际结果一点关系都没有，那就完全没用了。 - 估算。P79
- 让团队来做估算。
- 不要让他们花太多时间。
- 确保他们理解时间估算只是粗略估算，而不是承诺。
- 估算生产率。P80
投入程度表示“团队有多少时间可以放在当前承诺的故事上”。 - 统计一切因素，生成发布计划。P81
要视合同情况，范围限制有多严格，等等而定。我们通常都会增加相当多的时间缓冲，以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。在这种情况下，我们可能会统一把发布日期定在三个月后，让我们“保留”一个月。
第13章 我们怎样组合使用Scrum和XP
- Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题，可以互为补充，相得益彰。P83
- 结对编程。P84
- 结对编程可以提高代码质量。
- 结对编程可以让团队的精力更加集中。
- 令人惊奇的是，很多强烈抵制结对编程的开发人员根本就没有尝试过，而一旦尝试之后就迅速喜欢上它。
- 结对编程令人精疲力竭，不能全天都这样做。
- 常常更换结对是有好处的。
- 结对编程可以增进团队间的知识传播。速度快到令人难以想象。
- 有些人就是不习惯结对编程。不要因为一个优秀的开发人员不习惯结对编程就把他置之不理。
- 可以把代码审查作为结对编程的替代方案。
- “领航员”（不用键盘的家伙）应该自己也有一台机器。不是用来开发，而是在需要的时候稍稍做一些探索尝试、当“司机”（使用键盘的家伙）、遇到难题的时候查看文档，等等。
- 不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。
- 测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提供它的可读性和消除重复。人们对测试驱动开发有着各种看法：P84
- TDD很难。开发人员需要花上一定时间才能掌握。一旦掌握以后，他就会受到彻底的影响，从此再也不想使用其他方式工作。
- TDD对系统设计的正面影响特别大。
- 在新产品中，需要过上一段时间，TDD才能开始应用并有效运行，尤其是黑盒集成测试。但是回报来得非常快。
- 投入足够的时间，来保证大家可以很容易地编写测试。这意味着要有合适的工具、有经验的人、提供合适的工具类或基类，等等。
第14章 我们怎样做测试
- 在理想化的Scrum世界中，每个sprint最终会产生一个可部署的系统版本。尽可能缩短验收测试的时间。说得更明白一些，把需要花在验收测试阶段上的时间减到最少。我们的做法是：P90
- 全力提高Scrum团队交付的代码质量。
- 全力提高人工测试的效率。
- 把测试人员放到Scrum团队中。
- 每个sprint少做点工作。
第15章 我们怎样管理多个Scrum团队
- 宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产生互相干扰。P102
- 在Scrum中，团队分割确实很困难。不要想的太多，也别费太大劲儿做优化。先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。迟早就会发现针对你所在环境的解决方案。需要重视的是，必须要让团队对所处环境感到舒适，而且不会常常彼此干扰。P
104 - 最佳的团队尺寸：5到9个人被公认为是“最佳的”团队构成人数。
- 是否同步多个Sprint？P104
多个sprint在任何一个给定的时间点上，都有一个正在进行的sprint接近结束，而新的sprint即将开始。产品负责人的工作负担会随着时间的推移逐步推开。同步进行的sprint有如下优点：- 可以利用sprint之间的时间来重新组织团队！如果各个sprint重叠的话，要重新组织团队，就必须打断至少一个团队的sprint进程。
- 所有团队都可以在一个sprint中向同一个目标努力，他们可以有更好的协作。
- 更小的挂你压力，即更少的sprint计划会议、sprint演示和发布。
- 假设我们有三个团队开发同一个产品。我们通过引入“团队领导”的角色来解决了这个问题。你也许把他叫做“Scrum中的Scrum master”，或者“老大”，也或者“首席Scrum master”等。他不用领导某个团队，但是会负责跨团队的问题，例如谁担任哪个团队的Scrum master，大家如何分组等等。P106
- 有多个团队开发同一个产品时，一般有两种分配人手的策略。P107
- 让一个指定的人来做分配，例如我们提到的“团队领导”。
- 让团队自己决定。
- 跨组件的团队。P110
创建跨组件的团队，也就是说团队的职责不会被束缚在任何特定的组件上。它减少了诸如“我们没法完成这个条目，因为他们再等server那帮家伙完成他们的工作”之类的情况发生。 - Scrum-of-scrums实际上是一个常规会议，是为了让所有的scrum master聚到一起交流。P113
在会议上我们讨论集成问题，团队平衡问题，为下个sprint计划会议做准备。
* 每个人围着桌子坐好，描述一下上周各自的团队都完成了什么事情，这周计划完成什么事情，遇到了什么障碍。
* 其他需要讨论的跨团队的问题，例如集成。 - 团体层次的Scrum-of-Scrums。P115
- 开发主管介绍最新情况。例如即将发生的事件信息。
- 大循环。每个产品组都有一个人汇报他们上周完成的工作，这周计划完成的工作，及碰到的问题。其他人也会做报告（配置管理领导，QA领导等）。
- 其他人都可以自由补充任何信息，或者提问问题。
- 交错的每日例会。P116
这种做法超级有效，原因有二：- 像产品负责人和我这样的人可以在一个早上参加所有的例会。想清楚了解到当前的sprint进展状况，有什么严重的风险，这是最好的方式。
- 团队成员可以参加其他团队的额例会。这种情况不常发生，不过有时两个团队会在相似的环境下工作，所以会有几个人参加彼此的例会来保持同步。
- 救火团队。P117
我们创建了一个专门的救火团队，救火团队（实际上我们管他们叫“支持团队”）有两项工作。- 救火。
- 保护Scrum团队远离各种干扰，包括挡开那些不知从何而来的、增加临时特性的要求。
- 一个产品和两个Scrum团队，是否分产品backlog？P118
- 策略1：一个产品负责人，一个backlog。
你可以让团队根据产品负责人当前的优先级来自行管理。产品负责人关注他所需要的东西，团队决定怎么分割工作。 - 策略2：一个产品负责人，多个backlog。
它的劣势在于，产品负责人要把故事分配给团队，而这项工作交给团队自己处理会更好。 - 策略3：多个产品负责人，每人一个产品backlog
如果两个产品backlog都对应一个代码库，那两个产品负责人可能会发生严重的利害冲突。
- 策略1：一个产品负责人，一个backlog。
- 代码分支。P123
- 主线的状态要保持一致：最起码所有的东西都要能够进行编译，所有的单元测试都可以通过。每时每刻都能创建一个可以工作的发布版本。如果可以做到持续构建系统在每晚进行构建，并把结果自动部署到测试环境中就更好了。
- 给每个版本打上标记（tag）。无论什么时候，只要是为验收测试进行发布，或是发布到产品环境，在主线中就应该进行版本标记，用来精确标识所发布的内容。这便意味着在将来的任一时刻，你都可以会退到某个历史版本中，创建一个维护分支。
- 只在必须的时候创建分支。这里有一条很好的规则：如果你无法在不违反现有代码基线策略的情况下使用改代码基线，那么只有在这种情况下，才能创建新的代码基线。如果摸不准是什么情况，那就不要创建分支。为什么？因为每个活动分支都会增加复杂性，提高管理成本。
- 将分支主要用于分离不同的生命周期。无论你是否决定让每个团队在他们自己的代码基线上进行编码，如果你打算再同一个代码基线上将短期的修复版与长时间的变化进行合并，到时候就会发现：要发布这个短期的修复版本绝非易事。
- 经常同步。如果你在分支上工作，那么只要有了一些代码可以构建，就应该与主线进行同步。在每天的编码工作开始之前，都把代码从主线同步到分支上，这样你的分支就可以与其他团队所做出的变化保持更新。如果会产生让你觉得生不如死的合并情况，那也只能接受这种现实，因为等下去的结果只会更糟。
第16章 我们怎样管理地理位置上分布的团队
- 我们的策略很简单：就是想尽办法来把物理位置上分散的团队成员之间的沟通带宽增至最大。我不只是说每秒传递多少兆字节（当然这也很重要），还包括含义更广的沟通带宽：P125
- 能够在一起结对编程。
- 能够在每日例会上面对面交流。
- 在任何时候都能够面对面讨论。
- 可以真正地碰面与交往。
- 整个团队可以主动举行会议。
- 团队对sprint backlog、sprint燃尽图、产品backlog和其他信息传递设施有相同的理解。
- 每一台工作站前面都配备网络摄像头和耳麦。
- 可以远程通话的会议室，带有网络摄像头、会议用麦克风、随时可用的计算机和桌面共享软件等等。
- “远程窗口”。每个地方都有大屏幕，显示其他地点的固定画面。就像两个公寓之间的虚拟窗口一样。你可以看到谁坐在座位前，谁在跟谁说话。这可以增强“我们是在一起工作”的感觉。
- 交换程序。来自每一个地方的人按照某个规律交叉访问。
第17章 Scrum master检查列表
- sprint开始阶段。P129
- Sprint计划会议之后，创建Sprint信息页面。
- 在wiki上创建从dashboard指向所创建页面的链接。
- 把页面打印出来，贴在通过你们团队工作区域之外的墙上，让经过的人都可以看到。
- 给每个人发邮件，申明新的sprint已经启动。邮件中要包括sprint目标和指向sprint信息页面的链接。
- 更新sprint数据文档。加入估算生产率、团队大小和sprint长度等等。
- Sprint计划会议之后，创建Sprint信息页面。
- 每一天。P129
- 确保每日Scrum会议可以按时开始和结束。
- 为了保证sprint可以如期完成，需要适当地增删故事。
- 确保产品负责人了解这些变化。
- 确保团队可以及时得知Sprint backlog和燃尽图的最新状况。
- 确保存在的问题和障碍都能被解决，并报告给产品负责人以及（或者）开发主管。
- 在sprint结束时。P130
- 进行开放式的Sprint演示。
- 在演示开始前一两天，就要通知到每个人。
- 与整个团队以及产品负责人一起开Sprint回顾会议。开发主管也应该受邀参加，他可以把你们的经验教训大范围传播开来。
- 更新sprint数据文档。加入实际生产率和回顾会议中总结出的关键点。
