隨著軟件行業(yè)的發(fā)展，越來越多的企業(yè)開始進(jìn)行敏捷轉(zhuǎn)型榕订，在軟件開發(fā)過程中采用敏捷的方式，期望敏捷可以提升效率蜕便，改善質(zhì)量劫恒。敏捷也不再局限于互聯(lián)網(wǎng)行業(yè)，很多傳統(tǒng)行業(yè)——包括銀行轿腺、保險(xiǎn)两嘴、證券、電信等等也逐漸開始認(rèn)同敏捷的開發(fā)方式和流程族壳，在企業(yè)內(nèi)部的系統(tǒng)開發(fā)過程中把敏捷與原有的流程相互融合憔辫，以更好地適應(yīng)高速、快節(jié)奏所帶來的不確定性仿荆，從而達(dá)到更好地體現(xiàn) IT 部門價(jià)值的目的贰您。

轉(zhuǎn)型前客戶M和大多說傳統(tǒng)開發(fā)一樣面臨著大量的問題：

組織架構(gòu)按產(chǎn)品分層，各層研發(fā)團(tuán)隊(duì)分散于不同部門拢操，如何有效的協(xié)調(diào)各部門協(xié)作锦亦？

各種固化的流程、KPI數(shù)據(jù)度量庐冯、詳盡的文檔卻無法繼續(xù)推動產(chǎn)品質(zhì)量提升和開發(fā)效率持續(xù)提高孽亲。

業(yè)務(wù)需求端到端交付周期長，已經(jīng)無法滿足市場對需求快速響應(yīng)的要求展父。

為了改變現(xiàn)狀返劲，客戶M決定實(shí)施敏捷轉(zhuǎn)型玲昧，希望用業(yè)界領(lǐng)先的方法論指導(dǎo)企業(yè)生產(chǎn)力提升。項(xiàng)目從2017年1月份正式啟動篮绿，到2017年9月底一期大致收尾孵延，共歷時(shí)9個月的歷程，主要經(jīng)歷了調(diào)研分析亲配，設(shè)計(jì)規(guī)劃尘应，試點(diǎn)改進(jìn)，總結(jié)推廣吼虎，結(jié)項(xiàng)總結(jié)等階段犬钢，已經(jīng)初步完成了敏捷的轉(zhuǎn)型的第一階段，9個月的轉(zhuǎn)型轉(zhuǎn)型猶如刮骨療傷思灰，實(shí)踐中有很多收獲玷犹，也因?yàn)榉N種原因，留下很多遺憾洒疚。不過回頭看來歹颓，還是有很多可以分享：

一：敏捷轉(zhuǎn)型，意識先行：

在大型組織轉(zhuǎn)型過程中會碰到的各種阻力油湖、因?yàn)槊總€人都喜歡停留在自己的舒適區(qū)巍扛，想要讓人從舒適區(qū)中出來，是個技術(shù)活乏德。如何有效改變這個組織中的“人”撤奸？是否先從改變每個人的“行為”開始，進(jìn)而形成”新的習(xí)慣”喊括，還是先轉(zhuǎn)變“觀念”寂呛，然后改變行動。實(shí)踐證明瘾晃，對敏捷的推廣，必須做到意識先行幻妓。對敏捷的誤解很容易造成管理人員蹦误，團(tuán)隊(duì)成員對敏捷的抵觸，任何組織的變革中肉津，總會有小部分“抵觸者”的存在强胰，碰巧如果這些人影響力很大，對項(xiàng)目的推廣非常不利妹沙。轉(zhuǎn)變這些”抵觸者”為"支持者”是我們的工作重點(diǎn)之一偶洋。

下面就是我們在項(xiàng)目中聽到的，大家對敏捷典型的誤解：

“敏捷就是快”距糖，

這是對敏捷不了解的人對敏捷最深刻的誤會玄窝。

敏捷二字其實(shí)是針對需求變化的快速反應(yīng)而來牵寺，而不是過去所謂的快速應(yīng)用程序開發(fā)。敏捷開發(fā)為何會比傳統(tǒng)開發(fā)方法快恩脂？傳統(tǒng)開發(fā)法依循計(jì)劃帽氓、分析、設(shè)計(jì)俩块、程序開發(fā)黎休、測試再進(jìn)行修改整合后發(fā)布的步驟進(jìn)行，是一種順序性的開發(fā)模式玉凯，也就是說當(dāng)前一個步驟還沒完成之前势腮，后面的步驟就會位在等待的行列，當(dāng)前一個步驟用掉越多時(shí)間時(shí)則后面步驟的前置時(shí)間就會越長漫仆，而形成時(shí)間上越多的浪費(fèi)捎拯。也就是說傳統(tǒng)開發(fā)浪費(fèi)了太多的時(shí)間，在前置作業(yè)上的意思歹啼。前置時(shí)間造成了一種沒有充分運(yùn)用資源的現(xiàn)象玄渗，當(dāng)進(jìn)行到分析或設(shè)計(jì)的步驟時(shí)，程序設(shè)計(jì)人員仍然處于等待的狀態(tài)狸眼，因此形成了時(shí)間的浪費(fèi)藤树。

以下是客戶M原有的產(chǎn)品開發(fā)流程

