線上分享實錄|平安7年精益敏捷轉型之路

圖片描述

導讀:平安做爲互聯網金融的領跑者,目前有超過40個APP,傳統業務全面互聯網化。可以成功轉型與敏捷密不可分,平安科技更是整個集團敏捷轉型的領頭羊。
2011年,敏捷開發試點項目大獲成功以後,平安科技駛入敏捷推廣的加速車道。
2012年試點範圍擴大到10個團隊,引入Scrum、看板(Kanban)、持續集成等流行的敏捷方法。
2013年「開啓敏捷2.0」,在組織架構上成立「敏捷中心」,整合業界優秀實踐,造成平安科技本身的敏捷開發方法體系和敏捷成熟度評價體系。
2014年,敏捷開發覆蓋到公司大約80%的開發團隊,並開始探索互聯網產品的敏捷開發模式。
2015年「邁向持續交付」,從研發過程的敏捷,向上下游擴展,引入精益創業(Lean
Startup)、DevOps等新的方法,打造端到端的反饋閉環。
2016年啓動持續交付支撐工具鏈的建設,致力於打造「精、輕、快」的持續交付一體化平臺與解決方案。
從2013年到2015年,公司總體的30天需求實現率從24%
提高到80%;產品研發週期從以往的6個月縮短到3個月之內。此外,更靈活的響應變化、穩定的版本質量、更高的團隊產能、持續改進的習慣,都逐步顯現出來。前端

本次分享將經過真實的案例,分享平安科技全面敏捷模式如何在小團隊、大項目,乃至整個組織的實踐和落地。編程

文章來源:公衆號msup後端

背景介紹安全

圖片描述
先簡單介紹一下公司的背景。上圖中左側的高樓是平安金融中心,這是深圳最高的樓,118層。曾幾什麼時候,咱們聽到「平安」的時候只能聯想到保險或歌星,現在咱們能夠驕傲地說,咱們是作金融互聯網的高科技企業。架構

2016年平安在世界五百強企業裏排41,這個成績和平安互聯網+綜合金融的轉型戰略是分不開的。平安如今已經有了40多個APP,近3.5億的互聯網用戶,這個數字還在快速增長。框架

與之適應的產品策略和管理思路也在全面互聯網化。咱們從以前的關注能賣多少錢,到如今關注能爲用戶創造多大的價值,這偏偏都是敏捷所倡導的也是互聯網須要的。工具

圖片描述

上圖是咱們從2011年到如今的轉型路線圖。單元測試

從2011年開始咱們成立了第一個 feature team;2012年引入看板方法進行可視化管理;2013年是很是重要的一年,咱們成立了敏捷中心推行敏捷2.0,也就是scrum+看板+極限編程的方法,聘請了大量的敏捷教練,也組織了不少場培訓,開始全面推行敏捷。學習

2014年開始將敏捷實踐推廣到大型項目,平安是國內第一個引入LeSS(大型敏捷框架)的企業;2015年開始向敏捷的上下游拓展,引入了精益創業和持續集成、持續交付的方法;2016年,咱們開始本身研發一個持續交付的工具——神兵,同時經過工具來獲取一些過程數據,並進行價值流分析以提高企業的效能。測試

2011 元年

圖片描述
2011年是咱們開始敏捷轉型的第一年。通常改變老是有緣由的,我業餘時間學了些心理學和教練技術,個人老師常說「不夠痛就不會動」。有的痛是切實感覺到的,有的是對將來的焦慮。

平安敏捷轉型的出發因素不少仍是來自於互聯網,當時互聯網巨頭紛紛涉足金融和保險,淘寶的保險頻道都已經上線了。馬明哲還說BAT纔是平安真正的對手。

顯然,以前的標準化、規範化的研發管理模式已經不適應當前變化的互聯網環境了,咱們更須要一種靈活多變的多元化的管理思路來更高效地作事情。

圖片描述

從上圖左右側的對比能夠看到:2011年以前咱們強調的是管理的標準化和規範化,當時還經過了CMMI的三級評審。2011年開始推行敏捷以後,咱們開始倡導開發模式的靈活化多元化,應用不一樣的管理模式來應對不一樣的場景。

咱們還開展了一個叫「百日行動」的活動,就是用一百天去提高效率,具體作了這麼幾件事:

