敏捷系列

Sprint backlog是敏捷開發團隊在Sprint中的工作計畫，內容比PO提供的Product backlog多上許多，Sprint backlog是一個具有足夠細節的計畫。

敏捷開發團隊在整個Sprint期間都會去修改Sprint backlog，當需要有新的工作時，敏捷開發團隊會將其加到Sprint backlog 內。隨著工作的進展或完成，團隊會去更新預估的剩餘工作量。當計畫內的某些部份被認定是不需要的，就會被移除。 

點擊【史荳芮小姐：Sprint backlog  】了解更多❗️

Product backlog就像是一個Wish list，因為在敏捷開發過程中會有很多聲音，這些聲音可能來自於直接使用者、公司高階主管、功能經理甚至是發起人……等等，PO會將所有的需求收納到Product backlog內，並且針對各個項目排序，決定出重要的先後順序。

Product backlog永遠沒有被完成的一天，隨著產品和使用環境的演變會不斷地演化，只要產品持續存在的一天，它的Product backlog也會同時存在。  

點擊【史荳芮小姐：Product backlog 產品待辦清單 】了解更多❗️

進行中的工作(WIP)是指正在進行中卻還沒有完成的工作，如果同時有太多進行中的工作在執行，不僅可能造成資源浪費，或當任務環節出現變更時會造成巨大變動，讓之前做的工作變成白工。

透過進行中的工作限制 (WIP limits)就可以有效控管進行中工作的數量，提升工作效率跟產出喔！ 

點擊【史荳芮小姐：WIP所帶來的後遺症】了解更多❗️

展示會議是在專案的執行過程中，漸進式的把產品交付給客戶，除了可以讓客戶了解專案進度外，也能夠讓使用者實際的參與專案給予意見，對於公司來說也可以降低專案失敗的風險。透過彼此的腦力激盪就能創造雙贏的結果喔！

點擊【史荳芮小姐：審查會議的利害關係人意見】了解更多❗️

「Sprint retrospective」，中文叫做回顧檢討會議。

目的是用來反省回顧Sprint有什麼值得改善的地方，逐步完善的內容很廣泛，除了在Retrospective前的Sprint review已經提出的產品改善項目以外，其他關於關係、工具、流程及人員四個部分的內容都可以納入考量。 

雖然改善這件事可能在平常工作期間的任何時間點執行，但Sprint retrospective提供了一個正式的機會，讓敏捷團隊能專注檢視與調適，幫助Scrum Team在下一個Sprint的工作能更有效能及愉快。 

點擊【史荳芮小姐：Sprint retrospective】了解更多❗️

Sprint review，中文叫做審查會議。

Sprint review主要目的是讓利害關係人可以定期審查敏捷團隊所開發出來的階段成品，能夠在Sprint review展示的產品一定要符合Definition of Done (簡稱 DoD)。Definition of Done是由Scrum Team共同定義出來交付給客戶的每個Feature應滿足的要件。

一個Feature需滿足DoD才能在會議上供利害關係人審查。

假設沒有這樣的審查機制，可能隔了一段時間才發現產品做錯，或者產出結果根本不是客戶要的，所以Sprint Review主要是讓利害關係人能審查產品。 

點擊【史荳芮小姐：Sprint review】了解更多❗️

一般來說，如果Sprint是兩個禮拜，則Sprint Planning會議時間會控制為4小時，如果Sprint是四個禮拜，則Sprint Planning會議時間為8小時。

Sprint Planning會產出Sprint Goal及Sprint Backlog。Sprint Goal 是指使用者可使用的功能，比如說：輸入的量測數據可產生趨勢圖。Sprint Backlog是一份開發團隊可以自主管理的待辦清單，開發團隊可在Sprint Backlog自行增加、修改、刪除任務，完全不需PO或Scrum Master同意。

這個會議最終的結果，會讓敏捷團隊產生對於工作事項與目標的共同認知。是敏捷不可或缺的會議之一。 