反觀敏捷開發(fā)，實(shí)行的是一種務(wù)實(shí)的做法拓萌，例如:在進(jìn)行需求搜集的步驟時(shí)岁钓，當(dāng)收集到足夠一次迭代開發(fā)的需求時(shí)即向下一個步驟前進(jìn)，盡量縮短前置時(shí)間的浪費(fèi)微王，然后將”分析屡限、設(shè)計(jì)、開發(fā)與測試“形成一個開發(fā)步驟炕倘，減少了步驟與步驟之間的銜接時(shí)間钧大，這種開發(fā)方式形成了一種所謂的「衍生式的設(shè)計(jì)」，也就是遇到實(shí)質(zhì)上的問題時(shí)才采用設(shè)計(jì)方法來克服它罩旋，而不是預(yù)先作好設(shè)計(jì)的方式啊央。 因此讓起步顯得輕量化了，再加上只有少少的規(guī)范涨醋，所以敏捷才有了輕量化的開發(fā)方法的稱謂瓜饥。

這是敏捷的理念也是精髓：迅速響應(yīng)需求，快速反饋結(jié)果浴骂。agile 的引入像一股活水沖擊著老氣橫秋的瀑布流模型乓土，速度上跑贏幾條街，如下圖所示。

“敏捷會議多”趣苏，

Scrum定義了5大活動：產(chǎn)品待辦事項(xiàng)列表梳理狡相，Sprint計(jì)劃會議，每日Scrum會議拦键，Sprint評審會議谣光，Sprint回顧會議。初接觸敏捷的人芬为，會認(rèn)為突然多出很多會議萄金，而開發(fā)測試更愿意專注于可以看到結(jié)果的開發(fā)工作，而認(rèn)為會議是一種浪費(fèi)媚朦。

如果我們計(jì)算一下所有與會人員的開銷及管理費(fèi)用是很高昂的氧敢。因此，務(wù)實(shí)的做法是询张，會前做好充足的準(zhǔn)備孙乖，以確保敏捷會議盡可能的高效。

而其實(shí)所有的會議份氧，都是為了圍繞著開發(fā)進(jìn)行的團(tuán)隊(duì)溝通唯袄，敏捷的四大原則之一就是個人和互動高于流程和工具。

雖然會議是昂貴的蜗帜，但它們也是必要的恋拷。關(guān)鍵是高效的進(jìn)行，最大化的利用現(xiàn)有資源并培養(yǎng)良好的溝通厅缺。

”敏捷不需要文檔“

?長久來看蔬顾，文檔是提高效率的一大利器。雖然《宣言》中明確地放低了文檔的地位（“工作的軟件大于詳盡的文檔”）湘捎，敏捷強(qiáng)調(diào)互動和變化诀豁，以及對變化的及時(shí)響應(yīng)。誠然文檔恰恰做不到如此靈活窥妇。但敏捷真的完全排斥文檔嗎舷胜？

文檔的時(shí)效性和靈活性遠(yuǎn)低于口頭溝通，但卻有它實(shí)在的好處活翩。

1.空間上逞带，文檔傳播范圍更廣。規(guī)范化和常規(guī)化的內(nèi)容形成文檔可以大大減少溝通成本纱新。尤其在多個系統(tǒng)協(xié)作的情況下，跨 scrum 穆趴、跨團(tuán)隊(duì)甚至跨部門的溝通時(shí)有發(fā)生脸爱，文檔的重要性和便捷性不言而喻。

2.時(shí)間上未妹，文檔流傳性更好簿废。團(tuán)隊(duì)不是一成不變的空入，有人離開有人加入。更新?lián)Q代中族檬，新人快速了解系統(tǒng)歪赢，老兵傳承研發(fā)理念；在更大的時(shí)間跨度上单料，團(tuán)隊(duì)可能成為忒修斯之船埋凯，文檔的存在就是對產(chǎn)品歷程的完整追溯，你將不用他人幫助就可以了解到產(chǎn)品的大部分面貌甚至全貌扫尖。

而如何提高文檔的有效性是團(tuán)隊(duì)需要考慮的白对，比如測試代碼即文檔可以有效的減少團(tuán)隊(duì)重復(fù)工作，和提高文檔的實(shí)時(shí)有效性换怖。

二：外練肌肉甩恼，內(nèi)練經(jīng)脈：

外功練的是肌肉，內(nèi)功練的是經(jīng)脈沉颂；轉(zhuǎn)型必須先形似条摸，輔以心法修煉；外功會隨著年齡的老化而衰退铸屉，內(nèi)功隨著年齡增長而日益深厚钉蒲，老了也會深化，只是速度越來越慢而已抬探。

重塑敏捷團(tuán)隊(duì)架構(gòu)組織

問題：敏捷的產(chǎn)品團(tuán)隊(duì)子巾，產(chǎn)品經(jīng)理、產(chǎn)品負(fù)責(zé)人小压、開發(fā)團(tuán)隊(duì)线梗、ScrumMaster是一個整體團(tuán)隊(duì)，俗話說是一條船上的人怠益。如果這些人分乘幾條船仪搔，方向也不同，結(jié)果可想而知蜻牢。

這是技術(shù)支撐部的組織架構(gòu)圖烤咧，他們是三周一個版本，每個版本配屬一個版本經(jīng)理抢呆，負(fù)責(zé)統(tǒng)籌協(xié)調(diào)各個團(tuán)隊(duì)的工作和節(jié)奏煮嫌、解決各個團(tuán)隊(duì)的內(nèi)部問題、負(fù)責(zé)協(xié)調(diào)外部門的溝通抱虐。這里的外部門是指前端和客戶端昌阿。

