更少的也許是更多的
早期，我們注意到添加詳細的信息到需求也許不總是對項目有益的。對其他類型的文檔也是同樣的。你的質量保證計劃、軟件開發計劃或者需求管理計劃都不是項目健康的良好量度。太詳細不總是更好的：你應該調整你特定項目需要的文檔詳細級別。決定合適詳細級別的方法是關注 風險和結果：如果你添加詳細信息到某一產物可以減少風險或者改進特定結果的質量，那么這個投入是值得的；否則，在更有生產力的活動上花費時間是更好的。
使用瀑布型的方法 項目經理需要付出很多的注意以詳細的計劃和指定需求。而使用迭代開發的方法項目經理可以根據工作中的風險來權衡的將時間花費在細化需求、架構、設計和實現上。他們會問：“什么樣類型的活動可以最有效的立即降低風險呢？” 也許原型化一個方案可以處理與項目客戶買進相關的風險，或者也許他們需要實際的設計、實現和測試架構以完全的處理架構方面的風險。
使項目中的每一個成員都參與到質量保證中
對于項目經理來說移到迭代開發方法需要的其他思想的改變是開始將質量保證作為一個集體的職責考慮。我通常會驚訝的聽到項目經理說“我需要測試小組對我的開發人員保持忠誠，”或者“如果分析人員沒有寫下單個的需求，他們將不會被實現�！� 當然，你的確需要測試小組來建立高質量的應用，并且失敗的文檔化和跟蹤需求將導致問題的出現。但是如果開發人員不把質量當作自己的責任，你也就會陷入到質量問題中。為了實現這一點，你需要從通過信任你的 團隊和清晰的交流你們的預期開始。假如你不能信任這些人，那么也許這些人不應該屬于你的團隊。
理想的情況下，項目經理應該能夠宣稱“我的開發人員負責交付高質量的代碼；為了幫助開發人員，我們有一個測試團隊，測試團隊有專業的能力并可以驗證被交付的代碼是否是高質量的，”并且“我們的開發人員負責實現滿足最終用戶需要的應用。為了幫助開發人員，我們有一個分析的團隊在適當的詳細級別上文檔化需求，并且分析人員是開發人員和最終客戶之間的橋梁�！� 創建交能夠協同工作的團隊 — 也就是說使團隊中的分析人員、開發人員和測試人員能夠一起工作來實現高質量的結果 — 是成功的迭代開發的關鍵之一。
質量保證和方法專家的新思想
為項目選擇適當的形式級別（更多的不總是更好的）。
關注在整個項目周期中維護質量，但是可以是靈活的。最好的到達高質量的做法不是僅僅通過瘋狂的關注檢查和測試實現的，而是通過在給定時間上對需求、架構、設計、實現、檢查和測試的良好平衡實現的。
采用風險驅動的過程方法。你的過程應該允許項目經理對項目當前的風險情況采用戰術性的活動。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
