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能夠變得更敏捷更精益。