程式者的胡言亂語
星期三 五月 13, 2009
漫談開發流程 - 徒具形式的開發流程
一個人自己寫著自己心中構想的程式，沒有時間壓力、自由自在的寫著，突然腦中靈光一現，想要做些改變，也都任由自己動手，不需要考慮到別人，也毋需為別人負責，這大概是全天下最單純的軟體開發形式吧？
不過，大多數人參與的軟體開發專案，恐怕都不是這樣子的形式。大多數的情況下，每個專案都會有使用者端的代表，決定開發產物最終的面貌，有著既定的開發時程，規劃開發進度及截止的期限。通常也都會由多人同時參與，各自扮演一個或是多重的開發角色，並且透過彼此的溝通與合作，一同完成專案的開發。
正因為大多數的軟體專案開發，相較於個人化的程式寫作複雜許多，必須處理具有不同專長的各種角色參與、協調指派多人一起協同工作，並且在期限內完成開發目標、準確的滿足使用者的需求。因此，才會有各式的開發流程（development process）被設計出來，用以指引開發團隊如何在開發的過程中進行角色的分工、如何規劃開發的各個階段，以及每個階段的里程碑設定、在每個階段中，每個角色應當從事那些工作，以及如何與團隊中的其他成員合作，以便達成每個階段的任務。
老實說，我知道的許多程式員對開發流程都沒有什麼好感。我想這中間有很大的原因是因為在許多開發流程的運作下，程式員的工作自由度大減，同時增加了許多程式設計以外的工作。許多程式員心中對開發流程有個刻板的印象，認為在開發流程的運作下，只是多出一些徒具表面形式的文件及表單，程式員不僅得完成原本就應該撰寫的程式碼，同時還得花費力氣去填寫這些文件及表單，而這類的紙上作業，更是眾多程式員最為深痛惡絕的呀！
建立軟體開發流程，其原始動機當然是為了改善軟體開發的生產力及品質，以便在花費最小的情況下，準時的交付產品。但是，似乎許多團隊在採用他們所挑選的開發流程後，反而不見生產力及品質的提昇，但卻引發了一些問題，而在這些問題中，程式員最在意的，當然是額外的人力資源消耗。程式員或許很喜歡寫程式，但喜歡寫文件的程式員恐怕是鳯毛麟角的稀有動物了。
當然，我認為這問題並不出在開發流程上頭，關鍵還是在於人如何看待開發流程。
就從管理者開始說起吧。有些管理者可能的迷思，是他們將開發流程看待成為一種制度化的工具。某種角度來看，這樣的想法倒也沒有太大的錯誤，但是，有些管理者會認為，開發團隊採用愈是繁重的開發流程，引入愈多的系統或是表單，產出愈多的書面文件，就代表開發團隊本身制度化的程度就愈高。而對管理者而言，制度化是一件重要的事，什麼事都應該要制度化，制度化代表著他的管理上軌道，所有被他管理的一切，都在這軌道上依照該有的秩序在運行著。在這種思維下，很容易產生像「CMMI對軟體開發的成熟度分為五種等級，那麼當然是等級愈高愈好」的認知。
對一名程式員而言，當管理者對於開發流程是如此看待時，那無疑是一場災難。此時，建立開發流程的目的，是在於打造一個從管理面來看「看似井井有條」的完整制度時，便不再是針對開發本身的目的去建立流程。
在開發流程中勢必投入的一些活動，而這些活動並不是撰寫程式碼，因此，嚴格來說，不算是對最後產出有直接貢獻的活動。因此，從某種角度來看，這些活動也算是一種額外的成本。
但事實上這樣的成本，其實算是一種投資，因為我們希望透過這些活動的進行，能夠達成引入開發流程的原始目的，也就是縮短開發時程、減少投入的人力及資源，維護良好的品質等等。既然是投資，總不會希望投入的成本大過於最後能回收的收益吧？但事實上，許多團隊施行他們所選用的開發流程後，不僅未蒙其利，反而身深其害。這其中的原因又是在那邊呢？問題終究還是因為許多工作僅僅只是表面功夫，徒具形式罷了。
舉例來說，許多流程設計了需求規格文件的撰寫工作，而這個工作有一個重要的目的，也就是記錄、描述規格使用者的需求。達成這個目的後，開發團隊便可以依據這份文件，理解使用者心目中所想像的系統，究竟是長成什麼樣子。而使用者可以憑藉著這份文件，去了解開發團隊在一次或多次的需求訪談��程中，他們所理解的系統，究竟又是長成什麼模樣，並且可以進一步的進行確認。
這樣的文件，對開發來說，當然是相當重要的一份文件。許多專案的開發，之所以遇到瓶頸，最終都是源自於需求管理上的問題。需求管理的基礎是了解需求，而了解需求代表必須和使用者對於系統的最終產物建立起共識。倘若缺乏了這一層共識，開發團隊自己開發自己想像中的空中樓台，等到使用者開始進行測試時，才驚而不喜的發現，原來開發團隊開發的系統，竟然不是自己想要的。這時候，就得花費更多的力氣來進行矯正。你可以想像，之後必須要付出的代價究竟有多高昂了。所以，需求訪談的活動、需求規格文件的撰寫、以及需求規格文件的確認，算是我們對於開發的一項投資。沒錯，它是會帶來額外的人力負擔，但它所預期帶來的回報，便是開發團隊得以降低日後因為沒有精確掌握需求所付出更為驚人的人力消耗。
但是，一般來說，我們所看到的，大多是徒具形式的需求規格文件。他們或許排版整齊，看起來該有的章節一應俱全，但很可惜的，因為撰寫的人並不是以詳實記錄使用者需求並做為與開發團隊溝通為基礎的方式來進行撰寫，他不過只是依據著文件的樣板，一個蘿蔔一個坑的填些東西進去，讓這份文件看起來像是樣樣俱全（這實在是我們時常可以觀察到的殘酷事實）。但這份文件之所以需要存在的真正目的，除了記錄之外就是溝通－不僅要完整、精準描述欲開發的系統長相，更要藉此減少使用者和開發團隊的認知差異。
但徒具形式的文件，卻無法達成上述的目的。這麼一來，撰寫的人花了大量的時間撰寫這份文件，這份文件卻發揮不了它應該要發揮的效果。開發團隊花費了成本，卻無法回收投資。
徒具形式是最可怕的，因為它比不去做還要糟糕。而一些團隊在施行開發流程時，很容易陷入徒具形式的陷阱中，他們講究要去執行流程中所規劃的活動，以便讓他們看起來像是極具制度化的在運作著。例如，他們執行流程中所規範的文件撰寫活動，但卻又不去理解流程中之所以規劃此一活動的真正用意，最後的產出，不僅不能讓這份文件發揮溝通的效果，而且還白費了力氣及時間。這對於生產力、以及開發預算都是很大的傷害。
這或許正是許多開發人員，對於「開發流程」多半有著一些錯誤觀感的原因之一。事實上，開發流程是輔助開發團隊的工具，而不是障礙。倘若，對開發團隊構成了障礙，那麼，勢必需要認真思考，究竟是在那一個環節出了差錯了。
Posted at 12:26上午 五月 13, 2009 by Chien-Hsing Wang in General | 迴響[3]
如果學長的文章中，再加上『調適』這種概念，就更完整了。
由...發表 Rick Wang on 五月 13, 2009 at 11:42 上午 CST #
這位學弟是清華碩士班的王姓學弚嗎？ :)
由...發表 Qing on 五月 13, 2009 at 01:51 下午 CST #
Qing 兄
好久沒有接受你的觀念洗禮,最近看到微軟的mobile活動,你會主講一場,才想到先來拜讀一下你的文章,讓自己的腦袋洗滌一下,企業間的資訊開發我想八成以上都在進行無效的工作,然這是因循已久的積弊,畢竟上位者多的是停留在過去的觀念行為,少的是接觸觀念改造,雖無奈,卻也得屈就現實啊
yusco IT
由...發表 Tiny on 六月 15, 2009 at 02:58 下午 CST #