令人擔憂的Scrum解釋

在我最近參加的一次敏捷活動中，演講者調查了觀眾關於形成Scrum的9個元素。我提出“9”時立即提出了我的懷疑。當演講者提出時，情況會變得更糟：

讓我想知道Scrum的錯誤概念可以在不超過兩分鐘內表達出來：

我希望到現在（2016年），並且當然考慮到Scrum指南（自2010年起）的可用性，對Scrum的基本理解更好。

然而，最讓我擔心的不是錯誤和缺失元素的形式，而是如何反映Scrum框架的無效使用，限制了Scrum如何支持團隊創建優秀的軟件產品：

在問責制增量的自組織創造屬於開發團隊作為一個整體。協同作用是關鍵，而不是個人主義。
當Product Backlog包含產品的所有類型的工作和要求時，透明度會得到優化。Product Backlog項目的格式和語法是開放的，供團隊決定。用戶故事肯定不是強制性的。
幾年前，Scrum強制刪除了刻錄圖表。它取而代之的是，無論格式如何，在Product Backlog和Sprint Backlog上都可以看到進度。
如果Scrum被簡化為一個目的，而且只有一個目的，那就是在Sprint中創建可釋放的增量。它是經驗主義和商業敏捷性的基礎。想像一下，我甚至沒有提到這一點，Scrum的核心目的。
Scrum 沒有處方說每日Scrum需要站起來。Scrum的興趣在於確保團隊在每日基礎上對Sprint目標的進展進行檢查，以便讓團隊適應。
Sprint Review是一個協作活動，Scrum團隊和利益相關者共同合作，確定下一步工作最重要的事項。將利益相關者的輸入添加到被檢查的軟件的當前狀態（通過增量）可以改善該決策。它比演示更豐富。
Scrum中的所有事件都包含在Sprint中。短跑不超過30天，通常更少。沒有提到Sprint這樣（容器）事件可能會忽略這一方面。

Agile & Scrum Basis