敏捷開發的一些體會

現在在網上看文章，貌似不敏捷就落伍了。公司內部各team在show off的時候也是大談如何從瀑布走向敏捷，貌似一敏捷就藥到病除。最近在coolshell的blog上看到一篇老文“再談敏捷和ThoughtWorks中國諮詢師”，頓感心有戚戚焉。現在就結合我這裡的具體項目談談什麼樣的項目適合做敏捷以及如何做好敏捷開發。

PS: 哥雖然有Scrum Master的認證但還是反對什麼都往敏捷頭上套。

公司之所以選擇這個項目進行Scrum試驗有如下幾個原因：

1. 上一個版本原計劃半年結果做了1年，公司近三分之一的開發與測試資源砸了上去。
2. 需求頻繁變化，產品經理和開發測試人員相互扯皮。
3. 產品倉促上線，大量功能未經充分測試。
4. 新上任的工程總監是敏捷開發愛好者，正好拿此項目開刀。

現在Scrum正式開始了，但是我在這裡要問一句我們開發軟體的目的是什嗎？這個還要問嗎？不就是為了發行後賺錢嗎！帶著這個問題，我們美國的專案經理我們準備什麼時候發行？哥承認被shock了，那位大哥的回答是：我們現在開始敏捷了，一個sprint接一個sprint做，啥時幹完啥時發行。好吧，幸虧這個項目的測試不是哥直接負責，你愛咋地咋地。(其實哥是對自己手下的兄弟有信心，真要做砸了我們估計還能成為僅有的亮點。)

帶著同志們的祝福，項目開始了。每個sprint不管3721隻要產品經理腦袋一拍，一堆需求就塞進來了。開發看著只有一句話描述的需求面對的回複是：現在是敏捷開發了，要多溝通少文檔。溝你妹啊！一個在中國，一個在美國，郵件溝通一來一去一天就沒有了。電話？是你熬夜呢還是我黎明即起？3周一個sprint，光把需求搞明白就一周去掉了，然後做啊做啊，還有2天sprint就要結束了，可是突然一看工作清單，50個只完成了30個，怎麼辦？根據Scrum的教條，sprint是不能延期的，那麼做不完的就踢到下一個sprint去好了，反正沒有發行日期，慢慢做好了。嗯，很好，這個sprint我們順利完成了35個任務！做啊做啊，3個月過去了，產品經理看看幾個大功能也有模有樣了，很好，我們宣布某某新版本順利發行！！！(先開槍再畫圈，很好很強大！)

顯然這樣的敏捷開發是不能讓高層滿意的，大家坐下來總結經驗教訓，推出了2.0版，更新如下：

1. 大老闆希望更快的看到成果彙報，sprint周期由三周縮短為兩周。
2. 中美各成立一個Scrum小組，本地測試支援本地開發，每個sprint的任務按比例分配。
3. 產品經理必須提供更完善的設計文檔。
4. 加強溝通，每周雙方召開例會。
5. 除去在美國的主產品負責人和Scrum master，在上海增設本地的產品負責人和Scrum master，部分決策可以就地做出，不必請示美國。
6. 開發必須寫單元測試。

這些改動，3456點都是對項目整體有利的。第1點帶來的問題是如果開發工作稍有延誤，留給測試的空間就十分有限了。第2點則喜憂參半，好處是上海團隊有了更大的自主權，壞處是測試開發比嚴重不足。因為上海的測試leader要兼任Scrum master，所以測試和開發是2.5比7，而美國的測試和開發則是4比6。不過考慮到本地測試生產率高於美國，而且開發也願意擠出時間來協助測試執行測試案例，在2個sprint之後，上海團隊表現良好，而美國團隊依然落後於進度。

雖然2.0版的Scrum比起1.0版大有進步，但是依然存在以下幾個問題：

1. 周期太短，開發完成工作後留給測試的時間太少。
2. 上海的測試長期超負荷工作。
3. 因為周期太短，所以沒有時間做測試自動化，這樣導致在無法做自動化的迴歸測試，只能依賴手工測試選取幾個關鍵測試案例保證之前的功能正常工作。

雖然還是有種種問題，但好歹是穩步前進了。周期恢複到三個星期，人手不夠開始招實習生，自動化測試沒時間做那麼就上線後集中拉一段時間補課。

通過近半年的Scrum實踐，我總結了一些經驗和大家分享一下：

1. 一定要有一個release目標，要根據這個目標倒過來排計劃。
2. PO和Scrum master必須有豐富的傳統開發模式經驗，不然項目很容易失控。
3. 每天的例會後Scrum master要迅速跟進，重大問題要立刻解決，什麼工作生活平衡全是扯淡，執行力必須是第一位。
4. 雖說搞Scrum要求每個員工都積極主動，但是開發與測試leader還是要花很多時間分配任務，調整優先順序。開發必須為測試和修複bug留出足夠時間。
5. 自動化測試非常重要，早做晚做一定要做。
6. 員工之間的知識共用非常重要，誰都有個頭疼腦熱，不能因為一個人暫時離開就影響項目進度。
7. 單元測試協助很大，一是避免了很多基礎的商務邏輯錯誤，二是可以讓開發更清楚商務邏輯。

更多內容請訪問http://monstersay.cn/，謝謝！