持續交付1-持續交付管理
持續交付管理
持續整合:個體不斷向主幹分支快速迭代的過程,強調開發的及時性,以保障區域性和整體開發進度的協調,而不是像瀑布模型那樣集中提交,而存在大量衝突的情形;
持續交付:將持續整合的二進位制包不斷進行測試,優化的過程,使應用保證一種隨時可交付使用的狀態.
持續部署:構建產品可快速安全交付使用者使用的方式,強調快速生產化,包含基礎設施的部署能力.
業務治理
持續交付的實現不僅僅是一種新的交付方法論,它更是對於企業的業務治理.
1 快速交付可以支援收入的持續增長;
2 業務風險管理,提前控制風險;
通過明確持續交付內容,可以把握軟體的整體和部分,理解整個業務流程,便於規劃和管理企業軟體;
配置釋出成熟度模型:
業務治理目標
- 縮短生產週期,快速交付,提前盈利;
- 減少缺陷,提高效率,降低修復成本;
- 提高軟體交付生命週期的可預測性;
- 具有采用和遵守任何必要的法律規章的能力;
- 具備發現和管理軟體交付風險的能力;
- 通過更好的風險管理和交付更少缺陷的軟體來減少成本;
成熟度模型使用:
- 確認公司配置釋出階段;
- 選擇適合公司的階段領域進行改造,定義驗收條件;
- 建立實施計劃;
- 驗證是否達到預期,相關干係人進行實施討論;
- 不斷重複,積累知識,然後在內部推廣;
專案生命週期
團隊發展階段:
建立期,風暴期,規範期,運轉期,調整/重組期;
同樣,專案也可以劃分為以下階段:
識別階段,啟動階段,初始階段,開發/部署階段,運維階段
- 識別階段
1 收集利益干係人列表
2 進行軟體前期業務分析
3 收集產品需求
4 排列需求優先順序
- 啟動階段
1 生成商務分析報告,評估專案價值;
2 列示概括性的功能和非功能需求列表(容量,可用性,服務連續性,安全性等要求),可以滿足工作量評估和做專案計劃即可;
3 釋出計劃,包括了工作量規劃,專案相關成本;需要評估需求的相對大小,工作量,風險和人力資源計劃;
4 測試策略
5 釋出策略
6 架構評估報告,使用的平臺和框架
7 風險和問題列表
8 開發生命週期的描述
9 執行上述內容的計劃描述
實際該階段需要干係人對產出物達成共識,可以對於相應的問題域有較詳盡的認識且是共識,這個是必須要記錄的,也是該階段的關鍵;
整個專案最長週期最好以三到六個月為怡.
- 初始階段
1 確保團隊獲取到對應的軟硬體
2 確保基礎設施就緒
3 許可權分發
4 建立好版本控制庫
5 角色,職責,工作時間和會議時間達成共識
6 為第一週做準備,並設定好該周目標
7 建立一個簡單的測試環境和測試資料
8 稍微詳細的研究下預定系統設計:探索可行性
9 做一些調研,識別和緩解任何分析,開發和測試風險
10 建立需求列表
11 初始化專案,完成專案結構,構建指令碼,一些測試,可以持續整合
- 開發/部署階段
核心流程
1 程式碼隨時處於可工作狀態,每次提交程式碼都會觸發自動化測試套件(單元測試,元件測試,端到端驗收測試)
2 每個迭代都可以部署到類生產環境,並向用戶演示
3 迭代長度不超過兩週
迭代開發價值
1 功能被劃分優先順序,將核心功能快速成型,
2 快速和使用者溝通產品進度,得到產品反饋
3 定期演示,進行產品進度跟蹤
4 保持軟體隨時可工作,加強團隊紀律性和興奮度
5 可以有效驗證產品,可以部署到生產環境.
- 運維階段
識別新功能,排定優先順序,分析,開發,測試和釋出,周而復始
整個專案的生命週期代表軟體的成長階段,針對不同的階段有效的安排對應的事情,可以加速軟體成型,快速創造價值,磨練各個團隊.一個好的專案管理是企業文化的體現,這種環境下,企業的效益和員工的成長都是息息相關的.
風險管理流程
影響軟體交付進度的所有因素都是軟體的風險.對於它們的管理,可以加強軟體的健壯性和快速交付能力.
風險管理模型:影響*可能性;
比如如果軟體推遲一天交付,公司要損失10萬,而推遲的可能性是50%,那麼風險的影響的就是5萬.
實際中根據專案生命週期的階段來進行風險管理是具體而有效的,不斷降低軟體開發中的不可控因素,是保障軟體成功的關鍵,將所有風險影響因素變為可測量項,並進行跟蹤治理,就可以獲得一個健康的產品.
風險管理內容:
1 如何跟蹤專案進度
2 如何防止缺陷
3 如何發現缺陷
4 如何知道一個需求已完成;
5 如何管理環境
6 如何管理配置項,如測試用例,部署指令碼,環境和應用程式配置,資料庫指令碼和外部庫
7 演示頻率
8 回顧會議頻率
9 執行自動化測試頻率
10 如何部署軟體
11 如何構建軟體
12 可行且可接受的釋出計劃
13 風險問題列表及時更新
常見軟體風險:
1 不頻繁或充滿缺陷的部署
2 較差的應用程式質量
3 缺乏管理的持續整合工作流程
4 較差的配置管理