Scrum是一個(gè)流行語，是軟件組織中層管理人員選擇的美德信號。如果您作為經(jīng)理的目標(biāo)是實(shí)現(xiàn)一個(gè)系統(tǒng)，您可以：加快進(jìn)度的出現(xiàn)、支付兩倍于您所需人數(shù)的費(fèi)用、根據(jù)無意義的指標(biāo)收集細(xì)粒度的數(shù)據(jù)。然后，在Scrum中我們先來就簡單的舉個(gè)例子： “哦，您上一個(gè)雇主在Scrum上遇到了問題嗎?嗯，那不是真正的Scrum。”您的Scrum主管，他不是真正的蘇格蘭人不用說，我們不在Qvault使用scrum 。這給我們帶來了第一個(gè)問題...

　　問題1-Scrum模糊

很難批評Scrum。我腦海中的“ Scrum”想法可能與您熟悉的想法大不相同。這是設(shè)計(jì)使然，也因錄取而定。在官方的《Scrum指南》中，我們找到了Scrum的定義：

一個(gè)框架，人們可以在其中解決復(fù)雜的適應(yīng)性問題，同時(shí)以富有創(chuàng)造力的方式交付最高價(jià)值的產(chǎn)品。

更簡潔地說：

Scrum(名詞)-1. [軟件]任何運(yùn)行良好的良好過程

因?yàn)槎x太含糊，所以我在接下來的文章中唯一可以批評的就是我所熟悉的“ Scrummers”的常見做法。希望你們中的一些可愛的讀者可以建立聯(lián)系。

　　問題2-“沖刺”

根據(jù)官方指南：

Scrum的核心是Sprint，即一個(gè)月或更短的時(shí)間范圍，在此期間創(chuàng)建“完成”，可用且可能發(fā)布的產(chǎn)品增量

沖刺是有用的，就像電子游戲中的成就是有用的;它們使我們內(nèi)心感到溫暖和模糊。動(dòng)機(jī)是一個(gè)強(qiáng)大的工具，請不要誤解我。問題在于，那些熱烈的毛病主要是為了管理團(tuán)隊(duì)。這使他們感到有控制權(quán)并了解情況。他們確切地知道完成了什么以及何時(shí)完成。

我不反對通知管理人員…… 但是要付出什么代價(jià)？

短跑需要可實(shí)現(xiàn)的短期目標(biāo)。假設(shè)我是一個(gè)進(jìn)行兩周沖刺的團(tuán)隊(duì)的一員（因?yàn)槌掷m(xù)時(shí)間必須保持一致），并且我被分配去構(gòu)建一個(gè)直到完成所有事情才有用的API。也可以說，在我的腦海中，我相信如果我能始終如一地工作，整個(gè)任務(wù)將花費(fèi)兩個(gè)月。

我需要將API分成可以2周為增量完成的部分。我也許可以在一兩天之內(nèi)完成一些端點(diǎn)，但是我不想錯(cuò)過任何目標(biāo)，而且我知道一些較困難的邏輯可能要花費(fèi)整整一周的時(shí)間每個(gè)端點(diǎn)。有14個(gè)端點(diǎn)，因此我決定每個(gè)沖刺2個(gè)端點(diǎn)的整數(shù)。

一個(gè)本來可以在2個(gè)月內(nèi)完成的API 現(xiàn)在將花費(fèi)將近4個(gè)月，因?yàn)槲依速M(fèi)了沿途添加人工停止點(diǎn)的時(shí)間。我的冒名頂替綜合癥開始出現(xiàn)，但至少管理層會(huì)有不錯(cuò)的燃盡圖。

　　問題3-Scrum Master

Scrum Master是Scrum團(tuán)隊(duì)的仆人領(lǐng)導(dǎo)。Scrum Master幫助Scrum團(tuán)隊(duì)之外的人員了解他們與Scrum團(tuán)隊(duì)的哪些互動(dòng)是有幫助的，哪些沒有幫助。

根據(jù)Scrum Master想法的實(shí)現(xiàn)方式，它可能是壞主意，也可能是更糟的主意。讓我們談?wù)勎铱磥碜畛Ｒ姷那闆r。

Scrum Master是一種非技術(shù)性的，中層管理的類型，喜歡負(fù)責(zé)一些事情。

