0°

Scrum敏捷真的有捷径哦

尝试过Scrum敏捷的人都很清楚,这东西看着简单,但是实施起来还真的不简单。


而小婧也不止一次的说过,很多团队只是披着皮的伪敏捷。

披着什么皮呢?至少找个理由不写文档了吧。


我个人算是参与过真正的敏捷过程的,那感觉真的很美好。


之前我也在自己的号里分享过一个敏捷Scrum的系列。

作为BA的Scrum Master,我把自己的经验和心得记录了下来给大家做分享。


这两天看了一本一个Scrum Master写的书,觉得其中讲述的东西非常实在,迫不及待的想和大家做分享。

如果你们已经开始实施敏捷,但是你却对其效果抱有疑虑;如果你觉得你们现在实施的敏捷流于形式;如果你对敏捷不是那么了解,请继续看。


作者介绍了30条敏捷Scrum捷径,其实都是一些经验的总结。

第一部分:起步


1一句话推销Scrum

到底要不要实施Scrum,首先需要说服的是项目发起人,然后是团队成员。需要向他们推销Scrum“固定的灵活”这一理念,并让其同意开展并参与试点项目。


2脆弱的敏捷

必须要说明的是,敏捷是一个框架,类似于打麻将的规则一样。要么全盘接受,要么就不接受。没有只接受或者采取一部分的说法。

明确这个也就明确了我们看到的参与的很多团队,其实并不能被称为是敏捷。


3有创意的舒适

敏捷很提倡团队,所以需要想办法提升团队的士气。比如想办法改善办公环境,让一个scrum团队的人坐在一起,最好还有一个临时的讨论桌。另外,给团队起个名字,这样可以帮助团队建立身份认同感和使命感。记得我们以前公司里面有Pandora团队,OX团队,我们团队叫做Waka(成立那年刚好是世界杯,满世界都是夏奇拉的WakaWaka)。


第二部分:态度和能力


4技艺高超的Scrum Master

不要把Scrum Master当做传统意义上的领导,我是比较提倡团队成员自愿的情况下,轮流做Scrum Master。这个角色完全是一个仆人式服务式的角色。作为一个没有权利的领导,你必须完全依靠你的公平、尽责、情商去管理这个团队。


5态度高于能力

Scrum团队的成员肯定各有各的个性,但是都必须认同和符合这样的Scrum价值观:开放、勇气、专注、尊重、承诺。


6选择团队阵容

建议建立Scrum的团队规约,有点类似于我们上学的时候学校制定的“文明公约”一样。主要是为了让团队一开始就达成共识,特别是涉及到多种族多语种一起工作的情况,Scrum不提倡小团队。而针对人员的构成,作者的建议是:3个dev,1个QA,0.5个精深专家。当然他的这个建议是基于自动化测试的基础上的。而我之前在我的经验中给出的建议是:2:1:1的结构。

而Scrum Master是可以同时服务于多个团队的。


第三部分:规划和保护


7搭建Scrum舞台

为了使得Scrum能顺利进行,Scrum Master需要确保团队稳定,“在一起”的办公环境,支持可持续开发,灌输Scrum价值观。


8制定Sprint计划并全力贯彻执行

针对这个部分我在之前的PlanMeeting文中有做详细的说明,作者和我的观感基本一致:准备Backlog的过程是一个迭代的过程。不需要像之前瀑布开发的模式,将需求规格全部都准备妥当再转阶段到下一个部分“设计”。只需要将前面两个Sprint的Backlog准备妥当即可。


9受累于障碍

首先我们需要区别障碍与阻碍。障碍是指这件事情影响到整个团队的Sprint进展了,比如核心人员被抽调。而阻碍是指某一个具体任务在执行时受阻,但是不影响整个Sprint。

在实际的Sprint过程中,是会遇到形形色色的障碍,作为ScrumMaster需要领导团队去及时确认障碍(站会)、进行诊断、消灭、告知团队、并从中总结(回顾会)。


第四部分:需求的细化


10结构化故事

曾经看过有一本书专门介绍怎么写user story。我只能说,这东西真的是技术活,并不像表面上看得那么简单。而我们的故事一个非常重点的划分标准是:对用户来说有价值。另外我觉得有个很困难的工作,就是:划分的粒度。


11制定完成标准

这里说的是完成标准而不是接收标准。有什么区别?

完成标准是针对整个团队的所有story的,比如:符合接收标准、国际化工作完成、操作手册准备完成等。

