作為一個軟體項目產品經理，最終的目標是是否能如期保質保量地交付，並且更重要的一點，你需要向你的老闆說明，你採用不同的開發方式到底能為他們節省多少錢。任何公司的老闆都看重這一點。我自己也一直對敏捷和傳統開發在不斷地進行對比，可慢慢發現，如果工作中真的摒棄傳統開發方法，完全按敏捷的步子來，那麼很難計算出我們的成本。
為什麼？最容易看出的地方就是對傳統開發來說，抵制的是產品設計的變更，因為行業業務邏輯相對穩固，最終的主線需求是不變的，所以無論設計還是開發，這部分變更的成本都容易控制和核算。但對于敏捷開發來說，比如網際網路行業經常用迭代式開發和增量式交付，來不斷地更改產品設計，更改交付的模塊，那這部分因為變更導致的成本是沒辦法衡量的，或者更嚴謹地說，這部分變更的成本，誰來買單呢？是自己還是客戶？
也許有人會說敏捷中也有項目工作量呀！比如我們把用戶故事拆分成任務，再用撲克估算法估算出較為準確的工作量。沒錯，但這並不是只有敏捷中才有的方法和手段，在傳統的軟體開發中，做規模較大的項目時，我們也會將功能模塊拆分到可估算的顆粒度，比如一個工作時長為6～8小時的活動，用WBS分解和類比法來做工作量的預估，而敏捷中的用度量數據調優，在傳統軟體中我們也會用資產沉澱的數據，來做掙值分析和項目預算，任何項目都不抗拒歷史數據的積累，這不是任何開發方式/方法的特點，而是人類在項目經驗中不斷的積累，對任何項目都適用。更重要的一點，並不是能預估工作量、能計算實際工作量就能得出成本，因為你必須還能得到損失的成本。
在一次敏捷會議中，其中QA階段有個人提問：「敏捷如何來幫助我們控制成本呢？」有個很明確的回答：「並不是所有項目都適合用敏捷，要看你最後想達到的目標是什麼，如果目標是看到某個產品在網際網路用戶中的增長率、產品反饋速度，那麼敏捷可以幫你實現，但如果是成本，敏捷無法幫你控制成本，它無法來準確地估算。」
所以如果我們的項目是以交付為導向，是以成本、合同為驗收目標，而不是用戶數量，那麼敏捷中適合我們的就是那些頻繁的溝通和站立式會議，以及顯而易見具有靈活性鮮明的狀態板，因為這些優勢和開發模型無關，就像飯前洗手一樣，在任何時候都適用。