靈活運(yùn)用開發(fā)項(xiàng)目管理方法論文

1、靈活運(yùn)用開發(fā)項(xiàng)目管理方法論文編者按：本文主要從小型軟件開發(fā)項(xiàng)口中常犯的錯(cuò)誤； 小型軟件實(shí)行項(xiàng)目管理的方法和步驟進(jìn)行論述。其中，主要 包括：小型軟件開發(fā)項(xiàng)目一般具有項(xiàng)目需求相對較少、人員 較少、開發(fā)周期較短的特點(diǎn)、沒有重視項(xiàng)目計(jì)劃，做一天和 尚撞一天鐘、沒有完整的開發(fā)文檔，無意之中增大項(xiàng)目風(fēng)險(xiǎn)、 人員沒有技術(shù)分層，職責(zé)不清分工不明、樹立小型軟件開發(fā) 也需要項(xiàng)冃管理的理念、項(xiàng)冃需求的確認(rèn)、人員角色的安排 和定義、建立合理的開發(fā)流程，注重過程的銜接、重視文檔 化過程、使用好制度與紀(jì)律這個(gè)工具、制度與紀(jì)律對于能否 成功也是至關(guān)重要的等，具體請?jiān)斠姟！菊縤個(gè)企業(yè)的管理，大公司有大公司的方式， 小公司

2、也有小公司的做法。如果把別人的經(jīng)驗(yàn)生搬硬套到自 己身上，可能會適得其反。同樣，管理一個(gè)軟件開發(fā)項(xiàng)目也 一樣，大項(xiàng)目和小項(xiàng)目的方式也完全不一樣。如很多人認(rèn)為 小型軟件開發(fā)項(xiàng)目不需要嚴(yán)格的管理，但事實(shí)上卻恰恰與此 相反，小型軟件項(xiàng)目不單需要進(jìn)行項(xiàng)目管理，而且不能完全 照搬大型軟件項(xiàng)冃的管理方式和開發(fā)模式，應(yīng)該要遵循一種 適合小型軟件項(xiàng)目的管理方式。近期，我在負(fù)責(zé)的一個(gè)小型軟件開發(fā)過程中忽視了小 型軟件項(xiàng)目的特點(diǎn)，結(jié)果是麻煩事情特別多，差點(diǎn)兒項(xiàng)目要 以失敗告終。但從另一個(gè)角度來看，項(xiàng)目的大與小并沒有本 質(zhì)的區(qū)別，很多方法是共通的，但必須要切合實(shí)際來靈活運(yùn) 用。本文結(jié)合我在這個(gè)小型軟件開發(fā)項(xiàng)目中得到的

3、經(jīng)驗(yàn)和教 訓(xùn)，首先分析小型軟件開發(fā)項(xiàng)冃中常見的問題，然后提出相 應(yīng)的解決辦法。一.小型軟件開發(fā)項(xiàng)目中常犯的錯(cuò)誤小型軟件開發(fā)項(xiàng)目一般具有項(xiàng)目需求相對較少、人員 較少、開發(fā)周期較短的特點(diǎn)。因此，小型軟件開發(fā)看起來都 比較簡單，比較容易成功，因而人們往往忽視了小型軟件開 發(fā)的管理，其實(shí)這是一種誤解。例如，由于人員較少就分工 不明確或由于開發(fā)周期較短就忽視項(xiàng)目計(jì)劃和進(jìn)度表的控 制，結(jié)果是經(jīng)常會出現(xiàn)開發(fā)流程混亂，重編碼輕設(shè)計(jì)，甚至 到編碼完成后再回頭編寫各種文檔資料等現(xiàn)象。從我這次的 開發(fā)經(jīng)驗(yàn)看來，在小型軟件開發(fā)管理中最容易犯以下的錯(cuò) 誤：(1) 沒有重視項(xiàng)目計(jì)劃，做一天和尚撞一天鐘往往由于項(xiàng)目較小，便

