成功輔導過淘寶、閒魚，他都是如何幫助團隊實施敏捷的

爲了讓你們對敏捷有更多的瞭解，小編特地採訪了阿里巴巴高級技術專家、敏捷教練張燎原。他是如何看待敏捷、如何幫助團隊落地敏捷的，做爲研發團隊的一員，咱們能夠從哪些地方着手敏捷，如下是對他的採訪。

嘉賓簡介：張燎原，阿里巴巴高級技術專家，他是敏捷和精益方法的積極實踐者和推進者，具備十多年軟件研發一線實踐經驗，經歷過消費電子、通訊及互聯網多個行業，長期從事研發管理、研發教練及組織轉型工做，曾負責Nokia全球大規模敏捷導入實施和轉型輔導，成功幫助淘寶、閒魚、阿里雲等事業部引入精益產品交付和創新方法，幫助實現DevOps轉型。譯有《程序員度量》、《軟件驅魔》等。同時，他熱衷編寫代碼和開源，涉及軟件設計、測試驅動開發、代碼重構、遺留代碼的維護和持續集成及交付。工做之餘，他還擅長畫畫和攝影，被同事戲稱「最會畫畫的敏捷教練」。

一、燎原你好，我知道你是敏捷和精益方法的積極推進者，在阿里也輔導過淘寶、閒魚等多個團隊。從事敏捷這麼多年，特別好奇，你是如何看待敏捷和精益的呢？

張燎原：之前，敏捷做爲一個很時髦的概念，你們老是反覆在提，就像如今的DevOps同樣。在我看來，不管是敏捷、精益仍是DevOps，能不能解決問題， 這個纔是最重要的，一切不以解決實際問題的概念炒做都是耍流氓。去年我和何勉老師（阿里巴巴敏捷教練團隊負責人）在一塊兒討論， 咱們是在作敏捷、精益的轉型仍是其餘的什麼，後來咱們決定提高研發效能。做爲一個研發團隊，可以持續快速高質量地交付有用的價值，纔是咱們以爲做爲一個研發團隊要追求的。

提高研發效能，主要分兩點來看，第一個是回答如何持續快速高質量的交付的問題。在交付團隊裏，你們協做特別好，寫的代碼要沒有太大的問題——高質量，發佈特別快。因此，咱們知道的好比看板、Scrum是解決咱們協做的問題；測試自動化、CI/CD以及DevOps是爲了幫助高質量的發佈；咱們提倡的DDD、Clean Code，是爲了讓咱們的代碼可以更健壯、質量更好、更Clean，你們在協做的時候，可以經過代碼來交流，這些都是提高交付能力的手段和實踐。

另一點是，就要回答什麼是有用的價值這個問題。對不少工程師來講，你們可能更關心代碼寫的好很差，從產品那拿到的需求，你們基本都認爲是對的。不少時候產品提了一個需求，一個工程師可能要作一天甚至是一個禮拜才能完成這個需求。可是，若是這個需求沒有價值，那就至關於白乾了。因此這個時候，咱們要走到源頭去看一看，這個需求是不是有用的，對咱們的業務有沒有幫助，是否值得咱們投入。

因此你問我如何看待敏捷，我不會說是要快速響應變化，由於我以爲這樣仍是有點抽象。回到研發的本質，咱們是要持續快速高質量地交付有用價值，從解決阻礙咱們達成這一目標的問題出發，選擇相應的方法和實踐，最終解決掉這些問題，這纔是實實在在、對咱們有幫助的。

二、你是如何幫助團隊落地敏捷的，這中間有沒有遇到一些困難？

張燎原： 我以爲首先是讓你們看得見，對問題造成一致的理解。當咱們開始在團隊落敏捷時，你們會說我沒有問題，因此首先咱們要讓你們看得見問題，在問題上達成共識。這樣，目標纔會一致，作事才能齊心。

其次，你們在解決方案上要達成共識。有的時候，針對一個問題，可能有A解法，也可能有B解法，但咱們要一塊兒探討是用A仍是用B。例如，B可能見效快，但不持久；A見效慢，可是持久。這個時候，咱們得去找一個折中的解決方案。