第一,看文檔有哪些是必要的,哪些是不須要的。咱們把文檔分爲系統級和過程級兩類。系統級的文檔要增強,好比架構文檔;過程級的文檔要弱化,好比周報日報,這些只是爲了溝通,實時性很強,徹底能夠經過面對面的溝通來取代。

第二,縮短簽報的審批鏈。平安如今有一百多萬人,審批鏈很長也很複雜,咱們會分析每個環節的經過率,若是這個經過率長時間以來一直是100%,那這個環節就應該是能夠去掉的。

第三,討論怎麼開會更高效。

第四,搭建部署流水線。嘗試將代碼從手工移交變成自動化移交。

圖片描述

分享一個車險網銷平臺的案例。咱們拿這個項目來作第一個敏捷試點項目。這是一個小團隊,這個平臺要作的功能是實如今互聯網上賣車險。

圖片描述

這是咱們第一個特性團隊的照片,這個團隊包括產品經理、先後端開發、測試等各個角色,這樣的一個全功能團隊可以實現端到端的交付。

當時進入特性團隊的種子成員都是通過挑選的,咱們會選擇一些樂於接受新思想、願意尋求改變的人,隨着這樣的實踐他們後來都成長爲平安的骨幹人才。

圖片描述

上圖是咱們特性團隊的第一個看板,雖然不夠美觀,可是已經有一些樣子。

圖片描述

經過敏捷實踐和落地,咱們達到了如下的效果:
上線週期從兩個月縮短到兩週;
外部合做夥伴接入的週期從3個月縮短爲1.5個月;
產能提高30%;
版本測試周期壓縮一半,生產問題減小70%。

圖片描述

咱們的組織在最初嘗試導入敏捷的時候作了三件事:

第一,創建全功能團隊,經過面對面的協做改善溝通。業務方表明最好也可以加入到這個團隊中去,這樣可以及時給團隊答疑並提供反饋。
第二,經過看板可視化進度,今早發現問題消除瓶頸。
第三,把需求拆小拆細,以便可以儘快交付儘早獲得反饋,從而下降風險、靈活應對變化。
第四,最重要的是人,須要有一些可以接受敏捷思想的人去作這樣的一些改變。

2012 起跑

圖片描述
圖片描述
第一個試點項目取得成效以後,咱們開始逐步深化咱們的看板實踐。上圖是一個壽險的支持項目,這個看板系統比以前的原型看板漂亮多了,從圖中還能夠看到它與原型看板的區別:

首先,有了測試就緒、驗收就緒的等待隊列;
第二,卡片上有貼owner的照片;
第三,右下角有一個燃盡圖;
第四,圖中打紅叉的部分是作了一個WIP的限制,就是說這個隊列不能有太多的卡片,卡片不能貼到那個禁止的區域裏。

圖片描述

說到轉型時度量也很是關鍵。上圖是一個累計流圖,縱座標是Story Point,粉色的線是啓動開發的故事點數,深綠色的線是用戶驗收完成的故事點數,這兩條線的寬度對應到橫座標大概是三週的時間,就是說這個需求的lead time,從啓動開發到用戶驗證大概須要三週的時間來完成。

圖片描述

經過改進這個看板實踐,咱們能夠看到:因爲中途發現了優先級更高的需求,因此有40%的原始需求被捨棄了。從傳統項目管理的強調交付範圍轉化爲交付價值,這是互聯網的要求。由於如今的社會充滿了不肯定性,咱們也很難從一開始就把範圍肯定並保證後面不發生變化。

咱們須要擁有靈活應對變化的能力,要保證團隊一直在交付高優先級、高價值的任務。同時咱們也不但願這個範圍無限蔓延致使同窗們每天加班,質量降低。因此當有一個高優先級的任務要加進來的時候,咱們就會擠掉一個同等工做量的低優先級任務。這就是爲何上圖中左下角中途增長的40%優先級更高的需求,右上角又擠掉了一樣多的需求。

圖片描述

總結一下咱們2012年敏捷轉型的幾個關鍵要素:
延遲決策,讓它快速流動;
交付價值賽過交付範圍;
經過約束限制在製品數量來拉動系統;
經過看板實現阻礙和問題的可視化。

2013 推廣

圖片描述
圖片描述
經過前面兩年的積累,咱們取得了一些成果,2013年進入關鍵性的一年,這一年咱們成立了敏捷中心推廣敏捷2.0。那時主要主打的是三種方法:看板、Scrum、持續集成。咱們提供三天的訓練營打包培訓,有不少團隊成員加入進來參加這樣的培訓。

