关于scrum的一点思考

敏捷的本质，在于拥抱变化。

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

前言

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

简介

提到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去做，团队效率就能飞起了。然而并没有放之四海而皆准的理论或工具，也没有一蹴而就的办法，唯有经历过艰苦的磨合，找到最合适的，才是最好的。