1，快速叠代
相比大版本的半年發布，小版本的需求、開發、測試更加簡單快捷。有的公司壹年只發布2-3個版本，發布進程緩慢。他們仍然采用瀑布開發模式，更嚴重的是，他們對敏捷開發模式有誤解。
2.讓測試人員和開發人員參與需求討論。
以討論組的形式討論需求是最有效的。研討會小組需要包括測試人員和開發人員，這樣更容易定義可測試的需求，對需求進行分組並確定優先級。同時，這種方法還可以充分利用團隊成員的互補特性。這樣確定的需求往往比需求討論會議效率更高，大家更積極，參與感更強。
3.編寫可測試的需求文檔
從壹個“用戶故事”開始(用戶？Story)方法來編寫需求文檔。這種方法允許我們關註需求，而不是解決方案和實現技術。過早提及技術實現會降低對需求的關註。
4.多溝通，盡量減少文件。
溝通是任何項目的通病。良好的溝通是敏捷開發的先決條件。妳在圈子裏呆的時間越長，妳就越會強調良好高效溝通的重要性。
團隊要保證日常溝通，面對面的溝通比郵件強很多。
5.制作壹個好的產品原型
建議使用草圖和模型來說明用戶界面。不是每個人都能看懂壹個復雜的文檔，但是每個人都會看圖。
6.考慮盡早測試
在敏捷開發的早期考慮測試是很重要的。在傳統的軟件開發中，測試用例編寫得很晚，導致需求中的問題發現得太晚，改進成本太高。早點開始寫測試用例，當需求完成後，可接受的測試用例基本壹起完成。