scrum

敏捷项目管理scrum知识总结和应用总结脑图，Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。

SCRUM

• 定义
  • Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。
    • • 轻量的 • 易于理解的 • 难以精通的
• 理论
  • 透明
    • 过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。
  • 检视
    • Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。
  • 适应
    • 如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。
• 4 个正式事件
  • • Sprint 计划会议 • 每日 Scrum 站会 • Sprint 评审会议 • Sprint 回顾会议
• Scrum 价值观
  • 承诺、勇气、专注、开放和尊重五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过Scrum 的角色、事件和工件来学习和探索这些价值观。
• Scrum 团队
  • 产品负责人
    • 产品负责人的职责是将开发团队开发的产品价值最大化。
    • 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括： • 清晰地表述产品待办列表项； • 对产品待办列表项进行排序，使其最好地实现目标和使命； • 优化开发团队所执行工作的价值； • 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及 确保开发团队对产品待办列表项有足够深的了解。
    • 产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。
    • 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定
  • 开发团队
    • 开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
    • 开发团队具有下列特点： • 他们是自组织的。没有人（即使是 Scrum Master ）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量； • 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能； • Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。 • Scrum 不认可开发团队中所谓的 “ 子团队 ” ，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
    • 开发团队的规模：3~9人
  • Scrum Master
    • Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点，是一位服务型领导。
    • Scrum Master 服务于产品负责人
      • Scrum Master 以各种方式服务于产品负责人，包括： • 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域； • 找到有效管理产品待办列表的技巧； • 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项； • 理解在经验主义的环境中的产品规划； • 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值； • 理解并实践敏捷性；以及，当被请求或需要时，引导 Scrum 事件
    • Scrum Master 服务于开发团队
      • Scrum Master 以各种方式服务于开发团队，包括： • 作为教练在自组织和跨职能方面给予开发团队以指导； • 帮助开发团队创造高价值的产品； • 移除开发团队工作进展中的障碍； • 按被请求或需要时，引导 Scrum 事件；以及，在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
    • Scrum Master 服务于组织
      • Scrum Master 以各种方式服务于组织，包括： • 带领并作为教练指导组织采纳 Scrum； • 在组织范围内规划 Scrum 的实施； • 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发； • 引发能够提升 Scrum 团队生产率的改变；以及， • 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
• Scrum 事件
  • Sprint
    • Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。
  • 构成
    • Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。
  • Sprint 计划会议
    • Sprint 计划会议是有时间盒限定的，以一个月的 Sprint 来说最长为 8 小时。
    • Sprint计划会议回答以下问题： •接下来的Sprint 交付的增量中要包含什么内容？ •要如何完成交付增量所需的工作？
      • Sprint 会议的 输入 是 产品待办列表、最新的产品增量、开发团队在这个Sprint 中能力的预测以及开发团队的以往表现 。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的Sprint 可以完成什么工作。在Sprint 计划会议中，Scrum 团队还草拟一个Sprint 目标。Sprint 目标是在这个Sprint 通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。
        • 产品backlog
      • 在设定了Sprint 目标并选出这个Sprint 要完成的产品待办列表项之后，开发团队将决定如何在Sprint 中把这些功能构建成“完成”的产品增量。这个Sprint 中所选出的产品待办列表项加上如何交付它们的 计划 称之为 Sprint 待办列表 。
        • 开发团队自组织地领取Sprint 待办产品列表中的工作， 领取 工作在Sprint 计划会议和Sprint 期间按需进行。
        • 在 Sprint 计划会议结束 时，开发团队应该能够向产品负责人和Scrum Master 解释他们将如何以自组织团队的形式完成Sprint 目标并开发出预期的产品增量。
  • Sprint 目标
    • Sprint 目标是在当前Sprint 通过 实现产品待办列表 要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。
    • Sprint 目标在Sprint 计划会议中确定。
    • 如果所需工作和预期的不同， 开发团队需要与产品负责人沟通 协商Sprint 待办列表的范围。
  • 每日Scrum站会
    • 每日Scrum 站会是开发团队的一个时间盒限定为 15 分钟 的事件。
    • 开发团队籍由每日Scrum 站会来检视完成Sprint 目标的进度，并检视完成Sprint 待办列表的工作进度趋势。
    • 讨论内容
      • •昨天，我为帮助开发团队达成Sprint 目标做了什么？ •今天，我为帮助开发团队达成Sprint 目标准备做什么？ •是否有任何障碍在阻碍我或开发团队达成Sprint 目标？
    • 开发团队自己负责召开会议。Scrum Master 教导开发团队将每日Scrum会议时间控制在15 分钟内。
    • 如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。
    • 每日Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的 关键会议 。
  • Sprint评审会议
    • Sprint 评审会议在Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。
    • 这是一个 非正式会议 ，并 不是一个进度汇报会议 ，演示增量的 目的 是为了获取反馈并促进合作。
    • 对于长度为一个月的Sprint 来说，评审会议时间最长不超过4 小时。
    • Sprint 评审会议包含以下内容： •参会者包括Scrum 团队和产品负责人邀请的主要利益攸关者； •产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”； •开发团队讨论在Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的； •开发团队演示“完成”的工作并解答关于所交付增量的问题； •产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）； •参会的所有人就下一步的工作进行探讨，这样，Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息； •评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时，为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
    • Sprint 评审会议的 结果 是一份 修订后的产品待办列表，阐明很可能进入下个Sprint 的产品待办列表项 。产品待办列表也有可能为了迎接新的机会而进行 全局性地调整 。
  • Sprint回顾会议
    • Sprint 回顾会议是Scrum 团队检视自身并创建下一个Sprint 改进计划的机会。回顾会议发生在Sprint 评审会议结束之后，下个Sprint 计划会议之前。对于长度为一个月的Sprint 来说，回顾会议时间最长不超过3 小时。
    • Sprint 回顾会议的 目的 在于： •检视前一个Sprint 中关于人、关系、过程和工具的情况如何； •找出并加以排序做得好的和潜在需要改进的主要方面；同时，制定改进Scrum 团队工作方式的计划。
    • 在Sprint 回顾会议 结束 时，Scrum 团队应该明确接下来的Sprint 中需要 实施的改进 。
