Scrum

Jira Roadmap 是一個將 Epic 可視化管理介面，適合用於管理大型，需要耗時幾個月的專案，以及不同Groups的 sprints。

Scrum 執行 Sprint backlog

• 將 Story 轉化成可被執行的 Sprint 清單

  首先，先確認清楚團隊可投入的有效工作時數

Artifact，Scrum 文件管理

• Vision
  • 軟體的遠景、願景
• User Story

將期待及需求明確化

Activity，執行 scrum 活動的流程 初期衝刺規劃 - Sprint planning meeting 每個 sprint 開始的第一天，先進行 4-8 小時 plan to sprint 會議 Core Role 成員都需要參與，溝通 逐一將所有 stories point分割成 task 項目（要做什麼，該怎麼做） 估算每一個 task 所需要的時間（單位：小時） 會議結束會產生 Sprint baccklog story (以及 task list) 每日立會 - Daily Scrum 每天15分鐘

Scrum

Scrum 是一個敏捷專案管理架構：

敏捷軟體開發宣言

藉著親自並協助他人進行軟體開發， 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力，我們已建立以下價值觀:

對於本文，請記住，在每個sprint結束時，每個story都標記為已完成或未完成。還要記住，每個story都需要被分解成可以提供商業價值的工作塊。

敏捷軟體版本測試週期

採用敏捷開發過程，只要當需求足夠形成一個週期工作量之後，

就可以進行啟動循環週期： 分析-設計-開發-測試-上線

每個循環期間，會需要非常頻繁的進行軟體版本測試週期

(事實上，這裡所提及的 alpha, beta… 測試階段，與傳統做法不同，敏捷的測試階段都是以週期為檢核點 )

LEAN 精實軟體度量 - 如何減少內耗成本

• 距離導致的浪費：開發需耗費移動或跨區域等候才能取得結果
• 層級導致的浪費：第一線人員需具備行動權力，才能減少來回溝通的成本
• 技術債的浪費：環境不一致導致上線部署出問題，寫出不良程式碼導致後續維護問題，都是技術債的一部分
• 文件導致的浪費：文件寫作錯誤，可能導致後續極大的損失及浪費，因此需重視文件的品質
• 度量本身的浪費：從客戶的角度來看，不會關心我們搜集這些度量的成果，他們重視的始終是價值，因此還是要評估現有狀況來導入度量，別因為強制導入而對價值造成影響

LEAN 精實軟體度量 - 如何提升效率

無論敏捷或精實，整體重點離不開以下幾點

• 進度
• 效率
• 品質
• 能力
• 客戶滿意度

LEAN 精實軟體度量 - 整體決策大目標 支撐決策的計畫可以區分為三個方向，從這些方向再衍伸出各種決策計畫，來設定合理的目標 組織 組織的方向除的公司本身，還包含競爭市場分析，內容包括產品規劃、藍圖、資源配置、市場調查 專案 專案主軸在於專案進度計畫，估算產能及工作量，提升品質，防範缺漏及測試，資源分配(交付週期、規模、個人及團隊能力)及能力提升計畫 個人至團隊 個人方面著重個人能力、工作量評估，提升目標則是個人能力、團隊能力及組織技能提升 本系列共五篇 1. LEAN 精實軟體度量 - 基礎結構及要求 2. LEAN 精實軟體度量 - 專案管理仍是重點 3. LEAN 精實軟體度量 - 整體決策大目標 4.

LEAN 精實軟體度量 - 專案管理仍是重點

整個敏捷開發或精實開發，都是圍繞在一個重點： 專案管理

專案管理最終目的是做出符合使用者期望

這也是純技術團隊發展 Scrum 通常被忽略的重點 - UI/UX 反饋 打造貼近使用者的產品，關鍵都在 UI/UX 這是在產品規劃過程必須考量的重點因素 因此在執行每一個階段後，都必須要再檢視，並檢討修正，確保品質與維持價值

LEAN 精實軟體度量 - 基礎結構及要求 軟體開發過程是一個複雜的體系， 敏捷開發 > 核心 > 快速交付？ 快速交付，要交付的是任務 再聊精實度量之前，先談談敏捷開發一些基礎構成 敏捷開發角色大概可分成主要三類： Scrum master, 產品負責人, 團隊 每兩週為一個 sprint 單位，來做衝刺 為什麼要敏捷開發？ 因為要讓專案可以有節奏地進行 敏捷開發最終還是要回歸到專案管理本身 專案管理牽涉的層面較為複雜，通常會需要考量的因素較多 在專案經驗較缺乏的情況下，很容易形成做敏捷而不是變敏捷 只是表面上看起來有在做這件事情 在實施敏捷開發時，也應該針對目前成員及專案狀況來進行 scrumful scrum 其實有基本的要求，其中包括成員素質、Master特質、專案經驗都有基本的要求 你無法在一個不求進步的團隊落實 scrum，因為最終結局機會讓人全部跑光，或者做出奇怪的東西