版本發(fā)布流程是技術(shù)支撐部先上線，發(fā)布到現(xiàn)網(wǎng)，然后前端懦冰、客戶端分別上線芯侥，上線時(shí)間就看他們的開發(fā)進(jìn)度仑最。一個產(chǎn)品上線苛蒲，由三個部門負(fù)責(zé)勤篮，而且呈流水線工序。

羅馬不是一天建成的内地，欲速則不達(dá)伴澄。部門的變化或者融合很難一下子達(dá)成，強(qiáng)行去改變只會遇到更大的阻力瓤鼻，有可能會導(dǎo)致敏捷轉(zhuǎn)型失敗秉版。所以經(jīng)過協(xié)商，將前端和客戶端一起拉入敏捷團(tuán)隊(duì)茬祷，雖然行政上人員隸屬不同部門清焕，但是溝通變得開始簡單、工作節(jié)奏也可以保持一致祭犯。版本經(jīng)理的崗位依然保留著秸妥，協(xié)調(diào)三部門統(tǒng)一行動。

這是經(jīng)過調(diào)整后的敏捷團(tuán)隊(duì)架構(gòu)沃粗。

不過略微遺憾的是粥惧，企業(yè)敏捷很強(qiáng)調(diào)業(yè)務(wù)驗(yàn)收測試的作用，但是因?yàn)槎喾矫娴脑蜃钪眩粋€總體的突雪、上層的業(yè)務(wù)驗(yàn)收團(tuán)隊(duì)沒有能夠形成。目前還只是以重點(diǎn)需求抽檢模式涡贱，對產(chǎn)品質(zhì)量的保障還沒有達(dá)到預(yù)期的目標(biāo)咏删。

組建跨特性團(tuán)隊(duì)

問題：當(dāng)前團(tuán)隊(duì)每個版本采用小瀑布式的開發(fā)方式，需求下發(fā)到多個組件團(tuán)隊(duì)问词，在所有組件團(tuán)隊(duì)完成工作之后督函，才能集成并測試，整個開發(fā)過程需求不可見激挪。開發(fā)過程中以及現(xiàn)網(wǎng)問題難以解決辰狡，組件之間往往互相推諉，解決周期長垄分。

組件團(tuán)隊(duì)專注于開發(fā)組件或者子系統(tǒng)宛篇，這些組件或子系統(tǒng)只能實(shí)現(xiàn)最終客戶想要的部分特性，組件團(tuán)隊(duì)所有成員由技能相近的人組成薄湿，所有成員可能都向同一個職能經(jīng)理匯報(bào)工作叫倍，這種情況在客戶M尤為明顯豌鸡。

如何解決溝通不暢的問題？如何加速問題的解決段标？是開發(fā)部面對的最棘手問題。

組建跨職能特性團(tuán)隊(duì)炉奴，由特性團(tuán)隊(duì)完成特性所需的全部工作是敏捷轉(zhuǎn)型的第一步逼庞。有效的特性團(tuán)隊(duì)需要團(tuán)隊(duì)成員具備完成多種特性的技能和能力，以完成特性的全部工作瞻赶。對于這種完全共享代碼所有權(quán)的多特性團(tuán)隊(duì)模式赛糟，有一種解決方案如下：

但是客戶M的實(shí)際情況更為復(fù)雜：在客戶M由于不同的組件團(tuán)隊(duì)來自不同的分包商，理想情況下分包商之間人員全部打散砸逊，組成跨職能小團(tuán)隊(duì)璧南，每個團(tuán)隊(duì)具備多模塊能力，可以快速的實(shí)現(xiàn)端到端特性開發(fā)團(tuán)隊(duì)师逸；但多分包商組成的跨職能團(tuán)隊(duì)合作與管理復(fù)雜度走然提升：不同的分包商人員合作是否順暢司倚？SM誰來承擔(dān)？人員的考核誰來定篓像？最重要的多分包商以往按照完成工時(shí)計(jì)算工作量动知，打散之后各分包商工作量又該如何核算？

最終經(jīng)過團(tuán)隊(duì)商過后员辩，我們決定采用各組件團(tuán)隊(duì)直接切割為特性團(tuán)隊(duì)的模式盒粮，避免了跨分包商團(tuán)隊(duì)的情況出現(xiàn)，但是如此一來奠滑，每個特性團(tuán)隊(duì)都是能力儲備不健全的丹皱，因?yàn)樘匦詧F(tuán)隊(duì)的成員只具備同一個組件的能力。很明顯宋税，這樣特性團(tuán)隊(duì)與我們要求的具備各組件領(lǐng)域知識的團(tuán)隊(duì)相差甚遠(yuǎn)摊崭，但轉(zhuǎn)型之初，我們就保證必須保證版本的開發(fā)能力弃甥，產(chǎn)品質(zhì)量在轉(zhuǎn)型期間不能有下滑爽室，所以一邊需要保障版本的開發(fā)交付正常進(jìn)行，另一方面特性團(tuán)隊(duì)還沒真正成長起來淆攻，理想和現(xiàn)實(shí)的差距又橫在我們面前阔墩。

