今天不談DevOps的開源技術工具鏈，而是從敏捷開發(fā)和研發(fā)過程效能改進的角度再來回顧下DevOps研發(fā)運維一體化和研發(fā)效能改進。

在前面我專門寫過一篇文章，里面有個核心觀點，即：

不要期望通過DevOps各種工具鏈技術來解決研發(fā)效能和過程管理中存在的問題，研發(fā)效能提升有一個核心還是軟件工程域和過程管理最佳實踐。

敏捷和精益各在強調(diào)什么？

大家對敏捷方法論都比較熟悉，特別是當前主流的Scrum敏捷研發(fā)方法論。而敏捷方法論的核心如果用一個詞就是短周期迭代。

為了短周期迭代，你必須將大塊的用戶需求輸入進行拆解為條目化的UserStory，為了確保迭代版本可交付，你需要持續(xù)集成，可視化進度看板等。通過短周期迭代，你具備了一個關鍵的敏捷能力，即快速地適應變化和自我調(diào)整能力。

敏捷得快，一個是響應變化快，一個是自身的生產(chǎn)加工過程也快，效率高。所以你看到在軟件研發(fā)過程中各種自動化工具的引入，自動化的流水線，持續(xù)集成等實際都是提升這個效率服務。

再回來看精益，精益的一個核心是減少浪費。

而軟件開發(fā)過程中的浪費實際體現(xiàn)在幾個方面。

其一是減少任何不必要的輸出工件，所有的工件輸出本身都要有價值，不要為了輸入而輸出，為了文檔而文檔。要提倡源代碼就是文檔。

其二是減少返工，所有的返工，不論是需求變更引起的，還是Bug修改等，都是COPQ壞質(zhì)量成本，都是對資源的極大浪費，同時又拉長了交付周期。

其三是減少人員等待，任何一個研發(fā)項目和研發(fā)過程，如果你在整體計劃和任務分解中，導致出現(xiàn)了大量的人員閑置和等待，那么本身就是一種巨大的浪費。

對于第三點減少人員等待或閑置本身是一個技術活，考驗的是項目經(jīng)理或架構(gòu)師的任務分解能力，如何通過恰當?shù)慕巧止ず腿蝿辗纸猓軌蜃屗械娜藛T并行工作，并減少相互之間的依賴。

推式生產(chǎn)和拉式生產(chǎn)，流水線和看板

在談敏捷和精益生產(chǎn)的時候，經(jīng)常會談到看板文化，基于用戶和市場需求的拉式生產(chǎn)模式。看板解決了一個關鍵的可視化和進度跟蹤問題。而拉式生產(chǎn)模式解決了零庫存和減少浪費的問題。

回到敏捷研發(fā)和看板，也是同樣的道理。

敏捷團隊中的每一個人實際都應該時刻知道我有哪些todo list，我需要做的就是將我待辦的任務按規(guī)范和質(zhì)量要求盡快做完，并快速地朝下游傳遞。比如一個開發(fā)人員應該隨時能夠看到自己的待辦清單。有哪些功能點要開發(fā)，有哪些Bug要修改等。

對每個角色都是，我只需要關注我的todo，并盡快完成。

任何一個任務在上游角色完成相關工作后，通過流水線都能夠做到自動化地推送到下游活動節(jié)點。這個節(jié)點可以是自動化機器節(jié)點，也可以是需要人工進入處理的工作節(jié)點。

流水線起到的關鍵作用就是基于上下游的任務活動協(xié)同關鍵，將多個任務編排為一個完整的整體，并做到自動化或半自動化執(zhí)行，同時隨時可以監(jiān)控其進度和狀態(tài)。

那么流水線的效率體現(xiàn)在哪里？

流水線的效率不僅僅體現(xiàn)在自動化的程度，而是體現(xiàn)在流水線運行過程中各種閑置或等待時間的多少。比如一個開發(fā)過程流水線，到了開發(fā)階段后開發(fā)人員始終都無事可做而處于等待狀態(tài)，那么流水線效率就不可能高效。

