傳統企業的敏捷轉型實踐
——以惠普打印機固件開發為例

文/

惠普打印機固件始創于20多年前，曾經有過非常輝煌的歷史。2008年，惠普打印機已經在此固件基礎上開發了上百個產品，開發人員超過400人，分布在多個國家和地區，幾十個獲獎產品都是在原有架構支持下實現的。但是，它的局限是僅僅支持單功能的打印機，且每次新固件的開發需向下兼容其舊的功能，這就讓更新變得愈發艱難。因此，固件轉型勢在必行。

轉型難點

敏捷轉型分為三個級別：團隊級、產品級和組織級，面臨的困難和需要解決的問題也逐級遞增。這次轉型雖然只是惠普的一個產品，但是所涉及的領域和人數幾乎超過一個中小企業的規模，因此可以說相當于組織級的轉型。下面重點列舉幾個轉型過程中遇到的問題。

難點一：架構重構還是新建

當時，惠普打印機的架構已經過時，沒有清晰的系統接口圖，一旦改變一塊區域的代碼，難以估計會有多少關聯的地方被影響。此外，由于開發時不得不考慮對外設的影響，因此惠普在過去的幾年一直糾結于是滿足客戶需求還是開發新的產品功能。所以開發工程師被困在死循環中，開發不出有競爭力的產品。面對這樣的問題，需要的是找一個根本性的方法解決。與其把時間花費在解決問題上，不如開發出一個解決方案以避免這樣的問題發生。

筆者從這個項目獲得的經驗是，當研發人員超過25%的預期比重時，應該考慮重新架構系統，而不是對現有系統的修修補補。

難點二：如何實施規?；艚?/h3>

企業級敏捷轉型有兩種推行方法：一是自下而上，二是自上而下。兩種方法各有利弊。自下而上會讓團隊有很好的改進意愿，但是經歷時間長，對于團隊之外的問題需要領導層的幫助。對于自上而下的轉型，一旦領導層認可敏捷的價值，會從制度、流程和工具上大力推行。這種方式具有轉型的時間優勢。

此外，還有其他難點，例如如何調整組織結構，如何合理分配研發資源，如何建立分層測試策略等。本案例是自上而下的轉型模式，主要分享敏捷能解決的問題和方案。

轉型實踐

在選擇如何轉型的方法時，需要遵循敏捷/精益理論的一項基礎原則是減少支出和浪費（保持精簡）：如果你采取的敏捷實踐讓你比之前在計劃和開發階段所花費的時間成本更高，那么它就不是敏捷。這里列舉最為重要的幾個實踐方法或者原則。

注重團隊靈活性而不是運作方式

對于大規模敏捷的推廣，需要更關注下面幾類問題：

如何使集成更早、更頻繁？這個問題關系到大型持續集成如何實踐。

如何實現保持代碼隨時可發布？這會讓團隊意識到需要實現自動化部署流水線，必須先做好大規模的自動化測試系統。

如何用最小的投入做出企業級的開發計劃？這個問題會驅使團隊創建一個具有優先級的待辦事項，降低計劃和估算成本。

如何保持短期目標的正確性，以及確保在正確的方向上執行流程？這個問題幫助團隊更好地管理工作進行項（WIP）并提高每個短周期目標（Mini Milestone），以及使用敏捷的迭代方法。

讓每個團隊感受敏捷對于計劃及任務跟蹤的不同之處。不管是團隊已經開始用Scrum的燃盡圖和每日站會，還是一直在使用傳統的計劃和跟蹤辦法，決定權在于團隊。真正花費精力的地方是如何將需求分割成2～4周的任務，以進行目標設定和任務估算，以及安排自動化測試和集成等。設定嚴格的操作規范比自動化測試、持續集成、企業級計劃給團隊帶來的影響還要深。

減少編譯資源和時間

由于之前架構的限制，集成流程是由從每個團隊里挖出來的技術強人擔任“編譯負責人”專門負責本項目的編譯，每天要把開發人員變更的代碼整合起來，確保不同版本的代碼整合后仍然可以工作，再把代碼打包提交一份整合申請給中心編譯團隊。以上是手工過程，如果哪個地方報錯，就要打回申請，從頭開始編譯提交和整合等一系列過程。

除了流程所需要的大量人力和時間投入，還引起另外兩個問題：第一，如果沒有必要安排日程，不鼓勵開發團隊經常做大規模的代碼集成；第二，缺陷的發現/修復循環進行緩慢。當團隊開發新代碼時，要回過頭來修復上一版本代碼引起的問題，這樣來回切換極大地降低了功能產出率，并使開發效率大打折扣。

團隊嘗試過很多源代碼管理工具，像SCM（Source Code Management）用了很多年，直到選擇GIT。GIT是一個開源的工具，可以將復雜的代碼簡單準確地整合起來，是實踐持續集成的關鍵工具。團隊用開源的持續集成平臺（Cruise Control）創建簡單的自動化集成和編譯系統，每個小時或者新代碼提交時就會觸發一次編譯。現在，我們將持續集成時間縮短到一小時，相對于以前一周的時間，極大加快了功能開發和測試反饋的周期，也是實現敏捷流程的基礎。

