【总结】Scrum敏捷开发

• 敏捷开发
• • 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发
  • 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态
• 敏捷4大宣言
• • 个体和交互胜过过程和工具
  • • 人是软件项目获得成功最为重要的因素
    • 合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
  • 可以工作的软件胜过面面俱到的文档
  • • 过多的面面俱到的文档往往比过少的文档更糟
    • 软件开发的主要和中心活动是创建可以工作的软件
    • 编制的内部文档应尽量短小并且主题突出
  • 客户合作胜过合同谈判
  • • 客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
    • 为开发团队和客户的协同工作方式提供指导的合同才是最好的合同
  • 响应变化胜过循环计划
  • • 变化是软件开发中存在的现实
    • 计划必须有足够的灵活性与可塑性
    • 短期的迭代的计划比中长期计划更有效
• 敏捷12大原则
• • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
  • 即使到了开发的后期，也欢迎改变需求
  • 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
  • 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
  • 围绕被激励起来的个人来构建项目
  • 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
  • 工作的软件是首要的进度度量标准
  • 敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度
  • 不断地关注优秀的技能和好的设计会增强敏捷能力
  • 简单化是根本（不做过度设计和预测）
  • 最好的构架、需求和设计出自于自组织的团队
  • 每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整
• 敏捷方法
• • 是一类软件开发流程的泛称
  • 相对于传统的瀑布式软件过程提出的
  • 可以用敏捷宣言（4条）、敏捷原则（12条）来概括
  • 通过一系列的敏捷实践来体现出来
  • 包括
  • • XP
    • Scrum
  • 敏捷和传统项目管理对比
  • • 传统项目管理
    • • 事先对整个项目进行估计、计划、分析
      • 反对变更; 变更需要重新估计、重新规划
      • 严密的合同来减少风险, 如果改变需求要走 CR 流程
      • 项目作为一个“黑盒子” ，对客户与供应商的可视性差
      • 文档和计划驱动的方法
      • 软件交付时间晚, 意识到风险的时间晚
      • WBS,甘特图,关键路径分析
    • 敏捷项目管理
    • • 对整个项目做一个粗略的估计,每一次迭代都有详细的计划
      • 鼓励变化, 客户价值驱动开发
      • 信任和赋予权力;合约使变更变得简单，增加价值
      • 客户和开发人员之间是紧密的连续的合作关系
      • 每次迭代都产生可交付的软件，专注于交付软件
      • 第一次迭代就可交付能工作的版本，风险发现的早
• 为什么用敏捷？
• • 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险
  • 快速交付, 每次迭代都能交付可运行的软件
  • 最高风险和最高优先级的需求，最优先进行开发
  • 改善应对变更能力, 减少大量的重计划
  • 改善项目沟通
  • 更好的客户参与, 避免错误的假设
  • 改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）
• 敏捷实践
• • 增量迭代
  • • 每个迭代有一个大约为1～4周的时间框，在Scrum里称为一次冲刺（超过1个月的详细计划往往偏差很大）
    • 每次迭代都应该有明确的目标
    • 每次迭代都应该有明确的可演示的工作成果
    • 迭代过程中项目团队应该尽量免受打扰
    • 迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解
  • 测试驱动开发 TDD
  • • 一种设计软件的方法，而不仅仅是一种测试方法
    • 所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护
    • 不需要测试的工作不需要完成
    • 所创建的测试用例通常替代详细的业务和技术需求
    • 测试也有效地驱动设计，使设计更加趋向于可行的设计
    • 通常情况下需要自动测试的支持 (EUnit, JUnit etc.)
    • 对于UI软件应用TDD方法有一定的困难
  • 持续集成
  • • 极限编程称为“每日构建”，日构建的好处：
    • • 将集成风险降到最低
      • 降低质量风险
      • 提升士气
    • 日构建可以看做是项目的心跳，冒烟测试就像是听诊器
    • 日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试
  • 面对面交流
  • • 虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代
    • 敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会
    • 尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的
    • 匿名共享需求文档只会打开曲解和误解之门，更不用说书面信息比口头交流还要慢很多
  • 其他
  • • 结对编程
    • 每日立会
    • 用户故事 
    • 频繁发布
    • 自组织团队
    • 重构
