令人擔憂的Scrum解釋

(原文: Worrying interpretations of Scrum)

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

Scrum的定義(9)

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

Scrum的定義(9?)

我希望到現在(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這樣(容器)事件可能會忽略這一方面。

Scrum的定義(11)

Agile & Scrum Basis

Leave a Reply

發佈留言必須填寫的電子郵件地址不會公開。