4、很草率地制定一個(gè)開發(fā)h程表, 也沒有認(rèn)真地估計(jì)項(xiàng)目難度，結(jié)果是實(shí)際完成時(shí)間與估計(jì)完 成時(shí)間往往有較大差別。還有人是這樣說計(jì)劃的：”計(jì)劃、 計(jì)劃，紙上畫畫，墻上掛掛，計(jì)劃不如變化”。因此，由于 觀念的不正確使到計(jì)劃管理經(jīng)常成為空話，特別是在小型軟 件開發(fā)中影響計(jì)劃的因素太多時(shí)或加上想省事怕麻煩，結(jié)果 計(jì)劃管理就形同虛設(shè)了。但是，軟件進(jìn)行項(xiàng)目管理的目的就是綜合各種因素， 制定合理的計(jì)劃，并通過計(jì)劃的實(shí)施，使其規(guī)范化，從而提 高人員效率，降低項(xiàng)冃成本。因此，軟件開發(fā)無論項(xiàng)冃大小, 其實(shí)都需要計(jì)劃過程。只是對于小型軟件項(xiàng)目來說，計(jì)劃階 段可能切換的很快。例如，有時(shí)候項(xiàng)目負(fù)責(zé)人只是腦海里想 一遍就把計(jì)劃

5、確定了。但項(xiàng)目負(fù)責(zé)人必須心里要清楚：有時(shí) 候想省事兒，可能反而會更加費(fèi)事兒。俗語有云：一年之計(jì) 在于春、一日之計(jì)在于晨。其意義不是說越早做越好，而是 闡述一個(gè)目標(biāo)的實(shí)現(xiàn)需要盡早做規(guī)劃。(2) 沒有完整的開發(fā)文檔，無意之中增大項(xiàng)目風(fēng)險(xiǎn)一個(gè)完整的軟件開發(fā)項(xiàng)目應(yīng)包括有相當(dāng)多的相關(guān)文 檔：例如項(xiàng)目開發(fā)計(jì)劃、軟件需求說明書、概要設(shè)計(jì)說明書、 詳細(xì)設(shè)計(jì)說明書、開發(fā)進(jìn)度月報(bào)、測試計(jì)劃和開發(fā)總結(jié)報(bào)告 等。而在實(shí)際屮，許多小型軟件項(xiàng)目只有簡單的流水帳式的 開發(fā)口志。最常見的借口往往是以文檔滯后來解釋文檔的不 健全，這似乎沒有什么不妥，而且好象還理直氣壯的。但如 果將軟件項(xiàng)目叫做”工程”的話，再將其與建筑工程相比

6、 較，那我們也就可以說：大樓有了，圖紙滯后，這是很可笑 的。還有許多開發(fā)人員認(rèn)為軟件設(shè)計(jì)已經(jīng)在其腦了里完成 了，在其意識里工作就只是一堆需要敲出來的程序，既然能 直接敲得出來，自然沒必要再做寫文檔的重復(fù)工作。這樣做的結(jié)果使到設(shè)計(jì)思路和實(shí)現(xiàn)細(xì)節(jié)在項(xiàng)目團(tuán)隊(duì)內(nèi) 的交流很困難，開發(fā)過程會由于需要大量嘗試性、重復(fù)性工 作而變得緩慢，而且會出現(xiàn)許多意想不到的大大小小的問 題，狼煙四起之時(shí)最重要的工作就變成了”救火”。所以， 在小型軟件項(xiàng)目里會”救火”的技術(shù)人員會成為大家推崇 和依賴的英雄。但這種”救火”式的行為最終結(jié)果卻是項(xiàng)目 延期成了普遍現(xiàn)象，產(chǎn)品質(zhì)量也得不到保證。另外，如果這 個(gè)英雄半途離開，那沒有任

7、何文檔支持的屮間結(jié)果對其它人 來說基本上就是” 一堆垃圾”而已，項(xiàng)目被迫中斷就成了家 常便飯。(3) 人員沒有技術(shù)分層，職責(zé)不清分工不明許多小型軟件開發(fā)項(xiàng)目一直采用個(gè)人主義式的開發(fā)方 式，決定了規(guī)范化開發(fā)方式的不被認(rèn)可。對規(guī)范化管理的淡 漠，抑制了團(tuán)隊(duì)工作效率的提高，甚至扼殺了其牛命。所以, 小型軟件項(xiàng)目往往要求主要的項(xiàng)目人員從各個(gè)方面都得是 非常出色的，不僅要全而地掌握系統(tǒng)架構(gòu)知識、具有業(yè)務(wù)分 析和系統(tǒng)設(shè)計(jì)能力，而且還得是多種流行開發(fā)工具的專家、 數(shù)據(jù)庫的專家、網(wǎng)絡(luò)配置的專家等，但這樣的全才和通才往 往是可遇不可求的。因此，小型軟件項(xiàng)目更需要做技術(shù)分層，例如系統(tǒng)分 析員、需求分析師、程序員、