圖片描述

上圖是咱們的學員在玩看板沙盤遊戲。這是一個從國外引進的很是經典的遊戲,可以幫助咱們體會看板方法的精髓。如今這個培訓一直持續在作,也收到了很好的效果。

咱們說2013是敏捷推廣最紅火的一年,這一年,咱們還作了一件很是重要的事:成熟度的評估。

圖片描述

上圖是一個成熟度評估模型的一部分,左邊能夠看到一級二級(後面還有三級)。這是一個在整個公司範圍內發起的活動,由敏捷中心去推行,成立專家小組給團隊評級,而後在全公司公佈結果。這個在當時無形中成爲了一個團隊的KPI,但當時達到三級的只有四個團隊,二級的幾十個團隊,其餘團隊大部分還處於一級。到2014年的時候,平安科技有4000多人100多個分組,80%的團隊都引入了敏捷方法。

![圖片描述

上圖中這個活動叫看板大巡遊,主要是由教練帶隊,他們像導遊同樣舉着旗子帶領你們一站一站地看過去。每一個團隊設計的看板都不同,咱們會考慮美觀、實用等方面去給各個看板打分、寫評語。而後一塊兒討論有哪些好的地方值得你們學習,最後還會有評比和頒獎。

這是鞏固得很是好的一個實踐,實施的效果是80%的團隊都應用敏捷和看板,並且這麼多年在平安可以很好地落地並延續。敏捷在IT領域的看板方法在剛問世時也會有一些爭議,可是仍是被不少公司所採用。由於即便是在各個公司文化、管理風格迥異的環境下,看板方法做爲一個漸進式的變革方法仍是比較容易切入進去的。

也就是說,它提供了一個更加平滑的路徑,可以最大限度地減小敏捷轉型帶來的陣痛。其實基於現狀以及實用至上,這是我在平安科技甚至在整個平安集團可以看到的,一向執行下來的思想和策略。

我看到過一些自上而下的激進變革的例子,到最後有一些是打回原形的,員工對此產生了諸多的誤解;也有一些自下而上的變革,通常這樣的變革發起者都是比較超前的員工,企業沒跟上最後致使員工心灰意冷離職,變革也草草收場。相比之下,我更欣賞平安這種溫和的演進策略,可以更持久更有效。

2014 深化

2014年是咱們敏捷深化的一年,基於前幾年的成果逐步把敏捷擴展到更大型的項目裏來。咱們第一個大型的試點項目是作一個直銷銀行,這個項目有幾十我的的研發團隊,其中還有大量的外包,困難也不少。

敏捷轉型以前的場景是業務拼命地加班寫文檔,他們也知道寫了要被推翻,可是開發說了沒有文檔就不能幹活,雙方的互信度很是低經常僵持不下,後來有人提出來講:我們不是有敏捷教練嗎?

咱們敏捷教練的團隊leader林偉丹(平安科技敏捷中心資深經理、Wizard產品商業化總監)、著名的精益敏捷教練吳穹博士都加入了這個項目,諮詢顧問帶團隊作了一個Quick Start,Quick Start也是平安堅持得很是好的一個實踐,通常小型項目的時間是大概1-2天,像這樣大型的項目可能須要一週時間。

咱們把Quick Start方法總結成36計,再加上引導技術、沙盤演練提煉成兩天的工做坊,經過這個工做坊也培養了不少Quick Start的引導師,這個工做坊在平安也是很受歡迎的。

須要全部的決策角色(特別是能拍板的人)都參加到Quick Start工做坊,這樣能快速地把業務需求梳理成開發可以去作的迭代計劃。達成的效果就是但願會議結束後立刻就能開始去迭代、可以持續交付一些可見到的東西。

上圖咱們在Quick Start以後梳理出來的一個四層的故事牆,從主題到Epic到Feature到Story,看起來仍是蠻壯觀的,貼了滿滿的一面牆。

由於會涉及到多個Scrum team的協做,上圖是一個Scrum team的看板,把迭代計劃放到上面,最左邊大的卡片是用戶故事,右邊小點的卡片是任務。咱們後面也作了一些改進:用不一樣顏色的卡片來標示用戶故事和任務,還特別用紅色的卡片標示風險。

咱們還有一個專門的看板,用來管理大型項目之間的關聯和依賴。藍色卡片是業務模塊、黃色卡片是關聯繫統。裏面會有不少具體的檢查點,每一個作完以後就用打鉤的方式跟蹤風險,上圖右邊的五角星是標示一些風險大的地方。

上圖是一個比較完整的分層看板,右邊每一個人都有兩張照片,並且只能有兩張照片,這是爲了不一我的手頭同時有多個並行任務、須要頻繁切換任務而致使效率下降的狀況,咱們鼓勵你們先作完一個任務再去領下一個,這樣有助於任務快速流動提高效率。最左下方有一大堆卡片,這些都是被捨棄的需求。

上圖是咱們30多我的參加的每日站會。咱們可以保證在15分鐘內完成,每一個人在上面移動卡片。這面牆仍是蠻大的可以將全部的用戶故事、任務都展現出來。

這個直銷銀行的項目從最開始業務和開發的互相不信任、集體焦灼的狀態,到後面啓動Quick Start,並取得驚人的成績:
三個月以後首個版本發佈能夠內測;
四個月以後直銷銀行產品正式推向市場;
發佈一年以後,用戶量突破五百萬,並得到中國最佳直銷銀行的大獎。
這個大型項目的敏捷試點也是至關成功的。

2015 延伸

2015年以前的不少實踐都是在幫助咱們把事情作對作好,主要是在解決域方面,而咱們面對的問題是其實咱們不知道什麼是對的事情,問題域須要咱們用精益創業和設計思惟的思想來解決。因此,從2014年起咱們開始往敏捷的上游拓展,創建上圖這樣的產品側看板,同時咱們引入了一些精益創業的實踐。

上圖是業務側看板的一個實例。有澄清、評估、排期,排期就是進入了開發的迭代計劃,這個看板到如今產品經理還在用。

咱們也但願可以往敏捷的下游——持續交付拓展。想要交付得快自動化是不可缺乏的,咱們要去持續驗證。自動化測試方面,其實要分層的,而接口測試是比較容易作的,我這邊的團隊更傾向於由開發把自動化的接口測試寫好,甚至把這個部分定義到DoD(Definition of Done)裏,以便可以快速地去測試。

原來都是評估從需求準備好到交付的時間,如今咱們能夠去評估從創意到投產的lead time,前置時間。上圖中縱座標是天數,從圖中能夠看出2015年9月到2016年是有顯著下降的,也就是說從有了初步想法到最後上線的週期在快速縮短。

這是咱們2015年實踐敏捷的一些感悟和關鍵要素:
總體優化賽過局部優化;
造成有價值的閉環;
強調內建質量。

2016 神兵

2016年,咱們研發管理部開發了一個可以實現:從需求管理到自動化測試到自動部署、持續集成還有一些靜態掃描持續交付的工具鏈——神兵。咱們也能夠經過神兵獲取不少的數據作價值流的分析。固然這個數據不只是從神兵獲取,還從公司不少系統裏獲取。

咱們在IT領域的能力提高以後,將改進的方向擴展到了更多的領域,好比運營管理、財務管理、行政管理、法務管理、安全等方面,分析這些過程當中的等待返工和浪費,並試圖作出優化,縮短lead time。

咱們找到了top 10,也就是最須要改進的十項來進行改善,並取得了明顯的效果,好比合同簽署、新建子系統、公共平臺的接入、移交部署,都有了百分之十幾到三十幾的提高,公司總體的流程效率提高了14%。

2016年的關鍵要素:
實現了端到端的價值流建模;
持續不斷地消除浪費;
慎用「流程」
這裏值得強調的是:不少時候咱們發現漏洞的直覺反應是加一個流程去防範這樣的漏洞,這樣作的結果是致使流程愈來愈臃腫,組織效率愈來愈低下。

轉型心得

回顧一下咱們在敏捷轉型路上的一些心得體會。

首先,系統思考。當咱們發現問題的時候,不要像西醫同樣只針對問題治病,而要從整個系統的角度去考慮,優化整個環節中可能的各個部分。
其次,發揮人的創造性和主觀能動性很是重要。
第三,痛點驅動,數據閉環。痛點驅動,經過數據去發現改進的點,而後度量改進的效果。
最後,持續改進,永遠在路上。
像平安這樣的體量可以作到這樣的變革是很不容易的,可能中小型企業的改變相對容易一些,咱們經歷了這麼長時間的嘗試和實踐,後面可能就能夠少走一些彎路,也許進展會更快一些。

團隊如今的敏捷實踐

最後分享一下團隊如今的敏捷實踐。

這是我輔導的一個叫伺客的團隊,作在線雲客服項目。咱們會有一個這樣的做戰室,全部的角色都坐在一塊兒,包括產品經理、先後端開發、測試等,你們可以很方便地溝通,效率也有了很大的提高。從圖中能夠看到這個項目室的四周也有不少的看板。

隨着如今團隊的擴張,不少異地的小夥伴加入,好比成都、深圳等,咱們的看板也從本來的物理看板換成了電子看板,由於咱們有神兵的支持,因此咱們能夠把全部的任務、需求、缺陷、測試用例等都放到神兵的系統裏,每日站會改成站在觸摸屏的電子看板前展開。

我對這個看板作了個小小的改動,把咱們的DoR、DoD以及一些站會的提醒寫成卡片貼到觸摸屏的四周。下面還有一個屏幕來作CI監控,以及一個Sonar的掃描。

我還編了一些口訣來幫助你們記住咱們的敏捷實踐:
自治團隊輪值表
開會嚴守時間盒
需求准入實例化
任務拆細兩天工
開發單側接口測
前端後端需並行
內建質量都有責
CI失敗立刻修
代碼review面對面
技術債務日日清

咱們是一個自組織團隊,在平安科技有不少人複用的狀況,這是很難避免的,想找一個專職的Scrum master更是難上加難,因此咱們就讓你們輪流擔任Scrum master,主持各類會議,有一個輪值表貼在牆壁上。

開會的時候,包括需求的梳理和澄清都要嚴守時間,一個需求的澄清不能超過15分鐘。若是有不少不清楚的、團隊提出質疑的地方,就須要先hold住回去弄清楚了再回來說。

咱們但願需求准入實例化場景化,讓你們能有一個統一的語言清晰地理解。

還有任務的拆細,必定要保證這個任務在兩天的時間裏可以完成;開發人員要負責單元測試和接口測試,先後端是並行工做的;內建質量每一個人都要負起責任來;一旦有CI失敗立刻要有人去修復。

由於咱們你們都是坐在一塊兒的,面對面溝通很是方便,包括代碼review。咱們有Sonar掃碼監控還有哪些技術債務,隨時發現隨時修復,咱們也預留了一些時間去解決這些技術債務。

Q&A:

Q:如何上線快,風險小?

A:作互聯網的都有這樣的訴求,但願快速上線。肯定MVP(最小可行的產品)。如何去定義一個最小的可行產品,快速地開發快速地上線,而後獲得驗證?埋點也很重要,咱們要去分析用戶的行爲,由於咱們會有不少假設,必定要經過真實的用戶去驗證這些假設是否正確。

Q:有些老闆或者管理者思惟固化不肯意改變,如何讓他們接受你的提議?

A:如今應該不太會有說爲了作敏捷而作敏捷了。咱們必定要告訴管理者敏捷可以解決什麼樣的問題、可以帶來什麼樣的好處,這樣纔有可能會引起一些改變。固有思惟每一個人都會有,特別是老闆,可是咱們要相信他們既然能坐在這個位置上,應該是有不少成功經驗的累積,那些成功經驗可能就是基於他以往的一些方法,咱們如今是提出一個新的方法,他沒有嘗試過,因此有一些顧慮和擔憂也是正常的。

做爲敏捷教練,咱們不少時候都是基於痛點去切入的。

首先要深刻團隊、深刻企業瞭解真實的需求和想要解決的問題。

而後看看已有的實踐哪些能夠逐步引入並取得成效,用小成果來鞏固這些實踐。

同時領導可以看獲得的度量指標也是不可少的,要讓高層可以看獲得這個方法帶來的改變,讓他信任咱們,繼而再擴大實踐的範圍。

Q:對於跨業務線協做有沒有好的方法+工具?敏捷強調的是每一個人都是主人翁,但對於國內的公司環境是廣泛非扁平管理,敏捷的理論與實際應用是有差別的,怎麼看待這個問題?

A:跨業務線的方法和工具仍是不少的,主要看你們的需求,若是全部人都在一塊兒辦公,有一個物理的看板也是不錯的,若是在不一樣的地方就須要一些在線的工具來支持。還有就是咱們是否是多團隊協做的狀況,有不少大型的敏捷框架,好比LeSS、SAFe、scrum of scrums均可以用來解決協做的問題。

敏捷強調每一個人都是主人翁,而國內的環境大可能是非扁平的管理,我以前還蠻理想主義的,對這個問題也有糾結的時候。我當時有顧慮:這樣的環境是否是可以支持咱們作一些敏捷的實踐呢?事實證實其實也是有很多事情能夠作的。

雖然咱們在組織架構上很難說作到扁平,也不像國外那樣比較寬鬆的管理方式,可是其實咱們在一些小的環境裏是能夠作得很好的,好比我帶的這個伺客團隊,你們在一塊兒就很是融洽,咱們也沒有什麼層級概念。雖然有些人仍是偏向management contorl的方式,可是其實也會慢慢被影響。

咱們也提供了不少教練和引導技術去幫助這些管理者,包括我曾在部門推行的管理3.0和讀書會等,這些先進的理念你們也很容易接受。

Q:敏捷團隊有效性衡量指標除了需求完成率、發佈速率等,還有什麼別的具體的指標麼?

A:說到度量實際上是一個很大的話題,需求完成率、發佈速率等是一些指標。咱們但願經過度量達成什麼樣的目的?得先明確這個目的再來肯定要度量什麼。

好比咱們但願流動效率更高,那咱們就須要知道需求從開始想法到啓動開發到完成須要的時間大概是多少、每一個環節耗時多少。而後借用價值流分析很是有用的一些工具來幫助作一些改進。好比咱們可能從一個需求產出到發佈須要三個月的時間,但實際工做在這個需求上的時間可能只有五天不到,那咱們能夠算一個百分比,而後想怎麼可以讓它加快流動,隨之而來的就會有不少方法和策略能夠用上了。

Q:主要是敏捷跑得快了,質量好確定是前提,不能妥協,可是感受敏捷和DevOpS在應用中或多或少有點削弱了測試,對此您怎麼看?

A:確實質量是不能妥協的,我發如今我們國內作互聯網都仍是偏向糙快猛的方式,儘快地先上線再說,但實際上質量是一個很大的成本。

敏捷和DevOps實際上應該是增強測試,更多的自動化。而現實狀況是你們都在分析計算ROI、急着去趕某個時間點,有的時候可能確實會弱化了測試,這並非咱們但願看到的。

開發和測試在融合,咱們也但願業務、產品經理、開發、測試可以在一塊兒把需求實例化,而後經過ATDD在整個過程當中保證質量。質量不是測出來的,而是在需求產生的時候、代碼構建的時候就須要保證的。

Q:理論和實踐有距離,現實也會有誤差,不少團隊中專職測試人員或多或少都有在減小。如今平安開發人員必須作單元測試吧?還有專門的系統功能測試團隊嗎?

A:咱們會有一些專職的測試,但不是說越多越好,有的時候專職測試多了咱們反而容易產生依賴。咱們更傾向於讓開發團隊作好自測,作好自動化接口測試,就是說必要的測試都是由開發這邊保證、質量也是由開發這邊保證,咱們逐步但願培養每一個人都能是多面手。

單元測試是確定要的。專門的團隊負責系統功能測試比較少,多數是和開發在一塊兒的,非功能性測試會有一些,好比壓力測試、安全測試會有專門的人來負責。

Q:如何轉型成爲一個敏捷教練?
A:首先,要看一下本身是否是一個願意持續學習的人,是否是一個有開放心態的人,是否是一個願意去幫助別人的人。這是一個很好的基礎,若是具有這個基礎就能夠逐步地去學習一些敏捷的實踐。

其次,我以爲有一些好的團隊可以讓你體會到敏捷的好處,好比我曾經在Autodesk的時候就很幸運地帶一個特別優秀的團隊,你們很樂意去嘗試各類實踐並承擔各類工做,包括咱們也作了ATDD、以及一些看板的實踐,你們都可以感覺到它的好處,包括我本身。

第三,作一個敏捷教練我對這些實踐是深信不疑的,我相信它們能給團隊給你們帶來好處,而後我會去讀不少的書、和社區裏的小夥伴交流、參加一些大會聽聽其餘公司是怎麼用敏捷來作各類實踐的。

最後有當敏捷教練的機會必定要嘗試,若是發現還有些技能不足,再想辦法彌補。

推薦書籍:http://www.scrumchina.com/res...

相關文章
相關標籤/搜索