軟體過程的發展的思考 (轉)

軟體過程的發展的思考 (轉)[@more@]

  從泛義上來說, 專案開發可以分成以目標為中心或以過程為中心。

以目標為中心的專案開發可以為達成目標而不擇手段或者說不採用任何手段， 只要最後專案成功,專案人員可以使用任何辦法。而以過程為中心則以過程為主要依據,要求過程步驟完美,最後結果如何都是成功的專案。按儒家的中庸說法, 兩種觀點看起來都是不正確的, 能夠相互補充那時最好了。

  首先, 軟體專案剛剛開始出現的時候,人們完全不知道需要如何對付它, 所以那時候是隻能以目標為中心, 採取個人主義,僅僅需要一個人或者幾個人就能完成一個偉大的專案, 當時其中的領導者一定是能力超強, 不僅技術令人折服,而且充滿了人格魅力,管理能力也是必不可少的。這樣可以說靠著他一個人的能力和意志帶領著大家完成專案。就像很多傳奇中的研發專案，就是靠著個人能力領導著整個團隊。

 中國的很多中小企業就是這一階段的以目標為中心， 雖然使用了一些先進的工具，但是思路還是沒有脫離原始的狀態。在這樣的公司你往往能聽到這樣的話，“我頭頭說這個東西必須在這個星期完成”。 然後專案就在無序中進行，如果專案有一個傑出技術專家，可能會僥倖成功。但更多都是糊里糊塗的失敗了，但是即使失敗了，很多專案也會被公司當作成功專案，因為沒人願意承認失敗。所以如果去找工作，如果一看要招一個XX高手這樣的人，這個公司一定就是這一型別的公司，經歷過很多次失敗以後，它只能把希望寄託在一兩個高手身上。

  慢慢的隨著業界對軟體的需求越來越大，專案也越來越大，開發人員也越來越多，這種再也無法承受使用了。仍採用這種模式的專案的失敗率也越來越高。然後一些聰明人發明了瀑布模型，從本身看這並非是一個創舉，它把一個大目標分割成幾個小的目標步驟，一個一個次序完成。他們的一小步是人類的一大步，他們開創了一種可行的文化。這樣隨著目標越來越大，越來越細化，模式也從瀑布變成了增量，模型也從以目標為中心轉變成了以過程為中心。理論上，只要把最簡單的瀑布模型每一個步驟都嚴格完成，那麼專案一定會成功。這個時候，軟體業也從混沌轉變到了有序的階段。

  國內很多企業做的形似而神不似，專案雖然使用了一些過程，但是這些過程只是用來擺樣子，全無實用價值。在過程中，對各個階段的控制和稽核是最主要的，不然就失去了分階段的作用，其實就是退回到混沌的階段。在很多的專案中，這一階段雖然完成的不好，但是還是會往下面走，原因就是根本沒有認識到為什麼要採用過程方式。

  在過程為中心的開發中，一般來說採用一個適合的過程模型，然後適當的裁剪，我認為是成功係數很高的， 當然需要一個合適理解這個過程的專案經理，很多公司的失敗是因為專案成員並不理解這個過程，只是為了擁有過程而過程。業界的過程模型已經經過長時間的檢驗，如果問題出現了，很大願意是使用的人的對這個過程理解得不夠。

  任何過程都會帶來一個副面的影響：太耗費資源。大家應該深有感觸，過程中的那些文件的確是讓任何人都非常害怕，尤其是對這些文件的維護，更是恐怖。但是這是減少點對點交流的非常好的解決途徑之一。對於這個問題，只有大量採用裁剪，畢竟實用才是大家追求的。人們開始對動不動就是資源消耗極大的過程開始反感，重新開始了對過程的思考。他們希望有特別針對與中小專案的適合的過程，即使是瀑布也太複雜。他們需要在保持一定過程的前提下，採用最為節省資源的做法。保證專案成功並不一定需要繁瑣的步驟，在每一道關口設卡檢查。完全有可能在主要的關口設卡，在內部如何方便通行就採用哪種路線，這樣就能保證能最快最正確的透過。這就是以目標為中心和以過程為中心的結合體。於是XP等新的想法誕生了。

  像任何行業一樣，軟體業也從無序進入有序，有從有序進入了過度繁瑣的有序，然後再從繁瑣進入精簡，進入了實用的有序。在反反覆覆後，我們會看到一個成熟的工業，像其他所有的行業一樣，實用是最重要的。