谈到敏捷,大家可能首先想到的是Scrum,它是最常用的敏捷框架之一。
Scrum来源于英式橄榄球比赛中争球环节的启发,团队进行产品开发的协同方式,就像橄榄球队员相互协同以获得对球的控制并球送到目标区。
Scrum可以概括为33355:3个支柱、3个角色、3个工件、5个事件、5个价值观。下面将分别进行介绍。
01
三大支柱
Scrum的三大支柱分别是:透明、检视和适应。
透明:产品开发的过程对所有相关人员都是可见的。只有透明的敏捷环境,才能建立团队间的信任。只有团队成员相信任,才能尽早将项目风险暴露出来,提前制定风险应对措施,规避不必要的误导和浪费。
检视:Scrum工件和实现商定目标的进展必须经常地和勤勉地检视,以便发现潜在的不良差异或问题。为了帮助检视,Scrum以5个事件的形式提供了稳定的节奏。
适应:产品开发过程的任何方面超出可接受的范围或所得产品不可接受,就必须对当下的过程或过程处理的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差。
只有透明的检视才有意义。如果没有透明的敏捷环境,团队对产品开发过程和产品阶段性成果的问题或风险进行隐瞒,那么检视的结果也就不准确,检视就变成形式化,对适应和调整不具备指导意义。
只有检视让适应具备可执行性。通过检视形成的反馈,团队做出的调整才有针对性。通俗来讲,每日站会、冲刺评审会、冲刺回顾会的反馈,在各自的下一阶段进行调整。
没有适应的检视没有任何意义。如果检视发现问题不去进行调整,那么团队就不会有成长和进步,检视就变成了项目流程节点中的一个步骤,大家为了做而做,用于应付审计。
02
五个价值观
Scrum的五个价值观分别是:承诺、勇气、专注、尊重和开放。
承诺:作为自组织团队,愿意在冲刺的开始阶段对目标进行承诺,并在整个冲刺阶段全力以赴。
勇气:敢于对目标做出承诺,履行承诺,面对过程中的问题和挑战,能够迎难而上,有勇气去解决。
专注:全身心投入,专注于冲刺目标的实现。
尊重:团队成员往往具有不同的背景和经验,只有相互尊重和理解,才能构建信任的工作氛围。
开放:保持开发的态度,将项目的过程和阶段性成果公布给相关的每个人看,构建透明的工作环境。
只有将这些价值观渗透到团队里面,才能真正发挥敏捷团队的价值。
03
三个角色
Scrum团队是一个小型团队,通常不超过10人。Scrum团队包括三种角色:
-
产品负责人(Product Owner,简称PO)
-
敏捷教练(Scrum Master,简称SM)
-
开发团队(Development Team)
产品负责人:作为客户代表对接客户(或发起人)收集需求,进行产品待办事项的有效管理。决定产品发布的内容和日期,确保Scrum团队所交付产品的价值最大化。需要向团队提供清晰的产品愿景和目标。
产品负责人对产品待办事项的有效管理包括:
-
制定并明确沟通产品目标
-
创建并清晰沟通产品待办事项
-
为产品待办事项列表中的条目排序
-
确保产品待办事项列表的透明度、可见性且易于理解
产品负责人可以自己做上述工作,也可以委托给其他人。但是,无论由谁来做,产品负责人是这项工作的最终负责人。
敏捷教练:Scrum团队真正的领导者,通过帮助Scrum团队和组织内的每个人了解Scrum 理论和实践来建立Scrum,扫除Scrum实际运行中的障碍,保护团队不受打扰,使Scrum团队可以持续改进、持续创造价值、最大化效率。
敏捷教练以仆人式领导的领导风格服务于团队和组织。
敏捷教练主要为团队提供以下服务:
-
指导团队成员进行自我管理和跨职能协作;
-
帮助团队专注于创建符合Definition of Done的高价值增量;
-
促使移除团队工作进展中的障碍;
-
确保所有Scrum事件在时间盒内都顺利、积极、富有成效地举行及完成。
敏捷教练主要为产品负责人提供以下服务:
-
寻找有效产品目标定义和产品待办事项管理的技巧;
-
为团队提供能够清晰、简洁地了解产品待办事项列表需求的方法;
-
为复杂环境建立基于经验主义的产品规划;
-
当需要或被要求时,引导利益相关者协作。
敏捷教练主要为组织提供以下服务:
-
通过引领、培训和指导他们采用Scrum;
-
通过帮助员工和利益相关者理解并灌输经验主义方法以处理复杂工作;
-
消除利益相关者和团队之间的隔阂。
开发团队:完成迭代开发涉及到的相关人员,包括开发、测试、UI/UED等。
Scrum开发团队具有以下特点:
-
团队成员是T型人才,能够跨职能工作。例如,前端开发人员除精通前端技能外,同时具备后端开发能力,避免因后端开发人员的缺席造成任务的延期和阻塞;
-
自组织管理团队。团队成员具备高度的自我管理能力,专注于目标的实现,主动领取任务,团队成员之间在透明、尊重、开放的环境中进行协作;
-
要求团队成员能够全职投入,保证冲刺节奏的可控。类似DBA的特殊职能可除外,在实际工作中,UI/UED一般也是共用的;
-
团队关系在一个迭代中应该是固定的;
-
经典团队一般5~9人。
Scrum开发团队有以下主要职责:
-
一起为冲刺(Sprint)创建计划,即冲刺待办事项(Sprint Backlog);
-
通过遵循Definition of Done来保证质量;
-
每天根据冲刺目标(Sprint Goal)来调整计划;
-
作为领域专家共担责任。
04
三个工件
Scrum的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度,以便于每个对其进行检视和调整的人拥有同样的基线。
每个工件都包含一项承诺,以确保其提供的信息能够提高用以衡量进展的透明度和关注点:
-
对于产品待办事项(Product Backlog),其承诺是产品目标(Product Goal);
-
对于冲刺待办事项(Sprint Backlog),其承诺是冲刺目标(Sprint Goal);
-
对于增量(Increment),其承诺是“Definition of Done”。
产品待办事项列表是一个不断涌现的、有序的清单,列出了改进产品所需的所有内容。它是Scrum团队开展工作的唯一来源。可以理解为传统开发模式的产品需求列表,包括业务需求、技术需求、技术债务、NFR等。理想情况下,每一个产品待办事项都将产生客户价值。
产品待办事项列表具有以下特点:
-
每个产品待办事项条目以用户故事的形式呈现;
-
产品待办事项的优先级是动态的,每次迭代开始前,产品负责人对优先级排序进行修正。
产品待办事项列表是产品目标的投影,通过定义“做什么”来实现产品目标。
软件开发初期设计的技术架构一般都是比较优雅的,但随着需求的迭代,会让软件架构越来越难以维护,新需求越来越难实现,从而成为一种限制,这就是技术债务。敏捷里面提倡定期或阶段性的将技术债务作为产品待办事项进行解决,使产品越来越好地实现价值。
冲刺待办事项列表是开发团队在冲刺计划会议上,根据本轮的冲刺目标,为本次冲刺选择的产品待办事项。
增量是开发团队将冲刺阶段内完成的交付成果,集成到以往的所有增量成果上,形成新的增量交付。交付的增量必须是可用的。
只有当交付项满足Definition of Done,才能作为增量的一部分。Definition of Done可以理解为是增量需要达到的产品质量标准的描述。
05
五个事件
Scrum的五个事件分别是:冲刺(Sprint)、冲刺计划会(Sprint Planning)、每日站会(Daily Scrum)、冲刺评审会(Sprint Review)和冲刺回顾会(Sprint Retrospective)。
冲刺是Scrum的核心,Scrum中的所有工作都是通过冲刺完成的。Scrum的其他事件也都是在冲刺中发生。可以通过燃尽图、燃起图等方式来预测冲刺的进展。
冲刺完整的流程如下图所示:
冲刺阶段的注意事项:
-
不能做出可能威胁到冲刺目标的任何变更
-
不能降低产品质量
-
根据需要对产品待办事项进行梳理
-
随着了解到更多信息,可能会与产品负责人进行范围的澄清和重新协商
如果冲刺目标已经过时,即冲刺待办事项变得没有价值或价值非常小,可以向产品负责人申请取消冲刺,最终由产品负责人决策。
冲刺计划会是启动冲刺的工作会议。产品负责人、敏捷教练、开发团队共同创建冲刺计划,也可邀请外部人员参加,以提供建议。
冲刺计划会的核心主题包括:
-
本次冲刺的价值。先由产品负责人提出如何在当前冲刺中提高产品的价值和实用性,然后由Scrum团队共同制定冲刺目标,并向利益相关者传达冲刺的价值。冲刺目标必须要在冲刺计划会结束前确定;
-
本次冲刺能完成的事项。开发团队通过和产品负责人讨论,从产品待办事项列表中选择一些条目放到当前的冲刺中,形成冲刺待办事项;
-
确定如何完成本次冲刺的待办事项。针对所选的每个产品待办事项条目,开发团队需要规划必要的工作,以便创建符合Definition of Done的增量。这通常是通过将产品待办项分解为能在一天或更短时间完成的较小条目来实现的。
冲刺计划会是对产品待办事项列表、产品目标、Definition of Done的检视,对冲刺目标和冲刺待办事项的调整。
每日站会是开发团队每天在同一地点、同一时间举办的例会,控制在15分钟以内。每日站会的主要目的是暴露问题和风险,并寻求帮助。
每日站会一般是开发团队围绕在看板前(也可以是电子看板)进行轮流发言,发言的主要内容为:
-
上次站会到现在,完成了哪些任务
-
今天到下次站会之间,将要完成哪些任务
-
有什么问题需要帮助或者有什么可以分享
如果敏捷教练参与每日站会,主要作用是确保会议顺利进行、会议不被干扰、会议控制在15分钟内。
每日站会是对冲刺目标的检视,根据需要调整冲刺待办事项,以调整即将进行的工作。
冲刺评审会是Scrum团队向利益相关者进行工作成果的展示,讨论产品目标的实现情况,并收集意见反馈。
产品负责人作为产品价值的最终负责人,所以,产品负责人必须参与冲刺评审会,并根据预先定义的验收标准接收或拒绝工作成果。
冲刺评审会的主要内容包括但不限于:
-
产品负责人说明哪些产品待办事项已经“完成”,哪些没有“完成”;
-
开发人员讨论冲刺期间哪些工作做得比较好,遇到什么问题以及如何解决的;
-
开发人员展示已完成的工作成果,并回答有关增量的问题,以获得相关方的验收通过;
-
未完成或未验收通过的产品待办事项,重新放回产品待办事项列表,并在下一次冲刺计划会议进行讨论;
-
产品负责人讨论当前的产品待办事项,并根据迄今为止的进展情况,必要时预测可能的里程碑和交付日期;
-
全体参与者共同商讨接下来的行动计划,确保冲刺评审能为接下来的冲刺计划会提供宝贵的意见输入;
-
审视市场变化或产品潜在用途对接下来最有价值的工作方向的影响;
-
审查下一次预期发布产品功能和能力的时间表、预算、潜在能力和市场。
冲刺评审会是对增量、冲刺、产品待办事项、产品目标进展的审视,以调整产品待办事项列表。
冲刺回顾会是对冲刺阶段的流程、协作、工作以及Definition of Done方面的检视,回顾冲刺阶段做得好的地方以及需要改进的地方,讨论下一个冲刺的改进计划,使团队可以持续改进。
冲刺回顾会需要注意:无论发现什么,我们都要理解并且相信每个人在当时的状况下,基于他的能力和资源,已经做了最大的努力。因为没有信任,大家就不能开诚布公地反馈和提出改进意见,失去回顾会议的目的,甚至可能造成团队成员间的相互指责和批评。所以,敏捷教练需要在回顾会前进行准则说明,并在偏离会议宗旨的时候进行纠偏。
Scrum框架中,每个事件都有固定的时间盒:
-
冲刺周期不超过1个月,1~4周
-
冲刺计划会一般在2~8小时,一般1个月的冲刺耗时8小时
-
每日站会不超过15分钟
-
冲刺评审会一般控制在2~4小时
-
冲刺回顾会一般控制在1~3小时
结语
围绕Scrum的33355框架进行了敏捷实现的介绍,都是敏捷实践中必不可少的工作。
但在实际工作中,敏捷实践经常受限于企业的组织文化、KPI等因素的影响,遇到各种障碍,使得敏捷实践只有其形,没有带来真正的价值和效率的提升。需要组织从上往下去变革,将敏捷的理念和价值观深入进去。同时,也需要参与敏捷实践的所有成员(特别是敏捷教练)去推动组织的变革。
更多的项目管理知识,可关注微信公众号:ITPM