• 何时用Scrum？
• • 公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法
  • 敏捷方法对需求不完整以及经常变换的项目比较有效
  • 项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
  • 公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master
  • 项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组
• Scrum理论基础
• • Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险
  • Scrum 的三大支柱支撑起每个经验性过程控制的实现：透明性、检验和适应。Scrum的三大支柱如下
  • • 第一：透明性（Transparency）：透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
    • 第二：检验（Inspection）：开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性
    • 第三：适应（Adaptation）：如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差
  • Scrum中通过三个活动进行检验和适应：
  • • 每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值
    • Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值
    • Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐
• Scrum框架
• • 3个角色
  • • 产品负责人（Product Owner）
    • • 产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同
      • 产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:
      • • 清晰地表达产品代办事项列表条目
        • 对产品代办事项列表中的条目进行排序,最好地实现目标和使命
        • 确保开发团队所执行工作的价值
        • 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
        • 确保开发团队对产品代办事项列表中的条目达到一定程度的理解
        • 产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者
      • 产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人
      • 为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令
      • 确定产品的功能
      • 决定发布的日期和发布内容
      • 为产品的profitability of the product (ROI)负责
      • 根据市场价值确定功能优先级
      • 每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）
      • 接受或拒绝接受开发团队的工作成果
    • 团队（Scrum Team）
    • • 开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量
      • 开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点：
      • • 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能
        • 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能
        • Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外
        • 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队
        • 开发团队不包含如测试或业务分析等负责特定领域的子团队
      • 开发团队的规模
      • • 开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于 3 人的开发 团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会 受到技能限制,从而导致无法交付可发布的产品增量。大于 9 人的团队需要过多的协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和 Scrum Master 的角色不包含在此数字中,除非他们也参与执行 Sprint 代表事项列表中的工作
      • Scrum开发团队的主要职责包括如下五个方面：
      • • 执行Sprint
        • 梳理产品Backlog
        • 做Sprint计划
        • 每天跟进工作进展，并对他们的工作做检查和调整
        • 每个迭代对产品和团队的工作过程做检查和调整
      • 开发团队有如下10方面的特征：
      • • 自组织
        • 多元化、跨职能的完整团队
        • 团队成员符合T型技能，即一专多长
        • 持续改进
        • 最大限制的沟通
        • 透明沟通
        • 2个披萨的团队大小（5-9人）
        • 专注、投入
        • 按照可持续的节奏工作
        • 团队长期存在，人员稳定
    • Scrum Master（Team Leader）
    • • Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。
      • Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值
      • Scrum Master 以各种方式服务于产品负责人,包括：
      • • 找到有效管理产品代办事项列表的技巧
        • 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目
        • 教导开发团队创建清晰简明的产品代表事项列表条目
        • 在经验主义环境中理解长期的产品规划
        • 理解并实践敏捷
        • 按需推动Scrum活动
      • Scrum Master 以各种方式服务于开发团队,包括：
      • • 指导开发团队自组织和跨职能
        • 教导并领导开发团队创造高价值的产品
        • 移除开发团队进展过程中的障碍
        • 按需推动Scrum活动
        • 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队
      • Scrum Master 以各种方式服务于组织，包括：
      • • 领导并指导组织采用 Scrum
        • 在组织范围内计划 Scrum 的实施
        • 帮助员工及干系人理解并实施 Scrum 和经验性产品开发
        • 发起能提升Scrum 团队生产力的变革
        • 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum
  • 5个活动
  • • 概念
    • • Sprints（冲刺）
      • • Scrum的项目过程有一系列的Sprint组成
        • Sprint的长度一般控制在2-4周
        • 通过固定的周期保持良好的节奏
        • 产品的设计、开发、测试都在Sprint期间完成
        • Sprint结束时交付可以工作的软件
        • 在Sprint过程中不允许发生变更
      • 任务板（Task Board）
      • • 任务板（墙）展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整
      • 用户故事（User Story）
      • • 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
        • • 角色：谁要使用这个功能
          • 活动：需要完成什么样的功能
          • 商业价值：为什么需要这个功能，这个功能带来什么样的价值
        • 关于用户故事，Ron Jeffries用3个C来描述它：
        • • 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等
          • 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通
          • 确认（Confirmation）- 通过验收测试确认用户故事被正确完成
        • 用户故事的六个特性- INVEST（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable）
        • • 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性
          • 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通
          • 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事
          • 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）
          • 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大
          • 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的
    • Sprint计划会议（Sprint Planning Meeting）
    • • 决定在Sprint中需要完成哪些工作
      • • 在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作
        • Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量
        • 通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成的工作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的小细节
      • 决定这些工作如何完成
      • • 在会议的第二部分里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成小的单元,每个工作单元不超过一天。之后要完成的工作可以稍⼤些,以后再对它们进行分解
        • 决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责
        • 在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人
        • Sprint计划会议的产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项
        • 最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”
    • 每日站会（Daily Scrum Meeting）
    • • 每日Scrum会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行
      • 最好是每天早晨开，一般15分钟左右，时间比较短，也有利于团队成员安排好当天的工作
      • 每日Scrum会议由Scrum Master主持， Scrum团队所有成员轮流回答以下3个问题
      • • 昨天我完成了什么工作？
        • 今天我打算做什么？
        • 我在工作中遇到了什么困难？
    • Sprint评审会议（Sprint Review Meeting）
    • • Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner
      • 团队展示Sprint中完成的功能
      • 一般是通过现场演示的方式展现功能和架构
      • 不要太正式，不需要PPT，一般控制在2个小时
      • 团队成员都要参加
    • Sprint回顾会议（Sprint Retrospective Meeting）
    • • 团队的定期自我检视，发现什么是好的，什么是不好的
      • 一般控制在15-30分钟
      • 每个Sprint都要做
      • 全体参加
      • Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬
    • 产品Backlog梳理会议（ Product Backlog Refinement）
    • • 产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:
      • • 保持产品待办事项列表有序
        • 把看起来不再重要的事项移除或者降级
        • 增加或提升涌现出来的或变得更重要的事项
        • 将事项分解成更小的事项
        • 将事项归并为更大的事项
        • 对事项进行估算
  • 3个工件
  • • 产品任务（Product Backlog）
    • • 一个需求的列表
      • 一般情况使用用户故事来表示backlog条目
      • 理想情况每个需求项都对产品的客户或用户有价值
      • Backlog条目按照商业价值排列优先级
      • 优先级由产品负责人来排列
      • 在每个Sprint结束的时候要更新优先级的排列
    • 冲刺订单（Sprint Backlog）
    • • 团队成员自己挑选任务，而不是指派任务
      • 对每一个任务，每天要更新剩余的工作量估算
      • 每个团队成员都可以修改Sprint backlog，增加、删除或者修改任务
    • 燃尽图（Burn Down Chart ）
    • • Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日
      • 在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束
      • 由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能略微呈上升趋势
  • 5个价值
  • • 承诺 – 愿意对目标做出承诺
    • 专注– 把你的心思和能力都用到你承诺的工作上去
    • 开放– Scrum 把项目中的一切开放给每个人看
    • 尊重– 每个人都有他独特的背景和经验
    • 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
  • 自组织团队
  • • 什么是自组织团队？
    • • 自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作
    • 自组织团队和经理领导的团队的区别
    • • 理领导的团队
      • • 对于经理领导的团队来说，团队成员被分配任务，团队成员只有执行任务的权利
        • 对于经理领导的团队来说，管理者除了要确定目标、方向，团队的上下文（组织结构、团队结构、团队组成），还需要监督和管理团队的过程和进度，分配任务即确定谁做什么。这种团队的管理方式，更多的是命令与控制，以及微观管理
      • 对于自组织团队来说，他们拥有如下权利：
      • • 团队决定谁做什么，即任务的分配
        • 团队决定如何做，如何实现目标，即团队做技术决策
        • 团队需要在确保目标的前提下制定团队内的行为准则
        • 团队有义务保持过程的透明性
        • 团队监督和管理他们的过程和进度
      • 在自组织团队的环境下，管理层关注在如下几个方面：
      • • 确定团队目标和愿景
        • 确定团队上下文，组织结构、团队结构、团队组成
        • 提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）
        • 授权团队
        • 训练协作
      • 对于自组织团队的普遍误解：
      • • 误解1：团队自己决定目标是什么 ； 纠正：管理层决定团队目标
        • 误解2：团队自己决定谁进入团队； 纠正：管理层决定团队上下文
        • 误解3：团队自己设计团队结构； 纠正：管理层决定团队上下文
        • 误解4：自组织团队不需要管理者； 纠正：管理者从微观管理转向目标驱动、授权团队的管理方式
        • 误解5：自组织团队需要员工更加主动； 纠正：自组织让团队更加主动，每个人都不喜欢被命令和控制，每个人期望有成就感、期望被认可
        • 误解6：自组织团队想干什么就干什么； 纠正：管理层决定团队目标，团队决定如何实现目标
      • 一个自组织的团队通常由不同职能专业、思考方式和行为模式的成员组成，也就是说它是跨职能的团队
      • 自组织的团队不是与生俱来的，打造一个团队需要一个过程，打造一个组织团队也是一样。打造自组织团队，首先要让团队需要完全自主； 其次，有了自主，管理者需要引导团队持续改进，帮助团队持续地挑战更高的目标；第三，给团队提供环境和支持，引导团队往正确地方向迈进
