敏捷開發系列文章目錄

    在討論PO如何給團隊講好故事這個問題之前，先給大家瞭解一些基本的敏捷概念，然後講講我們敏捷團隊構成與整個敏捷開發的過程。

    當初敏捷老師講課的時候就跟我們所過，敏捷沒有什麼具體的形式，每個敏捷團隊可能做法都不一樣，表現出來的性格也不一樣，比如有挑戰型團隊、有保守型團隊等。但敏捷有一個核心是不能變的，這個核心就是3355。

1、3個角色：SM、PO、開發團隊（自然包括了我們的開發人員和QA）。
2、3個產出物：Product Backlog、Sprint Backlog、互動的可用軟體工件。
3、5個活動：計劃會、sprint評審會、回顧會、每日立會、Product Backlog的梳理（發生在整個SCRUM週期的任何時間）。每一個會議都有自己的時間盒，其長短在SCRUM中都有比較明確的建議。當你召開某一個會議的時候，超出了這個時間盒或者召開某個會議的時候出現一些問題，也是一種有問題的訊號。一個團隊在衝刺的週期內，去充分的暴露問題，然後在回顧會上去分析問題，再進行改進。在每日立會上比較強調的是，根據昨天完成的情況來做出新的調整，我們每日立會上所描述的，一定是對有助於完成當前sprint目標的事情。同時，特別需要強調的是，在sprint評審會上，團隊除了對當前sprint完成的故事進行show case還需要對剩餘的任務卡進行梳理，可以讓團隊有機會去回顧和識別版本釋出的風險。

    我所在的團隊有11個人，1個PO（也就是我自己），1個SM（他有兼職好幾個團隊的SM），6個開發和3個測試，這算是一個比較大的敏捷團隊了，一般6,7個人一個團隊剛剛好。然後我們團隊開始開發一個系統，當然這個系統在分配到我們團隊之前在公司是已經立過項的，有一個基本的PRD文件，架構設計也都已經確定下來（我們做應用系統的架構一般比較固定）。這時候我就會把所有的需求整成一個故事地圖，然後根據故事的緊急程式會把故事放到對應的Product Backlog，然後請求開發團隊對這些故事做一個簡單的估算，好讓我知道這些故事大概需要多少個迭代完成。迭代開始，PO拿出第一個迭代的故事給到團隊，我們一個迭代是2個星期，10個工作日，一般第1個工作日開迭代計劃，最後一個工作日做整合測試和迭代回顧，所以一個迭代真正做事的時間只有8個工作日。迭代第一天由產品經理給團隊講故事，然後團隊對故事進行估點，這個一般都花費好幾個小時，重點就是團隊所有人都搞清楚這些故事有一些什麼東西，再接著就是團隊成員自由領用自己的故事，然後對自己的故事拆分任務排計劃，這天最後團隊一起給出一個本次迭代完成的信用值，信用值從1-5,5表示本次迭代肯定完成，4表示努力一把還是能夠完成的，3表示可能加班才有可能完成，2表示加班都有可能完不能，1表示怎麼搞都完不成。

    一般開迭代計劃會之前PO會把本次迭代的故事都會提前發給團隊，讓大家都提前熟悉一下故事，這樣可以速縮短迭代計劃會的時間。開完迭代會第二天不會馬上就開始動手編碼，一般上午會開設計評審和測試用例評審兩個會議，開發人員設計的產出包含用例圖、概要類圖、資料庫表結構和介面原型，設計評審就是對這些東西就行討論。測試人員編寫的測試用例，開發人員參與評審，就是驗證測試理解的功能實現與開發想的是否一樣，與PO想表達的是否一樣。

    評審之前開發人員可以準備一些資料，最好用圖來表達自己的設計思路，不必編寫一個什麼設計文件來應付評審。接下來就可以進入編碼實現階段，每天早上準時開每日站會，大概10分鐘，由SM組織，簡要說明一下今天要做的任務，有什麼困難加強團隊的溝通協助。迭代過程中最重要的一張圖就是燃盡圖，基本上每個人都會關注，如果發現這張圖下降得不正常，那麼SM一般就會找出問題並進行干預。第一週週五的下午會組織一次程式碼走讀，然後迭代完成的前一天會再進行一次程式碼走讀。然後所有故事開發完成後，測試進入整合測試。整合測試完之後，測試會給出一個DI值，這個值的大小會決定本次迭代的成功或失敗。然後開sprint評審會，由PO來驗收本次迭代的成果。接下來就是最重要的迭代回顧會了，回顧會中全體成員總結本次迭代遇到的問題，以及解決方法，還有團隊好的方面也要記錄並保持下去，還會對之前迭代制定的解決方法進行回顧是否有用。

    最後回顧會議中還會評出本次迭代的迭代之星，表揚表現最突出的成員，迭代之星最後會獲得團隊提供的一些小禮物。然後下週繼續開始下一個迭代。

    PO對產品負責，開發團隊勇於對自己承諾的故事，SM是團隊的保護傘。

    敏捷開發系列文章目錄