目前，在軟體開發工程領域，敏捷開發流程已經逐步取代瀑布開發流程成為主流。敏捷開發流程的最大特點是以兩個星期為一個開發周期（即Sprint）逐步進行迭代，從而更好的響應來自客戶需求，UI設計或者技術方案的變化。Sprint Planning可以說是整個流程中最重要的一步了，在這一步會理清需求，消除儘可能多的不確定因素，從而確定下來整個Sprint任務的範圍進而分配任務到個人，讓團隊能夠穩定的交付。我目前所在的企業，開發流程採用了企業級的Scrum框架SAFe(scaled agile framework)，它相對於經典Scrum流程，增加了許多環節，其中一個就是PI Planning。PI Pllanning是針對一個PI，通常是6個Sprint中的5個正常的開發Sprint的範圍作計劃，剩下的1個IP Sprint用於PI Planning、Innovation和修bug等等。

初始認知

剛接觸SAFe流程時，我最大的困惑就是關於PI Planning了。按照Sprint Planning的思路來推演，計劃是為了消除變化，從而穩定的交付，那麼計劃的周期越長，不確定因素就越多，也就越難消除變化。一個PI的目標確定下來後，它工作內容的範圍基本上是固定的，通常是不會更改的。相對固定的工作內容，一方面讓響應變化的周期將從一個Sprint擴大的一個PI；另一方面，在PI Planning時，是會把要做的工作細化到把每個Sprint中去的，當PI Planning結束時，每個Sprint要做的事情也會有個大概，並且相對固定，那麼Sprint Planning的作用會削弱，更偏向於任務的細化和分配。這樣的流程中一個隱藏的困境就是一旦某個Sprint的工作因為各種原因滯後或者錯誤估計了，其實是沒有多少調整空間的，要不就會影響後續的Sprint。關於這個潛在風險，SAFe的指導原則是，除了第一個Sprint需要排滿工作量，後面的Sprint的工作量可以逐漸遞減來應對一些預期之外的變化。這是一個好的建議，但是因為整個PI的目標是固定的，如果再加上如果整體開發工作的時間節點是固定的，這個原則就真的只起「指導」作用。於是，再高大上的管理流程，在幹活的人眼裡也只是「理想」，現實才是真實的。借用薛兆豐老師在得到專欄《北大經濟學課》的一句話來說，「凡政策必遭遇對策」，開發團隊的「對策」就是：

1. 重視PI Backlog Grooming，在PI Planning之前儘可能的發現不明確的地方，並儘可能的想辦法消除。方法不外乎兩種，要麼自己研究，要麼問明白人。

2. 合理的估計團隊的工作能力，即Velocity。

3. 合理的協調PO(Product Owner)的期望。

前兩條SAFe的指導原則中有提到。後面兩條團隊處理的好壞在一定程序體現了這是否是一個成熟的團隊，沒什麼太好的方法，需要一定的時間，來慢慢磨合。如果這三條都沒做好，那隻能是自己挖的坑，自己填，硬著頭皮上吧，需要加班就加班吧，千萬別問不是說好的，跑了Scrum就會不加班了嗎？嘿嘿

簡單來說，那時我就是把PI Planning當大號的Sprint Planning來對待的。加上在公司的前幾個項目，都比較獨立，和其它的團隊交集不是很多。於是，在相當長的時間裡，我都覺得PI Planning有些雞肋。

第一次迭代

