有些 團隊中會要求每個成員每天對自己的工作進度以百分比的形式做匯報，他們以為通過這樣的方式可以確實的掌握事情的進展，但實際上并不行，因為軟件開發中存在很多不確定因素，有時候我們認為事情已經完成了一大半，但是可能因為技術或者其他的原因發現這一大半工作方向是錯的，這時候就要推倒重來，而且人們在匯報工作量的時候總是會有一些感情的因素在里面，這就使那些看似精確的百分比打了個折扣。
所以，我們需要更加實際和細致地劃分工作，對目標的完成情況進行度量。這也是迭代周期不能太長的一個原因：如果你把大量有前后關聯的工作劃分入一個迭代周期，在設定的結束到來時，突然發現只完成了一小部分，這時候雖然亡羊補牢仍然可以，但是中間浪費了大量的人力和物力。
反饋
一個男人在大街上走著，他并沒有發現褲子上的拉鏈已經松開了，雖然看到這個情況的人有很多，但他們有各種各樣的擔心，比如不想多管閑事，怕讓那個男人難堪，或者干脆就是想看笑話。結果就是這個人繼續穿著一條敞開拉鏈的褲子在大街上行走。
這件事情至少帶給我們兩個啟示：1，得到反饋是重要的；2，要想得到正確的，有價值的反饋，你需要其他人的配合。
對于用戶需求來說，沒有用戶及時地反饋，我們就可能把那些不符合需求的開發繼續下去，由于軟件中各種功能和模塊的依賴性，這種不符合最后可能被放大到數倍。越遲得到反饋，問題可能就越大。
軟件開發中一個很重要的概念是“可行性”和“合理性”，無論我們做需求，設計還是開發，集成，測試，都會遇到這兩個問題。有些事情的可行性和合理性是我們可以通過事前的分析進行判斷的，但是有些問題就必須有一定的實踐作為基礎。這也是一個反饋的問題。譬如說在某項目中技術架構師決定采取一個技術架構，但是經過一些階段的開發發現它有一些技術上問題不能實現用戶的關鍵需求，這時候就必須放棄它。
“反饋”意味著兩個意思，對一件事情的調查和根據調查做出決策。
在意識到反饋的重要性之后，你會要求所有的人都對迭代的成果做出反饋�？赡艽嬖诘膯栴}是，是不是所有的人都意識到了反饋的重要性并且認真地去做了呢？如果客戶認為他們只需要對迭代出來的產品“看看而已”，那么你就很難了解他們一些深層次的想法。再比如一次迭代中某些模塊開發的進度比較慢，開發人員可能會抱怨技術方案不能滿足要求，而實際的原因可能是設計不合理或者根本就是有人沒有認真工作。
中國國家隊前主教練米盧曾經說過“態度決定一切”，反饋作為迭代開發中至關重要的一個方面，必須得到足夠的重視。
獲得反饋的方式和對于反饋信息的分析是另外一個重要的方面。一般來講，根據軟件開發角色的不同，我們非常關注的是兩類人的反饋：項目組之外的客戶和項目組之內的各種實施人員。
軟件項目一般都會要求客戶方安排專門的業務人員進行配合，在迭代開發中，這種配合不只是進行需求的整理和發掘，還包括對已經完成軟件版本的評測。在這個過程中應該有需求分析師的配合。
在每次迭代完成之后，軟件項目組應該有一些總結和分析活動。通過這些總結和分析，找到做得好和做得不好的方面。
在非迭代式的開發中，也有反饋的環節。比如通常在軟件交付階段會有一個試用期讓用戶提出意見。而軟件團隊在各種開發中都會有一些總結活動。迭代式開發的獨特之處在于盡量早地引入反饋機制；使得反饋機制更加制度化；并且，更加快速和靈活地分析這些反饋，把得到的結論應用到下一階段的開發中去。
對于一些機制引起的問題，比如組織結構不合理，角色分配不明確之類。最好有一個明確的問題記錄表。在每次迭代完成以后將這些問題記錄下來，同時在下次迭代中努力改善它。如果相同的問題連續出現在幾次迭代中，可能就說明項目管理出了問題。
合作
軟件團隊中的合作是人們一直都在提倡的。我們在這里提到“合作”的意思并不只包含團隊內部的協作，還包括和客戶的合作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