8、測試員等。在項(xiàng)目開發(fā)中相應(yīng) 的角色必須要有相應(yīng)的專業(yè)人員來擔(dān)當(dāng)，當(dāng)然可依據(jù)項(xiàng)目規(guī) 模大小和現(xiàn)有人員來合理配置。這里強(qiáng)調(diào)技術(shù)結(jié)構(gòu)分層和技 術(shù)人員劃分，更多的是技術(shù)責(zé)任的明細(xì)，而非具體個(gè)人的技 術(shù)定位，將技術(shù)任務(wù)和相應(yīng)的責(zé)任劃分到具體的崗位、將崗 位落實(shí)到具體的人，這與具體技術(shù)人員身兼數(shù)職是不矛盾 的。而我們經(jīng)?？吹降氖窃谠S多小型軟件開發(fā)過程中，人 員職責(zé)不清、分工不明的現(xiàn)象非常嚴(yán)重。有的甚至從調(diào)研到 分析、設(shè)計(jì)，到開發(fā)、調(diào)試，再到測試一氣呵成。先不說工 作量有多大，僅從項(xiàng)目的風(fēng)險(xiǎn)來說就是非?？膳碌?，更不用 說最大限度發(fā)揮開發(fā)人員的長處了。二.小型軟件實(shí)行項(xiàng)目管理的方法和步驟為什么小型軟件開發(fā)項(xiàng)目

9、卻會面臨更多的失敗風(fēng)險(xiǎn)呢? 在我所負(fù)責(zé)的項(xiàng)目面臨下馬前的每一個(gè)夜晚，我的腦袋里一 直在思考這個(gè)問題。也許是多日思考的沉淀，也許是思緒在 不停的四處游蕩后的突發(fā)靈感。使我明白到原來決定小型軟 件項(xiàng)目成敗的核心因素，是有沒有堅(jiān)持進(jìn)行實(shí)行項(xiàng)目管理。 現(xiàn)總結(jié)為以下幾個(gè)要點(diǎn)：(1) 樹立小型軟件開發(fā)也需要項(xiàng)口管理的理念但凡專業(yè)的軟件開發(fā)人員都學(xué)過軟件工程這門課， 縱觀這些指導(dǎo)性的理論以及建議。我們應(yīng)該要樹立即使是小 型軟件開發(fā)也應(yīng)該在一定程度不要違背開發(fā)理論，必須要遵 從于工程化軟件理論的原則和方法，落實(shí)規(guī)范化的管理。否 則，失敗的風(fēng)險(xiǎn)將伴隨著整個(gè)開發(fā)過程，而且越到后期失敗 的可能性會越大。對小型軟件項(xiàng)

10、口而言，最急需的不是設(shè)計(jì)方法，也非 分析方法，當(dāng)然也不是開發(fā)方法，而是管理方法。因此，無 論項(xiàng)目大小都必須要遵循一定的項(xiàng)目管理步驟。從概念上講，軟件項(xiàng)目管理是為了使軟件開發(fā)能夠按 照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成，而對成本、人員、進(jìn) 度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行分析和管理的活動。實(shí)際上，軟件項(xiàng) 目管理的意義不僅僅如此，進(jìn)行軟件項(xiàng)目管理還有利丁將” 英雄”式的開發(fā)人員的個(gè)人開發(fā)能力轉(zhuǎn)化成團(tuán)隊(duì)的開發(fā)能 力，團(tuán)隊(duì)的軟件開發(fā)能力越高，就越能減小項(xiàng)目的開發(fā)風(fēng)險(xiǎn)。(2) 項(xiàng)目需求的確認(rèn)在軟件開發(fā)屮，最重要的活動是要明確項(xiàng)口的范圍、需求和提出至少一個(gè)可用的軟件架構(gòu)方案。在明確項(xiàng)目范圍 的過程中，不能認(rèn)為是小型軟件開

11、發(fā)項(xiàng)目就馬馬虎虎的、想 當(dāng)然的認(rèn)為已經(jīng)了解了客戶的真實(shí)需求。項(xiàng)目經(jīng)理應(yīng)要就項(xiàng) 目的邊界、功能、限制條件等與客戶進(jìn)行協(xié)商，并應(yīng)以需求 說明書和功能說明書的形式把客戶的需求記錄下來，并且和 客戶達(dá)成一致的認(rèn)識和理解。在此基礎(chǔ)上，再提供至少一個(gè) 合適的軟件架構(gòu)方案，并且完成原型系統(tǒng)。原型系統(tǒng)的目的 不但是為了驗(yàn)證技術(shù)上的可行性，而且是為了給客戶一個(gè)感 性的認(rèn)識，更好地完善對需求的理解和確認(rèn)。(3) 人員角色的安排和定義角色定義包括個(gè)人或團(tuán)隊(duì)的行為和職責(zé)，包括設(shè)計(jì)人 員、編程人員、測試人員、項(xiàng)目管理人員和輔助人員。比較 小的項(xiàng)冃往往是幾個(gè)人來完成，這幾個(gè)人基本上從頭到尾參 加開發(fā)。而且由于項(xiàng)目小，項(xiàng)目

