敏捷教练----Scrum-概述

https://www.atlassian.com/agile

3.1 总览
       Scrum是一个框架，可以帮助团队一起工作。就像橄榄球队（以此为名）为大型比赛训练一样，Scrum鼓励团队学习经验，在解决问题时自我组织，并反思自己的得失，以不断提高。
       虽然我所谈论的Scrum最常被软件开发团队使用，但是它的原理和课程可以应用于各种团队合作。这是Scrum如此受欢迎的原因之一。人们通常认为Scrum是一种敏捷的项目管理框架，它描述了一组会议，工具和角色，它们可以协同工作，以帮助团队构建和管理其工作。
       在本文中，我们将在Scrum Guide和Scrum.org首席执行官David West 的帮助下讨论传统的Scrum框架是如何  构成的。我们还将提供一些示例，说明我们如何看待客户偏离这些基本要求以适应其特定需求。
 3.1.1 框架
       人们常常认为Scrum和敏捷是同一回事，因为Scrum围绕着持续改进，这是敏捷的核心原则。但是，Scrum是敏捷完成工作的心态，是完成工作的框架。您无法真正做到“敏捷”，因为整个团队需要全心全意地改变他们考虑为客户提供价值的方式。但是您可以使用Scrum之类的框架来帮助您开始以这种方式思考，并在日常的沟通和工作中实践敏捷原则的构建。
       Scrum框架是启发式的。它基于不断学习和对波动因素的调整。它承认团队在项目开始时并不了解所有内容，并且会通过经验不断发展。Scrum的结构旨在帮助团队自然地适应不断变化的条件和用户要求，并在流程中内置了重新优先级和较短的发布周期，因此您的团队可以不断学习和改进。
       虽然Scrum是结构化的，但它并不完全僵化。可以根据任何组织的需求量身定制其执行方式。关于成功团队，Scrum团队必须如何工作的理论很多。但是，在帮助敏捷团队在Atlassian上完成工作十多年之后，我们了解到清晰的沟通，透明性和持续改进的奉献精神始终应该是您选择的任何框架的核心。其余的取决于您。
 3.1.2 Scrum工件
       让我们从识别scrum中的三个工件开始。工件是我们制造的东西，就像解决问题的工具。在Scrum中，这三个工件是一个产品待办事项列表，一个sprint待办事项列表，以及一个带有“完成”定义的增量。这是scrum团队中的三个常量，我们会不断地重新审视和投资。

•  产品待办事项列表是产品所有者或产品经理需要完成的工作的主列表。这是作为sprint backlog输入的特性、需求、增强和修复的动态列表。本质上，它是团队的“任务”列表。产品backlog会被产品所有者不断地重新访问、重新划分优先级和维护，因为随着我们了解的更多或者随着市场的变化，项目可能不再相关，或者问题可能会以其他方式得到解决。
• Sprint Backlog是项目、用户故事或bug修复的列表，由开发团队选择在当前Sprint周期中实现。在每个sprint之前，在sprint计划会议(我们将在本文后面讨论)中，团队从产品backlog中选择它将为sprint处理的项目。sprint backlog可能是灵活的，可以在sprint中演进。然而，基本的sprint目标——团队希望从当前的sprint中实现什么——是不能妥协的。
• 增量(或冲刺目标)是冲刺中可用的最终产品。在Atlassian，我们通常会在sprint演示结束时演示“增量”，团队会展示在sprint中完成了什么。你可能在世界上听不到“增量”这个词，因为它通常被认为是团队对“完成”、里程碑、sprint目标、甚至是完整版本或已发布的史诗的定义。这取决于你的团队如何定义“完成”以及你如何定义你的sprint目标。例如，一些团队选择在每个sprint结束时向客户发布一些东西。所以他们对“完成”的定义就是“发货”。然而，这对于其他类型的团队来说可能是不现实的。假设您正在开发一个基于服务器的产品，该产品每个季度只能交付给客户。你仍然可以选择在两周的冲刺中工作，但你对“完成”的定义可能是完成一个更大版本的一部分，你计划一起发布。当然，软件发布的时间越长，软件偏离目标的风险就越大。

       正如您所知道的，您的团队可以选择定义许多变体，甚至在工件中也是如此。这就是为什么对如何维护工件保持开放的态度是很重要的。也许您对“完成”的定义为您的团队提供了撤消压力，您需要返回并选择一个新的定义。
 3.1.3 Scrum仪式或活动
       Scrum框架中一些比较知名的组件是Scrum团队定期执行的一系列连续事件、仪式或会议。仪式是我们看到团队变化最多的地方。例如，一些团队发现所有这些仪式都是繁琐和重复的，而另一些团队将它们作为必要的检查。我们的建议是在开始的时候用所有的仪式进行两次短跑，然后看看感觉如何。然后，您可以执行一个快速回顾，看看您可能需要调整的地方。
     下面是scrum团队可能参与的所有关键仪式:

