敏捷開發 - Activity，執行 scrum 活動的流程
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分鐘
- 每日成員會議，團隊成員輪流報告
- 昨天目標執行狀況
- 今天預計完成目標
- 有沒有遇到什麼問題
-
檢核 - Sprint
- 以 2-4 週為一個衝刺區間
- 在期間內逐一完成 story 中的 task 項目
-
展示 - sprint demo (review) meeting
- 在正式 Demo 之前，進行 2-4 小時的預前會議
- Core Role 成員都需要參與
- Production owner 會確認 story 有做到他期望的結果
- Production owner 會再根據 story 提出新的想法，形成新的 sprint 則作為第二階段需求
- 需預留會發生不符期待所需要的修正時間
-
回顧 - Sprint repospective metting (1.5-3小時)
Continue Reading
Git-flow + Scrum
Continue Reading對於本文，請記住，在每個sprint結束時，每個story都標記為已完成或未完成。還要記住，每個story都需要被分解成可以提供商業價值的工作塊。
敏捷軟體版本測試週期
敏捷軟體版本測試週期
採用敏捷開發過程，只要當需求足夠形成一個週期工作量之後，
就可以進行啟動循環週期： 分析-設計-開發-測試-上線
每個循環期間，會需要非常頻繁的進行軟體版本測試週期
(事實上，這裡所提及的 alpha, beta… 測試階段，與傳統做法不同，敏捷的測試階段都是以週期為檢核點 )
Continue ReadingLEAN 精實軟體度量 - 如何減少內耗成本
LEAN 精實軟體度量 - 如何減少內耗成本
- 距離導致的浪費：開發需耗費移動或跨區域等候才能取得結果
- 層級導致的浪費：第一線人員需具備行動權力，才能減少來回溝通的成本
- 技術債的浪費：環境不一致導致上線部署出問題，寫出不良程式碼導致後續維護問題，都是技術債的一部分
- 文件導致的浪費：文件寫作錯誤，可能導致後續極大的損失及浪費，因此需重視文件的品質
- 度量本身的浪費：從客戶的角度來看，不會關心我們搜集這些度量的成果，他們重視的始終是價值，因此還是要評估現有狀況來導入度量，別因為強制導入而對價值造成影響
LEAN 精實軟體度量 - 整體決策大目標
LEAN 精實軟體度量 - 整體決策大目標
支撐決策的計畫可以區分為三個方向，從這些方向再衍伸出各種決策計畫，來設定合理的目標
- 組織
組織的方向除的公司本身，還包含競爭市場分析，內容包括產品規劃、藍圖、資源配置、市場調查
- 專案
專案主軸在於專案進度計畫，估算產能及工作量，提升品質，防範缺漏及測試，資源分配(交付週期、規模、個人及團隊能力)及能力提升計畫
- 個人至團隊
個人方面著重個人能力、工作量評估，提升目標則是個人能力、團隊能力及組織技能提升
本系列共五篇
1. LEAN 精實軟體度量 - 基礎結構及要求
2. LEAN 精實軟體度量 - 專案管理仍是重點
3. LEAN 精實軟體度量 - 整體決策大目標
4. LEAN 精實軟體度量 - 如何提升效率
5. LEAN 精實軟體度量 - 如何減少內耗成本
Continue ReadingLEAN 精實軟體度量 - 專案管理仍是重點
LEAN 精實軟體度量 - 專案管理仍是重點
整個敏捷開發或精實開發，都是圍繞在一個重點： 專案管理
專案管理最終目的是做出符合使用者期望
這也是純技術團隊發展 Scrum 通常被忽略的重點 - UI/UX 反饋 打造貼近使用者的產品，關鍵都在 UI/UX 這是在產品規劃過程必須考量的重點因素 因此在執行每一個階段後，都必須要再檢視，並檢討修正，確保品質與維持價值
Continue ReadingLEAN 精實軟體度量 - 基礎結構及要求
LEAN 精實軟體度量 - 基礎結構及要求
軟體開發過程是一個複雜的體系，
敏捷開發 > 核心 > 快速交付？
快速交付，要交付的是任務
再聊精實度量之前，先談談敏捷開發一些基礎構成
敏捷開發角色大概可分成主要三類： Scrum master, 產品負責人, 團隊
每兩週為一個 sprint 單位，來做衝刺
為什麼要敏捷開發？ 因為要讓專案可以有節奏地進行
敏捷開發最終還是要回歸到專案管理本身 專案管理牽涉的層面較為複雜，通常會需要考量的因素較多 在專案經驗較缺乏的情況下，很容易形成做敏捷而不是變敏捷
只是表面上看起來有在做這件事情
在實施敏捷開發時，也應該針對目前成員及專案狀況來進行 scrumful
scrum 其實有基本的要求，其中包括成員素質、Master特質、專案經驗都有基本的要求 你無法在一個不求進步的團隊落實 scrum，因為最終結局機會讓人全部跑光，或者做出奇怪的東西
scrum 在紀律之下，必須要有充足的尊重跟授權 也就是說，團員要遵守一定的紀律，但Master也充足的授權及尊重他們的意見