敏捷开发框架
Scrum通常被认为是一个敏捷开发项目管理框架，它描述了一组协同工作的会议、工具和角色，以帮助团队组织和管理其工作。
一、什么是Scrum
Scrum是一个帮助团队协同工作的框架。就像橄榄球队（它的名字的由来）为大型比赛进行培训一样，Scrum 鼓励团队从经验中学习，以自组织的方式去处理问题，并对他们的胜利和失败反思以不断改进。
虽然我们说Scrum 最常被软件开发团队使用，但它的原则和经验教训可用于各种团队合作，这也是 Scrum 如此受欢迎的原因之一。Scrum通常被认为是一个敏捷开发项目管理框架，它描述了一组协同工作的会议、工具和角色，以帮助团队组织和管理其工作。
二、常用的敏捷开发框架：Scrum
人们通常认为 Scrum 和敏捷开发是同一回事，因为 Scrum 关注持续改进，而这是敏捷开发的核心原则。
但是，Scrum 是完成工作的一种框架，而敏捷开发是一种思维模式。
仅凭 Scrum 你无法真正“敏捷化”，因为这需要整个团队一致努力才能改变其向客户交付价值的思维方式。
但是，您可以使用 Scrum等框架来协助您开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷工作流原则。
Scrum框架是一种基于持续学习和波动因素调整的启发式框架。它承认团队在项目开始时并不了解所有内容，并通过吸取经验教训不断发展。Scrum的结构旨在帮助团队自然而然地适应不断变化的条件和用户要求，并在流程和较短的发布周期中重新调整优先级，以便您的团队不断学习和改进。
虽然 Scrum是结构化框架，但它并不是完全僵化的，你可以根据组织需求调整其执行。关于 Scrum 团队如何才能成功有很多的理论。
但是，十多年来，在帮助 PingCode 敏捷开发团队完成工作的过程中，我们发现，无论您选择何种框架，清晰的沟通、透明度和致力于持续改进始终都是框架的核心。
1、Scrum获得成功所需的三个重要角色
Scrum 团队需要三个特定角色：产品负责人(Product Ower)、ScrumMaster和Scrum 团队。由于 Scrum 团队为跨职能部门，因此除开发人员之外，开发团队还包括测试人员、设计人员、用户体验 (UX) 专家和运营工程师。
主要负责构建正确的产品，确定 Scrum 团队交付什么并解释为什么做这些工作。产品负责人是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：
- 构建和管理产品待办事项。
- 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
- 明确指导团队接下来提供哪些功能。
- 确定何时发布产品，且倾向于更频繁地交付产品。
产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。
主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践。Scrum master 是其团队中在 Scrum 方面的佼佼者。
他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法细调他们在此方面的实践。高效的Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为最主要的推动者，此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源（人力和物力）。
负责以正确的方式构建产品，执行具体工作任务。Scrum团队是具体工作的执行者，成员通常为 5 到 7 名。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。团队成员具有不同的技能，并且彼此互相锤炼，因此没有人会成为交付工作的瓶颈。
强大的Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成冲刺。
Scrum团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。
2、Scrum 工件
工件是我们完成的事情，就像是解决问题的工具。在 Scrum 中，这三个工件分别是产品待办事项、冲刺（Sprint）待办事项，以及对“已完成”定义的增量变化。
它们是 Scrum团队中的三个常量，我们会不断地对其进行重新审视，并投入额外的时间进行改进。
产品待办事项（Product Backlog）
产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。
本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或是可能会以其他方式解决问题。
产品目标：Product Goal
Product Goal 描述了产品的未来状态，可以作为Scrum Team 制定计划的目标。Product Goal 在Product Backlog 中。Product Backlog 的其余部分涌现，用来定义“做什么”将实现 Product Goal。
产品是传递价值的载体，它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。Product Goal 是 Scrum Team 的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。
冲刺待办事项（Sprint Backlog）
冲刺待办事项列表，一个冲刺目标阶段内的用户故事列表。这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级最高的用户故事放入迭代。
每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。
冲刺：Sprint Goal
Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。Sprint Goal 还创造了连贯性和专注点，鼓励 Scrum Team 一起工作而不是分开独自行动。
Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次Sprint Backlog 的范围。
增量
增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。
在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护最好保持开放态度。比如“已完成”、“故事点”重新定义能更好的提升效率和品质，那你完全可以根据需求进行新的定义。
你应该像处理产品一样敏捷地处理 Scrum 框架，花一些必要的时间来检查事务的进展情况（无论是通过PingCode 这样的工具或者是其他），并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。
3、Scrum 仪式
Scrum 框架中一些更为人所知的组件包括 Scrum团队定期举行的一系列会议。在这些仪式中，我们可以看到团队之间的最大差异。
例如，有些团队发现举行所有这些仪式既繁琐又重复，而另一些团队则将这些仪式作为必要的登记手段。我们的建议是，在两次冲刺阶段使用所有仪式，然后看看其效果。接着，你可以进行快速回顾，看看可能需要进行哪些调整。
以下是Scrum 团队可能参加的所有重要仪式清单：
需求梳理会(Backlog Grooming Meeting)
有时也被称为待办事项梳理，它由产品负责人负责。产品负责人的主要工作是协助实现产品愿景，并持续关注市场和客户。因此，客户可根据用户和开发团队的反馈来维护此列表，以协助确定列表的优先级并保持整洁，同时准备在任意给定时间进行工作。
Sprint计划会(Sprint planning meeting)
由整个开发团队在本次会议期间规划当前冲刺期间要执行的工作（范围）。本次会议由 Scrum MAster主持，而团队则在会议期间决定冲刺目标。接着，可将产品待办事项中的特定用途故事添加到冲刺中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在冲刺期间完成。 在规划会议结束时，每位 Scrum 成员均需清楚在冲刺期间可以交付的内容，以及如何交付增量变化。
冲刺（Sprint）
冲刺是 Scrum团队共同完成增量的实际时间段。两周是一个相当典型的冲刺时长，尽管某些团队发现一周更容易确定范围，或是一个月更容易提供有价值的增量变化。
但国外知名敏捷教练 Dave West 建议，工作越复杂，未知因素就越多，而冲刺就应该越短。但事实上，这取决于团队，而如果不起作用，团队也可以进行改变！ 所有事件（从规划到回顾）都是在冲刺期间发生的。
一旦确定了冲刺的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的冲刺。
Scrum每日站会(Daily Standup Meeting)
这是每天在同一时间（通常是早晨）和地点举行的超短例会，以确保此会议简洁明了。很多团队试图在15 分钟内完成会议，但这只是一个参考。此会议也被称为“每日短会”，它强调需快速举行会议。
每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着冲刺目标努力，并制定未来 24 小时的计划。 你可在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的问题。
每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题：
• 我昨天做了什么？
• 我今天打算做什么？
• 是否存在障碍？
然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。
因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。
Sprint评审会(Sprint Review Meeting)
在冲刺结束时，团队聚集在一起进行非正式会议，以观看增量演示或检查增量。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项，以征求他们的反馈意见。
尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。此次审核会议也是产品负责人根据当前冲刺重新处理产品待办事项之时，当前冲刺可为下一次冲刺规划会议提供相关信息。
对于为期一个月的冲刺，可考虑将您的冲刺审核时间限制为最长四个小时。
Sprint回顾会(Sprint Retrospective Meeting)
是指团队聚集在一起共同记录和讨论冲刺、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。
我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。
作者：CLAIRE DRUMOND