華爲雲MVP黃雋：從排斥到佈道者，敏捷的正確打開方式是什麼
（原標題：華爲雲MVP黃雋：從排斥到佈道者，敏捷的正確打開方式是什麼）
黃雋：
華爲雲MVP，十餘年IT從業經驗，中國DevOps社區核心組織者、敏捷江湖桃花島社區創始人。熱衷並致力於精益敏捷、DevOps、過程改善、項目和團隊管理等工作。曾擔任過敏捷專家、資深過程改善顧問、項目經理、副總經理等服務於多家世界五百強和大型集團。作爲DevOps&敏捷的實踐和推行者，努力搭建從現狀通向未來的橋樑，構建共贏生態。
華爲雲MVP黃雋
敏捷這個詞雖然被很多開發人員掛在嘴邊，但真正理解並能用敏捷解決實際問題的其實少之又少。
很多公司開始實踐敏捷，但多數被僞敏捷折騰一痛，失敗告終。
爲什麼會這樣？難道敏捷出了問題，或者說敏捷轉型有這麼多痛點，敏捷還適合軟件開發嗎？
在敏捷專家黃雋看來，"如果本身對敏捷開發就存在誤解，這很容易導致錯誤的實踐方式。"
那麼，敏捷的正確打開方式是什麼？且聽黃雋慢慢道來。
與敏捷結緣
黃雋最開始接觸敏捷時，其實是有點排斥的，因爲他一直處於傳統開發模式狀態下，一時很難改變傳統軟件開發的固定思維模式。
直到2012年初，當時在IBM工作的他，接觸了非常多的相關培訓和實踐，隨着瞭解的深入，黃雋逐漸跳出了當初的思維定式，對敏捷產生深厚的興趣。
黃雋認爲，"敏捷開發只是一個指導思想和原則，並沒有給出具體的實施步驟。在實際工作中，如果企業只是覺得不用敏捷好像很老土，一再對外強調敏捷開發是沒有意義的。重要的是在敏捷原則和核心價值觀的指引下，哪些實踐和方法可以幫助達到目標，或者如何解決這些問題從而達到目標。"
在從事敏捷開發過程中，黃雋看到許多企業因爲認知偏差走進了死衚衕，更加堅定了他的敏捷開發之路。
也正是因爲一直從事敏捷開發工作，黃雋機緣巧合下接觸到了華爲雲軟件開發雲DevCloud。
DevCloud是集華爲研發實踐、前沿研發理念、先進研發工具爲一體的研發雲平臺，它面向開發者提供研發工具服務，讓軟件開發簡單高效。
"和華爲雲幾位敏捷專家分享佈道的日子裡，接觸了很多企業用戶、老闆、高校教師和領導，更深刻的瞭解到企業轉型和高校產教融合的很多痛點，一種要幫助解決痛點的責任油然而生。"黃雋笑言，"隨後，我們就一起創建了'敏捷江湖桃花島社區'，專門解決敏捷和DevOps轉型痛點問題。"
在諸多轉型問題中，黃雋發現多數企業有一個共性的難題：研發團隊經常會提到的Backlog管理問題，特別是那些突發性的工作應該如何管理。
下面黃雋將對提到的這些痛點問題做詳細闡述，從事研發的團隊可以參考。
研發團隊如何管理瑣碎、突發性工作？
先看看解決方案思路：管理好工作項是解決問題的核心，那麼在形成工作項之前，我們需要解決誰對工作項負責或者說工作項來源的問題，然後要針對工作項做好工作計劃，這樣開發團隊才能很好的執行。
第四，回顧總結，選出改善點，下個迭代做得更好。
另外，同步需要進行的是人才的培養，向跨職能型團隊努力。解決方案思路示意圖如下：
解決方案思路示意圖
剖析解決方案，一步步解決Backlog管理問題
1、明確需求責任人
一方面，需求責任人必須很好地理解項目中的利益干係人、客戶和用戶的需要（包括前面提到的突發工作項）及其優先級。
同時，需求責任人還要在版本、迭代和Backlog層面都持續做出良好的經濟決策，管理經濟效益。爲了統一叫法、便於理解，後面需求責任人都由產品經理充當（類似Scrum框架中的產品負責人）。
總結一下，產品經理的主要職責如下圖所示：
產品經理主要職責圖
產品經理需要與利益干係人充分溝通，確定這些突發的工作優先級別，同時從業務價值和管理經濟效益等維度考慮，明確是否一定要在本迭代中完成。一旦確定這些突發工作屬於高優先級，必須在本迭代中完成，那就需要重新梳理工作項了。
2、梳理產品待辦列表
梳理產品待辦列表，就是將高優先級的工作項放到迭代待辦列表中先做。下圖說明了通過梳理活動改變Backlog的結構：
梳理活動改變Backlog的結構圖
梳理後，對應DevCloud中的體現：
DevCloud梳理活動結果圖
產品經理梳理後，如圖高亮部分，突發性培訓任務的工作項得到了合理的優先級，同時它是被細化的，而且是經過工作量估算的。
產品經理是梳理活動的最終決策者，優秀的產品經理能夠充分協調利益干係人，安排足夠的時間，並根據團隊的特點和項目類型來開展梳理活動。同時團隊還要估算新加入突發工作的工作量，幫助產品經理根據技術依賴關係和資源約束排列工作項的優先順序，如果新加入突發性培訓任務的工作項優先級高，那麼就會納入本迭代代辦列表中。
3、重新定計劃
重新定計劃，確保團隊容量適合，合理更新迭代目標。
敏捷宣言中提倡"響應變化高於遵循計劃"，盲目的相信計劃往往會讓我們忽視"計劃可能有錯"這個事實。
在敏捷開發過程中，目標是快速重新制定計劃並根據開發過程中不斷出現的、具有重要經濟價值的信息進行調整。原計劃準備做的工作項可能被移入到下一個迭代中實現，這裡體現的是"等價交換原則"，意思是用優先級高的突發性工作項，替掉了同等工作量的其它工作項，這也是爲了保證團隊按照穩定的節奏交付，等價交換示意圖如下：
等價交換示意圖
具體在DevCloud中的體現，如等價交換圖一和等價交換圖二所示。
等價交換圖一
等價交換圖二
最後，從迭代中選取差不多工作量的低優先級工作項移回到Backlog中，即在DevCloud中完成了工作項的等價交換。
4、迭代回顧，識別改善點
幾個迭代下來，需要對這類突發工作進行度量分析，識別改善點，持續改善。雖然我們提倡響應變化高於遵循計劃，但執行迭代的時候也需要團隊在不受干擾的情況下全力以赴。因此，就得思考爲什麼每個迭代中都有外界的干擾（突發工作）存在，團隊共同分析和找到辦法纔是解決問題之道。
這裡給出一個DevCloud的小實踐，可以提供客觀數據幫助回顧。
新納入迭代待辦列表的突發性工作項可以在DevCould的"模塊"下進行管理。也就是說，在新建User Story之前建立一個"突發任務"模塊。這是爲了在後續幾個迭代中對這類突發性工作進行度量分析，爲持續改善做準備。
圖：新建突發模塊圖
圖：新建User Story圖
選擇報表—新建報表—自定義報表—增加篩選條件（模塊）—按迭代維度—保存。然後對統計出來的數據進行分析，可以以圖和表兩種方式展示。
圖：按圖展示圖
圖：按表展示圖
5、同步進行人才培養
如果團隊成員都是T型技能的時候，每個任務都有好幾個人可以做，那麼團隊就能夠在迭代執行期間全力完成制約工作項流程的任務，更靈活地平衡資源，使團隊更高效。
所以，同步需要進行的是人才的培養，向跨職能型團隊努力。不僅僅可以應對處理突發性工作，而是讓團隊更高效。
以上就是黃雋對於敏捷開發中，研發團隊如何管理瑣碎、突發性工作的一些思考。總而言之，降低或解決突發性工作對團隊的干擾非常重要，它直接影響團隊工作的進度和速率，間接影響迭代目標是否能完成，甚至整個項目的成敗。所以，一定要重視並想辦法一勞永逸解決它。