• Scrum工件
  • Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会。Scrum 所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此 每个人对工件都需要有相同的理解 。
  • 产品待办列表
    • 产品待办列表是 动态 的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。
    • 业务需求、市场形势或者技术的变化 都会引起产品待办列表的改变。
    • 多个Scrum 团队常常会一起参与对同一产品的开发。一个产品 只有 一个产品待办列表用于描述下一步产品开发工作。
    • 产品待办列表 精化 指的是为产品待办列表项增添细节、估算和排序的动作。产品负责人或者其他人在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。
    • 排序越 高 的产品待办列表项通常比排序 低 的更清晰同时包含更多细节。
    • 开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是 最终估算是由开发团队决定的 。
  • 监控目标实现的进度
    • 产品负责人 比较这次的剩余工作量与之前Sprint 评审会议时的剩余工作量，来评估在期望的时间点达成目标的进度。
  • Sprint待办列表
    • Sprint 待办列表是一组为当前Sprint 选出的 产品待办列表项 ，同时加上交付产品增量和实现Sprint 目标的 计划
    • 至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。
    • 是拥有足够细节的计划，任何进度的变化可以在每日Scrum 站会中清晰地看到。
    • 在Sprint 期间， 只有 开发团队可以改变Sprint 待办列表。
    • Sprint 待办列表是高度可见的，是对开发团队计划在当前Sprint 内工作完成情况的实时反映， 该列表由开发团队全权负责。
  • 监控Sprint 进度
    • 在Sprint的任何时间点都可以计算Sprint 待办列表中所有剩余工作的总和。开发团队 至少在每日Scrum 站会时跟踪剩余工作的总和 ，预测达成Sprint 目标的可能性。通过在Sprint 中不断跟踪剩余的工作量，开发团队可以管理自己的进度。
  • 增量
    • 增量是一个Sprint 完成的所有产品待办列表项的总和，以及之前所有Sprint 所产生的增量的价值总和。
    • 无论产品负责人是否决定发布它，增量必须可用。
• 工件透明
  • Scrum Master 必须和产品负责人、开发团队和其他相关人员 一起合作，以确保所有工件都是完全透明的。
    • 谁来做
  • Scrum Master 的职责就是和Scrum 团队以及组织一起合作增加工件的透明化。这一工作通常包括学习、说服和改变。
• “完成”的定义
  • DoD
  • 每个Sprint 的目标在于交付符合Scrum 团队当前“完成”的定义的潜在可交付功能增量。
  • 如果增量“完成”的定义不是开发组织的惯例，那么Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由 多个 Scrum 团队一起开发，那么所有Scrum 团队中的开发团队 必须一起 参与制定“完成”的定义。
  • 每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。
