前言

筆者09年的時候在Sybase工作，那時候公司就在內(nèi)部開始推廣極限編程XP（ExtremeProgramming），當時是第一次聽說這個名詞當時公司也做了一個敏捷培訓，從培訓中了解到了在當時硅谷XP已經(jīng)大行其道，而且當時亞馬遜、微軟、IBM都已經(jīng)實施了XP，Sybase美國總部也已經(jīng)用XP在軟件開發(fā)方面實施了一年多，反響都是很好的，XP其實和現(xiàn)在的Scrum、Kanban的核心思想其實是一樣的，但是XP更傾向于軟件開發(fā)，Scrum和Kanban更聚焦在項目管理的全流程。當時的Sybase美國總部那邊很多項目都已經(jīng)做到了敏捷需求管理、TDD、CI和小迭代發(fā)布版本，當時親眼看到這樣的全自動的持續(xù)集成和快速迭代版本發(fā)布還是很驚訝的，一對比當時國內(nèi)的軟件公司，簡直就是天與地的差別，后來去了傳統(tǒng)銀行從事了6年開發(fā)也印證了當時的看法。后來所在的銀行也順應(yīng)潮流實施了敏捷，后來還去了互聯(lián)網(wǎng)公司也實施了敏捷，本篇文章就講述下當年在傳統(tǒng)銀行實施敏捷開發(fā)和項目管理方面的一些感想和實踐經(jīng)驗。因為全程參與了傳統(tǒng)銀行的IT項目的敏捷改造，并且傳統(tǒng)銀行的IT項目也比較有代表性，基本代表了目前主流的傳統(tǒng)IT項目，改造的實施過程對于其它傳統(tǒng)IT項目也有一定的參考性。

1.什么是Scrum

Scrum 是一個用于開發(fā)和維護復(fù)雜產(chǎn)品的框架 ，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog。在每個迭代結(jié)束時，Scrum團隊將遞交潛在可交付的產(chǎn)品增量。 Scrum起源于軟件開發(fā)項目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項目。

scrum流程

SCRUM框架包括3個角色、3個工件、5個事件、5個價值

3個角色

1. 產(chǎn)品負責人（Product Owner）
2. Scrum Master
3. 開發(fā)團隊

3個工件

1. 產(chǎn)品Backlog
2. SprintBacklog
3. 產(chǎn)品增量

5個事件

1. Sprint（Sprint本身是一個事件，包括了如下4個事件）
2. Sprint計劃會議（Sprint Planning Meeting）
3. 每日站會（Daily Scrum Meeting）
4. Sprint評審會議（Sprint Review Meeting）
5. Sprint回顧會議（Sprint Retrospective Meeting）

5個價值

1. 承諾 – 愿意對目標做出承諾
2. 專注– 把你的心思和能力都用到你承諾的工作上去
3. 開放– Scrum 把項目中的一切開放給每個人看
4. 尊重– 每個人都有他獨特的背景和經(jīng)驗
5. 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重

這里我就不詳細描述scrum的這些關(guān)鍵要素了，只是給大家羅列了下，相信看這篇文章的同學多少對敏捷還是有一定了解的，如果不了的同學可以網(wǎng)上搜搜就知道了。

2.傳統(tǒng)銀行IT項目管理流程

在傳統(tǒng)銀行工作了6年，對于傳統(tǒng)銀行的IT項目管理流程也是比較熟悉的，下面先說下傳統(tǒng)IT項目的流程，基本都是這個套路：

• 傳統(tǒng)IT項目一般的流程都是業(yè)務(wù)經(jīng)理搜集了客戶的需求，將這些客戶的共性需求整理成了粗糙的項目需求條目‘
• 業(yè)務(wù)產(chǎn)品經(jīng)理接收到這些零散的需求條目后，會將這些需求條目進行整理，整理成比較規(guī)范的PRD需求文檔;
• 業(yè)務(wù)產(chǎn)品經(jīng)理會將需求拿去進行需求評審；
• 需求評審?fù)ㄟ^后，科技部門的架構(gòu)師會收到通過需求評審的需求，進行技術(shù)方案制定；
• 架構(gòu)師制定好技術(shù)方案后，拉著各個關(guān)聯(lián)產(chǎn)品進行方案評審；
• 在方案評審?fù)ㄟ^后，項目經(jīng)理會制定項目計劃，并制定項目預(yù)算表等等；
• 分別進行項目計劃評審和項目預(yù)算評審；
• 這些項目類評審都做完后，項目經(jīng)理會和相關(guān)產(chǎn)品一起進行項目排期；
• 制定好實施排期計劃后，項目經(jīng)理才會安排開發(fā)項目組進行項目開發(fā)工作；
• 開發(fā)項目組開發(fā)完成后，接下來會進入SIT測試，SIT測試完成后會進入UAT測試，UAT測試完成后會發(fā)布生產(chǎn)版本；
• 運維人員拿到生產(chǎn)版本后會在約定的批次投產(chǎn)時間進行投產(chǎn)工作；

