如果你正開車到一個陌生的新景點去旅行，總距離大約是 200 公里左右，而你現在已經開了 160 公里，花掉了你兩個鐘頭，那麼，你知道，過去這段時間，你的平均車速是大約每小時 80 公里左右。現在我們來考慮以下的三種情境。
-
根據這個數據，此刻的你可以估算出，要到達目的地，大概還需要 30 分鐘左右。因為，用 (200 - 160) / 80，就能得出 0.5 小時的答案！
-
如果，現在你突然發現你快沒有汽油了，而下個加油站，需要再開 20 公里的車程，那麼你也會知道，大該還需要 15 分鐘左右，就一定可以有油可以加。因為，用 20/80，就能得出 0.25 小時的答案！
-
如果，現在你赫然發現，你附近的景色就已經是美不勝收了，有山、有水、有紅葉，你立馬決定改變原先的行程，就此打住，不再繼續往前開，改到此處走走逛逛，那麼，你知道，原來，你只花了 160 公里的代價，就得到了比原先的計畫更加美好的旅行經驗，而這個經驗卻是當初所沒有預期到的！
我們在做專案的時候，往往也會遇到像以上那樣的三種情境。而要回答這三種情境，最根本的還是要先能掌握專案團隊的「開發速度」！
如果我們能夠掌握專案團隊的「開發速度」，那麼，我們就能知道：
-
還需要多久，才能夠完成專案的所有功能和服務（如同上述的最終目的地）？
-
要達到某個里程碑（如同上述的加油站），團隊還需要多久的時間？
-
現在已達成的成果夠好了嗎？好到能結案出貨了嗎？（如同上述赫然發現的美好景色）
以專案管理的語言來說，對應上面三點的好處就是：
-
專案會不會 delay（或提早完成）？如果會，那會 delay（或提早）多久？
-
給定一個功能和服務的範圍，團隊會需要多少時間才可以達成？
-
如果需要因應市場態勢，現在就要提早結案上市，現在專案的 readiness OK 嗎？能短期快速把 bug 收斂完嗎？
不論是傳統式專案管理，或是敏捷式的專案開發方法，我們在管理專案的時候，其實都是一直在問自己以及在問團隊，這幾個最根本的問題而已。掌握團隊的開發速度，就幾乎是掌握了整個專案的狀態！
問題來了，開車的時候，我們隨時可以在儀表板上監看車速，那麼，專案團隊的開發速度又該怎麼來監看呢？
傳統式專案管理我們會用甘特圖（Gantt chart）來管理專案所有活動（Activity）的進度，搭配所謂的實獲值管理（Earned Value Management）的方式，來監控專案的進度。先對計畫完的所有活動做一個快照，當作一個比較的基準，再把實際執行專案時的狀況，跟基準做比較，來看出差異的程度。
這個方式是基於每個活動來追蹤進度的，而每個活動的複雜度差異、負責人的能力差異、守諾程度的差異，也可能相當地巨大，因此，整體專案的進度變異風險也容易變得很高！
而敏捷式專案開發方法，則是用所謂的「故事點數（Story points）」來追蹤進度，就如同文章一開始的開車旅行例子的「公里數」一樣。我們可以把「故事」簡單一點地類比為「功能特色」。需要花費比較多時間完成的故事，開發團隊就把故事的「點數」訂得多一些，需要花費的時間比較少的故事，就把故事的「點數」訂得少一些，而這些點數之間的比例，則是「開發團隊所有成員一起」將兩個故事相比較、大量討論細節之後制定出來的。這樣不僅可以去除掉個人能力上的差異風險，也讓「點數」變得客觀許多。
有了這個客觀的估算方法之後，敏捷式開發團隊就開始以固定週期的方式（就是所謂的「衝刺 Sprint」）來監看每個週期團隊能消化掉的點數有多少，這也就是所謂的「開發速度」趨勢。
這些點數背後所代表的，就是一個個的「故事」。這些「故事」有大有小，有難有易，但這些對衡量開發速度來說都不重要，因為都已經被轉化為「點數」的觀念了！
只要開發團隊永遠都先做高優先權、高使用者價值的故事，再藉由團隊成員之間的緊密互助和備援，加上不斷地監控、改進每個衝刺週期的開發速度，我們就能很容易地回答上面的三個問題，轉換成敏捷式專案開發的語法就是：
-
還需要多久（幾個衝刺週期），才能完成專案的所有功能和服務（所有的故事）？
-
要完成到某個特定的故事（必須依照故事的優先順序來開發），還需要多久的時間（幾個衝刺週期）？
-
專案已經完成的所有衝刺的總成果（故事）夠好了嗎？好到能結案出貨了嗎？
此外，除了已經被安排進衝刺去執行實做的故事之外，所有其他的故事都可以隨時被移除掉、被修改、被改變其優先順序，這也就是所謂的「敏捷」！
如同我們的開車旅行計畫，若是你中途就已經達到了比原計畫更好的成果了，也就是發掘到更棒的景點，何不就此打住，好好地享受一番過去努力的成果了呢？
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
