GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » 敏捷方法 (Agile) » 敏捷方法的特性 (Features of agile)

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

Sprint (衝刺)、Stand-up (站立會議)和其他定期會議

我們在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

請留言

你的email信箱不會被發布出來. Required fields are marked *

*