再次，要有一條明確清晰的改進路徑。解決方案要能解決問題，但同時也要給你們改進的信心。每一個階段都能解決一些問題，經過持續地發現和改進問題牽引着你們往前走。這種改進不該該都是菸斗式的，即開始會致使效率先降下來，而後纔會慢慢持續往上爬。

最後，有節奏地給出有效反饋。經過在合做過程當中，經過數據也好，或者觀察到的問題也好，持續地給團隊反饋，讓你們明白本身是在正確的路上行走的。

這幾點對咱們來講都是比較大的挑戰，但比較好的是，咱們如今能得心應手來應對。還有一點，大部分時間，咱們是站在全局的視角來看問題，這和具體的職能團隊是有差異的，他們更可能是站在本身的職能的角度。你們看問題的視角不同，在溝通的時候，也就須要更有同理心。

三、在敏捷實施過程當中，給團隊創建信心真的很重要，能具體說說你是如何在短期內給團隊創建信心的嗎？

張燎原：在實施轉型或提效的時候，須要持續地給你們信心。咱們不太建議一股腦地給一個完整的解決方案，把以前的所有推翻掉，就按照新的來。由於咱們接觸的團隊，基本上都是工做在現有的業務上的，哪怕是創新型的一些團隊，你們以前也一塊兒磨合了很長的時間，你們都有本身熟悉的工做方式和習慣。

咱們團隊以前有一個案例：《4個迭代，從批量交付到持續交付轉型》，就很是典型，每作一個迭代都是讓你們看到收益，而後纔有信心作第二個迭代。例如，當時的第一個迭代是把全部的職能端到端的拉齊，讓你們看到總體。這個時候就減小了各個職能之間的交流誤會，整個溝通就順暢了。而後在整個可視化的協做流程中，你們就會發現：喔，原來需求有這麼多反覆、原來需求太大了，甚至需求都沒搞清楚就開始了。其實不少時候，這些都是你們本身發現的。當解決了協做的問題，你們有了信心，就開始着手解決需求的問題。當需求澄清的問題解決後，又會發現發佈速度是否是能夠更快一點，原來一個月發一次，如今是否是能夠每一個禮拜都能發。這樣每個迭代都會有一些點獲得了改進，而且也可以持續暴露其餘的一些問題，可以讓你們朝比較理想的狀態前進。

若是你告訴你們落一個解決方案須要半年的時間說半年以後才能看到結果，你作了一個月沒結果，你們能接受，第二個月沒結果，你們能夠堅持，若是第三個月仍是如此，可能就沒有而後了......這是咱們在制定解決方案的時候須要特別考慮的。

四、大家的敏捷實施或提效通常多久能見到效果？

張燎原：從目前在阿里接觸的一些團隊來講，一個月內，基本上就可以看到一些明顯的效果了。固然這跟咱們合做的團隊也有很大的關係，你們彼此都挺配合的，甚至有的時候他們比咱們還專業，他們會說，燎原老師，你看這種方式是否是會更好。而後我發現他給出來的點多是我都沒想到的，因此在這個過程當中，咱們也是在相互學習。

固然，改進是一個持續的過程，目標越大，要投入的時間可能就會越長。

五、通常何時能夠判斷說這個團隊輔導OK了？

張燎原：通常狀況下，在輔導開始的時候，咱們都會有特別明確的目標，咱們會清晰地把須要改進的問題定義出來，讓你們看得見，找出根因，而不只僅是現象。隨着問題逐漸被解決，後面咱們會有意識的慢慢抽身出來，看沒有咱們的時候，是否是也可以work起來，若是咱們發現沒有咱們也行，這個時間也就到了。

在這個過程當中，很重要一點，咱們要善於發現和培養有潛力的同窗，在被輔導團隊留下種子，這些同窗會是團隊持續改進的生力軍。

六、有什麼方法能夠幫助一些團隊發現本身的問題？

