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

Velocity （已經(jīng)完成的故事點(diǎn)?。?/h3>

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

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

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

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

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

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

下一個(gè)Sprint的承載力（這回說(shuō)的是故事點(diǎn)啦！）

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

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

Sprint中的范圍蔓延 （你最好問(wèn)問(wèn)你的PO!）

你需要了解每個(gè)Sprint中增加/減少的Story Point，甚至是增加/減少的Story，我們希望這樣的變化趨于0，但我們可以接受一定范圍內(nèi)的增加，但當(dāng)這種趨勢(shì)越來(lái)越不可控的時(shí)候，你最好問(wèn)問(wèn)你的PO，因?yàn)樗雌饋?lái)是你團(tuán)隊(duì)最大的Impediment。

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

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

Sprint的成功或失敗 （直面成功或者失?。。?/h3>

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

小結(jié)

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

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