《Scrum精髓—敏捷转型指南》读后感

Posted 2022-11-24 Ethan_LiYan

       首先很庆幸，能在适合的时间，遇到了这样一本适合的书。之所以这样说，是因为在遇到这本书前，我还是一名单纯的程序员，“增删改查”的业务代码，占据了我大多数的时间，本就繁杂的工作，还被一个叫“敏捷”的东西，弄的一团糟。不知道从什么时候起，似乎搞一个口水话连篇的“早会”，弄一块不伦不类的“白板”，就开始全世界宣称，“我们‘敏捷’了”。

       老板们自然开心的不亦乐乎，因为从此以后，就可以以“敏捷”之名，塞给你更多的工作量，因为“敏捷”不是要“快”嘛。需求也可以理直气壮的随意改变，因为“敏捷”不是鼓励“变更”嘛。甚至代码都不用测试，就想直接上线，因为“敏捷”不是要“快速交付”嘛。

天生叛逆的我，自然不会相信，难道这就是大行其道的“敏捷”吗？但是打铁还须自身硬，于是，我开始看大量的敏捷相关的专业书籍，并且一边翻书，一边实践，在摸索中前行。这其中对我影响最深，帮助最多，最具有启蒙意义的，当属《Scrum精髓—敏捷转型指南》一书。

理论概念部分，书中已经讲的非常好了，通俗易懂，这个是基础，想要做好敏捷，这些都是基本功，我就不再赘述了。下面，我斗胆以“过来人”的角度，谈一谈再次翻看本书，那些依旧能触动我的观点：

1.“全面拥抱Scrum并不意味着组织在实践Scrum的时候必须得照着某个一刀切、放之四海皆准的公式生搬硬套（前言部分）”

多年后，或许你已经参见过或听过N多人分享其他公司的敏捷转型成功的案例，再或者你已经掌握了N多打着敏捷旗号的架构或模型，但是这些都不重要，切记，这些都不是你的，凡是告诉你可以按部就班去做，就可以成功的，都是骗子。都知道“世界上没有两片相同的叶子”，同样，世界上也没有处境完全相同的团队，生搬硬套意味着要“削足适履”，最后一定是哀声载道，以失败告终。所以，找到适合自己团队的才是最重要的，开始在Scrum的大框架下，包容甚至吸纳团队内已适应的方法，即使在你看来，有些不是好的习惯，但是，请相信，在时间的推演过程中，那些“顽疾”会在Scrum框架的一次次“检视与调整”的循环中，被识别出来，并最终被“改变”。

2.“每日例会不是用来解决问题的……每日例会也不是传统意义上的状态会……每日例会主要是一个检视、同步、适应性定制每日计划的活动（P30）”

看过太多喋喋不休的早会了，充满了口水话，也不注重消息的传递性，自顾自说，期间还有人交头接耳开小会，或是某几个人就一个问题，讨论来讨论去，显得自己很有事做，其他人站的生不如死，也听不懂那几个在胡说八道些什么。或是一群人围着主管/产品，汇报各自进度，或是对着jira电子屏更新状态。这样的早会，意义何在，就是为了一大早上给大家添堵吗？如此，你怎么能不叫大家有抵触情绪呢？

想开好早会一定要有看板，不然对着空气瞎说个啥，而且我个人非常鼓励物理看板，一是，物理看板多了，可以形成“信息辐射中心”，或者“作战空间”。二是，物理看板很提升士气，改变风水格局，营造一种攻坚克难的气势。三是，早会移动物理看板上的任务卡，可以产生信息拉动的效果，且很有仪式感。再者，如果团队有人喜欢开小会，可以增加发言授权物，可以是任何东西，只有拿到授权物的人才能发言，且严格控制时间盒，产品可以旁听，但不要打断和质问进度，主管能不参加最好，把自主权交给团队。早会只是为了同步信息，暴露风险，检视计划，有任何问题，散会后，相关人单独讨论，不要在早会浪费所有人时间喋喋不休。

3.“在面对不确定性时，不要一厢情愿地预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息给出明智、合理的最终解决方案(P48)假设事先无法制定完美计划（P284）”

传统的项目管理方式，都是基于计划驱动，有计划，必然要预测，想要计划准确，必须要精准预测，想要精准预测，就要花费很长时间去胡思乱想。结果呢？在知识量最匮乏的阶段，拍脑门造了一堆低质需求，都是一厢情愿的“你以为”。而且还很容易过度设计，花了很大成本实现一堆“不痛不痒”的需求。所以我们要承认，我们没办法在认知有限的情况下，作出完美的计划，要学会利用短周期的迭代，快速试错，不断获取反馈，以增加知识，来调整下一次迭代的交付。

4.“关注闲置工作，而非闲置人员（P59）”

这个理念是最难被上层接受的，因为传统的项目管理理念，是把人当作资源来看的，所以，资源出现闲置，意味着浪费，真的是这样吗？

第一，每个人的关注的点是有重心的，当你把所有的精力陷入关注人，就变成了一种监控，而人又不直接产生价值，能直接产生价值，决定项目成败的是那些还没有被完成的闲置工作，所以，请把重心放回到剩余的工作上，而不是绞尽脑汁让人100%连轴转。