張燎原：我以爲能作IT的人都是聰明人，若是他沒有發現這個問題，更多的是由於他沒有這個意識，沒有意識到本身要去看有沒有問題。因此咱們會經過其餘的一些渠道，讓你們去意識到這件事。老實說，你們不缺方法，缺的是意識，咱們但願可以讓你們意識到這件事情的重要性，若是咱們沒有一個很好的研發能力去支撐業務效能的話，咱們也很難把業務效能作好。雖然不少時候咱們只以爲業務效能很好很重要，我認可確實很重要，但研發效能是基礎。若是你有一個很好的點子，可是沒有很好的這種研發團隊，沒有研發方式來支撐。你的點子，也實現不了。

七、如何讓更多的有需求的團隊也能獲得大家的支持？

燎原：確實，讓咱們去輔導一個團隊，確定沒有問題，可是若是讓咱們同時去輔導不少的團隊，精力確定就忙不過來，一我的一天就24個小時。這個時候咱們會有一些策略，例如，就像前面所述，咱們會培養業務團隊的一些同事，讓他們成爲這方面的專家，就像一顆種子，他也會發展壯大，而後他本身作的一些事情，對他所在組織都會有很大的幫助，這是一種槓桿撬動的力量。另外，咱們還會經過其餘的一些手段，例如線上、線下的培訓課程、最佳實踐文章、案例分享，以及鼓勵更多同事把他們一些好的點子share出來。我相信這樣一個一個的點，都可以幫助規模化。

還有另一個很重要一點，咱們所在的研發效能團隊，經過各個業務部門的實踐，對實踐方法及不一樣場景的總結沉澱，會造成一些體系化的東西，而後與工具作更多的結合，讓你們經過工具就能夠輕鬆上手，把好的實踐最大化。例如，如今Aone的看板，看板上爲何分那些階段、爲何有那樣的一條條泳道、需求是怎樣移動的，最先咱們是用物理看板，可是如今咱們把它都融入到產品裏，團隊建好本身的項目空間，就自動會有一塊項目看板，從而讓好的實踐在更多的團隊獲得使用。

八、做爲研發團隊的一員，咱們每一個人能夠如何着手去實施敏捷？

我以爲單獨從瞭解方法或知識的角度來講，看完了一本書或者一篇博客，10天半個月可能也就忘了。可是咱們能夠從本身現實當中的問題出發，好比作爲程序員能夠去思考，如何可以讓代碼變動高效地發佈。例如你能夠搭一個持續集成的流水線，讓你們的代碼一提交就觸發自動化的檢查、自動化的測試和部署，把這個作好就是往敏捷，往研發效能的提高上就走了一大步。

對產品經理來講，需求應該如何組織，是否都有對應的目標，任務朝需求對齊，需求朝目標對齊。對於一線管理同窗，能夠思考整個團隊的能力模型，團隊的協做當中有哪些問題，好比測試和開發同事、前端和服務端之間的協做有沒有更好手段，讓你們的協做更高效。這樣每一個人都站在本身的角度上，改進一點點的話，造成協力。你們再在站在系統的角度，串起來一塊兒看，就會改進不少。

即便是一個剛入職場開發同窗，也能夠思考代碼能不能寫的更clean，減小code smell，把這代碼寫的別人一看就懂，每一段代碼都能有很好的單元測試，減小維護成本。這些都是在提高研發效能，在實踐敏捷。敏捷不是掛在嘴上，而是落在天天的工做裏。

九、最後，本週六你的分享《從持續交付到業務創新》，但願能給你們帶來哪些收穫？

張燎原：不少時候咱們作工程師，都是站在本身的位置去看待問題，不多有機會可以站在全局，端到端的角度去看待問題。此次分享我但願可以帶着你們一塊兒，從研發的端到端、從需求到交付，去了解咱們能夠經過哪些手段去提高研發效能，以支持咱們提高業務效能。

對於每個不一樣的角色，可以富有同理心地去看待軟件研發過程當中的其餘職能的工做，真正作到「眼高手低」：即看到總體，落到實處，總體造成協力，往組織效能最大化的方向去努力。

阿里有一句話叫作：一張圖、一場仗，一顆心，首先畫好一張總體的圖，把團隊之間協做的圖畫好，咱們才能得對齊，上下同心，而後把這場仗打好。期待與你們的交流。

做者：雲效鼓勵師

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。