敏捷的落地就是理想和現(xiàn)實(shí)的碰撞，然后找到最佳的結(jié)合點(diǎn)瓶珊。本著遇到問題解決問題的態(tài)度啸箫，我們協(xié)調(diào)團(tuán)隊(duì)之間形成臨時(shí)合作伙伴的方式，不同能力的團(tuán)隊(duì)互為結(jié)對伞芹，相當(dāng)于學(xué)習(xí)小組忘苛，對合作團(tuán)隊(duì)的開發(fā)手把手的指導(dǎo)蝉娜，迅速幫對方建立各組件知識，以緩解能力的差距扎唾，帶團(tuán)隊(duì)慢慢建立起相關(guān)的領(lǐng)域能力召川，等能力成長起來之后再慢慢獨(dú)立開發(fā)。

以用戶故事描述需求

問題：以需求分析文檔為基礎(chǔ)胸遇，由分析人員拆分到組件的任務(wù)荧呐，往往顆粒度較大。在試點(diǎn)前期纸镊，我們發(fā)現(xiàn)每個團(tuán)隊(duì)成員在一個迭代中倍阐，基本只能完成1到2個任務(wù)，團(tuán)隊(duì)成員之間沒配合逗威，團(tuán)隊(duì)成長緩慢峰搪，對項(xiàng)目進(jìn)度的管理造成困難。

敏捷開發(fā)推薦以用戶故事的方式對需求進(jìn)行描述凯旭，用戶故事可以幫助開發(fā)團(tuán)隊(duì)從用戶的角度來理解需求概耻，同時(shí)在交付的過程中按照用戶可用的場景進(jìn)行交付，確保了開發(fā)團(tuán)隊(duì)可以持續(xù)的交付用戶關(guān)心的功能尽纽。原團(tuán)隊(duì)則以產(chǎn)品需求文檔PRD傳遞需求咐蚯，直接拆分到組件，由組件團(tuán)隊(duì)開發(fā)交付弄贿，在團(tuán)隊(duì)轉(zhuǎn)型特性團(tuán)隊(duì)之后春锋，迫切的需要轉(zhuǎn)型為以用故事的方式管理需求。

需求拆分到單模塊任務(wù)差凹，顆粒度大期奔，涉及多業(yè)務(wù)場景，容易發(fā)生遺漏危尿，集成時(shí)間晚呐萌。而用戶故事以用戶角度描述系統(tǒng)需求，直觀可見谊娇，驗(yàn)證方便肺孤，開發(fā)過程可見，顆粒度更小济欢，風(fēng)險(xiǎn)可控赠堵。

需求分析方式的轉(zhuǎn)變對MDE習(xí)慣來說還是有挑戰(zhàn)的，因?yàn)榘凑展ぷ髁?xí)慣法褥，通常都是MDE直接分析到接口茫叭，然后再交給團(tuán)隊(duì)做詳細(xì)設(shè)計(jì)，用戶故事引入之后半等，整個部門原有的分析流程并沒有打破揍愁，試點(diǎn)團(tuán)隊(duì)拿到需求的時(shí)候呐萨，已經(jīng)是MDE分析到接口的需求，為了適配新的用戶故事莽囤，自然而然開始把拆分的任務(wù)映射到用戶故事谬擦。

這種工作方式的本身屬于本末倒置，先有了接口任務(wù)朽缎，才有到用戶故事的映射怯屉，但是在整個部門大流程沒有變化的情況下，試點(diǎn)團(tuán)隊(duì)的小流程也必須具備兼容性饵沧。為了保障試點(diǎn)團(tuán)隊(duì)開發(fā)的流暢性，試行了兩個版本赌躺，期間就發(fā)現(xiàn)由于用戶故事顆粒度較小狼牺，往往出現(xiàn)一個任務(wù)對應(yīng)多個用戶故事的情況。

此時(shí)的用戶故事礼患，徒有其形是钥，沒有發(fā)揮真正的描述需求的作用。我們在和團(tuán)隊(duì)進(jìn)行多輪用戶故事的培訓(xùn)之后缅叠，強(qiáng)調(diào)了廢棄對接口分析后的需求文檔悄泥，完全采用用戶故事的方式描述需求，進(jìn)而拆分到任務(wù)肤粱，任務(wù)的顆粒度有了明顯的減小弹囚。

需求分析流程優(yōu)化

問題：各組件MDE作為需求分析人員，每條需求需要多個組件MDE進(jìn)行分析影響领曼，長期成為需求分析的瓶頸鸥鹉；而團(tuán)隊(duì)成員只負(fù)責(zé)代碼開發(fā)，對需求不了解庶骄，完全按照概要設(shè)計(jì)進(jìn)行開發(fā)毁渗，一葉遮目不見泰山！

客戶M原有的需求分析流程冗長单刁，在產(chǎn)品經(jīng)理和最終的開發(fā)人員之間還隔著PO和MDE(需求分析工程師)兩層角色灸异，這樣的規(guī)劃對敏捷轉(zhuǎn)型造成了三方面的影響：

1、不符合我們敏捷開發(fā)模式下羔飞，PO/團(tuán)隊(duì)/SM通力協(xié)作扁平化的要求肺樟。

2、MDE只負(fù)責(zé)模塊褥傍、接口分析儡嘶，但不編寫或者很少編寫代碼，時(shí)間長了之后恍风，代碼能力下降蹦狂。

3誓篱、開發(fā)人員嚴(yán)重依賴MDE，對自己負(fù)責(zé)的業(yè)務(wù)內(nèi)容并不了解凯楔。

在和團(tuán)隊(duì)協(xié)商過后窜骄，我們決定取消MDE的角色，分拆到團(tuán)隊(duì)進(jìn)行分析指導(dǎo)摆屯，幫助團(tuán)隊(duì)能力建設(shè)邻遏，同時(shí)參與代碼開發(fā)。

