目前實施項目規(guī)范的考慮  

由于目前軟件開發(fā)實際情況的約束，完全按照RUP實施項目管理是一個理想化思路。在實際實施中會受多方面的影響（如客戶要求、小組成員素質等），這種盲目的追求標準只會做成項目的阻礙，基于這種考慮，我認為根據(jù)實際情況采用分步實現(xiàn)的方式，逐步建立起一支穩(wěn)定的、技術分工合理的開發(fā)TEAM，才能采?UP管理規(guī)范實現(xiàn)省時、合理的軟件開發(fā)。

下面我根據(jù)自身對項目管理的認識，對原有項目管理中的問題進行總結，并對目前如何實現(xiàn)軟件工程，及對本項目管理規(guī)范的實施進行了相應說明。
4.1. 對項目管理的幾點感受

目前我們的軟件開發(fā)多為瀑布式開發(fā)，項目管理可以說是沒有。所有的管理與軟件設計都是由項目經(jīng)理一個人來負責，這樣對項目經(jīng)理的要求較高。項目開發(fā)主要依賴于個人能力，開發(fā)中又總是依靠程序員高手來支撐，好是要有一批“快槍手”。而高手又因為多種因素不能集中在一個項目中，同時高手的流動會給項目致命的打擊。以上等等只是項目管理中的一部分問題。我對項目管理中之不足歸納為以下幾個方面：

4.1.1.人員素質

項目開發(fā)人員的個人素質不同，根據(jù)素質進行角色與行為劃分是項目管理中的一個非常重要的環(huán)節(jié)。

責任心

我在項目管理中曾遇過這樣一種情況，有個項目成員技術不錯，但是在開發(fā)的關鍵時期為個人的一點小事而不顧整個項目的進度，而其在項目中擔任了比較重要的職務，在他看來，項目不如自己個人的小事（可做可不做）重要，所以造成項目進度的延誤，我不得不去物色另外一個人來代替他。但后果已成。

還有一種情況，安排了某人工作，工作量在你的估算內，但是到了檢查時，他對你說“我不會做”，“我不知如何做”之類的話，而同時他還在上網(wǎng)或做其他的事，但作為已有計劃的你來說，則是項目進度被打亂的后果。

這種人當然在下一個項目不會被用，但是如何避免這種情況的發(fā)生呢？我認為應當將工作量細化到天甚至于小時，遇到這種員工則可立即開除，同時損失的工作時間是可控的。從而減輕了對項目開發(fā)的影響。

個人能力

程序員的領悟力各不相同。對不同的人要采用不同的方法來工作。

對個人能力高的人你可以務虛的談工作任務，他在接受任務的同時可以提出這樣那樣的問題，甚至想到你沒有想到的問題，直到把問題搞清楚。這樣的人你可以放心的讓他去做，因為他已經(jīng)完全理解了你的意圖。

對個人能力一般的人，你講什么他不能理解的很清楚，有的為了面子不懂也不說，但是在做的時候出了問題，在你指著他做的程序大罵的同時，你的項目進度在拖延。對于這種情況，你只能寫出對他工作的要求，寫出你的意圖，明確工作目標。

對個人能力差的人你不能說只是寫個要求行的，那樣的話他寫的程序依然會讓你忍無可忍，怎么辦，把系統(tǒng)中技術要求較低的部分分出來，然后按1，2，3，4步驟寫出來。有人說這樣還不如自己寫完算了，但是這種工作往往是重復量很大。如做界面等。

當然，RUP的實施方針希望是淡化個人力量，而注重流程與大家的協(xié)作，同時細化了系統(tǒng)的每一部分。但是的實施不能教條化，在實行中還要根據(jù)項目實際情況而變化。

自我約束能力

自我約束能力主要是指對管理者而言的。因為項目成員工作基本是由項目管理者來監(jiān)督實施的，那管理者呢，可能沒有人來管理，如果管理者的自我約束能力不強，那樣建立什么樣的軟件工程規(guī)范都無法實施。

在實施項目管理規(guī)范時，由于條件限制，不可能一下完備軟件工程所需的各個機構部門，從而也可能不存在與項目組平行的流程管理機構，質量審批機構等。由于采用逐步實現(xiàn)的方法，所以提高約束力只能采用其他方法。

針對這種情況，可以采用各種提醒方式：電子系統(tǒng)如掌上電腦；人員提醒如部門技術秘書等。

4.1.2.            工作流程

4.1.2.1             工作流程中的多重循環(huán)

用戶需求的不斷變化是令項目開發(fā)中頭痛的問題了。我們在做項目時傳統(tǒng)的做法是，新需求來了，趕快叫程序員們改，在這里加一塊，那里補幾行代碼，只要實現(xiàn)行。結果是項目做完了，再看自己設計的系統(tǒng)已面目全非。還談什么可重用性，可定義性，產(chǎn)品化，甚至下一個差不多的項目還要花費同樣的時間。

RUP中強調的循環(huán)概念 是針對于這種情況提出的，通過項目小組之間各種角色的循環(huán)，實現(xiàn)對用戶需求變化的問題解決。如下圖

這樣采用迭代法開發(fā)可以實現(xiàn)此問題，是的，但是要有所犧牲，那是時間。時間充足我們自然可以按照標準的RUP思路來進行。而實際上呢，又是我們犧牲不起的�，F(xiàn)在國內大多數(shù)項目具有這樣一個共同點：用戶要求急。如我們做一個基金的核心業(yè)務系統(tǒng)，用戶說開發(fā)時間為兩個月。而由于基金是個新行業(yè)，無可用之部件，兩個月的時間是不可能進行迭代開發(fā)的。同時我們還要在一定程度上避開需求不斷變化。我建議采用的方式如下：

按階段地進行循環(huán)

實現(xiàn)階段性的循環(huán)，并且存在多個循環(huán)的并發(fā)。如業(yè)務需求循環(huán)在一個階段內將生成相應的模型與業(yè)務需求文檔，并得到用戶的認可，然后轉入系統(tǒng)需求循環(huán)，在系統(tǒng)需求轉入另一個循環(huán)時，再繼續(xù)業(yè)務需求循環(huán)，但此時只是記錄用戶需求，而不進行下一個循環(huán)。待根據(jù)初需求制作的版本生成后，再根據(jù)新的業(yè)務需求及與用戶協(xié)商結果再決定是否開發(fā)下一個版本。

采用快速原型法

快速原型法的作用是為了讓用戶在感性上了解系統(tǒng)的概貌，通過與用戶的交流，從而固定了相應的元素（如輸入?yún)��?shù)、跳轉順序等），通過快速原型法與用戶進行交流，能很好的理解用戶的意圖與需求，是縮短開發(fā)周期的良好途徑。

生成一個版本

用戶需求是不斷變化的，而且任意性很大，如果一個項目根據(jù)用戶需求的變化而變化，那么開發(fā)周期是無法估量的。一個三個月開發(fā)周期的項目做了六個月，還沒有一個象樣的系統(tǒng)出來，用戶則不斷的埋怨開發(fā)力度不夠，管理不好等，項目組又認為是用戶隨意性太大，導致了這種后果。結果是雙方互不滿意。

根據(jù)這種情況，我認為在業(yè)務需求循環(huán)到一個階段，生成正式的業(yè)務需求文檔與模型，并得到用戶的認可后，則進入下一個循環(huán)。以至于生成一個版本。這樣由于存在這樣的版本，用戶則不能將項目的延遲歸于項目組。而項目組也存在一個完整的版本管理體系。