一、測試也有敏捷
1、全程參與
測試人員從項目立項到發佈結束全程參與整個研發過程，而不是開發完畢後很突然的提交到測試部安排測試，測試人員必須從需求階段就開始介入，從理解需求到幫助產品人員完善需求；在我們很多項目中經常忽略了測試人員參與需求的評審及討論，這個和W模型中談到的測試和開發並行稍有區別，以前的有V和W模型，而現在的是敏捷模型（具體區別在哪裏有時間再和大家分享）。
2、從客戶出發
保持大局觀，站在客戶的立場，保證最終發佈的是一個優秀的產品，而不僅僅是提交了多少個Bug，這主要是價值取向不一樣，在一個團隊中，不管你處於什麼角色，最終的目的是要讓這個產品是一個優秀的產品，是客戶需要的有價值的產品，而不是各個角色在這個項目中付出了多少，提交多少Bug等等各自的業績數據。
3、測試驅動
測試驅動產品整個開發過程，測試人員要做的不僅僅是測試，而是要做對這個項目一切有利的事情，比如與客戶溝通需求澄清、版本控制、流程機制等其他事務。
4、時刻敏捷
根據不同迭代調整測試策略（測試進度、人力投入、測試方向）
5、不是一個人
項目所有人員均參與測試，當然測試人員肯定是主要角色了，其他開發人員、產品人員等和項目相關的人員也要抽一定的時間來測試，只是和測試人員測試的重點和方向不一樣而已，比如產品人員更多的關注用戶體驗、價值收益等，一但發現問題或者不妥之處立即反饋修正。
二、走出敏捷誤區
1、敏捷開發是否需要文檔？
敏捷肯定也需要文檔，只是沒有CMMI要求的那個嚴格，那麼細緻。我們也不能完全依靠文檔來幫助我們提高效率，但一些框架性基礎性的文檔肯定是需要的，特別是基礎需求，這樣能夠幫助項目成員瞭解整個項目的大概意圖。在敏捷的過程中我們要做好文檔的變更管理（因爲變化無處不在）。
很多人認爲敏捷重在溝通，這完全沒錯，但我們不能因爲這個缺乏一些文檔支撐，不能只靠口頭或者零粹的郵件代替文檔，那就是亂上加亂，敏捷過頭了！
2、敏捷開發模式與項目管理是否有衝突？
完全沒有衝突，只是價值觀有些區別，其實在某種意義上來說，如果項目管理沒做好就直接進入敏捷模式跨越比較大，推行起來比較困難，比如項目管理中涉及到的變更管理、溝通管理等這些都是敏捷模式所需要的，也是一些基礎性的工作方式。因此可以認爲項目管理是一個基礎。
3、敏捷是善變的良藥？
顯然敏捷不是善變的良藥，一個產品的研發過程中肯定會涉及到很多變化，但是我們的方向不能變，比如開始需求是要做一個花捲，最後改成要做包子，其實像這類變化是不能容忍的，如果要改變花捲的顏色形狀那還是可行的。
敏捷中涉及到的變化是指在需求不清晰的情況下，通過迭代讓客戶快速確認反饋最終形成一個非常清晰的需求並得以呈現，而不是隨意的變化，那技術人員不累死還不討好。
三、敏捷要求
1、產品的整體規劃及需求說明（包括未來的產品走向）
我們把產品比喻成一個孩子的話，那麼產品經理就猶如這個孩子的父母，作爲父母的必須要爲孩子的成長做一些規劃，這樣纔有利於孩子的成長以及在成長過程中根據孩子的反饋不斷的修正成長路線，這樣父母纔是一個合格的父母。
2、迭代計劃需要產品人員制定和重點把控
和前一個觀點差不多，只是說明產品人員是一個產品成功或者失敗的關鍵，是產品的靈魂人物，產品經理們責任重大啊。
3、迭代的劃分要遵循可測試性原則（保證每次迭代是一個可執行完整操作流的測試）
在做迭代計劃中需要測試人員參與考量下每次迭代的可測試性是否最佳，不能出現迭代開發完畢後完全是一個不能測試不能評估的半成品，都展現不出什麼價值談何評估反饋，不能爲下一個迭代提供有價值的東西那麼就不要去迭代，直接與其他合併即可。
4、迭代中的需求變更需要落實在文字或圖表上
5、測試將原有的W測試模式變爲迭代測試
6、文檔流程只是一個輔助工具，最主要依靠及時有效的溝通（文檔、溝通之間如何權衡這是個度的問題，千萬不能走極端）。
歡迎轉載此文，轉載時請註明文章來源：張元禮的博客 http://blog.csdn.net/vincetest