團隊設置的其中一條度量項是固件（Firmware）每天可以編譯多少次。開始持續集成后，每天都有幾次失敗，并花費幾個小時甚至大半天時間解決問題。后來一般每天只做5～8次編譯，并專門創建了一個“紅/綠圖”展示，系統可以接受新代碼提交（紅表示系統正在編譯或者編譯報錯，綠表示可接受新代碼提交）。

合理調整人力資源

縱觀這個案例，超過400人聚集在固件，過百萬條代碼進行變更更新和集成測試, 并有很高的質量要求。在敏捷轉型之初，惠普處在一個非常復雜的開發環境，現有的資源剛夠維持系統的運行，具體的資源投資情況如下。

團隊10%的資源做代碼編譯（編譯負責人，全職從事代碼集成和編譯），設置了一個中心編譯團隊負責集成團隊的代碼。編譯團隊需要具備非常高的代碼水平，并通過人工操作來集成和回滾。這樣的流程，不僅讓資源變得緊缺，更糟糕的是有些代碼有可能要等將近一周的時間才能夠集成到主版本驗證。

團隊20%的資源為未來做計劃，這些計劃在不久的將來又變成難以完成或者不需要開發的內容。比如，業務和市場部門曾經提出，希望得到一個一年期的“最終功能列表”，并開始著手做細致的工作分解、排班、集成計劃和項目工時估算。后來發現這些內容需要不斷更新和維護。

團隊25%的資源投放到將其中一個產品的功能和代碼延伸到另一個產品中去。由于時間有限，敏捷轉型后，轉型專家打破組織內部分化的局面，在原有代碼基礎上，創建了三個不同的代碼分支。這意味著原團隊將從繁重的代碼維護中解放出來，專注于各分支的功能需求的開發。

團隊15%的開發資源投放到手工測試中去，這對于團隊來說是很大的一筆開支。盡管有非常龐大的測試工具支持，但是大部分工作是由測試工程師完成的。這也意味著，從測試反饋傳遞到開發人員需要經歷很長的一個周期。有時需要幾周，甚至出現過幾個月才能得到測試結果的情形。同時，因為沒有測試資源去測試這些新功能，很難將新的產品功能加入到開發計劃。

團隊25%的資源投入到支持現有產品的部署，包括實現客戶提的變更需求或者保障公共功能集可以跨平臺在多產品（Multifunction Products，MFPs）上實現。多年來，產品團隊不斷向市場投放不同的產品，現在已經有很多個功能分支需要維護和支持。

綜合上面的資源安排，團隊只剩下極少的資源可以投放到可以讓業務不斷向前的價值主張和客戶差異中。

成效思考

從業務的角度和當初的基線進行比較，筆者總結了大規模推廣敏捷所帶來的改進。

代碼集成成本率從10%降至2%。組件專家團隊，用自動化手段替代手工操作。每當大型整合存在問題或者設施上發生問題時，專家就會出手提供幫助。這些專家都是來自團隊中最被認可的工程師，從而讓集成成本降到了最低。

詳細計劃成本率從20%降至5%：這個時間成本主要是系統工程師和各個團隊組長的部分時間，系統工程師主要負責需求定義，團隊組長根據功能需求和架構限制做取舍，審核設計的擴展性和完整性。系統工程師和團隊組長的人工成本一般不會算到成本和日期中，但是對于需求的定義，則需求定義者保持很好的關系，這是實現“少承諾/高交付”的關鍵。

代碼移植率從25%降至15%。因為有時候每個產品的功能都是唯一的，需要非常熱情的人承擔這個職責，可以從宏觀上確保架構的完整性和對于現有的功能支撐和發展，不斷降低手工移植代碼的工作，

現有產品支持成本率從25%降至10%。創建一個小的團隊專門做產品支持。只要出現問題，專家都可以很快切入進來，不管是新產品團隊還是舊功能維護團隊。這個團隊同時也負責已經上市的產品新功能的質量保障。整個惠普Future Smart固件的戰略思路是不斷創新而不是新的產品，同時也保留現有的一系列產品。

測試資源分配率從15%降至 5%。過去有大量的手工測試工作需要做，現在引用自動化工具，降低手工測試的比重。

價值取向/客制化資源分配率從5%升至40%。時至今日，團隊把大部分資源用于架構實現及創造有競爭力的功能。未來團隊將更關注在新功能的創新以及需求的創造，這樣將更加穩固在市場上的領導地位，以及大量減少對業務的生產和支持成本。

后記

惠普打印機固件開發敏捷轉型的過程發生在惠普還未分家之前，筆者時任惠普服務中心敏捷咨詢組的組長。筆者實施了多個轉型成功的案例，也有幸同Jim Highsmith和Jez Humble共事參加了這個無論規模還是最終效果都堪稱成功的轉型工作。

在轉型之前，第一個需要認真思考的是為什么需要轉型，這將決定我們能在這條路上走多遠。

在敏捷轉型過程中，很多人開始是沒有信心的，一點點的積累后回過頭看，會發現原來已經比之前好很多了。任何變革或者改進都是這樣的，不會一

蹴而就。P