寫在前面
曾經(jīng)有個聾子看人放炮仗，說，怎么好好地一個花紙卷，放地上，一會兒說散就散了呢？因為他的感官缺少了一個維度，因此他沒有辦法理解爆竹怎么引爆的。
作為PM，你在生活中可能是一個特別二的人，但是項目中你只能敏感。
“聾子系列”一共三部分：
“信息透明”部分集中說一下如何發(fā)現(xiàn)、解決信息不透明的問題；
“微調(diào)”部分說的是，進入項目組以后，如何逐步調(diào)整自己和團隊；
“檢驗”部分說的是，敏捷項目中的項目檢驗指標；
透明、微調(diào)適應、檢驗。你覺得這三個關鍵詞還用在哪兒了？
檢驗
檢驗并不是什么高科技的詞，其實我們身邊充滿了檢驗。“檢驗”通俗的說就是“合格標準”，有很多事情可能你都想不到那個就是“檢驗”，比如：
賽跑，誰跑得快誰贏，怎么檢驗？弄根繩子橫終點，誰先拿肚子頂上，誰贏；
跳高，誰跳的高誰贏，怎么檢驗？弄個桿子架起來，誰先拿屁股碰掉，誰輸；
想象一下啊，賽跑發(fā)令槍響了以后，一伙子人即使不知道怎么算贏，但是仍然人人爭先恐后；另一伙子人努力的助跑，往墊子上摔，墊子前面既沒有裁判，也沒有桿子，但是那伙子人還是興奮的不行。
這不有病么？這可能么？
那么憑什么做項目的時候就可以沒有檢驗，卻期望每一個人跟打了雞血似的干活呢？
檢驗，不僅得有，而且得讓所有人都知道，得讓所有人都能靈活了解。舉個例子啊，問一個賽跑運動員“如果組委會找不到繩子放在終點怎么辦？”，他可能一下傻了，拍著腦袋說“我去，這問題老大了。。?！泵?？
但是，如果你拉住一個PM，問他“如果客戶又提了很多新需求”或者“如果團隊主力病倒了”，再或者“如果BA和Developer對于標準不統(tǒng)一了”怎么辦，他還真的有可能傻了，拍著腦袋說“我去，這問題老大了。。。”
這些看似“老大”的問題，都和“檢驗”相關，聽我細說說。
首先，ATDD是指導思想
全稱是Acceptance Test Driven Development。為什么加上個A呢？用TDD不是挺好的么？加上A以后，更能夠說明和強調(diào)這不是一個技術手段，是項目管理手段。而TDD僅僅是ATDD用到的一種技術實踐。
ATDD這個東西，用極端的話說：所有的模塊都是為測試而開發(fā)的。以這個思想為指導，在所有模塊構建的時候，就應該想好了怎么測試。換句話說，作為一個開發(fā)，如果你發(fā)現(xiàn)你即將要做的功能自己都不知道怎么做成自動化測試的，說明你沒想好，或者BA給你的就是一個“假功能”。那就放下鍵盤，先找BA畫邏輯圖吧，肯定你的理解不全面。
有了ATDD指導思想以后，下面的這些是方法：
code review、Retro
知道這兩個活動的人可能會奇怪，為什么把這兩個看似不相關的東西放在一起說呢？其實仔細想想啊，他們的作用是一樣的，只不過Code review是給技術宅準備的；retro是給項目組準備的（當然也包括技術宅），他們的作用都是回顧過去，找到問題，找到現(xiàn)行和標準之間的差異，討論改進辦法；
kick-off meeting、sign-off、show case、CI
如果說code review和retro是概念性的和粗粒度的，那么這四樣東西就是更加具體的行動和做法。
首先，每一個iteration開始的時候，都要有Kick-off meeting，在這個會議上，BA講解這個迭代中的全部故事卡，PM將這個迭代的目標與大家討論，達成一致。這就好比賽跑中告訴運動員“看見前面的繩子沒有，誰先拿肚子頂上誰贏”；
然后，在這個Iteration結(jié)束的時候，所有的故事卡BA都應該已經(jīng)sign-off了，每一個故事卡完成以后，BA都要確定“按照要求”完成了，這就好比沖過終點后，運動員們對于名詞有了認可；
接著，show case meeting，在這個會議上，項目組把產(chǎn)品增量給客戶演示，得到客戶的反饋。這就好比裁判最終認可了比賽成績；
最后一個，CI。CI是個啥，CI是Continuous integration的縮寫，是一種方法，CI可以保證每一次提交都不會破壞整體的功能，還記得上面提到的TDD么？只有用了TDD以后，CI server才可以完成自動編譯、測試、打包等事情，保證一切順利。
Story card & Planning Wall
這兩個東西也必不可少，他們是一個項目的全部載體，在以前，項目的需求“藏”在電腦的某個深層的目錄的文檔里（除了島國片你可能藏得更深之外，很難再找到藏得更深的東西了）；項目的計劃藏在甘特圖里面，這個漂亮、光鮮的圖雖然隨時可用，但是受到責難的苦主一般第一句話就是：這是個“假計劃”，情況變了，這個計劃是2個月以前的，現(xiàn)在早變了。而此時，PM除了后悔自己沒有“及時”修改甘特圖之外，還后悔自己沒有早點兒認識黑社會的打手。
敏捷開發(fā)是怎么解決這個問題的呢？用故事卡，故事卡就是需求，既有描述又有測試標準，團隊每天的工作就是圍著這些故事卡。Planning Wall就是貼滿了這些卡的一面墻，誰說文檔就一定要在電腦里面，我邊上這堵墻就不能當成一個文檔么？
最后，我們說一下：Velocity Estimation
在軟件項目中，最難做的“檢驗”的事情，恐怕就是團隊的產(chǎn)能了。
我們都知道，在付錢的時候，人總會問一句：多少錢？
比如你想買一個電腦，銷售會說我這里有10種，價格從3千到3萬塊，相同的電腦我這里的價格不算貴；
比如你想買個房子，銷售會說這個房子每平米6萬，按照建筑面積算，公攤小，我這里的價格不算貴；
那憑什么客戶想做一個軟件的時候，人問多少錢，我們就忸忸怩怩的呢？
這又涉及到另外一個問題：你一天吃幾碗干飯？
人，最可貴的品質(zhì)就是知道自己吃幾碗干飯。作為一個PM，你除了要知道你自己，還要知道團隊能吃幾碗干飯。我們先不展開說，就說這個比喻：“干飯”，你是不是需要知道“多大的碗”，“飯有多干”？這些是外部的關鍵點，你是不是還需要知道“自己當時餓不餓”、“有沒有好菜”這類的內(nèi)部關鍵點？
單說“干飯”這事，你就已經(jīng)評估不出來了。何況更加復雜的團隊產(chǎn)能估計（Velocity Estimation）。
不過，敏捷項目管理還真的有招：用“故事點”評估。（這篇文章說的是“檢驗”，所以評估方法就不細說了，想聽的話，留個言啥的，我單寫一個文章說“敏捷團隊產(chǎn)能評估”）
每個迭代以后，PM都會得到一個新的以故事點為單位的團隊產(chǎn)能，PM要做的就是拿這個與以前的比較、預估，得到一個最新的“更準點兒”的產(chǎn)能數(shù)據(jù)，用于衡量下一個迭代。如果項目的時間很長，比如1年（24個迭代），那么在7，個迭代以后，就應該可以得到相對準確的產(chǎn)能，PM也能拍著胸脯應對客戶的這類問題了，因為他會了“檢驗團隊產(chǎn)能”。
更多文章，去《藝術家死得福》
