為什麼說Scrum並不適用於軟體開發？

接收程序員的技術早餐

作者 | Adam Ard

編輯 | Alice

1、由於全部產品決策權皆歸「產品擁有者」所有，因此 Scrum 不允許工程師們在產品方向的各個層級當中作出任何產品決策，且嚴格控制其產品管理權。

2、Scrum 以緊密管理方式佔用了工程師們的全部時間，因此會阻礙大多以自發形式出現、且無法匹配任何具有良好可預測性的時間表或系統的創新活動。

3、Scrum 鼓勵「儘可能減少工作量」類解決方案，旨在滿足嚴格的可預測性要求。

4、通過將每項任務拆分成理論上可由團隊中任何成員完成的小型項目，Scrum 實際上並不鼓勵工程師們對自己的工作內容形成自豪感或所有權。這種所有權的缺失將導致：

設計質量低下

缺少動機（『這不是我的東西』、『我剛接手的時候就有問題』）

5、Scrum 對修改任務極度不友好，而這一理念的支持者們在實現當中往往採取全有或全無的態度。

「Scrum 的角色、工作內容、事件以及規則是不可改變的，且儘管可以僅採用 Scrum 的部分理念，但結果卻與 Scrum 無關。Scrum 只存在於其中 ，並充當其它技術、方法及實踐的容器。」

6、Scrum 對於自我反省的低容忍態度貫穿於其全部實踐當中。只有在 Scrum 框架內部運行的流程才能夠進行修改——而就 Scrum 本身而言，其基本規則可謂「神聖不可侵犯」。

7、Scrum 是一種重度管理工具。典型的團隊當中需要具備產品擁有者、Scrum Master 以及團隊負責人。但實際上，創新且積極的團隊要求更少干涉、更好管理——Scrum 顯然恰恰相反。

8、Scrum 通常使用非常差勁的任務管理工具（例如 Jira、tfs 等等），這些工具會對 Scrum 的執行作出非常官僚化的解釋，因此導致開發人員的時間被大量浪費。此外，無論效能多麼低下，Scrum 都會將工程師們牢牢鎖定在這一種運營模式當 。

9、Scrum 不鼓勵修正 bug、減少技術債務或者冒險，這是因為其極為狹隘地僅關注執行產品負責人認為有價值的項目。

經理或產品擁有者往往並沒有對所開發的產品進行全程追蹤及評估，也很少提供指導性意見。

並未要求他們以每兩周一次的頻率組織會議以證明當前工作的正確性。

並未要求他們提供詳盡圖表以證明目標是否已經階段性完成。

11、Scrum 作出大量錯誤的假設：

其假設工程師們不具備任務追蹤系統（但實際情況恰恰相反），因此需要時間管理手段以約束其時間分配方式。

其假設工程師們無法指導自己的工作內容。

其假定工程師們在未經嚴格監督的情況下，無法與組織的最佳利益保持一致。

其假設工程師們無法在缺少協調員（Scrum Master）的前提下高效進行會議討論。

其假設可以通過在衝刺階段 / 庫存清理階段通過討論規劃軟體任務中的各方面問題。

其假設所有工程師都以同樣的方式工作。

12、Scrum 故事點被廣泛認定為毫無意義，但其仍在組織內的各個層級中被加以追蹤、記錄與展示，且繼續作為團隊績效的惟一指標（即速度）。

13、Scrum 的設計目標在於管理能力最為低下的工程師，但這會令更傑出的人才遭到束縛。

14、Scrum 與初始敏捷宣言中提出的許多觀點正好相反：

個人與流程及工具間的相互作用

通過全面的文檔進行軟體構建

通過合同談判實現客戶協作

根據計劃作出變更回應

15、Scrum 忽略了一項事實，即軟體開發領域當中任何已經完成的任務皆可以復用方式再次起效，而無需重新構建。這意味著在 Scrum 的範圍之內，任何新的軟體任務都屬於從零開始的工作，導致我們很難對其加以預估。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！