第二，我们要打造的是自组织团队，既然如此，请选择相信团队，基于迭代前的承诺，我们彼此遵守，过程中不打扰。我们要允许在开始阶段出现各种反常的状态，但是，在经历了几轮迭代的磨合后，一切不好的现象都会被潜移默化的改变掉。

5.“在使用Scrum时，不是用既定计划的执行情况衡量进度，也不是看某个特定周期或开发阶段的工作有多大的进展，而是用已交付且验证过的结果来衡量（P63）”

这是一种增量开发的思想，也符合敏捷的原则之一，“可工作的软件是衡量进度的首要标准”。所以，对比传统项目管理中的汇报，所谓的“完成80%”意味着什么呢？意味着剩下的20%工作要花20%时间完成吗？几乎没什么可能性。意味着已经完成的80%可交付吗？也是不可能的。所以，在传统的衡量进度的理念里，所谓的完成百分之多少，就如同信口雌黄一样，没任何说服力。

但是，在敏捷项目里，如果说完成80%，那一定是，完成了已符合完工定义（DoD）且优先级最高的，可交付使用的那80%。

6.“质量不是测试团队在最后阶段“测”出来的，而是由跨职能的scrum团队负责并持续内建于每个冲刺中。(P66)”

质量一定不是测试同学测出来的，而且测试同学也不是质量警察的角色，而且整个团队，大家一起要努力做好的事情。自动化测试一定是敏捷中不可缺少的部分，同时结合TDD（测试驱动开发），不断识别代码中的坏味道，然后进行反复重构，无论对程序员本身基本功的提升，还是对项目整体质量，都是有利无害的，强烈推荐大家试行。

7.“在Scrum中，我们的目标是消除可有可无的繁文缛节（P66）”

无聊的邮件、没完没了的日报，周报、各种汇报糟心的PPT、有一点点小事情，就磨磨叽叽的开会、即使做的很近，也不会过去面对面沟通一下，而是在各种类似微信群里，喋喋不休的唠叨…….太多的形式主义，太多的没用的繁文缛节，占据我们大量的开发时间。在敏捷转型时，我们一定要在前期的敏捷思维导入中告诉大家，敏捷不玩虚的，一切以实用为主，短平快的高效解决问题才是王道。准备好随处可以见的白板及便利贴，相互沟通时，走过去，边画边讲的效果，一定好过你干巴巴的文字聊天。

8.“冲刺是在时间盒内完成的，持续时间短并且长度一致，冲刺开始后就不能再改变目标，必须达到团队的完成定义中要求的最终状态。（P71）”

“敏捷就不管进度了吗”，错！我们是有限定的时间盒的，一般现在大多能做到1～2周一个迭代。且这个时间盒的长度一般是固定的，因为这样可以给团队一个节奏感，类似健康的心跳，同时有一种屡战屡胜的成就感，同时由于时间短，错误有限，也有利于我们快速获取反馈，即使调整方向。

“敏捷就可以随便变更吗”，错！我们也是有规则的，一般一个迭代开始后，那个这个迭代所做的内容，是不会变更的，如果变，请放在下一个迭代中，毕竟我们的迭代周期很短，但是如果真的非常紧急，那么，没办法，我们要切掉某个独立的功能点，把这个紧急需求放进去，这个时候，就考验产品的拆分能力了，MVP能做到多小，很见产品同学的功夫。

9.“产品列表是产品开发期间一直存在的‘活文档’（P96）”

我很喜欢“活文档”这个概念，我觉得，在敏捷里，不仅文档是“活的”，计划是“活的”，“人”更是活的，而不是生硬的“资源”。当一切都是“活”的，让就可以适应一切变化，像活水一样，“兵无常势，水无常形”。所以，我们要经常对不仅是产品列表，sprint列表等等的一切，定期review，不断的检视与调整，这才是不至于把自己变成一滩绝望的死水，发臭发霉。

10.“传统的需求收集方法是问用户，了解他们想要什么。这种方法我从来没有用爽过。以我的经验，让用户当评论家远比当作家好(P112)”

这种现象就太普遍了，你问业务/用户，你想什么，他们通常会用很多非常空洞且飘渺的词汇来描述他们的需求，或者说了一堆，最后干脆来一句，其实我也不是很知道。所以，与其没完没了的问他们想要什么，期待把所有情况都考虑清楚，再去动身开发，恐怕，一切都晚了。一是，用户描述不清楚；二是，过程中用户的想法会变。所以，倒不如我们通过频繁的交付可工作的软件，来邀请他们使用和感受，请他们当一个评论家，然后通过不断的收集他们的反馈，来辅助业务/用户发现他们的真实需求，才是王道。

11.“估算不是承诺（P145）”

有太多的开发人员，都很忌讳做估算，因为一旦他们给出了一个时间的概念，即使再三强调，且用了很多“大概”“可能”“差不多”的概念，但是依旧会当成开发人员的承诺，在后期的排期中进行约束和限制。

