系統(tǒng)分析師軟件過程概述：過程重要嗎？

來自于 Rational Edge：遵循軟件開發(fā)中一個協(xié)調一致的過程的價值是確定無疑的。但是究竟需要什么樣的過程呢？究竟有多復雜呢？需要什么樣規(guī)模的團隊？Gary Pollice教授考慮到企業(yè)中對多樣化過程的需求情況，詳細回答了這些問題。
在我參加 2006 年敏捷年會，這個會議討論關于方法和技術的問題，之前。我已經(jīng)開始編寫這個月的理論與實踐專欄中的文章，這篇文章是關于測試過程中使用和創(chuàng)建模擬對象的問題的。哦，我聽到你說“天啦，這是唯一關于敏捷的論文。”我可以向你保證這不是我的意圖。我與其他幾個人在這次會議上的觀點介紹與討論使我想到總體過程的問題，以及過程在軟件開發(fā)中扮演角色的問題。

當然，參加會議與沒有參加會議的人們所真正關心的問題是找到能夠幫助他們完成軟件開發(fā)的銀彈。這使我開始明白這次會議討論的中心是組織中特定的成功水平，一個與公司規(guī)模、軟件開發(fā)團隊規(guī)模、以及用來確保成功過程的范圍相關的水平。我開始嘗試將這些挑選出來，并認為我自己已經(jīng)有了幾種有助于思考軟件開發(fā)中過程中角色的方法。

對于初試者來說，當一個小的組織逐漸成長成為一個大的企業(yè)組織時，事情變化了，你的過程也必須相應變化。敏捷社區(qū)夠很快指出了敏捷的基本原則之一就是，它可以反映在你為了改進工作方法所表現(xiàn)的行為上。但是這個原則與RUP中的或者任何一個其他現(xiàn)代的方法中的原則沒有什么區(qū)別。因此就產(chǎn)生這樣一個問題：“過程還重要嗎？”

“過程還重要嗎？”這個問題看起來是一個反問句，尤其是出自于先前的一個“RUP怪老頭”的口中，這是我在離開Rational組織從事理論生涯之前的昵稱。事實上，這個問題只是稍微帶點反問，過程當然重要。有些情況下它是十分重要的――比如當已經(jīng)選擇的過程超過了這個團隊的能力，使團隊不能夠滿足顧客的需求的時候。如果我們將滿足顧客的需求與質量等同看待，那么過程就會對質量產(chǎn)生潛在的負面作用。

或許這樣的問題會更好一點，“特殊的過程重要嗎？” ; 在前一個專欄中我討論了將過程與項目匹配的重要性，定制并裁剪過程以適應一個項目的需要已經(jīng)是目前被公認的軟件開發(fā)最佳實踐。此外，能夠有效支持一個項目團隊或者一個組織的過程并不止一個，可能有很多。我可以設想，幾乎任何過程（不管是否是定義明確的）都會對一個團隊的成功有所幫助。

我認為有兩個主要因素中的任何一個存在，都可能會影響適用于特殊情形過程的數(shù)量：1）團隊的規(guī)模和 2）在大的團體背景中過程的作用范圍。我將調查這些因素，然后考慮過程層面的需求，在較大的組織中存在多個過程。

一個定義

在我們進入細節(jié)之前，讓我們確保對“過程”的概念有一個共同的理解。我將查閱我最喜愛的資源，詞典，然后采用其中的一個過程定義：“一系列將產(chǎn)生結果的行為、變化或者功能�！�2 這是一個簡單的描述性的定義，在我看來，這是過程的本質。過程是我們?yōu)榱送瓿晌覀兊墓ぷ鞫�采取的一系列步驟。它不是我們編寫的如何計劃我們工作的設計，也不是一系列我們必須盲目遵守的規(guī)則。它是我們要做什么，不管是否被記下來，也不管是否被詳細說明。

團隊規(guī)模與溝通

一個有效的過程是支持有效溝通的過程，有效的溝通與項目團隊的規(guī)模是直接相關的。這對任何在不同規(guī)模項目團隊工作過的人來說并不陌生。

對于那些讀者來說他們可能喜歡更嚴格的證據(jù)，僅僅考慮基于團隊規(guī)模的可能有的溝通渠道的數(shù)量。一個兩人項目，A和B，只有一個溝通連接。如果我們增加一個C到這個項目中，我們就有三個溝通連接，A－B，B－C，C－A。當D加入這個團隊時，我們就有六個溝通連接，當加入E時，我們的溝通連接達到10個。一個十人團隊將會有45個溝通連接。由于有如此多的可能性，同步與關鍵信息的傳送就變得相當困難而且容易出錯。

決定溝通連接數(shù)量的公式就是你從數(shù)量n中挑選出配對數(shù)量的公式，不必考慮順序。公式如下所示：

　當我們尋找配對時，它可以減少為

圖1中顯示了一些重要特征，在那你可以看到增長并不是線性的。當你的團隊規(guī)模增長，你需要通過決定捕獲什么信息以及如何捕獲，從而找到溝通渠道公式的方法。

　　圖1. 團隊規(guī)模對溝通的影響：當團隊規(guī)模增長，溝通連接的數(shù)量并不是呈線性增長的。

團隊規(guī)模的大小不僅僅影響到溝通渠道的數(shù)量，它還影響團隊過程的各個部分。一個兩人團隊一起從事于一個小項目會采用一些機制來分配工作，管理他們的資源代碼，給他們的工作歸檔等等。這對工作人員的確不需要很多指導方針告訴他們改如何完成他們的工作。他們幾乎都是告訴對方，一天好幾次地要么親自告訴對方，要么通過電子郵件的方式傳達。的確，這就是溝通，但是來自外界的噪音很少有機會來干擾這個溝通。因為他們只有兩個人，他們不需要將他們的信息提交給一種更持久的形式，就像隱藏在一個工具或者詳細用例描述中的統(tǒng)一建模語言（UML）。幾乎任何“微不足道的”過程都會對他們倆起作用。5