這個印象直到去年開始做公司的下一代平台中的項目時才有此許改變。公司在下一代平台的項目上投入了很大的資源，方方面面有10多個團隊工作在不同的子項目上，這樣的項目背景是SAFe最適用的場景。PI Plannning提供了一個合適的窗口來協調各個團隊之間的依賴，並分析潛在的風險。我試著用更高的格局來看待PI Planning，把PI Planning中計劃的Feature類比為Sprint Planning中的User Story，參與PI Planning中的各個團隊類比為參與Sprint Planning中的一個個成員，那麼PI Planning其實是身處幕後的管理團隊的Sprint Planning，只是他們需要通過各個團隊的反饋來實現，而不是自己實現。再則，因為計劃的粒度變大了(Feature通常有多個User Story組成，User Story又由多個Task組成)，所以計劃的周期由兩個星期擴大到三個月是合理的。順著這個思路想，高管團隊應該是通過管理團隊的Release Planning來做他們的Sprint Planning，周期就更長了。回到團隊的角度，作為要落地實施的團隊成員，相對於Sprint Planning，PI Planning需要的考慮的因素多了，計劃的粒度大了（即計劃的是User Story，而不是Task），所以本質上還是存在當計劃的粒度變大周期拉長，不確定因素概率變大的問題。我接受了這是一個限制，因為能夠解決的問題是問題，不能夠解決的問題就是限制，只能接受。按我的理解，一個開發團隊走向成熟的過程就是和這個限制逐漸和解的過程。

第二次迭代

在上面階段，我還一直在糾結計劃和變化的關係，並篤定計劃要以消除變化為目的。直到我在聽了羅輯思維4月19號《計劃的用處》的音頻後，才終於領悟，計劃不是用來不折不扣地實現的，它有以下三個妙用：

1. 計劃制定的過程，本質上是一個統一上上下下的意志和決心，明確戰略方向，盤清資源家底的過程。

2. 計劃的結果是讓臨時應變者可以有一個資源框架可以利用。

3. 計劃的結果是形成一個個小型的執行模塊。

羅胖在那期節目中以公認的戰鬥力強、作戰素養高的德軍為引子，指出了德軍的強大源自於戰前作戰計劃的詳盡。以施里芬計劃為例，那可是詳盡到每支部隊每天要做什麼的地步。而真實情況卻如一位著名的德國將領所說的前半句是「一旦開戰，所有的計劃也就作廢了」，他的後半句卻是「但戰前必須制定計劃」。重點就在於上面提到的三個妙用，施里芬計劃讓德軍上上下下都明確了要儘快結束西線戰事，不能陷入東西兩面作戰的局面。同時一旦情況有變，戰場中的指揮官可以基於計劃作一些大體的預測，以原有的計劃為參考執行下一步的行動，而不至於毫無方向，亂成一團或者原地待命。

回到PI Planning這個場景，團隊在計劃的過程中會對未來三個月的工作強度產生共識，對哪個Spring要緊一些，哪個功能要提前準備起來有了清晰的認識，即使哪個功能或者依賴的內容有所變化，團隊也可以根據計劃知道總體的進展情況，有其它的可做的功能，並在Sprint Planning時做出相應的調整，不至於陷入開發進度完全停滯的狀態。這麼相來，計劃是為了更好的應對變化，因為對某些場景思考過，不是完全陌生的狀態，遇到變化才不會不知所措。這與「擁抱變化」的軟體開發思想不謀而合。轉變了思路後，確實對接下來的PI Planning更加期待呢。

第三次迭代

這次迭代是受益於得到App的《李翔知識內參》5月28號的一篇文章《扎克伯格如何定目標》，文中總結了扎克伯格的歷年年度目標的特點：

1. 重複做一件小事，比如每天打領帶，每天跑步。

2. 它們都服務於扎克伯格為自己設定的大的目標：通過社交網路連接起每個人。

這種大目標和小目標相結合思路不就是團隊成員每天的開發或者測試，實現Sprint的目標，進而實現PI的目標嗎。PI Planning的結果就是那個大目標，那麼每天默念一次PI Ojective會不會覺得更有動力呢？因為你是為了三個月後回個頭來看，當初的設想都一一實現了，那一刻就是努力工作三個月的意義。

本文首發於我的個人公眾號《踐行思考再踐行》，歡迎關注。

aHR0cDovL3dlaXhpbi5xcS5jb20vci83amdUQzJQRWJ6NFFyU2RvOTIzOA== (二維碼自動識別)

推薦閱讀：

相关文章