作者 | 九歌 網(wǎng)易智企服務(wù)端開(kāi)發(fā)

敏捷開(kāi)發(fā)的一個(gè)重要目標(biāo)是建立持續(xù)價(jià)值交付的能力。這種能力最終必須服務(wù)于業(yè)務(wù)的創(chuàng)新，促進(jìn)業(yè)務(wù)的成功。

面臨的問(wèn)題

在互聯(lián)網(wǎng)行業(yè)，業(yè)務(wù)的發(fā)展通常日新月異，并且伴隨著不斷的試錯(cuò)。這對(duì)研發(fā)團(tuán)隊(duì)的效率和靈活性有著非常高的要求，在傳統(tǒng)的迭代模式中面臨很多問(wèn)題，如：

• 需求相互耦合，上線交叉感染。一個(gè)版本上線出現(xiàn)問(wèn)題時(shí)，由于上線的內(nèi)容很多，定位問(wèn)題就會(huì)變得更困難，不能確定是哪個(gè)需求的變更引起的問(wèn)題。
• 臨時(shí)調(diào)整需求，牽一發(fā)而動(dòng)全身。大家應(yīng)該都碰到過(guò)版本上線前一天了，產(chǎn)品說(shuō)有個(gè)很重要的需求必須得加急上，不上不行。這種臨時(shí)的需求調(diào)整，對(duì)版本的交付影響是很大的。
• 因?yàn)橐粋€(gè)不重要的需求，延期整個(gè)版本的上線。上線當(dāng)天，可能發(fā)現(xiàn)有一個(gè)不是很重要的需求有問(wèn)題，整個(gè)版本都必須等這個(gè)問(wèn)題解決，有時(shí)候直接回導(dǎo)致版本的延期，或者產(chǎn)生很多臨時(shí)方案。
• 整個(gè)團(tuán)隊(duì)上線發(fā)布到凌晨。由于一個(gè)版本交付的內(nèi)容太多了，準(zhǔn)備工作很長(zhǎng)，影響的范圍也很大，通常會(huì)安排在晚上做發(fā)布，而發(fā)布過(guò)程中只要遇到一兩個(gè)問(wèn)題，通常發(fā)布就會(huì)搞到凌晨甚至后半夜。
• 有checklist依然不能避免遺漏。同樣也是當(dāng)版本越大，內(nèi)容越多時(shí)，就越容易遺漏。
• 不同價(jià)值的需求，相互影響。一個(gè)版本中通常會(huì)包含各種優(yōu)先級(jí)的需求，而不同優(yōu)先級(jí)的需求同時(shí)開(kāi)發(fā)交付，就一定會(huì)存在相互影響的問(wèn)題。
• 產(chǎn)研團(tuán)隊(duì)交付效率上不去。所有問(wèn)題最后都導(dǎo)致了交付效率上不去，交付質(zhì)量上不去。

相信大家也有碰到過(guò)和我們類似的這些問(wèn)題。這其中有很多問(wèn)題，都是可以通過(guò)敏捷交付來(lái)解決。

敏捷VS迭代

那什么是敏捷呢？關(guān)于敏捷模式和迭代模式的理論知識(shí)，相信大家都已經(jīng)有些了解，這里就不細(xì)說(shuō)其中的理論知識(shí)了。

迭代模式中每個(gè)迭代的需求、時(shí)間、資源是確定的，三個(gè)因素相互制約。最大的優(yōu)勢(shì)在于可預(yù)測(cè)性，流程簡(jiǎn)單，有固定的時(shí)間點(diǎn)。但同時(shí)帶來(lái)的問(wèn)題是缺乏靈活性，進(jìn)入版本后，調(diào)整需求或時(shí)間的代價(jià)會(huì)非常大，并且版本越大時(shí)帶來(lái)的風(fēng)險(xiǎn)和不確定性越大。大多數(shù)研發(fā)團(tuán)隊(duì)采用的都是迭代模型。敏捷模式中需求變成了變量，在固定時(shí)間和資源的情況下，靈活調(diào)整需求，從而獲得最大交付價(jià)值。

如圖所示，迭代模式中整個(gè)團(tuán)隊(duì)按步驟一步步執(zhí)行，最終全量交付。而在敏捷模式中，在固定的時(shí)間內(nèi)（迭代周期）將一個(gè)版本拆分為一個(gè)個(gè)可以獨(dú)立交付上線的需求，優(yōu)先交付高優(yōu)先級(jí)（高價(jià)值）的需求，并由一個(gè)個(gè)獨(dú)立的小團(tuán)隊(duì)負(fù)責(zé)交付。最大的優(yōu)勢(shì)是非常靈活，可以根據(jù)實(shí)際情況隨時(shí)調(diào)整需求，同時(shí)由于交付單元限定在最小范圍內(nèi)，使得上線發(fā)布的影響范圍最小，風(fēng)險(xiǎn)可控，也可以提高交付質(zhì)量。目標(biāo)是在盡可能短的時(shí)間內(nèi)交付盡可能高的價(jià)值。

