敏捷開發(fā)已在公司內(nèi)部推行了有四五個月了，開始檢查各個團(tuán)隊(duì)實(shí)行敏捷開發(fā)之后的效果，以檢查團(tuán)隊(duì)是否真的敏捷了。按說這是好事，引入一種新的開發(fā)模式，是要定期檢查一下，以便使這種新的模式能夠按照正常的軌道來走，而不至于跑偏了。但現(xiàn)實(shí)情況往往是很多的，評估小組就真的能領(lǐng)會到敏捷的精神么？

通過一段時間的敏捷開發(fā)執(zhí)行，確實(shí)發(fā)現(xiàn)了其好的地方，對于互聯(lián)網(wǎng)這種需求變化非常頻繁的行業(yè)，敏捷開發(fā)確實(shí)比較合適，能更好的適應(yīng)需求的變化，更快的完成項(xiàng)目的開發(fā)和測試進(jìn)度。內(nèi)部也樹立了幾個敏捷開發(fā)的標(biāo)桿團(tuán)隊(duì)，供大家模仿參考，但我之前也說過，單純的照搬模式并適合每個團(tuán)隊(duì)，況且你得允許人家吸納敏捷開發(fā)的優(yōu)勢為己用，然后找到適合自身團(tuán)隊(duì)的敏捷開發(fā)方法。關(guān)鍵就在這個適合自身上，每個團(tuán)隊(duì)在敏捷的過程當(dāng)中，摸索的過程都是不一樣的，執(zhí)行的人也不一樣，這注定不會使每個團(tuán)隊(duì)都有相同的敏捷模式。

光有敏捷開發(fā)的形能起作用么？

我不知道是否有標(biāo)準(zhǔn)的敏捷模式或者規(guī)范來告訴我們敏捷開發(fā)的第1，2，3步該如何去走，大致上的使用方法肯定是有的，細(xì)節(jié)的東西肯定也都是前人所摸索出來的。采用過敏捷模式的人都知道敏捷開發(fā)的一些標(biāo)簽：backlog，站會，迭代計(jì)劃，迭代總結(jié)會議等等，這些其實(shí)都沒什么問題，關(guān)鍵在執(zhí)行之后的效果上，拿backlog的維護(hù)和站會模式來說。

Backlog就是以前的user story，這個維護(hù)一般是要產(chǎn)品經(jīng)理來完成的，需要在每個迭代開始之前將該迭代所需完成的部分backlog根據(jù)優(yōu)先級一一維護(hù)好，以便開發(fā)和測試團(tuán)隊(duì)執(zhí)行。最早制定的模式是每個backlog都必須能在2-3天里面完成，后天發(fā)現(xiàn)不行，有些backlog達(dá)到所要求的功能確實(shí)時間會較長，且無法再拆分，后來變成每個task必須在2-3天里面完成，每個backlog必須在一個迭代里面完成，一個迭代是兩個星期。按照這個方式，一個開發(fā)周期超過兩周的項(xiàng)目必須得拆成好幾個backlog，也就是說項(xiàng)目是允許跨迭代執(zhí)行的，然后按照backlog的優(yōu)先級原則，優(yōu)先級高的會先行進(jìn)入開發(fā)。咋看之下是沒什么問題的，但一旦同時進(jìn)行的項(xiàng)目變多了，很多backlog擠在一個需求池里面的時候，問題就來了。

首先是backlog管理的混亂，按照優(yōu)先級原則開發(fā)，部分項(xiàng)目中的部分backlog確實(shí)優(yōu)先級高，業(yè)務(wù)價值高，先行開發(fā)是對的，但幾個迭代下來之后，維護(hù)這個需求池就比較的吃力了，產(chǎn)品經(jīng)理確實(shí)能看到每個backlog的完成進(jìn)度，但是每個項(xiàng)目的完成進(jìn)度看不了了，因?yàn)橐呀?jīng)拆的七零八落，且有的完成有的還在等待排期，或許一段時間內(nèi)都排不上了，非常不利于項(xiàng)目的管理。

其次是開發(fā)測試人員的混亂，剛進(jìn)入某個項(xiàng)目，做完一小部分功能后立馬投入到另外一個項(xiàng)目中，做一小部分功能然后又去另外一個項(xiàng)目，思維轉(zhuǎn)變來轉(zhuǎn)變?nèi)?，到最后在理解業(yè)務(wù)需求的時候發(fā)現(xiàn)都串了，特別是幾個項(xiàng)目之間有關(guān)聯(lián)性的時候，我終于明白為什么迭代計(jì)劃會議要開那么久了，就是為了讓開發(fā)測試人員轉(zhuǎn)變思路的。

