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

　　問題1-Scrum模糊

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

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

更簡潔地說：

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

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

　　問題2-“沖刺”

根據(jù)官方指南：

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

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

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

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

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

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

　　問題3-Scrum Master

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

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

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

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

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

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

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

　　問題4-估算

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

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

　　斐波那契和T恤尺寸

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

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

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

Scrum master：“斐波那契，最高為8分，因為我們將其定義為開發(fā)人員在兩周的沖刺中可以處理的工作量”。

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

1分：0-8小時

2分：8小時-2.4天

3分：2.4天-1周

5分：1周-1.5周

8分：2周

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

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

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

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

1、2、4、8。小時，天或周。

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

如果估算是基于可測量的時間，那么工程師如果錯過估算，就會覺得自己搞砸了。

好的一點(diǎn)是，估算很困難，我們不希望任何人僅僅因為他們不是理想的估算員而覺得自己是一名糟糕的工程師。就是說，也許不是開始游戲“反正是誰的線?”

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

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

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

最后說明：敏捷！= Scrum

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