Scrum Archives - 頁3，共7 - IT 觀察者隨筆

您的敏捷團隊：太大還是太小？

大多數敏捷和Scrum培訓課程都提到了7+/-2規則，也就是說，敏捷或Scrum團隊應該是5到9名成員。 Scrum愛好者可能記得，Scrum指南中說Scrum團隊不應少於3人或多於9人。這個經驗法則從何而來？為什麼？

LeSS是由Bas Vodde和Craig Larman根據擴大Scrum規模的實踐經驗創建的，於2014年成立了LeSS公司。 LeSS（大規模Scrum）的核心是 “用LeSS更多 “的原則。複雜的產品開發並不要求復雜的解決方案。它需要深入了解問題的本質，然後用更簡單的解決方案來解決這些問題。

我們在軟件開發中總是會遇到這些術語。有時人們一塊軟件的功能–需求/用例，積壓項目….。軟件人員使用這個或哪個的慣例是什麼？

在軟件開發中，通常的“估計”包括對執行給定開發任務所需工作的定量評估；這通常以持續時間（小時/天）或估計單位（故事點）來表示。目的是合併一些這樣的單獨估計，以獲得軟件項目的總體持續時間、工作或成本的指示。

2011 年夏天，Ken Schwaber 和 Jeff Sutherland 修改了他們的 Scrum 指南。在其中，他們刪除了 Scrum 已知的一種長期存在的行為，即團隊對產品所有者和客戶的承諾。承諾被預測取代。他們說團隊可能會預測他們的工作，但不會承諾。

完成的定義（DoD）是一個用戶故事必須遵守的要求列表，以便團隊將其稱為完成。而用戶故事的驗收標準由一組測試場景組成，這些測試場景需要被滿足，以確認軟件是按預期工作的。

每個衝刺階段結束時都會有一個由兩部分組成的衝刺回顧會議。這樣的會議以客戶回顧和演示開始，以團隊回顧結束。這兩個部分都發生在衝刺的最後一天。衝刺回顧的重點是 “檢查 “和 “調整 “增量（潛在可發貨），而衝刺回顧則更注重衝刺過程中的 “檢查 “和 “調整”。

INVEST提醒我們，一個高質量的產品積壓項目（PBI）（或用戶故事）通常是以用戶故事的形式寫成的。但什麼是好的用戶故事的特徵呢？縮寫 “INVEST “可以提醒你，好的故事應該是

在過去的20年中，什麼被證明是Scrum的優勢？什麼應該是Scrum在未來20年的重點？到目前為止，Scrum中最讓你沮喪的是什麼？是什麼讓你與Scrum聯繫在一起？什麼是可以添加到Scrum中的一個小改進？

在一個設計精美的Scrum過程畫布中無縫地瀏覽整個Scrum過程。快速、輕鬆、無縫地執行Scrum活動。讓整個團隊充分參與。我們的敏捷軟件使敏捷項目簡單而有效。