• Scrum Master检查单
• • 一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议，控制时间盒以及处理团队成员提出的障碍的话，你可以将这个角色当作成兼职来对待。在这种情况下，团队仍然有可能达到预期的目标，而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候，你就成为了一位出色的ScrumMaster
  • 一位出色的ScrumMaster一次能够负责一个团队
  • 我们推荐每个7人左右的团队都有一位专职的ScrumMaster，尤其是刚开始实施Scrum的时候
  • 如果你还没有发现你能够做的事情的话，尝试聆听Product Owner，团队还有团队以外的公司成员的想法。下面我列出了一些ScrumMaster常忽略的东西
  • Product Owner干得怎么样？
  • • 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。（需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。）
    • 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗？是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了？要记得待办事列表是涌现的。
    • 产品待办事列表的大小是否还能够维护呢？为了使列表更容易维护，应该将细粒度的项目放在靠前的位置，而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间，效果只会适得其反，因为你的需求会在团队和客户/股东的持续谈话中发生变化。
    • 需求（特别是在产品待办事列表最顶端的需求）能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗？
    • 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗？其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
    • 待办事列表是不是能让所有股东都能够看懂？
    • 如果你正在使用自动工具来管理你的待办事列表，想一下它真的能够帮助你吗？自动化的管理工具有可能成为ScrumMaster了解信息的障碍。
    • 你能够通过有效地把信息打印出来然后传达给其他人吗？
    • 你能够通过制订可视化图表来传达足够的信息吗？
    • 你有曾经帮助过Product Owner整理待办事列表项目，然后分配到不同的版本中去吗？
    • 是否所有人（包括股东和团队）都知道目前的团队速率是否能够赶上发布的计划呢？
    • Product Owner有根据上次Sprint评审会议来调整发布计划吗？通常Product Owner应该至少在个Sprint之后调整发布计划，一般来说会把一些工作放到后面的版本中，原因是发现了一些更重要的工作要做。你可以在每个 Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图，这样就可以更早地发现当前的进度是不是能够符合预期。
  • 团队做得怎么样？
  • • 团队成员是否在大多数时间里都能够进入“流”的状体？下面是这种状态的一些特征（摘录自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi）：
    • • 有清晰的目标
      • 集中且专注，高度集中在某个特定的领域或事物上
      • 失去自我意识，完全沉浸在动作和兴趣中
      • 扭曲的 时间感受，只能感受到主观世界的时间
      • 直接和立即的反馈（无论是成功还是失败都能够马上感知到，以马上对行为进行调整）
      • 在能力和挑战之间保持平衡
      • 自我的控制能力
      • 行为能够从本质上有所回报，所以感觉毫不费力。
    • 团队成员之间相处得怎么样？气氛融洽吗？有为彼此的成功感到高兴吗？
    • 团队成员之间会以高标准要求对方吗？会互相挑战来促进成长吗？
    • 有没有一些事情团队会觉得不舒服而避免讨论的？（详见：Crucial Conversations: Tools for Talking When Stakes are High）或者引入专家来缓解不安的谈话情绪。
    • 有没有试过以不同方式或者在不同地点举行Sprint回顾会议？详见：Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen)
    • 团队在开发过程中有没有集中在验收标准上？也许你应该在Sprint当中举行一次会议来评审当前Sprint所承诺的产品待办事列表项目的验收标准。
    • Sprint待办事列表能够真正反映出团队正在做的事情吗？所有对Sprint的目标的打断和干扰都应该被视为障碍。
    • 团队有保持更新任务版吗？
    • 团队的任务版和燃尽图都能够很容易地被团队看见和使用吗？
    • 团队成员都能够自己领取任务吗？
    • 团队能够被保护得足够好而避免微管理吗？
    • 用于解决技术债务的事项都能够在待办事列表里面反映出来吗？还是需要和Product Owner另外沟通呢？
    • 团队成员会在团队的房间外忽略自己的职称吗？
    • 是不是整个团队都将团队看作一个整体，对测试和编写文档共同担当责任呢？
  • 工程实践进行得怎么样？
  • • 你们正在开发的系统有“开始测试”按钮能让每个都很容易地察觉到自己是否破坏了某些功能呢？通常这个是靠xUnit框架来实现的（JUnit，NUnit等等）。
    • 你们能够在自动化端对端系统测试和自动化单元测试之间保持平衡吗？
    • 团队在开发系统功能测试和单元测试的时候使用的是同一种语言吗（而不是使用团队里只有部分成员懂的脚本语言）？这个是可能的。
    • 你的团队能够发现系统测试和单元测试之间的灰色地带吗？
    • 你们的持续集成服务器能够在回归测试出现错误的一个小时（或者一分钟）内自动发出警报吗？
    • 所有的测试都能够在CI服务器的测试结果报告中反映出来吗？
    • 团队能够发现持续设计和无情的重构，而不是一开始就进行详细的设计带来的乐趣吗？重构拥有一个严格的定义：改变系统的内部结构而不改变其外部行为。重构需要在每个小时内进行多次，每当有重复代码，复杂的条件逻辑（通常表现为过量的缩进和冗长的方法），糟糕的命名，对象间的过度耦合，一个对象的职 责过多等等问题出现的时候就需要进行重构。要在重构的时候有充足的信心，就要有足够的自动化测试覆盖率。测试覆盖率的漏洞和推迟的重构被称作技术债务。
    • 在你的每个产品待办事列表项目的验收标准中都包含了完全自动化测试和代码重构这两项吗？如果不学习使用极限编程的工程实践，你就不可能在每个Sprint都能完成潜在可交付的产品（正如Kent Beck, Ron Jeffries等人所说的）。
    • 团队成员多数时间都在结对编程吗？结对编程可以大幅度提高代码的可维护性，也可以大大降低bug出现的机率。但是有时候结对编程实在挑战大家的极限，有时候甚至会使完成任务的时间变长（如果我们更重视数量而不是质量的话）。所以，比较推荐的做法是和团队成员先讨论以选择在一周内大家愿意尝试使用结对编程的时间，而不是从一开始就强迫团队使用结对编程。然后慢慢地，部份人会开始喜欢结对编程的。
  • 整个公司的做得怎么样？
  • • 团队之间有没有适当地交流合作呢？Scrum of Scrums是唯一的解决方案。也可以考虑在团队中选出代表参加别的团队的每日站会。
    • ScrumMaster之间有互相交流吗？
    • 来自公司内部的困难会在适当的时候被贴到开发总监的办公室的墙上吗？成本能够以金钱、丢失市场的份额、损失的质量或者损失的客户来量化吗？
    • 你的公司的职业发展道路和你的团队的集体目标相符吗？如果以测试、自动化测试或者开发文档为代价来鼓励编程或者设计架构，那么答案就是否定的。
    • 你能够帮助公司成为一个学习型企业吗？
    • 你的公司已经被外界认定为最好的工作场所或者业界的领头羊了吗？