【敏捷江湖桃花島】華山論劍第三期問答精選

主講人：姚冬，華為云DevCloud首席技術布道師；資深DevOps與精益/敏捷專家、軟件工程專家；中國DevOps社區核心組織者；中國DevOpsDays大會核心組織者。

問答一：

八戒：在企業的DevOps轉型當中，一般都會伴隨組織機構和業務的重組，在這個重組的過程中，傳統的瀑布項目走出來的項目經理要如何重新定位自己，才能更好的幫助自己適應這種變化？

姚冬老師：核心一點就是傳統的項目經理更多的是項目的思維，實際上我們更應該轉變到產品的思維。這里有幾個方面，第一，項目的思維是典型的甲乙方簽一個工作說明書，每一期做的事情都是相對比較固定的，我們會跟甲方有一個談判的過程，這是一種交付的方式，等到項目完成以后，這一批人就會分散到下一個項目當中去。而產品思維的團隊相對比較固定，由于團隊本身內部的磨合，人員之間的相互信任，包括溝通協作的方式，其實是非常難得的，那就至少需要三個迭代以上的時間來做這樣的磨合，然后把整個團隊的速率穩定下來，也就是說首先團隊是一個長期存在的團隊；其次，做的事情也是長期存在的，產品思維中，整個產品的生命周期，即這個產品的生老病死，從這個產品的初期一直到開發、上線、上線以后的版本更新升級，以及上線以后的相關運營，其實是非常重要的，所以第二點就是產品的整個生命周期是要完全參與并全權負責的；第三就是需要有產品的思維或者業務的視角，例如以商業模式畫布的9個維度來看，整個過程里需要考慮市場的競爭是什么，目前的定位是什么，自己的優勢、劣勢是什么，能夠利用的渠道是什么，整個的價格策略等等。所以傳統的項目經理需要往產品思維方向去轉型，最后一點就是需要有服務的意識。

八戒：如果在敏捷轉型或者說在DevOps轉型當中，PM（Project Manager，項目經理）必須要轉成PO（Product Owner，產品或業務負責人）或者是BA（Business Analyst，業務需求分析師）或者是SM（Scrum Master，敏捷專家）的話，您建議PM向哪一個方向轉型？

姚冬老師：其實跟個人的職業發展路徑或者興趣愛好是相關的。這里有很多可能性，比如說PM向PO這個方向轉型，其實有兩種類型的PO，一種是偏業務的，他可能會到前端一些或市場側的位置跟客戶溝通等等，實際上是業務和產品之間的一個橋梁，也有可能這個PO會變成一個產品經理，需要考慮在實現層面上哪些是共性訴求，怎樣將它們進行產品化，并且把整個產品的規劃做出來，所以更多是產品和實現或者跟技術之間的一種角色。可能還會有另外一種角色，就是會變成一個Scrum Master，這可能也是我們比較常見的一種類型，當你做了Scrum Master之后可能又會由單團隊的Scrum Master逐漸變成多團隊的，然后逐漸變成培養Scrum Master的角色，就變成一個教練，甚至是變成一個獨立的咨詢顧問，去對外做傳播。也有可能這個PM的技術能力非常強，他有可能會變成一個架構師，也有可能他會去做一些協調類的工作或者做一些管理類的事情，那么他可能之后就走管理的路徑了，所以這些路徑都是有可能的。

問答二：

大理段譽：現在我們想實施敏捷開發模式，我們講究的敏捷開發就是小版本迭代、持續交付，我需要一個月開發出一些模塊，然后上線，之后進行客戶培訓，再進行用戶測試，但客戶表示由于時間關系無法每個月進行一次培訓，這個問題該怎么解決？

姚冬老師：其實敏捷是說我們要保持跟客戶的溝通，并不是說做每個迭代都要發布出來，未必是每個迭代都需要上線到生產環境的。我們依然可以按照客戶的節奏去做發版計劃，這個發版計劃可以是一個月或者三個月等等，但是在這期間需要有一些小的迭代交付，然后去找客戶的干系人或者客戶代表，跟他保持溝通，比如說兩周一個迭代，做出來一些東西可以演示，然后跟他去溝通，去澄清自己做的是不是客戶想要的東西，是不是高優先級的東西，如果他認可就接著進行下一個迭代，如果有問題就及時做調整。真正的迭代完成以后實際上被叫做“潛在可發布版本”，所以真正在發版之前還是會有很多工作要做，比如培訓的事情，跟客戶的工作交接，還有幫助文檔、培訓文檔等文檔補齊的事情，所以在真正發版之前會有一個短的迭代去做這些事情。

大理段譽：在需求可能會變化的情況下，如果和客戶簽固定期限的合同，限期上線，跟實行敏捷是否沒有太多關系，就只是在自己內部實施敏捷開發就行了？