MDE和團(tuán)隊(duì)融合虐骑，扁平化開發(fā)團(tuán)隊(duì)角色准验，開發(fā)參與分析，省去反講環(huán)節(jié)廷没；數(shù)據(jù)顯示糊饱，版本需求分析時(shí)長3周降至1.5周。

Scrum Master選拔

問題：ScrumMaster的選拔由分包商自行挑選颠黎，選拔標(biāo)準(zhǔn)不統(tǒng)一另锋，導(dǎo)致推舉的SM多為技術(shù)牛人，工作安排是命令控制型狭归，很多會議變成SM的一言堂夭坪。

SM是轉(zhuǎn)型到團(tuán)隊(duì)內(nèi)部推動的關(guān)鍵，如何選擇合適的SM是保障實(shí)施效果很重要的一環(huán)过椎，技術(shù)牛人室梅，意見領(lǐng)袖，都有可能被推舉為SM疚宇，什么樣的人適合做SM竞惋，那首先看下SM需要做什么？Scrum Master的職責(zé)簡單的說可以總結(jié)為：?

作為團(tuán)隊(duì)教練灰嫉，確保團(tuán)隊(duì)按照Scrum的方式運(yùn)行拆宛，幫助團(tuán)隊(duì)更好的工作。

移除項(xiàng)目進(jìn)度的障礙讼撒，保護(hù)團(tuán)隊(duì)成員被過度承諾等浑厚。

SM就像團(tuán)隊(duì)的一個大保姆，維護(hù)工作方式根盒，保護(hù)團(tuán)隊(duì)钳幅，為團(tuán)隊(duì)和持續(xù)改進(jìn)負(fù)責(zé)，而非技術(shù)或者業(yè)務(wù)的決定者炎滞；而技術(shù)大拿敢艰，意見領(lǐng)袖如果不具備傾聽團(tuán)隊(duì)的特質(zhì)，獨(dú)斷專行册赛，經(jīng)常幫團(tuán)隊(duì)拿主意钠导，出方案震嫉，且不說解決方案質(zhì)量如何，團(tuán)隊(duì)成員的參與度非常低牡属，無法培養(yǎng)主人公的精神票堵，長此以往團(tuán)隊(duì)沒有平等對話的氣氛，團(tuán)隊(duì)成員沒有對團(tuán)隊(duì)的歸屬感逮栅，這是在敏捷團(tuán)隊(duì)中最不想看到的悴势。

在客戶M的敏捷推廣的過程中，根據(jù)實(shí)際情況措伐，優(yōu)先能力突出的MDE擔(dān)當(dāng)SM角色特纤，雖然從技術(shù)能力上得到保障，但在帶領(lǐng)團(tuán)隊(duì)方面還存在能力不足的情況侥加，在后續(xù)推廣中大部分SM的能力得到了鍛煉叫潦，個別出現(xiàn)了團(tuán)隊(duì)協(xié)作不通暢的情況，SM人選也及時(shí)做了調(diào)整官硝。

崗位職責(zé)重新定義

問題：為了適應(yīng)敏捷團(tuán)隊(duì)的開發(fā)模式，對現(xiàn)有團(tuán)隊(duì)人員進(jìn)行了崗位職責(zé)的梳理和重新定義短蜕，重新調(diào)整了組織架構(gòu)氢架。

跨職能的團(tuán)隊(duì)是敏捷項(xiàng)目里的交付單元，但企業(yè)級的敏捷只有這些團(tuán)隊(duì)是玩不轉(zhuǎn)的朋魔。如何圍繞Scrum團(tuán)隊(duì)岖研，打造周邊的服務(wù)團(tuán)隊(duì)，是企業(yè)敏捷成功的關(guān)鍵警检。

圍繞著新型的跨職能團(tuán)隊(duì)孙援，我們組建了：

PO團(tuán)隊(duì)，包括了產(chǎn)品經(jīng)理和系統(tǒng)分析師SA扇雕，主要為團(tuán)隊(duì)導(dǎo)入高價(jià)值的需求拓售，負(fù)責(zé)需求驗(yàn)收。

代碼看護(hù)團(tuán)隊(duì)：原各組件團(tuán)隊(duì)的負(fù)責(zé)人镶奉，對組件代碼最為了解础淤，繼續(xù)發(fā)揮長項(xiàng)，轉(zhuǎn)型為代碼看護(hù)哨苛，優(yōu)先識別團(tuán)隊(duì)之間依賴關(guān)系鸽凶，把控模塊整體質(zhì)量。

TC測試控制團(tuán)隊(duì)：原各組件測試的負(fù)責(zé)人建峭，對組件測試最為了解玻侥，轉(zhuǎn)型為測試控制團(tuán)隊(duì)，負(fù)責(zé)團(tuán)隊(duì)特性測試方案的審核亿蒸，確保測試質(zhì)量凑兰。

解決方案驗(yàn)收測試團(tuán)隊(duì)：統(tǒng)一的驗(yàn)收測試團(tuán)隊(duì)掌桩，實(shí)現(xiàn)端到端的驗(yàn)收測試。

ETC：團(tuán)隊(duì)內(nèi)部的敏捷推薦組織票摇，主要是發(fā)現(xiàn)拘鞋、解決團(tuán)隊(duì)在轉(zhuǎn)型過程中的問題，組織必要的培訓(xùn)矢门、分享等等盆色。