• 开展sprint计划会议中需要关注的地方
  • 产品负责人如何让团队接受更多更多的story
    • 困境描述，团队接受的backlog
    • 产品负责人想让团队接受的A B C D
      • 可以重新设置优先级。如果他给故事D赋予最高的重要级别，团队就不得不把它先放到sprint里面来（在这里需要把C扔出去）。
      • 可以更改范围——缩小故事A的范围，直到团队相信故事D能在这个sprint里完成为止。
      • 可以拆分故事。产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别。
  • 团队怎样决定把哪些story放到sprint里面
    • 本能反应-经验判断
    • 生产率计算
      • 方法1.昨日天气（yesterday’s weather）
        • 在过去几个sprint里面的生产率是多少，然后假定在下一个sprint里面生产率差不多不变。
          • 满足两个条件： 1. 团队已经完成了几个sprint（这样就可以得到统计数据）， 2. 会以几乎完全相同的方式（团队长度不变，工作状态等条件不变）来进行下一个sprint。
          • 另外应该从前的sprints，计算出平均数，这样可以得到更合理的估算。
      • 方法2.经验
• 怎样编写sprint backlog
  • 管理sprint backlog最有效的形式——挂在墙上的任务板。
  • 燃尽图
    • 这张图包含的信息有： 1. Sprint的第一天，8月1号，团队估算出剩下70个故事点要完成。这实际上就是整个sprint的估算生产率。 2. 在8月16号，团队估算出还剩下15个故事点的任务要做。跟表示趋势的虚线相对比，团队的工作状态还是差不多沿着正轨的。 3. 按照这个速度，他们能在sprint结束时完成所有任务。
  • 任务板警示标记
  • 任务板警示标记
• sprint管理中的其他方法
  • 让团队成员坐在一起
    • 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
    • 互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
    • 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。
• 怎样管理多个Scrum团队
  • 创建多少个团队
    • 宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。
  • 虚拟团队
    • 1. 你选择了使用“大团队”。不过观察一下sprint中的交流方式，你就能发现事实上这个大团队自动分成了两个子团队。
      • 如果这两个虚拟的子团队一直变化（也就是大家在虚拟团队中换来换去），那把他们放到一个团队中就没有问题。
      • 如果二者的构成在整个sprint中保持不变，在下个sprint中可能就得考虑把他们分成两个真正的Scrum团队了。
    • 2. 你选择了使用三个小团队的方式。不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立。
      • 如果团队1和团队2在整个sprint中一直聊来聊去（把团队3扔在一边），在下个sprint中你大概就得把团队1和2合并到一块。
      • 如果在sprint的前半阶段，团队1和团队2一直交流，然后在后半阶段，团队1和团队3又相谈甚欢，那合并或者保持原样就都是可行的。你可以在sprint回顾会议上提出这个问题，让团队自己决定。
    • 团队分割确实很困难。先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。需要重视的是，必须要让团队对所处环境感到舒适，而且不会常常彼此干扰。
• 引入“团队领导”的角色
  • 标记为“P”的红色家伙是产品负责人。标记为“S”的黑色家伙是Scrum Masters。
• 在团队中分配人手
  • 让一个指定的人来做分配，例如我前面提到的“团队领导”，或产品负责人，或职能经理（如果他的参与度比较高，就可以做出正确的决定）。
  • 让团队自己决定。
  • 上面两种方法结合。
  • 最开始使用一些集中式控制，然后再用分散式优化。
• 是否使用特定的团队
  • 方式1：特定于组件的团队
    • 创建针对特定组件展开工作的团队，例如“client团队”、“server团队”和“DB团队”。意味着这三个团队 – client团队、server团队和DB团队需要协作来完成这个故事。不建议。
  • 方式2：跨组件的团队
    • 每个团队都可以自己实现包括client、server和DB三部分的完整故事。他们可以互相独立工作，这就很好。
  • 我们在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队（方式1），创建跨组件的团队（方式2）。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作”之类的情况发生。不过，要是有很强烈的需求，我们也会临时创建针对特定组件展开工作的团队。
