冬哥追樂夏 - 從後海大鯊魚為何加入，談敏捷專案試點

關於後海大鯊魚加入樂隊的夏天

敏捷與DevOps如何選擇試點專案

影響試點專案選擇的四個關鍵要素

• 持續時間 — 小專案會讓人懷疑敏捷只對小專案有用。如果專案過大，那麼大家又將不得不等待很長時間才能評估實施的情況。Mike 建議理想的專案週期應該接近中值，也就是公司所有專案程式時間的平均值左右。
• 大小—試點專案應該小到只需要一個團隊就能完成。這樣就沒有了多團隊和跨越溝通的問題了，這也就讓團隊能更加關注到敏捷過程中去。
• 重要性—試點專案得是對公司很關鍵的。這會刺激團隊很好地使用流程進行工作，從而確保專案的成功。一個不是很重要，風險也不高的專案通常只會變成演習專案。因此，試點要選擇那些在企業業務的主航道上的專案。但是，不要選擇那些最關鍵的專案，比如對企業生死攸關的專案、處於救火狀態的專案，因為拋開敏捷轉型因素不談，一旦這些專案自身運作有了問題，大家會懷疑“是敏捷的錯”。所以，要選擇那些在企業的主航道上的中等重要程度的專案。
• 業務發起人的參與—高度參與的業務發起人能幫助團隊在需要的時候去推動特定的業務流程、部門或者個人。業務發起人的參與時間和精力對專案的成功非常關鍵。很多企業的高管擔心敏捷轉型會影響專案的進度，因此喜歡選擇那些內部產品，原因是內部產品的進度可松可緊，沒有外部客戶和市場的壓力；或者傾向於選擇那些不在公司的主航道上的專案，原因是如果這些專案失敗或延期，對公司的核心業務沒有影響。但是，在這樣的專案裡即使試點成功，對公司的主航道專案人員也沒有說服力，因為大家會覺得這些專案不重要，他們有閒功夫來嘗試，而我們沒有時間。

微服務的四個特徵

試點團隊的選擇，也可以參考微服務小獨輕鬆的四個特徵。

• 小：Small services；粒度小，且專注一件事情；由2-Pizza團隊端到端負責1個或1組服務，大小是合適的；
• 獨：Own process，單獨的程式；
• 輕：Light weight mechanisms，輕量級通訊機制；
• 松：Independently deployable，松耦合，可獨立編譯（無二進位制介面依賴），獨立部署（無部署順序依賴），獨立執行（無啟動順序依賴）。

選擇試點還需要考慮啥？

• 團隊最好坐在一起：儘量不要選擇那些團隊分佈在不同的地區甚至國家的專案，除非這種分散式團隊是企業的主流團隊。
• 最好選擇那些新產品開發的專案，而不是維護型別的專案：維護型別的專案往往不能夠引入太多的變化，比如：你無法用敏捷的方式實踐新的Idea從誕生到上線的整個過程。此外，一般來說，維護型別的專案遺留程式碼的包袱比較重，在遺留程式碼上嘗試敏捷工程實踐尤為困難。
• 純軟體專案優先：如果企業有軟體、硬體整合的專案，要先選擇純軟體專案來試點，試點見效後再考慮將硬體專案試點。雖然有很多報導、案例證實敏捷完全可以應用在硬體專案中，本人也做過硬體專案的敏捷輔導，但是，相對來說，軟體的本質決定了軟體專案更加適合敏捷，也更容易讓企業看到變化。

再聊聊《樂隊的夏天 2》中的那些新生代

結語

• 《敏捷轉型-打造VUCA時代的高效能組織》王明蘭