人月(man-month)通常用來預估或排定時程，也是一般用來評估工作量的單位。

可以單純使用人月來預估工作量的前提有以下兩個 : 
1.工作者彼此之間不需要溝通(包含訓練和交換資訊)
2.工作可以完全切割(被切割的部分沒有連續性)

可以套用人月來計算工作量的簡單範例就是收割作物。
假設1個人採收1公畝的作物需要1個月，佔地4公畝需要4個人月。你可以讓1個人工作4個月來完成，也可以請4個人工作1個月來完成。

也可以說在這種情況下人月是可以互換的。(當然，前提是忽略工作者不會在工作中閒聊或割錯範圍)

但軟體開發很難只透過人月來預估工作量。

1.首先是溝通，溝通包含訓練和交換資訊。

每位投入的開發人員都必須接受技術的訓練，目標和策略的規劃等等
(雖然收割作物也需要訓練，但對比軟體開發而言成本相對小了多)

另外無論元件的交換資訊(API)或開發人員的交換資訊(討論資料格式，架構規劃，程式流程等等)，所佔的成本其實是相當可觀，可以計算看看開了多少會議來討論這些問題。
(交流量公式 : n(n-1)/2，n為人數，根據這個公式，3個人的交流量是2個人的3倍，4個人的交流量則是2個人的6倍，以此類推)

2.至於工作是否可以完全分割，以一個很簡單的4個模組來說明，登入模組，主畫面模組，加密模組，儲存模組。依賴關係如下

假設儲存模組發生儲存資料的內容錯誤，除了查找本身的缺陷(fault)和功能失常(failure)以外，它還必須通知加密模組以及主畫面模組或登入模組查找問題。

因此以測試或除錯的角度來看，軟體模組不僅具有連續性而且透過這種連續性引發的行為會大大增加所需的成本，在大型系統(模組數量大於100)的連續性成本更加嚴重。

事實上不單是軟體開發，想單純透過人月來評估工作量都應該至少考慮以上兩個前提(溝通和連續性)。

回過頭來，在軟體開發領域是否有其他方式可以減緩溝通和工作連續性所引發的成本?

敏捷開發可能就是個解方。

1.首先就技術的訓練而言，可以透過結對編程(Pair programming)讓老手來帶領新手來減輕新進人員的技術負擔和專案的陌生程度。

各種交換資訊所消耗的成本則可以透過Scrum會議(衝刺計劃會議/每日站立會議/評審會議/回顧會議)來減緩。

2.工作連續性所消耗成本，背後原因其實是個別元件沒有確實驗證而導致錯誤難以釐清定位。基本上可以透過單元測試或測試驅動開發(TDD)來確實驗證元件的正確性(行為和資料)。