小目標就是大目標細化后的結果。主要的目標是一個階段或一段增量的末尾。要達到那一點，項目需要在整個進程中都設立細化的目標。小目標一到兩天的工夫就可以達到，以小時為單位。它有這樣的好處：可以改善狀態報告；因為可以知道一個小目標是否沒有完成所以能夠實現細粒度控制；因為大約每天都可以完成一個小目標所以會更好地激勵員工；還有可以降低執行進度超時的風險。為了避免項目中的各種問題，建議小目標的設定從項目一開始時就著手實施。最好的辦法是用電子表格記錄和跟蹤小目標的執行進度。由工具（如 MicroSoft? Project）生成的項目計劃最好只用于更上層的任務。當然，只當前的階段才劃分多個小目標任務。后面的階段在需要時再進行劃分。盡管開發人員認為設定小目標是個麻煩，但是這個問題補償了小組領導和單個開發人員定義他們自己的目標并分散項目管理和跟蹤項目的工作量的能力。通常一個由技術指導定義的任務，一旦由開發人員將其細化為多個小的目標，則任務就會變得更大。有時技術指導會提供備選的、更快、更易維護的方案，在其他一些場合他也同意任務的分解并分配給任務更多的時間。盡早地實施小目標計劃的工作可以避免潛在的災難性結果的發生。
8. 以小時為單位跟蹤所有的項目時間
不僅要跟蹤以小時付薪的顧問和立約人所花的時間，每個項目成員所花費的時間同樣很重要。這樣做的好處是可以對照個人所用的時間與項目計劃的時間。如果個人已經轉向其他任務就要采取一些步驟。同樣，實際的時間也可以對照估算的時間，估算的時間可以依次地為項目的下一個階段或下一個項目的時間估算方法提供反饋。對小目標的全部時間的估算可以限制時限的超出，因而這些時限是可以修正的。應用小目標技術要求來自各方面的包括技術指導、小組領導和每個開發人員的時間和努力。至少每個星期，每個開發人員要以電子表格的方式提交他的工作狀況，讓項目主管可以在每個更上層的任務中更新完成進度的百分比。這樣將使項目管理的工作量分散到其他的小組成員身上。跟蹤項目時間會耗費更多的時間，但這能實現非常有效的項目管理。
9. 應對不斷出現的變化
對于大多數項目，每個月項目的需求變化不會大于 5%。這些變化的產生有多方面的原因，例如沒能在正確的時間提出恰當的問題、正在處理的問題發生了變化、用戶改變了他們的主意或觀念、商業環境發生了變化或者是市場發生了變化。功能特性蠕變都會輕易使得成本和執行進度超出預先的估計。在項目的初期階段，項目需求中有許多纏雜不清的地方。當執行到某個階段（通常在第二階段的末尾）時，項目需求就必需確定下來并鎖定其核心內容。一個變化的管理過程由一個所謂的“變化委員會（change board）”來執行，變化委員會由項目所涉及的每個領域的代表組成，例如業務、市場、開發、質量保證、用戶文檔、客戶支持和項目管理等。變化委員會負責將所要做的改變交由適當的人去完成、對改變作出說明并測定來自各方的估算值的大小。在獲得足夠的信息后，變化委員會就可以決定接受還是拒絕這項變化。一旦接受一個變化，它將被加入到計劃當中并且執行進度也要做出改變。伴隨有變化的項目要比原先沒有變化的項目提交得晚，但是它仍然是成功的，因為它仍然滿足修正后的執行進度和股東的期望。一個項目如果在啟用變化委員會之后有超過 5% 的改變，則表明項目制定得非常糟糕或者已失去了控制，最終很可能會失敗。
10. 項目領導
公司的管理者委任一個執行者承擔軟件項目成果的責任是至關重要的。這個關鍵的執行者不僅要總覽全局，還要獲得和控制項目所需的資源來幫助和支持這個小組。同樣重要的是，執行者不需要去干涉、管理小組中的一些瑣碎的事。執行者要相信小組是可以委以重任的。
結束語
本文列出了幫助提高軟件開發項目成功率的十點因素。遵從這些指導原則，您可以在預算和預定時間范圍內更好地完成項目、保持一個高效率的小組并盡量不改變功能特性。您可以參考 Mike 的另一篇關于最佳實踐的文章軟件開發項目的最佳實踐。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