這個流程看著每個評審寫的都很簡單，經(jīng)歷過傳統(tǒng)項目評審的應(yīng)該都知道，這個評審的過程一般是比較耗時的，雖然說整個流程中一般不會有什么實質(zhì)性的阻攔或者問題，但是就是會在各個環(huán)節(jié)耽擱很多時間，導致一個需求要經(jīng)過三個月左右才能真正進入開發(fā)階段，最后投產(chǎn)還需要運維人員進行版本部署。可見這個流程全部走下來是非常艱難的，需要耗費非常多的時間用戶才能看到我們的新功能，就算是比較小的需求基本也是要等到半年后才能與用戶見面，那時候可能用戶已經(jīng)找到了替代方案或者根本不需要這個功能了。

3.敏捷迭代開發(fā)在互聯(lián)網(wǎng)公司的應(yīng)用

敏捷開發(fā)是這幾年炒的非常熱的一個概念，國內(nèi)基本上是在2010年開始，在各個互聯(lián)網(wǎng)公司開始普及敏捷開發(fā)，主流的敏捷開發(fā)模型就是Scrum、Kanban，Kanban和Scrum對比起來沒有本質(zhì)上的區(qū)別，也不用在意這兩個的區(qū)別細點到底是什么，因為我待過的3家公司都實施過敏捷但是每家都是變種，都按照自己公司的情況和項目的情況進行過調(diào)整，沒有一家是完全按照模型去實施的。

2016年的時候我所在的一家互聯(lián)網(wǎng)電商公司內(nèi)部也在推廣敏捷，但是實施方式上和之前在傳統(tǒng)銀行實施的敏捷開發(fā)也有比較大的區(qū)別，下面我介紹下當年所在的互聯(lián)網(wǎng)公司的敏捷是如何實施的。我們都知道敏捷開發(fā)的核心理念是擁抱變化，互聯(lián)網(wǎng)項目的最大特點就是變化快，每個項目都是需要在很短的時間內(nèi)完成，為了在互聯(lián)網(wǎng)的世界存活下來只有快，要經(jīng)快上線才能獲得市場的認可，最近比較火的吃雞游戲，騰訊游戲300人的團隊采用3班倒的方式進行開發(fā)，人停代碼不停，這讓我想到了富士康。。。人停機器不停，倒班制居然出現(xiàn)在了互聯(lián)網(wǎng)科技公司，這也從側(cè)面說明了必須要快速、擁抱變化才能贏得勝利。

下表是我們迭代中幾個關(guān)鍵的時間點：

下面按時間軸來說明下我們每輪迭代每天的工作，我們迭代是以兩周為一個迭代，共計10個工作日，下面我就描述一個需求經(jīng)過的全過程（迭代1-1表示迭代1第一天，迭代1-2表示迭代1第二天以此類推）

迭代1－1至迭代1-7:開發(fā)人員進行本輪迭代開發(fā)工作；

迭代1-5:PMO、產(chǎn)品經(jīng)理、產(chǎn)品開發(fā)負責人召開下輪迭代預(yù)排期會，這個預(yù)排期主要是根據(jù)本輪開發(fā)的情況，評估下輪迭代可以排入迭代進行開發(fā)，這個時候開發(fā)負責人需要首先評估下輪迭代有幾個人力可以使用，還需要參考產(chǎn)品經(jīng)理當前接到的所有需求，進行評估哪些可以排入下輪迭代進行開發(fā)，這里的評估是非常考驗開發(fā)負責人的經(jīng)驗，需要負責人對自己的手下足夠了解，并且一般要預(yù)留20%－30%的人力作為儲備，用于處理緊急需求和一些緊急的bug，互聯(lián)網(wǎng)公司的緊急需求是非常多的，所以一定不要相信產(chǎn)品經(jīng)理說需求就這么多了。。。

迭代1-7:迭代第二周周二是下輪迭代的正式排期，這個排期會有所有提需求的產(chǎn)品經(jīng)理和開發(fā)負責人、測試負責人、所有PMO參加，這個會議每次參加都像菜市場一樣，各種爭吵，親眼見到有產(chǎn)品妹子被開發(fā)負責人罵哭，每次的場景都是非常壯觀的，現(xiàn)場也非常的混亂。大家互相討價還價，你能做了還要看其它產(chǎn)品能不能做，這還是非常考驗產(chǎn)品經(jīng)理協(xié)調(diào)能力的，牛的產(chǎn)品經(jīng)理基本都可以把其它產(chǎn)品經(jīng)理的需求擋下去，讓自己的需求排進開發(fā)計劃；