12、負(fù)責(zé)人除了負(fù)責(zé)分析、設(shè)計(jì) 和協(xié)調(diào)的工作外，也要參加編程。但在此過程中必須要合理 進(jìn)行人員角色的安排和定義，將技術(shù)任務(wù)和相應(yīng)的責(zé)任劃分 到具體的崗位，再將崗位責(zé)任落實(shí)到具體的人身上，避免推 卸責(zé)任或由不專業(yè)的人馬虎應(yīng)付了事。例如，一個(gè)人可以同 時(shí)擔(dān)當(dāng)幾個(gè)角色，一個(gè)角色也可以市幾個(gè)人來共同承擔(dān)，但 前提都是要有責(zé)任的、有專業(yè)技能的。(4) 建立合理的開發(fā)流程，注重過程的銜接句話形容就是”麻雀雖小，五臟俱全”。也就是說 即使是小型軟件的開發(fā)，仍然應(yīng)該遵循軟件開發(fā)的一般規(guī) 律，必須的步驟和合理的開發(fā)流程還是不能省略。不但要建 立合理的開發(fā)流程，而且還要注重分析與設(shè)計(jì)過稈的銜接。 當(dāng)然，小軟件項(xiàng)目也有它

13、自身的一些特點(diǎn)，實(shí)行起來可以相 對靈活些。例如：要強(qiáng)調(diào)協(xié)調(diào)幾個(gè)人的工作比某一開發(fā)人員完 成一段編碼更重要。因?yàn)樵趨f(xié)調(diào)上出了漏洞，就可能導(dǎo)致很 大的問題。是給每個(gè)開發(fā)人員要有明確的任務(wù)書，也就是 說每個(gè)開發(fā)人員必須非常明確自己的任務(wù)，而且這些任務(wù)是 采用文檔來表示。是要讓每個(gè)開發(fā)人員都清楚自己所做的 工作在整個(gè)系統(tǒng)中處于什么地位，避免各人的代碼編寫完畢 之后又要重復(fù)修改。(5) 重視文檔化過程在小型軟件項(xiàng)目中有兩個(gè)特點(diǎn)：是市于人員少，意 味著不同人員的程序之間交互、接口相對少一些;是由于 人員少，往往是同樣的幾個(gè)人從頭到尾負(fù)責(zé)這個(gè)項(xiàng)目。但這 兩個(gè)特點(diǎn)會讓人容易犯錯(cuò)誤，就是往往是幾個(gè)人碰一下頭，

14、討論一下最皋本的任務(wù)分工便分頭去做自己的工作了，沒有 一份較正式的開發(fā)文檔。當(dāng)有人對任務(wù)理解有偏差時(shí)或有誤 解時(shí)，就可能會造成返工。因此，小型軟件開發(fā)項(xiàng)目也不應(yīng) 該忽視文檔化過程的作用。文檔化有三方面的作用：是有助于團(tuán)隊(duì)溝通，能給 別人一個(gè)交待以及給自己一個(gè)備忘。是有助丁自我理解， 一般來說如果你不能寫下它，你就可能沒有真止的理解它。 是有助于連貫一致性，它會使團(tuán)隊(duì)擁有可重復(fù)的優(yōu)勢。雖 然文檔是如此重要，但在小型項(xiàng)目中有用的文檔最好也不要 太兀長繁雜，一般1-2頁的過程說明就足夠了。(6) 使用好制度與紀(jì)律這個(gè)工具有效的團(tuán)隊(duì)制度與紀(jì)律是非常有利于團(tuán)隊(duì)有序工作 的。也許在一、二十年前經(jīng)常聽到某位大俠單獨(dú)完成了某種 創(chuàng)舉，成了人們崇拜的對象?？山裉爝@種以自我為中心的大 俠已經(jīng)很難有生存空間了，取而代之的是要發(fā)揮團(tuán)隊(duì)力量才 能攻克難關(guān)。因此，軟件開發(fā)雖然是一項(xiàng)創(chuàng)造性的智力活動，但無 可置疑的是制度與紀(jì)律對于能否成功也是至關(guān)重耍的。如果 因?yàn)轫?xiàng)目小、人員少、周期短，在