軟體開發的專案週期大體分為3個階段：獲取需求和定義產品、開發和測試、部署和運維。

　　在獲取需求和定義產品階段，需要防止 的不是進度太慢而是過快、過草率。特別是對於創業公司的產品經理來說，很可能因為看到開發人員無事可做而感到壓力，所以儘快完成產品定義，而沒有充分了解 市場和競爭對手資訊，沒有與合作伙伴充分溝通，沒有做深入的思考。

　　這些因倉促而隱藏的問題，發現得早則導致開發階段大量返工，發現得晚則導致產品上線後不 受歡迎。常聽一些人說現在網際網路開發，講究快速迭代和敏捷，邊做邊想，返工也正常。這是一個誤解。快速迭代指的是將不同版本之間的週期縮短，小步快跑，而 不是在一個版本的週期內來回折騰。

　　在開發和測試階段，專案管理重在跟蹤進度和保持溝通—用整合和演示跟蹤進度，基於Bug溝通問題。

　　要做到各個模組外部介面相對清晰穩定，並儘早完成各個模組間的整合，最晚不超過開發週期的1/4時間。第一次整合之後，就應該開始每日整合和每週演示。每日 整合使得測試團隊每天能同步測試最新的程式碼，幫助開發團隊儘早發現問題並及時瞭解技術細節上的進度；每週演示使產品經理、專案經理和管理層能從使用者的角度 感受產品，使他們對產品有信心。整合和演示是專案管理的心跳，合理利用它們，有助於及時把握專案的健康程度。

　　無論開發流程多敏捷，工程師能 力多強，記錄和跟蹤Bug都是必不可少的。開發團隊和測試團隊的溝通都應該基於Bug，才能言之有物。開發工程師每次提交程式碼都應該記錄是針對哪個Bug 的，每日

　　在後期部署和維護階段，要快速響應。考驗的是團隊成員的責任心和抗壓能力。系統運維工程師要深夜工作，因為部署可能要在流量低的時 候進行；專案經理要保持能隨時溝通，做出快速而準確的決定，鼓勵團隊並做出表率；一旦出現高危害Bug，開發團隊要在24小時內準備好補丁。Amazon 的做法比較有趣：在產品剛上線一段時間內，開發工程師要保持24小時開機。如果自己負責的模組中出現高危害Bug，那麼很可能會在深夜被系統運維工程師叫醒。這樣不僅能保證快速響應，還能讓工程師意識到：前期程式碼不好好寫，後期就別指望能好好睡覺了。

　　本文出處：http://www.programmer.com.cn/13625/