本文主要是介绍Scrum的工件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我们采用了Scrum进行开发方面的管理，那么所有的计划和工作都应该是透明的，这给了我们检查这些东西的机会，以便能够即时做出调整来适应即将发生的变化。
那么Scrum为我们设计了一些工件帮助我们检查我们的工作和计划，每个工件都有它的承诺，这有效地帮助我们的团队理解和检查我们的工作时否取得了工件所代表的工作或价值。
这些工件存在的目的是为了最大化关键信息的透明度。这些工件就是我们每个人在检查我们的工作进展和方向时，作出评价的最低适应标准或者说是基础。
每个工件的承诺确保了它能够提供足够的信息来增强计划和工作的透明度。这些工件各自的承诺都有自己的目标，如：
1.Product Backlog（产品待办列表）
对于产品待办列表来说，它的目标是取得Product Goal（产品目标）
2.Sprint Backlog（Sprint待办列表）
对于Sprint待办列表来说，它的目标是取得Sprint Goal（Sprint目标）
3.Increment（增量）
对于增量来说，它的目标就是实现Definition of Done（完成的定义）的要求。
由于每个工件都有自己的承诺，它们的存在增强了我们进一步应用前面实践的获得的经验（在Scrum实践中，经验是很重要的，但是它会随着检查和再适应的过程不断发展），同时这些承诺也增强了Scrum的价值。
接下来，我们来介绍一下这些工件，它们有六个。
- Product Backlog（产品待办列表）
Product Backlog 产品待办列表里有很多任务要做，这些任务最终需要我们的Scrum团队来在一个Sprint或多个Sprint来完成。这里任务一般是很多，不可能在一个Sprint里全部完成，因此综合所有的资源（测试、开发、商业分析、设计等）的可用度和任务优先级来确定要从这个待办列表里拿出多少个任务来在一个Sprint里完成。这些工作都会发生在做Sprint计划会议中（Sprint Planning event.）。
这个产品待办列表会不断被优化，如有些不再需要，有些需要调整，有些再描述更详细些，有些需要增加进来，有些任务需要进一步拆分等等，这些优化的工作是一个持续进行的过程，只要这个项目还要存在的价值，那么这个列表的优化是不会停止的。
在这个过程中，Product Owner可能会受到开发者的影响，开发者会帮助其理解和权衡选择出来的任务。
Product Backlog 的承诺就是要实现产品的目标。产品是传递价值的载体。它有清晰的边界、已知的涉众、定义良好的用户或客户。产品可以是一种服务，一种实体产品，或者更抽象的东西。产品目标是Scrum团队的长期目标。在开始下一个目标之前，他们必须完成(或放弃)一个目标。
- Product Goal产品目标
承诺，一个精神上的东西，一旦许诺了，就会全力以赴去达成。这个魔力在很多人身上都会应验。所以在Scrum的实践中，一个软技能就是让Scrum的参考者作出相应的承诺。这也是在后来可以进行问责的一个依据，承诺巩固了Product Owner, Scrum Master 和 Developers在Scrum Sprint中的责任。产品目标是Product Backlog产品待办列表作出的承诺。产品目标贯穿了产品待办列表的始终。所以这是一个方向性问题，所以的努力都是为了达成这个目标，它也是产品在未来的状态。它必须具备战略性。换句话说，Scrum团队正在实现未来的产品，在一步一步朝着那个方向去迈进。Product Backlog产品待办列表包含了要实现这个目标的必要工作。理想一点来说，只要Scrum团队实现了产品待办列表中的必要任务就可以实现产品目标。
产品目标，是Product Owner负有责任的一个工件，其必需时常优化和沟通这个目标，具备一定的战略眼光，提高产品的成功率。
在一个Sprint结束的倒二天会举行Sprint Review会议，这是一个复盘会议，这个会议邀请整个Scrum 团队和相关的干系人和客户，目的是复盘在这个Sprint交付的增量和进度是否依然向着产品目标的。这个会议鼓励提问，如工作是如确保工作不会偏离产品目标的，有什么新的发现，有没有出什么问题等等。这些发现都会很助于做下一次的Sprint planning。
- Sprint Backlog（冲刺待办列表）
Sprint Backlog是Developers的一个计划，他们会在当前这个冲刺完成里面的任务。冲刺待办列表是在Sprint planning会议中经过各方（包括Developers）深思熟虑后从产品待办列表（Product Backlog）中选出来的任务。同时，Sprint Backlog也是一个增量交付的一个行动计划表。
Sprint Backlog一定是高度可视化，也就是每天都能够清楚地看到进度、完成的情况（可视化方面的工具都可以用上，常的就是看板、燃尽图等等），这个待办列表每天都会被更新，这通常发在整个Sprint过程中，Daily Scrum每日站会是一个重要更新场所，关于Sprint Backlog的任何更新和反馈提供了足够的细节来检查我们的进度，也给作出新的调整适应新的变化提供了依据。
Sprint Backlog的承诺是实现冲刺目标Sprint Goal。这个承诺是由Developers作出的。这个承诺分解下去，就是Developers在领取了任务对那个任务的承诺，承诺在什么时候交付那一个增量。通过每个Developer的承诺，最终兑现这个Sprint的承诺。
Sprint目标还创建了一致性和焦点，鼓励Scrum团队一起工作，而不是各自独立地工作。一起工作才能更好的实现1+1大于2的效果。大家的智慧和技能才能互补。如果团队成员出各扫门前雪的情况，那么这个Scrum团队就是很不专业的。
Sprint目标会在Sprint Planning event 中产生，然后添加到Sprint Backlog中。Developers中冲刺时，只要把本次Sprint的目标放在心上即可。如果中途出现了与预期的不一样的增量或情况，那么是可以和Product Owner讨论调整Sprint Backlog的范围，尽量不影响本次Sprint的目标。
增量是一个实实存在的垫脚石，朝着产品目标去的。在一个Sprint中，会有增量会被创建和交付。每个增量都会经过彻底测试后添加到前面的增量中，这是为了确保所有的增量能够一起工作。为了提供有价值的增量，必须确保每个增量都是可用的。最后，所有这些增量都会在Sprint倒数第二天的Sprint Review复盘会议中向各方展示，接受检查和试用。
Sprint Review主要是回顾这个Sprint的增量交付情况，不应该被认为是发布的大门，尽管有些增量已经交付到用户手里。
什么是有价值的增量呢？一个有价值的增量必然满足了完成的定义（Definition of Done），这个定义中会有各种具体的标准，只有增量都满足了这些验收标准，才能算得上是一个有价值的增量。否则就是没有用的，做了再多工作也没有用。没有功劳也有苦劳这句话在Scrum中顶多只能是怜悯。
-
Sprint Goal冲刺目标
我们再多聊一下冲刺目标。这个目标一定是清晰的，一定是可实现的。这样的目标可以给Scrum团队一个清晰的方向，同时让团队聚焦在这个目标上去开展相应的必要工作。另外，要注意一下，这个目标不能够太大，因为太大的话，团队可能会没有太大的信心去达成，相反还会给团队带来焦虑等负面影响。
Daily Scrum（每日站会）是一个检查我们的工作过程的好时机。要利用好这个时机去确保我们的工作方向和重心是朝着冲刺目标去的。 -
Increment增量
增量是我们实现产品目标的垫脚石。每个增量都是叠加到先前的增量上，并且通过了所有的测试，能够和先前的增量一起工作。确保增量是可用的，才能够交付价值。在每个冲刺（sprint）中都会有很多增量被创建出来。这些增量会在Sprint Review会议中展现出来，在相关方在场的情况下，检验增量。还是要提醒一点，Sprint Review不应该被认为是发布价值的大门。
6.The Definition of Done 完成的定义
这个完成的定义是开发者对这个增量的承诺，也就是这个增量做成什么样子，是这个增量的完成定义来决定的。它是通过若干个验收标准来定义的。所以我们可以这么认为我们兑现了Sprint Backlog里的增量的承诺，也就兑现了Sprint Goal。
这篇关于Scrum的工件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
