最近看到幾個產品的開發,上市發表的時間往後調整了幾次,但還是遲遲無法問世。發生什麼問題呢?不是技術不行,也不是人力嚴重不足,而是開發範圍(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 盡量維持它不擴展、不改變,但是可以適度地削減它。

作者簡介


Advertisement

更多 iThome相關內容