1. 组织待办事项:有时称为待办事项梳理，此事件由产品负责人负责。产品负责人的主要工作是将产品推向其产品愿景，并对市场和客户保持持续的关注。因此，他/她使用来自用户和开发团队的反馈来维护这个列表，以帮助确定优先级，并保持列表的整洁，以便随时处理。您可以在这里阅读关于维护健康的backlog的更多信息。
2. Sprint计划:在当前Sprint期间要执行的工作(范围)是由整个开发团队在会议期间计划的。这个会议由scrum master主持，是团队决定sprint目标的地方。特定的用例然后从产品backlog中添加到sprint中。这些故事总是与目标保持一致，scrum团队也同意在sprint中实现这些故事是可行的。在计划会议结束时，每个scrum成员都需要清楚在sprint中可以交付什么，以及如何交付增量。
3. Sprint: Sprint是scrum团队共同完成一个增量的实际时间段。对于sprint来说，两周是一个相当典型的长度，尽管有些团队发现一周更容易确定范围，或者一个月更容易交付有价值的增量。来自Scrum.org的Dave West建议说，工作越复杂，未知越多，冲刺应该越短。但是这取决于您的团队，如果它不起作用，您不应该害怕更改它!在此期间，如果需要，可以在产品所有者和开发团队之间重新协商范围。这构成了scrum经验主义本质的关键。所有的事情——从计划到回顾——都发生在冲刺阶段。一旦确定了某个sprint的时间间隔，它就必须在整个开发期间保持一致。这有助于团队从过去的经验中学习，并将这种洞察力应用到未来的sprint中。
4. 每日例会或站会:这是一个每天在同一时间(通常是早上)举行的超短会议，目的是保持会议的简单。许多团队试图在15分钟内完成会议，但这只是一个指导方针。这次会议也被称为“每日站立会议”，强调会议必须迅速进行。每日例会的目标是让团队中的每个人都在同一个页面上，与sprint的目标保持一致，并制定出未来24小时的计划。
   站会是表达你对实现sprint目标或任何阻碍因素的担忧的时候。
   在实现sprint目标的过程中，每个团队成员都要回答三个问题:
        我昨天做了什么?
        我今天打算做什么?
        有什么障碍吗?
   然而，我们看到会议很快变成了人们阅读昨天和明天的日历。“站起来”背后的理论是，它能让人们在日常会议上分心，这样团队就能在一天剩下的时间里专注于工作。所以，如果它变成了每天的日历，不要害怕改变它，变得有创意。
5. Sprint审查:在Sprint结束时，团队聚在一起进行非正式的会议，以查看或检查增量的演示。开发团队向涉众和团队成员展示现在已经“完成”的待办事项，以获得反馈。产品所有者可以决定是否发布增量，尽管在大多数情况下，增量是发布的。这个评审会议也是产品负责人根据当前sprint重新设计产品待办事项列表的时候，它可以提供给下一个sprint计划会议。对于一个月的冲刺，考虑将你的冲刺回顾时间限制在最多四个小时。
6. Sprint回顾:回顾是团队聚集在一起，记录和讨论在Sprint、项目、人员或关系、工具，甚至某些仪式中什么是有效的，什么是无效的。我们的想法是创建一个地方，让团队能够专注于哪些工作进展顺利，哪些需要在下一次改进，而不是关注哪里出了问题。

3.1.4 scrum成功的三个关键角色
       scrum团队需要三个特定的角色:产品负责人、scrum master和开发团队。因为scrum团队是跨功能的，开发团队除了开发人员外，还包括测试人员、设计师、UX专家和ops工程师。
