不論怎樣，生活還是要繼續，我們就這樣懵懵懂懂、半推半就地實踐著我們自認為的敏捷開發……

前段時間，一個偶然的機會，我的工作角色發生了比較大的變化，開始做一個專案(Feature)的負責人，我們稱之為FP(不是Fang Pi，是Feature Prime)。此時，因為兩年多的實踐結果並不理想，公司已經不再大肆鼓吹敏捷開發了，但是車子大了不是說剎車就停得住的，在我們的開發過程中還是摻雜著一些敏捷開發過程的元素，這也剛好讓我有機會從另外一個角度重新審視敏捷開發。

作為FP，我的工作主要是制定計劃、監控進度、預估風險和風險發生時作出相應處理。

首先，要說一下這個“計劃”，一個專案的計劃絕對不是一個靜態的、一成不變的計劃，專案的計劃是要隨著專案的進行不斷調整以適應各種變化的一個動態的計劃。當然，這並不表示專案初期的長遠計劃沒有意義，專案剛開始的時候，一個比較長遠的計劃，對整個專案的開展具有重要的指導意義，很簡單，凡事只有有了方向才能向前進。其實，這也常常是初嘗敏捷開發者的一個理解誤區，認為敏捷開發的專案都沒有一個長遠的計劃。誠然，敏捷開發因為以小步快走的方式進行，所以更多的是短而小的計劃，一個

再說“監控進度”和“預估風險”。專案的第一個Sprint結束後，我們開了一個Retrospective meeting(這個會議我一直是支援的，因為我認為階段性的反思和總結是很重要的)，會上大家一致認為剛剛結束的一個Sprint裡，團隊成員之間的溝通太少，導致資訊不同步，會議決定從下個Sprint開始恢復每天站會(Daily Standup meeting)。每天都進行一次15分鐘左右的同步會議，對於FP瞭解專案的進度和估計可能的風險，都有很大的幫助，因為每天同步可以保證資訊的實時性，而面對面交流則可以保證資訊的準確性。可在我們團隊裡面，我慢慢地發現了一個問題，每次同步得到的資訊都不是那麼清晰，都有一些模稜兩可、不是很確定的地方。究其原因，則是因為在

洋洋灑灑千餘字，總要有點結論性發言。首先，敏捷開發對於管理專案不能說不好，但是想做好很難。其次，想做好敏捷開發，必須有合適的團隊，也就是”Self-Organized”的團隊。所以，敏捷開發好還是不好，取決於它是不是你的那道菜。

                              -- 2013年8月