利用django打造自己的工作流平台(一):從EXCEL到流程化運作


  因工作所需以及管理個人一些日常事項,自己基於django(一個基於python的web框架,詳細介紹可查閱相關資料)開發了一個簡易的工作流平台[平台地址]。本文首先簡要介紹工作流平台的設計思想及其在項目開發中的應用案例,代碼層面的細節介紹后續有時間繼續補充。

  1.工作流平台在日常工作中的設計思想: 

  如果你是一名軟件研發類工作的從業者(開發、測試等),設想一下早期在沒有問題單系統的時候是怎樣處理軟件問題的:使用一份excel表格記錄問題,如圖1所示:用戶A在系統日常使用或者測試過程中遇到問題,需要將問題的關鍵信息(概要,詳細描述,環境配置,觸發步驟等)整理到EXCEL表格中。再通過電子郵件把表格發送給開發人員B。B可能同時有幾個問題要處理,在接收到的問題中添加一些列用於記錄問題狀態信息(當前狀態;解決時間;問題處理人等)。

 圖1.問題記錄表格示例 

  用excel記錄和傳遞問題信息的弊端:
  1.處理閉環的不確定性:發送給開發人員B的問題郵件可能被淹沒在他的大量郵件中,無法確保問題一定被解決;
  2.效率問題:通過郵件流轉問題處理信息效率太低。尤其人員較多時,人手一份EXCEL的副本,進行信息同步帶來很高的溝通成本。

  為了解決上述兩個問題,誕生了專用於問題處理的問題單系統,其實質是web化的excel:圖1中的每一行對應為一個問題單,每一列對應問題單的一個字段。其中有兩個字段較為特殊:"問題處理人"和 "當前狀態",WEB后端利用"問題處理人"字段與當前登錄用戶X進行匹配,把過濾出相匹配的問題並顯示在界面上,就是需要用戶X處理的問題。另外WEB后端預設有問題處理流程,根據"當前狀態"字段決定接下來的處理:比如問題處於"待處理"狀態,則下一步可以通過編輯問題單處理問題;如果問題單處於"已解決"狀態,則表示該問題已完成處理歸檔,不能再進行處理了。

  問題單系統優勢在於通過固化字段、流程以及某些流轉條件(比如設計xx字段為必填項),首先保證了問題處理的閉環,同時最大程度減少了問題流轉到下個環節信息不足的情況;解決了多個環節間信息流通,多人協作的效率問題。

  其不足在於字段和處理流程固化導致功能單一,只能用於問題處理跟蹤,擴展性差。再審視一下問題單系統的實質:問題單系統實際是將一份EXCEL WEB化並使用固定的流程進行處理。我們把問題單系統視為一種特例,特例一般化(將多份EXCEL WEB化,每份EXCEL使用其給定的流程進行處理)就可以打造可定制字段、流程的工作流平台,用於部門團隊的事務管理和知識積累。

  工作流平台的架構非常簡單,采用自底向上的設計,步驟如下:

  1.為一種事務(問題處理、請假審批等)定制字段和流程;

  2.把一種事務的字段和流程封裝成一個項目。

  3.把多個項目封裝成項目群。

  工作流平台的基本架構如圖2所示:  

圖2:工作流平台的基本架構

  理解了上述架構,不難看出工作流平台的核心就是兩張表:數據表和狀態轉換表。數據表決定顯示哪些內容,數據表字段決定如何顯示(比如從數據表過濾出“當前處理人字段”等於當前登錄用戶名的數據顯示在界面)。轉換表決定每個問題的處理流程,每個項目都有一組State1xStim1>State2格式的描述,表示State1狀態下收到Stim1激勵跳轉到State2狀態,這組轉換描述確定了項目的處理流程。State1xStim1>State2格式的描述的具體實現形式可以自由定義,下圖是一個示例:

 

圖3:狀態轉換描述表 

