Scrum 之 活动

产品待办事项列表梳理

        产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:

                1.保持产品待办事项列表有序

                2.把看起来不再重要的事项移除或者降级

                3.增加或提升涌现出来的或变得更重要的事项

                4.将事项分解成更小的事项

                5.将事项归并为更大的事项

                6.对事项进行估算

        产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:

        理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。

        产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。

Sprint计划会议

        每个Sprint都以Sprint计划会议作为开始， 这是一个固定时长的会议，在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

        整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定 义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时⻓的。Sprint计划会议推荐时⻓是Sprint中的每周对应两⼩时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是限制时⻓长的,Sprint计划会议的成功⼗分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。

        1.需要完成哪些工作?

        在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作。

        Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。

        通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成的工 作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的⼩小细节。

        2.如何完成工作?

        在会议的第二部分⾥里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增 量。他们进⾏行⾜足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成⼩小的单元,每个工作单元不超过一天。之后要完成的工作可以稍⼤大些,以后再对它 们进⾏行分解。

        决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

        在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。

        Sprint计划会议的产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而⾔言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。

        最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

每日Scrum会议

        开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息:

        从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。

        每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队 会在每日Scrum之后⻢马上开会处理他们遇到的任何问题。

        每日Scrum既不是向管理层汇报,也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责⼈人,可以在会议中发⾔言。其他感兴趣的⼈人可以来旁听。在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的⺫⽬目标。

        每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自⽴立。所有Scrum会议都是限定时⻓长的。每日Scrum通 常不超过15分钟。

Sprint评审会议

        Sprint结束时,Scrum团队和相关⼈人员一起评审Sprint的产出。所有Scrum会议都是限定时⻓长 的,Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint 包含2个星期,则Sprint评审会议时⻓长为2个小时)。

        讨论围绕着Sprint中完成的产品增量。由于Sprint的产出会涉及到一些⼈人的“利益”,因此一个明 智的做法是邀请他们参加这个会议,这会很有帮助。这个会议是个⾮非正式的会议,帮助⼤大家 了解我们⺫⽬目前进展到哪⾥里,并一起讨论我们下一步如何推进。每个⼈人都可以在Sprint评审会议 上发表意⻅见。当然,产品负责⼈人会对未来做出最终的决定,并适当地调整产品待办事项列表 (Product Backlog)。

        团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。

        Sprint评审会议向每个⼈人展⽰示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。

Sprint回顾会议

        在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时⻓长的,Sprint回顾会议的 推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint包含2个星期,则 Sprint回顾会议时⻓长为2个小时)。