先試點(diǎn)再推廣

進(jìn)行敏捷交付的轉(zhuǎn)型前，我們進(jìn)行了很多調(diào)研和溝通工作，學(xué)習(xí)公司內(nèi)部外部已經(jīng)實(shí)現(xiàn)敏捷交付的團(tuán)隊(duì)的經(jīng)驗(yàn)。然后制定了初步的方案，并在小范圍內(nèi)進(jìn)行試點(diǎn)，試點(diǎn)過(guò)程中不斷調(diào)整方案，調(diào)試工具，當(dāng)試點(diǎn)方案執(zhí)行順利以后再推廣到整個(gè)團(tuán)隊(duì)?；タ蛣傞_(kāi)始的時(shí)候，就是選擇其中一些比較小的簡(jiǎn)單的需求來(lái)進(jìn)行試點(diǎn)的。在轉(zhuǎn)型的過(guò)程中，我們總結(jié)出四個(gè)重要的要素：系統(tǒng)、規(guī)范、工具、組織。

需要準(zhǔn)備什么

系統(tǒng)架構(gòu)

首先想要進(jìn)行敏捷交付，需要有能適應(yīng)敏捷模型的研發(fā)環(huán)境，包括系統(tǒng)的合理拆分、邊界清晰的業(yè)務(wù)、可以進(jìn)行獨(dú)立開(kāi)發(fā)測(cè)試的環(huán)境隔離能力。要有平滑發(fā)布的能力，任何時(shí)間發(fā)布任何服務(wù)不應(yīng)該因?yàn)榘l(fā)布動(dòng)作本身引起問(wèn)題。還需要有完善的監(jiān)控可以實(shí)時(shí)反饋系統(tǒng)的異常，特別在實(shí)踐初期總會(huì)有意外情況，研發(fā)應(yīng)該能第一時(shí)間獲知系統(tǒng)發(fā)生異常。如果研發(fā)環(huán)境本身還是非常耦合，牽一發(fā)而動(dòng)全身的情況，需求的負(fù)責(zé)人都不知道影響范圍在哪里。那就很去難實(shí)現(xiàn)敏捷的交付方式。如果沒(méi)有準(zhǔn)確的異常監(jiān)控能力，會(huì)有很大的風(fēng)險(xiǎn)。因此合理的架構(gòu)是敏捷的基礎(chǔ)。

流程規(guī)范