除了他們所有的開發(fā)工作之外，工程師現(xiàn)在還經(jīng)常被Scrum主管打斷，后者要求什么時(shí)候完成React應(yīng)用程序的“ Java代碼”。

旨在阻止外界打擾開發(fā)人員的個(gè)人是最大的麻煩。我認(rèn)為，非技術(shù)人員很少（如果有的話）管理技術(shù)人員（CEO除外）。我應(yīng)該能夠向上司尋求有關(guān)我的任務(wù)的幫助和建議，或者至少我應(yīng)該期望他們能理解我的任務(wù)。

即使Scrum Master是一個(gè)可愛的人，從高層次上掌握技術(shù)問題，Scrum Master也不是一個(gè)全職工作。Scrum Master的日常任務(wù)通常涉及早上一兩口的站立，下午與上級的會(huì)議，等等。

如果您仍然需要“ Scrum Master”，則讓首席開發(fā)人員來處理。他們已經(jīng)站起來，可能會(huì)對發(fā)生的事情有更好的了解。您不會(huì)在他們的盤子上放更多東西，您可能會(huì)摘下一些東西。

　　問題4-估算

在Scrum中，估算的主要目的是-確定團(tuán)隊(duì)在給定的sprint中可以完成多少工作。如果我同意Sprint是個(gè)好主意（我顯然不相信），那么官方Scrum指南中對估算的描述就不會(huì)有問題。

問題在于，實(shí)際中的估算是現(xiàn)實(shí)的混蛋。Scrum指南在該主題上含糊不清，因此管理人員可以自己處理問題。考慮到這一點(diǎn)，我將再次批評一些關(guān)于估算的常見做法。

　　斐波那契和T恤尺寸

許多超級公司組織喜歡使用最令人困惑的量表進(jìn)行估算。他們聲稱，這使估算速度更快，壓力較小。我仍然深信不疑。

我在新公司的第一天，在我們的估算會(huì)議上，聽說他們使用了可怕的“故事積分”系統(tǒng)：

　　這里的分?jǐn)?shù)是多少？

Scrum master：“斐波那契，最高為8分，因?yàn)槲覀儗⑵涠x為開發(fā)人員在兩周的沖刺中可以處理的工作量”。

我最終了解了實(shí)際的系統(tǒng)。

1分：0-8小時(shí)

2分：8小時(shí)-2.4天

3分：2.4天-1周

5分：1周-1.5周

8分：2周

估算的最終目標(biāo)是將工作量->時(shí)間轉(zhuǎn)換為。為什么我們需要增加工作量->故事點(diǎn)->時(shí)間?簡單估算“多少天?” 本來可以更容易地思考和推理，同時(shí)還可以提供更多的粒度。

使用這種野蠻簡單的系統(tǒng)的普遍反對意見是：

我們使用斐波那契是因?yàn)楹茈y想象7天和8天之間的差異。沒有人能對此做出精確估計(jì)。斐波那契數(shù)列的每一步都會(huì)增加約60%，因此您不必被迫非常接近您的估計(jì)。

為此，我建議基于您首先關(guān)心的規(guī)模time的 base-2取冪。

1、2、4、8。小時(shí)，天或周。

看來我們已經(jīng)解決了問題!直到另一個(gè)好主意的Scrum管理員開始：

如果估算是基于可測量的時(shí)間，那么工程師如果錯(cuò)過估算，就會(huì)覺得自己搞砸了。

好的一點(diǎn)是，估算很困難，我們不希望任何人僅僅因?yàn)樗麄儾皇抢硐氲墓浪銌T而覺得自己是一名糟糕的工程師。就是說，也許不是開始游戲“反正是誰的線?”

可以設(shè)定合理的期望，即估算值就是估算值。

估計(jì)-粗略計(jì)算或判斷其價(jià)值，數(shù)量，數(shù)量或范圍。

如果估算結(jié)果很差，則可以在不損害估算器的情況下重新估算。

最后說明：敏捷！= Scrum

我喜歡敏捷方法論和敏捷宣言。我不是Scrum的粉絲。在以后的文章中，我計(jì)劃在仍然運(yùn)行“敏捷”組織的同時(shí)，重新思考如何代替Scrum。想了解更多關(guān)于Scrum的信息，請繼續(xù)關(guān)注中培偉業(yè)吧。