在互聯(lián)網(wǎng)行業(yè)，敏捷應該不是陌生的名詞了?；ヂ?lián)網(wǎng)產(chǎn)品快速發(fā)展的特性，決定了“小步快跑”的管理思想，持續(xù)迭代，不斷的改進產(chǎn)品。而應用敏捷基本上可以讓迭代周期減少一半，在追求效率和產(chǎn)出的互聯(lián)網(wǎng)，這確實是一劑良方。

在產(chǎn)品研發(fā)過程中，從需求管理到最終的產(chǎn)品運營，全過程應用敏捷的思想，讓產(chǎn)品團隊成為產(chǎn)品的主人和管理創(chuàng)新的驅(qū)動者。

當產(chǎn)品團隊自發(fā)的去持續(xù)優(yōu)化產(chǎn)品，不斷提升產(chǎn)品質(zhì)量和研發(fā)效率時，整個團隊的工作效率就提升了，產(chǎn)品的迭代周期自然會縮短，他們會樹立更高的目標去挑戰(zhàn)，當他們持續(xù)地周而復始時，卓越就成為了團隊的習慣。

在敏捷實施的過程中，從產(chǎn)品經(jīng)理的角度來說，更應該關心需求是否也可以迭代的方式去產(chǎn)出，合理的按照價值和優(yōu)先級去安排每個迭代需求，是產(chǎn)品經(jīng)理需要關注的。這會保證每個迭代開發(fā)人員在實現(xiàn)的都是優(yōu)先級最高的需求。

從開發(fā)人員角度來講，對每個迭代的任務的需求理解和工作量安排是他們所要關心的，要合理的分配每個人的任務，以達到最大化的效率利用，進而保證每個迭代的高效產(chǎn)出。

團隊動態(tài)背后反應的問題可能是多方面的，不同團隊不同階段碰到的瓶頸也不同，下面用三個維度來進行分享有效的實踐案例：

需求協(xié)作

簡單點說就是，每個迭代開始前，讓產(chǎn)品，開發(fā)和測試三方一起來看看接下來迭代的需求，確保大家對這些需求的理解一致（注意這里強調(diào)更多的是一致的理解而非需求正確，因為這次需求的正確性已經(jīng)不是這些人討論能解決的）。

具體討論的方式是為每個需求寫出驗收條件或者測試用例，使用的例子越具體理解的一致性越高，當然討論會更費時。這個主要針對需求-?開發(fā)-?測試過程中需求理解不一致導致的返工或修bug，通常有一半以上的bug都來源于此。

最簡單的應用這個方式就是在寫代碼前，測試和開發(fā)一起看看針對這個功能可以有哪些測試用例，開發(fā)帶著這些測試用例來開發(fā)。

團隊結(jié)構(gòu)

選擇恰當?shù)膱F隊結(jié)構(gòu)：職能團隊，組件團隊和特性團隊。

職能團隊即按職能劃分：需求分析團隊，開發(fā)團隊，測試團隊等。

組件團隊即按系統(tǒng)架構(gòu)的組件來劃分：前端團隊，后端團隊，平臺團隊等。

特性團隊則按照需求特性來組織團隊，每個團隊都能獨立完成整個功能，較少或不依賴于其他團隊。

這三種團隊結(jié)構(gòu)越往后團隊效率越高，但不同的組織上下文不同，所處現(xiàn)狀的約束也不同，需要選擇現(xiàn)階段可行的團隊結(jié)構(gòu)，逐步朝特性團隊調(diào)整。

拆分需求

這里的需求指的是對用戶有價值的需求，而非針對某個組件，拆分出來的需求也要對用戶有價值。

需求拆分的力度參考：一個團隊（人數(shù)為5~9人）在一個迭代內(nèi)（迭代長度為1~3周）能“完成”的需求在5~7個左右。這里要完成的定義需要和團隊一起商量決定，但至少要包括編碼完成，測試完成，無嚴重bug。

這里提升的效率指的是整體需求的交付效率，而非個體或局部的效率。針對的是不同工作間的等待，排隊，重復等浪費，縮短反饋周期。

敏捷開發(fā)在互聯(lián)網(wǎng)行業(yè)中的應用是大勢所趨，個人覺得會深刻影響到傳統(tǒng)的瀑布式項目流程。

從實際經(jīng)驗來看，敏捷開發(fā)也確實有很大的優(yōu)越性，能夠更快的適應需求變更，靈活的安排資源的投入，每個迭代的產(chǎn)出都是產(chǎn)品的階段性目標，也有可能就是一個小版本的發(fā)布，對于崇尚“持續(xù)迭代、小步快跑”的互聯(lián)網(wǎng)產(chǎn)品來說，非常適合。