圖4:狀態轉換描述表對應的流程圖

  圖3是狀態轉換描述的一種實現示例,其對應的流程圖如圖4所示。圖3中'source'表示源狀態;'trigger'表示觸發事件,對應界面上的按鈕; 'dest'表示目標狀態;'trans_condition'表示完成狀態轉換需要滿足的條件;'trans_action'表示狀態轉換時需要執行的操作。狀態轉換描述表由狀態機引擎解析,這樣每個項目只要定義自己的狀態轉換描述表就可以確定項目對應的事務處理流程。

  平台采用三級的頁面結構,按層級關系分為項目群首頁、單個項目主頁和具體問題單頁面。

  首頁列出了每個項目的項目名稱,該項目下分配給當前賬號的待處理問題個數等 信息,此外還可以管理項目,創建項目下的問題,以及注冊為特定項目的用戶等,如圖5所示。

 圖5.項目群首頁

  項目群主頁上點擊項目名稱可以進入具體的項目主頁;項目主頁中列出了分配給當前用戶的待處理條目,以及當前用戶的監視條目,如圖6所示。所謂監視條目就是 其他人在處理,但是當前用戶比較關心的問題;比如某重大問題由人員 A 處理並使用該系統進行跟蹤,並將最新的處理進展更新到系統中的問題單里,A 的直接主管可以監視該問題單以及時了解問題的最新進展,避免了各種匯報帶來的整理材料和溝通成本; 若某重大問題的關鍵階段已處理完成,只有一些瑣碎的收尾工作,則主管可以隨時取消監視問題,交由 A 處理即可。項目首頁的右半部分畫出了當前項目的處理流程,該流程圖根據項目的狀態轉換表自動生成。

 圖6.具體的項目主頁

  項目主頁點擊問題概要可進入具體問題單頁面,其左半部分是問題單字段信息,上方有監視問題和取消監視兩個按鈕用於監 視和取消監視該問題(監視功能介紹見上文);右半部分是問題單的管理信息,包括創建時間、創建人、當前處理人、當前狀態等,如圖7所示。問題單當前狀態下所能執行的操作由項目流程定義,比如在” 維護人員處理” 狀態下所能執行的操作是” 更新進展” 和” 提交審核”,前者只更新字段信息,后者將問題處理結果提交給維護代表審核,分別對應問題單界面下方的兩個按鈕。

圖7.具體問題單頁面

  2.工作流平台在日常工作中的應用示例:

  團隊項目開發過程中涉及下列事務:

  1. 測試問題跟蹤
  2. 代碼檢視記錄;
  3. 版本發布記錄;
  4. 各種匯報材料管理
  5. 調試設備信息、編碼注意事項等雜事記錄

  上述事務中有些需要歸檔記錄以便隨時查閱,比如版本發布記錄、編碼規范、代碼檢視記錄以及調試設備信息、相關人員聯系方式之類雜項記錄等;有些只需要完成處理即可,比如分解的子功能點開發、測試過程中遇到的一般問題等。這些事務如果沒有統一的平台進行管理,多名開發之間的協作,開發、測試、項目管理等不同角色之間的溝通,上下級間的匯報等都會帶來很高的溝通成本。

  為此在工作流平台中創建了三個項目:

  1. 任務跟蹤:用於跟蹤從需求分解出的子功能點開發、測試過程中遇到的一般問題等,處理完后即可關閉,不再顯示在界面上。
  2. 開發記錄:用於記錄調試設備信息、相關人員聯系方式之類雜項記錄等,不要關閉,一直顯示在界面上用於相關人員查閱。
  3. 代碼走查:用於歸檔代碼走查記錄。

  這三個新增項目的三級頁面結構見圖8-14。

圖8.項目群首頁最后添加三個項目

圖9.任務跟蹤項目主頁

 圖10.任務跟蹤項目的具體問題 

 圖11.開發記錄項目主頁  

  圖12.開發記錄項目中的具體問題 

圖13.代碼走查項目主頁

圖14.代碼走查項目中的具體問題

  此外,平台中每個項目都支持權限管理,平台中數據與EXCEL之間導入、導出等,如下圖。還有的項目支持繪圖,詳見https://www.cnblogs.com/leituhaomo/p/11784600.html

 圖15.代碼走查項目導出到表格的問題

  除用於項目管理外,工作流平台還可以拓展其他方面的應用,如問政反饋、掃碼點餐、請假審批、物流信息跟蹤等。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM