《大规模敏捷开发实践》 读书笔记之一
这本书名字很长，全名是《大规模敏捷开发实践——HP LaserJet产品线敏捷转型的成功经验》，英文名是《A Practical Approach to Large-Scale Agile Development-How HP Transformed LaserJet FutureSmart Firmware》。老外的非虚构类书籍为了精准，书名都很长，比如《论借助自然选择（即在生存斗争中保存优良族）的方法的物种起源》，引入到中国的时候缩写为《物种起源》。为了让这篇文章的标题短一些，我就只用主标题了。
虽然书名很长，但其实书的篇幅并不长，是一本32开不到200页的小书，但如译者郑立所说，这本书有点像日式料理，都是很精华的内容，并且内容都是原汁原味，营养丰富。其实也就是说都是干货的意思，绝没注水，因此值得你的阅读时间。
今天准备把书中内容制作成ppt，后续组织下研讨的，花了一下午的时间还没有能够做完，想着本周给自己定的目标必须要完成，所以还是先写一篇读后感，把感受最深的部分写出来。
这本书讲述了HP LaserJet Firmware涉及到400多位研发人员的敏捷转型经历，这种规模符合Craig Larman在《精益和敏捷开发大型应用指南》中关于大型的定义：如果你与所有团体成员在同一间办公室里工作，都记不住所有人的名字，那这就算是大型团体了。实际上书中说的400人是分布在世界各地的，这种规模的转型难度要更大一些。郑立将敏捷转型划分为个人转型、团队转型和组织转型，书中的案例就属于组织转型。母公司将敏捷划分为团队级敏捷、项目级敏捷、产品级敏捷，书中的案例应该归属于产品级敏捷。
Practical，理解敏捷精髓
值得注意的是原来书名中的practical这个词，翻译成中文是实际的，实用的，意思是说这个案例中的转型不是按照学院派的方式进行的，但是在中文书名中并没有体现出来。从介绍的转型历程来看，作者认为和学院派的主要差别有两点：
一是并非从一两个团队起步转型，有成效后再推广的方式，而是由管理层发动400人一起动起来，但并不完全是自上而下的推动敏捷，而是一种上下结合的方式。作者在书中说单纯的自上而下或者自下而上的方式，之前都失败过，这次上下结合的方式让团队能够切中团队痛点，让团队成员感受到好处，所以能够成功；
二是作者并未严格遵循某种敏捷方法，如Scrum，虽然采用固定时间盒，有计划会、评审会、回顾会，有某种形式的需求梳理会，但是没有每日站会，用持续发布度量报告的方式完成团队的沟通，用度量来发现问题，驱动改进。这个案例应该属于守破离“破”的境界。对于初期接触敏捷的团队，应该还是先从“守”开始做起吧？
敏捷可以划分为价值观、原则、实践和方法3个层次，其中最核心的部分是价值观，也就是敏捷宣言的4+1句话，外围的实践和方法都是可以变的。敏捷是为了达成业务目标，让研发团队能够更好的应对变化，所以必须是痛点驱动，不能搞成货物崇拜。
演进式架构支撑业务，并投入人员持续维护
Firmware是打印机的核心软件，类似计算机的操作系统，复杂度高。400人的团队在维护一个上百万行有多年历史的代码库，急需重构，研发人员饱受多代码分支的困扰，整天忙于救火。整个团队95%的人员精力在日常的交付和维护上，只有5%的精力能够投入到新特性的研发上。管理层尝试过将开发团队人员增加2.5倍，但并未解决问题。
之前Firmware只是用于单功能打印机，但是客户越来越不满意，市场希望有能够有多功能打印机，并且每次升级固件之后就可以自动具备新的功能，当前的系统架构无法满足这个要求。研发总监提出一种新的架构来支撑这种市场需求，但起初因为做不到，大部分技术人员都认为研发总监的想法是天方夜谭，并不支持，直到有一天有人解决了关键技术问题，让这个架构成为可能。随后经过6个月的迭代架构演进，终于实现了这个市场需求，支撑了后续的单主干开发模式，这是后续所有敏捷运作的基础。
其实遗留代码难以维护和扩展，这几乎是所有有历史的软件系统共同的痛点和难点，唯有通过新的架构实现了产品化，才能真正减少后续的人力投入。书中对于新的架构的效果提供了一张图，但因为我并不了解打印机，其实我并没有特别理解，不知道是什么样的架构。也许是需要有另外一本书专门来讲这个架构的，也许这是HP的核心商业机密，不可能随便公开。
为了保持架构的完整性，书中建议需要有一个架构师团队持续的维护架构，对每个需求进行详细的分析，决定是否需要架构的支撑，以免架构在后续维护工作中腐化。
这个案例体现了架构师的重要性，或者说是优秀程序员和普通程序员的价值差别：一个重点的技术难关的突破就依赖于1个核心人员，给10个普通程序员没法解决问题。问题是，这个核心人员的薪资会有普通人员的10倍吗？
持续集成和质量系统
这一章的内容是持续集成、分级自动化测试和快速的质量反馈，实际上就是《持续交付》中提到的部署流水线。因为成书时间早于《持续交付》，所以不是按照部署流水线来提的。作者建议更多细节可以参考《持续交付》。
怎么强调持续集成在敏捷运作中的重要性都不过分。有自动化测试的持续集成，并且形成对开发人员的快速反馈环，这是生产率10倍速提升的关键。没有自动化测试和持续集成的敏捷都是假敏捷。
书中在另外一个章节重点提到了虚拟机供应系统，确实在推行CI和CD时研发人员最头痛的事情是申请和维护机器资源，是个关键问题。现在公司内部也在加紧打造云CI，简化这块的成本，非常值得期待。
这里给我的启发是：可以通过度量每天的编译构建次数和集成代码行数量这个指标来衡量研发的效率。书中提到的10倍速提升，指的就是这两个指标的提升。这两个指标可以驱动研发人员关注持续集成的构建效率指标，驱动自动化程度的持续提升。
敏捷计划和项目管理
在敏捷转型之前，有20%的资源用于做详细的估算和计划，但计划经常变化，投入被浪费；在转型之后，把“长计划”变成了“常计划”，只需要投入2%的时间做计划，资源是大大节省了。前提条件是市场负责人必须给出明确的优先级排序。书中没有提到用户故事地图，但感觉本质应该是类似的。书中提到一本Dean Leffingwell的《Agile Software Requirements》，提供了敏捷项目计划的很好素材，可以作为下一步的读书目标。
书中特别提到了一个系统工程师的角色非常关键，这个角色的主要职责是整体分析需求，并全程跟踪需求的实现过程。在Scrum中是没有这样的角色的，但是对于一个大规模的产品团队，这个角色是不可缺少的，因为PO是市场人员，可能对系统的具体实现并不非常清楚，另外精力上也顾不过来。具体到某个研发团队，可能只关注自己负责的一块内容，缺乏对整体的了解，所以这种整体协同的角色是必须的。
对了，大规模敏捷框架如LeSS和SAFe我都还没花时间学习，不知道其中是否有类似的角色？
印象深刻的主要是上面几点，先写这么多吧，有缺漏的以后再补充。