點擊【史荳芮小姐：Sprint planning】了解更多❗️

Sprint是屬於固定時間長度的概念，通常介於1個禮拜到4個禮拜之間可以增加利害關係人溝通的頻率，且可以及早偵測可能的失敗、避免失敗成本的增加。

幫助Scrum團隊完成對客戶有商業價值的任務。因為時間有限的關係，所以每個Sprint都要列出最高優先完成的特定事項。大部分的Scrum團隊都將Sprint設定在2個禮拜左右，這是適當大小的週期。

點擊【史荳芮小姐：Sprint】了解更多❗️

電梯演說是敏捷經常會用來表達願景的一種工具，利用簡單的一頁摘要或資訊，

在短短1分鐘以內的時間，便能表達整個專案的重點資訊，讓利害關係人對願景

能用簡易、快速的方式了然於心。 

點擊【史荳芮小姐：電梯演說 】了解更多❗️

Dev team是一個自我組織和具備跨職能的團隊。

開發團隊會自己選擇最佳的方式完成工作，讓整體的效率和效能最大化。 

點擊【史荳芮小姐：什麼是敏捷的開發團隊?     】了解更多❗️

敏捷團隊的Product Owner，角色是產品負責人，為產品負成敗之責，他會說明自己對於產品需求的主要架構及內容，並且頻繁地與敏捷團隊溝通、針對團隊產出給予適時的回饋，確保最後產出的正確性。

點擊【史荳芮小姐：Who is Product owner    】了解更多❗️

User story是敏捷團隊經常使用來蒐集PO需求的一個簡單工具，通常是可以在1~3天完成的工作量，由PO講出來後依照對他有價值的順序進行排列，敏捷團隊可以依照PO的排序認領User story，並將其展開成更小的Task，在一個Sprint內開發出相對應的功能。  

點擊【史荳芮小姐：User story   】了解更多❗️

在變動的環境下，執行專案難免變動，因此依照客戶的需求適時調整，不按原定的計畫執行，更可以為客戶帶來價值。

這就是敏捷核心價值的：因應需求變更比依計畫行事重要。   

點擊【史荳芮小姐：敏捷核心價值4：因應需求變更比依計畫行事重要  】了解更多❗️

敏捷概念中的風險向下燃燒圖， 是利用圖表方式讓相關利害關係人了解整個專案執行期間可能遇到的風險，團隊會在一開始先執行最高風險的工作。

在專案啟動的短時間內先降低專案風險，並定期監控與管理。如果評估風險後發現專案不適合繼續執行時，就能盡早節省資源拿到其他專案使用。

除了可以讓團隊提前審視風險外，也能盡早做好預防，降低相關利害關係人的憂慮哦！  

點擊【史荳芮小姐：風險評估圖  】了解更多❗️

客戶永遠是最知道想要什麼結果的人，因此，敏捷專案團隊應該站在客戶立場往相同方向前進，而非對立，才能真正提供客戶所需。

這就是敏捷核心價值與客戶合作比合約協定重要的精神所在。  

點擊【史荳芮小姐：敏捷核心價值3：與客戶合作比合約協定重要 】了解更多❗️

敏捷團隊非常重視團隊合作及授權，即使流程跟工具再好再先進，如果忽略了成員彼此間的溝通與協調，就不太可能做出有價值的產品。

敏捷團隊保持開放性的態度、成員間彼此頻繁地溝通與討論，降低自我摸索時間，也能互相請益學習，這就是敏捷核心價值：「個人跟互動比流程跟工具重要」的精神所在。  

點擊【史荳芮小姐：敏捷核心價值1：個人跟互動比流程跟工具重要 】了解更多❗️

產品願景盒， 是在有限的六面體空間中讓成員彼此討論產品的願景和產品特性。

主要是在專案初期執行，讓客戶與團隊能一起討論及表達對專案產品期望的資訊，

使彼此達成共識。 

點擊【史荳芮小姐：產品願景盒  】了解更多❗️