敏捷軟件開發方法中的6個實戰經驗(2)

　　團隊要確保日常的交流，面對面溝通比郵件強得多。

　　敏捷開發鼓勵日常的協調會議和碰頭會，5~7人參與的會議盡量控制在10分鐘內。碰頭時，要過一遍昨天完成了什么，今天要做什么，哪些問題仍待討論?？梢杂肂urndown Chart(燃盡圖)來形象展示工作進度。每次迭代的時候也都要開一個計劃會議和評審會議，一般需要的時間可能會長些，比如半天。這些會議的目的就是對工作查缺補漏。

　　評審會議很重要，傳統開發模式往往略過該環節，導致一些錯誤做法不斷重復，好的做法無法推廣。

　　開會時，可以將原先的分組打散，讓整個團隊都參與到項目的需求討論和測試中來，這樣可以突出成員個人，讓大家更樂意參與。

　　5. 做好產品原型

　　建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復雜的文檔，但人人都會看圖。

　　一個常見的問題是軟件新的功能與用戶想要的不一致。為了避免這一問題，可以模擬真實操作，改進模擬操作過程中難以理解和不清楚的操作行為。

　　6. 及早考慮測試

　　及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。

　　敏捷開發中一個常見問題就是開發者沒有對已有的代碼庫進行充分的回歸測試。迭代周期很短，從開始到交付就是4周的時間，這樣可以對迭代的設計、實現和底層測試一塊進行回歸測試。

　　一系列迭代之后，可以只針對測試活動再補充一個迭代。這個迭代可以將重點放在系統測試、與其他系統的集成度、性能等方面。敏捷開發過程中，可能會導致過少的測試文檔。如果迭代周期為1個月左右，可以不必對測試文檔過于要求，但要制定好測試策略。

　　最后

　　可能大多數公司或團隊還沒有開始嘗試敏捷開發，不過可以開始從點滴做起，比如開碰頭會、為項目管理采用一個更加高效的管理工具等等。最后，希望上面的建議能夠為大家的軟件開發管理帶來幫助。(編譯/王殿進)

原文轉自：http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques