DevOps系列之 —— DevOps概覽（一）軟體産業和傳遞模式發展趨勢DevOps系列之 —— DevOps概覽（二）新型軟體技術及傳遞模式DevOps系列之 —— DevOps概覽（三）DevCloud HE2E DevOps 架構及其主要服務DevOps系列之 —— 持續規劃與設計（一）靈活項目管理理念與方法實踐DevOps系列之 —— 持續規劃與設計（二）規劃與設計
DevOps 系列文章，持續更新中 ~~~
- 靈活項目管理的方法
- 1. Kanban 方法
- Kanban 看闆的含義
- 拉動式生産的收益
- 建立和運作看闆的五大實踐
- 可視化價值流動
- 顯式化流程規則
- 控制在制品數量
- 管理工作項流動
- 建立回報，持續改進
- 不同角色關注看闆的重點
- 看闆展示核心元素
- 看闆分層架構
- 看闆度量名額和方法
- 2. Scrum 方法
- Scrum 是什麼？
- Scrum 的起源
- Scrum 三大特點
- 全面視角的 Scrum 架構
- Scrum 架構
- Scrum 團隊模型（三種角色）
- Scrum 三種工件
- Scrum 過程模型（5個活動 + 1個合約）
- Scrum 價值觀
- Scrum 三大支柱
靈活項目管理的方法
1. Kanban 方法
Kanban 看闆的含義
- 看闆源自精益制造
- 豐田公司實踐演化得來，故又稱“豐田生産方式”
- 兩個支柱：準時化、自動化
- 看闆（Kanban）一詞來自日文，指可視化卡片
- 實質：後道工序需要時，通過看闆向前道工序發出信号——請給我需要數量的輸入，前道工序隻有得到看闆後，才按需生産
- 由下遊向上遊傳遞，拉動上遊的生産活動，使産品向下遊流動
- 拉動的源頭是最下遊的客戶價值，也就是客戶訂單或需求
拉動式生産的收益
- 好處：控制庫存、加速流通、靈活響應、促進改善等，讓
- 控制庫存：下遊需要時上遊才開始生産（庫存控制的水準是工廠管理的核心名額）
- 加速流動：進入生産環境的物料和半成品，很快被拉入下一環節，直至變成成品，保證安全庫存前提下物料最快的流動，提供工廠的
- 靈活響應：使用者需求的變化通過看闆形成的資訊流快速傳遞至各個環節，系統做出了最快的響應。同時低庫存水準降低了負載，讓響應更加迅捷和低成本
- 促進改善：庫存的降低和流動的加速，可以讓生産環節的問題可以在第一時間暴露，
拉動式生産是否能解決軟體産品開發中的問題？2006年 David J. Anderson 最早在軟體開發中借鑒和應用看闆實踐，并總結成為完成的方法體系——“看闆方法”
DevOps系列之 —— 持續規劃與設計（三）靈活項目管理的方法【Kanban 與 Scrum】
建立和運作看闆的五大實踐
- 建立看闆
- 可視化價值流動
- 現實化流程規則
- 控制在制品數量
- 運作看闆
- 管理工作項流動
- 建立回報，持續改進
可視化價值流動
- 團隊繪制出自己的工作流，并将其分解為關鍵的幾個狀态（例如下圖中的就緒、設計、實作、測試、釋出），
顯式化流程規則
- 流轉規則：什麼條件下卡片可以進入下一個環節
- 分類規則：不同類型的工作采用不同的卡片，泳道、優先級的選擇
- 工作節奏：團隊以什麼樣的節奏接受工作，更新看闆的節奏，釋出的節奏等等
控制在制品數量
- 在制品指某個環節内所有的工作項（包括進行中和等待的），環節内在制品小于某個數時，可以從上一環節拉入新的工作，否則不允許
- 減少了并行工作，縮短時間，工作項從進入看闆到傳遞的時間随之縮短
- 如某個工作長時間受阻成為瓶頸，影響到上遊環節，團隊應該聚焦于完成已經開始的工作
管理工作項流動
- 目的：讓使用者價值順暢和高品質地流動
- 就緒隊列填充活動：輸入環節和價值流動的源頭
- 看闆站會：關注價值流動過程中問題和阻礙，處理問題，提出方案
- 釋出評審：需求釋出前的活動，決定上線或釋出哪些需求、釋出政策等（可選活動）
建立回報，持續改進
- 流動是否順暢的回報（eg：阻礙問題分類，影響和問題分析）
- 品質問題的回報（eg：開發和測試環節遺漏缺陷的問題）
不同角色關注看闆的重點
看闆展示核心元素
- 分層、泳道、列、價值流、在制品（WIP）、風險&瓶頸、拉動式開發
看闆分層架構
- 基于不同視角的價值流，看闆可以分層
- 産品級看闆：基于産品視角
- 團隊級看闆：基于設計團隊、開發團隊、SIT測試團隊視角
看闆度量名額和方法
- 看闆度量主要名額
- 前置時間（Lead Time）：又稱為傳遞時間（Delivery Time）：工作項進入看闆輸入隊列到已經完成所需要的整個時間
- 吞吐量（Throughput）：在固定周期内能夠完成多少個故事點的故事
- FE流動效率
- 準時傳遞率
- 流動性&波動性
- 看闆度量主要方法
- 價值流圖
- 累積流圖（CFD：Cumulative Flow Diagram）
- 快速概覽項目或産品工作中發生的情況
- 控制圖
- 直方圖（weibull分布圖）
2. Scrum 方法
Scrum 是什麼？
- 英文意思是橄榄球運動的一個專業術語，表示 “争球” 的動作
- 1986年，竹内弘高和野中郁次郎在《The New New Product Development Game》 文章中提到将Scrum 用于産品開發
- 傳統 “接力跑” 産品開發模式不能滿足快速靈活的市場需求
- 如同橄榄球賽的團隊合作方式：團隊作為一個前進，在團隊的内部傳球并保持前進，這樣也許能更好的滿足激烈的市場競争
Scrum 的起源
Scrum 三大特點
- “可能性” 的藝術：關注當下
- 團隊自組織，自管理：放權
- 面對面溝通
全面視角的 Scrum 架構
- 輕量級的項目管理架構，核心在于
- 首先有産品代辦清單 ——> 計劃會議上從産品清單中選擇合适的條目加入到疊代的代辦清單 ——> 2~4周疊代開發（每日站會）——> 送出潛在的可傳遞增量（使用者評審、回顧會議）
Scrum 架構
任何的軟體開發過程架構都可以由最基本的三個要素組成：角色（人）、活動及其輸入輸出的工件
- 包括了一系列實踐和預定義角色的過程架構
- 角色
- 産品負責人（Product Owner）
- Scrum 主管（ScrumMaster）
- 團隊成員
- 活動
- 沖刺規劃會議（）
- 工件
Scrum 團隊模型（三種角色）
Scrum 三種工件
Scrum 過程模型（5個活動 + 1個合約）
Scrum 價值觀
- 承諾：願意對目标作出承諾
- 專注：把你的心思和能力都用到你承諾的工作上去
- 勇氣：要有勇氣作出承諾，并且要履行承諾，接受别人的尊重
- 開放：scrum 讓把項目當中的一切都開放給每個人看
- 尊重：每個人都有他獨特的背景和經驗，我們都要給予尊重
Scrum 三大支柱
- 透明：通過任務闆的形式，把項目中的任務和資源等進行可視化
- 檢視：在每日站會評審和回顧等環節都是進行檢視的環節
- 适應：在檢視過程當中發現了偏差，就要進行調整，以适應目前的情況
在軟體開發過程當中，常用的控制理論有兩種，預定義控制和經驗過程控制
- 預定義過程控制：類似于瀑布開發模型
- 經驗過程控制：理論是靈活的開發模式