正如標題所示，這篇文章是關於 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
譯者：Queena
送福利啦~ 近期將之前已翻譯文章，整理成PDF。
在公眾號後臺回覆：002 即可領取哦~
後續也會不斷更新PDF的內容，敬請期待！