敏捷轉(zhuǎn)型不能一蹴而就，需要給團(tuán)隊(duì)成長容錯的空間祟剔，但產(chǎn)品不等人隔躲，綜合團(tuán)隊(duì)當(dāng)前所面對的實(shí)際情況，確立該方案物延，團(tuán)隊(duì)間各司其職互相協(xié)作宣旱，適合在敏捷團(tuán)隊(duì)建設(shè)過渡期內(nèi)，以質(zhì)量為先決條件叛薯，保證迭代持續(xù)進(jìn)行浑吟。

團(tuán)隊(duì)能力提升

問題：特性團(tuán)隊(duì)的成員由原單個組件團(tuán)隊(duì)組成，彼此技能相似耗溜，而特性團(tuán)隊(duì)需要各組件能力组力，如何快速建立，并保證產(chǎn)品質(zhì)量抖拴？

團(tuán)隊(duì)能力提升是玩轉(zhuǎn)敏捷的基礎(chǔ)燎字，沒有優(yōu)秀的團(tuán)隊(duì)成員，敏捷就是無本之木阿宅，無源之水候衍。敏捷團(tuán)隊(duì)要求團(tuán)隊(duì)成員是一專多能的T型人才，而客戶M開發(fā)團(tuán)隊(duì)因?yàn)殚L期按照組件的方式開發(fā)洒放，團(tuán)隊(duì)成員能力單一蛉鹿。巧婦難為無米之炊，如何在現(xiàn)況下往湿，最大化的支持高效的敏捷的開發(fā)榨为，是我們必須考慮的。

我們組織各團(tuán)隊(duì)搞跨模塊學(xué)習(xí)煌茴，制定詳細(xì)的學(xué)習(xí)計(jì)劃随闺，建立起長效的學(xué)習(xí)機(jī)制，以保障團(tuán)隊(duì)能力成長蔓腐。如下圖矩乐，互動團(tuán)隊(duì)的跨模塊學(xué)習(xí)規(guī)劃。

能力提升的落實(shí)一定要在細(xì)處，比如我們采用1帶1的方式散罕，具備模塊能力的成員做開發(fā)分歇，需要提升該模塊能力的成員配合做單元測試，這樣通過特性的開發(fā)過程欧漱，熟悉代碼結(jié)構(gòu)职抡，業(yè)務(wù)邏輯等。通過2個迭代的學(xué)習(xí)熟悉误甚，開發(fā)人員已經(jīng)可以開始在新的模塊上進(jìn)行開發(fā)缚甩。

管理可視化

問題：敏捷管理工具五花八門，客戶M經(jīng)過多年的發(fā)展窑邦，已經(jīng)有了自己的工具擅威，是推到重來？還是打通工具之間的墻冈钦，協(xié)同作戰(zhàn)郊丛，形成工具體系？

敏捷管理工具主要還是為了過程可視化瞧筛，增加透明度厉熟，提升管理效率。期間我們?yōu)榭蛻鬗引入了基于Icescrum的白板管理工具较幌，但是在經(jīng)過3個版本的試點(diǎn)之后發(fā)現(xiàn)一個很嚴(yán)重的問題：與現(xiàn)有工具的不兼容揍瑟。

客戶M需求管理平臺客戶使用的是Redmine，已經(jīng)集成很多流程和配置绅络，PO的需求都是在Redmine上下發(fā)給團(tuán)隊(duì)，而我們給客戶導(dǎo)入的開發(fā)迭代管理工具是Icescrum嘁字，需求需要重新建立恩急，而不能直接由需求管理平臺下發(fā)。兩個平臺無法的銜接纪蜒，團(tuán)隊(duì)成員苦于在工具之間切換衷恭，效率太低，這樣低效的狀況有悖于我們的初衷：工具本身是為了提高團(tuán)隊(duì)效率纯续，而不是增加團(tuán)隊(duì)負(fù)擔(dān)随珠。

團(tuán)隊(duì)在商議之后，決定拓展Redmine的白板管理功能猬错，取代試點(diǎn)的Icescrum窗看。工具的選擇與推廣是否能和客戶的習(xí)慣有效結(jié)合是我們需要關(guān)注的，此舉也得到了團(tuán)隊(duì)的一致歡迎倦炒。

另外工具使用習(xí)慣的培養(yǎng)也是一個漫長的過程显沈，避免采用命令的方式強(qiáng)行要求團(tuán)隊(duì)配合使用，最好結(jié)合團(tuán)隊(duì)工作的流程，比如使用電子白板作為晨會的白板拉讯，以事件涤浇，流程驅(qū)動和培養(yǎng)大家使用習(xí)慣。

CI并不是一句口號而已

問題：俗話說魔慷，不做CI的敏捷都是在耍流氓只锭。團(tuán)隊(duì)已經(jīng)建立了一套CI的框架，Hudson院尔、Maven等等工具都做了集成蜻展。不過再好的工具體系也得真正嵌入流程中使用起來，否則也只是擺放在那里的一個好看的花瓶而已召边。

企業(yè)轉(zhuǎn)向高效開發(fā)運(yùn)營铺呵，CI是必要的，其中自動化又是重中之重隧熙。CI框架的搭建是第一步片挂，客戶M已經(jīng)完成，接下來就是使用的問題贞盯。教練團(tuán)隊(duì)對自動化測試的覆蓋率做了一次評估音念。

客戶M有零星的單元測試和接口測試，但更多的是手動測試躏敢，每次開發(fā)兩周需要兩周時(shí)間集成測試并驗(yàn)收闷愤，嚴(yán)重阻礙的交付效率。