所以再回顧下DevOps流水線。

代碼Checkin-》編譯-》構(gòu)建-》打包部署-》環(huán)境遷移

這個并不是一個完整的開發(fā)過程流水線，因為這個流水線并沒有體現(xiàn)需求人員，開發(fā)人員，測試人員的任務和活動。

完整的研發(fā)流水線一定是自動化+人工參與結(jié)合的一個大流水線。實現(xiàn)從用戶需求進來，到最終完成IT應用的功能交付的完整過程。

這里面不是簡單地持續(xù)集成，重點是架構(gòu)，開發(fā)，測試，工程運維人員之間的高效協(xié)同，同時在協(xié)同過程中如何建設依賴。

從條目化需求到文檔結(jié)構(gòu)化

在Scrum敏捷方法論里面，條目化始終是一個重點強調(diào)的內(nèi)容。

條目化本身就意味著更好的結(jié)構(gòu)化。

敏捷方法論過程改進，最好的思路就是所有文檔都要結(jié)構(gòu)化和條目化掉，而不是再去輸出冗長非結(jié)構(gòu)化的word文檔。

我們都知道在軟件開發(fā)中的需求文檔往往是Word形式的非結(jié)構(gòu)化內(nèi)容，一個需求文檔往往會實現(xiàn)多個用戶需求并分解為多個用例，由于沒有結(jié)構(gòu)化我們管理和變更的單元都將是以一份文檔為準。而現(xiàn)在結(jié)構(gòu)化的文檔開發(fā)工具可以使文檔開發(fā)工作結(jié)構(gòu)化，通過結(jié)構(gòu)化后可以對文檔的管理顆粒度粒度從一個Word文件喜歡到一個具體的用例或用戶故事，而這不僅僅是帶來了版本控制和多人文檔協(xié)作的方便，更重要的是文檔開發(fā)過程的一個重要變更。

在軟件開發(fā)中需求的端到端管理中，我們對用戶需求，產(chǎn)品需求，軟件需求都可以拆分為條目化管理，并且實現(xiàn)條目化需求的狀態(tài)跟蹤和需求追蹤。通過需求追蹤保證需求實現(xiàn)的完整性，方便跟蹤需求實現(xiàn)狀態(tài)，同時為后續(xù)的需求變更分析提供有利的影響范圍識別。

需求可以條目化，測試用例也可以條目化，比較困難的就是設計內(nèi)容如何進行條目化管理。架構(gòu)設計的內(nèi)容放到哪個層次和級別。在微軟的SCRUM實踐里面我們也看到了通過UserStory驅(qū)動的需求跟蹤和管理。為了方便條目化我們又可以解決FDD里面的最佳實踐通過領域模型分析找出具體的特征點，而特征點就是一個細粒度的可以從需求一直管理到測試的最小單位。我們的實現(xiàn)過程追蹤，狀態(tài)跟蹤，版本管理和控制都可以以這個為單位進行管理。這樣在我們實現(xiàn)的過程中，在關心某一個具體的功能點的時候很容易的就能夠獲取到有關該功能點從頭到尾的全部信息，包括每次變更的相關信息也可以很容易獲取到。

當我們向客戶按階段交付文檔的時候如何處理呢？這個其實在結(jié)構(gòu)化文檔開發(fā)工具里面已經(jīng)有了，即可以根據(jù)我們的不同配置規(guī)則，根據(jù)預定的文檔生成格式，自動的抽取相應的內(nèi)容來生成出我們需要的文檔?？梢钥吹皆谡麄€過程中我們不會再去專門強調(diào)文檔這個概念，而是更加強調(diào)業(yè)務功能和用例，特征值和需求管理和跟蹤的概念，文檔僅僅是我們在各個階段思考過程的一種記錄后的整合，我們隨時的思考和實現(xiàn)思路都應該隨時的記錄，而不是到后面再來補文檔。

