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

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

去年夏天，是《樂隊的夏天》。

冬哥喜歡搖滾樂隊，打小就喜歡，所以樂夏第二季來了，冬哥一定會追。

記得彭磊在夏日終曲那首歌結束時說，曾經邀請後海大鯊魚的老曹客串吉他手，後者說打死也不會來。

但是樂隊的夏天第二季，後海大鯊魚自己主動來了。

小組PK賽剛進行了一場，還沒輪到後海大鯊魚這組。下輪到他們上場，勢必會被問到這個問題。

我猜測其答案，大概超不出以下幾點：看到了節目組的專業性、真誠，並非一檔單純的娛樂節目，能夠看到節目組對樂隊的尊重，希望可以讓樂隊的夏天真正的來到，自己也能夠參與助力。

據說樂夏1結束後，收到了近1000支樂隊報名，而首季節目組可是一個個打電話邀約。從0到1，永遠是最難的，因為會有各種質疑，會有各種傲嬌和驕傲，會擔心翻車，會放不下搖滾樂隊的堅持和矜持。

有了第一季的打底，有痛仰、面孔、新褲子、旅行團、刺蝟這樣的老炮，有盤尼西林、九連真人、Click 15、斯斯與帆這樣的新人，風格囊括了朋克、金屬、FUNK、民謠、雷鬼、搖滾、電子。

再沒有一個樂隊會傲嬌地說，樂隊的夏天與我無關；有了第一季的臺階，就更容易放下身段，去參與到一個略帶比賽的娛樂節目中，畢竟痛仰、面孔這樣接近30年的樂隊老大哥都可以參與並樂在其中。

所以，第二季來了很多重量級樂隊，包括後海大鯊魚。我想說，這就是榜樣的力量。

萬事開頭難，所以需要打個樣板，所以需要榜樣的力量。

一旦成功達成從0到1的突破，從1到3的過程就會水到渠成，就會吸引到更多重量級樂隊的目光。

（當然也會有人來搭順風車，所以討論評委對水木年華的評價是否尖刻其實沒有意義，畢竟這幫號稱搖滾樂評委也要標榜自己的態度，最大的問題在於節目組。）

在敏捷和DevOps轉型中選擇試點專案，也是一樣一樣的。

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

Small Win，積小勝為大勝，是敏捷和DevOps的行動指南，同樣也適用於試點專案的選擇。

敏捷試點與成功推廣之間，存在著一道鴻溝，所以如何選取試點團隊並保證成功，並且對未來的專案推廣的影響，對敏捷轉型而言至關重要。

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

Mike Cohn曾提出影響試點專案選擇的四個關鍵要素。

“不是每個專案都合適成為試點的。理想的試點專案需要綜合專案大小、專案持續時間、專案重要性以及業務發起人的參與度。”

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

微服務的四個特徵

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

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

每個微服務相對獨立且松耦合，對其他團隊較少依賴；能夠完成一個端到端的服務，對於業務價值的衡量就尤為重要；較小的服務，以及團隊規模，更容易在內部鬆土並儘快達成思想一致。

選擇試點還需要考慮啥？

除了Mike Cohn的模型裡提到的因素以外，還需要考慮以下因素：

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

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

除了重磅樂隊，樂夏2出現了一票新晉樂隊，例如Mandarin、福祿壽、傻白。

Mandarin和福祿壽順利晉級，傻白遺憾被淘汰，但我相信傻白大機率會被撈回來，即便不是，也已經讓我們記住了這個名字。

這幫新生代實力滿滿，新意十足，不可小視，更重要的是，他們Nothing to lose。

傳統專案或者系統的轉型，會有太多的歷史包袱，不求有功但求無過的心態，是不適合做試點的，就像求穩的樂隊註定走不長一樣。

新的專案，尤其是創新類專案，天生適合敏捷，因為創新就需要快速探索、快速試錯，就需要小步快跑而不是大河東流浪淘盡時間和金錢。

那麼創新類專案，是否適合選取做試點專案呢？並非最佳選擇。

目的要單純，創新類專案的目的是業務探索，不要把敏捷試點與業務試錯摻雜在一起。創新就意味著大機率會失敗，而試點專案的失敗是難以接受，並且存在政治意義的。這會讓原本應該及時止損終止專案的決策，因為考慮到試點專案的成敗，而變得猶豫舉棋不定。這不僅與創新探索的初衷相違背，同時也讓敏捷試點失去了意義。

結語

總結下來，試點就是要找典型，即典型的團隊規模大小，典型的專案週期時間，業務價值具備樹典型（打樣板）意義，天時地利人和兼備。

從0到1的試點，也不要貪心，每次只嘗試少量必要的實踐；從1到3將動作進行固化，並適應不同的團隊和專案，並且適度對嘗試的實踐加以擴充套件。

樂夏到第三季除了收割以外，一定會求變，大眾的口味很容易審美疲勞。試點專案從3到N的過程，精化、深化和差異化是重點，一方面是要擴量，另一方面是要玩出新意，到那個時候，也許就是另一個維度的從0到1的過程，正如創新的第二條S曲線。

樂夏2中，採訪水木年華，問起來最近為何沒有音訊，盧自嘲是因為過氣了，而自己在搞電影另一位在搞助農。那麼請問，為何李健沒有過氣？

永遠不要滿足現狀，持續去追尋新的增長曲線，做樂隊如此，做試點和轉型也是同樣。

參考材料

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