基於story的敏捷基礎知識----需求管理（三）

（3）每日站會

站會的目的有三個：

（1）周知進度

僅從使用者故事和任務的層面周知進度，任務進度只有兩種狀態：完成或未完成（完成百分比）。

（2）周知計劃

你將會在下次會議之前做哪些工作？

（3）丟擲問題

哪些東西阻礙你的進度？（“沒有問題”，意味著你能夠交付自己當前的任務，而且符合估算的時間範圍）如果遇到需要解決的問題，可以在每日立會之後處理。

實現一專案的必要前提：

1.站

2.敏捷專案必須提供能夠“安全失敗”的環境，團隊成員不會因為沒有達成任務承諾遭受懲罰。

大家要能夠安全說出任務狀態的真實情況，並且瞭解專案環境的現實情況。有時，我們的估算可能很糟糕（只是估算

站會的主要內容：

從PM、RD到QA，每個人發言，內容為：1. 昨天干了什麼，2.遇到什麼問題，3.今天準備幹什麼。如果有想要分享給大家的知識，也可以在此分享。

最後主持人總結一下，然後根據實際遇到的問題，少數人進行線下溝通、跟進、解決。

站會的時間儘量控制在十分鐘左右。

開站會的一些技巧

（a）輪流主持

輪流主持能提高團隊成員的參與度，且如果主持人臨時有事，也不會因此無法開展，通常每次站會結束時指定下次站會的主持人。

（b）解決問題不放在會議中

會議中僅丟擲問題，解決問題放在站會結束後，相關人蔘與。目的是避免浪費大家的時間。

（c）早上舉行

可以讓所有人按時來，按時工作。

可以讓每個人更清楚今天自己該幹什麼。

晚上每個人進度不一，作息時間不一樣，早上說昨天干了什麼更準確。

（4）卡片牆

有了迭代的總體計劃，還需要細化到對每個story進行管理，除了之前的估點外，我們使用卡片牆對其進行管理。

卡片牆如下圖所示：

需求池：所有新建的story（一般為未經過估點的）卡片貼在此處。

待開發：所有待開發的story卡片貼在此處。

需求池->待開發：講解溝通完需求、估完點、補充完驗收標準後，移動

開發中：所有正在開發的story卡片貼在此處

待開發->開發中：RD將story拆分完task，並給QA講解task實現思路，QA同意後，移動。

待測試：所有開發完成，等待QA測試的story卡片貼在此處。

開發中->待測試：RD開發完成story，且完成單測、整合測試編寫，和經過仔細的自測後，移動。

測試中：所有QA正在測試的story卡片貼在此處。

QA singn off：所有經過QA測試，QA認為可以上線的story卡片貼在此處。

測試中->QA singn off：QA經過仔細測試，bug都被修復驗證，認為story符合上線標準時，移動。

已驗證：所有經過PM驗收，可上線的story卡片貼在此處。

QA singn off->已驗證：PM在驗收環境中驗收，認為符合需求後，移動。

加速區：所有需要加速解決的story卡片貼在此處。如卡片中有block測試的bug急需修復，等。

block區：所有被一些問題block的story卡片放在此處。

卡片：story卡、task卡（story編號、估點數、使用者故事）。

角色卡：FE、RD、QA的名字，以不同顏色區分，分別寫上人名，用於貼在story上。誰在做什麼，誰忙誰閒，有多少剩餘人力，一目瞭然。

上線時間：略。

（5）燃燒圖

使用燃燒圖，計劃及其變化，以及每天進度一目瞭然。

燃燒圖如下：

1、X軸為時間，一般是迭代週期的每一天；

2、Y軸為工作量，根據專案情況，可以用已完成估點或已完成story點數來表示；

3、最開始，計算出本次迭代要完成的所有工作量(作為y軸刻度，迭代天數作為x軸刻度)，然後，每天站立會議時，瞭解前一天已經完成的工作量，並計算出迄 今為止完成的工作總量。把其畫在Y軸上，以此類推(並把y點連線成線)。如果計劃比較(理想)準確，燃燒圖的最後一天”燃燒“折線將和總工作量折線相交；

（6）總結

以上五項，簡單易實現，用很低的時間成本就能做出“計劃”，並保證計劃的落實，且能快速適應變化！