我想知道什麼時候開始使用項目管理應用程序（例如Redmine或Trac）的正確時間或正確的項目大小。何時開始使用項目管理應用程序？
我有一個認真的項目，現在只有我在開發，但我使用redmine來設置我的項目版本，問題和估計。我認爲這是一個好主意，因爲你永遠不知道什麼時候有人會加入這個團隊，並且還可以讓我有效地組織自己。
我問這個問題是因爲我在大學的教學助理連續工作了一年，而且我經常遇到這方面的問題。雖然我是一個堅信原則的人，但我認爲學習早期使用這些工具是大多數時候都是雙贏的。
我真的相信我們可以避免這個問題成爲議論性的，並且對於這個問題有一些共識，我認爲在今天的軟件開發世界裏這個問題非常重要。
那麼，何時是正確的時間？什麼是正確的項目/團隊規模？
當項目達到複雜程度（無論是管理還是代碼要求）時，團隊的所有成員都無法立即向利益相關者提供有關項目狀態（即時或計劃）的答案。
這意味着：就可以開始使用管理工具或在任何階段，你喜歡的當量（這裏「相當於」是指使用帶有燃盡圖或沿着類似Excel之類的工具）。有人可以繪製沙子中沒有線，然後說「一旦你越過這條線，你必須使用管理工具」。
您不必證明使用管理工具是正當的，您必須證明其中的費用爲。他們是否給予了足夠的效率，以便爲您付出的代價，您投入培訓的時間或使用它們所花費的時間？
slu，，謝謝你的回答。我明白，我認爲這筆開支不僅有錢（考慮免費工具），還包括培訓時間等。 – Goles 2010-04-25 05:17:16
我不熟悉redmine，但假設它具有功能性和複雜性堪比trac，我會建議「爲它去」更早而不是更晚 - 我不會真的叫trac一個「項目管理」工具（這個術語讓我想到Microsoft Project，GANTT圖表等等，它們對軟件開發項目的適用性要求更高，更有爭議），而是一個「問題跟蹤」工具。
如果你有一個簡單的項目，會出現越來越少的問題（功能請求，錯誤修復......），但沒有什麼壞處，並且在跟蹤它們時有一定的好處 - 人員項目可以輕鬆確定和調整問題或期望所處的領域，其相對優先級等。
還有其他方法可以跟蹤（例如，Pivotal的tracker），這些方法可能更適合沿着敏捷線路運行的項目，至少在理論上，但我個人總是喜歡類似trac的系統，無論我使用的其他工具和方法如何（如果我可以將其與我的代碼管理系統集成 - 自動跟蹤變更集會提供什麼問題或功能目標等等 - 然後我是一個真的快樂露營）。
一些有助於處理大型複雜項目的工具和方法不能「簡化」到更簡單，更小的項目（因爲方法或工具中存在複雜性或剛性的最低限度，使其過於沉重足夠小的項目），但根據我的經驗，一些工具和方法（版本控制系統，問題跟蹤器，代碼評論，如果我可以得到它們以及在任何情況下自動「編程風格」檢查器等）甜蜜，我總是樂於將它們放在我的工具欄中，就像一個項目一樣簡單！
恕我直言，只要你問的問題，答案永遠是「現在」！ – Ether 2010-04-25 16:27:31