摘要：在交付團隊里，大家協作特別好，寫的代碼要沒有太大的問題——高質量，發布特別快。當我們開始在團隊落敏捷時，大家會說我沒有問題，所以首先我們要讓大家看得見問題，在問題上達成共識。

為了讓大家對敏捷有更多的了解，小編特意採訪了阿里巴巴高級技術專家、敏捷教練張燎原。他是如何看待敏捷、如何幫助團隊落地敏捷的，作為研發團隊的一員，我們可以從哪些地方著手敏捷，以下是對他的採訪。

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

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

張燎原：以前，敏捷作為一個很時髦的概念，大家總是反復在提，就像現在的DevOps一樣。在我看來，不論是敏捷、精益還是DevOps，能不能解決問題， 這個才是最重要的，一切不以解決實際問題的概念炒作都是耍流氓。去年我和何勉老師（阿里巴巴敏捷教練團隊負責人）在一起討論， 我們是在做敏捷、精益的轉型還是其他的什麼，後來我們決定提升研發效能。作為一個研發團隊，能夠持續快速高質量地交付有用的價值，才是我們覺得作為一個研發團隊要追求的。

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

另外一點是，就要回答什麼是有用的價值這個問題。對很多工程師來說，大家可能更關心代碼寫的好不好，從產品那拿到的需求，大家基本都認為是對的。很多時候產品提了一個需求，一個工程師可能要做一天甚至是一個禮拜才能完成這個需求。但是，如果這個需求沒有價值，那就相當於白幹了。所以這個時候，我們要走到源頭去看一看，這個需求是否是有用的，對我們的業務有沒有幫助，是否值得我們投入。

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

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

張燎原： 我覺得首先是讓大家看得見，對問題形成一致的理解。當我們開始在團隊落敏捷時，大家會說我沒有問題，所以首先我們要讓大家看得見問題，在問題上達成共識。這樣，目標才會一致，做事才能齊心。

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

再次，要有一條明確清晰的改進路徑。解決方案要能解決問題，但同時也要給大家改進的信心。每個階段都能解決一些問題，通過持續地發現和改進問題牽引著大家往前走。這種改進不應該都是煙鬥式的，即開始會導致效率先降下來，然後才會慢慢持續往上爬。

最後，有節奏地給出有效反饋。通過在合作過程中，通過數據也好，或者觀察到的問題也好，持續地給團隊反饋，讓大家明白自己是在正確的路上行走的。

這幾點對我們來說都是比較大的挑戰，但比較好的是，我們現在能駕輕就熟來應對。還有一點，大部分時間，我們是站在全局的視角來看問題，這和具體的職能團隊是有差別的，他們更多是站在自己的職能的角度。大家看問題的視角不一樣，在溝通的時候，也就需要更有同理心。

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

張燎原：在實施轉型或提效的時候，需要持續地給大家信心。我們不太建議一股腦地給一個完整的解決方案，把之前的全部推翻掉，就按照新的來。因為我們接觸的團隊，基本上都是工作在現有的業務上的，哪怕是創新型的一些團隊，大家之前也一起磨合了很長的時間，大家都有自己熟悉的工作方式和習慣。

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

如果你告訴大家落一個解決方案需要半年的時間說半年之後才能看到結果，你做了一個月沒結果，大家能接受，第二個月沒結果，大家可以堅持，如果第三個月還是如此，可能就沒有然後了……這是我們在制定解決方案的時候需要特別考慮的。

4、你們的敏捷實施或提效一般多久能見到效果？

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

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

5、一般什麼時候可以判斷說這個團隊輔導OK了？

張燎原：一般情況下，在輔導開始的時候，我們都會有特別明確的目標，我們會清晰地把需要改進的問題定義出來，讓大家看得見，找出根因，而不僅僅是現象。隨著問題逐漸被解決，後面我們會有意識的慢慢抽身出來，看沒有我們的時候，是不是也能夠work起來，如果我們發現沒有我們也行，這個時間也就到了。

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

6、有什麼方法可以幫助一些團隊發現自己的問題？

張燎原：我覺得能做IT的人都是聰明人，如果他沒有發現這個問題，更多的是因為他沒有這個意識，沒有意識到自己要去看有沒有問題。所以我們會通過其他的一些管道，讓大家去意識到這件事。老實說，大家不缺方法，缺的是意識，我們希望能夠讓大家意識到這件事情的重要性，如果我們沒有一個很好的研發能力去支撐業務效能的話，我們也很難把業務效能做好。雖然很多時候我們只覺得業務效能很好很重要，我承認確實很重要，但研發效能是基礎。如果你有一個很好的點子，但是沒有很好的這種研發團隊，沒有研發方式來支撐。你的點子，也做到不了。

7、如何讓更多的有需求的團隊也能得到你們的支持？

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

還有另外一個很重要一點，我們所在的研發效能團隊，通過各個業務部門的實踐，對實踐方法及不同場景的總結沉淀，會形成一些體系化的東西，然後與工具做更多的結合，讓大家通過工具就可以輕鬆上手，把好的實踐最大化。例如，現在Aone的看板，看板上為什麼分那些階段、為什麼有那樣的一條條泳道、需求是怎樣移動的，最早我們是用物理看板，但是現在我們把它都融入到產品里，團隊建好自己的項目空間，就自動會有一塊項目看板，從而讓好的實踐在更多的團隊得到使用。

8、作為研發團隊的一員，我們每個人可以如何著手去實施敏捷？

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

對產品經理來說，需求應該如何組織，是否都有對應的目標，任務朝需求對齊，需求朝目標對齊。對於一線管理同學，可以思考整個團隊的能力模型，團隊的協作當中有哪些問題，比如測試和開發同事、前端和服務端之間的協作有沒有更好手段，讓大家的協作更高效。這樣每個人都站在自己的角度上，改進一點點的話，形成合力。大家再在站在系統的角度，串起來一起看，就會改進很多。

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

9、最後，本周六你的分享《從持續交付到業務創新》，希望能給大家帶來哪些收獲？

張燎原：很多時候我們做工程師，都是站在自己的位置去看待問題，很少有機會能夠站在全局，端到端的角度去看待問題。這次分享我希望能夠帶著大家一起，從研發的端到端、從需求到交付，去了解我們可以通過哪些手段去提升研發效能，以支持我們提升業務效能。

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

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

作者：雲效鼓勵師

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