人人都是Scrum Master:對(duì)于Scrum團(tuán)隊(duì),PM應(yīng)該從何下手

2 評(píng)論 14104 瀏覽 38 收藏 8 分鐘

如何跟蹤項(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和股票一樣漲漲漲!

1.webp

下一個(gè)Sprint的承載力(這個(gè)單位是人天!)

如果你不知道在下一個(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。

2.webp

下一個(gè)Sprint的承載力(這回說(shuō)的是故事點(diǎn)啦?。?/h3>

如果你跑了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)題。

3.webp

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。

4.webp

分析問(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)題將迎刃而解,是不是很酷。

5.webp

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。

6.webp

小結(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)載。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 此文嚴(yán)格來(lái)說(shuō)應(yīng)是“原創(chuàng)翻譯”吧?語(yǔ)句明顯翻譯風(fēng)??!

    來(lái)自北京 回復(fù)
    1. 一頭霧水進(jìn)來(lái),一頭霧水出去

      來(lái)自四川 回復(fù)