迭代1-7:同時迭代第二周周二還有一個非常重要的任務(wù)就是提交SIT版本給測試團隊，這個是迭代中非常重要的一個里程碑時間點，這個時間點如果不能按時提交測試版本，那么就意味著縮短了測試的時間，意味著產(chǎn)品測試可能不充分，上線后存在bug的風險就會提高；

迭代1-10:迭代第二周周五下午一般本輪迭代的開發(fā)任務(wù)和bug修改也都完成了，可以召開下本輪迭代的總結(jié)會，讓大家把遇到的問題提出來，負責人后續(xù)可以去改進，來不斷幫助大家提高開發(fā)效率；

迭代2-4:迭代2第一周的周四，是我們公司的版本發(fā)布日，當天晚上運維會進行版本部署和APP上架，公司已經(jīng)實現(xiàn)了半自動的devops，3個人完成70多個系統(tǒng)的生產(chǎn)日常運維版本部署，當時覺得這方面做的還是很完善的，完全釋放了運維人員的工作，同時也減少了人為出錯的可能性；

整個迭代還是比較緊湊的，工作的節(jié)奏非常快，當時我作為門戶移動端的負責人，每天都非常忙，被各種評審和組內(nèi)日常管理牽制了太多精力，和各個產(chǎn)品協(xié)調(diào)也是一件非常累的事情。這個流程整個公司所有項目都是這么運作，所以總流程還是比較順利的，但是各個產(chǎn)品的bug都是挺多的，后來我們在一起回顧bug多的原因的時候發(fā)現(xiàn)主要有以下幾點：

• 需求變化比較頻繁
• 缺少充分的回歸測試
• 跨系統(tǒng)架構(gòu)方案設(shè)計常常考慮不完善

這幾個問題，也是在敏捷迭代中比較常見的問題，需求變化頻繁這個問題，我相信在任何一家互聯(lián)網(wǎng)公司都存在需求變化頻繁的問題，這個問題用Scrum官方解釋的解決辦法就是將在迭代中提的需求放到product backlog中，排到下輪迭代中開發(fā)，但是在實際中，所有的產(chǎn)品經(jīng)理都會要求就放在這個迭代完成，這就產(chǎn)生了需求和開發(fā)的矛盾，一般來說都是按照老板要求開發(fā)加班把需求完成，目前我是沒找到太好的辦法。

缺少充分的回歸測試，這個問題對于國內(nèi)大型互聯(lián)網(wǎng)公司目前基本都沒這個問題了，都已經(jīng)實現(xiàn)了高自動化的CI，每完成一個功能代碼提交到git后就會自動觸發(fā)CI，完成靜態(tài)代碼復(fù)查、單元測試、版本構(gòu)建、版本部署、功能自動化回歸等功能。而且這些過程往往都在很短的時間完成，開發(fā)人員馬上就可以知道自己提交的代碼是否有問題，是否影響到了其它代碼，這是非常好的一種體驗。但是這個對于很多小公司來說是很難實現(xiàn)這樣的自動化CI的，我們當時其實規(guī)模也不算小，但是在整個CI的搭建是完成了，并且完成了大部分的步驟，除了單元測試和功能自動化測試，其它都已經(jīng)完成了，但是就是因為少了這兩步，導致整個CI過程是不完整的，這個CI流程從運維人員角度看，可能是已經(jīng)完成全部的自動化了，但是從開發(fā)人員和測試人員的角度來看，都缺少了關(guān)鍵的環(huán)節(jié)回歸測試。單元測試是針對開發(fā)人員的回歸測試，國內(nèi)的程序員基本沒幾個有單元測試習慣，大部分都是寫完代碼，run一下自己用接口工具或者和功能測試人員一樣點兩下就完成了所謂的內(nèi)部測試，之前在sybase的時候，發(fā)現(xiàn)老外的單元測試代碼量是超過源碼量的，當時不能理解為什么開發(fā)要寫那么多的單測代碼，后來看了他們的單測代碼才知道，單測代碼是針對代碼邏輯分支都編寫了不同的案例，所以源碼寫了一個if else就針對了至少兩條unit test case，這樣自然就比源碼多了。目前國內(nèi)的開發(fā)迭代任務(wù)都沒有考慮單測的時間，都是滿打滿算開發(fā)新功能產(chǎn)能，所以產(chǎn)生了一個惡性循環(huán)，要讓開發(fā)人員養(yǎng)成編寫單測的習慣，一方面是要求開發(fā)人員提高意識和能力，另一方面也要求產(chǎn)品經(jīng)理能夠控制迭代需求的節(jié)奏。還有一塊是功能自動化測試，這個對于目前國內(nèi)的測試人員要求是有點高了，目前國內(nèi)的大部分測試都還停留在手工測試階段，一些大的互聯(lián)網(wǎng)公司已經(jīng)完成了高度自動化的功能測試，一旦有了單元測試和功能自動化測試的保駕護航，開發(fā)人員對于自己寫的代碼也比較有信心，代碼也能做到每次提交后CI跑完就是可部署可執(zhí)行的產(chǎn)品。

