敏捷开发 scrum

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1                  

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

3个角色

1. 产品负责人（Product Owner）
2. Scrum Master
3. 开发团队

3个工件

1. 产品Backlog（Product Backlog）
2. SprintBacklog
3. 产品增量（Increment）

5个事件

1. Sprint（Sprint本身是一个事件，包括了如下4个事件）
2. Sprint计划会议（Sprint Planning Meeting）
3. 每日站会（Daily Scrum Meeting）
4. Sprint评审会议（Sprint Review Meeting）
5. Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

透明（在软件开发过程的各个环节保持高度的可见性）、检验（工作完成的效率，检验工作成果人员的技能水平和积极性。）、适应（最终产品是不合格）

过程控制通常有两种方式，第一种方式是预定义的过程，第二种方式是经验性过程。

“在过程运行机制相当简单易懂的情况下，典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围，便应用经验性方式。”

产品待办事项列表通常以价值、风险、优先级和必须性排序

产品负责人至少在每个 Sprint 评审的时候追踪剩余工作总量。

开发团队每天追踪剩余总和并预测 达成 Sprint 目标的可能性。通过在 Sprint 中不断追踪剩余工作,开发团队可以管理自己 的进度。

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

5个事件

（1）

每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于 完成某些事情。每个 Sprint 都会定义要开发什么，还有一份设计过和灵活的计划用来指导 如何做这些事、工作内容和最终产品。

如果 Sprint 目标过时，那么 Sprint 就会被取消。所有未完成的产品待办列表 项都会被放回到产品待办列表中，并重新估算。取消 Sprint 会消耗资源，因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一 个 Sprint 。

（2）

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预 测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团 队可以评估接下来的 Sprint 可以完成什么工作。

在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天 或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

了达成 Sprint 目标，需要实现相应的功能 和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

（3）

每日 Scrum 站会是一个以 15 分钟为限的事件，它让开发团队同步开发活动，并为接下了的24小时制定计划

每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。在会议上，每一个开发团队 成员都需要说明:

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么?
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
• Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。
  
• Scrum Master 强制执行每日 Scrum 站会规则——只有开发团队成员才能参加。

（4）

Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办 列表。

对于长度为一个月的 Sprint 来说，评审会议的限时为 4 小时。对于较短的 Sprint 来说，会 议的时间会有所缩短

• 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议;
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决 的;
• 开发团队演示“完成”的工作并解答关于所交付增量的问题;
• 产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话);
• 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息;
• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;同时，
• 为下个预期产品版本的发布评审时间表、预算、潜力和市场。

（5）

Sprint 回顾会议发生在 Sprint 评审会议结束之后

对于长度为 一个月的 Sprint 来说，会议的限时为 3 小时。对于较短的 Sprint 来说，会议时间通常会缩 短。Scrum Master 要确保会议举行

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;
• 找出并加以排序做得好的和潜在需要改进的主要方面;同时,
• 制定改进 Scrum 团队工作方式的计划。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下 一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视 而做出的适当调整。

SCRUM的四大支柱

（1）

在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。

迭代的长度是固定

这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

（2）

增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 

无论产品负责人是否决定真正发布它,增量必须可用

（3）

自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。

（4）

Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。

在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

SCRUM团队

Scrum开发团队的主要职责包括如下五个方面：

• 执行Sprint
• 梳理产品Backlog
• 做Sprint计划
• 每天跟进工作进展，并对他们的工作做检查和调整
• 每个迭代对产品和团队的工作过程做检查和调整

• 开发团队有如下10方面的特征：

  • 自组织
  • 多元化、跨职能的完整团队
  • 团队成员符合T型技能，即一专多长
  • 持续改进
  • 最大限制的沟通
  • 透明沟通
  • 2个披萨的团队大小（5-9人）
  • 专注、投入
  • 按照可持续的节奏工作
  • 团队长期存在，人员稳定

  对于自组织团队来说，他们拥有如下权利：

  • 团队决定谁做什么，即任务的分配
  • 团队决定如何做，如何实现目标，即团队做技术决策
  • 团队需要在确保目标的前提下制定团队内的行为准则
  • 团队有义务保持过程的透明性
  • 团队监督和管理他们的过程和进度

  在自组织团队的环境下，管理层关注在如下几个方面：

  • 确定团队目标和愿景
  • 确定团队上下文，组织结构、团队结构、团队组成
  • 提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）
  • 授权团队
  • 训练协作
  特性团队
  

如果我们的产品开发团队只有在10人以内，我们使用一个跨职能的Scrum团队，可以很容易地按照scrum和敏捷的方式开发产品。 

如果产品团队规模较大， 考虑团队的结构和组织方式。

在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式

按照Scrum和敏捷的交付模式，组件团队有如下一些限制：

第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。

第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。

第三：由于职责单一，限制了学习，使得专业更加单一化

第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付

特性团队的特点：

