項目進度狀況通常是通過各工程活動完成程度(百分比)逐層統(tǒng)計匯總計算得到的。進度指標的確定對進度的表達、計算、控制有很大影響。項目進度管理是在項目實施過程中，對各階段的進展程度和項目最終完成的期限所進行的管理。在實際項目操作中，總有影響項目進度的因素出現(xiàn)。
1、使用敏捷開發(fā)
敏捷開發(fā)，這是現(xiàn)在非常時興的一個詞，聽起來挺牛逼的，敏捷，讓我們感覺用了它就會“快”。在被這種開發(fā)模式折磨了1年多的我想說，其實它跟其他所有的事情都一樣，它有自己適用的領(lǐng)域，假如錯誤的以為任何項目用敏捷開發(fā)都能敏捷，那就是自找苦吃。
為什么?敏捷開發(fā)的特點就是根據(jù)用戶的需求迭代，一個迭代解決一個迭代的問題，對于一個對于架構(gòu)清晰的項目來說，這樣每一個迭代都會有一些成果。而對于有些項目而言，比如說殺毒軟件，磁盤分析器等等，對于這種產(chǎn)品類的項目，很多時候它的需求都是一開始需要定義清楚的，客戶名義上是廣大的PC用戶，實際上是PM或是PGM，PM說這個項目里面我們要做3個功能，那我們就需要做3個功能，多一個不行，少一個也不行，如果PGM在你做了3個功能后告訴你，要加一個功能，而且這個功能在舊的架構(gòu)上是很難實現(xiàn)的，那么這個PGM就是不合格的，為什么?因為他加大了項目的成本。所以，我想說的是，如果需求是由我們自己定義，而且我們很清楚要做一個什么東西的時候了，采用敏捷開發(fā)的風險可能會加大，因為它過多的依賴于“迭代”，認為迭代可以解決大多數(shù)的問題，可是實際情況遠不如此樂觀!當你的PM對你我們要加這個新功能，之前的定義的功能不行這個迭代要改的時候，作為一個程序員，我們能做什么呢?去跟PM說，對不起，我們之前的底層架構(gòu)不支持這種變態(tài)的需求，PM會告訴你，我就是代表客戶，這個功能就得這么做，我說了算，為什么不支持，我們不是采用的敏捷開發(fā)嗎，敏捷開發(fā)的特點不是迭代來解決問題嗎?
老實說，瀑布模型的好處之一，就是你的PM可以少幾個變需求的理由，PM一個星期變一次需求，我們程序員就沒有幸?？裳粤?，所以，我想勸有些項目經(jīng)理，別拿需求的變更當做理所應當?shù)?，你不是一個嬌生慣養(yǎng)的小孩，沒有必要變的需求就不要變，如果你把敏捷開發(fā)的需求變更當做是你隔三差五變需求的理由，那下個項目，當你的程序員聽說你要用敏捷開發(fā)，肯定想抱頭痛哭。你是產(chǎn)品的設計師，這個產(chǎn)品的外觀功能，應該一開始就定義好，不要前一個月說要做個電飯煲，這個月又說要在電飯煲加個微波爐的功能，如果你手下的程序員任勞任怨，把微波爐的功能真的加進了電飯煲，那只能說PM幸運，碰到了技術(shù)牛人，并且技術(shù)確實是可行的，但是如果功能實現(xiàn)不了，那么PM可能就怪開發(fā)者，覺得他們技術(shù)不行，心想我用的是敏捷開發(fā)，為什么我給了你們時間缺不能解決問題呢?
時間確實是可以解決問題，但是作為開發(fā)者更希望把時間多花在需求分析階段，而不是修改舊的代碼上。開發(fā)模型只是一種工具，依賴敏捷開發(fā)這個工具，并不是解決所有問題的萬金油。
作為項目經(jīng)理，你不光要對客戶負責，更需要對產(chǎn)品負責，對你手下的程序員負責。其實，假如做不到后面兩點第一點也不好做到，因為項目很可能經(jīng)常delay，到最后客戶不滿意，或者產(chǎn)品上線的時候早已經(jīng)落于市場上其他的產(chǎn)品。
2、角色分配
角色分配的問題在整個軟件開發(fā)過程也是很重要的，說簡單點就是分工要明確，按照博弈論的觀點，假如我們每個人的目標都是合理的，那么我們通過相互的制約很好的推進項目的周期，但是如果角色分配的不合理，比如說職責重復，缺少角色等等，那么開發(fā)的過程