CSM敏捷實踐|如何讓團隊的迭代效率更高？

在網際網路行業，敏捷應該不是陌生的名詞了。網際網路產品快速發展的特性，決定了“小步快跑”的管理思想，持續迭代，不斷的改進產品。而應用敏捷基本上可以讓迭代週期減少一半，在追求效率和產出的網際網路，這確實是一劑良方。

在產品研發過程中，從需求管理到最終的產品運營，全過程應用敏捷的思想，讓產品團隊成為產品的主人和管理創新的驅動者。

當產品團隊自發的去持續最佳化產品，不斷提升產品質量和研發效率時，整個團隊的工作效率就提升了，產品的迭代週期自然會縮短，他們會樹立更高的目標去挑戰，當他們持續地週而復始時，卓越就成為了團隊的習慣。

在敏捷實施的過程中，從產品經理的角度來說，更應該關心需求是否也可以迭代的方式去產出，合理的按照價值和優先順序去安排每個迭代需求，是產品經理需要關注的。這會保證每個迭代開發人員在實現的都是優先順序最高的需求。

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

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

需求協作

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

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

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

團隊結構

選擇恰當的團隊結構：職能團隊，元件團隊和特性團隊。

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

元件團隊即按系統架構的元件來劃分：前端團隊，後端團隊，平臺團隊等。

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

這三種團隊結構越往後團隊效率越高，但不同的組織上下文不同，所處現狀的約束也不同，需要選擇現階段可行的團隊結構，逐步朝特性團隊調整。

拆分需求

這裡的需求指的是對使用者有價值的需求，而非針對某個元件，拆分出來的需求也要對使用者有價值。

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

這裡提升的效率指的是整體需求的交付效率，而非個體或區域性的效率。針對的是不同工作間的等待，排隊，重複等浪費，縮短反饋週期。

敏捷開發在網際網路行業中的應用是大勢所趨，個人覺得會深刻影響到傳統的瀑布式專案流程。

從實際經驗來看，敏捷開發也確實有很大的優越性，能夠更快的適應需求變更，靈活的安排資源的投入，每個迭代的產出都是產品的階段性目標，也有可能就是一個小版本的釋出，對於崇尚“持續迭代、小步快跑”的網際網路產品來說，非常適合。