最后一個比較常見的問題就是跨系統(tǒng)架構(gòu)設(shè)計考慮不完善，這個問題之前很多人都將這個問題的根因歸類到敏捷開發(fā)沒有做總體設(shè)計和詳細設(shè)計導致了該問題，但個人覺得這不是主要原因，主要原因還是公司架構(gòu)師的能力問題，如果一幫對自己系統(tǒng)都不是很了解的人做架構(gòu)師，然后一群不懂的架構(gòu)師坐在一起討論架構(gòu)方案，那出來的方案必定存在各種漏洞，所以解決這個問題最好的辦法就是，各個產(chǎn)品的架構(gòu)師最好不是空降，而是從自己的開發(fā)團隊中選出對系統(tǒng)最熟悉的人去擔任這個角色。

總的來說在互聯(lián)網(wǎng)公司實施敏捷的感受還是很帶感的，痛并快樂著。

4.傳統(tǒng)銀行使用敏捷遇到的問題和實踐經(jīng)驗

上面大概介紹了下我當時在互聯(lián)網(wǎng)公司實施敏捷的一些經(jīng)驗，下面再說下前幾年在傳統(tǒng)銀行實施敏捷遇到的問題，這個可能對更多要試試敏捷的公司有參考價值，我們是在13年開始在行內(nèi)開始敏捷試點的，當時也是找了敏捷咨詢和敏捷教練來帶我們實施敏捷轉(zhuǎn)型，下面我就羅列下期間遇到的各種問題。

• 用戶故事的拆解粒度問題

用戶故事拆解的粒度這個問題其實是剛解除敏捷的時候絕大部分同學都會提的疑問，這個問題就好像是在問微服務(wù)，一個服務(wù)應(yīng)該定義成多大？這個問題每個敏捷教練的答案可能都是不一樣的，用戶故事從我這些年拆分的經(jīng)驗來看，這個問題的回答可以簡單總結(jié)為只要拆到團隊一個開發(fā)人員平均可以在1-2天內(nèi)完成的工作內(nèi)容，這句話聽起來簡單，其實這對一個PO的要求是非常高的，需要PO對團隊內(nèi)每個開發(fā)人員的戰(zhàn)斗力、當前工作負荷、需求的理解都要非常熟悉。因為用戶故事的粒度這是一個很抽象的問題，很難用定量的指標進行描述，這里為了方便大家實踐和執(zhí)行所以定了1-2天工作量這樣的指標，其實在真正實施過程中，只要PO不定義那種史詩故事直接放到sprint中就可以了。當你拆解故事多了以后就能找到那種感覺了，還是需要大家多實踐，一開始可能似懂非懂，經(jīng)過幾個迭代就會漸漸找到拆分用戶故事的感覺了。

• 用戶故事工作量評估問題

用戶故事工作量的評估是個比較耗時的過程，按照Scrum的敏捷過程規(guī)范來說應(yīng)該是先定義一個基準故事，基準故事一般選擇比較簡單又具有代表性的故事，可以讓每個組員一看就知道大概這個基準故事需要花費多久時間，這樣就可以讓組員了解用戶故事和故事點之間的比例關(guān)系，例如我們定義了一個基準故事-修改用戶信息（1個故事點），修改用戶信息這個基準故事我們定義了一個故事點，這個故事很簡單也很有代表性每個組員一看就知道這個任務(wù)大概需要花費多長時間才能開發(fā)完，所以再用這個故事和其他待評估的故事一對比，自己心里就知道這個待評估故事大概需要多少個故事點，這樣就把每個人的評估基準給拉平了。如果按照傳統(tǒng)敏捷教練教的故事評估方法，一定是組內(nèi)每個人都對一個故事進行故事點評估，評估完了之后再一起拿出評估結(jié)果給大家看誰的評估故事點多了，誰評估少了，并讓故事點評估最高和最低的同學說下評估理由，這樣可以讓所有人了解到每個人對這個故事的理解，評估低的同學可能是沒考慮到這個故事一些深層的工作，評估高的同學可能會發(fā)現(xiàn)自己考慮復(fù)雜了，其他同學聽了以后也會根據(jù)其他人的討論重新進行評估，討論過后需要每個人再重新評估，一直這樣評估討論評估討論，直到評估結(jié)果大家都非常相近的時候，去掉最大值，最小值取平均值作為該故事的故事點。我印象很深刻，第一次在教練的帶領(lǐng)下進行評估的時候，一個迭代的故事，我們一個組的人居然評估了一天。。。為什么評估那么長時間，一方面是大家第一次進行評估，還有一個主要的原因是大家評估的結(jié)果每次都有比較大的差異，當時教練的說法是第一次會比較慢，后面會越來越快，但是我這樣做了好幾個迭代后，發(fā)現(xiàn)雖然是比第一次快了很多，但是還是比較耗時的，尤其是團隊中開發(fā)人員能力層次不齊的時候，這種狀況出現(xiàn)的頻率更高。因為我們團隊當時大部分同學都是外包公司的程序員，人員初級、中級、高級都有，能力也相差比較大，評估的結(jié)果也相差比較大，所以后來我干脆不用教練教的那種方法了，我按照我對開發(fā)人員的了解，用專家評估法進行評估，雖然這樣評估會有很大的片面性，也可能對需求考慮的不全面，但是這樣能夠極大的縮短評估時間，我評估好了之后，會讓所有組員去看評估的結(jié)果是否有問題，讓每個人也能夠有個確認的過程。后來在互聯(lián)網(wǎng)公司發(fā)現(xiàn)，組內(nèi)人員的開發(fā)能力都比較強，大家評估的準確度也比較高，所以當時也對故事評估過程進行了修改，直接任務(wù)認領(lǐng)后，讓每個開發(fā)人員自己進行評估，他們評估好后，我去復(fù)評估，這樣可以解放PO的評估工作，但是也都有了工作量的確認過程。從兩個團隊的評估經(jīng)驗，我也體會到了敏捷中所有的過程和方法都是可以修改的，不要教條主義，一定要根據(jù)敏捷團隊當前的實際情況來調(diào)整。

