我在Reddit編程上發佈了這個問題，但沒有得到任何答覆。所以我希望Stack Overflow社區會有意見。已崩潰或快速跟蹤有效的項目計劃？
有任何你曾經上了身後倒下一個軟件項目，其中「崩潰」或「快速跟蹤」項目進度實際帶來的項目進度計劃回到正軌？我從未見過這些項目管理技術中的任何一種都可以發揮作用我讀過的所有關於軟件開發的文章均指出，這兩種技術不起作用，並且實際上將項目推進得更遠（例如關於神話人月的文獻）。那麼誰看到它的工作？
謝謝比爾。
我只見過它一次工作。這是一個長達三個月或四個月的項目，預計比原來的交付日期多兩個月。該項目得到了快速追蹤，最終事情回到了正式發佈的軌道上。
...但是要記住，這只是一次。我已經參與了許多項目，其中PM試圖使用這兩種方法中的一種，並且他們慘敗失敗，並且將項目拖延了已經延長日期。
有一個軟件管理原則說增加人手後期項目使得它以後。
這就是說，只要採取的措施是合理的，應該沒問題。不要期望你的員工太多，並提供合理的激勵措施，不要採取捷徑。它不會造成奇蹟發生，但如果你是實用的，並希望把事情推得更快一點，那絕對可以做到。
當人們擁有的東西潛力休慼相關，這是驚人的多少，他們更多的精力是願意投入。
這取決於你所說的「工作」是什麼。我認爲我從未見過這會讓遲到的項目按時交付，如果這就是你要求的。
不過，我已經看到它讓路後期項目後期只能傳送一個位。從管理的模糊角度來看，這可能被稱爲「工作」。我也看到它顯着降低了公司對客戶的壓力。有些人也可能稱之爲「工作」。
當然價格也相當高。員工疲於奔命，在被忽視的個人生活中出現健康問題或重大問題等等，所有這些都給公司帶來了巨大的經濟反響。所以我懷疑這家公司從長遠來看未來。這是「工作」嗎？
它可以工作。但是需要付出代價：更低的質量（更多的錯誤，更少的測試）以及被燒燬的程序員的更替。
而且在很多情況下，一個快速跟蹤的項目將無法按時交付，並且仍將支付全部的負價，原因如下：神話人月。
我見過它的工作，但它不是標準。
事情我想看看之前我想這可能是可行的：
1）工作人員可提供適當的技能和方法。我認爲這並不意味着「。NET程序員「，我的意思是詳細的技術技能，業務領域技能（讓他們理解問題），個性適合並理解工具和方法（源代碼控制，方法學等）。工具，標準和知識，但你需要確保它們幾乎在所有的盒子裏都打勾了。
2）任務必須是可以整除的，最好的情況是整個模塊，應用程序或任務沒有啓動，你可以讓新人加入，最大限度地減少技術提升，增加溝通等等，如果你不能分清新人會做什麼，你很可能會破壞現有團隊。必須購買這種方法ting團隊並不認同帶人蔘與是對的，他們可能會與之抗衡，你註定要失敗。
4）你需要確定你已經解決了爲什麼它在第一個地方遲到。如果這只是不好的估計，那麼你有信心新的估計是好的？如果它是範圍蔓延你現在是否有範圍和改變控制？如果是因爲截止日期的推移，你確定它不會再移動嗎？
如果你不能打勾所有四個，它不會工作。
崩潰和快速跟蹤是兩個完全不同的東西...
快速跟蹤中你需要的東西（任務或工作包）失序和早期做。這可能是因爲硬件交付週期，資源可用性，風險或其他因素。因此，您可能會按原先計劃按順序進行並行處理。我已經快速追蹤了很多項目。是的，它的工作原理。
使項目崩潰是不同的，因爲你通常會拋出更多的資源來解決問題，以便更快地完成它......這可能會非常棘手。如果這是作爲危機應對措施完成的，那麼可能會讓您痛苦不堪，因爲您已經處於泵的下方。在某些情況下，您只需添加更多問題。
崩潰的另一種替代方法是縮小範圍。這並非總是可行，但應該考慮。
隨着快速跟蹤或崩潰......越早知道何時需要制定日程安排更容易管理。這就是爲什麼早期的截止日期如此重要，它們表明項目的其餘部分將如何進行。
+1用於解釋條款。 – RodeoClown 2009-09-08 04:23:02
這兩個項目管理技術起到了很好的保持一個時間表，但他們應該通過智能分析明智的網絡圖中：
我的意思是「工作」是做你在第二段中說的。開展一個計劃落後的項目，並按計劃恢復或至少縮短落後的時間。 – bkoch 2009-09-03 14:10:08