站會是敏捷特有的形式，就是每天早上大家面對面站成一圈，各自花1分鐘講述一下過去一天都完成了什么，有什么問題，接下來今天要干什么，有什么需要協(xié)助的地方。這種形式其實(shí)挺好的，是一種高效的開會模式，能在短短十幾分鐘完成每個人都發(fā)言且形成決議（站會報告），日常的會議組織肯定沒有這么高效。前提是整個團(tuán)隊(duì)都在一個辦公地點(diǎn)，實(shí)在不行分兩處視頻或語音開會也是可以的。有人說這種模式雖然有點(diǎn)奇怪但習(xí)慣了就好，但就是習(xí)慣不了啊。

站會模式應(yīng)該是外國人搞出來的，其實(shí)國人在這方面確實(shí)不像老外那么收放自如，特別是我們的程序員，大都沉默寡言的，本身坐著發(fā)言話都很少，別說一群人站著面對面了，別提多別扭。當(dāng)然開過幾次之后會好一些，然后最后的效果是大家都習(xí)慣了快速的敷衍了事，趕緊把自己那點(diǎn)講完，可能還帶了很多程序的術(shù)語，至少產(chǎn)品經(jīng)理是不大聽得懂的，不過團(tuán)隊(duì)成員之間熟悉了之后確實(shí)好了很多。

再就是產(chǎn)品經(jīng)理一般都要趕趟，如果負(fù)責(zé)的產(chǎn)品線夠多的話，一早上的站會就得參加好幾次，所以理想中的一個產(chǎn)品經(jīng)理一個團(tuán)隊(duì)的做法，在現(xiàn)實(shí)當(dāng)中也比較難實(shí)行，大多數(shù)公司都是恨不得把一個人拆成幾個人用的。

敏捷開發(fā)的神是什么呢？

簡單的說，敏捷開發(fā)是一種以人為核心，迭代、循序漸進(jìn)的開發(fā)方法。在敏捷開發(fā)中，項(xiàng)目的構(gòu)建被切分成多個子項(xiàng)目，各個子項(xiàng)目的成果都經(jīng)過測試，具備集成和可運(yùn)行的特征。換言之，就是把一個大項(xiàng)目分為多個相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中系統(tǒng)一直處于可使用狀態(tài)。敏捷開發(fā)是針對傳統(tǒng)的瀑布開發(fā)模式的弊端而產(chǎn)生的一種新的開發(fā)模式，目標(biāo)是提高開發(fā)效率和響應(yīng)能力。關(guān)鍵點(diǎn)出來了，就是提高開發(fā)效率和響應(yīng)能力，擁抱需求變化。

雖然說除了原則和實(shí)踐，模式也是很重要的，多研究模式及其應(yīng)用可以使你更深層次的理解敏捷開發(fā)。但是光有模式也不行，還得掌握其核心目的。我們所說的目標(biāo)導(dǎo)向，就是這個意思。既然敏捷開發(fā)的目標(biāo)是提高開發(fā)效率和響應(yīng)能力，那是不是只要能實(shí)現(xiàn)這個目標(biāo)的一切方法都是敏捷開發(fā)呢？

顯然問題的反問就不是肯定的答案了，因?yàn)槊艚蓍_發(fā)模式的出來，比然已經(jīng)經(jīng)過了很多人的傳承才會引起大家的廣泛認(rèn)可，有這樣的基礎(chǔ)在，就證明其有一些特性化的東西是不可磨滅的，比如說站會。那是否可以在引進(jìn)的模式基礎(chǔ)上做適當(dāng)?shù)霓D(zhuǎn)化呢？個人覺得完全是可以的，取其精華去其糟粕嘛。

雖然說沒有預(yù)先的模式照搬，不會得出后面的神，就像國家的社會主義革命一樣，也都是先經(jīng)歷了錯誤才走到正確的道路上。但是我們已經(jīng)知道了這樣的歷史，那就得借鑒歷史的教訓(xùn)，結(jié)合自身的實(shí)際情況，取其精華即可。一個真正實(shí)行敏捷開發(fā)的團(tuán)隊(duì)，絕對不應(yīng)該有條條框框的東西去束縛他們的手腳。

敏捷開發(fā)的形神兼?zhèn)?/strong>