DevOps落地實踐，BAT系列，敏捷看板

DevOps 自 2009 年誕生以來，至今整整過去了十年，從最初的摸索，逐步變成一種主流的軟體開發交付模式。BAT 在 2014 年左右，甚至更早的時候，內部的 DevOps 系統就已經差不多成型了，比如騰訊的織雲、藍鯨，阿里的 AOne，百度的效率雲等。在 DevOps 的研發過程中，好的看板功能有助於優化專案管理、提升開發效率，是較重要的功能之一。本文從需求分析角度入手，分析 DevOps 產品對看板的需求，並結合CORNERSTONE 一站式雲端 DevOps 平臺看板部分的實際開發經驗和使用者反饋向大家介紹 DevOps 看板的設計實踐之路。   

一.DevOps 需要的看板 

看板是 DevOps 較為常用的功能，整個專案開發週期都離不開它，從需求劃分、任務分配、功能實現到測試上線都需要看板的協助，看板使抽象工作流程視覺化，讓專案管理者能更清晰的掌握專案進度。由此，看板設計實踐就成為了 DevOps 實踐的重要內容之一。首先我們需要了解一下，DevOps 中的看板需要具備怎樣的功能：

 

1.價值流

 

廣義的價值流指的是從原材料變為成品、並給他賦予價值的全部活動。包括原材料的獲取，對原材料進行加工後轉變為成品交付給客戶的過程，其中還包括了各個階段各方之間的溝通形成的資訊流也是價值流的一部分。完整的價值流包括供應鏈成員之間的溝通，物料的運輸，生產計劃的制定和產品的生產過程等。

 

舉個簡單的例子，服裝加工廠要按照客戶要求生產一批服裝，生產方首先需要和客戶確定衣服的款式，用料，具體尺碼資訊，然後採購製衣所需的布料，將衣服制作圖紙下發到相關工人手中，工人按圖製衣，完成既定數量的通過質量檢測的成衣後將成品送到客戶手中，這就是一條完整的價值流。

 

DevOps 中的價值流

 

在 DevOps 中，價值流的概念同樣適用。定義：把業務構想轉化為客戶交付價值的、由技術驅動的服務所需的流程。

 

 

價值流貫穿了整個開發週期，好的價值流在保證快速的交付的同時還能保證部署工作不會產生混亂和破壞。只有打通業務、開發運維等一些列的價值鏈條，保證價值可以完整暢通的流動，減少積壓重組，才能保證產品的順利交付。在此前提下，提高開發效率實現敏捷開發才是可能的。但是技術價值流與製造業的價值流不同，它是不可見的，因此我們很難發現整個價值流是否順暢，在哪裡產生了阻礙積壓。因此我們需要將價值流視覺化，清晰的把價值流的呈現出來，這樣價值流是否完整，哪裡存在缺失就一目瞭然了。

 

二.DevOps 的三步工作法基礎原則

 

《鳳凰專案》一書把三步工作法作為基礎原則並由此衍生了 DevOps 的行為和模式：

 

 

（1）開發到運維的工作快速的從右向左的流動------流動原則

在保證質量的前提下加快價值流的流動速度，儘可能的優化工作流，減小流動單元合理控制流量，減少等待時間，提高工作效率，可以歸結為以下幾點：

1. 使工作可見

2. 合理控制最流動單元

3. 減少交接次數

4. 消除阻礙價值流的問題

（2）從右向左的每一個階段中，應用持續、快速的工作反饋機制------反饋原則

 

反饋原則是在流動原則的基礎上建立的一條資訊流，價值流上的各個環節通過這條資訊流溝通，好的資訊流有助於及時發現並解決問題，從中分析並總結經驗可以提升專案開發效率。

 

（3）建立具有創意和高可信度的企業文化，支援動態的、嚴格的、科學的實驗——持續學習與實驗原則：他打造出一種高度信任的文化和一種科學的工作方式

常見的專案中每天的站會、每週的週會一般是專案成員集中在一起交流並互相學習的機會，大家對工作作出自我總結並提出自己的想法互相交流意見，實現工作中的自我提升。

 

看板在 DevOps 中主要作為價值流的載體的一部分，使價值流中一些較為抽象的資訊可視，並讓使用者可以從中看清楚價值流的流通情況、每一個環節及環節的具體操作情況，何處需要改進、何處存在問題。三步工作法則可以幫助提升工作效率。結合對價值流的概念以及三步工作法原則的分析，看板需要具備以下功能：

 