然后是流程規(guī)范。從需求拆分、時(shí)間規(guī)劃、代碼分支管理、技術(shù)方案評(píng)審、測(cè)試報(bào)告、發(fā)布審核、自動(dòng)化回歸。團(tuán)隊(duì)中的每個(gè)人必須嚴(yán)格按照流程進(jìn)行，因?yàn)樵届`活的方案，背后意味著更多的不可控。所以在轉(zhuǎn)型初期，嚴(yán)格執(zhí)行流程是非常必要的。

敏捷交付的前提是需求必須是合理拆分的，而我們對(duì)合理的定義就是，可以獨(dú)立交付上線的稱為一個(gè)需求。如果兩個(gè)需求之間是相互耦合的，少了其中一個(gè)，另一個(gè)需求都不能獨(dú)立交付。那么這樣的需求就是不合理的，應(yīng)該合并為一個(gè)需求。

這個(gè)是互客某一個(gè)版本的需求列表，以及分工，時(shí)間規(guī)劃等等?？梢钥吹酱蟛糠质钦Ｐ枨?#xff0c;黃色部分是比較大的不跟版本的需求，紅色和劃線的是延期或取消的需求。需求的交付變成了一個(gè)靈活的過(guò)程。

這個(gè)是我們的需求分支管理，非常簡(jiǎn)單，每個(gè)需求開(kāi)始時(shí)從線上分支拉一個(gè)獨(dú)立的需求分支，當(dāng)需求環(huán)境提測(cè)通過(guò)后，合并到灰度分支，灰度驗(yàn)證后，再合并到線上分支發(fā)布上線。其中比較重要的是一定要經(jīng)常從master合最新代碼到自己的feature分支。

實(shí)施工具

工具是流程的承載，沒(méi)有合適的工具是很難把流程執(zhí)行起來(lái)的。網(wǎng)易內(nèi)部的ovemrind效能平臺(tái)可以很好的支持我們的流程，配合協(xié)作文檔，測(cè)試用例管理平臺(tái)和測(cè)試自動(dòng)化平臺(tái)，基本上可以比較好的支持整個(gè)流程了。下面的截圖是某一天下午的發(fā)布單，可以看到一下午就有多次發(fā)布。

團(tuán)隊(duì)組織

最后我們需要根據(jù)敏捷交付的邏輯去適當(dāng)?shù)恼{(diào)整團(tuán)隊(duì)的組織形式，原先的團(tuán)隊(duì)組織形式，邊界在于職能，所有的需求在不同的職能間流轉(zhuǎn)，最后由版本負(fù)責(zé)人負(fù)責(zé)交付上線。這種模式下，各職能團(tuán)隊(duì)的人只能接觸到自己工作范圍內(nèi)的東西，所以對(duì)需求的理解程度高低不等，當(dāng)產(chǎn)生需求變更時(shí)，也更容易產(chǎn)生抵觸情緒，當(dāng)出現(xiàn)調(diào)整或返工時(shí)也會(huì)付出很大的代價(jià)。

右邊是為了適應(yīng)敏捷交付調(diào)整的組織形式，每個(gè)需求都會(huì)有一個(gè)臨時(shí)的虛擬小組來(lái)負(fù)責(zé)，需求只在這個(gè)小組內(nèi)部流轉(zhuǎn)，最后由需求負(fù)責(zé)人交付上線。在這種模式下，團(tuán)隊(duì)組織的邊界不再是職能，而在于需求。虛擬小組的成員需要關(guān)心一個(gè)需求的全生命周期，能更好的理解需求。當(dāng)有需求變更時(shí)，影響范圍也相對(duì)小得多。并且通常會(huì)在方案設(shè)計(jì)過(guò)程中研發(fā)和產(chǎn)品一起討論調(diào)整需求。

不管是環(huán)境、流程還是工具，最后一定都是需要人去執(zhí)行的，也就是團(tuán)隊(duì)中的每個(gè)成員。因此團(tuán)隊(duì)成員的思維轉(zhuǎn)變是敏捷轉(zhuǎn)型中的重點(diǎn)，在工作進(jìn)行前，首先應(yīng)該在團(tuán)隊(duì)內(nèi)進(jìn)行足夠的溝通，讓每個(gè)人理解轉(zhuǎn)型的價(jià)值和意義，讓每個(gè)人都愿意為之努力。當(dāng)團(tuán)隊(duì)達(dá)成一致的目標(biāo)時(shí)，離成功就已經(jīng)不遠(yuǎn)了。

得到了什么

這是互客過(guò)去幾個(gè)版本的需求吞吐量，缺陷密度，不管質(zhì)量還是吞吐量都是有比較明顯的提升的。

當(dāng)然，我覺(jué)得更重要的是，我們得到了持續(xù)快速的交付價(jià)值的能力，得到了溝通順暢，相互信任的團(tuán)隊(duì)。另外從我個(gè)人做需求感覺(jué)來(lái)說(shuō)，在敏捷模式下，我對(duì)需求的理解會(huì)更好，工作會(huì)變的更聚焦，會(huì)自然而然的關(guān)注需求從評(píng)審到上線的整個(gè)過(guò)程，會(huì)及時(shí)的關(guān)注自己的需求的情況等等。比如有一個(gè)客戶的成單就是因?yàn)槲覀兩狭艘粋€(gè)數(shù)據(jù)看板的需求，需求的價(jià)值會(huì)直觀的反饋到了這個(gè)需求的負(fù)責(zé)團(tuán)隊(duì)，這可以讓產(chǎn)研統(tǒng)一目標(biāo)，相互促進(jìn)，產(chǎn)生良性循環(huán)。

經(jīng)驗(yàn)總結(jié)

在網(wǎng)易互客實(shí)踐敏捷交付的過(guò)程中我們踩了許多坑，并總結(jié)了一些經(jīng)驗(yàn)，希望可以幫助大家少走一點(diǎn)點(diǎn)彎路。

• 不要過(guò)分追求模式，我們的目標(biāo)是質(zhì)量和效率，而不是模式
• 溝通，充分的溝通，要達(dá)成理解一致
• 轉(zhuǎn)型初期流程要嚴(yán)格執(zhí)行
• 需求一定要有負(fù)責(zé)人
• 需求交付盡量不要合并操作，容易相互影響出錯(cuò)
• 對(duì)質(zhì)量負(fù)責(zé)的不是QA，是每個(gè)需求的小組
• 系統(tǒng)可觀測(cè)性很重要，研發(fā)團(tuán)隊(duì)需要掌握系統(tǒng)的實(shí)時(shí)狀態(tài)

最后期望所有的研發(fā)團(tuán)隊(duì)都能讓有限的資源產(chǎn)生最大的價(jià)值。

總結(jié)

以上是生活随笔為你收集整理的网易互客敏捷交付实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。