Scrum产品负责人
       产品所有者是他们产品的拥护者。他们专注于了解业务、客户和市场需求，然后根据需要对工程团队的工作进行优先排序。有效的产品负责人:
      建立和管理产品待办事项列表。
      与业务和团队紧密合作，确保每个人都理解产品待办事项列表中的工作项。
      为团队提供下一步要交付哪些特性的清晰指导。
      决定什么时候装运产品，以便更频繁地交付。
      产品负责人并不总是产品经理。产品负责人关注于确保开发团队向业务交付最大的价值。此外，产品负责人必须是一个独立的人，这一点也很重要。没有一个开发团队需要来自多个产品所有者的混合指导。
Scrum大师
      Scrum大师是团队中Scrum的拥护者。 他们在Scrum流程中指导团队，产品所有者和企业，并寻找微调其实践的方法。
      一个有效的Scrum主管深刻理解团队正在做的工作，可以帮助团队优化其透明度和交付流程。 作为总主持人，他/她为冲刺计划，站立，冲刺审查和冲刺回顾计划了所需的资源（人力和后勤）。
Scrum开发团队
      Scrum团队完成了s*%&。他们是可持续发展实践的倡导者。最有效的scrum团队是紧密联系的、共同定位的，通常有5到7名成员。计算团队规模的一种方法是使用亚马逊(Amazon)首席执行官杰夫?贝佐斯(Jeff Bezos)提出的著名的“两个披萨规则”(团队规模应小到足以分享两个披萨)。
       团队成员拥有不同的技能，并且相互交叉培训，因此没有一个人成为工作交付的瓶颈。强大的scrum团队是自组织的，并以明确的“我们”态度处理项目。团队的所有成员互相帮助，以确保成功完成sprint。
       scrum团队为每个sprint制定计划。他们以历史速度为指导，预测他们相信在迭代中可以完成多少工作。保持迭代长度不变给开发团队提供了关于他们的评估和交付过程的重要反馈，这反过来又使他们的预测随着时间的推移越来越准确。
 3.1.5 Scrum，看板和敏捷
       Scrum是如此受欢迎的敏捷框架，以至于Scrum和敏捷经常被误解为一回事。但是还有其他的框架，比如看板，这是一种流行的替代方法。一些公司甚至选择采用scrum和看板的混合模型，这被称为“Scrumban”或Kanplan，即带待办事项列表的看板。
scrum和看板都使用可视化的方法，如scrum board或看板来跟踪工作进度。两者都强调效率，并将复杂的任务分解成更小的、可管理的工作，但他们实现目标的方法是不同的。
       Scrum关注较小的、固定长度的迭代。一旦确定了sprint的时间段，就可以确定在这个sprint周期中可以实现的故事或产品backlog条目。然而，在看板中，当前周期中要实现的任务数量或正在进行的工作(WIP限制)在一开始是固定的。然后向后计算实现这些特性所需的时间。
       看板不像scrum那样结构化。除了WIP的限制外，它是相当开放的解释。然而，Scrum有几个分类的概念作为其实现的一部分强制执行，比如sprint 审查、回顾、每日Scrum等等。它还坚持跨功能，这是scrum团队不依赖外部成员来实现目标的能力。组建一个跨职能团队并非易事。从这个意义上说，看板更容易适应，而scrum可以被认为是开发团队思维过程和功能的根本转变。
       但是,为什么用scrum ?
       scrum框架本身很简单。规则、工件、事件和角色都很容易理解。它的半规范方法实际上帮助消除了开发过程中的模糊性，同时为公司提供了足够的空间来引入它们各自的风格。
        将复杂的任务组织成可管理的用户故事，对于困难的项目非常理想。此外，角色和计划事件的明确划分确保了整个开发周期的透明性和集体所有权。快速发布可以让团队保持动力，让用户满意，因为他们可以在短时间内看到进展。
        然而，Scrum可能需要时间来掌握，尤其是当开发团队已经适应了典型的瀑布模型时。较小的迭代、每日scrum会议、sprint评审以及确定scrum master等概念对于一个新团队来说可能是一个具有挑战性的文化转变。
        但是，长期的收益远远超过最初的学习曲线。Scrum在开发跨不同行业和垂直领域的复杂硬件和软件产品方面的成功，使其成为您的组织采用的引人注目的框架。