Scrum是脆弱的，不敏捷的

正如標題所示，這篇文章是關於 Scrum 的兩個不一樣方面。第一部分涉及 Scrum 不敏捷，第二部分涉及 Scrum 脆弱。

在詳細介紹以前，簡短的免責聲明：我在這篇文章（以及通常博客中）中提出的全部內容都是我我的觀點，並不表明我現任僱主，個人前僱主和任何將來僱主的觀點。

Scrum 是不敏捷的

我猜人們對這個標題的典型反應會是「這怎麼可能？ Scrum 不是敏捷的？Scrum 不是第一個敏捷軟件開發過程嗎？」 簡而言之，Scrum 聲稱是一個敏捷的過程，但使人遺憾的是，Scrum 離敏捷還很遠。我會告訴你緣由。

咱們快速瀏覽敏捷宣言。它說它重視「我的和交互而不是過程和工具」。讓咱們快速瞭解一下敏捷這個詞的含義。根據牛津詞典，敏捷的意思是「可以快速、輕鬆地行動」。選擇敏捷這個術語來表明敏捷宣言中的高級思想並非一個巧合。事實上，敏捷背後的一個主要觀點是，在許多軟件項目中，快速而簡單地移動是極其困難的。對於一個全新的項目來講，狀況並不是如此，但隨着時間的推移，許多項目進入了一種根本不可能實現可持續發展的境地。爲了防止這種狀況(和其餘問題)，敏捷宣言和敏捷宣言背後的原則提供了幾個高級指南。這些指導方針不是特定定義良好的流程或工具，它們容許許多不一樣的實現。我懷疑這兩個屬性(高級的和容許不一樣的實現)都是徹底有意的。整體目標不是提供靈丹妙藥，而是幫助同行避免軟件開發中的許多陷阱，敏捷宣言的做者親身體驗過這些陷阱，而這些陷阱剛好屬於這些類別。

如今讓咱們來看看 Scrum指南 （由敏捷宣言的兩位做者編寫）。與敏捷宣言和敏捷原則相比，本指南彷佛至關冗長。使人驚訝的是，整個指南一次都沒有提到敏捷。我不肯定歷史上是否老是這樣，可是若是 Scrum 指南的做者不聲稱 Scrum 是敏捷的，那麼咱們已經完成了這個博客文章的第一部分。我想狀況並不是如此，因此咱們繼續。 Scrum 指南是關於一個包含「角色、事件、工件和將它們綁定在一塊兒的規則」的框架。換句話說，這是一個很是具體和明確的過程。這聽起來既不敏捷，也不敏捷（記住：「我的和過程和工具之間的交互」）。這是很是諷刺和明顯的。這就是整個 Scrum 運動應該中止的地方。但它沒有，反而讓世界各地愈來愈多的軟件開發人員感到沮喪。每當一個 Scrum 項目失敗，並非由於 Scrum 潛在的缺陷，而是由於 Scrum 沒有正確實現。這聽起來是一個很好的過渡到這篇文章的第二部分。

Scrum是脆弱的

這部分很短。我認爲 wordplay （Scrum being agile / fragile）頗有趣，除此以外，它完美地描述了 Scrum 真正困擾個人一件事:每當 Scrum 項目失敗時，都是由於 Scrum 沒有獲得正確的實現。你能夠閱讀大量這樣的項目。若是大量的智能軟件開發人員不能正確地實現 Scrum，這意味着什麼?這意味着整個框架是脆弱的。這是反對使用 Scrum 的另外一個主要論點。若是它很難使用，那麼什麼是適合的框架？

好吧，彷佛在昂貴的諮詢和指導，以及培訓和證書的幫助下，Scrum 實際上可能提供價值。 但目前尚不清楚這對於軟件開發公司以及辛勤工做的軟件開發人員或那些在 Scrum 生態系統內部和周圍提供服務的人來講是否有價值。

我的觀點

最後，我想談談我我的對軟件開發、敏捷和 Scrum 的見解。在我看來，高質量軟件開發的一個很是重要的部分是維護一個簡單的優先級任務隊列。權重是任務爲客戶/開發人員提供的價值和實現該任務的估計工做量的組合。有些開發人員天生就會這樣。對於不屬於這種狀況的團隊和公司，Scrum 提供了一個至關昂貴和低效的優先隊列實現。坦白的說吧。軟件開發是一項很是困難和複雜的工做。這麼多項目都失敗了，咱們真的感到驚訝嗎?這個領域還很年輕，咱們須要學習不少東西。這一點相當重要：咱們須要從過去的經驗中學習，不論是失敗仍是成功的故事。在這裏，咱們都失敗了。咱們沒有使用錯誤的流程或以錯誤的方式實現正確的流程。咱們只是陷入了一場激烈的競爭，沒法短暫地休息一下，去看看周圍發生的一切，從中學習，甚至是在咱們這個時代以前。咱們的職責是從咱們很容易得到的許多資源中提取知識、經驗和智慧：許多有關軟件開發的書籍、文章和視頻，最後但並不是最不重要的是敏捷宣言。

原文：http://www.dennisweyland.net/blog/?p=43

做者：Dennis Weyland

譯者：Queena

------送福利啦~ 近期將以前已翻譯文章，整理成PDF。

在公衆號後臺回覆：002 便可領取哦~

後續也會不斷更新PDF的內容，敬請期待！