littlemujiang.github.io

View the Project on GitHub

关于scrum的一点思考

“所谓敏捷,不过是一次只做一件事,一次就把事情做对. “

前言

7月20、21两天,参加了捷行咨询为期2天的scrum master认证的培训。总结下自己的收获及感悟。


scrum

提到scrum,就不得不提到敏捷,或者Agile。敏捷是一种开发模式,或者思想,相比于瀑布式的开发模式,它能更快的响应市场或需求的变化,能更快的交付产品,也就是更敏捷。因为软件开发往往是团队协作,而要大家一起玩,做到敏捷式的开发,当然是都要遵循一些原则和约定,于是就有了4大敏捷宣言和12条敏捷原则。

有了这些当然也是不够的,就像有了公认的道德体系,那就不会有人做坏事了吗?当然不是,所以法律才有其存在的意。同样道理,于是就有了scrum,scrum可以看作是一个框架,一种方法论,用来指导人们如何有效地把Agile的思想进行落地。

scrum框架主要从角色、文档、活动这些方面来规范和指导团队行为。角色有PO、Scrum Master、Dev Team,文档有产品backlog、迭代backlog、产品增量,活动有产品backlog细化会、迭代规划会、每日站会、迭代总结会、回顾会。这些东西都是围绕着迭代的过程来进行的,当然其中也穿插着用户故事、验收标准(dod)、燃尽图等等一些概念,用来辅助团队更好的执行或交付。scrum的东西并不多,看似简单,但通过和其他学员的沟通,大家都在实践中遇到了不同的问题,当然自己所在团队的问题也不少。作为一名刚接触scrum的小白,虽然解决不了这些问题,但好歹学过管理,考过了PMP,还是有些个人的思考。

感悟

scrum与清单

最令我印象深刻的,或者刷新认知的就是,scrum中对清单的使用。清单是个很好的东西,《清单革命》一书中指出,清单是人类大脑的外延,能有效避免遗漏和减少犯错。scrum中的核心文档就是几类清单,而且是渐进明细的,产品backlog相当于产品的road map及feature list,是功能模块清单,迭代backlog是将功能模块细分后的用户故事清单。团队间能共享且不断维护这些清单,不仅能避免遗漏重要的事项,而且能够让大家都很清楚当前团队在做什么,增加了透明化程度。而且,当人把清单上的待办一项项勾掉的时候,是很能带来成就感的(产生成就感的前提当然是得觉得自己own这个清单)。

scrum与PMP

一提到PMP,给人的感觉就是瀑布式、框架太重、不灵活等等这些概念。其实任何完善的工具都是大而全的,因为考虑到要应对各种场景去解决不同的问题。但这并不意味着我们解决实际问题就要拿着这全套的工具。个人感觉,scrum其实是抽取了PMP中的部分工具,然后重新组合而形成的一套新工具。举个也许不太恰当的例子,就像从医院的医疗器械中选取一部分,做成日常急救包一样。

scrum中的PO其实就类似于产品经理的角色,而Scrum Master就是项目经理,而迭代过程中的文档和活动,在PMP中也都有对应。只是,scrum和PMP的关注点不太一样,scrum更关注如何能让小型团队快速和高质量的交付,也因此,scrum中几乎没有提到成本、资源、沟通的管理及控制。其实,使用任何工具,最最关键的是要领会到其核心思想,也就是它这样设计到底是为了解决什么样的问题。

再举个例子,在剪指甲刀被发明之前,大家都用剪刀去修剪指甲,有的人剪的很圆润,而有的人每次都剪出血,后来剪指甲刀出现了,剪的好的那些人还是能用剪刀剪,并且跟用指甲刀一样快速,其实就是由于这些人已经灵活地掌握了剪刀的使用诀窍。

scrum就一定敏捷吗

敏捷虽然不是银弹,但确实是个很好的思想或理念。其实几乎所有的团队虽然没实行scrum,却都已经拥抱了Agile。现在恐怕已经没有团队,把200个功能规划半年的时间,然后齐头并进去开发了吧。

拿我之前在联想的团队来说,虽然没用scrum ,没有迭代的概念,但我个人认为也做到了敏捷。我们会定期规划下半个月或者一个月或者2个月的要开发的功能,要调研的技术和要细化的UI,功能优先级是和老板还有客户一起讨论并确定的,具体的开发方案就由架构师、前后端开发、测试相关同事一起讨论,然后分配下人员和确定时间点,再整理到一个思维导图上,就开始做了。 我们也会每天下午开站会,由一个人来更新这一阶段各任务的进度,与scrum不太一样的是,我们的站会主要是主持人来问:你负责的这块任务今天进度如何,有什么问题。关于这一点,和scrum规范的每日站会相比,感觉各有优劣,主持人去问这种方式,团队成员发言少,会丢失scrum中的那种成员的承诺感,但是会让大家围着目标去听,容易有整体的概念,能够清楚的知道,我们离目标又近了多少,哪部分是落后的,而且便于控制时间。而各说各的,几乎都是在说自己一天做了什么,容易陷入琐碎的细节,很有可能跟迭代目标并没有什么关系,也有可能说了很多但对目标的推进只有很少,让大家误以为做了很多,也许一个有全局观的scrum master能够避免此类问题。

以上,就我个人的实践来说,抓住Agile核心的自由模式,比严格执行规范却流于形式的scrum要高效,这也与老师在开课一开始就提到的,敏捷团队应该是自组织的,这一理念相吻合,毕竟存在即合理,从混沌中演化而来的才是最合适的。而我理解的Agile的核心,无非是以下几点:共同定下的目标,紧盯目标的执行,轻松积极的氛围,不断提升的个人能力。没有这些,看板、工具用再好都发挥不出作用。


最后,我觉得很多团队之所以会在scrum的实践中遇到各种各样的问题,总觉得 不是这不合适就是那别扭,极有可能的原因是,太过在意和追求scrum规定的那些细节和流程了,总觉得只要按这些个12345去做,团队效率就能飞起了。然而并没有放之四海而皆准的理论或工具,也没有一蹴而就的办法,唯有经历过艰苦的磨合,找到最合适的,才是最好的。

—— mujiang 记于 2018.07.29