DevOps系列之 —— DevOps概覽（一）軟體産業和傳遞模式發展趨勢DevOps系列之 —— DevOps概覽（二）新型軟體技術及傳遞模式DevOps系列之 —— DevOps概覽（三）DevCloud HE2E DevOps 架構及其主要服務DevOps系列之 —— 持續規劃與設計（一）靈活項目管理理念與方法實踐DevOps系列之 —— 持續規劃與設計（二）規劃與設計DevOps系列之 —— 持續規劃與設計（三）靈活項目管理的方法【Kanban 與 Scrum】
DevOps 系列文章，持續更新中 ~~~
- 靈活需求管理
- 1. 使用者故事
- 什麼是使用者故事
- 描述使用者故事
- 使用者故事 —— 角色類型的建立
- 角色類型的建立 —— 頭腦風暴
- 角色類型的建立 —— 整理角色類型集合
- 角色類型的建立 —— 整合角色類型
- 角色類型的建立 —— 提煉角色類型
- 使用者故事 —— 搜集故事
- 使用者故事 —— INVEST原則
- 使用者故事的層級關系
- 使用者故事的優先級
- 使用者故事的優先級 - 考慮因素
- 使用者故事的優先級 - 渴望度 kano 模型
- 使用者故事的優先級 - MoSCow 原則
- 使用者故事的優勢
- 使用者故事的問題
- 2. 靈活估算
- 故事點
- 故事點可以引導對整個故事的思考
- 故事點的優點
- 對大小的純粹估計
- 我的理想人天不等于你的
- 理想人天的優點
- 估算方法
- 估算方法 - 原則
- 估算方法 - 如何确定估算值
- 估算撲克
- 分解使用者故事
- 何時分解
- 分解方法 - 資料邊界分解
- 分解方法 - 操作邊界分解
- 估算速度
- 使用曆史指
- 預測
- DoR 與 DoD
- 案例模拟 - 項目流程
靈活需求管理
1. 使用者故事
什麼是使用者故事
- 使用者故事描述了對使用者，系統或軟體購買者有價值的功能，由以下三方面組成
- 一份書面的故事描述卡片，用來做計劃和作為提示
- 有關故事的交流，用于具體化故事環節
- 測試，用于記錄和确認故事細節且可用于确定故事何時完成
描述使用者故事
As who, I want what so that why
- 作為X【什麼使用者角色】
- 我希望Y【系統提供什麼功能】
- 以便Z【達到什麼目的或實作什麼價值】
- 或者是：
- 為了X【達到什麼目的或實作什麼價值】
- 作為Y【什麼使用者角色】
- 我希望Z【系統提供什麼功能】
相對于編寫好的使用者故事，産生和讨論的過程更加重要！
使用者故事 —— 角色類型的建立
我們以一個招聘網站的例子來描述角色類型的建立
角色類型的建立 —— 頭腦風暴
- 隻創造角色
- 不讨論角色
- 比如有哪些角色：求職者、獵頭、招聘者等等
角色類型的建立 —— 整理角色類型集合
- 我們将不同類型的角色進行分組，分組之後再進一步整合和濃縮
- 如果有兩個重疊的卡片對我們的意義是相同的，就可以保留一個，舍棄另外一個，或者将其變為一個新的
角色類型的建立 —— 整合角色類型
角色類型的建立 —— 提煉角色類型
- 角色特征考慮方面：
- 操作計算機的熟練程度
- 專業技術水準
- …
使用者故事 —— 搜集故事
- 使用者模型建立好後，我們就可以開始收集我們的使用者故事
使用者故事 —— INVEST原則
使用者故事的層級關系
使用者故事的優先級
使用者故事的優先級 - 考慮因素
要根據業務價值确定優先級
使用者故事的優先級 - 渴望度 kano 模型
- 當我們購買一件産品時，有那些功能是我們覺得理所應當應該有的？
- 哪些是我們覺得越多越好的？
- 哪些功能如果有的話是會令我們覺得興奮的？
使用者故事的優先級 - MoSCow 原則
使用者故事的優勢
- 強調口頭溝通
- 便于了解
- 大小适中
- 适合疊代開發
- 鼓勵延遲細節
- 适應變化
- 參與性設計
- 傳播隐形知識
使用者故事的問題
- 故事太小
- 很難排優先級
- 想得太遠
- 過早考慮界面細節
- 故事互相依賴
- 不願排優先級
- 細節太多
2. 靈活估算
故事點
- 什麼是相對估算？
- 當我們根據戶型圖來預估粉刷每個房間工作量時，是否能準确說出每個房間會耗費多少時間？
故事點可以引導對整個故事的思考
- 當我們用理想人天開來估算整個故事的工作量時，很難避免團隊中不同崗位的人員以自身的工作量進行分别估算
故事點的優點
對大小的純粹估計
- 項目開始時，5個故事點的故事耗費團隊3天完成
- 項目尾聲時，同樣5個故事點的故事是什麼情況？
- 如果此時用來估算工作量的是理想人天，那麼又将發生什麼情況？
我的理想人天不等于你的
理想人天的優點
- 更容易跟團隊外的人解釋
- 估算更容易開始
- 便于測試速度
估算方法
估算方法 - 原則
- 通常是團隊人員聚在一起，去比較待估算的使用者故事，每個人寫下自己認為的故事點數，進行展示，交換意見
估算方法 - 如何确定估算值
估算撲克
- 使用者故事的規模
- 受以下因素影響
- 工作量
- 複雜程度
- 不确定性
- 撲克牌的數值是斐波那契數列
分解使用者故事
何時分解
- 當我們成功編寫了一個使用者故事以後，由于各種原因，我們往往需要把一個使用者故事分解成多個更小的部分
- 使用者故事過大
- 疊代時間不夠
- 估算不準
分解方法 - 資料邊界分解
- 按照使用者故事所支援的資料邊界來分解大型使用者故事
分解方法 - 操作邊界分解
- 按照大型使用者故事中進行的操作對其進行分解
- 比如圖書管理系統管理者權限部分
- 增加
- 删除
- 查詢
- 修改
估算速度
使用曆史指
- 使用的技術是否一樣？
- 針對的領域是否一樣？
- 開發團隊是否一樣？
- 産品負責人是否一樣？
- …
預測
- 估算個人可用小時數
- 估算疊代可用時長
- 選擇故事填充可用時長
DoR 與 DoD
- DoR（Definition of Ready）
- 靈活開發發展後，發現進入疊代開發應當滿足一定條件，否則過于模糊的需求會導緻疊代失敗，在疊代内花費過多的時間去做需求澄清，是以給進入疊代設立門檻，稱為 Definition of Ready，簡稱為 “DoR”
- 常見的 DoR
- 使用者故事澄清
- 使用者故事的故事點估算
- 使用者故事的驗收條件
- DoD（Definition of Done）
- 在靈活軟體開發中，常用 Definition of Done “完成的定義” 來表示工作是否已完成，不同的活動有不同的完成定義
- DoD 類型及常見規則
| DoD類型 | 常見規則 |
| 使用者故事 DoD | 使用者故事最終的描述符合 INVEST；使用者故事得到測試用例的對應覆寫；使用者故事得到對應的自動化測試用理；使用者故事得到 PO 試用并初步認可 |
| 疊代 DoD | 所有代碼疊代通過靜态檢測，嚴重問題已修改；所有新增代碼得到人工評審；測試用例都已執行 |
| 釋出 DoD | 完成釋出規劃所要求的重點需求；至少通過一次全量回歸測試；修複所有等級為1、2的缺陷，3、4級缺陷不超過20個 |
| 版本 DoD | 産品文檔已全部更新；代碼已部署到産品伺服器上；運維在驗收測試環境上冒煙通過；原始需求送出人對功能已經驗收通過；對運維、市場、客服的新功能教育訓練已完成 |
| 每日 DoD | 下班前檢入當天編寫的代碼；當天的代碼在當天或者第2天邀請同伴進行代碼評審；檢入的功能代碼要有對應的單元測試；每天晚上觸發靜态代碼檢查、自動化回歸測試；當天持續內建、建構環境中的問題當天解決 |
案例模拟 - 項目流程
最後，歡迎大家關注我的個人微信公衆号 『小小猿若塵』，擷取更多IT技術、幹貨知識、熱點資訊。同時，我在公衆号中分享了精心整理的一些視訊資料（包括 Python全棧教程、AI教程、前端、資料庫等），大家回複相應關鍵詞即可擷取網盤視訊連結，感謝大家的關注😊