• 用戶故事認領(lǐng)工作分配不合理問題

用戶故事評估過后，按照標準的敏捷實施過程應(yīng)該是，所有組員根據(jù)自己擅長的技能去認領(lǐng)故事的過程，一開始我也是按照這樣的流程讓大家自主去認領(lǐng)，但是發(fā)現(xiàn)總會存在一些不是特別主動的同學每次認領(lǐng)的任務(wù)都是比較少的，這就導致了組內(nèi)每個人工作分配的不平均，長期下來就會導致其他正常工作的同學心理存在不平衡，會影響到團隊的和諧。所以我后來的做法是在每次認領(lǐng)后會根據(jù)每個人領(lǐng)取的故事點情況，再進行一次平衡，由PO來主動調(diào)整，這樣可以起到一個再平衡的作用，也能維持好團隊的氛圍。

• 迭代小組人員過多問題，導致每次晨會發(fā)言時間很長

我們一開始迭代小組內(nèi)大約有8個人，除了PO還有7名同學，3名andorid開發(fā)、4名ios開發(fā)，其中一名ios開發(fā)兼SM。這樣的人員配置開晨會的時候每個人說下自己的工作情況和問題就已經(jīng)會花費比較多的時間了，基本上要20分鐘才能搞完，后來隨著項目組的逐漸龐大，人員也越來越多，最多的時候有22人，這么多人開晨會場景是非常壯觀的，遇到幾個比較大的問題，一個是人太多，Scrum看板前面站不了那么多人，基本上都是圍了2-3排，后排的同學基本每次晨會都沒有什么參與感，而且每次會議的時間都超過了半小時，浪費了大家很多時間，所以后來為了提高效率，我按照功能模塊拆成了3組，每個組都分配了SM，分別由每個SM單獨去組織晨會，每個組單獨維護看板和燃盡圖。每個組的開會時間都是岔開的，這樣PO就可以去參加每個組的會議，了解到所有組的進展，并能能夠在各組之間協(xié)調(diào)工作。

• 迭代文檔缺失問題

