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

　　問題1-Scrum模糊

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

一個框架，人們可以在其中解決復雜的適應性問題，同時以富有創造力的方式交付最高價值的產品。

更簡潔地說：

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

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

　　問題2-“沖刺”

根據官方指南：

Scrum的核心是Sprint，即一個月或更短的時間范圍，在此期間創建“完成”，可用且可能發布的產品增量

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

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

短跑需要可實現的短期目標。假設我是一個進行兩周沖刺的團隊的一員（因為持續時間必須保持一致），并且我被分配去構建一個直到完成所有事情才有用的API。也可以說，在我的腦海中，我相信如果我能始終如一地工作，整個任務將花費兩個月。

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

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

　　問題3-Scrum Master

Scrum Master是Scrum團隊的仆人領導。Scrum Master幫助Scrum團隊之外的人員了解他們與Scrum團隊的哪些互動是有幫助的，哪些沒有幫助。

根據Scrum Master想法的實現方式，它可能是壞主意，也可能是更糟的主意。讓我們談談我看來最常見的情況。

Scrum Master是一種非技術性的，中層管理的類型，喜歡負責一些事情。

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

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

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

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

　　問題4-估算

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

問題在于，實際中的估算是現實的混蛋。Scrum指南在該主題上含糊不清，因此管理人員可以自己處理問題?？紤]到這一點，我將再次批評一些關于估算的常見做法。

　　斐波那契和T恤尺寸

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

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

　　這里的分數是多少？

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

我最終了解了實際的系統。

1分：0-8小時

2分：8小時-2.4天

3分：2.4天-1周

5分：1周-1.5周

8分：2周

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

使用這種野蠻簡單的系統的普遍反對意見是：

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

為此，我建議基于您首先關心的規模time的 base-2取冪。

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

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

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

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

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

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

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

最后說明：敏捷！= Scrum

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