【51CTO專稿】敏捷開發從國外引進發展已經有了很長的一段時間，而在國內的追棒依然很火爆，中小企業，創業公司很多項目成員開始學習敏捷，采用以及轉向敏捷開發。可是，當實際操作上并不能解決傳統開發的一些問題解決，反而新增加了更多的問題。

有人說，實踐敏捷的根本不在于敏捷本身，而在于理解敏捷背后擁抱變化的基因。確實，使用敏捷，那么你就應該知道為何敏捷。

當你從某個行業去領悟衍生出這種方式，畢竟那是成熟行業成功的經驗映射。在實際的操作中，分配，轉型，時間，技能等等都需要嚴格謹慎的執行。

就在前段時間，網易有道云筆記負責人蔣煒航在微博上分享了一篇名為《敏捷開發的實戰經驗》的文章，講解了團隊如何實踐scrum的一些經驗得到了網友很高的評價。網易有道云筆記從事敏捷開發積累了豐富的經驗，因此，51CTO的記者基于敏捷開發為主題，采訪了網易有道研發經理李勤飛。

[[65236]] 

李勤飛目前是網易有道研發經理，有道云筆記技術負責人。曾參與過有道詞典的開發，具有多年的團隊管理經驗。是有道云筆記引入和實踐敏捷開發方式的主要負責人。

以下是李勤飛給網友們分享的敏捷開發管理經驗：

一、敏捷團隊

1）在敏捷開發中團隊的拆分

在敏捷開發中，組織團隊方式是按照項目組織，而不是行政劃分。拆分團隊只有一個理由，就是能提高團隊效率。根據經驗，小團隊的效率更高。當團隊人數大于9個時，計劃會和站會，成員的參與感會下降，效率會降低，溝通成本也會加大，這時候需要拆分團隊。

2）在敏捷開發中團隊的管理

敏捷開發只適用于小規模的團隊的這種說法是錯誤的，敏捷開發跟團隊的數量沒有直接關系，只要大于3人的團隊都可以實行敏捷開發。

但是，小團隊更容易敏捷。團隊人數的增加必然會提升溝通協作的成本，可以通過拆分團隊的方式來提升效率。把一個大團隊拆分成幾個小團隊，團隊之間的協作也走敏捷開發的流程，就是我們常說的Scrum of Scrums。

3）在敏捷開發中團隊的轉型

想要做到敏捷開發，每個團隊都要經歷一個轉型期，那么在轉型期還需要每個團隊根據自身的不同，找出合理有效的解決方法。

對于有道云筆記的團隊是逐步推行敏捷開發的，沒有遭遇明顯的轉型期，但推行過程中確實也遇到一些問題。比如產品經理開始并不認同根據固定時間的sprint來劃分版本，最后用已有團隊整體產出提升的經驗說服了他。還有比如產品已經上線，sprint進行中間會有一些線上的問題插進來，我們通過線上值日，以及根據經驗數據來預留時間等方式來解決這個問題。

二、敏捷方式

1）編碼方式

很多人為了編寫易變更的代碼，在采用敏捷時，拋棄許多習慣用法，這是一個誤解。敏捷開發推崇涌現式設計，通過不斷的重構來實現更好的架構。指的設計而不是編碼，對于編碼方式，不需要發生變化，除了需要遵守公司和團隊的編碼規范外，用自己熟悉的方式即可。

2）極限編程（XP）

極限編程有很多爭議，我們的方式是選擇性接受，比如把兩位工程師組成一對，相互review代碼，并且要求編碼測試代碼等。但是暫時不會采用兩人一起編程的方式。

3）指標衡量

每個sprint的總結非常重要，會記錄每個任務（task）的預估時間和完成時間。并且定義了完成度（任務的完成情況），希望sprint的完成度在80%以上。如果完成度低，就需要總結原因并改進，團隊成員的績效也會受影響。當然，除了項目進度以外，有道公司還有另一套評價體系，跟業務無關，而是由專業的技術委員會對程序員個人能力的評估。這兩套評估結合在一起，就可以很好的衡量程序員的工作。總的來說就是，按進度完成項目的同事，個人能力也需要不斷提升。

4）scrum會議

Sprint會議是實踐scrum中最重要的事件，這更是團隊做改進的最佳時機。有道云筆記團隊的Sprint以一個月為期，四種會議：需求梳理會，Sprint計劃會，Scrum例會，Sprint回顧會議。

1. 需求梳理會在Sprint計劃會的前1-3天開，參加的人員是產品經理和開發人員，由產品經理稱述需求，開發人員討論設計與實現。
2. Sprint計劃會是Sprint開始第一天開，參加的人員有產品、開發和測試，由產品經理講需求，開發人員把需求分解成任務。
3. Scrum例會每周兩次，周二和周四，主要溝通任務的完成情況，和下一個兩天做什么。
4. Sprint回顧會議在Sprint結束時做，主要總結這個Sprint的經驗教訓，并且達成一些團隊共識，比如例會遲到如何懲罰等。

最后，

李勤飛希望未來敏捷開發在多地方點辦公，敏捷測試等方面有新的發展。建議大家使用敏捷開發時都可以做些調整，然后把自己的實踐經驗分享出來，共同改進這套方法。