原來我們的傳統(tǒng)項目使用的工程模型是瀑布式的或者螺旋式，這些項目開發(fā)工程模型，基本每個階段都是比較清晰的，需求分析、總體設(shè)計、詳細設(shè)計、開發(fā)、sit、uat、投產(chǎn)，在項目計劃中有明確的需求分析、總體設(shè)計、詳細設(shè)計的開發(fā)時間節(jié)點，所以每個階段的輸入輸出文檔都是比較明確的，但是使用了Scrum后，會發(fā)現(xiàn)，其中很多環(huán)節(jié)表面上看都確實了，例如需求分析階段、總體設(shè)計、詳細設(shè)計好像都沒有，好像是PO開完迭代計劃會議，分好故事大家就開始進入迭代開發(fā)了，感覺少了很多分析設(shè)計的環(huán)節(jié)，這就導致了之前各個環(huán)節(jié)的文檔，都統(tǒng)統(tǒng)不見了，沒人寫了。這個其實是對敏捷非常錯誤的理解，經(jīng)過幾輪迭代后，發(fā)現(xiàn)文檔缺失的后果非常嚴重，引出了很多問題，當人員存在流動的時候，交接工作基本就是對著代碼說，接手的人基本都是講的時候一臉懵逼；查問題的時候也沒法查看交易流程，只能看代碼分析；在評審的時候因為沒有問題，所以評審專家也沒辦法評估到底有沒有問題。所以經(jīng)過幾個這樣混沌的迭代后我們立馬意識到存在的問題，需求分析文檔，其實就是我們的用戶故事，PO在編寫用戶故事的時候其實已經(jīng)做了需求分析，并且將故事需要實施的內(nèi)容進行了詳細的描述，讓開發(fā)人員看到故事就能夠了解這個故事到底要實現(xiàn)什么功能，如果不理解，PO也可以聯(lián)系PO繼續(xù)講解故事。總體設(shè)計文檔，我們后來體現(xiàn)在了每個task的文檔中，我們要求開發(fā)人員對每個task都要進行交易時序圖、數(shù)據(jù)結(jié)構(gòu)、接口的編寫，這樣就保證了每個task都是有總體設(shè)計的，去掉了原先總體設(shè)計文檔中一些比較虛的內(nèi)容，只保留了最有價值的內(nèi)容。詳細設(shè)計文檔，詳細設(shè)計文檔我們在整個過程中用代碼注釋進行了替代，我們要求所有開發(fā)人員遵循公司的編碼規(guī)范，變量、函數(shù)、類命名都有了規(guī)范，并且在每個關(guān)鍵步驟都編寫注釋，通過注釋來替代原先的詳細設(shè)計文檔。經(jīng)過這些改革，我們發(fā)現(xiàn)分析設(shè)計的精髓還是留下來了，同時也去掉了原先文檔中一些比較繁瑣沒用的內(nèi)容，做到了最簡化。

• 迭代質(zhì)量保證

Scrum有個比較關(guān)鍵的思想是每次迭代結(jié)束后，產(chǎn)品都是可發(fā)布的，可發(fā)布意味著什么，意味著產(chǎn)品的質(zhì)量是經(jīng)過嚴格考驗的，我們原先瀑布式開發(fā)是有專門的sit、uat階段的，如果跳過這兩個階段就發(fā)布產(chǎn)品，這對一個銀行來說顯然是不可能的，起碼目前來說是不可能的，可能未來幾年后銀行it也會像互聯(lián)網(wǎng)公司一樣，做到2周甚至1周就發(fā)布一個版本，這樣的快速迭代。在不可能改革現(xiàn)有流程的前提下，我們又對Scrum流程進行了改造，我們的敏捷迭代只涵蓋了開發(fā)需求分析分析、設(shè)計和開發(fā)階段，對于測試和運維還是和原來一樣獨立由測試中心和數(shù)據(jù)中心來實施，因為對于一家傳統(tǒng)國有大型銀行，讓所有環(huán)節(jié)都陪著我們瘋顯然是不太現(xiàn)實的，幾年后可能其他中心的領(lǐng)導會慢慢接受真正的全流程敏捷，這樣笨重的銀行也能夠和互聯(lián)網(wǎng)產(chǎn)品一樣跑起來。

• 迭代排期和傳統(tǒng)項目產(chǎn)品排期協(xié)調(diào)問題

上面說了我們只是在需求、設(shè)計和開發(fā)環(huán)節(jié)敏捷了，其他環(huán)節(jié)還沒有敏捷，這是個不徹底的敏捷，其實在我們開發(fā)中心內(nèi)部也存在不敏捷的項目，例如核心系統(tǒng)和一些比較重要的外圍系統(tǒng)都還是傳統(tǒng)的實施方式，每年拍5-6個大的版本發(fā)布時間點，然后排期實施，但是我們敏捷項目是每個月都會發(fā)布一次版本，這就使得我們的節(jié)奏和其他傳統(tǒng)系統(tǒng)是不一致的，如果我們的產(chǎn)品涉及到需要核心系統(tǒng)改造，可能我們最后的上線時間是一樣的，但是有個問題是，我們迭代一結(jié)束了，核心系統(tǒng)的開發(fā)團隊才需求分析結(jié)束，我們迭代二結(jié)束了，核心團隊才總體設(shè)計技術(shù)，最后我們前幾個迭代都是在我們假想的核心接口中開發(fā)完成的，這勢必會存在一個嚴重的問題就是，核心系統(tǒng)總體設(shè)計結(jié)束后肯定和我們開始假象的核心會提供的接口存在出入，需要我們敏捷團隊重新返工，而且我們一直到核心開發(fā)完后才能進行接口聯(lián)調(diào)，在核心系統(tǒng)接口開發(fā)完之前可能我們都是用自己的擋板進行的開發(fā)和測試，用過擋板的應(yīng)該都知道擋板功能的單一，這就導致核心系統(tǒng)開發(fā)完和我們敏捷產(chǎn)品集成測試的時候，我們暴露出一堆問題，因為前期的迭代都是我們自己玩，人家核心系統(tǒng)根本沒陪你測過，所以這個問題就是由于相關(guān)聯(lián)產(chǎn)品開發(fā)周期不同步導致的問題。因為沒辦法要求核心系統(tǒng)也在短時間內(nèi)陪著我們改成敏捷開發(fā)模式，畢竟銀行的核心系統(tǒng)還是要以穩(wěn)定為主，后來就改成了所有敏捷產(chǎn)品的需求都在核心系統(tǒng)產(chǎn)品進入測試階段或者上線后才可以排期實施，這就解決了周期不同步的問題，但這也使得敏捷產(chǎn)品發(fā)布時間的延遲，只要涉及到核心系統(tǒng)的需求就變的不敏捷了。