姚冬老師：需求變化就是一個最大的問題，首先客戶的需求是模糊的，其次即使是簽了合同，甲方依然可以在過程中發生調整，所以需要保持跟甲方頻繁地面對面溝通，不斷做一些小版本的發布或迭代，然后跟甲方做澄清。

問答三：

sujuan feng：我們公司的敏捷的推行過程跟一般流程不一樣，正常來說從上到下推行是比較順暢的，但是我們目前是從中間層推行敏捷過程。經過一年多時間，大家的工作習慣、生產效能、內件質量確實有提高，但是目前我們想和項目發起人進行溝通，實際上我們在統計數據的時候發現數據并不好看，公司內部的項目發起人可能是一個高層領導的角色，他對敏捷不會特別了解，也不會給我們太多時間去講解中間的過程，在這種情況下，定期匯報，我們如何給他呈現出實行敏捷之后的一些效果？

姚冬老師：首先這里面肯定是有問題的，在發起的時候，一開始是可以自下而上或者先做一些小的嘗試，見到一些效果，及時地跟決策層進行溝通，便于把敏捷試點的事情在更大的范圍做推廣，一定要有這樣的意識。如果跟上層領導溝通比較順暢，更好的一種方式是在一開始就去了解上層領導關注的點在什么地方，然后根據他的訴求去拆解落地到實踐中能夠展現出來的一些數據或度量，如果一開始沒有做這件事情，也需要在中期開始做這件事。

sujuan feng：我的思路是先跟高層領導做一個非正式交談，看干系人的期望到底是什么，但是目前領導要求一個正式的溝通過程，給作為事業部領導的項目發起人做匯報，該如何進行呢？

姚冬老師：如果現在不了解領導的訴求，這個過程其實類似挖掘客戶需求的過程。如果把這個過程作為一個敏捷開發的案例，可以先做一兩個迭代，跟領導做非正式溝通，用例如缺陷率、需求變更率、人員速率等數據和度量的變化把效果呈現出來，之后可能會發現研發的結果和業務的指標訴求不相符，就要考慮調整，這是一個逐漸匹配的過程。所以這個過程實際上就是一個大的瀑布模型，這個過程對于項目發起人來說也是一個黑盒子，就需要把這個過程重新做一遍。如果已經要做匯報，可以收集現有數據，例如管理類和工程類數據，重點尋求與業務匹配的數據，尋找亮點。如果目前的敏捷僅在開發團隊實施，沒有納入業務團隊，后期就要考慮納入業務部門，及時了解業務指標的反饋。

問答四：

王重陽：我們公司是做房屋租賃業務的，一般項目周期為一個月，在公司里，領導也有這個意識，覺得敏捷應該去做，但是一直沒有進行。如果一下子拿出一個大的框架，團隊可能會畏難，如果僅在開發內部實施，意義又不大。現在我想要聚集一批核心層的領導來講解我們目前能夠用敏捷做什么，我該如何準備材料？

姚冬老師：可以找一些同行業或相近行業的案例來講解，甚至是把一些相關行業的榜樣請過來跟領導做溝通。如果項目周期較短，在做完兩周的迭代之后要交付上線，對內部或外部客戶進行開放，由于業務訴求的重要性，就要把內部或外部的客戶代表拉入整體閉環當中。另外要考慮清楚為什么要做敏捷這件事，要用敏捷達到什么目的，這個目的如何與領導的訴求進行關聯，實際上應當由領導的訴求拆解得到應該做的敏捷實踐，再去看這些實踐的采納路徑是什么，先做短期并且能夠快速見效的事，便于快速與領導匯報溝通，從而讓領導認可這件事并支持自己繼續向前走。

王重陽：測試這個環節并非需要專業團隊來進行，開發和測試需要分開，但在我們公司里，又往往是開發結束了，測試才接入，這個過程中開發就需要等待，所以我嘗試過幾次讓開發人員互相測試，但沒有形成一個規范，該怎么解決人員效率浪費的這個問題？

姚冬老師：涉及到角色調整或組織架構調整的事情并不容易，可以等到領導真正支持的時候再去做這件事，在此之前可以以拉動各部門的溝通協作的名義，在前期更多地把測試人員拉進來，這樣匯報線其實沒有改變，但測試做的事情已經與開發團隊融合在一起。例如看一下測試有哪些事情可以前置，開發去幫測試做一些事情，或者測試資源有限，嘗試把測試環境自動化，甚至是集中測試等就由開發人員去做，承認測試的專業性，在此基礎上由測試人員去教開發如何去做這件事，逐漸就達到了技能共享，下一步就可以把團隊打散，把測試人員融合到開發的團隊中，事情就會進行得更順暢了。

以上文字內容由【內容眾創小組-梔】整理

DevOps 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。