（1）清晰描述最小工作項單元及工作項間的關係

（2）提供便捷的小組成員互相溝通方式

（3）快速直接的反饋某工作項的各種情況

（4）一目瞭然的任務完分配整合情況，方便開會總結

 

  三.看板實踐及優化 

 

首先是工作的最小單元——工作項，工作項是看板上各類工作內容的最小顯示單元，負責顯示工作內容的各種資訊，一些類似的工作項管理看板對工作項型別進行了極為細緻的劃分，但過於繁雜的工作項型別難於記憶並且存在概念重複反而不利於，結合實際專案開發情況我們將工作項型別分為三類：

 

（1）故事——一個故事代表一個完整的需求點，可以包含多個任務、bug，一  個故事及其包含的所有子專案可以完整的詮釋一個需求點在價值流上流通的全過程

 

（2）任務——將故事拆分為一個個的具體工作內容，分配到具體人員

 

（3）Bug——測試人員向開發人員、專案管理人員提出反饋的途徑

 

工作項的要展示很多的具體資訊：

 

 

（1）描述資訊（標題、描述、附件、COMMENTS、所屬迭代、所屬版本）COMMENTS 是提供給開發人員的交流空間，讓開發人員可以在這裡進行簡短的意見交流，一些較小、內容簡短的討論可以在這裡進行，無需所有相關人員聚集在一起討論節約時間

 

（2）狀態資訊（工作項狀態、優先順序）

 

（3）人員資訊（責任人、建立人、解決人）明確工作項的相關人員，責任劃分明確。

 

（4）時間資訊（建立時間、預估時間、耗費時間、到期時間）提供明確的時間資訊，有利於專案管理者控制專案開發進度

 

（5）關聯的工作項（子任務、BUG）將有關的工作項關聯到一起，完整描述產品中某一項功能，從需求分析到開發實現到測試反饋的全過程

工作項設計完成後需要考慮的就是如何一個個的工作項集中在一起展示，考慮到 DevOps 的使用者有很多不同的角色，對看板的關注角度也不同，例如專案經理更希望可以一目瞭然的看到任務的完成情況，開發人員需更關注的是分配給自己的工作項的具體的內容，CORNERSTONE 提供

【表格、分欄、看板、甘特圖、日曆、統計、周彙總、分類導圖】八種檢視，方便企業成員通過多種角度檢視專案，全方位瞭解專案狀況。

 

(1) 表格檢視

資訊以列表形式呈現，可拖動檢視所有欄位下的內容，方便概覽任務情況。

(2) 分欄檢視

分欄檢視可幫助團隊成員更快的找到他所需要的資訊；

(3)看板檢視

看板檢視可更直觀的顯示每種狀態下的任務情況，方便團隊成員及時更改任務內容；

 

 

(4)甘特圖  推薦★★★★★

 

CORNERSTONE的甘特圖功能可方便管理者弄清專案的剩餘時間，評估工作進度，調整工作任務，更好地把握專案的整體。

 

（5）日曆

CORNERSTONE的日曆檢視是基於時間，讓專案更加易於理解的管理工具。

 

（6）統計檢視

CORNERSTONE提供報表和統計圖，可檢視團隊總體任務狀態，也可檢視團隊成員個人工作貢獻，便於把控總體專案程式。

 

 

（7）周彙總

CORNERSTONE的周彙總檢視可直接提取專案中各項任務的完成情況和相應指標，自動生成簡潔的分析報告。

 

 

（8）分類導圖

CORNERSTONE的分類導圖其實就是思維導圖，它有一箇中心主題，由中心主題發散出不同的關節點，每個關節點又可以獨立成為一個分支的中心主題，整個圖形呈現出放射性立體結構，這種結構更方便記性和理清思緒。

 

 

以上就是CORNERSTONE一站式雲端 DevOps 平臺看板模組的設計和實踐歷程，在價值流視覺化和專案成員溝通等方面我們仍在持續改進，希望能打造出更便捷、更清晰的看板，完善 DevOps 平臺看板模組。最後，回到 DevOps 的理念上，DevOps 並不是專門稱呼一項技術，也不是一套流程和方法論，更不是一套簡單的工具產品，越來越多的跡象表明，DevOps 是一種文化，這種文化崇尚的是以客戶價值為根本導向讓 IT 可以變得更敏捷更精益。