讓開發流程形神合一一的關鍵思考

一個人寫著心中構想的程式，沒有時間壓力、自由自在地寫著，突然腦中靈光一現，想要做些改變，也任由自己動手，不需要考慮到別人，也毋需為別人負責，這大概是全天下最單純的軟體開發形式吧？

不過，大多數人參與的軟體開發專案，恐怕都不是這樣的形式。大多數的情況下，每個專案都會有使用者端的代表，決定開發產物最終的面貌，因此有著既定的開發時程，需規畫開發進度及截止的期限。專案的開發通常由多人同時參與，各自扮演一個或是多重的開發角色，並且透過彼此的溝通與合作，一同完成。

開發流程導致的問題在於「人」
正因為大多數的軟體專案開發，相較於個人化的程式寫作複雜許多，必須處理具有不同專長的各種角色參與、協調指派多人一起協同工作，並且在期限內完成開發目標、準確地滿足使用者的需求。

因此，才會有各式的開發流程（Development Process）被設計出來，用以指引開發團隊在開發的過程中的角色分工、規畫開發的各個階段，設定每個階段的里程碑、階段中每個角色應當從事的工作，以及如何與團隊中的其他成員合作，以便達成各階段的任務。

老實說，我知道許多程式人，對開發流程都沒有什麼好感。我想這中間有很大的原因，是因為在許多開發流程的運作下，程式人的工作自由度大減，同時增加了很多程式設計以外的工作。

不少程式人心中對開發流程有個刻板的印象，認為在開發流程的運作下，只是多出一些徒具表面形式的文件及表單，程式人不僅需完成原本就應該撰寫的程式，還得花費力氣填寫這些文件及表單。這類的紙上作業，是眾多程式人最為深痛惡絕的呀！

建立軟體開發流程，原始動機當然是為了改善軟體開發的生產力及品質，以便在花費最小的情況下，準時交付產品。但是，似乎許多團隊在採用他們所挑選的開發流程後，不見生產力及品質的提升，反而引發了一些問題。而在這些問題中，程式人最在意的，當然是額外的人力資源消耗。程式人或許很喜歡寫程式，但喜歡寫文件的程式人，恐怕是稀有動物。

當然，我認為這問題並不出在開發流程上，關鍵還是在於人如何看待開發流程。

深思投入的成本大於回收效益的原因
就從管理者開始說起吧！有些管理者可能的迷思，是他們將開發流程看待成為一種制度化的工具。某種角度來看，這樣的想法倒也沒有太大的錯誤，但是，有些管理者認為，開發團隊採用越是繁重的開發流程、引入越多的系統或是表單、產出越多的書面文件，就代表開發團隊本身制度化的程度就越高。

而對管理者而言，制度化是一件重要的事，什麼事都應該要制度化，代表著他的管理上軌道，所有被管理的一切，都在這軌道上依照該有的秩序在運行著。在這種思維下，很容易產生像「CMMI對軟體開發的成熟度分為五種等級，那麼當然是等級越高越好」的認知。

對於一名程式人而言，這無疑是一場災難。

此時，建立開發流程的目的，是在於打造一個從管理面來看「似乎井井有條」的完整制度時，便不再是針對開發本身的目的建立流程。

開發流程中勢必投入一些活動，而這並不是撰寫程式碼，因此，嚴格來說，不算是對最後產出有直接貢獻的活動。從某種角度來看，這些活動也算是一種額外的成本。

但事實上這樣的成本，其實算是一種投資，因為我們希望透過這些活動，能夠達成引入開發流程的原始目的，也就是縮短開發時程、減少投入的人力及資源，維護良好的品質等。

既然是投資，總不會希望投入的成本，大於最後回收的效益吧？但事實上，許多團隊施行他們所選用的開發流程後，不僅未蒙其利，反而身受其害。這其中的原因又是在那邊呢？問題終究還是因為許多工作僅僅只是表面功夫，徒具形式罷了。

了解需求規格文件的目的
舉例來說，許多流程設計都有需求規格文件的撰寫工作，而這個工作有一個重要的目的，就是記錄、描述規格使用者的需求。達成這個目的後，開發團隊便可以依據這份文件，理解使用者心目中所想像的系統，究竟是長成什麼樣子。而使用者可以憑藉著這份文件，了解開發團隊在一次或多次的需求訪談過程中，他們所理解的系統，究竟又是長成什麼模樣，並且雙方可以進一步確認。

這樣的文件，對開發來說，當然是相當重要的一份文件。許多專案的開發，之所以遇到瓶頸，最終都是源自於需求管理上的問題。因為需求管理的基礎是了解需求，而了解需求，代表必須和使用者對於系統的最終產物建立起共識。

倘若缺乏了這一層共識，開發團隊自己打造想像中的空中樓臺，等到使用者開始測試時，才驚而不喜地發現，原來開發團隊打造的系統，竟然不是自己想要的。這時候，就得花費更多的力氣來進行矯正。

只求形式的後果，比不做還糟糕
你可以想像，之後必須要付出的代價究竟有多高昂了。所以，需求訪談的活動、需求規格文件的撰寫、以及需求規格文件的確認，算是我們對於開發的一項投資。

沒錯，它是會帶來額外的人力負擔，但預期帶來的回報，便是開發團隊得以降低日後因為沒有精確掌握需求，而不必付出更為驚人的人力消耗。

但是，一般來說，我們所看到的需求規格文件，大多是徒具形式。他們或許排版整齊，看起來該有的章節一應俱全，但很可惜的，因為撰寫的人並不是以詳實記錄使用者需求，並做為與開發團隊溝通為基礎的方式撰寫。

例如，只是依據著文件的樣板，一個蘿蔔一個坑地填些東西進去，讓這份文件看起來像是樣樣俱全（這實在是我們時常可以觀察到的殘酷事實）。但這份文件之所以需要存在的真正目的，除了記錄之外就是溝通，不僅要完整、精準描述欲開發的系統長相，更要藉此減少使用者和開發團隊的認知差異。

徒具形式的文件，卻無法達成上述的目的。這麼一來，撰寫的人花了大量的時間產出這份文件，卻發揮不了它應該要產生的效果。開發團隊花費了成本，卻無法回收投資。

徒具形式最可怕，因為它比不做還要糟糕。

開發流程應是輔助，而非障礙
而一些團隊在施行開發流程時，很容易陷入上述的陷阱中，他們講究要去執行流程中所規畫的活動，以便看起來像是極具制度化地在運作著。例如，執行流程中所規範的文件撰寫活動，卻又不理解流程中規畫此一活動的真正用意，最後的產出，不僅不能讓這份文件發揮溝通的效果，而且還白費了力氣和時間。這對於生產力、以及開發預算都是很大的傷害。

這或許正是許多開發人員，對於「開發流程」多半有著一些錯誤觀感的原因。事實上，開發流程是輔助開發團隊的工具，而不是障礙。倘若，對開發團隊構成了障礙，那麼，勢必需要認真思考，究竟是在那一個環節出了差錯。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。