• APP組迭代和服務(wù)端迭代、UI設(shè)計配合問題

因為我一直是負責APP開發(fā)的，所以對APP開發(fā)的流程還是比較了解的，我們做APP開發(fā)不像服務(wù)端開發(fā)，上來只要有接口文檔就可以開發(fā)，我們依賴很多東西，首先UI設(shè)計師要出圖，并且將切圖給到APP開發(fā)的同學，界面做好后還需要服務(wù)端的同學提供接口進行開發(fā)測試。APP開發(fā)在迭代中依賴的東西比較多，我們在剛開始轉(zhuǎn)敏捷迭代開發(fā)模式的時候發(fā)現(xiàn)每次迭代一開始，APP開發(fā)人員都是最閑的，沒事做，因為啥都沒有，要圖沒圖，要接口沒接口，后來我們參考了其他互聯(lián)網(wǎng)公司的做法，將UI設(shè)計和服務(wù)端接口開發(fā)提前一個迭代實施，這樣APP開發(fā)人員一到迭代就可以全身心投入開發(fā)。但是會有同學問了，我們經(jīng)常會遇到一些項目是要求app端和服務(wù)端同步實施的，而且要求的上線時間比較緊，如果app開發(fā)慢了一個迭代那肯定是趕不上發(fā)布的，面對這種情況，我在app組內(nèi)是要求所有前端開發(fā)人員都使用mock和mock server來模擬服務(wù)端接口，這樣我們前端就有了很大的自主權(quán)，不用完全依賴于后來同學開發(fā)完才能實施。

• 持續(xù)集成

經(jīng)常有人問我“敏捷迭代中什么最重要？”，在我看來敏捷迭代中持續(xù)集成最重要，這個回答可能很多人不能理解。其實我們換個角度來思考就很容易理解，我們做軟件開發(fā)為什么要使用敏捷迭代開發(fā)模型，因為敏捷迭代模型能夠讓每個人專注在開發(fā)用戶故事，充分調(diào)用開發(fā)人員的主觀能動性，讓任務(wù)能夠在最短的時間完成并上線，但是我們功能兩周后上線了，這并不意味著我們?nèi)蝿?wù)完成了，我們還要去看這個功能完成的存不存在bug，如果上去后全是問題，自然只是一個不合格的敏捷迭代，如果功能上線快了，但是線上都是問題，這也必將引起領(lǐng)導的不滿，最后的效果可能還不如用傳統(tǒng)的瀑布模型慢慢的實施，保證沒有問題。所以在敏捷開發(fā)中不是說我們不考慮質(zhì)量了，我們要通過更加先進的方式來保證在每次修改后產(chǎn)品都是可運行的，不存在問題的。這就是為什么我認為持續(xù)集成是敏捷中最重要的內(nèi)容，如果沒有持續(xù)集成來保證迭代開發(fā)的每次代碼提交，那么這個迭代的每次代碼提交都是充滿危險和恐懼的，因為迭代周期一般都比較短，如果是兩周一個迭代基本就是第二周周二左右就要提交測試版本給測試人員進行迭代內(nèi)測試，不然質(zhì)量是沒法保證的，如果沒有持續(xù)集成，所有開發(fā)人員可能在提交給測試人員之前對自己的產(chǎn)品是沒有信心的，可能覺得自己的產(chǎn)品可能充斥著bug。但是如果我們實施了持續(xù)集成，不管什么時候我們交付給測試人員的時候我們都是自信的，因為我們提交的代碼起碼是經(jīng)過持續(xù)集成檢測的，經(jīng)過了靜態(tài)代碼復(fù)查、單元測試、構(gòu)建和自動化功能測試這么多持續(xù)集成階段，自然有這份自信。所以如果你發(fā)現(xiàn)你的敏捷迭代過程中沒有持續(xù)集成，那么你的敏捷迭代可能是個假把式，只是樣子貨，模仿了Scrum的樣子，但是沒有靈魂。

• 跨迭代任務(wù)問題