單元測試件余、接口測試的自動化測試腳本并沒有集成到Hudson上讥脐，開發(fā)團(tuán)隊(duì)都是本機(jī)跑這些用例，代碼提交到Hudson上沒有辦法調(diào)用腳本進(jìn)行測試啼器。

問題暴露出來之后旬渠，轉(zhuǎn)型團(tuán)隊(duì)一起努力提高自動化測試的覆蓋率，并且將單元測試和接口測試的腳本集成到了Hudson上端壳，開發(fā)團(tuán)隊(duì)只要提交代碼告丢，即可看到測試結(jié)果芦鳍，及早暴露問題骨饿。

敏捷發(fā)布火車

問題：技術(shù)支撐部門交付產(chǎn)品，未經(jīng)過前端客戶端測試合愈，產(chǎn)品上線后并未達(dá)到終端客戶使用的要求照捡。而技術(shù)支撐部颅湘，前端客戶端順序的開發(fā)節(jié)奏，開發(fā)節(jié)奏的不匹配也導(dǎo)致部門之間響應(yīng)速度比較慢栗精！

客戶M的開發(fā)部門分為閱讀事業(yè)部（包含前端開發(fā)測試）栅炒，技術(shù)支撐部（后臺），應(yīng)用開發(fā)部（app開發(fā)測試），產(chǎn)品的交付主要由技術(shù)支撐部驅(qū)動赢赊，在改進(jìn)之前乙漓，前端和客戶端分別有自己的發(fā)布計(jì)劃，任何部門的延遲都可能影響到一個功能的準(zhǔn)時(shí)發(fā)布释移。

探討分析之后我們引入敏捷發(fā)布火車叭披，以技術(shù)支撐部計(jì)劃為主導(dǎo)，前端和客戶端協(xié)同參加技術(shù)支撐部計(jì)劃的新工作方式玩讳。各部門分別完成單元測試涩蜘，接口測試之后，統(tǒng)一進(jìn)行集成測試熏纯，由以前異步式的交付節(jié)奏轉(zhuǎn)變?yōu)橥绞降慕桓斗绞健?/p>

這樣的工作方式帶來的最大的好處就是：

平臺功能測試無需再自行搭建簡易頁面測試同诫，在更接近現(xiàn)網(wǎng)的準(zhǔn)測試生產(chǎn)環(huán)境上，直接與前端客戶端對接樟澜，提前暴露了對接后有可能暴露的問題误窖。

前端客戶端在技術(shù)支撐部迭代計(jì)劃內(nèi)協(xié)同測試，發(fā)現(xiàn)需要聯(lián)調(diào)的問題秩贰，可以第一時(shí)間安排技術(shù)支撐部門協(xié)調(diào)解決霹俺，緩解了部門之間開發(fā)節(jié)奏不一致，導(dǎo)致的問題解決緩慢毒费。

遺憾：采用同步開發(fā)測試的交付方式也不是十全十美丙唧，因?yàn)榧蓽y試的環(huán)境和準(zhǔn)現(xiàn)網(wǎng)測試環(huán)境還有差距，前端客戶端在火車發(fā)布后觅玻，還需要在現(xiàn)網(wǎng)環(huán)境進(jìn)行重復(fù)測試以確保功能想际。該問題只有在徹底解決準(zhǔn)現(xiàn)網(wǎng)環(huán)境后才能緩解。

企業(yè)敏捷轉(zhuǎn)型社區(qū)

問題：試點(diǎn)團(tuán)隊(duì)經(jīng)過3個版本的試點(diǎn)溪厘，催生了很多優(yōu)秀的實(shí)踐胡本，如何在推廣階段有效分享到其他團(tuán)隊(duì)？如何在后續(xù)的推廣中桩匪，互相分享踩過的坑打瘪，優(yōu)秀的實(shí)踐友鼻，讓團(tuán)隊(duì)更快成長傻昙？

企業(yè)轉(zhuǎn)型社區(qū)（Enterprise Transformation Community）應(yīng)運(yùn)而生。它是為了創(chuàng)造一種文化彩扔、一個氛圍——那些對企業(yè)的成功抱有滿腔熱情的人嘗試做出改變妆档，而這些人的成功又吸引更多的人產(chǎn)生更大的熱情。ETC 不是通過給企業(yè)強(qiáng)加變革來做到這點(diǎn)虫碉，而是通過指導(dǎo)實(shí)施變革的小組贾惦，移去障礙以便做好Scrum，和為變革創(chuàng)造活力與激情來做到這點(diǎn)的。

企業(yè)范圍內(nèi)實(shí)施Scrum 時(shí)须板，對ETC 的成員組成可能更要深思熟慮碰镜。ETC 應(yīng)至少包括PO和SM，以及敏捷推動的相關(guān)高層責(zé)任人习瑰，甚至相關(guān)部門干系人绪颖，資深開發(fā)測試都可以參與到ETC。在轉(zhuǎn)型的初期甜奄，會議召開的頻率可以達(dá)到每周一次柠横，以盡快的發(fā)現(xiàn)問題，解決問題课兄，以及分享經(jīng)驗(yàn)牍氛。

ETC會議主題應(yīng)該來自于各團(tuán)隊(duì)，而不應(yīng)該簡單的由會議組織者確定烟阐“峥。可以針對內(nèi)部團(tuán)隊(duì)實(shí)踐中的問題，也可以是外部敏捷的分享曲饱。

