2.迭代開發的過程是怎麼樣的

    敏捷開發系列文章目錄

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

 

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

一、3個角色：SM、PO、開發團隊（天然包括了咱們的開發人員和QA）。
二、3個產出物：Product Backlog、Sprint Backlog、交互的可用軟件工件。
三、5個活動：計劃會、sprint評審會、回顧會、每日立會、Product Backlog的梳理（發生在整個SCRUM週期的任什麼時候間）。每個會議都有本身的時間盒，其長短在SCRUM中都有比較明確的建議。當你召開某一個會議的時候，超出了這個時間盒或者召開某個會議的時候出現一些問題，也是一種有問題的信號。一個團隊在衝刺的週期內，去充分的暴露問題，而後在回顧會上去分析問題，再進行改進。在每日立會上比較強調的是，根據昨天完成的狀況來作出新的調整，咱們每日立會上所描述的，必定是對有助於完成當前sprint目標的事情。同時，特別須要強調的是，在sprint評審會上，團隊除了對當前sprint完成的故事進行show case還須要對剩餘的任務卡進行梳理，可讓團隊有機會去回顧和識別版本發佈的風險。
四、5個價值觀：公開、專一、勇氣、承諾、尊重。
    另外，還講到了SCRUM最重要的時間盒，這個是我以前所理解的SCRUM裏面，沒有發現它居然是如此重要的。還學到一個新的理論：番茄工做法是一我的的SCRUM，SCRUM是一羣人的番茄工做法；理解到跨職能是團隊層面的概念，而一專多能是每一個團隊成員層面的概念。如今回過頭來看，發現曾經團隊在嘗試SCRUM的過程當中，對有些方面是理解得不夠的，包括爲何最終團隊放棄了SCRUM轉向看板，其原因也不徹底是曾經覺得的迭代週期的問題，須要系統的來看待這個問題。無論一套理論是如何的完善，結合到實際的工做中的時候總會遇到這樣和那樣的問題，但抓住最本質的東西纔是最重要的，抓住其精髓的部分，而後再加以靈活應用，以問題爲出發點，可以真正的解決實際的問題才能給你們帶來信心。

 

    我所在的團隊有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是團隊的保護傘。

    敏捷開發系列文章目錄