造成这个结果的直接原因，就是管理者没脑子，没有一点逻辑性。估算本身是对一种不确性的进行假设，这没错吧？你让大家对“不确定性”和“假设”作出确定的承诺，不是脑子坏掉了吗？

也会有人问，那估算还有什么意义？当然有意义，估算是以现有的认知，对未来的工作以何种逻辑关系进行开展的一种假设。可以推算产品开发的持续时间，同时在估算PBI的时候，还能激发人们思考PBI的细节，让所有假设都暴漏出来，这种热议很有价值。

12.“速率是一种计划工具，也可以作为团队诊断指标。它不应该作为一种绩效指标来判断团队的生产率。（P160）”

速率是衡量产出的，而不是成果。所以完成一个8个故事点，不一定比完成3个故事点的人，交付了更多的商业价值！可以纵向比较，即诊断一个团队每次迭代的交付状态正常与否，但是不要跨团队比较，没有任何意义！

13.“一个普遍误区，测试属于额外的开销，减少测试，我们就可以提高速率。现实是减少测试既增加债务又减缓速率。（P171）”

真的听人说过，有些创业公司为了所谓的“提高速率”，竟然取消了测试环境，短期内，确实感觉速度变快了，但是随之而来的，就是更多的线上问题不断的爆发，而且由于缺乏测试环节，人们的质量意识随之降低，造成大量的技术债堆积，所以，很快，修复问题的时间越来越长，留给开发新需求的时间越来越少，且技术债过重，后期技术做一个很小的新需求，也很容易“牵一发动全身”，大大的拖慢了项目的整体速率。

14.“开发团队（以及整个Scrum团队）的成员需要具备三个火枪手的态度——“人人为我，我为人人”。……团队成员共同承担工作的责任，成败是整个团队的事情。（P236）”

很多团队都没有“团队”的概念，大家竖井很深，各自负责一个小业务模块，自己做的又烦燥，别人又无法插手，各自为政，不是自己的模块，不闻不问不管。这样既没有集体感，又没有团队氛围，最后都是得过且过的开发，最后伺机跑路。由于业务竖井严重，对个人依赖度又高，所以核心人员跑路，其他人又难以短期内接手，对项目的损失又很大。

所以要想变革，首要任务就是要打破各种竖井，可以通过轮岗，结对编程等方式，减少项目对单个人的依赖。在思想上，从强调“我”变成为“我们”，摈弃传统的考核单一个人绩效的方式，引入团队绩效的概念，大家一起为项目奋斗，不分你我，关起门来，大家都是一家人，一荣俱荣，一损俱损。

15.“冲刺回顾：人们在表达意见时必须要有安全感，用不着担心受罚（P429）”

回顾会是团队能短暂驻足思考的重要环节，同时也是Scrum框架提供的有助于持续改进的重要因素。但是很多团队在开回顾会时，总难获得理想的效果。原因之一，就是没有营造一个开放且安全的氛围。不妨引入一些“世界咖啡屋”的方式，采用各种引导技巧，顺带买点零食，领导如非必须可选择不参加，交给团队自己完成。同时在会议的开始，制定基本规则，我们“对事不对人”，不要采用责备的口气来阐述问题，多用“我们”来代替“有的人”等。

16.“有一种无效的，为团队建立的“改进计划”与每个冲刺完成的工作不相干……为了确保落实改进计划，不要把二者分开，一定要整合。（P439）”

回顾会被大家视为形式主义的另一个原因就是，提了一堆问题，然后搞了一个所谓的“改进计划”，然后就没有下文了。最后发现，每次开会都是老生常态，翻来覆去都是那些问题，也解决不了，所以，大家本能的觉得回顾会没有任何用处。面对这种情况，我们不妨想一想，Scrum的哪个工件跟团队的任务密切相关？没错，是sprint冲刺列表。这是开发团队在每个迭代中真真切切要完成的工作，那么我们不妨把每次回顾中暴露的问题，能在下一个迭代中改进的，我们把它变成sprint冲刺列表中的一个条目，将两者合二为一，这样，是不是能促使改进项在下一个迭代中被移动呢。

17.“敏捷或Scrum你没有任何终极状态。变得更精通Scrum或更敏捷是一个持续的、永无止境的过程，追求的是日益精进。（P444）”

敏捷是不可能一蹴而就的，当然，也不可能有终止的时候。不会说我们拿出一年甚至两年的时间做敏捷转型，然后就成功了，就再也不用管了。这是不可能的。因为敏捷本身就不是一个静态的框架，里面充斥着大量的“检视与调整”的循环，在每次检视中识别出改进项，并在下一次迭代中调整，自产自销，更像是一台“永动机”，生生不息的运作，以趋于完美。

---

 

写在最后：文章写的比较匆忙，可能会有错别字，没时间校正。同时文中的观点，仅代表我个人的一些思考，若有不当之处，欢迎随时微信交流。最后良心的向大家推荐一下BoB姜信宝老师翻译的这本书《Scrum精髓—敏捷转型指南》，无论你是新手，还是老鸟，都一定会有一些不一样的收获！、