• 长期稳定的团队，逐个端到端完成客户特性
• 以客户为中心的特性驱动
• 跨职能、完整团队
• 共享代码库，统一的持续集成
• 拥有通用型专家
• 
  

• 特性团队的好处：

  • 团队内可以做到端到端，所以减少了等待，周期加快
  • 比较容易在一个Sprint中交付可用的产品增量
  • 减少了团队之间依赖，计划会更容易
  • 责任范围的扩大，各种不同领域的专家在一个团队，增加了
  • 个人学习和团队学习的机会

  用户故事的六个特性- INVEST

  INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

  一个好的用户故事应该遵循INVEST原则。

  • 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
  • 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
  • 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
  • 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
  • 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
  • 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
  敏捷估算

• 估算扑克的使用方法：

  • 每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
  • 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。
  • 团队讨论这个条目。
  • 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。
  • 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数”1,2,3″,大家同时展示估算结果。
  • 团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？讨论之后可以再估算一轮，最终团队需要达成一致。
  • 回到第二步，开始估算下一个条目。
  估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算
  

• 记录每个Sprint的团队速度

  团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数，通过团队速率可以知道团队做的有多快。新开始的项目或产品开发，或者是新团队，没有初始速度，我们可以做1-2个Sprint测算一个速度，作为初始速度。在Sprint执行过程中，我们要记录每个Sprint的速度，为以后的计划做参考。

  
  
• 
  

• 在Sprint进行过程中，如下内容不能发生变化：

  • Sprint的目标
  • Sprint的质量目标和验收标准
  • 开发团队的组成

  集中优势兵力各个击破

  在Sprint执行的过程中，团队要避免一个萝卜一个坑的工作方式，团队要协作，并且要集中优势兵力各个击破。

  团队按照蜂拥式（Swarming）的工作方式，团队先集中工作在少数几个需求上面，协作完成它们，然后在开始下一批需求。按照这样的方式一方面可以加强团队协作，另外也有利于及早完成一些需求，让这些需求及早验收。

  
  

• 为什么每日站会没有效果？

  每日站会和传统的项目会议有如下几点不同：

  1.       不会有ScrumMaster或者其他任何人来指派任务。

  2.       团队成员不是向ScrumMaster汇报情况，每日站会是团队自己的会。

  3.       团队成员不会在会上讨论或者解决问题，大家会把问题记录下来，会后找相关的人讨论或召开具体的讨论会议。

  4.       任何团队之外的人不得发言或干扰会议。

  Scrum的最基本原则是“Inspect and Adapt”(检视然后适应)，如果什么事情做得很好，问问自己为什么，然后寻找提升的办法。

  Martin Fowler’s 《Patterns of Daily Stand-up Meetings》

  你如何知道每日站会起到了很好的效果？

  一个好的每日站会有如下几个特点：

  1.       ScrumMaster不会逐个的问每个人问题，如果是，那么这个会议已经沦为了报告会。

  2.       团队成员互相交流，不是向ScrumMaster报告。

  3.       每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会，你就不需要再担心超时了。

  4.       站会结束后，ScrumMaster知道哪些问题需要帮助团队成员解决。

  一个自组织的团队有一个非常明显的每天的节奏：Daily Scrum之前非常安静，每日站会之后会有一段活跃的讨论，到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论，当下班前慢慢的安静下来。

  
  

• 完成的定义

• 每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。

  随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。

  需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。

  SCRUM MASTER检查单

  一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议，控制时间盒以及处理团队成员提出的障碍的话，你可以将这个角色当作成兼职来对待

• 我们推荐每个7人左右的团队都有一位专职的ScrumMaster，尤其是刚开始实施Scrum的时候。
  

• Product Owner干得怎么样？

  • 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。（需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。）
  • 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗？是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了？要记得待办事列表是涌现的。
  • 产品待办事列表的大小是否还能够维护呢？为了使列表更容易维护，应该将细粒度的项目放在靠前的位置，而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间，效果只会适得其反，因为你的需求会在团队和客户/股东的持续谈话中发生变化。
  • 需求（特别是在产品待办事列表最顶端的需求）能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗？
  • 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗？其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
  • 待办事列表是不是能让所有股东都能够看懂？
  • 如果你正在使用自动工具来管理你的待办事列表，想一下它真的能够帮助你吗？自动化的管理工具有可能成为ScrumMaster了解信息的障碍。
  • 你能够通过有效地把信息打印出来然后传达给其他人吗？
  • 你能够通过制订可视化图表来传达足够的信息吗？
  • 你有曾经帮助过Product Owner整理待办事列表项目，然后分配到不同的版本中去吗？
  • 是否所有人（包括股东和团队）都知道目前的团队速率是否能够赶上发布的计划呢？
  • Product Owner有根据上次Sprint评审会议来调整发布计划吗？通常Product Owner应该至少在个Sprint之后调整发布计划，一般来说会把一些工作放到后面的版本中，原因是发现了一些更重要的工作要做。你可以在每个Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图，这样就可以更早地发现当前的进度是不是能够符合预期。