ETC 與Scrum 開發(fā)團(tuán)隊(duì)一樣使用Scrum悠抹，所以他們也通過sprints 取得進(jìn)展。每個ETC sprint 以計(jì)劃會議開始扩淀，以評審和回顧會議結(jié)束楔敌。這些會議和Scrum 開發(fā)團(tuán)隊(duì)的那些會議完全一樣，也經(jīng)常發(fā)生同樣的問題驻谆。

重構(gòu)卵凑，我們走在前行的路上

問題：客戶M的系統(tǒng)架構(gòu)是華為以前設(shè)計(jì)的，典型的組件式胜臊、強(qiáng)耦合勺卢，各個組件交織糾纏，牽一發(fā)而動全身象对。隨著互聯(lián)網(wǎng)的發(fā)展黑忱，強(qiáng)調(diào)價(jià)值快速交付的當(dāng)下，越來越顯得步履維艱勒魔。

客戶M的系統(tǒng)架構(gòu)是典型的組件式甫煞，一共有七大組件，各組件間強(qiáng)耦合冠绢，導(dǎo)致開發(fā)前置條件過多抚吠，發(fā)生現(xiàn)網(wǎng)問題也需要逐個組件排查，定位效率低弟胀，修復(fù)時(shí)間長楷力，運(yùn)維團(tuán)隊(duì)的壓力也非常大喊式。既然決心推動敏捷，最終萧朝、最難啃的骨頭也是應(yīng)用系統(tǒng)的架構(gòu)設(shè)計(jì)岔留，客戶M也認(rèn)識到了這樣的問題，決心開始逐步改變检柬。

當(dāng)前業(yè)內(nèi)炒的最火的微服務(wù)架構(gòu)贸诚，是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成厕吉。系統(tǒng)中的各個微服務(wù)可被獨(dú)立部署酱固，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)头朱。在所有情況下运悲，每個任務(wù)代表著一個小的業(yè)務(wù)能力∠钆ィ客戶M也朝著這個方向去改造班眯。

經(jīng)過一段時(shí)間的梳理，48個特性已經(jīng)被總結(jié)出來烁巫，最終還會體現(xiàn)在系統(tǒng)架構(gòu)上署隘，目的就是希望每個敏捷團(tuán)隊(duì)能夠獨(dú)立運(yùn)作，解耦合亚隙，不再互相干擾磁餐。

目前門戶已經(jīng)開始進(jìn)行重構(gòu)，底層服務(wù)拆分也逐步啟動阿弃，隨著時(shí)間的推移诊霹，我們相信最終的結(jié)果一定是值得期待的。

三：種下行動渣淳，收獲進(jìn)步

經(jīng)過兩個版本的敏捷推廣脾还，我們得到來自團(tuán)隊(duì)各種各樣反饋，比如團(tuán)隊(duì)參與度更強(qiáng)入愧，交流更加通暢鄙漏，開發(fā)效率更高了等。通過管理數(shù)據(jù)監(jiān)控和分析棺蛛，我們已經(jīng)明顯看到敏捷推廣帶來的一些改變趨勢怔蚌，包括交付質(zhì)量，交付效率都有了明顯的提升鞠值。

交付質(zhì)量提升

通過127~130版本的數(shù)據(jù)收集媚创，我們發(fā)現(xiàn)在版本需求承接能力不變的情況下渗钉，127(39條)彤恶、 128(41條)钞钙、 129(48條)、 130(43條) 声离。整體缺陷總數(shù)和缺陷密度下降約20%芒炼。

我們知道缺陷的成本曲線，越晚發(fā)現(xiàn)缺陷修復(fù)的成本越高术徊。因此問題提前發(fā)現(xiàn)本刽，也是也是我們測試質(zhì)量提升的表現(xiàn)。通過下表我們發(fā)現(xiàn)赠涮，SIT1階段缺陷比重上升約25%子寓，說明端到端測試也有效果。

指標(biāo)說明：

ST缺陷占比率=ST測試階段的缺陷數(shù)/缺陷總數(shù)*100%?

SIT1缺陷占比率=SIT1測試階段的缺陷數(shù)/(SIT1+SIT2+SIT3)*100%?

交付效率提升

技術(shù)支撐部上線后笋除，一個關(guān)鍵的指標(biāo)就是需求上線時(shí)長斜友，準(zhǔn)確的說就是該條需求和前端客戶端集成測試開始到完成的時(shí)間，中間發(fā)現(xiàn)的問題越少垃它，解決的時(shí)間越快鲜屏，意味著上線時(shí)長越短。

相比非敏捷需求国拇，單位敏捷需求在前端客戶端集成測試階段洛史，缺陷密度下降約41%（0.56降低至033）。

質(zhì)量的提升使敏捷需求的上線時(shí)長降至2.75天

經(jīng)歷了啟程時(shí)的興奮到收尾時(shí)的豁然開朗酱吝，深刻體會到企業(yè)敏捷的落地是理想和現(xiàn)實(shí)的激烈碰撞也殖。敏捷轉(zhuǎn)型不是一蹴而就，也沒有銀彈务热，所有的問題都要用心感受客戶心聲毕源，探索最優(yōu)的解決方案。敏捷是個過程陕习，卻沒有終點(diǎn)霎褐，這其中最讓人著迷的也就是在敏捷燈塔的指引下，一步步探索该镣，不斷靠近彼岸的過程冻璃。