• 是否在sprint之间重新组织团队?
  • “团队凝聚力”是Scrum的核心要素之一，如果一个团队合作工作达多个sprint之久，他们就会变得非常紧密。他们会学会如何达成团队涌流（group flow），生产力会提升至难以置信的地步。不过要达到这个地步需要花上一定时间。如果不断变换团队组成，你就永远无法得到强悍的团队凝聚力。 所以，如果你确实想要重新组织团队，请先考虑一下后果。这是个长期变化还是短期变化？如果是短期变化，最好考虑跳过这一步。如果是长期变化，那就干吧。 这里有个例外：第一次在大型团队中开始实施Scrum的时候，你需要就团队拆分进行一些实验，最后才能找到令所有人全都满意的做法。要确保所有人都能够理解：在最开始几次时犯些错误是可以接受的，只要能够持续改进。
• 怎样进行Scrum-of-scrums
  • Scrum-of-scrums实际上是一个常规会议，是为了让所有的Scrum master聚到一起交流。
  • Scrum-of-Scrums议程安排如下： 1) 每个人围着桌子坐好，描述一下上周各自的团队都完成了什么事情，这周计划完成什么事情，遇到了什么障碍。 2) 其他需要讨论的跨团队的问题，例如集成。
• 是否拆分产品backlog
  • 策略1：一个产品负责人，一个backlog
    • 每个Scrum团队各自选择墙上的一块空白区域，贴上自己团队的名字。那就是他们的“团队墙”。然后他们从最高优先级的故事开始，从产品backlog墙上把故事逐一挪到他们自己的团队墙上。这个过程可以用下面的图片来描述，图中的黄色箭头表示故事卡从产品backlog墙移动到团队墙的过程。
  • 策略 2：一个产品负责人，多个backlog
    • 在这种策略中，产品负责人会维护多个产品backlog，每个团队对应一个。
    • 它的劣势在于，产品负责人要把故事分配给团队，而这项工作交给团队自己处理会更好。
  • 策略 3：多个产品负责人，每人一个产品backlog
    • 它跟第二个策略有点像，每个团队都有一个产品backlog，但每个团队也都有一个产品负责人！
    • 如果两个产品backlog所对应代码库不同，那这样做，就跟把整个产品分成不同的子产品然后独立运作毫无二致。也就表示着我们回到了每个团队一个产品的情况，这样处理起来既愉快又轻松。
• 怎样管理地理位置上分布的团队
  • 应对措施： 1.能够一起结对编程。 2.能够在每日例会上面对面交流。 3.在任何时候都能够面对面讨论。 4.可以真正地碰面与交往。 5.整个团队可以主动举行会议。 6.团队对sprint backlog、sprint燃尽图、产品backlog和其他信息传递设施有相同的理解。 7.每一台工作站前面都配备网络摄像头和耳麦。 8.可以远程通话的会议室，带有网络摄像头、会议用麦克风、随时可用的计算机和桌面共享软件等等。 9.每个地方都有大屏幕，显示其他地点的固定画面。就像两个公寓之间的虚拟窗口一样。你可以看到谁坐在座位前，谁在跟谁说话。这可以增强“我们是在一起工作”的感觉。 10.交换程序。来自每一个地方的人按照某个规律交叉访问。
• Scrum master检查列表
  • sprint开始阶段
    • 1.Sprint计划会议之后，创建Sprint信息页面。 2.在wiki上创建从dashboard指向所创建页面的链接。 3.把页面打印出来，贴在通过你们团队工作区域之外的墙上，让经过的人都可以看到。ƒ给每个人发邮件，声明新的sprint已经启动。邮件中要包括sprint目标和指向sprint信息页面的链接。ƒ更新sprint数据文档。加入估算生产率、团队大小和sprint长度等等。
  • 每一天
    • 1.确保每日Scrum会议可以按时开始和结束。 2.为了保证sprint可以如期完成，需要适当地增删故事。 3.确保产品负责人了解这些变化。 4.确保团队可以及时得知Sprint backlog和燃尽图的最新状况。 5.确保存在的问题和障碍都能被解决，并报告给产品负责人以及（或者）开发主管。
  • 在sprint结束时
    • 1.进行开放式的Sprint演示。 2.在演示开始前一两天，就要通知到每个人。 3.与整个团队以及产品负责人一起开Sprint回顾会议。 4.开发主管也应该受邀参加，他可以把你们的经验教训大范围传播开来。 5.更新sprint数据文档。加入实际生产率和回顾会议中总结出的关键点。
• 其他
  • SCRUM是需要计划的，至少前期需要