開發時要總是想著範圍

最近看到幾個產品的開發，上市發表的時間往後調整了幾次，但還是遲遲無法問世。發生什麼問題呢？不是技術不行，也不是人力嚴重不足，而是開發範圍（scope）的管理上出問題。

這是個很常看到的情況，我們找了優秀的程式設計者來開發，理論上，他們更有能力完成工作，包括設計出好的架構、寫出優質的程式碼，有著高效的開發速度，但是，為什麼產品還是無法如期交付？開發範圍沒有管理好，是常見的原因之一。

事實上在開發時，你應該總是優先想到 scope。

定義軟體的開發範圍與處理細節的必要性

開發範圍的界定，本來是專案規畫（project planning）中的一個工作，目的是用來確定要開發的究竟是什麼、需要滿足那些需求。在界定 scope 之後，才能以此為依據，分析出需要那些工作，以及這些工作需要花費多少人力及時間。

未確認開發範圍內的細節，是開發範圍管理上會發生的問題之一。

沒有細節要如何開工呢？似乎有點詭異，但卻不難見到。很多時候，scope 的權責者（例如產品經理或是客戶），只是把需求描述了一個大概，就讓開發團隊開始投入開發。這看似很奇怪，因為連要做的東西都還沒有確定，要怎麼去做出這個東西呢？

於是，我們可以想像接下來發生的事：隨著開發進入更細部的實作，程式開發者遇上了細節的問題，是他所接收到的「範圍藍圖」裡所沒有描述的，所以，要嘛他自己憑藉著想像力，補上了這些細節，或者，他開始回過頭來，向 scope 的權責者確認這些細節。

若是他直接憑藉著想像力自行補上，那麼在進入測試階段時就可能會發生慘劇。

因為他所想像的細節，不見得符合掌管 scope 的權責者的預期。這麼一來，實作錯了，又得耗費大量的時間重頭來過。而若是在開發中途，發現細節描述不足，回頭過來雙方確認，一則擔誤時間，因為溝通常常需要不斷的往返，因而延誤時間；二來若是確認細節後，發現之前的實作尚需要調整，此時，又得回過頭去修改調整已有的產物，而這也會影響時間。

因此，沒有足夠清楚的細節，就逕行投入開發，最後就會花去比實際所需時間更多的時間。

拿捏執行細節

若是依照傳統的 waterfall開發方式，把規格寫的洋洋灑灑、鉅細靡遺（雖然也不見得人人都做到），而在敏捷開發風潮的流行之下，大家開始節省文件化的程度，有的甚至節省到連細節都不描述了。

敏捷的想法是很好的，但是究竟需要描述到多深入的細節，是需要隨著開發時的情境來決定的。描述了太多不需要的細節，是浪費時間，影響開發前進的敏捷性；但若描述的太少，則又會有缺乏細節反而影響開發時間的問題。不過，我想說的是，當你不斷把這個議題放在腦海裡，你也明白這件事需要依開發時的情境來取捨時，你就會試著做出一個比較好的決定。最糟的情況是，你完全沒有意識到這一點，所以你省略了太多細節，因而衍生了後續缺乏細節的問題。

要有切點∕里程碑

關於 scope 的第二個常見問題是沒有明確的「切點」，也就是沒有一個明確的停止點。

在這種問題裡，最常見的是邊開發邊增加 scope 的內容，因為隨著開發的前進，掌管 scope 的權責者，又有了更新的想法，例如，看到了競爭對手的新功能、或是自己天外飛來的靈感，致使他決定在自家的產品上加上了新的功能，而這就會增加 scope。

問題是，開發正在進行中，擴展後的 scope 會影響到原先對於完成時間的計畫，而使得完成日延遲。延遲總是會在所有人的心理帶來一些負面的影響，業務人員會覺得，產品怎麼遲遲無法問世（即使他們也知道 scope 一直在增加），而開發人員也覺得，這個產品怎麼老是開發不完，感覺開發的黑洞深不見底。

所以總是要意識到目前正在進行的工作要有個「切點」，總是可以去設想日後還需要做些什麼，但是你需要為現階段的工作設定一個切點，先讓它告一個段落，或許距離你心目中的完美還有一段距離，但是，你還是得先讓一個可以運作的成品出來。這樣的好處是它會把一個開發的循環跑完，最起碼會完成測試，確定它是可以運作的。

這麼一來，所有的人都可以拿它做為基礎來做為下一個階段開發計畫的評估。包括你可能會先讓這個版本公開發行，或是招募封閉的測試使用者以接收進一步的使用回饋意見。

有了一個成品之後，還有一個好處，是讓所有的人，都暫時不需要懸著一顆心在那裡想著，業務人員不需要掛念究竟東西完成了之後確切使用起來的樣貌，而開發人員也不需要心煩，覺得為什麼這個產品老是開發不完、開發的東西為什麼愈長愈大，好像沒有止盡一樣。

就算你在切點後沒有要立刻對外發行，你也應該將內部的開發計畫畫分為多個切點，讓每一次切點的產物都是可以獨立運作，並且被用來評估下一階段的開發計畫的。在過去，我們可能會稱這樣性質的東西為「里程碑」，其意差不多，但是我覺得在這邊使用「切點」這個名稱的原因，是要提醒大家不要不捨得「切斷」。

難不是難在設一個目標來做為里程碑，難是難在你要從你想做的事情當中，設定一條停止線，把一些暫時還不那麼需要的東西切掉，讓這些東西在當下的目標完成、被使用之後，再來做進一步的評估。

我們應該都很常看到那些掌管 scope 的人，不捨得把功能從目標中捨棄掉。事實上，應該挑出一組核心的功能，讓它快一點被完成、被看到、被體驗，以致於其餘的功能得以被評估其優先順序，甚至是存在的必要性。

這其實是希望開發具有敏捷性的基本要則，但是正因為不捨得，切不掉，所以才會讓 scope 太大，甚至是持續成長。很多時候，時間條件會回過頭來要求你限制 scope，例如必須趕上一個重要的參展機會，時間是不可變動的，所以能調整的只有 scope。

設法有效管理開發範圍的異動

最後一個容易發生的問題就是 scope 的變動，也就是當你訂立了一個階段性的目標後，你在執行過程中去變動它，包括修改功能，或是增加功能。

除非極其關鍵，否則最好是等這個階段（即切點所切出的範圍）完成後，再把它加到下個階段裡去，否則 scope 的增加或功能修改，都等於是讓切點不再成為切點。

需要增加的 scope 或修改的功能，應該等本階段完成後，一起納入評估優先順序及存在必要性，而不是參雜在當前的 scope 中去開發。

有一種 scope 的變動通常是好現象，那就是砍掉 scope。我們在執行的過程中因為一些因素，例如發現根本沒意義或是因為符合時間限制的關係，所以我們會打算砍掉原本計畫納入 scope 的東西。這種 scope 的變動常常都是健康的。它幾乎不太會造成負面的效果，而且開發人員很喜歡。它也讓大家更可以如期得到一個可以運作的產物。

因此，所有參與開發的人，包括掌管 scope 的權責者，總是要一直在心裡想著 scope。有明確的 scope 才能開始開發。此外，scope 中的細節需要被足夠的描述，而且，總是應該要畫分出適合的斷點，在一個切點裡的 scope 盡量維持它不擴展、不改變，但是可以適度地削減它。