如何跟蹤項目進(jìn)展，了解團(tuán)隊生產(chǎn)率，分析千行代碼缺陷率等，相信對于一個PM來說，PV, EV, SV, CV, Defect Density等這些概念都是爛熟于胸的，然而對于Scrum的PM，面臨的困境是，項目開始的時候，要開發(fā)的產(chǎn)品沒有明確的需求和時間軸，手頭拿到的只是一個High Level的Product Backlog，PM甚至不知道6個月后這個Backlog會不會面目全非。顯然，傳統(tǒng)的管理方式是很難讓人客觀了解項目的進(jìn)展并評價項目。為了客觀評價一個Scrum團(tuán)隊的承載力和效率，點融黑幫今天給大家提供幾個容易上手的度量標(biāo)準(zhǔn)和追蹤的方法，簡單快速幫助大家評價和管理一個Scrum團(tuán)隊。

Velocity （已經(jīng)完成的故事點！）

好吧，我們說的是在一個Sprint中已經(jīng)徹底完成的故事點，沒有Defect，不是部分完成的，而是真正的已經(jīng)把User Stories轉(zhuǎn)化為已經(jīng)生產(chǎn)運行的軟件的大小（點數(shù)）。

什么？已經(jīng)被解決的Defect算不算，你覺得你去4S店買了輛車發(fā)現(xiàn)雨刮器噪音太大，結(jié)果人家?guī)湍阈藓昧藛柲阋蘩碣M，你會給嗎？ 只有真正完成并交付使用的功能才被記錄成為某個Sprint的Velocity，它代表的是一個Scrum團(tuán)隊真正的速率。

哦，對了，正規(guī)的項目交付中，我們還分為已完成的Velocity和被接受的Velocity，前者是團(tuán)隊的認(rèn)知，而后者是PO的認(rèn)知，如果兩個值不一樣，恭喜你，你有了一個Impediment。此外，請注意，我們計量的單位是故事點，而不是人天，工作小時或者其他什么，若干個Sprint的ramp up以后，我們希望Velocity和股票一樣漲漲漲！

下一個Sprint的承載力（這個單位是人天?。?/h3>

如果你不知道在下一個Sprint你有多少人能有多少時間為你的項目工作，那你自己就是一個Impediment，從趨勢角度來說，我們希望看到的是一個穩(wěn)定的承載力，任何不穩(wěn)定的變化，即便是承載力的上升，也未必對團(tuán)隊的速率和質(zhì)量有好處。

如果一個團(tuán)隊成員有20%投入在你的項目上，是否應(yīng)當(dāng)疊加他的人力呢，我的答案是否，試想你每天要花人力到處去找他，找到他也不一定能持續(xù)性的解決問題，天知道到底是加強(qiáng)團(tuán)隊承載力還是削弱，這些人有時候也許能解決大問題，但如果我是你，我會在管理成本和Impediment里都記上一筆。和Velocity不同的是，有時候我們并不喜歡這個值漲漲漲，我們更喜歡看到穩(wěn)定的趨勢，否則，你需要正視這個Impediment。

下一個Sprint的承載力（這回說的是故事點啦！）

如果你跑了5個Sprints，發(fā)現(xiàn)Velocity漸漸穩(wěn)定在50左右，這時候，你就可以根據(jù)50故事點這個數(shù)字作為你團(tuán)隊交付能力的一個重要參照，也可以成為你未來項目走向和預(yù)判的一個重要數(shù)據(jù)支撐。

在Sprint Planning Meeting上，你的團(tuán)隊成員會承諾在下一個Sprint中完成多少個Story Points，如果累計的數(shù)字和50相差甚遠(yuǎn)，你最好問問團(tuán)隊，哪里出了問題。記錄每個Sprint Planning中得出的預(yù)估完成故事點的數(shù)量，將他們和Velocity表對比，你就知道哪里出了什么問題。

Sprint中的范圍蔓延 （你最好問問你的PO!）

你需要了解每個Sprint中增加/減少的Story Point，甚至是增加/減少的Story，我們希望這樣的變化趨于0，但我們可以接受一定范圍內(nèi)的增加，但當(dāng)這種趨勢越來越不可控的時候，你最好問問你的PO，因為他看起來是你團(tuán)隊最大的Impediment。

分析問題，解決問題 (二八法則！)

如果你信奉二八法則，你可以試試帕累托分析來分析問題和解決問題，找到你的defect，通過魚骨圖找到造成問題的原因并記錄下來，你會很快發(fā)現(xiàn)你80%的defect是由20%的原因造成的，解決了20%的Root cause，80%的問題將迎刃而解，是不是很酷。

Sprint的成功或失敗 （直面成功或者失敗！）

每個Sprint都應(yīng)該有一個準(zhǔn)確的結(jié)果定義，成功或者失敗，不存在接近成功或者有些失敗。你可以定義成功的標(biāo)準(zhǔn)，按時交付，按質(zhì)交付，成本的控制，但重要的不是定義成功或者失敗的指標(biāo)，重要的是給團(tuán)隊一個Sprint結(jié)束后的準(zhǔn)確評價，如果一個Sprint獲得了失敗的結(jié)果，那么每個團(tuán)隊成員在評審會議中都應(yīng)該找到解決辦法，期望下一次可以獲得成功。讓你的團(tuán)隊產(chǎn)生對成功的渴望，追逐每一個Sprint的完美交付，如果你沒有這么想，那么你就是那個Impediment。

小結(jié)

這些指標(biāo)和分析給誰看，給Senior Management Team？不不不，他們只想知道你的項目是不是紅色，即便是橙色預(yù)警，他們也默認(rèn)你的團(tuán)隊可以自行解決。這些信息應(yīng)該給到你的Scrum團(tuán)隊，讓他們知道發(fā)生了什么，是否存在問題，發(fā)生問題的原因是什么，最終幫助解決問題，快速成長和提高。 當(dāng)然，如果你的團(tuán)隊缺乏足夠的自我約束力，足夠的工作積極性，你最好檢討下是不是面試環(huán)節(jié)出了問題 lol。

本文由點融黑幫 @Richie Zhang 原創(chuàng)投稿，并經(jīng)人人都是產(chǎn)品經(jīng)理編輯。未經(jīng)許可，禁止轉(zhuǎn)載。