还有就是今天要聊的是,​CODING 敏捷实战系列课第二讲:Scrum 敏捷项目管理核心要素之 3355

Scrum 是敏捷开发流派中最著名和最落地的一支,全球 70% 以上公司的敏捷转型都是以 Scrum 起步。CODING 特邀敏捷顾问、CST & CTC 认证敏捷教练申健老师将在本课程 《Scrum 敏捷项目管理核心要素之 3355》 中介绍 Scrum 框架的核心要素,帮助大家更好地学习实践 Scrum。

大家好,本次我将为大家详细讲解敏捷的一个流派,叫做 Scrum 敏捷项目管理核心,它起源于 2001 年,当时有 17 位大牛共同讨论了他们的想法和各种软件开发方法,经过交流,他们最后达成了价值观和原则上的共识,共同发布了敏捷软件开发宣言。

而迭代的概念则可以追溯到 1970 年左右,Scrum 也是用迭代式去进行发展,与之相应对的就是瀑布式,所有工作像流水线一样有计划且按部就班的去进行。例如:在软件开发中,先是需求分析、设计,然后进入开发编码、测试,到最后上线,整个过程有前后顺序,不过现实中总会在某个地方出现问题从而造成返工。

有两个日本学者在 1986 年研究了丰田、本田、佳能等高科技公司怎样在一个不确定的情况下去研发一个新产品,他们发现这些公司不再去区分职能部门,而是具有跨职能团队的特点。就像打英式橄榄球,每个人都有各自的专长,但是目标是统一的:要进球赢球。

所以他们在管理智力型研发项目时,没有再用瀑布流式来管理,而是用一种不断迭代的方式。项目的迭代时间不超过四周,在这四周里必须包含所有的必备工作,包括分析、设计、编码、测试,确保快速交出一份相对简单可用的产品,及时获得用户反馈。否则如果等到产品上线再来收取用户反馈,改动成本、项目风险将是非常高的。Scrum 通过事务减少工作任务和工作时间,给予跨部门小团队充分的授权,让他们自己决定如何工作,同时又保持目标一致。

1995 年创立 Scrum 时,也吸收了丰田汽车的精益思想,例如减少浪费、限制流动。Scrum 是一个解决复杂自适应问题的框架,让我们以迭代和增量的方式,在最短时间内交付最大价值的产品。要知道你的人力、物力、财力,包括你的时间,永远是有限的,有一句老话叫“钱要花在刀刃上”,集中优势兵力干一件大事,先做价值最高的那个,分清主要矛盾和次要矛盾。越想全都解决,越解决不了,而 Scrum 就是希望你能做出取舍。例如你的项目上线后,真正被用户使用的部分占比多少,创造了多少价值?通常我们叫二八原则,是指 80% 的价值一定是在 20% 的工作任务里,剩下的都是锦上添花,也有可能是无用功,如果能够减去没有价值的任务,就能让我们获得更充分的时间把质量做的更好。Scrum 并不是必须把所有东西做完,有一句名言叫做“遇到事要尝试反过来想一想,世界每天都在变化,所有事情没有一个尽头”,要学会适应变化、破解和应对复杂性、拥抱变化。

其实在敏捷 Scrum 里,我们更喜欢用这种产品的思维,而非项目,因为按照定义项目是一次性的,也就是说必须先做一个计划,然后按部就班去遵循这个计划的固化思维。你需要分清你的产品到底是什么类型,在业务目标之下,大家可能会有很多的想法,所以有时会缺乏一个真正的决策者,或者决策者的位置特别高,信息流动不畅,导致大家想法不一样,那真正干活的人实际上是无所适从。在 Scrum 里首先要定义一个很重要的角色,叫产品负责人,他要综合各方的想法,进行艰难选择,将所有想法根据投入产出比进行排序,形成一份产品待办列表清单。它可以无限地增长,但并不意味着要把列表里所有东西都做完,而是从业务、运营角度来说时间挺重要,那在这个时间点我们就要集中优势兵力做最重要最有价值的。

“倒排期”是指一开始规划很多任务,把所有任务全都扔进固定时间内,从进度上来说可能磕磕绊绊做完,但是质量就惨不忍睹了。而 Scrum 可以从时间往后倒推,根据可持续的方式来进行动态取舍和排期,先形成一个初始的产品待办列表,团队和 PO、业务干系人可以约定迭代周期,顾名思义它是一个短的时间周期,通常不超过四周。

首先需要开一个 Sprint 计划会,从长长的产品待办列表里面去拉取一批工作,进行分解,形成工作计划。每一个短的时间周期里都有一个小的目标,在小目标之上一定有个大目标,小目标是从大目标里进行分解,之后进行开发、编码、测试等等。而每日还有一个站会活动(Daily Scrum),让团队成员聚在一起分享今天的进展与遇到的问题,这是一个强制沟通的机会。在项目快结束时,我们将工作集成起来,如果是软件则进行集成测试,其他的产品类型则进行相应的产出。然后将完成的产品增量拿到 Sprint 评审会上,邀请产品相关人士并做演示,这时可能会有人提出产品跟预想的不一样,那么赶紧修改,反馈来得越早越好,越早去发现问题,修复的成本越低,根据反馈可以调整出我们到底要做哪些内容。最后来到回顾会,这时不止需要对产品进行调整,还要进行检测调整。

接下来讲讲三大角色,分别为:产品负责人( PO )、开发团队、Scrum Master 敏捷教练。 做产品只能有一个 PO ,负责最大化的投资回报率,并且不断地重新调整优先级和梳理列表。开发团队顾名思义就是干活的,这个团队就像球队一样,它是“跨职能”,并且是“自管理”,被给予很高程度的自治和责任。Scrum Master 敏捷教练,顾名思义就是教练,帮助你具备独立解决问题的能力,所以他并不是一个管理者和管控者,更多的是服务型的领导者,有什么不会的可以教你,但是最终干活的一定是开发团队,例如龙舟队,龙舟队上划船的就是开发团队,掌舵人就是 PO,前面敲锣打鼓把握节奏、鼓舞士气就是 Scrum Master,这三个角色就组成了一个龙舟队。

三个工件分别是指产品待办清单、Sprint 迭代待办清单符合完成定义的产品增量。例如首先产品有个大的目标方向,经过我们的收集信息分解,变成 1-8 号需求,我们需要选取需求到待办清单,团队再分成子任务,之后迭代开始,将产品进行集成,变成可以测试验收上线的产品增量,最后经过反馈,PO 可以再去调整剩余的需求。

在 3355 中,第一个 5 是指五个事件,是 Sprint 本身短时间盒和其他四个会,分别为 Sprint 计划会、每日 Scrum 站会、Sprint 评审会、Sprint 回顾会。在做同一产品多团队时首先要拆团队,维持不超过 9 个人的团队结构,类似 LeSS 结构,强调工作在同一个产品的多个团队,只有 1 个 PO 和 1 份 PB,所有团队的迭代时间盒对齐。在 Sprint 末尾要交出已集成、完成的产品增量。如果是超过 8 个团队,可以考虑 LeSS Huge 结构,增加领域产品负责人(Area Product Owner)角色。第二个 5 是五个价值观:开放、尊重、勇气、专注、承诺。承诺这个词在 Scrum 中表达的是全身心投入去完成 Scrum 团队的目标,而不是说必须按计划完成,两者之间还是有些不同。

Scrum 是一面照妖镜,它的设计“故意不完整”,也故意让项目团队“更难受”,你认为做的产品是完美的,而 Scrum 就是指出产品的不完美,也就是挑错。原来一个月交不出产品,那么就把时间缩短成一周或两周迭代,逼迫团队做出改变。敏捷不是从 0-1 的非黑即白,它是一个持续优化的过程,通过持续交付、持续优化、持续改进、持续提升、持续塑造,最终实现小步快跑,快速迭代。那么今天就分享到这里,谢谢!

点击观看完整录播视频

正文完