接收标准是针对单独的每个Story的验收要求,通过则可以标志为这个可以接收了。


12渐进启示

我们不能指望一次就把事情做完美了,有这样或那样的原因需要让我们去对产出进行调整。在调整的时候要注意需求镀金和范围蔓延的问题。并且对所有的信息都需要记录下来。

所以,看吧,敏捷并不是不需要文档,只是不需要不必要的文档而已。


第五部分:估算


这个我就不详细说了,在之前的PlanMeeting的文中有详细说明。使用比较的方法进行story的估算,可以用扑克牌的方式。

13关于估算

14规划扑克

15转向相对估算

第六部分:质量


16见鬼!Scrum代码错误

首先我们要明确什么是问题,什么是代码错误。

代码错误是指PO已经接收了Story,这个Story已经Done了,结果发现有代码错误。这个时候,不要reopen,而是另外拿一个Story去进行记录评估。

而问题是发生在Story接收前。


17我们仍然青睐测试人员

我们虽然提倡使用自动化测试,但是测试人员的角色会同时转向一些设计、探索测试、咨询方面的工作,而不是常规功能性测试。


18自动化王国

敏捷Scrum非常提倡自动化测试,没有持续集成和自动化测试就是伪敏捷(有专家如此说)。


第七部分:监控和指标


19有意义的指标

书中介绍了四个图来衡量敏捷Scrum的执行情况:

  • Sprint燃尽图(我之前的文里做过详细说明)

  • 增强型交付燃尽图(将Sprint燃尽图的横坐标由天换成SprintN)

  • Sprint干扰(每个Sprint花在非Sprint上的任务时间)

  • 补救关注点(并不是做的越多越快越好,我们需要衡量每个Sprint发生的问题占了我们总点数的多少)


20出色的站会

21优化任务板


这两个我之前的文也有,就不详细说明了。

第八部分:回顾会、审核会和风险


这个部分我在之前的文也有详细说明,就不一一说明了。

22Sprint Demo会议的事项

23不可或缺的回顾会

24勇担风险,敢于犯错

第九部分:经理怎么管理


25看法就是现实

虽然说Scrum敏捷是自下而上的管理,但是任何流程模式的变革都需要得到领导的支持。所以,在整个项目过程中,作为Scrum Master必须保持和项目发起人(领导)的信息沟通,并且尽量让其参与(参观)其中。


26我的上帝我的神

虽然我不是很明白这个捷径的标题的意思,但是作者提出可以建立类似PMO的首席Scrum Master以实现在策略层面的运作。这点倒是可以作为有很多Scrum团队的公司的参考。


27矩阵中的经历“变形记”

毫无疑问的是,敏捷Scrum准备“消灭”项目经理,而职能经理的主要职责也会转变为“导师、师傅”的角色。


第十部分:更大的经验和教训


28Scrum推广的推算

当试点项目进行了一段时间后,有什么评判的标准:决定是否应该继续推广Scrum?

  • 有这样几个指标供大家作为参考:

  • 团队在30天内的产出

  • 目标的明确性,即团队计划交付什么内容

  • 团队内部的协作与合作

  • 团队在30天内产生的商业价值

  • 被浪费的时间,返工或者不需要的工作,没有有效产出的Sprint

  • 团队产出的总体质量和“确定性”


29有所追求

其实Scrum团队如果能够良性运行,正如我在开篇的时候提到的,是一种非常美好的体验。不论对项目发起人、产品经理、还是团队成员。

Scrum是很反对殉道式的持续加班,因为这个与Scrum的价值不符。要知道Scrum提倡的是:多少资源多少时间就做多少事情,即由人和时间决定范围。而我们通常的做法是:由时间和范围决定人天,但是人就那么几个人,怎么办?加班呗。



30终极捷径

在整个敏捷Scrum的实施准备和过程中,必须要时常的自我审视、大胆尝试,千万不要固步自封。在Scrum的框架中,所有符合Scrum价值观的尝试都值得去试。


写在最后


作者提出的是他从业多年的经验。我一直觉得敏捷在国内团队很难落地的主要原因,是科普做的不够。就是很多人只是知道一个表象,就去干了,而并不了解敏捷的框架到底是什么,摊子铺的又太大,自己了解的有限,导致最后实施成四不像。当然,文化因素也是一个非常重要的原因。

我会建议,如果你真的有心实施敏捷,最好找个专家从一个试点项目开始,一步一步循序渐进的实施。




小婧是一名行走在产品路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

Scrum敏捷真的有捷径哦






「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论