DevOps平臺之看板設計

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

引言：

在DevOps的研發過程中，好的看板功能有助於最佳化專案管理、提升開發效率，是較重要的功能之一。本文從需求分析角度入手，分析DevOps產品對看板的需求，並結合普元DevOps產品看板部分的實際開發經驗和使用者反饋向大家介紹DevOps看板的設計實踐之路。   

目錄：

1.DevOps需要的看板 

2.看板實踐及最佳化  

1.DevOps需要的看板 

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

1.價值流

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

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

DevOps中的價值流

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

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

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

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

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

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

1. 使工作可見

2. 合理控制最流動單元

3. 減少交接次數

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

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

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

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

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

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

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

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

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

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

2.看板實踐及最佳化 

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

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

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

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

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

（1）描述資訊（標題、描述、附件、Comments、所屬迭代、所屬版本）

Comments是提供給開發人員的交流空間，讓開發人員可以在這裡進行簡短的意見交流，一些較小、內容簡短的討論可以在這裡進行，無需所有相關人員聚集在一起討論節約時間

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

（3）人員資訊（責任人、建立人、解決人）

明確工作項的相關人員，責任劃分明確。

（4）時間資訊（建立時間、預估時間、耗費時間、到期時間）

提供明確的時間資訊，有利於專案管理者控制專案開發進度

（5）關聯的工作項（子任務、Bug）

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

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

（1）普通列表

普通列表檢視用分頁列表形式展現工作項，不會展示過於詳盡的資訊，意在為使用者提供一個可以快捷操作的頁面，如新增工作項、快速修改工作項的狀態。

（2）詳情列表

詳情列表檢視將頁面分為左右兩個區域，左側是簡化的目錄列表展示全部工作項，右側展示使用者在目錄列表選中的工作項的全部資訊，適用於快速瀏覽工作項後切換檢視各個工作項的詳細資訊。

（3）狀態甬道

從工作項狀態的維度展示工作項的簡要資訊，標題、負責任、狀態，方便專案組舉辦週會，每日站會時彙總展示當前所有工作項所處狀態，統一分配任務、總結任務完成情況使用，採用拖拽形式來修改任務狀態，方便快捷。

（4）時間甬道

針對每日站會的甬道，專案進入較為緊張的開發階段時往往需要每日或較短的時間內分配任務、檢視任務完成情況，以時間為展示維度，讓專案管理者看到每個時間段內工作項的數量、完成情況，方便把控專案進度。

根據真實使用反饋的最佳化完善

DevOps的看板設計完成後經過一段時間的使用，發現了許多問題，我們對此做出了總結和改進：

（1）檢索功能最佳化

工作項具備很多檢索條件，條件過多，選擇控制元件按鈕在頁面上堆疊，使用者體驗不佳，所以改為採用摺疊形式的查詢欄並提供常用查詢條件儲存功能，最佳化體驗。

（2）時間甬道看工作項板卡片最佳化

工作項具備很多屬性，開站會時經常需要修改負責人、任務優先順序等一些資訊，甬道修改時間方便但是要修改其他屬性則需要進入詳情頁面，增加了操作步驟，浪費時間，因此將一些常修改的屬性新增至卡片上方便修改。

（3）列表檢視資訊快速修改最佳化

列表檢視的使用者一般對工作項內容較為了解，很少檢視工作項詳細內容，此類使用者要修改工作項的一些基本資訊時不希望進入詳情頁後才能修改工作項資訊，因此將列表的單元格改為可編輯形式，減少點選頁面次數。

以上就是普元DevOps產品看板模組的設計和實踐歷程，在價值流視覺化和專案成員溝通等方面我們仍在持續改進，希望能打造出更便捷、更清晰的看板，完善DevOps平臺看板模組。

*參考書籍：《DevOps實踐指南》

關於作者：夏夏，前端工程師，參與普元DevOps產品開發，以及微服務、容器雲等產品開發，負責前端頁面設計、架構搭建等工作。善於架構搭建、元件封裝及相關演算法設計。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。