我們可以看到，現(xiàn)在一些SCRUM的敏捷項目管理工具已經(jīng)具備了結(jié)構(gòu)化的UserStory管理和跟蹤的能力，而這正是結(jié)構(gòu)化文檔開發(fā)的一個雛形。

即不再依賴word去輸出需求文檔，而是應該直接在敏捷研發(fā)和過程管理工具中編寫每一個userStory，對其業(yè)務場景，流程，規(guī)則，界面UI等進行詳細說明。當然從一個大IT系統(tǒng)構(gòu)建的整體性層面，我們?nèi)匀粫Ａ羯倭康恼w業(yè)務流程，整體架構(gòu)方面的介紹。

那么如果最終需要向客戶交付完整的需求文檔如何辦？

簡單來說應該是我們選擇需要交付的模塊和功能點，然后通過勾選的內(nèi)容自動化的生成最終的word文檔。也就是最終交付的文檔應該是通過配置的方式動態(tài)生成的。

從產(chǎn)品結(jié)構(gòu)，WBS分解到任務活動

我們可以回顧下一個微服務架構(gòu)下前后端分離開發(fā)模式，任何一個需求點過了，實際都可以分解為如下幾個任務。

• 需求和原型開發(fā)
• 前端開發(fā)
• 后端開發(fā)和數(shù)據(jù)庫設計
• 測試設計
• 測試執(zhí)行

如果你是用的傳統(tǒng)開發(fā)模式，那么可能分解為如下幾個任務：

• 需求開發(fā)和文檔編寫
• 功能設計和數(shù)據(jù)庫設計
• 編碼和自測
• 測試設計
• 測試執(zhí)行

什么意思呢？

對于一個條目化的需求自然會對應到相應的需求開發(fā)，設計，編碼和測試等任務。對于PBS產(chǎn)品結(jié)構(gòu)分解處理的最底層的模塊或單元結(jié)合WBS模板都會產(chǎn)生這些WBS條目。

這就是一個簡單的交叉相乘的過程。

1. 對于總體設計任務不需要根據(jù)具體的模塊和單元進行分解。
2. 對于集成測試任務如何來產(chǎn)生的問題

解決了以上兩個問題，基本上就可以自動生成相應的WBS。而且我們還可以根據(jù)過程定義和裁剪來選擇哪些條目應該生成，哪些不應該生成。比如可以裁剪掉單元測試，則就不自動生成相應的單元測試任務?；谝陨峡紤]可以參考下圖的例子，左邊為WBS模板，右邊為一個簡單的PBS分解。

其中PBS中黃色的為最底層的模塊或單元，都需要和左邊的WBS模板相乘得到相應的WBS條目。對于集成測試任務的生成，可以看到滿足存在葉子節(jié)點，且葉子節(jié)點大于1個的都需要生成集成測試任務。因此根據(jù)該方式可以生成如下實際的WBS分解

同時在生成的過程中我們還可以建立根據(jù)生命周期模型建立WBS條目任務之間的關聯(lián)和依賴關系，設置每各WBS條目的類型。模板化每個條目和任務的輸出格式，責任人等內(nèi)容。

在實現(xiàn)了這一個步驟后，我們接著可以考慮的問題就是受崗位角色分工和資源約束限制條件下的自動排程。在供應鏈管理中我們可以通過建立模型和目標約束來實現(xiàn)最優(yōu)的排程，在軟件項目進度計劃的編制中應該同樣是可以的，這種方式將通過約束理論，目標規(guī)劃和計算機模型來選擇可行的進度方案。而不是根據(jù)簡單的根據(jù)關鍵路徑和資源平衡來制定進度。

以上自動生成規(guī)則并不復雜，但是當前的各類Scrum敏捷項目管理工具往往并不支持這種自動化生成規(guī)則。