敏捷方法的特性 (Features of agile)

我們在GDS中使用敏捷開發方法的一些共同點。

Sprint (衝刺)

Sprint 是 Scrum 的一部份 ，而 Scrum 是敏捷方法之一，是團隊開發產品的框架。

Sprint 是有關規劃您和您的團隊將實現什麼以及如何實現。團隊中的各個成員在每一個 Sprint 中都應有一個任務要完成。

每個 Sprint 是等長的，通常持續1到2週，但你可以在你的專案中使用更長或更短的 Sprint。

決定你 Sprint 的長度時，可以考慮：

• 專案長短 – 在較短的專案中使用較短的Sprint，讓你可以釐清專案進行的程度，有機會迭代 (iteration) 和更靈活地調整計劃以因應狀況
• 團隊成員 對Scrum 的熟悉程度：
  • 短的 Sprint 可以幫助初用 Scrum 的人更快習慣例行會議的模式和流程
• 釋出程式為產品的頻率 – 若只在每個 Sprint 尾聲時要釋出程式為產品，可以幫助你決定多常有產出

從Sprint 0 開始整個流程。Sprint 0 是為了要替你的團隊準備好第一個 Sprint。利用 Sprint 0 達到：

• 設置好開發環境和工作環境
• 同意一些設計原則（技術、產品、互動、內容）
• 為第一個Sprint準備產品需求清單

雖然有其他不依賴 Sprint 的敏捷方法，如Kanban ，但是團隊一開始就用 Scrum 是很常見的。

標準會議

敏捷方法的過程中有4個不同類型的定期會議：

• 每日Stand-up（站立會議）
• Sprint planning （Sprint 計劃會議）
• Sprint review（檢視會議）
• 回顧會議（Retrospective）

每日Stand-up

每天和你的團隊開 Stand-up 不要超過15分鐘。最好可以在你的專案牆前站成半圓形開會。這將幫你保持它的長度不過長，讓你的團隊成員可以指著牆上的使用者故事卡，專注地討論主題。

團隊中的每個成員都應該回答：

• 我昨天做了什麼／產出了什麼
• 我今天要做什麼（還有我可能需要什麼協助）
• 什麼讓我感到阻礙（阻止我完成一個使用者故事卡）

要求成員發言保持簡短，而且不要害怕重複提醒他們。如果有人試圖在 Stand-up 解決問題，請停止相關討論，並在會後安排一個小型會議，討論相關問題。

Sprint planning (Sprint 規劃會議)

Sprint planning 在每個 Sprint 的ㄧ開始實行。在事前要撰寫完包含驗收標準的使用者故事。

產品負責人要唸出故事給大家聽，解釋驗收標準，以及安排優先順序。團隊要能夠：

• 理解故事和驗收標準
• 同意在每個 Sprint 中要完成使用者故事的數量
• 同意要完成的任務

根據學習敏捷方法實驗室的網站，一個好的Sprint planning 包含二部分：

• 我們要做什麼？
• 我們要怎麼做？

這種會議可能很難在大團隊內執行。有人會想探究並質疑每一個故事，有些人希望繼續前進，不想討論細節。但一定要堅持下去！

Sprint review （Sprint 檢視會議）

這是機會可以讓團隊成員展示他們在Sprint過程中所做出來的東西。您可以找相關的人到在本次會議中，利用開會告訴他哪些使用者故事尚未完成，以及為什麼還沒完成。

回顧會議（Retrospective）

這些會議都是反覆調整團隊工作流程的重要機會。了解如何開回顧會議 。

使用者故事

使用者故事是開發服務和使用者體驗中不可或缺的一部 ，因此如何把故事寫好至關重要。學習如何撰寫使用主者故事 。

敏捷方法中的測試

在敏捷方法中做測試，為的是不斷提高服務的品質。了解敏捷式測試方法 。

譯者：
校稿：Richard
原始出處：https://www.gov.uk/service-manual/agile/features-of-agile