這本書名字很長档玻，全名是《大規(guī)模敏捷開發(fā)實踐——HP LaserJet產(chǎn)品線敏捷轉(zhuǎn)型的成功經(jīng)驗》受啥，英文名是《A Practical Approach to Large-Scale Agile Development-How HP Transformed LaserJet FutureSmart Firmware》沛鸵。老外的非虛構(gòu)類書籍為了精準，書名都很長泄朴，比如《論借助自然選擇（即在生存斗爭中保存優(yōu)良族）的方法的物種起源》蔬顾，引入到中國的時候縮寫為《物種起源》。為了讓這篇文章的標題短一些玉掸，我就只用主標題了刃麸。

雖然書名很長，但其實書的篇幅并不長司浪，是一本32開不到200頁的小書泊业，但如譯者鄭立所說，這本書有點像日式料理啊易，都是很精華的內(nèi)容吁伺，并且內(nèi)容都是原汁原味，營養(yǎng)豐富租谈。其實也就是說都是干貨的意思篮奄，絕沒注水，因此值得你的閱讀時間割去。

今天準備把書中內(nèi)容制作成ppt窟却，后續(xù)組織下研討的，花了一下午的時間還沒有能夠做完呻逆，想著本周給自己定的目標必須要完成夸赫，所以還是先寫一篇讀后感，把感受最深的部分寫出來咖城。

這本書講述了HP LaserJet Firmware涉及到400多位研發(fā)人員的敏捷轉(zhuǎn)型經(jīng)歷茬腿，這種規(guī)模符合Craig Larman在《精益和敏捷開發(fā)大型應用指南》中關于大型的定義：如果你與所有團體成員在同一間辦公室里工作，都記不住所有人的名字宜雀，那這就算是大型團體了切平。實際上書中說的400人是分布在世界各地的，這種規(guī)模的轉(zhuǎn)型難度要更大一些辐董。鄭立將敏捷轉(zhuǎn)型劃分為個人轉(zhuǎn)型悴品、團隊轉(zhuǎn)型和組織轉(zhuǎn)型，書中的案例就屬于組織轉(zhuǎn)型。母公司將敏捷劃分為團隊級敏捷苔严、項目級敏捷菇存、產(chǎn)品級敏捷，書中的案例應該歸屬于產(chǎn)品級敏捷邦蜜。

Practical，理解敏捷精髓

值得注意的是原來書名中的practical這個詞亥至，翻譯成中文是實際的悼沈，實用的，意思是說這個案例中的轉(zhuǎn)型不是按照學院派的方式進行的姐扮，但是在中文書名中并沒有體現(xiàn)出來絮供。從介紹的轉(zhuǎn)型歷程來看，作者認為和學院派的主要差別有兩點：

一是并非從一兩個團隊起步轉(zhuǎn)型茶敏，有成效后再推廣的方式壤靶，而是由管理層發(fā)動400人一起動起來，但并不完全是自上而下的推動敏捷惊搏，而是一種上下結(jié)合的方式贮乳。作者在書中說單純的自上而下或者自下而上的方式，之前都失敗過恬惯，這次上下結(jié)合的方式讓團隊能夠切中團隊痛點向拆，讓團隊成員感受到好處，所以能夠成功酪耳；

二是作者并未嚴格遵循某種敏捷方法浓恳，如Scrum，雖然采用固定時間盒碗暗，有計劃會颈将、評審會、回顧會言疗，有某種形式的需求梳理會晴圾，但是沒有每日站會，用持續(xù)發(fā)布度量報告的方式完成團隊的溝通洲守，用度量來發(fā)現(xiàn)問題疑务，驅(qū)動改進。這個案例應該屬于守破離“破”的境界梗醇。對于初期接觸敏捷的團隊知允，應該還是先從“守”開始做起吧？

敏捷可以劃分為價值觀叙谨、原則温鸽、實踐和方法3個層次，其中最核心的部分是價值觀，也就是敏捷宣言的4+1句話涤垫，外圍的實踐和方法都是可以變的姑尺。敏捷是為了達成業(yè)務目標，讓研發(fā)團隊能夠更好的應對變化蝠猬，所以必須是痛點驅(qū)動切蟋，不能搞成貨物崇拜。

演進式架構(gòu)支撐業(yè)務榆芦，并投入人員持續(xù)維護

Firmware是打印機的核心軟件柄粹，類似計算機的操作系統(tǒng)，復雜度高匆绣。400人的團隊在維護一個上百萬行有多年歷史的代碼庫驻右，急需重構(gòu)，研發(fā)人員飽受多代碼分支的困擾崎淳，整天忙于救火堪夭。整個團隊95%的人員精力在日常的交付和維護上，只有5%的精力能夠投入到新特性的研發(fā)上拣凹。管理層嘗試過將開發(fā)團隊人員增加2.5倍森爽，但并未解決問題。

之前Firmware只是用于單功能打印機嚣镜，但是客戶越來越不滿意拗秘，市場希望有能夠有多功能打印機，并且每次升級固件之后就可以自動具備新的功能祈惶，當前的系統(tǒng)架構(gòu)無法滿足這個要求雕旨。研發(fā)總監(jiān)提出一種新的架構(gòu)來支撐這種市場需求，但起初因為做不到捧请，大部分技術人員都認為研發(fā)總監(jiān)的想法是天方夜譚凡涩，并不支持，直到有一天有人解決了關鍵技術問題疹蛉，讓這個架構(gòu)成為可能活箕。隨后經(jīng)過6個月的迭代架構(gòu)演進，終于實現(xiàn)了這個市場需求可款，支撐了后續(xù)的單主干開發(fā)模式育韩，這是后續(xù)所有敏捷運作的基礎。

其實遺留代碼難以維護和擴展闺鲸，這幾乎是所有有歷史的軟件系統(tǒng)共同的痛點和難點筋讨，唯有通過新的架構(gòu)實現(xiàn)了產(chǎn)品化，才能真正減少后續(xù)的人力投入摸恍。書中對于新的架構(gòu)的效果提供了一張圖悉罕，但因為我并不了解打印機赤屋，其實我并沒有特別理解，不知道是什么樣的架構(gòu)壁袄。也許是需要有另外一本書專門來講這個架構(gòu)的类早，也許這是HP的核心商業(yè)機密，不可能隨便公開嗜逻。

為了保持架構(gòu)的完整性涩僻，書中建議需要有一個架構(gòu)師團隊持續(xù)的維護架構(gòu)，對每個需求進行詳細的分析栈顷，決定是否需要架構(gòu)的支撐令哟，以免架構(gòu)在后續(xù)維護工作中腐化。

這個案例體現(xiàn)了架構(gòu)師的重要性妨蛹，或者說是優(yōu)秀程序員和普通程序員的價值差別：一個重點的技術難關的突破就依賴于1個核心人員，給10個普通程序員沒法解決問題晴竞。問題是蛙卤，這個核心人員的薪資會有普通人員的10倍嗎？

持續(xù)集成和質(zhì)量系統(tǒng)

這一章的內(nèi)容是持續(xù)集成噩死、分級自動化測試和快速的質(zhì)量反饋颤难，實際上就是《持續(xù)交付》中提到的部署流水線。因為成書時間早于《持續(xù)交付》已维，所以不是按照部署流水線來提的行嗤。作者建議更多細節(jié)可以參考《持續(xù)交付》。

怎么強調(diào)持續(xù)集成在敏捷運作中的重要性都不過分垛耳。有自動化測試的持續(xù)集成栅屏，并且形成對開發(fā)人員的快速反饋環(huán)，這是生產(chǎn)率10倍速提升的關鍵堂鲜。沒有自動化測試和持續(xù)集成的敏捷都是假敏捷栈雳。

書中在另外一個章節(jié)重點提到了虛擬機供應系統(tǒng)，確實在推行CI和CD時研發(fā)人員最頭痛的事情是申請和維護機器資源缔莲，是個關鍵問題「缛遥現(xiàn)在公司內(nèi)部也在加緊打造云CI，簡化這塊的成本痴奏，非常值得期待蛀骇。

這里給我的啟發(fā)是：可以通過度量每天的編譯構(gòu)建次數(shù)和集成代碼行數(shù)量這個指標來衡量研發(fā)的效率。書中提到的10倍速提升读拆，指的就是這兩個指標的提升擅憔。這兩個指標可以驅(qū)動研發(fā)人員關注持續(xù)集成的構(gòu)建效率指標，驅(qū)動自動化程度的持續(xù)提升檐晕。

敏捷計劃和項目管理

在敏捷轉(zhuǎn)型之前雕欺，有20%的資源用于做詳細的估算和計劃，但計劃經(jīng)常變化，投入被浪費屠列；在轉(zhuǎn)型之后啦逆，把“長計劃”變成了“常計劃”，只需要投入2%的時間做計劃笛洛，資源是大大節(jié)省了夏志。前提條件是市場負責人必須給出明確的優(yōu)先級排序。書中沒有提到用戶故事地圖苛让，但感覺本質(zhì)應該是類似的沟蔑。書中提到一本Dean Leffingwell的《Agile Software Requirements》，提供了敏捷項目計劃的很好素材狱杰，可以作為下一步的讀書目標瘦材。

書中特別提到了一個系統(tǒng)工程師的角色非常關鍵，這個角色的主要職責是整體分析需求仿畸，并全程跟蹤需求的實現(xiàn)過程食棕。在Scrum中是沒有這樣的角色的，但是對于一個大規(guī)模的產(chǎn)品團隊错沽，這個角色是不可缺少的簿晓，因為PO是市場人員，可能對系統(tǒng)的具體實現(xiàn)并不非常清楚千埃，另外精力上也顧不過來憔儿。具體到某個研發(fā)團隊，可能只關注自己負責的一塊內(nèi)容放可，缺乏對整體的了解谒臼，所以這種整體協(xié)同的角色是必須的。

對了耀里，大規(guī)模敏捷框架如LeSS和SAFe我都還沒花時間學習屋休，不知道其中是否有類似的角色？

印象深刻的主要是上面幾點备韧，先寫這么多吧劫樟，有缺漏的以后再補充。