Scrum

什么是用户故事？用户故事是简短而简单的功能描述。它们是从系统的用户或客户的角度编写的。它们通常遵循简单的格式：作为[用户类型]，我希望 [某个目标] 以便[某种原因]。最初，用户故事是在索引卡或便签上写的。它们被安排在墙上以便于规划和讨论。您现在可以在任何主要的敏捷工具中突出显示它们。实体卡片或笔记将焦点从通过讨论的写作转移到关于能力和共享理解。事实上，这些讨论比故事中所写的更重要。谁写了用户故事？用户故事由业务代表以客户特定语言编写。我们之所以这样做，是因为我们希望业务部门和开发团队能够清楚地了解客户需求和原因。开发团队的工作是满足用户故事的验收标准。在Scrum中，产品负责人代表业务。产品负责人团队将完成该活动。何时撰写用户故事在整个产品或项目生命周期中编写用户故事。任何时候，任何人都可以编写新故事并将其添加到产品待办事项中。如果您的交付团队正在尝试预测发布计划，请在产品待办事项中维护大约准备好3个冲刺的用户故事的数量。而且付将用户故事写为功能的子集上付更大的努力。在这些情况下，产品所有者团队与交付团队协作，将故事分解到足够的水平。[作为]网站成员，[我希望]以半结构化的方式在我自己的页面上描述自己，[以便] 其他人可以学习 关于我。 也就是说，我可以填写预定义的字段，但也有一两个自由文本字段的空间。 （这会很好 让这个自由文本是HTML或类似的。）[As a] site member, [I want] to describe myself on my own page> in a semi-structured way [so that] others can learn about me. That is, I can fill in predefined fields, but also have room for a free-text field or two. (It would be nice to let this free text be > HTML or similar.)[作为]网站会员，[我希望] 可以填写申请成为认证Scrum从业者，[以便] 我可以获得 指定。 [注意：认证的Scrum Practitioner是被称为Certified Scrum的最初名称专业的。[As a] site member, [I want] to fill out an application to become a Certified Scrum Practitioner [so that] I can earn that designation. [Note: Certified Scrum Practitioner was the initial name of what became known as Certified Scrum Professional.[作为]一名从业者，[我希望]我的个人资料页面包含有关我的其他详细信息（例如，我的一些答案） 从业者申请）[以便]我就可以展示我的经验[As a] Practitioner, [I want] my profile page to include additional details about me (i.e., some of the answers to my Practitioner application) [so that] I can showcase my experience.[作为]培训师，[我希望]我的个人资料页面包含有关我的其他详细信息（即我的一些答案） 培训师申请），[以便]其他人可以了解我，并决定我是否适合他们。[As a] Trainer, [I want] my profile page to include additional details about me (i.e., some of the answers to my Trainer application) [so that] others can learn about me and decide if I’m the right trainer for them.[作为]培训师，[我希望]我的个人资料能够列出我即将开设的课程，并包含指向每个课程详细页面的链接 [以便]未来的参加者可以找到我的课程[As a] trainer, [I want] to list my upcoming classes and include a link to a detailed page about each [so that] prospective attendees can find my courses.[作为] 网站成员，[我希望]我可以查看其他成员的个人资料，[以便]找到可能需要联系的其他成员。[As a] site member, [I want]I can view the profiles of other members so that I can find others I might want to connect with.[作为]一个网站成员，[我想**]根据几个字段（类、位置、名称）搜索配置文件，这样我就可以找到其他我想联系的人。[As a] site member, [I want] to search for profiles based on a few fields (class attended, location, name) [so that] I can find others I might want to connect with.更多关于用户故事的文章用户故事工具What is User Story?What is Story Point in Agile? What is User Story Mapping? ...

我们汇总了您可能会在面试中获得的20个面试问题的清单，以及有效的答案，帮助您为梦想的敏捷Scrum工作做好准备！1.在30秒内解释敏捷。敏捷是一种方法和行为框架，鼓励“及时”生产，使客户能够更快地获得高质量的软件。2.敏捷和传统项目管理（瀑布）之间有什么区别？敏捷鼓励包括设计，开发和测试在内的一切都在同一时间完成。相反，传统的项目方法在下一个开始之前关闭并完成一个阶段。敏捷鼓励短暂，频繁的反馈循环并包含对需求的更改。在瀑布中，通常直到项目结束才收集反馈，并且不鼓励进行更改。3.您是认证Scrum Master吗？如果您没有认证并且他们问您这个问题，请不要感到惊讶！职位描述可能需要或不需要认证 - 面试官可能会或可能不会认为认证足以使专业知识成为您所申请职位的良好候选人。如果您还没有Agile Scrum Master认证，请告知他们您是否计划在不久的将来投资该认证。请务必提及您在该领域多年的经验。4. Scrum中有哪些角色？Scrum只规定了三个角色：产品负责人，Scrum Master和交付团队。理想情况下，这些角色应该是跨职能的，而不是在其他项目之间共享。许多Scrum大师没有机会与一个跨职能或专注的团队合作，因为该组织的抵制或无法允许一些人称之为“奢侈品”。这个问题可能会导致面试官问你怎么样会处理与团队中没有设计师或测试人员的团队合作，或者如何处理非专职团队。准备好了！5.什么是每日站立？关于敏捷的一个面试问题肯定是每日站立。答案？每天，最好是在早上，团队会面不超过15分钟回答三个问题：你昨天做了什么？ 你今天打算做什么？ 是否存在阻碍您工作的障碍或障碍？这次Scrum仪式并不意味着成为利益相关者的状态会议，而是一种激励团队并让他们为当天设定焦点的方式。6.描述Sprint计划会议中发生的事情。在Sprint计划中，产品负责人介绍了sprint的目标，并讨论了高优先级产品待办事项。交付团队然后选择下一个sprint的工作量。7. Scrum Master的作用是什么？以下是如何处理这样的Scrum Master面试问题：Scrum Master为团队服务并保护他们免受任何可能妨碍他们完成冲刺目标的干扰。他们还会删除障碍，教会团队自我组织，并担任教授敏捷和Scrum价值观和原则的教练。8.敏捷和Scrum之间有区别吗？是! 敏捷是Scrum所涵盖的更广泛的保护伞。敏捷有四个主要价值观和十二个原则。Scrum有自己的一套价值观和原则，并提供一个轻量级的“框架”来帮助团队变得敏捷。9.列举其他一些敏捷框架。除了Scrum之外，还有其他框架，例如看板，测试驱动开发和特征驱动开发。提及您遵循的框架并提供方案。10.什么时候应该使用瀑布而不是Scrum？如果需求简单，可预测，完全定义和理解，并且不会更改，请使用瀑布。11.您会为您的项目推荐自动化测试吗？Scrum鼓励使用自动化性能或回归测试，以便您可以尽快地连续交付软件。提供您的团队可能使用过的任何自动化测试工具的示例。12.你的短跑多久了？理想的冲刺长度在一到四周之间，两周的冲刺是最广泛使用的。13.什么是速度？速度是过去3-4次冲刺的平均点数。它用于帮助预测何时交付积压物品。14.如果有人想改变要求，可以吗？是。敏捷鼓励客户和利益相关者经常反馈，以便改进产品。我们需要能够接受改变。15.您使用了哪种类型的指标或报告？Sprint，发布刻录和刻录图表是标准报告。大多数公司还希望了解每个sprint完成的故事数量以及发布到生产后发现的缺陷数量。16.什么是烧毁图表？刻录图表显示团队已经烧毁的工作量 - 例如冲刺期间的小时数。讨论你过去如何使用它们。17.什么是回顾？回顾会是检查和调整过程的会议。这个敏捷方法访谈问题正在寻找进行回顾的许多方法 - 所以准备好解释一种或两种格式。18.您一次管理了多少个Scrum团队？这是一个很受欢迎的问题。不要提供Scrum指南，每个团队只有一个Scrum Master作为您的答案！在这个新角色中，您可能需要领导多个团队。注意使用“托管”和“领导”这个词.Scrum Masters不管理，他们领导团队 - 所以一定要在你的回复中使用这个词。你的面试官可能会非常仔细地听！19.您对团队使用了哪些类型的要求？Scrum中的要求是使用标准编写的用户故事，“作为___，我想要__以便我可以___。”作为Scrum Master，您不一定要编写用户故事，但是您可以帮助产品负责人确保用户故事的编写，优先级和准备好冲刺。20.描述交付团队成员似乎没有相处的时间。你是怎么处理的？注意一点冲突总是好的，但是你的面试官正在寻找你成为有效领导者的能力。反思你有几个团队成员，似乎从来没有能够解决问题。您是如何鼓励这些团队成员一起工作的？这是一项团队建设活动吗？你确定他们有一个共同的目标吗？说明你遇到的问题，你如何解决它以及结果。与任何面试准备一样，您需要自定义您的答案，以满足您面试的公司。想想大公司如何在他们的日常实践中使用敏捷Scrum方法。他们[希望充当这个角色的人能够擅长什么？]推薦的Scrum角色文章What is Scrum Team?What is a Self-Organizing Team in Scrum?How Scrum Team Works? - A Brief GuideHow to be a Good Product Owner in Scrum Project?What is Product Owner’s Role in Scrum?Agile Development: How to Become a Qualified Scrum Master?What is Pig and Chicken in Scrum?Project Manager vs Scrum Master vs Project OwnerWhat Are The Three Scrum Roles?What is a Scrum Master? The Role and ResponsibilitiesWhat is Cross-Functional Team in Agile? ...

自我評估作為Scrum大師, 你在扮演什麼角色（上面? 還是下？）哈哈！有些人仍然無法改變舊的思維方式一个伟大的Scrum Master确保整个团队支持所选的Scrum流程;管理超出团队自组织能力的障碍，阻止他们实现Sprint目标;认识到健康的团队冲突并促进建设性的分歧;准备好具有颠覆性，以便在组织内部实施变革;理解自组织的力量;理解稳定的冲刺节奏的价值，并尽一切努力创造和维护它;知道如何真正倾听并且沉默舒适;理解教练的力量，并且用心去学习一些有力的问题;教导产品负责人如何最大化ROI并实现目标;也适合XP，看板和精益。A great Scrum Master (英文原文)Ensures the entire team supports the chosen Scrum process;Manages the impediments that exceed the self-organizing capabilities of the team and it prevents them in achieving the Sprint Goal;Recognizes healthy team conflict and promotes constructive disagreement;Is prepared to be disruptive enough to enforce a change within the organization;Understands the power of a self-organization;Understands the value of a steady sprint rhythm and does everything to create and maintain it;Knows how to truly listen and is comfortable with silence;Understands the strength of coaching and has learned some powerful questions by heart;Teaches the Product Owner how to maximize ROI and meet objectives;Is also competent with XP, Kanban and Lean.推薦的Scrum文章What is Burndown Chart in Scrum?What is the Role-Feature-Reason Template?Sprint Increment vs Potential Shippable Product vs MVP vs MMPWrite SMART Goals & INVEST for User StoriesWhat is DEEP in Product Backlog?How to Write Product Vision for Scrum Project?How to Use Scrum Board for Agile Development?Who Create Product Backlog Items or User Stories in Scrum?What is Agile Estimation?What is Story Point in Agile? How to Estimate a User Story? ...

Scrum框架Scrum是一种管理项目的敏捷方式，通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论，而是将其视为管理流程的框架。要做Scrum，我们所需要的只是16个必需品，即3个角色，3个文物，5个价值观和5个事件。这些16个要素通过Scrum指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助Scrum团队尽可能充分利用Scrum框架来创建最大的业务影响。Scrum是3355的组合.scrum框架的核心概念可以简单地记为3.3.5.5，如下所示：3个角色产品拥有者开发团队Scrum Master3件文物产品积压Sprint Backlog - Sprint待办事项列表产品增量- 潜在的可发货产品增量5个事件短跑Sprint计划会议每日Scrum会议Sprint评审会议Sprint回顾会议5个值打开尊重勇气焦点承诺3355的目标落后于三个Scrum支柱透明检查适应“完成”（DoD）的定义是通过Scrum团队的5个事件来实现3个支柱来实现的。3355 Scrum框架Scrum依赖于一个自组织，跨职能的团队。Scrum团队是自我组织的，因为没有整体团队负责人决定哪个人将完成哪项任务或如何解决问题。这些是由整个团队决定的问题。在Scrum中，团队是跨职能的，这意味着每个人都需要从构思到实现。在敏捷开发中，Scrum团队由两个特定角色提供支持。第一个是ScrumMaster，可以被认为是团队的教练，帮助团队成员使用Scrum流程在最高级别执行。Scrum规则 (Scrum Rules)当我提到规则时，我的意思是那些无法修补以适应特定背景的方面。例如：没有3个角色，你不能做Scrum - 产品负责人，开发团队和Scrum Master。当我提到指南时，我指的是那些可能被改变以适应特定背景的方面; 然而，影响只能在实施后进行验证。然后我们相应地检查(insepction) 和调整(adaptation)。例如，Product Backlog Refinement消耗的不超过团队容量的10％ (<10% of the sprint duration)。是容量-小时数;故事点数; ＃天-好吧，没有规则。Scrum团队自我组织并选择最适合他们背景的东西;遵循我们消耗的指导方针，无论如何不超过团队容量的10％。在这篇文章中，我将探讨一些这样的指导方针，这些指南将11个要素绑定在一起，并赋予Scrum团队灵活性以适应这些方面的背景。＃1。开发团队规模：开发团队的规模建议为3-9名成员。根据具体情况，可能会有更多人或更少。它的影响因团队环境而异。来自Scrum指南：不到三个开发团队成员减少了交互，导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制，导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多协调。大型开发团队为实证过程提供了太多的复杂性。＃2。开发团队的标题/角色： Scrum不承认开发团队中的任何标题/角色。在开发团队中，每个人都是开发团队成员。虽然在组织内，团队成员可能拥有头衔/角色。根据我的经验，我与Scrum有关;我没有遇到任何只有一个职位/角色的团队。＃3。每日Scrum的三种问题格式：我使用过的大多数团队都使用Daily Scrum的3个问题的格式：昨天我做了什么帮助开发团队实现Sprint目标？今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何阻碍我或开发团队达到Sprint目标的障碍？令人惊讶的是，这3个问题只是开始使用Scrum的团队的模板。只要他们专注于Sprint目标的进展，开发团队就可以以他们认为合适的任何方式构建Daily Scrum。＃4。事件的时间框：事件的时间框表示事件为1个月冲刺所允许的最长时间。准则是：对于较短的短跑持续时间，它通常较短。 这是否意味着，对于为期两周的Sprint，Sprint Planning的时间限制为4小时，Sprint Review为2小时，Sprint回顾为1小时和半小时？编号 为尽可能满足他们的目的所需要的事件可以短/长;但不能超过最大分配时间。例如：Sprint规划活动为期2周Sprint可能会在2小时内结束，如果达到目的，或者可能会持续到8小时（如果没有）。＃5。进展趋势： Scrum指南建议使用烧毁图表，累积流量等实践来监控进度趋势。但是，团队完全可以自由选择他们认为合适的任何练习来达到目的。根据我的经验，我见过团队创建视觉路线图，基于里程碑的进度，旅程线，发布燃烧图等。虽然，我们还需要记住在复杂的环境中;只有经验数据才能帮助我们做出正确的决定。＃6。估算：该的Scrum指南介绍了积压的产品项目需要估计。他们应该如何估计完全取决于Scrum团队。故事点，理想日，T恤尺码，狗尺码是一些方法。Scrum团队可以做“没有估计”吗？当然，只要Scrum团队能够起草一份支持经验主义的计划; 创建透明度并帮助团队在Sprint结束时创建可能可释放的“完成”增量; 没关系。Scrum团队自行组织选择适合其背景的内容。＃7。工作分解：在“选择的工作将如何完成？”部分。对于Sprint计划，Scrum指南提到-开发团队在Sprint的头几天计划的工作在本次会议结束时分解，通常分为一天或更短时间。这通常有助于发展团队这样做，但这并非强制要求。根据我的经验，我已经看到几个团队没有将工作项目细分到如此精细的水平。他们非常清楚如何将功能转换为“完成”增量。＃8。Sprint评审：这是一项重要的Inspect＆Adapt活动，Scrum团队与主要利益相关方就Sprint期间取得的成果进行合作，以及在下一个Sprint中可以做些什么来优化产品的价值。Scrum指南还描述了Sprint Review的一部分：与会者包括Scrum团队和产品负责人邀请的主要利益相关者产品负责人解释了产品待办事项项目已“完成”且未完成的内容开发团队讨论Sprint期间的情况，遇到的问题以及这些问题是如何解决的开发团队演示了它“完成”的工作并回答了有关增量的问题产品负责人会按原样讨论产品Backlog。他或她根据迄今为止的进展预测可能的目标和交付日期（如果需要）整个小组就下一步做什么进行合作，以便Sprint Review为后续的Sprint Planning提供有价值的信息回顾产品的市场或潜在用途如何改变下一步最有价值的事情审查下一个预期的产品功能或功能版本的时间表，预算，潜在功能和市场对于每年获得资助的Scrum团队来说，每两周进行一次Sprint评估的预算是否合理？也许不吧。 并非所有上述元素都适用于所有Scrum团队。它们作为指导提供，以便Scrum团队可以选择在Sprint评审期间讨论和触及产品交付的各个方面，因为他们认为适合他们的背景。＃9。发布到生产：每个Sprint的目的是创建可能可释放的“完成”增量。这意味着增量需要处于可用状态并符合Scrum团队的DoD。 但是，将增量发布到生产中的选择由产品负责人决定。基于团队的背景和他们创造的增量; Scrum团队可能决定每个sprint执行多个版本，每个sprint一个版本或多个sprint的累积发布;无论如何优化产品的价值。＃10。完成的定义：完成的定义有助于提高透明度并创建对完成工作意味着什么的共同理解。根据Scrum指南，Scrum团队有望扩展其国防部并使其更高质量的更严格。 同样，这不是一个规则。取决于团队的背景; Scrum团队可能会在每次回顾中重新审视它的国防部，或者可能继续使用相同的国防部，除非它学会了新的东西以提高产品的质量。结论：这些只是在Scrum指南中传播的一些指导原则。我想提出这个区别，因为我经常发现Scrum团队对Scrum规则和指南感到困惑。很少有人很常见- 将Sprint Planning的时间框修改为4小时进行为期2周的冲刺，或者开发团队花费太多时间和精力将Product Backlog Items (PBI) 分解为“任务” - 其他人则不那么常见。我相信这篇文章将帮助团队识别Scrum的一些方面，他们可以修改这些方面以适应他们的背景，以及他们能够区分那些无法改变的方面。Scrum ArtifactsWhat are Scrum Artifacts?Definition of Done vs Acceptance CriteriaWhat is Definition of Ready in Scrum?How to Write a Sprint Goal?What is Product Backlog in Scrum? Who Responsible for It?How to Refine Product Backlog?What is Sprint Backlog in Scrum? ...

今天（2017年11月7日），Ken Schwaber 和 Jeff Sutherland 发布了 Scrum 指南的更新。Scrum指南是Scrum的最终定义，由Scrum的创建者Ken和Jeff编写。《Scrum指南》描述了Scrum框架。而且，它只有19页长。通过保持简短的定义，它不仅强制实现一个明确的重点，而且提醒每个人它不是一种方法论。过程是根据团队所处的情况使用框架而产生的。因为Scrum关注复杂的问题，所以不可能定义完整的方法论。相反，Scrum提供了一个简单的框架，鼓励正确的经验过程出现。这使得现在超过1200万人可以练习Scrum，同时在非常不同的情况下解决非常不同的问题。添加了有关Scrum使用的部分： Scrum最初是为管理和开发产品而开发的。从20世纪90年代初开始，Scrum在全球广泛使用：研究和确定可行的市场，技术和产品能力;开发产品和改进;每天多次发布产品和增强功能;开发和维护云（在线，安全，按需）和其他操作环境以供产品使用; 和，维持和更新产品。Scrum已被用于开发软件，硬件，嵌入式软件，交互功能网络，自动驾驶汽车，学校，政府，市场营销，管理组织的运作以及我们日常生活中使用的几乎所有东西，如个人和社会。随着技术，市场和环境的复杂性及其相互作用的迅速增加，Scrum在处理复杂性方面的实用性每天都在证明。事实证明，Scrum在迭代和增量知识转移方面特别有效。Scrum现在广泛用于产品，服务和上级组织的管理。Scrum的本质是一个小团队。个人团队非常灵活和适应性强。这些优势继续在单个，多个，多个团队网络中运行，这些团队开发，发布，运营和维护数千人的工作和工作产品。他们通过复杂的开发架构和目标发布环境进行协作和互操作。当Scrum指南中使用“develop”和“development”这两个词时，它们指的是复杂的工作，例如上面提到的那些类型。更改了“Scrum Master”部分中的措辞，以更好地阐明角色。现在的案文如下： Scrum Master负责推广和支持Scrum指南中定义的Scrum。Scrum Masters通过帮助每个人理解Scrum理论，实践，规则和价值观来实现这一目标。Scrum Master是Scrum团队的仆人领导者。Scrum Master帮助Scrum团队以外的人了解他们与Scrum团队的哪些互动是有用的，哪些不是。Scrum Master帮助每个人改变这些交互，以最大化Scrum团队创造的价值。添加到产品负责人的Scrum Master Service部分 确保Scrum团队中的每个人都能够理解目标，范围和产品领域。将Daily Scrum部分的第一段更新为： Daily Scrum是一个15分钟的开发团队时间盒活动。每日Scrum每天都在Sprint举行。在此，开发团队计划在接下来的24小时内开展工作。通过检查自上次每日Scrum以来的工作并预测即将到来的Sprint工作，这可以优化团队协作和性能。Daily Scrum每天都在同一时间和地点举行，以降低复杂性。更新了每日Scrum部分，以明确Daily Scrum的目标，包括以下文本： 会议结构由开发团队制定，如果侧重于Sprint目标的进展，可以采用不同的方式进行。一些开发团队将使用问题，一些将更多基于讨论。以下是可能使用的示例：昨天我做了什么帮助开发团队实现Sprint目标？今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何妨碍我或开发团队满足Sprint目标的障碍？在时间框周围增加了清晰度 使用“最多”一词来删除任何问题，即事件的时间框意味着最大长度，但可能更短。添加到Sprint Backlog部分： 为了确保持续改进，它包括至少一种团队工作的高优先级方式，在之前的回顾会议中确定。为增量部分添加了清晰度： 增量是一个可检查的，“完成”的工作，支持Sprint结束时的经验主义。增量是迈向愿景或目标的一步。2013年和2016年Scrum指南之间的变化关于Scrum值的部分。当Scrum团队体现并实践承诺，勇气，专注，开放和尊重的价值观时，透明度，检查和适应性的Scrum支柱将栩栩如生，为每个人建立信任。Scrum团队成员在使用Scrum事件，角色和工件时学习和探索这些值。成功使用Scrum取决于人们是否越来越熟练地掌握这五个价值观。人们个人致力于实现Scrum团队的目标。Scrum团队成员有勇气做正确的事情并处理棘手的问题。每个人都关注Sprint的工作和Scrum团队的目标。Scrum团队及其利益相关者同意对所有工作以及执行工作所面临的挑战持开放态度。Scrum团队成员互相尊重，是有能力的独立人士。2011年和2013年Scrum指南之间的变化添加了关于工件透明度的部分。Scrum依赖于透明度。根据工件的感知状态做出优化价值和控制风险的决策。在透明度完成的情况下，这些决定具有良好的基础。如果工件不完全透明，这些决策可能存在缺陷，价值可能会降低，风险可能会增加。Sprint Planning现在是一项活动。其中涉及两个主题：Sprint可以做什么，以及如何完成所选择的工作。在开发团队预测Sprint的产品Backlog项目之后，Scrum团队制定了Sprint目标。Sprint目标在开发团队的工作中创造了一致性，如果没有共同的目标，这些工作就不会出现在单独的计划中。请注意正式包含Sprint目标。产品Backlog经过精炼而非整理。精确的产品Backlog项目是透明的，足够的理解和粒度足以输入Sprint计划和Sprint的选择。具有此透明度的产品Backlog项称为“Ready”。Ready和Done是两个强化透明度的状态。Scrum规定其事件以创建规律性并最小化对未在Scrum中定义的会议的需求。所有事件都是时间盒事件，因此每个事件都有最长持续时间。作为容器事件的Sprint具有不能缩短或延长的固定持续时间。只要达到事件的目的，剩下的事件就可以结束; 确保花费适当的时间而不会在过程中浪费。Daily Scrum作为计划活动的重要性得到了加强。它经常被视为一种状态事件。每天，开发团队应该了解它打算如何作为一个自组织团队一起工作，以实现Sprint目标，并在Sprint结束时创建预期的增量。会议的输入应该是团队如何实现Sprint目标; 输出应该是一个新的或修订的计划，以优化团队在满足Sprint目标方面的努力。为此，重新制定了三个问题，以强调团队对个人的影响：昨天我做了什么帮助开发团队迎接Sprint今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何妨碍我或开发团队满足Sprint目标的障碍？价值观的概念得到了加强，可以在Sprint评论中使用。在Sprint评审期间，Scrum团队和利益相关者就Sprint的工作进行了合作。基于此以及Sprint期间产品Backlog的任何更改，与会者将就可以采取的下一步措施进行协作以优化价值。2010年和2011年Scrum指南之间的变化开发团队不承诺完成Sprint计划会议期间计划的工作。开发团队创建了它认为将要完成的工作的预测，但是随着Sprint中的更多知识的出现，预测将会发生变化。Scrum没有要求使用刻录图来监控进度。Scrum仅需要：Sprint的剩余工作每天汇总并且已知。整个Sprint都保持着完成Sprint工作的趋势。在使用Scrum时，发布计划是一件很有价值的事情，但Scrum本身并不需要。Sprint Backlog是为Sprint选择的Product Backlog项目，以及交付它们的计划。不再需要“Sprint Backlog项目”的概念，尽管这种技术可以制定一个很好的计划。自组织开发团队总是有一个计划。产品待办事项是“有序的”，而不是“优先”，为产品负责人提供灵活性，以便在其独特情况下优化价值。添加了Product Backlog Grooming的做法。删除许多提示，可选的做法和技术。执行创建增量工作的人员团队是开发团队。无论各个团队成员的工作如何，他们都被称为开发人员。删除了对鸡和猪的参考。删除了对撤消工作的引用。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?What is the Evolution of Scrum?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master? ...

最新版Scrum指南已由来自Scrum, Inc的Scrum共同发明人Ken Schwaber和来自Scrum.org的Jeff Sutherland联手发布。上一版发布于2013年，此版最大的变化是包含了Scrum价值观。Scrum指南包含有关Scrum的权威指南，「整个游戏的规则」。Schwaber和Sutherland通过合作定期更新该Scrum指南，并通过Scrum指南网站的User Voice区域响应来自社区的反馈。新版发布后，InfoQ与Schwaber谈到了最新版中的改动和未来的计划。Scrum Guide 指南的目的Scrum 是一個框架，這框架適用於開發，交付，與持續支援具有錯綜複雜的產品。這份指南包含 Scrum 的定義，其中定義涵蓋了 Scrum 中的角色，活動，產出物，與它們之間如何進行的規則。Scrum 是由 Ken Schwaber 和 Jeff Sutherland 共同發展出來的；Scrum 指南也是由他們所撰寫及提供，他們是 Scrum 指南背後的共同推手。Scrum 的定義Scrum （名詞）：一個框架，人們可以運用這個框架來處理錯綜複雜的調適性問題，善用生產力與創意來交付盡可能最高價值的產品。Scrum 是：● 輕量的 ● 淺顯易懂的 ● 難以精通Scrum 是一個流程框架，從 1990 年代初期它就被用來管理生產錯綜複雜的產品。Scrum 不是一種流程，一個技巧，或明確既定的方法。倒不如説 Scrum 是一個框架，在其中你可以使用各種不同的流程與技巧。運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。每個框架中的組成都有特定的目的，也都是讓 Scrum 成功和運行的必要條件。Scrum 規則把角色，活動和產出物整合在一起，也主宰了各個組成之間的關係和互動。這整份文件都是在描敘 Scrum 規則。各種使用 Scrum 框架的具體策略有很大的差異，這些策略不在這指南中描述。Scrum 的運用Scrum 一開始是為了管理和開發產品而發展出來的。從 1990 年代初期開始，Scrum 就在全世界被大量的運用在：研究和辨識出市場，技術，產品性能的可行性;開發產品和加強功能;發佈產品和加強功能，頻率高到一天可能發佈許多次;開發和支援雲端服務（線上，高安全性，隨時存取）和其他營運環境來幫助產品的運用，以及支援和更新產品。Scrum 已經被使用於開發軟體，硬體，韌體，互動的網路，自駕車，學校，政府，行銷，管理組織的營運，還有幾乎所有我們日常生活中的事物上，不論是個人或是社會。在科技，市場，環境都日趨錯綜複雜，而且各個因素之間的互動快速增加的情況下，每天都可以看到運用 Scrum 來處理錯綜複雜的問題的效用。Scrum 被證明在迭代和漸進式的知識轉移中特別有效。目前 Scrum 已經被廣泛的使用在組織內的產品，服務，和管理。Scrum 的精華在於小型的團隊。每個團隊都具有高度彈性和調適性。這些團隊從事開發，發佈，營運，和支援的工作，不論是一個團隊，一些團隊，許多團隊或是更多串連在一起的團隊所組成，都擁有這些優勢，他們藉由精細複雜的開發架構和鎖定發佈環境來協同合作和交互運作。當 Scrum Guide 中使用「開發 （develop）」這個字的時候，指的是從事複雜的工作，如上面所陳述到的那些類型。Scrum 的理論Scrum 是立基於經驗導向的流程控制理論，或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用迭代和逐步 Increment 的方式，來最大化可預測性和控制風險。 有三根支柱支撐了所有經驗導向的流程控制的實行：透明性，檢視性，調適性。透明性負責產生成果的人員必須清晰地看見流程中重要的部分，這些部分被共同的標準來定義，所以觀看的人能得到一致的認知，這就是透明性。例如：● 所有的參與者對該流程都有共同的語言；以及● 真正執行的人員和檢視 Increment 成果的人員，需要對「完成」之定義，有一個共同的認知。檢視性Scrum 的成員必須經常檢視 Scrum 的產出物和 Sprint 目標的進度來檢測意料之外的變數。他們的檢視不應該頻繁到會阻礙工作的進行。最有效益的檢視方式，是由盡職且擁有技能的檢視者在工作的當下進行。調適性如果檢視者判斷流程中的某些部分超出了可以接受的範圍，且會造成產品不被接受，就必須調整當下的流程或使用材料。調整必需越快越好來減少未來更多的偏差。在 Scrum 中規定了四個幫助檢視性和調適性的正式活動，在 Scrum 活動的章節會介紹：● Sprint Planning● Daily Scrum● Sprint Review● Sprint RetrospectiveScrum 價值觀當 Scrum Team 體現和活化承擔，勇氣，專注，開放和尊重這五種價值觀時，Scrum 的三根支柱：透明性，檢視性，調適性就會出現並幫助大家建立信任。隨著 Scrum Team成員從事 Scrum 角色，活動和產出物的過程中，他們就會學習和探索這些價值。 要成功運用 Scrum 取決於成員是否精通並融入這五個價值。成員個人承諾會達到 Scrum Team 的目標，Scrum Team members 有勇氣做對的事情和處理艱難的問題，每個人專注在 Sprint 的工作和 Scrum Team 的目標上，Scrum Team 和利害關係人同意對工作和工作上的挑戰保持開放的心態，Scrum Team members 互相尊重對方是有能力和獨立的人。Scrum TeamScrum Team 由 Product Owner，Development Team 和一位 Scrum Master 組成。Scrum Teams 是一個自我組織和跨職能的團隊。自我組織的團隊會自行選擇最好的方式來完成工作，而不是被團隊外的人指示如何做。跨職能的團隊不需依靠非團隊成員而擁有所有完成工作所必備的能力。Scrum 中的團隊模式是設計用來將彈性，創意，和生產力最大化。Scrum Team必須證明自己在前述的情況和錯綜複雜的工作中越來越有效。Scrum Teams 用迭代和逐步 Increment 的方式交付產品，將回饋的機會最大化。用逐步Increment 的方式交付「完成」的產品，可以確保一直提供一個潛在可用的產品版本。The Product OwnerProduct Owner 負責將產品的價值最大化，而價值來自於 Development Team 的工作成果。如何做到這點可能在每個組織，Scrum Teams，或個人，都差異很大。Product Owner 這個角色只能由一個人來擔任，專門負責管理 Product backlog。Product backlog 管理包含：清楚的表達 Product Backlog items；針對 Product backlog 上的事項進行排序來達到最好的目標和使命；將 Development Team 工作所產生的價值最佳化確保 Product backlog 是每個人都可以看見的，是有透明度的，以及清晰瞭解的，而且可以顯示出 Scrum Team 接下來要做的事；和確保 Development Team 對 Product Backlog 的了解有到達所需要的程度Product Owner 可以自己做以上的工作，或由 Development Team 來做。但不管如何都是由 Product Owner 當責。Product Owner 是由一個人來擔任，而不是一個委員會。Product Owner 可能代表一個委員會對於 Product backlog 的期望要求，但任何人想要改變 Product Backlog 的優先順序，都需要經過 Product Owner 的同意。要讓 Product Owner 成功，整個組織必須尊重他/她的決定。Product Owner 對於Product Backlog 內容和順序之決定是透明的，沒有人可以強迫 Development Team 做 Product backlog 以外的需求。The Development TeamDevelopment Team 由一群專業人士組成，他們可以在每個 Sprint 結束時交付「完成」潛在可發佈的產品 Increment。「完成」的產品 Increment 必須在 Sprint Review 上呈現。只有 Development Team 的成員可以產生產品 Increment。組織建立並授權 Development Team，讓他們可以自行組織和管理他們自己的工作。所達成的綜效可讓 Development Team 整體的效率和效能達到最大化。Development Team 有以下的特性：他們是自組織的。沒有人（甚至是 Scrum Master）可以對 Development Team 下指導棋，告訴他們如何把 Product backlog 轉換成潛在可發佈的產品 Increment；Development Team 是跨職能的，擁有產出產品 Increment 所需要的所有技能；Scrum 認為 Development Team members 沒有職稱，不管個人所做的工作是什麼；Scrum 認為 Development Team 中沒有小團隊，不管需要解決的是什麼領域，如測試，架構，營運或商業分析；和Development Team members 雖然可能各自有專精的技能和領域，但仍是由Development Team 整體來當責。Development Team 的大小最理想的 Development Team 大小，是小到足夠靈活而且大到能夠完成 Sprint 內重大的工作。少於三個人的 Development Team member 之間的互動會減少，以至於只能提升小部分的生產力。小一點的 Development Team 可能會在 Sprint 中遇到技能的限制，使得Development Team 無法交付潛在可發佈的產品 Increment。如果成員多過九個人則會造成太多的協調。大的 Development Teams 產生太多的複雜性，而使得經驗導向的流程沒辦法那麼有效。Product Owner 和 Scrum Master 的角色並不包含在 Development Team人數中，除非他們也執行 Sprint Backlog 上的工作。Scrum MasterScrum Master 依照 Scrum 指南中的遊戲規則來負責推廣和支持 Scrum。Scrum Master 幫助每個人了解 Scrum 的理論，實務，規則和價值觀，來達成推動 Scrum。對於 Scrum Team 來說，Scrum Master 是一個僕人式的領導。Scrum Master 幫助Scrum Team 外的人了解哪些與Scrum Team 之間的互動是有幫助的，而哪些是沒有幫助的。Scrum Master 幫助每個人改變這些互動的方式，讓 Scrum Team 產生的價值能夠最大化。Scrum Master 對 Product Owner 提供的服務Scrum Master 對Product Owner 提供多方面的服務，包含：確保 Scrum Team 的每位成員都盡可能地理解目標，範圍與產品領域；找出有效管理 Product backlog 的技巧；幫助 Scrum Team 理解為什麼需要清楚簡潔的 Product Backlog items；在經驗導向的環境中理解產品規劃；確保 Product Owner 知道如何安排 Product backlog 來讓價值最大化；理解和實踐敏捷；與當需要或被要求時，引導 Scrum 活動的進行。Scrum Master 對 Development Team 提供的服務Scrum Master 對 Development Team 提供多方面的服務，包含：作為教練指導 Development Team如何自我組織和跨職能；幫助 Development Team 創造高價值的產品；移除 Development Team 在過程中的障礙；當需要或被要求時，引導 Scrum 活動的進行；與在組織環境還沒有完全採用與理解 Scrum 的情況下，作為教練指導 Development Team。Scrum Master 對組織提供的服務Scrum Master 對組織提供多方面的服務，包含：帶領和作為教練指導組織來採用 Scrum；規劃 Scrum 在組織內的實施；幫助員工和利害關係人理解及制定 Scrum 與經驗導向的產品開發；造成改變來增加 Scrum Team 的生產力；與其他 Scrum Master 一起合作來加強組織內 Scrum 應用的有效性。Scrum 的活動Scrum 規定了幾項活動來創造規律性，以此來減少其它 Scrum 未定義的會議。這些活動都是有時間盒限制的，也就是在某個時間長度內必須要完成。當 Sprint 開始，Sprint 的長度就固定下來了，不可以縮短或是延長。剩下的活動在達成其目的後就可以結束了，以確保在過程中只使用了適當的時間而不會造成流程中的浪費。Sprint 本身包含了其他的活動，除了 Sprint 本身之外，每次活動都是用來檢視與調適某些事情的正式機會，這些活動都是特別設計來促成嚴格的透明性與檢驗性。遺漏其中的任何一種活動可能導致透明性降低，檢視和調適的機會變少。SprintScrum 的核心是 Sprint，Sprint 是一個月或更短的時間盒。在 Sprint 內，會產出「完成」的，可用的，潛在可發佈的產品 Increment。Sprint 長度在整個開發過程中都是固定的，前一個 Sprint 結束後，下一個新的 Sprint 立刻接著開始。Sprint 包括了 Sprint Planning，Daily Scrums，開發工作，Sprint Review 與 Sprint Retrospective。在 Sprint 過程中：不可以發生會危及 Sprint 目標的改變；對於品質的目標不可以降低；與隨著獲得了更多關於產品的細節，Product Owner 與 Development Team 之間對於範圍內要做的事可以加以澄清與重新溝通。每個 Sprint 可視為一個不超過一個月的專案，如同其他專案一般，Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標，而由一份設計和有彈性的計畫來引導其打造的過程，工作與最後的產品 Increment。Sprint 被限制在一個月內，當 Sprint 時間拉的太長時，現在正在打造的東西的定義可能會發生改變，而其複雜性也許會增加，導致風險上升，Sprint 藉由至少一個月一次的檢視與調適 Sprint 目標進度來達成可預期性，也因此，Sprint 便可將成本風險限制在一個月內。取消 SprintSprint 可在時間盒限制結束前取消，但只有 Product Owner 有取消 Sprint 的權力，雖然Product Owner 的這個決定可能是來自於利害關係人，Development Team 或是 Scrum Master 的影響。當 Sprint 目標已經變得過時，不重要的時候，就可以取消 Sprint，這可能是因為公司改變了方向或是因為市場或技術上的改變。一般而言，如果當下的情況已經變得不合理，那就應該取消 Sprint，但因為 Sprint 的時間很短，取消通常是不太合理的事情。當 Sprint 被取消時，會檢視已經「完成」的 Product Backlog items，如果有某部分的工作已經是潛在可發佈了，Product Owner 一般會接受這些成果。而尚未完成的 Product Backlog items 會被重新估計，並放回 Product backlog 內，花在這些尚未完成的 Product Backlog 上的工作價值會流失得很快，所以需要經常不斷的重新估計來反映。取消 Sprint 會消耗資源，因為要在新的 Sprint Planning 把每個人集合起來，重新開始新的 Sprint，Sprint 的取消會對 Scrum Team 造成重大傷害，所以並不常發生。Sprint PlanningSprint 內要做的事會在 Sprint Planning 中來訂定。工作計劃是由整個 Scrum Team 協同合作來制定的。Sprint Planning 是有時間盒限制的，以一個月的 Sprint 來説，Sprint Planning 最多為八小時。對於少於一個月的 Sprint，這個會議所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。並且教導 Scrum Team 在時間盒限制內完成此會議。Sprint Planning 回答以下問題：這次 Sprint 可以發佈什麼樣的 Increment？如何做才能夠達成 Increment？第一個討論題目：這次 Sprint 能做出什麼？Development Team 預測在這次Sprint內能開發出什麼功能。Product Owner 討論這次 Sprint 所應該達成的目標，以及完成哪些 Product Backlog items 可以達成這個目標。整個 Scrum Team 協同合作來了解 Sprint 要做的工作。這個會議的輸入包含： Product backlog ，最近的 Increment，在 Sprint 內 Development Team的產能預測，以及 Development Team 的過去表現。從 Product backlog 之中要選出那些項目完全取決於 Development Team。只有 Development Team 可以評估即將到來的 Sprint 所能達成的事情。在 Sprint Planning 中 Scrum Team 同時草擬本次的 Sprint 目標。Sprint 目標經由實作Product Backlog 來達成，同時指引 Development Team 知道為何要做這次的 Increment。第二個討論題目：如何完成所選的工作？在設定 Sprint 目標與選出 Product Backlog Items 之後，Development Team 決定如何在這次 Sprint 內，建造這個功能來做出一個「完成」的產品 Increment。Sprint Backlog 指的是：這次 Sprint 所選的 Product Backlog items 加上如何交付它們的計劃。Development Team 通常從系統的設計開始，到找出那些工作可以將 Product backlog 轉換成一個可運作的產品 Increment。工作通常有不同的大小，或不同的預估工作量。然而，在 Sprint Planning 中，Development Team 只預測他們在本次 Sprint 要完成的工作量即可。在 Sprint Planning 結束之際，Development Team 應該已經規劃出在 Sprint 的前幾天內所要做的工作，通常以一天或更少為一個單位。不管是在 Sprint 計劃會議中以及在Sprint 期間內，Development Team 自我組織的來承擔 Sprint Backlog 的工作。Product Owner 能夠幫助釐清所選定的 Product Backlog items 以及做出折衷。如果 Development Team 發現 Product Backlog 的工作內容太多或太少，他們可以與 Product Owner 重新商討所選的 Product Backlog items。Development Team 也可以邀請在技術領域或者其它領域的專家一起來參加會議提供建議。在 Sprint Planning 結束之際，Development Team 應該能夠解釋給 Product Owner 以及 Scrum Master，他們要如何自我組織來完成 Sprint 目標以及開發出預定的 Increment。Sprint 目標Sprint 目標是實作 Product backlog 過程中所必須達到的目的。它指引 Development Team 爲什麼要做這個 Increment。Sprint 目標是在 Sprint Planning 中產生的。對於在 Sprint 內要實作的功能，Sprint 目標提供了 Development Team 要實作哪些功能的彈性。這些被選定的 Product Backlog items 提供一個連貫的功能，而這個功能即可成為 Sprint 目標。Sprint 目標也可以是任何有連貫性的工作，這些工作讓 Development Team 一起合作，而不是讓他們各自做各自的。當 Development Team 工作時會牢記 Sprint 目標。Development Team 會實作出需要的功能和工藝來達到 Sprint 目標。如果要做的事情和 Development Team 預期的不同，他們會跟Product Owner 協同合作來溝通商量本次 Sprint Backlog 之範圍。Daily ScrumDaily Scrum 是一個針對 Development Team 的活動，其時間盒限制是 15 分鐘，此會議在 Sprint 期間內每日召開。在這個會議裡，Development Team 會規劃未來 24 小時的工作。透過檢視前次 Daily Scrum 後的工作及展望接下來的Sprint工作，將會逐步優化團隊協同合作和表現。Daily Scrum 在同一時間與地點舉行來降低其複雜性。 Development Team 藉由 Daily Scrum 來檢視達成 Sprint 目標的進度，以及檢視所完成的Sprint Backlog 進度的趨勢。Daily Scrum 優化了 Development Team 達到 Sprint 目標的可能性。每一天，Development Team 都應該理解如何以一個自我組織的團隊來一起完成Sprint 目標，並在 Sprint 結束時創造出符合預期的 Increment。 會議的架構由 Development Team決定，只要聚焦在達成 Sprint 目標的進度上，都可以用不同的方式進行。 一些 Development Team 會使用提出問題的方式，而有一些則會以討論的方式進行。以下是一個可以使用的範例：我昨天做了什麼事來幫助 Development Team 達到 Sprint 目標?我今天要做什麼事來幫助 Development Team 達到 Sprint 目標?我是否有察覺到任何障礙使得我或者 Development Team 無法達到 Sprint 目標?Development Team 或團隊成員經常在 Daily Scrum 後再立即會面，以便進行詳細的討論，調適或重新規劃 Sprint 的其餘工作。 Scrum Master 確保 Development Team 有進行 Daily Scrum，但 Development Team 要負責召開此會議。 而 Scrum Master 要教導 Development Team 將 Daily Scrum 保持在時間盒限制 15 分鐘內完成。 Daily Scrum 是 Development Team 的內部會議。 如果有其他人在場，Scrum Master 要確保他們不會打擾到會議的進行。 Daily Scrums 改善溝通品質，淘汰其他會議，發現並移除開發上的障礙，突顯及促進快速決策，還有提升 Development Team 的知識水平。 這是一個用來做為檢視和調適的重要關鍵會議。Sprint ReviewSprint Review 是在 Sprint 結束時舉行，目的是檢視 Increment以及在必要時調適 Product Backlog。在 Sprint Review 中，Scrum Team 和利害關係人一起協同合作檢視在 Sprint 中所完成的事項。依照這些事項和在 Sprint 過程中 Product Backlog 的變動，參與者一起協同合作討論接下來能做完哪些最有價值的事情。這是一個正式但輕鬆的會議，並不是一個進度回報的會議，關於 Increment 的展示是為了引發意見的反饋和提升協同合作。 對於為期一個月的 Sprint 來説，這是一個最多四個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。Scrum Master 教導參與的每個人如何在時間盒限制內完成會議。 Sprint Review 包含以下要件：參與者包含 Scrum Team 和 Product Owner 邀請的主要利害關係人；Product Owner 解釋哪些 Product Backlog items 已經「完成」，與哪些尚未「完成」；Development Team 討論在 Sprint 中進行順利的事項，遇到那些問題與及這些問題如何被解決；Development Team 展示已「完成」的工作並回答關於 Increment 的問題；Product Owner 討論目前的 Product backlog 的現況，他/她（視情況而定）根據到目前為止的進度來預測可能的的交付日期；整個團體協同合作來決定下一步要做什麼，所以 Sprint Review 提供了有價值的資訊給接下來的 Sprint Planning 當作輸入；檢視市場或潛在的產品使用情況是否改變了接下來最有價值的下一步；與檢視接下來期待會發布的產品功能的時間，預算，潛力，和市場。 Sprint Review 的結果，是一個修正過的 Product backlog ，在清單中定義了在下個 Sprint 可能會做的Product Backlog items。 Product backlog 亦可以調整來因應新的機會。Sprint RetrospectiveSprint Retrospective 提供 Scrum Team 一個自我檢視的機會，並建立一個改進計劃以便在下一個 Sprint 中落實。 Sprint Retrospective 召開在 Sprint Review 之後，下一個 Sprint Planning 之前。對於為期一個月的 Sprint 來説，這是一個最多三個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。 Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的 Scrum Master 確保這個會議是正向積極並有成效的。 Scrum Master 教導所有人在時間盒限制內完成會議。 Scrum Master 以團隊成員的身分來參與這個會議，因為他對 Scrum 的流程當責。Sprint Retrospective 的目的是：檢視上次 Sprint 內關於人員，關係，流程和工具的情況；找出並加以排序做的很好的重要事項，及具有改善潛力的事項；同時，制定一個計劃來落實如何改善 Scrum Team 的工作方法。Scrum Master 鼓勵 Scrum Team 在 Scrum 流程框架內改善其開發流程和實務，使其在下一個 Sprint 的工作中能更有效能及愉快。 在每個 Sprint Retrospective 中，Scrum Team 會規劃各種方法來提升產品的品質，在恰當且不與產品或組織標準相衝突為前提下，改善工作流程或調整「完成」之定義。在 Sprint Retrospective 結束之際，Scrum Team 應該已經確定了在下一個 Sprint 中要實施改善的地方。 在下一個 Sprint 中執行這些改善，即是 Scrum Team 在自我檢驗後的調適。雖然改善可能在任何時間點落實，但 Sprint Retrospective 提供了一個正式的機會來專注在檢視與調適上。Scrum 產出物Scrum 的產出物代表了工作或價值，用以提供透明化以及檢視和調適的機會。 Scrum 所定義的產出物是專門設計用於讓關鍵資訊有最大的透明性，以便每個人對該產出物有相同的理解。Product BacklogProduct Backlog 是產品所有已知需求的排序表。它是對產品進行任何更改的唯一需求來源。Product Owner 對 Product backlog 負責，包含其內容，可取得性和排序。Product backlog 永遠沒有完成的一天。早期的開發僅排定了最初已知和最被理解的需求。 Product backlog 隨著產品和使用環境的演變而演化。 Product backlog 是動態的；它不斷地變化來找出什麼對產品而言是恰當的，有競爭力以及有用的。只要產品存在的一天，它的 Product backlog 也會同時存在。Product backlog 列出了所有特性，功能，需求，改善功能和修補程式，這些事情構成了對未來要發布的產品的更新。Product Backlog items 的屬性包括了其描述，順序，估計和價值。Product Backlog items 通常包括測試描述，用來證明「完成」的完整性。隨著產品的使用和獲得價值，以及市場提供的反饋， Product backlog 將成為更大更詳盡的列表。 需求永遠不會停止改變，所以 Product backlog 就如同一個活的產出物。商業需求，市場狀況或技術的變化可能都會造成 Product backlog 的變動。數個 Scrum Teams 通常會一起參與對同一個產品的開發。 一個 Product backlog 便被用於描述該產品即將進行的工作，並採用 Product Backlog 的某一種屬性來把這些事項分類。 Product backlog refinement，是向 Product backlog 中的事項添加詳細資訊，估算大小和排序的動作。這是一個持續的過程，由 Product Owner 和 Development Team 就 Product Backlog items 的細節進行協同合作。在 Product backlog 精煉的過程中，事項會被進行審查和修訂。Scrum Team 決定如何以及何時來完成精煉。精煉所花的時間通常不超過Development Team 百分之十的產能。 然而，Product Backlog items 可以隨時由Product Owner 或在 Product Owner 的斟酌下來做更新。 較高排序的 Product Backlog items 比起較低的 Product Backlog items，通常比較清楚，同時包含更多細節。因為比較明確以及更多細節，可以讓預估更精準；而排序較後的 Product Backlog items，細節會越少。Development team 會在下一個 Sprint 開發的 Product Backlog items 會先被精煉，使得這些事項都可以合理的在 Sprint 時間盒期限內「完成」。「備妥」的 Product Backlog 可以在 Sprint Planning 中被挑選出來，而能夠 Development Team 在下一個 Sprint 內「完成」。 Product Backlog items 的透明性通常要經過上述的精煉化活動來獲得。 Development Team 負責所有的估計。Product Owner 也許可以經由幫助 Development Team 了解以及選擇取捨來影響他們，然而還是要由實際做事的人來決定最終的預估。監測達成目標的進度 在任何時候，用來達成目標的所有剩餘工作量都能夠被加總。Product Owner 至少在每次的 Sprint Reviews 中追蹤剩餘的工作量。Product Owner 將這次的剩餘工作量與之前做比較，進而評估預定的工作進度，是否能在期望時間內達成目標。這些資訊對所有的利害關係人都是透明公開的。 可以用各種不同關於趨勢走向的實務來預測進度，譬如：燃盡圖，燃起圖或累積流量圖。這些工具被證實是有用的，然而它們並不能用來取代經驗主義的重要性。在錯綜複雜的環境中，會發生什麼事是未知的。已經發生的事情，才能用來當做前瞻的決策的參考依據。Sprint BacklogSprint Backlog 是一組在這次 Sprint 要執行的 Product Backlog items 加上如何交付產品Increment 和達到 Sprint 目標的計劃。 Sprint Backlog 是 Development Team 對下一個Increment 中所需要的功能以及將該功能轉換到「完成」Increment 所需工作的預測。Sprint Backlog 讓 Development Team 識別出所有用來完成 Sprint 目標的必要工作。為了確保持續改善，它包含了至少一個在前次Sprint Retrospective 中優先級高的流程改進。 Sprint Backlog 是一個具有足夠細節的計劃，使得在 Daily Scrum 中可以了解正在發生的改變。 Development Team 在整個 Sprint 期間都會去修改 Sprint Backlog，使得 Sprint Backlog在 Sprint 期間裡慢慢變化而逐漸成形。 這樣的逐漸成形會隨著 Development Team 實作Sprint Backlog 的過程來發生，加上過程中學習而得到更多如何完成 Sprint 目標。 當需要有新的工作時，Development Team 便將其加到 Sprint Backlog 內。 隨著工作的進展或完成，團隊會去更新預估的剩餘工作量。當計劃內的某些部份被認定是不需要的，這些部分就會被移除。只有 Development Team 才能在 Sprint 期間內更改 Sprint Backlog。 Sprint Backlog 是 Development Team 在 Sprint 內計畫完成的工作，是一個可視性高且即時的工作畫面，且只屬於 Development Team 所擁有。監督 Sprint 的進度在 Sprint 的任何時間點都可以加總在 Sprint Backlog 內剩餘的總工作量。 Development Team 至少在 Daily Scrum 追蹤剩餘工作的總和，以預測達成本次 Sprint 目標的可能性。Development Team 可以藉由追蹤 Sprint 的剩餘工作來管理本身的進度。Increment Increment 是指在 Sprint 期間內完成的所有 Product Backlog items，以及所有先前 Sprint Increment 的價值總和。在 Sprint 的最後，新的 Increment 必須是「完成」的，這意味著它必須是可用的狀態，並符合 Scrum Team 對於「完成」之定義。在 Sprint 結束時，Increment 是一種可檢視，完成的工作實體，並可支持經驗主義。向願景或目標邁出更前進的一步。 無論 Product Owner 是否決定將其發佈，Increment 都必須是處於可用的狀態。產出物透明性Scrum 建立在透明性上，基於對產出物的理解做出把價值最佳化和控管風險的決策。在產出物完全透明的情況下，這些決定才會有可靠的基礎。 而當產出物沒有達到完全透明，可能會做出有瑕疵的決定，進而減低了價值，增加了風險。Scrum Master 必須與 Product Owner，Development Team，和其它相關人員一起努力來了解產出物是否完全透明。當不是完全透明時 Scrum Master 必須幫助所有人應用最合適的作法。Scrum Master 可以透過檢視產出物，對模式的感知，仔細傾聽周圍發生的對話，以及檢視預期和實際結果之間的差異，來發現不完整的透明性。 Scrum Master 的工作是與 Scrum Team 和組織合作來提高產出物的透明性。 這項工作通常涉及學習，使人信服和改變。 透明性不會在一夜之間發生，然而它是一條道路。「完成」之定義當一個 Product Backlog item 或者 Increment 被描述為「完成」時，每個人都必須了解什麼是「完成」之定義。 雖然這會隨著 Scrum Team 的不同而有很大的差異，但成員們必須對什麼叫做工作完成有共識，如此才能確保透明性。 這就是 Scrum Team 對「完成」之定義，並且用它來評估產品 Increment 上的工作是否完成。 同樣的定義用來指導 Development Team，讓團隊知道在 Sprint Planning 中可以選擇多少 Product Backlog items。 每一個 Sprint 的目的是交付潛在可發佈的功能 Increment，而這些功能符合 Scrum Team 目前對「完成」之定義。 Development Team 在每個 Sprint 交付產品功能的 Increment。 這個 Increment 是可用的，因此 Product Owner 可以選擇立即發佈它。 如果「完成」之定義對 Increment 來說是開發組織的慣例，標準或指導方針的一部分，那麼所有的 Scrum Teams 都必須要遵守。 如果 Increment的「完成」不是開發組織的慣例，那麼 Development Team 就必須對這個產品訂下一個合適的「完成」之定義。如果有多個 Scrum Teams 在同一個系統或產品發佈上工作，那麼所有的 Development Team 就必須一起訂下一致的「完成」之定義。 每個 Increment 都是遞加於先前的 Increment，並經過徹底地測試以確保所有 Increment 都能一起運作。 隨著 Scrum Teams 的成熟，可以被預期的是，他們對「完成」之定義將擴大到包含更多更嚴謹的標準以達到更高的品質。當使用了新的定義，可能會發現一些之前已「完成」的Increment需要更多的工作。 任何一個產品或系統都應該有一個「完成」之定義，作為工作的標準。結語經由此指南提供 Scrum 知識，Scrum 同時也是免費的。Scrum 的角色，活動，產出物和規則都是不能改變的，雖然實施部分的 Scrum 是可能的，但結果並不是 Scrum。Scrum 只有在完整的時候才會存在，也才能有效的成為其他技巧，方法論，和實務發揮的運作舞臺。 ...

Scrum是产品开发和团队组织的迭代和增量过程。借助Scrum框架，可以更快，更高质量地完成任务。这是可能的，因为团队的高自我激励，自己选择如何执行任务。客户需求将被迭代优先级并快速实现Scrum - 敏捷框架 (Agile Framework)Scrum是一个框架，支持迭代和增量产品开发，允许在正确的时间完成工作，最大化交付的价值。通过自组织团队，任务执行速度更快，质量更高。实现了高水平的自我激励，这也是Scrum允许团队更快地实现更高生产力的原因。根据业务价值不断优先考虑客户需求，并定期将其集成到产品中，使客户能够及时向团队提供反馈，从而按时提高产品质量。Scrum项目主要从对待开发的产品或系统的愿景开始。一开始，这个愿景可能含糊不清，并且肯定会在市场问题而不是技术术语上说明。随着项目的进展，它将变得更加清晰。出于这一愿景，产品负责人正在撰写产品Backlog。在迭代开始时（Sprint），产品负责人将优先级产品Backlog呈现给团队，团队选择它认为可以在Sprint结束时变为可发送功能的增量。这样做，就会创建Sprint Backlog。之后，团队将独自开发他们所选择的功能。该团队现在更深入地了解需求，考虑可用技术，并评估自己的技能和能力。然后它共同确定如何构建功能，每天修改其方法以找出新的复杂性或困难。团队确定需要做什么，并选择最佳方式。这一创作过程是Scrum生产力的核心。在Sprint结束时，团队向产品负责人展示了功能的增加，因此他可以一方检查功能，另一方面及时调整项目。Scrum角色 (Scrum Roles)Scrum - 3个角色：产品拥有者团队Scrum Master管理项目的所有职责分为这三个角色。产品拥有者 (Product Owner)产品负责人代表与项目有利害关系的每个人的利益（利益相关者），他负责最终产品。他从利益相关者那里获得产品需求，创建产品Backlog（需求细分为用户故事），负责投资回报（ROI），并且他正在制定发布计划。产品负责人使用业务价值点对产品Backlog进行优先级排序，以确保首先开发最有价值的功能。 企业想要的和团队可以做的事情之间的紧张关系是什么使Scrum成为高质量生产的有效工具。团队 (Team)该团队计算出如何将产品Backlog转换为Sprint内的功能增量。每个团队成员共同负责每次迭代和整个项目的成功。该小组负责/：软件质量用户故事的技术实施交付功能软件增量整理自己Scrum MasterScrum Master负责Scrum流程。他确保每个人都遵守规则。他还消除了球队的障碍。Scrum Master不属于团队。猪和鸡 - 承诺还是参与？所描述的三个角色已经致力于该项目。其他人可能只是对项目感兴趣（参与），但他们并没有陷入困境。Scrum明确分开了这两个群体。承诺：负责项目的角色有权为其成功做必要的事情。参与：对直接成功不负责任的其他利益相关者不能不必要地进行干预。应该总是清楚谁是负责投资回报率的人，谁与ROI有利害关系但不负责任。Scrum - 笑话一只鸡和一只猪走在路上。鸡对猪说：“你想和我一起开餐馆吗？” 猪仔细考虑了这个问题并回答说：“是的，我想那样。你想叫什么餐馆？” 鸡回答说：“火腿和鸡蛋！” 猪停下来，停下来回答：“我想，我不想和你一起开餐馆。我会承诺，但你只会参与其中。”Scrum工件Scrum - 3个主要的工件：产品积压 (Product Backlog)Burndown图表Sprint积压 (Sprint Backlog)产品积压产品的要求列在产品Backlog中。它是一个始终在变化，动态优先排序的业务价值排序要求列表。需求由PO分解为用户故事。Burndown图表Burndown图表显示了每个Sprint剩余的工作量。这是一种非常有用的方法，可视化任何时间点剩余工作与团队进度之间的相关性。它通过使用Burndown图表检查他们在规划方面的进展，并根据需要进行调整。Sprint积压 (backlog)Sprint Backlog包含团队分解为任务的当前Sprint的所有已提交用户故事。Sprint Backlog上的所有项目都应该进行开发，测试，记录和整合，以充分履行承诺。潜在的可交付产品功能 (Potential Shippable Product)Scrum要求团队在每个Sprint中构建产品功能的增量。此增量必须是可以发送的，因为产品负责人可能会选择立即实现该功能。这要求增量为：彻底测试过结构良好的写得很好的代码记录功能的用户操作新的管理职责三个主要角色 - 产品负责人，Scrum Master和团队 - 是管理角色。他们都是“猪”，因为他们在项目中承诺。组织中的所有其他管理者都是鸡，他们可能对项目感兴趣并且可能对其成功有浓厚的兴趣，但他们必须通过猪来解决问题。他们只是参与其中，因此他们对项目的执行或进展没有直接的权力。Scrum可以大大简化与项目相关的问责制和权限问题，但Scrum管理角色很难发挥作用。管理复杂的工作绝非易事，但定期使用Scrum实践可以使项目的进度，问题和社会学变得明显。Scrum - 易于使用？Scrum听起来很简单，在您阅读完这篇简短的文档之后，您可能会觉得可以毫无问题地开始使用。那是错的！与任何其他方法，流程或框架一样，scrum可能会对您的工作方式产生深刻的变化，因此请做好准备:-)Scrum活动什么是Scrum活动？什么是Scrum Ceremonies？什么是产品Backlog修饰？每日Scrum中的3个重要问题是什么？Scrum Sprint循环8个步骤什么是Scrum中的Sprint？Scrum的心跳 - 每日站立每日Scrum会议 - 快速指南为什么在Scrum中固定长度冲刺？什么是Scrum发布计划？什么是Sprint计划？什么是Sprint评论？什么是Scrum的Sprint回顾会议？什么是产品Backlog改进？什么是Scrum中的持续集成/交付/部署？什么是Scrum中的时间盒事件？什么是Scrum中的Spike？什么是敏捷计划扑克？

敏捷是一个术语，用于描述软件开发的方法，强调增量交付，团队协作，持续计划和持续学习，而不是试图在接近结束时立即交付。敏捷专注于保持流程的精益，并创建最小的可行产品（MVP），在最终结果出现之前经历多次迭代。不断收集和实施反馈，总而言之，这是一个更加动态的过程，每个人都在朝着一个目标努力。Scrum和其他领先的敏捷方法敏捷是一种思维方式，它是一套价值观和原则。敏捷是一种思考和行动的方式。敏捷就是短周期，迭代和增量交付，快速失败，获得反馈，及早向客户提供商业价值，关于人员，协作和互动。敏捷是一种关于透明度，检查和适应的心态。但是，敏捷不包含任何角色，事件或工件。这是一种心态。例如，Scrum是敏捷伞下广泛使用的框架之一，它可以帮助你变得更敏捷，但敏捷运动中有更多的框架，如看板，XP，Crystal等等，如图所示下面：ScrumScrum是一个框架，人们可以在其中解决复杂的自适应问题，同时高效且创造性地提供具有最高价值的产品。它用于管理软件项目和产品或应用程序开发。它的重点是适应性产品开发战略，其中跨职能团队作为一个单元在2-4周内达成共同目标（Sprint）。它由一系列价值，文物，角色，仪式，规则和最佳实践组成。Lean (精益)精益起源于丰田生产系统（TPS），它在20世纪50年代，60年代及以后彻底改变了实物商品的生产。精益保持其在制造业中的地位，但也在知识工作中找到了新的应用，帮助所有行业的企业消除浪费，改进流程并促进创新。软件开发是精益方法的自然应用，因为与制造业一样，它通常遵循一个确定的过程，具有一定的接受条件，并导致有形价值的传递。指导精益方法所有实践的关键概念，我们称之为精益支柱。他们是：连续的提高尊重人轻量级领导看板 (Kanban)看板是一种高度可视化的工作流管理方法，在精益团队中很受欢迎。事实上，83％的精益生产团队使用看板来可视化并积极管理产品的创建，重点是持续交付，同时不会使开发团队负担过重。与Scrum一样，看板是一个旨在帮助团队更有效地协同工作的流程。看板基于3个基本原则：可视化您今天要做的事情（工作流程）：查看彼此上下文中的所有项目可以提供非常丰富的信息限制正在进行的工作量（WIP）：这有助于平衡基于流的方法，因此团队无法启动并立即承诺过多的工作增强流程：当某些内容完成后，积压中的下一个最高优先级项目将被激活看板通过定义最佳的团队工作流程，促进持续协作并鼓励积极，持续的学习和改进。动态系统开发方法（DSDM）DSDM是一个由八个原则组成的框架，包括生命周期和产品，角色和职责以及几种最佳实践技术。这些支撑和支持的理念是尽早提供具有战略意义的商业利益，从而为组织提供最佳的投资回报率（ROI）。DSDM是一种优先考虑计划和质量而非功能的方法，它在一开始就修复了成本，质量和时间，并使用MoSCoW优先级排序方法，将项目分解为四种不同类型的要求：必须有（Must have）应该有（Should have）可以有（Could have）不会有（Won’t have）支持DSDM Atern的原则有八个[13]。这些原则指导团队必须采取的态度和他们必须采取的思维方式，以始终如一地提供。专注于业务需求按时交货合作绝不妥协质量从坚实的基础逐步建立起来迭代开发持续清晰地沟通表现出控制力极限编程最初由Kent Beck描述的极限编程（XP）已经成为最受欢迎和最有争议的敏捷方法之一。XP是一种快速，持续地提供高质量软件的规范方法。它旨在提高面对不断变化的客户需求的软件质量和响应能力。它促进了高客户参与度，快速反馈循环，持续测试，持续规划以及密切的团队合作，以非常频繁的间隔（通常每1-3周）提供工作软件。该方法的名称来源于传统软件工程实践的有益元素被带到“极端”水平的想法。例如，代码审查被认为是一种有益的做法。极端情况下，可以通过结对编程的实践不断检查代码。最初的XP方法基于四个简单的价值观 - 简单，沟通，反馈和勇气。它还有12个支持实践：规划游戏 (Planning Game)小版本 (Small Releases)客户验收测试 (Customer Acceptance Tests)简单的设计 (Simple Design)配对编程 (Pair Programming)测试驱动开发 (Test-Driven Development重构 (Refactoring)持续集成 (Continuous Integration)集体代码所有权 (Collective Code Ownership)编码标准 (Coding Standard)隐喻 (Metaphor)可持续发展 (Sustainable Pace)特征驱动开发（FDD）功能驱动开发（FDD）由Jeff De Luca于1997年在一家大型新加坡银行的软件开发项目中开展。它是一个迭代和增量的软件开发过程，是一种开发软件的敏捷方法。FDD将许多业界公认的最佳实践融合为一个有凝聚力的整体。这些实践是从客户端值的功能（特性）角度推动的。其主要目的是及时反复提供有形的，有效的软件。使用FDD的优势在于，由于“初期设计足够”（JEDI）的概念，它甚至可以扩展到大型团队。由于其以功能为中心的流程，它是一个很好的解决方案，可以保持对敏捷，增量和固有复杂项目的控制。它由五个基本活动组成：开发整体模型构建功能列表按功能规划按功能设计按功能构建。每个项目都有自己独特的模型，这将产生一个功能列表。最后三个活动是短迭代过程，其构建时间不超过两周。如果它需要两周以上，那么它将被分解为更小的功能。水晶 (Crystal)水晶方法是由Alistair Cockburn在20世纪90年代中期开发的一系列方法（Crystal系列）。这些方法来自Cockburn多年的学习和团队采访。Cockburn的研究表明，他采访过的团队并没有遵循正式的方法，但他们仍然提供了成功的项目。Crystal家族是Cockburn对他们所做的事情进行编目的方式，这些项目使项目成功。水晶方法主要关注：人 (people)相互作用 (Interaction)社区 (Community)技能 (Skills)人才 (Talents)通讯 (Communications)敏捷宣言“敏捷”一词是在2001年的敏捷宣言中创造的。该宣言旨在建立指导更好的软件开发方法的原则。敏捷宣言由4个重要的价值观组成。阅读敏捷宣言的方式并不是右侧的物品不再具有价值，而是敏捷运动更重视左侧的物品。那么让我们来看看敏捷宣言的第一行。这条线表明，我们重视人，他们的互动，沟通和协作，而不是拥有各种广泛的流程和工具。当然，流程和工具很有价值，但是，如果它们真正支持人们一起工作并提供优质产品，那么它们就更有价值。我们现在在很多组织中看到的是，流程和工具本身就是目标。从敏捷的角度来看，我们对此有不同的看法。流程和工具应该支持人们共同合作并为客户创造价值。敏捷宣言原则作为敏捷宣言的补充，敏捷联盟还定义了一套12项基本原则，除了敏捷宣言之外，还提供了指导和更详细的解释：我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求，甚至是开发后期。敏捷流程利用变化来实现客户的竞争优势。经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。业务人员和开发人员必须在整个项目中每天一起工作。围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。工作软件是进步的主要衡量标准。敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐。持续关注技术卓越和良好的设计可提高灵活性。简单性 - 最大化未完成工作量的艺术 - 至关重要。最好的架构，要求和设计来自自组织团队。团队定期反思如何变得更有效，然后相应地调整和调整其行为。摘要敏捷开发是软件开发行业的一个流行词，它是管理软件开发项目的另一种方式。它不是特定的软件开发方法，而是基于敏捷宣言中表达的价值观和原则的一套方法和实践的总称。解决方案通过自组织，跨职能团队之间的协作发展，利用适合其背景的实践。基本的Scrum閱讀Scrum和自组织团队 (Scrum and Self-Organizing Team)敏捷和Scrum - 有什么区别？在Scrum Sprint中发布的频率是如何确定的？通过3个步骤建立自组织团队The Best Free Scrum Learning Resources, Guides and Articles为什么敏捷开发是您项目的更好选择？为什么Scrum是 - 快速失败技术?8经常被误解的Scrum Master角色Scrum Events - 初学者阅读文章Scrum在3分钟内完成Scrum工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？ ...

SCRUM使用经验方法（或有时称为经验主义）以适应客户不断变化的需求。经验主义是根据实际经历的内容做出决策的行为。经验方法意味着以事实为基础，以经验为基础，以证据为基础的方式开展工作，特别是，进展是基于对现实的观察，而不是基于大量前期要求的虚构计划。简而言之，我们可以学习和改进过去的错误和经验。Scrum支持经验过程控制的每一个实施的三大支柱是：透明度，检查和适应性，如下图所示：Scrum的三大支柱透明度Scrum中的透明度可以通过Scrum工具实现，例如产品Backlog，任务板和Burndown图表，每日站立，回顾，完成定义，Sprint评论等。这些工具用于通过跨职能团队转移工作流程。这是SCRUM的关键优势之一 - 允许关于工作和团队进度的可见性。这意味着当团队实现其目标时，负责该目标的人员可以得到认可和赞赏。检查必须经常检查Scrum工件并朝着目标前进，以检测不希望的差异。Scrum中的检查可以通过scrum活动来实现，例如：使用通用的Scrum板和其他信息来清除每个人的项目当前状态在开发史诗期间收集客户和其他利益相关者的反馈创建优先产品Backlog，并执行发布计划流程产品负责人检查和批准交付物演示和验证Sprint流程中的客户适应在敏捷世界中，我们始终拥抱和适应变化，以便我们不断改进。适应意味着我们改变不起作用的东西或者更好的作用。这意味着我们不断进行小型实验，保持正常工作，并在失败时进行改变。我们使用检查结果来决定接下来要运行的实验，例如：开发团队，每日站立仪式期间每天检查和调整。Sprint Review是另一个仪式，Scrum团队将要求所有股东提供反馈并相应调整。在Sprint Retrospective期间，Scrum团队在内部讨论问题和改进机会。将作为一个团队准备和调整新计划，以产生更多价值。摘要在Scrum中，决策是基于观察和实验而不是基于详细的前期规划。经验过程控制依赖于透明度，检查和适应性这三个主要思想。这意味着项目成果应该：向负责结果的人员了解流程的重要方面及时检查Sprint目标的进度，以检测不良差异尽快调整流程，以尽量减少任何进一步的偏差或问题总之，经验主义和三大支柱不仅对Scrum过程很重要，它们也是它的基础。这是您的团队在您创建的产品和您为团队使用的流程中实现持续改进的方式。角色，事件和工件只有在遵守基于价值的渐进式改进的情况下才能发挥作用，这些改进是通过接受频繁的反馈和接受变革而产生敏捷和Scrum基础综合Scrum指南什么是Scrum的三大支柱？什么是敏捷软件开发？Scrum在3分钟内完成什么是5个Scrum值？经典项目管理与敏捷项目管理为什么Scrum难以掌握？什么是Scrum中的速度？什么是敏捷？什么是Scrum？敏捷中的三个Amigos发展战略是什么？经验过程控制与定义过程控制如何保持Scrum的透明度？Scrum vs Waterfall vs Agile vs Lean vs Kanban什么是Scrum框架中的3355？为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？最好的免费和商业敏捷工具 - 每个Scrum团队都需要！什么是Scrum中的猪和鸡？什么是8种精益废物？

Scrum是一个项目管理框架，强调团队合作，问责制和迭代进展，以实现明确的目标。该框架从一个简单的前提开始：从可以看到或已知的东西开始。之后，跟踪进度并根据需要进行调整。Scrum的三大支柱Scrum的基础是经验主义，它指出知识来自经验，我们应该根据已知的事情做出决定。有三个支柱将Scrum结合在一起。为什么选择Scrum？Scrum一次提供功能，而瀑布只提供阶段。典型的瀑布式开发是基于阶段的顺序过程，在项目结束之前不会给出价值。Scrum将这种模式转变为每一周提供新功能，而不是专注于未来的大发布。Scrum将复杂的工作划分为简单的部分，将大型组织划分为小型团队，将影响深远的项目划分为一系列短时间的称为sprint的视野。通过迭代和渐进式构建，公司能够更快，更有效地为客户提供他们真正需要的产品和服务。使用Scrum，您可以在每个小开发周期结束时接收并整合客户反馈，这意味着您的结果将通过实际使用而非您的假设来塑造。这使得让客户和主要利益相关者密切参与和参与变得更加容易。敏捷与Scrum敏捷方法是一种有助于在SDLC过程中持续迭代开发和测试的实践。敏捷将产品分解为更小的构建。Scrum只是众多迭代和增量敏捷软件开发过程中的一个，它使我们能够专注于在最短的时间内提供业务价值。Scrum框架通常处理的是需求可能会发生变化，或者大部分时间在项目开始时都不知道。Scrum的特点是：轻量级简单易懂很难掌握Scrum的好处以下是scrum为组织，团队，产品和个人提供的好处。更好的质量：存在实现愿景或目标的项目。Scrum提供持续反馈和曝光的框架，以确保质量尽可能高。Scrum通过以下实践帮助确保质量缩短产品上市时间：Scrum已被证明能够为传统方法提供比最终客户快30％到40％的价值。提高投资回报率：缩短上市时间是Scrum项目实现更高投资回报率（ROI）的一个关键原因。由于收入和其他目标福利开始提前，早期积累意味着更高的总回报率。这是净现值（NPV）计算的基本原则。士气高级团队：与喜欢工作的快乐人士一起工作可以令人满意和有益。自我管理将通常由经理或组织做出的决策放入scrum团队成员的手中。加强团队协作：当Scrum团队负责项目和产品时，他们可以产生很好的结果。Scrum团队通过增强团队参与和沟通来协作并掌握质量和项目绩效。Scrum框架Scrum很简单。它与大量交织的强制组件相反。Scrum不是一种方法论。Scrum实现了经验主义的科学方法。Scrum用启发式方法取代了程序化的算法方法，尊重人和自组织，以处理不可预测性和解决复杂问题。下图显示了Ken Schwaber和Jeff Sutherland在他们的“30天软件”一书中描述的Scrum in Action，它将我们从规划到软件交付。Scrum流程的组成部分Scrum框架本身非常简单。它仅定义了一些通用指南，仅包含一些规则，角色，工件和事件。然而，这些组件中的每一个都很重要，用于特定目的，对于成功使用框架至关重要。Scrum Framework的主要组件是：Scrum角色：Scrum Master，Scrum产品负责人和Scrum团队工件：Sprint积压，产品积压，燃尽图，日志等……Scrum活动：Sprint计划，春季评论，每日站立，冲刺复古等……短跑下图显示了SCRUM框架的关键元素。该过程已由敏捷软件工具Scrum Process Canvas应用。Scrum角色当一个组织决定接受Scrum时，首先要了解的是Scrum角色与传统项目执行角色的不同之处。虽然Scrum中只有三个主要角色，但它们并不会自动与我们大多数人熟悉的标题保持一致。让我们从每个的简要定义开始：产品拥有者产品所有者是代表业务或用户社区的人员的scrum开发角色，负责与用户组合作以确定产品版本中的功能。产品负责人的主要职责是：制定产品和服务的方向和战略，包括短期和长期目标;提供或获取有关产品或服务的知识;了解并解释开发团队的客户需求;收集，优先排序和管理产品或服务要求;接管与产品或服务预算相关的任何责任，包括其盈利能力;确定产品或服务功能的发布日期;每天与开发团队一起回答问题并做出决定;接受或拒绝与Sprint相关的已完成功能;在每个Sprint的最后展示开发团队的主要实现;负责产品BacklogScrum大师Scrum master是敏捷开发团队的推动者。Scrum是一种方法，允许团队根据敏捷原则自我组织并快速进行更改。Scrum master管理信息交换的过程。Scrum Master的主要职责是：充当教练，帮助团队遵循Scrum价值观和实践;帮助消除障碍并保护团队免受外部干扰;促进团队与利益相关者之间的良好合作;促进团队内部的常识;保护团队免受组织干扰;Scrum团队Scrum团队（又名开发团队）由3到9人组成，他们必须满足提供产品或服务的所有技术需求。它们将由Scrum Master直接引导，但不会直接管理。他们必须是自我组织的，多才多艺的，并且负责任地完成所有必需的任务。开发团队负责从分析，设计，开发，测试到技术写作等每个sprint提供潜在的可交付产品增量。对于Scrum团队具有以下特征非常重要：团队必须是自组织的。所有团队组件必须管理自己的工作以完成已经给出的任务。在Agile Scrum中，没有团队负责人或直线经理的身影。每个人都必须做出足够的承诺来开展自己的活动，并为团队的成功做出贡献。如果一个失败，每个人都会失败。团队必须是跨职能的。所有团队成员必须拥有所有必需的知识和技能，以提供做得好并且随时可用的服务或产品。专家可用于必要的案例，但仅作为教练将知识传授给团队以实现特定差距。成为产品负责人需要企业愿景。产品负责人代表客户的声音，需要将他们的需求转化为Scrum Master和开发团队。这通常是一份全职工作。Scrum Master不是直线经理。他们帮助向开发团队提供所需的教练，并帮助消除团队面临的任何障碍。Scrum工件SCRUM工件用于帮助定义进入团队并且当前正在团队中工作的工作负载。还有更多的工件，例如，用户故事，发布积压，刻录图表等。但我们将专注于核心三：产品积压产品待办事项是用户故事的集合，其呈现产品团队所需/期望的功能。通常，产品所有者负责此列表。Sprint积压Sprint积压包含一系列可以包含在当前sprint中的故事。有关sprint积压与将项目包含在sprint中之间关系的两个要点需要注意。1）团队决定添加到sprint的内容。因此，团队负责交付这些物品的所有权和责任。2）在将项目从sprint backlog中删除并添加到sprint之前，团队必须确保他们拥有积压中所需的所有信息。通常，团队定义在添加项目之前必须存在的项目清单。产品Backlog与Sprint Backlog在冲刺积压是Scrum的冲刺过程中完成了由Scrum团队确定的任务列表。在sprint计划会议期间，团队通常以用户故事的形式选择一些产品待办事项，并确定完成每个用户故事所需的任务，如下图所示：刻录图表刻录图表是剩余工作与时间的图形表示。突出的工作（或积压工作）通常在垂直轴上，沿水平方向的时间。也就是说，这是一份杰出工作的运行图表。它可用于预测何时完成所有工作。它通常用于敏捷软件开发方法，如Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。杰出的工作可以用时间或故事点来表示。Scrum活动沟通是关键！SCRUM依赖于团队的所有方面并且透明地工作（Scrum支柱＃1）。考虑到这种核心理念，该方法围绕一系列关键事件构建，以确保其他两个支柱：检查和调整如下表所示：事件检查适应Sprint计划产品积压（承诺回顾）（Done的定义）冲刺目标预测Sprint积压每日Scrum冲刺目标的进展Sprint积压每日计划Sprint评论产品增量产品积压（发布）市场商业条件产品积压Sprint回顾团队合作技术与工程完成的定义切实可行的改进注意：在执行每个sprint期间，Scrum中有五个主要会议，如下图所示：Sprint计划所有冲刺都从计划开始。团队需要确定并承诺将作为sprint的一部分交付哪些项目。可能的项目总是从Sprint Backlog中获取，如下图所示：这是SCRUM主人可以发光的时间。产品所有者从业务/客户的角度确定他们需要的方面，SCRUM团队，确定他们认为可以提供哪些项目，以及SCRUM主人适应所有项目并确保满足两个方面的最佳要求。每日Scrum会议一旦团队确定了他们承诺作为sprint的一部分交付的项目。该团队将举行每日站立会议。此次会议的核心目标是确保团队中的每个人（以及可能的观察员）完全了解正在完成的任务的状态和进度：他们做了什么他们今天要做什么什么阻止他们此每日更新向团队提供实例反馈并提供。这些会议意味着简短，每人不超过3分钟。注意：观察员在那里观察，SCRUM主人必须尽可能减轻外部干扰和团队干扰。Sprint评审会议在Sprint结束时举行Sprint评审/演示会议以检查增量。团队根据完成定义演示增量，重点关注Sprint目标。产品负责人审核并接受交付的增量。Sprint回顾冲刺回顾通常是冲刺中最后完成的事情。许多团队将在冲刺审查后立即执行此操作。包括Scrum Master和产品所有者在内的整个团队都应该参与其中。您可以安排scrum回顾展达一个小时，这通常是足够的。回顾展让团队有机会确定3个关键方面：应该开始做什么？什么不顺利（并再次停止做）？什么进展顺利（并且应该继续做什么？）？这种方法的目的是不断提高团队效率。积压细化会议将积压视为项目的路线图。当团队协作创建需要为项目完成构建或完成的所有事项的列表时，可以修改此列表并将其添加到整个项目中，以确保满足项目的所有必要需求。短跑在Scrum框架中，Scrum产品Backlog中实现条目所需的所有活动都在Sprint中执行（也称为“Iterations”）。短跑总是很短：通常大约2-4周。每个Sprint都遵循一个定义的过程，如下所示：如前所述，产品待办事项中的项目按优先级排序并选择sprint backlog。一个sprint只包含几个大项目，即使单个项目低估工作的影响也会对sprint产生深远的影响。而且由于较大的项目往往难以估计和理解，因此短跑失败的可能性会进一步增加。经验丰富的Scrum团队花费时间和精力将复杂和较大的项目（即用户功能或史诗）分解为较小的用户故事（或随后分解为任务或子任务）。史诗史诗捕捉了大量的作品。它本质上是一个“大型用户故事”，可以分解为许多小故事。完成史诗可能需要几次冲刺。因此，当我们将epic用于开发时，它必须被分解为更小的用户故事。在项目周期的早期，我们提出了Epics。这些是非常高级的，几乎以营销为中心的功能性要点。我们将大型故事称为“史诗”，以传达有关它们的信息。我喜欢把这与电影有关。如果我告诉你一部特定的电影是一部“动作冒险电影”，它会告诉你有关电影的一些信息。可能有一些汽车追逐，可能是一些射击，等等。同样，将一个故事称为“史诗”有时可以传达其他意义。用户故事故事是产品要求或业务案例的简要陈述。通常，故事用简单的语言表达，以帮助读者理解软件应该完成的内容。产品所有者创建故事。然后，scrum用户将故事分成一个或多个scrum任务。用户故事通常是最终用户可见的功能。用户故事遵循“我作为世界卫生组织想要做什么”的格式，以便为什么。用户故事为客户/用户提供价值。这是客户/用户的产品要求。例如“作为客户，我希望能够创建一个帐户，以便我可以看到我去年购买的商品，以帮助我明年的预算。”任务另一方面，任务更具技术性，任务通常类似于代码，设计，为此类创建测试数据，自动执行等等。这些往往是由一个人完成的事情。任务不是以用户素材格式编写的。任务更具技术性。例如“评估用户界面的角度材料设计”或“将应用程序提交到应用商店”。為初學者提供更多敏捷和Scrum文章Scrum和自组织团队 (Scrum and Self-Organizing Team)敏捷和Scrum - 有什么区别？在Scrum Sprint中发布的频率是如何确定的？通过3个步骤建立自组织团队The Best Free Scrum Learning Resources, Guides and Articles为什么敏捷开发是您项目的更好选择？为什么Scrum是 - 快速失败技术?8经常被误解的Scrum Master角色Scrum Events - 初学者阅读文章Scrum在3分钟内完成

词汇表：精益，敏捷，Scrum，Sprint，看板将Lean和Agile看作几乎相同的事情，它们基本上是处理具有很多不确定性的项目的好方法，这就是为什么成功的初创公司采用这种方法。 （有关精益，敏捷和Scrum起源的事实历史，请参阅 此处 。）Scrum和Kanban是最受欢迎的两个敏捷项目管理框架。 它们有很大的不同 - Scrum似乎更常用，纯粹的看板更少。 但实际上每个人都使用他们自己的Scrum修改版本，这是鼓励的，通常采用看板的元素（我们也这样做）。Sprint是一个Scrum术语。 这是Scrum中的迭代周期。所以： 精益≈敏捷> Scrum>冲刺为什么精益和敏捷？因为在这个不断变化的社交和数字参与世界中，我们需要更好的方式来开展业务和管理组织。精益和敏捷是现代组织功能失调的两个主要原因的解毒剂：瀑布项目管理 ，和功能层级组织结构 。瀑布与敏捷项目管理当我们想到项目管理时，我们大多数人都会想象一个规范，循序渐进的工作方法，并有良好的规划和明确的目标设定。 这基本上是瀑布项目管理。瀑布项目管理思想在我们的文化中根深蒂固。 我们的教育强调良好的准备和一步一步的审慎。 进展正在达到检查点的标记。 了解我们正在走上正轨可以让我们感到舒适和自信，同时也有助于我们的教师和领导者更轻松地监控和管理。 这是一个很好的方法。 没有瀑布，世界上许多现代奇迹都不会存在。 全球各地的企业已成功扩展瀑布。 但瀑布有其局限性：它在重复性和相对较低的不确定性项目中运行良好。现实是，世界充满了不确定性。 人类的行为很难预测。 在您正在开发尚未找到市场的产品的项目中，瀑布式项目管理是寻找适合产品市场的非常昂贵的方式。 您可以负担得起废弃和重建产品的次数有限，并且在瀑布中进行另一次产品构建迭代所需的时间会使您在竞争中处于劣势。敏捷成为解决瀑布缺点的解决方案。 对于企业来说，它是一种更快，更具成本效益且风险更低的方法，可以应对其业务的诸多不确定因素。 在这个快速数字化转型的世界中，不再仅仅是创业公司必须应对扰乱市场。 跨行业的各种规模的企业都需要更好的方法来应对变化，敏捷是一种解决方案。传统与敏捷组织结构委派工作对领导者和管理者来说是一项日常挑战。 团队之间的移交文化为追求更高层次的企业目标创造了障碍。 敏捷通过重新定义的团队合作和领导模式从根本上解决了这些组织挑战。在传统组织中，领导和管理团队负责决策 - 战略和解决问题，预计答案将来自上方。 这给领导者“做出正确决策”带来了巨大风险。 再一次，在这个快速发展的数字和社交时代，对任何人而言，很难一气呵成。 认识到解决问题是一个发现过程，敏捷鼓励假设建立和实验作为一个整体组织练习。 简单地说，更多的眼睛和集体智慧增加了“把事情做对”的机会。精益与敏捷的精神精益和敏捷是方法，而不是方法。 即使是敏捷的实施框架Scrum，也拒绝称之为方法论。 这是因为没有一种严格的方法可以解决所有不确定性问题。 相反，你遵循某些共同的原则，或者可以概括为精益和敏捷的精神，并且大量适应：坚持不懈地追求产品市场契合度 （=为客户提供真正的价值）作为整体组织的努力。列表项目建立，衡量，学习 ：接受不确定性 - 这就是为什么我们假设，测试和验证我们是否越来越接近客户真正想要的东西。 在它被钉住之前，以小增量进行并继续迭代。了解客户，而不仅仅是销售和营销或领导团队，这是每个人的工作。 认为客户不是别人的工作 - 这也是你的工作。 因此，您被允许并被鼓励与客户一起进行构建测量 - 学习实验（即使您不是直接面向客户），领导团队将作为仆人领导者，促进系统化的协作工作框架。在Lean＆Agile中，没有人会受到指责。 如果出现故障，我们不会责怪某人，而是检查产生故障并修复故障的系统。实施Scrum视觉层次结构首先，您的企业愿景需要以“连接”的方式与组织中的每个人共享：您的员工所做的一切，一直到个人工作的任务级别，需要连接到愿景。这比人们想象的要难。 领导能够分辨和销售愿景，但这并不一定能让每个人都参与其中。 视觉分享练习实际上是与您的员工一起进行的视觉形成练习。输入Scrum：Epic，Story，Task是Scrum术语，可帮助人们思考产品或项目中需要构建或完成的所有关键事项，以实现共享愿景。 根据设计，Scrum通过沿着视觉层次结构进行“Backlog”创建练习，将每个人放在同一页面上。运行SprintScrum是一个由时间限制的项目管理框架，由Sprint组成，根据团队工作的特点，您可以设置一个固定的工作周期，通常在一到四周之间。 （据您所知，另一个流行的敏捷项目管理框架看板是一种“容量受限”的方法。）我们的想法是以小增量和快速迭代的方式完成工作，特别强调审查工作以帮助团队实现目标。 假设构建和重复实验是Scrum不可或缺的一部分，因为大多数项目都面临不确定性，而发现是关键（营销是一个很好的例子 - 产品市场适合自己是一个发现过程）。1.积压 (backlog)想想可能包含在产品中或需要在项目中完成的所有事情。 踏上用户旅程的道路：用户故事是将客户需求和需求置于背景中的一种很好的方式。用户故事：作为[用户]，我想[什么]，所以[值]。2. Sprint计划 (Sprint Planning)优先考虑和估计Backlog，决定在即将到来的Sprint中做什么。为了估计完成每项工作需要多长时间， 规划扑克 很有用。该 看板 （或Scrum的董事会）是Scrum的一个关键项目。 这是信息持久显示，可视化和与团队共享的地方。 鼓励定制以适应团队的工作流程。完成的定义 是Scrum中另一个必须遵守的规则。 Done的定义不仅仅是Sprint团队成员在发布前验证工作的质量保证概念。 它也是Sprint中发生的许多假设和实验的测量和学习标准。Scrum中有两个辅导员角色。 第一个是 产品所有者 ，“什么”的人，第二个是 Scrum Master ，“如何”的人。 关键在于促进 - Scrum团队的生产力以“ 速度 ” 来衡量 ，或者他们能够以多快的速度完成任务，并且最有效的是促使团队成员单独和共同决定做什么和做什么，而不是而不是像传统的等级组织那样指导他们。3.每日站立 (Daily Standup)一个典型的Scrum团队应该在3到9人之间 ，包括产品负责人和Scrum Master。 任何更大的，团队的速度下降，所以最好分成不同的Scrum团队。速度的关键在于团队成员之间在进步和障碍方面的丰富沟通。 固定格式每日站立被证明是用于这一目的非常有效： 每天都 在 同一时间 ，为 不到15分钟 ，球队在看板前聚集，并且每个团队成员通过回答以下分享他们的进步三个问题：✓昨天做了什么工作？✓今天计划做些什么？✓任何阻碍的方式？或者，团队也可以按照看板上的完成和待办事项的顺序进行。 如果多个团队成员参与每个看板委员会项目的工作，这可以是更好的格式。在 每日站立不是状态更新会 为经理，找出谁是落后于计划或给工作指令。 状态更新仅提供快照 - 重要的是签入流程。 站起来是团队了解已完成的工作和剩下的工作，以便人们加快团队合作。 如果有人被困，其他团队成员会帮忙。 如有必要，Scrum Master会重新调整工作流程，以便于移除障碍物。4. Sprint评论和回顾 (Sprint Review and Retrospective)在每个Sprint结束时，Scrum团队会召开两次会议。第一个是“什么”会议：Sprint Review将讨论由产品负责人推动的最后一个Sprint所做的工作。 这次会议通常伴随着新版本和其他成就的演示，欢迎来自组织其他成员的成员加入。第二个是“如何”会议：Sprint回顾展。 这是Scrum团队成员反映和讨论在上一个Sprint期间出现的障碍，即使事情进展顺利，还有改进的想法。 Scrum所有者通过确保重点仍然是修复流程而不是人们责备来促进此会议。在两次会议结束时，团队更新Backlog并计划下一个Sprint。Scrum的常见陷阱‣无灵魂的Scrum：冲刺为迷你瀑布通常，用户故事成为迷你规范文档。 然后，执行编码或任何活动，然后进行UAT（用户验收测试）或其他签核过程。 乍一看，这听起来并不错，许多团队陷入了这个陷阱。问题是，这只是以迷你瀑布风格运行的迷你项目。 分析，设计，编码和测试以顺序方式完成，可能跨越多个Sprint，最有可能作为功能之间的移交过程（例如BA（业务分析师）>开发人员> QA（质量保证））。精益与敏捷是关于不确定性的发现。 在Scrum中，构建 - 度量 - 学习周期被设计为在Sprint中发生，并且从事假设，MVP（最小可行产品）构建和测试的团队成员需要彼此尽可能地工作; 即跨职能团队合作。 工作不必是顺序的 - 如果某些东西不起作用或缺少标记，那么完全可以进行设计更改和修改，或者做出有意识的决定以采用不同的方法; 即调整和微型旋转。 迷你瀑布击败了迭代的目的，只实现了Scrum的小增量优势。‣领土Scrum敏捷现在在软件开发团队中很常见。 问题是，在许多组织中，只是运行Scrum的开发团队，有效地在组织内创建了一个岛。结果是开发团队与组织其他部门（即销售团队）之间的交流文化：“我们按照您的规范将产品整合在一起，现在就去销售它”。传播组织范围敏捷的关键是让人们将敏捷视为一种更广泛的沟通，合作和共同创造概念，而不仅仅是一个项目管理框架。 问一个问题，如果我们内部无法很好地连接，我们如何与客户建立联系？ 这应该会促使持续的客户价值创造和产品市场适应各个团队的思维。在组织范围的敏捷的实际实施方面，销售和营销的Scrum可以与开发团队的Scrum并行运行。 最终，最好的目标是转向跨职能的Scrum团队，其中开发，销售和营销职能都在每个Scrum团队中，并与产品或客户项目保持一致。‣Scrum Master in Command在每日站立期间，如果人们向Scrum Master提供状态更新，并且Scrum Master告诉人们该做什么，那么你就是在击败Scrum的目的。Scrum是一种系统性的努力，可以使组织脱离管理者 - 工作者模式。 在解决问题的企业中，指挥领导模式失败 - 它依靠领导者得到所有答案，使领导者自己成为障碍。在敏捷组织中，你试图从人们身上带出所有“合作” - 合作，协作，协调，共同创造，沟通，联系等等。 Scrum Master的作用是保持“co”流向侧面，而不是像指挥一样垂直。我们还必须了解“工人”在经理 - 工人模式中的被动安慰：接受工作指示是令人欣慰的，因为您不必考虑原因和方法，并且您不受决策责任的影响。 Scrum以多种方式解决了转变为自主工作模式的痛苦; 小型构建模块方法使工作更容易管理，每日站立是为了让团队成员在遇到困难时互相帮助，并且不责备人的文化鼓励个人承担实验风险。‣冲刺直到你掉落如果一个领导者设计“冲刺”作为一种系统的手段，使人们在永久的高度戒备中尽可能地努力工作，那只是危机的习惯性管理，或者更糟糕的是，剥削劳动力。一个不那么邪恶的领导者可能将“冲刺”定位为类似于赛道或游泳中的间歇训练。 他可能会说，通过持续不断的紧张工作，团队将能够突破其表现的界限。 但这会给团队成员带来精神疲惫的风险。 在如此高压力的环境中吸引和留住人才是很难的。在一次Sprint之后，下一个Sprint立即开始。 如果团队开始尝试从最后一个恢复新的Sprint，显然他们已经过度踱步。 Sprint必须以可持续的速度运行，不需要Sprint之间的休息或恢复时间。实际上，Scrum Sprints可能不应该被称为sprint。 它应该更像是慢跑或其他东西。 是的，你确实希望你的团队的“速度”增加（在Scrum中我们使用“ Burn Down Charts ”来衡量这一点），但这并不是你追求的终极速度。 你追求的是平均速度的提高，即在相同的时间内覆盖更多的距离。 正如任何长跑运动员都会证明的那样，找到合适的节奏和节奏是迈向远方的关键。采用精益和敏捷并非易事。 精益和敏捷背后的意识形态是理性的，对大多数人来说都是有意义的，但是将其付诸行动需要思维方式的转变和许多破碎的习惯。 虽然如果做得好，精益和敏捷将带来令人难以置信的生产力，积极性和突破组织。 在Lifecycle，我们非常了解组织行为和黑客攻击方法，以推动成功的精益和敏捷组织转型。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master?What is Velocity in Scrum?What is Agile? What is Scrum? ...

为实际的Sprint Planning做准备充分的Sprint计划实际上是由所有团队成员完成的。团队代表在团队之间提交工作是不合理的。Sprint Planning 的要点每个团队队员应该准备Sprint Planning。如果多个scrum团队正在处理相同的产品待办事项列表，那么它们必须一起聚集并参与sprint计划。使用优先级排序的待办事项列表，PO按顺序向团队呈现最高价值的故事。目的是让团队中的每个人都完全理解故事的意图以及故事的具体接受标准 (definition of done)。解释所有用户故事的done定义也是很有帮助的。每个Sprint 都以Sprint Planning 会议开始，包括两个会议——WHAT会议和HOW会议。在WHAT会议中，团队从Scrum Product backlog 待办事项列表中选择用户故事 (user stores) ，他们将在其上工作。并且，在HOW会议中，所选择的用户故事被进一步分解成具有设置优先级和故事点的小任务到 Sprint Backlog。规划的前半部分——决定实现什么回顾Sprint目标 (Reviewing Sprint Goal) - Scrum会议代表将展示项目的高级愿景。产品负责人确定Sprint的目标，并证明它将如何向产品交付价值。检查产品待办事项清单 (Reviewing the Product Backlog)- 在sprint计划会议之前，产品所有者将重新排列用户故事，并优先考虑这些故事。计划第二部分-如何完成工作在计划的后半部分，团队决定如何完成工作。创建待办事项列表 (Creating Product Backlog) - PO与团队一起回顾最高优先级的故事，并决定他们在每次冲刺中能做多少。每个人都应该在这个计划中投入工作。如果有人无法提交，PO和团队需要共同努力来改变sprint的形状，直到每个人都能够提交。Sprint计划是scrum中的关键协作工作。更新发布计划 (Updating the Release Plan) - 一旦团队致力于用户故事，产品所有者将重新访问用户故事到Sprints的版本计划映射。使用当前信息，团队在前一次Sprint中完成的故事，从当前Sprint的产品待办事项列表中删除的故事，产品所有者更新发布计划。Scrum非常认真地对待承诺步骤。每个人的承诺对于实现你的冲刺目标是非常重要的。从回顾sprint目标到更新发布计划，每个步骤都必须仔细遵循。Scrum工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色功能原因模板？冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

故事点 (Sotry Points) - 简介Scrum指南告诉我们，估算应该由将要完成工作的人提供，但它并没有告诉我们应该如何提供估算。它把这个决定留给了我们。Scrum团队使用的一种常见策略是使用称为故事点的度量单位进行估算。但为什么要使用Story Points而不是几小时或几天或任何其他众所周知的时间单位？我们是故意试图混淆吗？在本文中，我将介绍使用Story Points的优缺点，并得出一个令人惊讶的结论。什么是故事点？“故事点是一个相对的度量单位，由各个Scrum团队决定和使用，以提供完成要求的努力的相对估计 “为什么要使用Story Points？故事点旨在使团队评估更容易。与其他产品积压项目 (product backlog items) 相比，团队只考虑产品积压项目需要多少工作量 (effort)，而不是查看产品积压项目并在几小时内估算出来 。好的，所以它使评估更容易，但它有用吗？我们无法对成本和可交付时间进行任何预测，至少直到我们从可能需要几个月的几个冲刺(sprints)中获得了速度(velocity)的平均值使用时间作为度量单位有什么问题？几百年来，我们有了标准的时间单位。为什么我们不能使用几小时或几天？好吧，简而言之，因为你的小时与我的小时不一样。如果您要求两位开发人员估算相同的任务，您将得到两个不同的答案。虽然一些差异可能是由规范或理解上的差距来解释的，但事实是开发人员拥有不同的知识和经验，因此需要花费更多或更少的时间来完成相同的工作。要求这两个开发人员评估完成一个产品积压项目(Product backlog item) 相对于另一个产品积压项目所需的工作量，并且您更有可能最终达成共识。使用Story Points的真正原因因此，到目前为止，您可能不相信使用Story Points的必要性。好吧，他们展示了完成不同产品积压项目工作的相对工作量，但这对任何事情有何帮助？在我们了解团队的速度之前，我们仍然无法预测产品积压项目何时可能完成。更糟糕的是，如果团队成员发生变化，速度会发生变化，我们将不知道新的速度是什么，直到一段时间。所有这些问题导致许多人试图在故事点和时间之间建立关联，但正如 Mike Cohn 在他关于将故事点与小时相关的文章中 指出的那样，这并不是微不足道的。但是，尝试将故事点数与小时相匹配是不容忽视的。重要的是团队可以在冲刺 (sprint)中完成多少个故事点 (story points)，称为速度 (velocity)。当你知道这一点时，你可以做出一些预测而且你知道什么，它们可能是好的。很好。使用Story Points的真正原因是它们是准确的。谁这么说？Jeff Sutherland，Scrum指南的合着者。在他关于为什么故事点比几小时更好的文章中 他这样说：使用故事点因此比小时更快，更好，更便宜，而表现最好的团队完全放弃任何每小时估计，因为他们认为它是浪费，只会减慢他们的速度。冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

Scrum要求产品在每个Sprint中保持可能可交付（例如，经过适当测试/集成）的状态，产品所有者(Product Owner)声明哪个工作是最优先考虑的，并且工作可以分成薄的垂直切片，通常是以客户为中心的用户故事(User Stories) 每个都要大于几天。如果我们正在做其他敏捷 (Agile)的东西，我们不能错过发布日期 (Time Schedule)，因为产品每周或每两周都可以发货。估计错误的唯一缺点是我们会按时发货，同时省略不太重要的功能 - 比瀑布 (waterfall) 或伪敏捷团队 ( pseudo-Agile) 今天所遇到的压力更小的工作方式。在瀑布式方法中 (waterfall approach)，管理人员根据时间确定团队成员的工作负载能力。经理要求选定的开发人员估计他们预期某些任务需要多长时间，然后根据该团队成员的总可用时间分配工作。在瀑布中，测试是在按照特定的职位名称之后完成的，而不是与代码一起编写的。瀑布的缺点是众所周知的：工作总是迟到，总是有质量问题，有些人总是在等别人，而且总是在最后一刻才赶上最后期限。Scrum团队采用完全不同的方法。首先，整个Scrum团队而不是个人负责这项工作。整个团队负责每个产品Backlog项目。整个团队负责测试产品。没有“我的工作”与“你的工作”。所以我们专注于每个产品积压项目的集体努力，而不是每个任务的个人努力。其次，Scrum团队更喜欢将项目相互比较，或者以相对单位而不是绝对时间单位来估算它们。（最终，这会产生更好的预测。）第三，Scrum团队将客户可见的需求分解为尽可能小的故事，从而大大降低风险。如果有7个人的工作量太大，我们会组建功能团队 (feature team) 消除依赖 (dependency)。估算过程是什么样的？Scrum并未规定团队估算其工作的单一方式。根据Sprint计划会议的决定，Scrum定义的唯一估计是团队是否会在此Sprint中尝试PBI 。常见的估算方法包括T恤尺码（S，M，L和 XL），2（1,2,4,8）的力量，斐波那契序列 (Fibonacci sequence):1,2,3,5,8等，或者只是小而不是需要拆分（参见下面的#NoEstimates）。在Product Backlog改进会议(refinement Meeting) 中，团队与产品负责人坐下来讨论产品Backlog顶部的故事。产品负责人通常需要工作量估算来帮助评估ROI，有效地确定产品Backlog中项目的优先级，并预测在给定的发布日期之前哪些项目将准备就绪。因此，产品负责人希望对工作难度进行诚实的评估。尽管团队中的个性不同，为了收集观点的横截面，所有团队成员通常同时披露他们的估计值是有用的。个人一次出示他们的牌，激发“计划扑克 (Planning Poker)”这个词。个人通常会选择不同的牌。这应该引发对实施方法的讨论，向产品负责人 (Product Owner)澄清要求，并将需求分成较小的故事（其中一些将是较低的优先级）。通常需要几轮来达到单一的工作量估计，这反映了整个团队对故事难度的感觉。改进和澄清比估计本身更重要。根据敏捷宣言，业务人员和开发人员必须在整个项目中每天一起工作。冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

“快速提供质量”是当前竞争激烈的数字商业世界的成功口号。传统的软件开发方法将开发和测试分为两个不同的步骤 - 开发人员构建一个功能，然后QA团队对其进行缺陷测试。随着产品的增长，测试时间和工作量也呈指数级增长。这给项目经理带来了一个不受欢迎的选择 - 要么延迟发布，要么停止测试。“敏捷”的出现是因为需要一种更好的软件开发方法，使开发人员和测试人员能够减少代码中的错误数量，并分别在代码的早期检测错误。敏捷方法可帮助组织管理不可预测性，同时推动团队之间的协作和透明度，并采用不同的思维模式来取得成功。在敏捷环境中，开发周期将任务分解为小增量。它使团队能够以更高的协作性和更好的质量交付工作软件。敏捷软件开发方法为业务带来了显着的好处 - 加快了产品上市时间，提高了竞争优势，提供了高质量的软件，丰富了客户的满意度。第10届年度敏捷状态调查表明，敏捷软件开发在过去十年中越来越受欢迎。包括初创公司和大型企业在内的组织数量每年都在不断增加。这篇博文简要概述了第10届Agile™状态调查中提出的关于采用敏捷软件交付的十大理由：加速产品交付 - 敏捷开发方法使企业能够在更快的发布周期内提供高质量的软件，更符合用户需求。涉及较短冲刺的敏捷开发方法正在获得动力，以保持与业务目标一致的开发过程的速度。增强管理不断变化的 优先级的能力 - 敏捷的软件开发方法不仅需要团队更快地开发和测试，还需要更快地为客户提供产品和服务的增强功能。确保客户以可靠和可用的方式进行更改/增强需要在项目的每个步骤中采用敏捷方法。提高生产力 - 组织需要不断寻找以获得更好的业务成果。他们需要更好的方法来改进IT人员用于交付软件的技能和方法。敏捷方法可以通过更有效的通信提高生产力，同时高度响应不断变化的客户需求。提高软件质量 - 在敏捷环境中，开发和QA团队相互合作非常好，还旨在与客户密切合作，快速开发软件。敏捷技术可评估和提高软件质量，同时提供更高的客户价值。提高交付可预测性 - 客户通常关心可预测性。他们要求团队善于制定并保持承诺，在每个sprint结束时可靠地提供工作，测试和补救的代码。没有可靠和可预测的团队，稳定的可预测程序，特别是当团队之间存在多个依赖关系时，是不可能的。通过灵活的软件交付方法，强调设置指标和度量，团队可以计划，协调和交付足够的可预测性以及发布级别的承诺。改善业务 / IT一致性 - 组织需要改进业务和IT一致性，以实现高业务价值。组织需要高效和有效才能具有竞争力。快速变化的商业环境需要创新和灵活性。组织必须专注于IT，以正确的方式实施正确的系统以满足业务需求。组织必须通过关注在考虑基础架构和技术的同时改进的流程来实现业务/ IT协调。敏捷方法可以使所有IT运营流程 - 变更问题 - 事故 - IT运营 - 保持一致。此外，它还专注于减少设计，记录，部署和测试的时间和精力，以及成本和投资。提高项目可视性 - 可见性是快速适应所需变更的关键。在缺乏项目可见性的情况下，很难跟踪和衡量生产率的提高。参与软件开发和交付的团队需要知道他们前进的方向，就像组织领导者需要知道的那样。各种开发，测试和运营团队必须了解项目和组织的当前状态，性能和目标。通过敏捷方法提高[团队和领导能力，可以及早提供客户价值。降低项目风险 - 敏捷作为一种有效的软件开发方法，可以降低软件开发的风险。短跑中的软件开发包括敏捷技术，例如冲刺回顾，冲刺回顾等。这些技术提供持续的反馈，有助于防止期望与完成的软件之间的偏差。通过敏捷，Scrum团队首先优先考虑最高价值和最高风险的要求。他们使用现有的敏捷工件和会议来管理风险。提高团队士气 - 敏捷的软件开发方法强调各团队之间更好的沟通和协作。敏捷方法的本质是让团队对未来的挑战感到兴奋。Scrum会议，优先级，回顾和反馈机制使团队环境保持活跃和发生。自我组织，无缝沟通，尊重每个成员，高度协作，所有利益相关者的项目可见性等，这些都是敏捷方法的内在特征，带来积极的变化并保持团队的积极性。特别是，通过各种论坛和讨论板进行沟通是敏捷方法的核心。敏捷方法 要求组织倾听员工的意见，传达其计划以处理员工的各种问题，并认可员工的努力和成就。改进工程学科 - 正确采用和实施的敏捷原则和实践，使团队成员能够管理和提高软件质量，而不仅仅是完成工作。高质量产品的重要组成部分始终是良好且可扩展的设计和架构。当一个组织采用敏捷原则以提供高质量产品为目标时，他们也应该接受合理的工程学科。良好的设计，完善的配置管理和有效的[测试策略对于充分利用敏捷性至关重要。您现在想采用敏捷Scrum吗？您还想了解更多关于Scrum的知识，以及如何建立自己的scrum团队？下面是一些非常有用的文章，可以帮助您开始：敏捷和Scrum基础综合Scrum指南什么是Scrum的三大支柱？什么是敏捷软件开发？Scrum在3分钟内完成什么是5个Scrum值？经典项目管理与敏捷项目管理为什么Scrum难以掌握？什么是Scrum中的速度？什么是敏捷？什么是Scrum？敏捷中的三个Amigos发展战略是什么？经验过程控制与定义过程控制如何保持Scrum的透明度？Scrum vs Waterfall vs Agile vs Lean vs Kanban什么是Scrum框架中的3355？为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？最好的免费和商业敏捷工具 - 每个Scrum团队都需要！什么是Scrum中的猪和鸡？敏捷和Scrum原则敏捷宣言和十二项原则Scrum中最经常提到的10个基本规则Scrum工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色功能原因模板？冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？Scrum活动什么是Scrum活动？什么是Scrum Ceremonies？什么是产品Backlog修饰？每日Scrum中的3个重要问题是什么？Scrum的心跳 - 每日站立每日Scrum会议 - 快速指南为什么在Scrum中固定长度冲刺？什么是Scrum发布计划？什么是Sprint计划？什么是Sprint评论？什么是Scrum的Sprint回顾会议？什么是产品Backlog改进？什么是Scrum中的持续集成/交付/部署？什么是Scrum中的时间盒事件？什么是Scrum中的Spike？什么是敏捷计划扑克？Scrum Sprint循环8个步骤

The Chicken and the Pig 的商业寓言解释了Scrum流程中的早餐猪和鸡。这是区分Scrum / Agile世界中角色的一种方法。角色是敏捷的关键。它们是不变的，是每个决策的基础，并定义了Scrum中最基本的人际关系。猪和鸡寓言鸡和猪的寓言用于说明参与项目的项目利益相关者的不同级别。基本的寓言运行：猪和鸡正走在路上。鸡说：“嘿猪，我以为我们应该开一家餐馆！”猪回答说：“嗯，也许，我们会怎么称呼它？”鸡回应：“火腿鸡蛋怎么样？”猪想了一会儿说：“不，谢谢。我会坚持，但你只会参与其中。“有时候，故事是一个谜语;问题：在培根和鸡蛋早餐中，鸡肉和猪之间有什么区别？答：鸡是参与的，但猪是承诺！Scrum语境中的猪与鸡The Chicken and the Pig的商业寓言是关于项目或事业的承诺。当生产由火腿和鸡蛋制成的盘子时，猪提供需要他牺牲的火腿，并且鸡提供不难生产的鸡蛋。因此，只有鸡只参与，所以猪确实在那道菜中生长，但两者都需要生产这道菜。在Scrum的背景下，鸡会对将要开发的产品有所贡献，但是猪决定了它将如何完成以及它可以完成的速度。因此，猪包括开发团队成员，代表鸡的产品所有者和Scrum Master，负责组织一些Scrum事件 (Scrum Events)，特别是在Scrum站立 (Daily Standup)期间，而客户，供应商，管理人员和其他有远见的重要人物事实上，是Scrum中的鸡。Scrum学习资源什么是产品负责人在Scrum中的角色？为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？Scrum在3分钟内完成Scrum Sprint循环8个步骤最好的免费和商业敏捷工具 - 每个Scrum团队都需要！什么是Scrum中的猪和鸡？谁在Scrum中创建产品Backlog项目或用户故事？

当我以敏捷教练的身份进入组织时，Scrum的一个常见问题就是Sprint Planning。“这些会议需要很长时间！" 我的客户抱怨。一个使Sprint Planning会议既短又高效的简单方法是通过定期使用Backlog Grooming Meeting。有时称为Story Time Section，这些会议的目的是对Product Backlog 进行改进 (Product Backlog Grooming Sessions)。这个定义故意含糊不清，因为会议非常通用。Backlog Grooming会话可用于：编写用户故事（可以在一系列一个或多个Backlog Grooming Section“从头”构建Product Backlog）列表项目分解太大的用户故事（史诗 epics）改进写得不好的用户故事估计积压项目添加接受标准深入研究待办事项以便进行长期技术规划最后点句很重要。有些人错误地认为，做Scrum意味着除了下一个冲刺阶段 (Sprint) 将要发生的事情之外永远不要关注任何事情。这不是真的。相反，积压梳理会议 (backlog Gromming Meetings) 是: 例如， Product Owner说 “3月份的发行版非常棒，所以今天我想花时间看看，我希望获得在7月份的发行版中的用户故事。” 这样做给团队一个机会来进一步研究产品的未来，并且能够提醒他们技术挑战和“必须解决的问题”。如何举行有效的Product Backlog Grooming？以下是一些指导方针：记住一个目标: 在每次会议中，产品负责人都应该说：“这是我今天想要完成的。”这可以是团队达成的协议目标，但关键是要在会议开始前设定目标。漫步到一个待办事项列表梳理会话中，说：“嗯，嗯……我们今天想谈什么？”“是浪费时间的保证。”安排会议来支持和改进下一届Sprint Planning会议: 一个好的Product Backlog Grooming Meeting让所有参与其中的人都感到熟悉Product Backlog，让他们清楚地了解下一轮Sprint的目标，并且意味着他们可以在Sprint Planning会议中实现目标。因此，安排Product Backlog Grooming Section，在下一个Sprint Planning之前至少几天。限制“鸡”的参与: 在Scrum中称为“鸡”，利益相关者 (stakeholders) 可以是积压梳理会话 (Backlog Grooming Meeting) 的有效参与者。但是限制他们的数量。例如，如果您有10个利益相关者，您想要从他们那里收集反馈，那么通过一系列2-3个会议，而不是一个大型会议，从他们那里获得反馈。记住，涉众通常并不像团队、产品负责人和Scrum Master那样理解Scrum的规则。他们通常不具备“良好的Scrum礼仪 (Scrum Manner)”，你可能会发现一大群人会很快接管你的会议，使得会议变得混乱和有效。定期使用Backlog Grooming Sections 是确保Sprint Planning会议更顺利运行的最佳方法之一。它们改进了产品待办事项列表的质量，使每个参与其中的人都更加熟悉所要求的内容，并且使自信地达成Sprint承诺变得更加容易。基本Scrum阅读列表什么是Scrum工件？什么是5个Scrum值？敏捷宣言和十二项原则Scrum中最经常提到的10个基本规则什么是Scrum的三大支柱？什么是产品Backlog修饰？每日Scrum会议 - 快速指南完成与接受标准的定义Scrum中Ready的定义是什么？为什么在Scrum中固定长度冲刺？如何写短距离目标？

Scrum是一个轻量级框架，具有最少的规则。这些规则有助于人们在创建软件产品的每一天都能凭经验充分利用。产品积压，sprint积压和潜在的可交付产品增量是Scrum工件的示例。产品积压 (Product Backlog)Sprint积压 (Sprint Backlog)增量（可能可发货）(Potentially Shippable)产品积压 (Product Backlog)产品Backlog只是项目中需要完成的所有事情的列表。它取代了传统的需求规范工件。这些项目可以具有技术性质，也可以是以用户为中心的，通常采用用户故事的形式。Sprint积压 (Sprint Backlog)sprint backlog是当前sprint中为开发选择的精炼产品积压项目列表，以及团队完成工作的计划。它反映了团队对可以完成的工作的预测。一旦sprint backlog建立，开发团队就开始研究新的产品增量。产品增量 (Product Increment)每个sprint都会产生一个产品增量，这是最重要的Scrum工件。产品增量是每个冲刺的“目标线”，并且在冲刺结束时，它必须：质量足够高，可以给用户满足Scrum团队目前对已完成的定义产品所有者可以接受产品Backlog修饰 (Product Backlog Grooming)Scrum产品积压只是项目要做的事情列表。产品负责人创建，维护并定期重新订购要为产品实施的功能列表，以适应新出现的需求，客户反馈和市场变化。Sprint规划产品Backlog的基础 (Groundwork of Product Backlog for Sprint Planning)产品Backlog顶部的产品Backlog项目应该进行细化，并可能很快包含在下一个sprint计划中。积压下来的项目需要更少的具体，并且可以反映更大的矿石更复杂的想法。这些较大的块需要在接近Product Backlog的顶部时分解成更小的块，如下图所示，如Gunther Verheyen的文章 - 产品Backlog的价值所示：在上面的产品待办事项中，产品待办事项（PBI）很容易被分类为三个不同类别的sprint计划：Sprint计划：Sprintable整理：可操作/用户故事 (Groomed)未来：史诗/宇宙故事 (Epic / Cosmic Stories)通过维护分类良好的产品积压（如上述结构），您的团队应该更容易进行sprint计划流程。更多Scrum阅读What is Definition of Ready in Scrum?Why Fixed Length Sprints in Scrum?How to Write a Sprint Goal?What is Sprint Planning?What is Sprint Review?What is Sprint Retrospective Meeting in Scrum?What is Product Backlog Refinement?

什么是Scrum团队？Scrum团队是一组个人（通常在五到九名成员之间）一起工作，以提供所需的产品增量。Scrum框架鼓励团队成员之间进行高水平的沟通，以便团队可以：遵循共同的目标遵守相同的规范和规则相互尊重Scrum团队的结构Scrum团队。Scrum团队包括：产品拥有者Scrum Master，和开发团队Scrum团队分享与产品交付相关的不同任务和职责。每个角色都密切相关。建议Scrum团队成员尽可能在同一位置一起工作。让我们从责任，权限和特征的角度来看看这些角色。项目负责人产品负责人是团队成员，他知道客户想要什么以及他们想要的相对业务价值。然后，他或她可以将客户的需求和价值转换回Scrum团队。产品负责人必须了解产品的业务案例以及客户需要的功能。他必须与团队协商，以确保他们正确实施产品愿景。最重要的是，他必须有权做出完成项目所需的所有决定，换句话说，产品负责人负责管理产品Backlog，其中包括：清楚地表达产品Backlog项目。订购产品Backlog项目以最好地实现目标和任务。优化团队执行的工作价值。确保产品待办事项清晰可见，透明且清晰，并显示团队将进一步开展的工作。确保团队将产品Backlog中的项目理解为所需的级别。Scrum MasterScrum master帮助团队保持对业务承诺的责任，并消除可能妨碍团队工作效率的任何障碍。他们定期与团队会面，审查工作和可交付成果，最常见的是每周一次的节奏。Scrum master的作用是指导和激励团队成员，而不是对他们执行规则。Scrum master的作用包括：确保流程顺利进行消除影响生产力的障碍组织关键活动和会议开发团队开发团队由组织组织和授权，以组织和管理自己的工作。由此产生的协同作用优化了开发团队的整体效率和有效性。开发团队具有以下特征：他们是自我组织的。没有人（甚至不是Scrum Master）告诉开发团队如何将Product Backlog转换为潜在可释放功能的增量;开发团队是跨职能的，具有创建产品增量所需的所有技能;Scrum不承认开发团队成员的任何头衔，无论该人员正在执行哪些工作;无论需要解决哪些领域，如测试，架构，运营或业务分析，Scrum都不会认可开发团队中的子团队; 和，个人发展团队成员可能具有专业技能和重点领域，但问责制属于整个开发团队。