今天不談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)理或架構師的任務分解能力，如何通過恰當?shù)慕巧止ず腿蝿辗纸?，能夠讓所有的人員并行工作，并減少相互之間的依賴。
推式生產(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-》編譯-》構建-》打包部署-》環(huán)境遷移
這個并不是一個完整的開發(fā)過程流水線，因為這個流水線并沒有體現(xiàn)需求人員，開發(fā)人員，測試人員的任務和活動。
完整的研發(fā)流水線一定是自動化+人工參與結合的一個大流水線。實現(xiàn)從用戶需求進來，到最終完成IT應用的功能交付的完整過程。
這里面不是簡單地持續(xù)集成，重點是架構，開發(fā)，測試，工程運維人員之間的高效協(xié)同，同時在協(xié)同過程中如何建設依賴。
從條目化需求到文檔結構化
在Scrum敏捷方法論里面，條目化始終是一個重點強調(diào)的內(nèi)容。
條目化本身就意味著更好的結構化。
敏捷方法論過程改進，最好的思路就是所有文檔都要結構化和條目化掉，而不是再去輸出冗長非結構化的word文檔。
我們都知道在軟件開發(fā)中的需求文檔往往是Word形式的非結構化內(nèi)容，一個需求文檔往往會實現(xiàn)多個用戶需求并分解為多個用例，由于沒有結構化我們管理和變更的單元都將是以一份文檔為準。而現(xiàn)在結構化的文檔開發(fā)工具可以使文檔開發(fā)工作結構化，通過結構化后可以對文檔的管理顆粒度粒度從一個Word文件喜歡到一個具體的用例或用戶故事，而這不僅僅是帶來了版本控制和多人文檔協(xié)作的方便，更重要的是文檔開發(fā)過程的一個重要變更。
在軟件開發(fā)中需求的端到端管理中，我們對用戶需求，產(chǎn)品需求，軟件需求都可以拆分為條目化管理，并且實現(xiàn)條目化需求的狀態(tài)跟蹤和需求追蹤。通過需求追蹤保證需求實現(xiàn)的完整性，方便跟蹤需求實現(xiàn)狀態(tài)，同時為后續(xù)的需求變更分析提供有利的影響范圍識別。
需求可以條目化，測試用例也可以條目化，比較困難的就是設計內(nèi)容如何進行條目化管理。架構設計的內(nèi)容放到哪個層次和級別。在微軟的SCRUM實踐里面我們也看到了通過UserStory驅(qū)動的需求跟蹤和管理。為了方便條目化我們又可以解決FDD里面的最佳實踐通過領域模型分析找出具體的特征點，而特征點就是一個細粒度的可以從需求一直管理到測試的最小單位。我們的實現(xiàn)過程追蹤，狀態(tài)跟蹤，版本管理和控制都可以以這個為單位進行管理。這樣在我們實現(xiàn)的過程中，在關心某一個具體的功能點的時候很容易的就能夠獲取到有關該功能點從頭到尾的全部信息，包括每次變更的相關信息也可以很容易獲取到。
當我們向客戶按階段交付文檔的時候如何處理呢？這個其實在結構化文檔開發(fā)工具里面已經(jīng)有了，即可以根據(jù)我們的不同配置規(guī)則，根據(jù)預定的文檔生成格式，自動的抽取相應的內(nèi)容來生成出我們需要的文檔?？梢钥吹皆谡麄€過程中我們不會再去專門強調(diào)文檔這個概念，而是更加強調(diào)業(yè)務功能和用例，特征值和需求管理和跟蹤的概念，文檔僅僅是我們在各個階段思考過程的一種記錄后的整合，我們隨時的思考和實現(xiàn)思路都應該隨時的記錄，而不是到后面再來補文檔。
我們可以看到，現(xiàn)在一些SCRUM的敏捷項目管理工具已經(jīng)具備了結構化的UserStory管理和跟蹤的能力，而這正是結構化文檔開發(fā)的一個雛形。
即不再依賴word去輸出需求文檔，而是應該直接在敏捷研發(fā)和過程管理工具中編寫每一個userStory，對其業(yè)務場景，流程，規(guī)則，界面UI等進行詳細說明。當然從一個大IT系統(tǒng)構建的整體性層面，我們?nèi)匀粫Ａ羯倭康恼w業(yè)務流程，整體架構方面的介紹。
那么如果最終需要向客戶交付完整的需求文檔如何辦？
簡單來說應該是我們選擇需要交付的模塊和功能點，然后通過勾選的內(nèi)容自動化的生成最終的word文檔。也就是最終交付的文檔應該是通過配置的方式動態(tài)生成的。
從產(chǎn)品結構，WBS分解到任務活動
我們可以回顧下一個微服務架構下前后端分離開發(fā)模式，任何一個需求點過了，實際都可以分解為如下幾個任務。
- 需求和原型開發(fā)
- 前端開發(fā)
- 后端開發(fā)和數(shù)據(jù)庫設計
- 測試設計
- 測試執(zhí)行
如果你是用的傳統(tǒng)開發(fā)模式，那么可能分解為如下幾個任務：
- 需求開發(fā)和文檔編寫
- 功能設計和數(shù)據(jù)庫設計
- 編碼和自測
- 測試設計
- 測試執(zhí)行
什么意思呢？
對于一個條目化的需求自然會對應到相應的需求開發(fā)，設計，編碼和測試等任務。對于PBS產(chǎn)品結構分解處理的最底層的模塊或單元結合WBS模板都會產(chǎn)生這些WBS條目。
這就是一個簡單的交叉相乘的過程。
- 對于總體設計任務不需要根據(jù)具體的模塊和單元進行分解。
- 對于集成測試任務如何來產(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ī)則。
]]>編輯導語：結合敏捷項目管理，產(chǎn)品經(jīng)理或業(yè)務人員可以一定程度上推動項目的快速運行，實現(xiàn)降本增效，并推動后續(xù)項目的優(yōu)化迭代。那么，若想實現(xiàn)敏捷項目管理，你應當具備哪些思維方式、或者拿出什么舉措？本文作者做了相應解讀，一起來看。
一、什么是敏捷項目管理
敏捷管理如果用一句話高度概括就是：面對高度不確定的事件，思維、行動，快速反應、快速應對，并作出正確選擇的行為，稱之為敏捷。
如果再精煉的概括一下，那就是“對、好、快”。PO確保做對的事，SM負責快速推進，DT保證正確地做事。
二、敏捷管理都有哪些具體措施
1. 思維方式的徹底轉(zhuǎn)變
實施敏捷管理前，最重要的一步就是給大家“洗腦”，讓大家從傳統(tǒng)的開發(fā)模式上徹底轉(zhuǎn)變到敏捷思維的開發(fā)模式中，只要先從思想上進行徹底改變，才能在日后的身體力行中去積極實踐。
而轉(zhuǎn)換思維，就先要讓大家深刻理解敏捷的價值觀，而敏捷價值觀就是：
大家可能覺得這個敏捷價值觀有點“混沌”，我給大家翻譯一下，大家就一目了然了。
第一條，敏捷管理注重以人為本，因為人才是整個項目的核心“資產(chǎn)”。二戰(zhàn)時，為什么美國從歐洲瘋狂搶人才？蘇聯(lián)解體時，為什么中國從烏克蘭瘋狂搶各類技術人才？都是這個道理，因為有了人才，才有辦好事的“源動力”。
第二條，可用的軟件是指交付物，意思是說我們最終交付給客戶的東西必須是高價值，有用的。如果竟是“反人類”的操作，文檔寫的再好又有什么軟用？
第三條以客戶為中心，這句話就很講究了，為什么不是以用戶為中心？因為敏捷管理思想的推出，是建立在B端的甲乙雙方這個邏輯框架下的（當然有些內(nèi)容也適合C端）。
在B端市場中，很多能拍板買你軟件的和最終使用你產(chǎn)品的是兩波不同的人。我們軟件開發(fā)要優(yōu)先滿足“客戶”，再去滿足“用戶”。如果你設計了一個讓用戶很爽的功能，到時候客戶不滿意，那恐怕到時候回款的時候就懸了。
舉個最簡單的例子，你給甲方爸爸開發(fā)了一個企業(yè)內(nèi)部的IM，老板要求顯示員工已閱信息，但是你為了尊重用戶個人隱私生活空間，就沒有這個功能，那老板心里肯定不舒服，以后合同還怎么續(xù)簽。
第四條，擁抱變化我就不細講了，這個世界唯一不變的就是“變化”。
除此之外，我們在今后的行事過程還要遵循敏捷的12條原則，具體見下圖：
你可能看后，第一感覺就是：WTF，東一榔頭，西一棒槌的，說的什么玩意，雖然列了1234，但還是感覺沒有邏輯感。
沒錯，當時我就是這個感覺。為了能夠讓大家能夠把他嚼碎了往肚里咽，我給大家做了一下抽象概括和歸納總結。其實12條原則這么多話，概括起來就是一句話（我最煩那種簡單問題復雜化的人）：
以人為本，高效溝通，以目標為導向，不斷自我進化，通過快速迭代的形式為客戶交付高價值的軟件。
具體我是怎么抽象概括起來的，還要歸結于歸納法，看似他把事情說了那么多多，但是好多東西都是同一個主題，具體如下：
歸納完我們發(fā)現(xiàn)，說了一大通，原來就是在敏捷價值觀中加了“高效溝通、自我進化、快速迭代”。這樣一梳理就簡單明了多了（感覺哥這總結能力，可以裸考ACP了-捂臉）。
2. 構建敏捷管理團隊
敏捷管理團隊的構建有點像管理學中，變“直線式管理” 為 “矩陣式管理”的意思。
之所以要構建敏捷的管理團隊，就是要幫助團隊去除“政治化、部門墻”等障礙，從而實現(xiàn)扁平管理，高效溝通的目標。其中最好的形式就是構建一個10人內(nèi)的小組，把大家的座位集合到一起，方便日常面對面的溝通與協(xié)調(diào)，從而免去過往冗長的各種流程。
3. 實施增量式迭代開發(fā)
我們拿造汽車舉例說明一下增量式思維和增量迭代式思維的區(qū)別。傳統(tǒng)的開發(fā)模式都是增量式思維，這次交付一個輪子，下次交付一個車身等等，每一次交付的東西都不能直接滿足用戶的交通行程需求。
而增量式迭代思維，是這次交付一個滑板，下次交付一個自行車，再交付你一個小汽車，每次給你的交付物用戶都可以正常使用，這便是Minimum viable prodouct（最小可行產(chǎn)品）思維。
反觀微信的成長史，他的快速成長史便是用了這種思維。首次上線的微信，只有一個聊天的功能，而且頁面粗糙，但是隨著快速迭代以及張小龍對人性和商業(yè)的深刻洞察，微信逐漸從通訊工具到信息平臺再到生活入口，一步步壯大起來。
微信歷次大版本迭代內(nèi)容：
- 微信的1.0版本，就是一個在熟人之間可以免費發(fā)文本信息和圖片的工具。
- 微信的2.0版本，增加了微信的語音功能和“查找附近陌生人”的功能，到這里，微信成為了陌生人語音社交的工具，但還是個工具，卻實現(xiàn)了用戶的爆發(fā)式增長。
- 微信3.0版本的時候推出了“掃一掃”、“服務號”，從這個點開始，微信開始連接世界。
- 在4.0版本的時候，微信推出了“朋友圈”，微信從通訊工具開始進化，變成了社交平臺。
- 微信的5.0版本，加上了“綁定銀行卡”，對微信來說有一個巨大躍升，成為了今天的移動生活場景，甚至是移動商業(yè)帝國。
- 在6.0中推出了群紅包和小視頻。
- 在7.0版本主要是增加了即刻視頻和做一些小優(yōu)化。
- 微信的8.0版本迭代登頂了熱搜，增加了“視頻號”和“直播”，但在外界看來，這是對快斗圍追阻截的絕地反擊。
4. 借力敏捷管理工具
有句老話說得好，叫做“君子性非異也，善假于物也”。能夠巧妙地借助外力，是大多數(shù)成功人士取得輝煌成就的重要因素之一。在敏捷項目管理中更是如此。能夠助力敏捷管理的軟件有PingCode、Jira等，這里我詳細介紹一下PingCode。
作為國內(nèi)最標準的Scrum 產(chǎn)品，PingCode不僅支持Scrum框架所必需的基本元素，而且?guī)缀跄軌蚪鉀Q所有敏捷項目管理相關的問題，并且還支持通過插件來補充實現(xiàn)與其他主流開發(fā)工具的打通，以實現(xiàn)敏捷開發(fā)過程中的需求管理、測試管理、缺陷管理、項目集管理、目標管理、知識庫管理、自動化管理等全過程管理。
5. 積極擁抱變化
敏捷之所以產(chǎn)生，很大程度上就是來源于對管理變化的探索。現(xiàn)實中很多變化來源于不確定性，而不確定性總是和風險相關的，所以敏捷項目擁抱變化也就意味著與風險共處，擁有了管理變化的能力，也就擁有了管理風險的能力。而擁抱變化主要有如下三種措施：
1）識別什么樣的變化能帶來真正的風險
在項目管理中，通常會遇到兩種變化。第一種是預期內(nèi)的變化，這種相對來說好處理或者說風險并不是很大，我們一定要提前做好應對方案。
第二種是預料之外的變化，他無法預測和判斷，不確定性很高，也很難從過往經(jīng)驗里找到最佳解決方案。這種變化是項目管理的關鍵，因為它帶來的是真正的風險。而這種變化一旦發(fā)生，不僅可能推翻我們原有的計劃，使我們努力的成果和正在努力的事情從頭來過，甚至連最初制定的方向和目標都要發(fā)生變化。
遇到這種情況，管理者最應該做的事情就是：快速行動，識別原因，驗證假設，評估風險，尋找辦法，甚至需要設計出一個新的方案。
2）如何管理不確定性帶來的變化
在我看來主要有以下三點：
- 事前時刻準備，不間斷地去診斷和評估現(xiàn)狀。
- 事中及時響應，快速找到新的平衡，設計出針對性的解決方案。
- 事后回顧、反思、復盤、總結，讓發(fā)生的事情成為經(jīng)驗的一部分。
3）在變化面前，應該擁有怎樣的心態(tài)
① 要有開放的心態(tài)，充分認識到變化的必然性。
② 敢于擔當，有的時候你會發(fā)現(xiàn)客戶也陷在不確定性里，不知道如何應對變化或者并不清晰自己想要什么，很多時候團隊會選擇等待，目睹客戶在猶豫中錯失良機或構成發(fā)布質(zhì)量的隱患，這個時候需要我們主動擔當起來，做好向上管理，幫助客戶一起并肩前行。
③ 不斷成長，事情是不斷變化的，事情的發(fā)展更多取決于人的選擇方向和努力程度，積極的心態(tài)和精益求精的追求能在很大程度上改變事情發(fā)展的方向和結果。
三、寫在最后
雖然敏捷管理是未來大勢所趨，并且有著諸多好處，但是，我們切忌大搞“大躍進”式的揠苗助長，否則未因敏捷而生，卻先因敏捷而死。敏捷管理的實施是漸進式的，初期我們可以先以混合開發(fā)為主，慢慢地切入到敏捷管理的主軌道上，讓其穩(wěn)步著陸，如此才能讓敏捷管理成為公司業(yè)務增長的增強發(fā)動機。
本文由 @B端實戰(zhàn)訓練營 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
]]>