我們在迭代的過程中還遇到過一類比較頭疼的問題就是跨迭代故事，按照理論來說在Scrum中不應(yīng)該存在跨迭代的用戶故事，用戶故事都應(yīng)該是在一個迭代中完成的，如果一個迭代都完成不了，那么就要對故事進行拆分。我個人覺得這是一種比較理想的狀態(tài)，實際實施過程中始終會存在一些大型的用戶故事，雖然可以進行拆分，但是你會發(fā)現(xiàn)拆分后，這些故事也是沒辦法在一個迭代中完成，這就存在跨迭代的問題，一旦跨迭代后，這就要求我們開發(fā)人員將本輪迭代不發(fā)布的功能，要在打包的時候?qū)⒋a注釋或者在本地不要提交到當輪迭代開發(fā)分支上，這樣操作后就會存在人為的一些失誤，從而導致版本混亂。當時出現(xiàn)這樣的問題后，傳統(tǒng)的解決辦法是拉多個開發(fā)分支，但是我們知道一旦分支多了以后，對于開發(fā)人員就可能更加容易犯錯，所以我采取的策略是開發(fā)人員只在自己本地的git拉個new feature分支提交跨迭代的功能代碼，這樣每個有跨迭代任務(wù)的同學對自己本地的分支是非常了解的因為他一直專注在這部分功能的開發(fā)，能夠最好的管理好這些跨迭代的代碼。這樣做的缺點就是一旦開發(fā)人員的電腦如果壞了或者出問題后可能存在這部分個人代碼丟失的風險，不過現(xiàn)在電腦沒那么容易壞了，如果有企業(yè)nas，也可以定期備份每個人硬盤的內(nèi)容來保證內(nèi)容不丟失。

• 版本分支問題

敏捷迭代中的版本分支其實和傳統(tǒng)瀑布開發(fā)的版本分支策略沒有本質(zhì)的區(qū)別，關(guān)鍵還是看實施過程中是否存在大量的跨迭代任務(wù)，如果存在比較多的跨迭代任務(wù)，我們可以為重疊的幾個迭代任務(wù)單拉分支，如果只存在比較少的跨迭代任務(wù)那么可以采用上面的方案，這樣更加輕量級，這樣也更加符合快速的迭代，開發(fā)人員不會有太多的代碼merge工作，也減少了出錯的可能性。我理想的敏捷迭代版本分支是一條master分支，用于記錄發(fā)布的版本，一條dev分支，用于記錄迭代開發(fā)的內(nèi)容，版本發(fā)布后將代碼merge到master分支，其他問題都在個人local git解決。但是了解instagram的同學應(yīng)該知道，instagram那么多的功能，那么快速的迭代，他們只有一個master分支，可以做到代碼一提交經(jīng)過持續(xù)集成后就發(fā)布生產(chǎn)，想想這要求開發(fā)人員和老板得有多大的心才敢這樣啊！

• 版本發(fā)布周期問題

敏捷迭代目前用的比較多的迭代周期一般是2周，也有部分特別快速的互聯(lián)網(wǎng)公司做到了一周一個迭代版本發(fā)布，我們當時做過一個實驗，一開始我們采用4周一個迭代，在實施4周一個迭代前我們居然感覺4周相對于原來瀑布式開發(fā)流程3個月一個版本簡直太短了，后來我們真正實施的時候發(fā)現(xiàn)4周我們也可以完成原來3個月的工作。。。可見原來我們的工作效率有多么的低，后來我發(fā)現(xiàn)在4周的迭代中前兩周大家工作進展都比較慢，后來我把縮短到2周一個迭代，一開始大家都很抵觸，覺得2周發(fā)布不了版本，不可能有獨立可發(fā)布的版本上線，后來實踐下來在做到很好的故事拆分后，每個迭代分配的任務(wù)都是可獨立上線的，大家也都在2周內(nèi)完成了工作，所以用了敏捷后你會發(fā)現(xiàn)原來我們有那么大的潛力。

總結(jié)

敏捷的形式是很好模仿和學習的，估計培訓一周所有人都能說個頭頭是道，但是在具體實施過程中會遇到各種問題，一方面的問題是由于公司原流程和敏捷迭代流程的沖突，另一方面是開發(fā)人員對敏捷開發(fā)的適應(yīng)性，還有一方面就是敏捷迭代的質(zhì)量保證。第三點我覺得是我非常重視的一點，不能說用了敏捷，項目的bug率就可以提高，項目的文檔就可以缺失，項目的需求就可以隨便加，所以總的來說整個實施的過程中最難的就是如何保障項目的質(zhì)量，直白點就是如何來通過完善的持續(xù)集成來保證代碼的質(zhì)量是充分可用的。后面我會寫一些文章來介紹如何實施持續(xù)集成，目前還是有很多公司不知道該如何實施，如何實施效果最好，我會在后續(xù)的文章一一介紹。