阅读此书纯属偶然，亦为缘分。彼时我刚刚进入一家大型传统能源企业IT部门做敏捷咨询工作，苦苦思索如何在这样的大型企业团队开展好敏捷实践，它就出现了，犹如黑夜里的一盏明灯，给我指明了方向。阅读本书起初是为其名字所吸引，对Craig Larman为何方神圣毫无概念。当注意到译者为我司同事并看过了译者序之后，更加确信此书为我当时之需。因此，我想结合我的咨询工作谈谈对本书内容的理解。
\闲话少说，阅读完本书之后总体感觉为，此书为传统大型IT部门多团队实施敏捷之得力帮手：首先，它列出了复杂问题的思考工具，让我既见树木又见森林，透过现象看本质，深刻理解实践背后的原则与价值观；其次，它给出了大型组织实施敏捷的具体方式及尝试方法，尤其是如何组织团队、提高团队适应能力、培养学习型团队以及各个角色如何做好职责转变等；其三，它描述了传统企业常见的团队组织方式并分析其利弊，犹如一面镜子映射到客户部门，让一些表面问题突显其深层原因，从而帮助我在给出建议时既能考虑如何治标，又能知道长期发展如何治本；最后，本书打开了精益与敏捷开发知识之门，各章基本都有丰富的推荐资源，少则两三本，多则十几本，如果你想成为这个领域的专家，此乃最便捷的入口。
\本书分为三个部分，首先来看看第一部分，思考工具。正如作者所说，这部分内容是大规模Scrum和敏捷开发取得成功的基石。个人认为第一部分的五章，每章都是一本书的内容，作者通过自己的语言将这些具有深厚理论基础的工具简明扼要、纲举目张地描述出来， 详细总结如下：
\第2章——系统思考：一种既见树木又见森林地分析问题的工具。作者提到：
\大规模地实施Scrum、精益思想和敏捷原则并不是孤立于开发团队存在的，它受到产品管理、预算、测试、发布、管理方法和人力资源政策的制约。因此，在大规模实施敏捷方法的过程中，与同事们在即将改变的大环境中一起讨论心智模型、因果关系、反馈回路、管理机制（或管理幻觉）是非常有用的。
\因此，在分析一个问题的时候要找到与之关联的其他因素，分析根因、全盘着眼、系统思考才能给出合理的建议。例如，我在客户现场遇到一个问题，某团队在回顾会议中很多人提到团队无法按时完成Sprint承诺的任务，基本每个Sprint都如此。后来我们组织该团队主要成员，从三个不同视角——产品负责人、项目经理、团队，画出了与此问题相关的系统循环图，最后发现这根本不是一个问题，而是一种合理的表象。其真正原因在于，在当前Scrum组织中，产品负责人、团队以及项目经理之间还没有明确各自角色应该承担的任务，比如产品负责人应该为每个Sprint列出需求列表并排定优先级，同时相信团队的选择完成哪些需求；项目经历负责协调资源帮助团队解决问题，完成承诺；团队专心于完成产品事项。当整个系统中所有角色的权利与义务都得到履行时，团队完成每个Sprint承诺的任务也就水到渠成。而现在完不成恰恰反应了各个角色对于Scrum的价值观理解不足，没有扮演好对应的角色。比如我们观察到，多路需求来源，优先级混乱，Sprint中期插入的临时任务很多导致团队不能专心工作等等。因此我们要解决的真正问题就显现出来了，那就是从澄清各个角色应该承担的职责入手，让各自扮演好自身的角色！
\关于系统思考有很多经典书籍，个人觉得丹尼斯·舍伍德 的《系统思考：学习型组织必备读本》是很好的入门读本。
\第3章——精益思想：本章详述了精益思想、精益目标、精益基础、14项基本原则以及精益产品开发等等。因为敏捷的价值观和原则很大部分受到精益思想的启发，比如敏捷实践中的故事墙就受到精益中看板的启发；持续集成受到“停工与修复”思想影响；回顾会议也是精益思想支柱之一——持续改善——的体现。这些知识给我的咨询工作提供了理论支持，帮助我清晰透彻地向项目经理、产品负责人、团队成员解释Scrum每个实践背后的深层次价值观，做到知其然且知其所以然；此外，本章对于人们容易误解的部分，比如精益思想的两大支柱等，也做了详细解释。在第3.3节，作者用一幅图浓缩了精益思想的精华，即图3-1精益思想屋：
\如果你想对精益思想有个概览和全局把握，那就仔细研究一下这幅图吧。
若要对精益思想进行更深入的理解，可以参考阅读其他书籍。其中， 詹姆斯 P.沃麦克（James P.Womack） / （英）丹尼尔 T.琼斯（Daniel T.Jones）的《精益思想》一书可谓介绍精益思想的经典书籍。该书书已有10余年的历史，销售数十万册。如果你觉得这本书还不够，可以参考作者在本章最后一节——推荐资源中列出的九本书。
\第4章——排队论：排队论作为一种用来研究事物如何排队通过系统的分析工具，反映在用精益“均衡”原则减少可变性，更重要的则是通过注重小批量和短周期实现流动，Scrum支持排队论的管理含义。个人觉得本章十分具有指导意义的是第4.7节——在Scrum中使用排队管理。作者分析了如何通过减少可变性以及限制排队规模来做好排队管理，提到了一些实践，诸如时间盒、清晰精细、规模相似的用户故事、稳定的特性团队等等。同时指出了常见项目管理中不太好的做法。我在客户现场的确观察到了，比如通过增加员工利用率或多任务处理，或增加更多的开发人员来减少过排队现象。这些做法在短期内能看到一些效果，但是给员工带来的自由度少、压力大，同时费用高昂，可持续性和可扩展性差。
\第5章——错误的两分法：本章主要解释一些在敏捷开发中常见的容易被大家误解的问题。5.4节——误解，澄清了很多常见的对敏捷、Scrum的误解，比如“敏捷不需要文档”、“敏捷就是迭代”等，让我们正确认识敏捷价值观、敏捷实践。我在阅读完本节之后，对于客户现场常见的问题都有了更加清晰的答案。
\第6章——掌握敏捷精髓：本章内容如题，是深入学习敏捷必须掌握的部分。我始终认为，敏捷的价值观就是敏捷实践的内功心法，只有掌握好心法，招式才能运用自如。第6.3节的“十二条敏捷原则”，为团队实施敏捷开发给出了具体可行的建议。
\本书的第一部分是铺垫和基础，第二部分“组织工具”则给出了在大型团队实施敏捷开发的具体解决方案。如果你在敏捷开发中面临如下问题，就请认真研读这部分内容吧：
\- 什么是特性团队，为什么需要特性团队，它的优势是什么？\
- 传统组件团队的问题有哪些？\
- 如何建立自组织团队？\
- 团队如何进行决策？\
- 如何有效管理多个协作团队的需求？\
- 在精益和敏捷开发原则下，如何建立一个模型来协调好任务、人员、结构、奖金、流程以及策略，从而适应组织变革？\
- 如何进行大型Scrum开发？\
- 在实施大型Scrum开发过程可能遇到的问题有哪些以及如何应对？\
总体说来，这部分从更高层次展示了在一个精益和敏捷原则指导下具有多团队的Scrum组织是如何建立、协作并运行的。本部分的五章内容，组织思路很清晰，其目标是给出大型Scrum的组织框架，下图给出了这几章的递进关系：
\ 
\值得一提的是，作者在第11章指出，所谓的“大型Scrum开发”指的是一般的Scrum开发加上一套适合大型多团队、多地点、离岸敏捷开发的做法。作者描述了小于10个团队的大型Scrum框架（图11-1 大型Scrum开发框架1），以及扩展到多个团队（一般多于10个团队）的大型Scrum开发框架（图11-2 大型Scrum开发框架2），这对于我们实施Scrum开发给出了具体可行的操作方法。
\结合我在客户现场的经验，遇到的是6个10人左右的团队一起合作进行大型Scrum开发，其组织方式类似于图11-2，在实施过程中暴露出不少问题。最严重的问题还是各个Scrum团队之间的局部优化，虽然有多个产品负责人负责准备产品待办事项列表，但是各个团队在实施时，需要相互协作和配合。问题在于需要协作的部分，其优先级在各个团队内却大相径庭，所以某些团队高优先级的story因为得不到支持而被block，从而造成大量浪费，可见以特性团队作为基础来构建大型Scrum团队是多么重要！
\本书第三部分，杂记，仅包含一章内容——Scrum简介。本章详细描述了Scrum实施中的角色、实践以及常见问题，如Sprint计划会议、产品待办事项表提炼、Sprint评审会议等等。本章提到的各个实践，在传统团队转型过程中常常会遇到很大挑战，比如我们在客户现场常常遇到的一些挑战为：
\- 每日例会太浪费时间，我们没什么可说的，团队成员期望取消；\
- Story的故事点估算对于我一个开发人员来说没什么意义，开发人员期望取消；\
- 回顾会议我也不知道说什么，时间太长，团队成员期望取消；\
- 原来的PM们不知道怎么做好角色转换，反倒成了团队实施Scrum的绊脚石；\
- 团队成员抱怨Scrum不好，搞得一点自己的时间都没有，太累了；\
在阅读完本章之后，我找到了一些答案。首先是明白了每个实践怎么去实施，原则是什么；然后知道如何说服团队成员看到它的价值，当然也包括如何去培训PM转变职能和思想。除此之外，正如作者所说：
\\\Scrum是揭露组织问题的简易框架。
\
在组织运用Scrum框架之后能迅速暴露组织内的弱点，作为咨询顾问，利用这些弱点就找到了改进的起点。
\此外， 本书的内容组织方式也值得推荐。首先，在每章背后都有“结论”一节，总结本章主要内容，起到梳理知识的作用；其次，在每章最后给出“推荐资源”，这比在全书最后给出更有效，因为读者可以迅速找到对应主题的资源延伸阅读。特别是对于本书第一部分的各章，这种方式十分有效。
\最后，我还要强调任何实践都是招式。招式不是最重要的，重要的是内功心法，也就是背后的价值观和原则。对于Scrum来说即精益思想和敏捷价值观。值得庆幸的是，要想深入理解这些价值观，本书的前几章已经为我们开启了登堂之门。
132
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
