軟件開(kāi)發(fā)項(xiàng)目管理實(shí)施方案-免費(fèi)閱讀
【正文】 版本控制 版本控制也是項(xiàng)目管理者的一個(gè)重要工作內(nèi)容之一，一個(gè)項(xiàng)目或產(chǎn)品的完成不可能是一步到位的，在項(xiàng)目完成的后期可能會(huì)有多個(gè)不同的版本的發(fā)布（開(kāi)發(fā)版本，測(cè)試版本，發(fā)布版本等）。我們常在會(huì)議上聽(tīng)到有人說(shuō)：大家討論了這么半天，結(jié)論呢？。比如：本次會(huì)議是一個(gè)需求確認(rèn)會(huì)，而非需求討論會(huì)， 主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。提前發(fā)出會(huì)議議程，以便會(huì)議參與者知道他們來(lái)做什么。以下是組織會(huì)議時(shí)應(yīng)該注意的問(wèn)題，也可看作組織會(huì)議的最佳實(shí)踐。好的高效的團(tuán)隊(duì)不是管理出來(lái)的，而是營(yíng)造出來(lái)的。這也將是考驗(yàn)一個(gè)項(xiàng)目管理者的經(jīng)驗(yàn)和知識(shí)對(duì)能否管理好風(fēng)險(xiǎn)至關(guān)重要的內(nèi)容。如何減少此類風(fēng)險(xiǎn)的發(fā)生？在項(xiàng)目開(kāi)始前的技術(shù)評(píng)估階段，明確技術(shù)難點(diǎn)，提前安排人員進(jìn)行攻克。返工是項(xiàng)目組最不愿意看到的，既浪費(fèi)人力、物力和財(cái)力，又影響團(tuán)隊(duì)積極性。在分析設(shè)計(jì)階段的中的確認(rèn)和評(píng)審也是降低此類風(fēng)險(xiǎn)的重要手段。針對(duì)用戶提出的新需求，按照正式流程提出變更申請(qǐng)，組織相關(guān)團(tuán)隊(duì)成員進(jìn)行分析及評(píng)估，作為是否實(shí)施的依據(jù)，變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷是否批準(zhǔn)，如果批準(zhǔn)，那項(xiàng)目組可以安排實(shí)施，否則，正式拒絕用戶的請(qǐng)求，當(dāng)然實(shí)際情況下可以采取一些軟措施緩解矛盾。項(xiàng)目不同于日常任務(wù)，它有明確的起止時(shí)間和目標(biāo)，要在明確的范圍、時(shí)間和成本約束下，達(dá)到相應(yīng)的質(zhì)量標(biāo)準(zhǔn)，并取得用戶的滿意。測(cè)試人員修改測(cè)試用例的相關(guān)內(nèi)容。所以需求變更的決策者應(yīng)該由項(xiàng)目管理者承擔(dān)。需求變更流程：確定需求的基準(zhǔn)線。需求變更管理 需求變更管理也是項(xiàng)目管理中最重要的一個(gè)環(huán)節(jié)，對(duì)需求變更管理的有效性將直接影響項(xiàng)目的成功與否。 代碼講解完畢后，代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。對(duì)于時(shí)間周期比較長(zhǎng)的任務(wù)，盡量將任務(wù)通過(guò)再細(xì)分的手段細(xì)化任務(wù)，爭(zhēng)取每個(gè)任務(wù)的最長(zhǎng)時(shí)間不超過(guò)3天；時(shí)間周期越長(zhǎng)的任務(wù)，不確定性越高，風(fēng)險(xiǎn)也越高，越有可能成為項(xiàng)目的瓶頸，影響項(xiàng)目的進(jìn)度。 B、技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。該模塊技術(shù)實(shí)現(xiàn)上是否有技術(shù)難點(diǎn)；這里所謂的技術(shù)難點(diǎn)定義是：在現(xiàn)有系統(tǒng)中還未實(shí)現(xiàn)的、開(kāi)發(fā)人員自身也未沒(méi)接觸過(guò)的技術(shù)。上線后監(jiān)控?cái)?shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問(wèn)題，及時(shí)進(jìn)行BUG FIXED及改進(jìn)或做補(bǔ)丁升級(jí)。該階段完成后的成果：確認(rèn)后的最終軟件需求規(guī)格說(shuō)明書(shū)文檔。跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。 項(xiàng)目管理實(shí)施方案 作為一個(gè)項(xiàng)目管理者，如何要成功的做好項(xiàng)目管理；首先必須先要明白的是在特定的領(lǐng)域中賦予這個(gè)角色所要實(shí)現(xiàn)的目標(biāo)、承擔(dān)的職責(zé)、以及項(xiàng)目管理者的具體工作內(nèi)容是什么？ 從我個(gè)人的淺見(jiàn)和角度以及我們所從事的IT領(lǐng)域來(lái)分析回答以上三個(gè)問(wèn)題。積極解決項(xiàng)目過(guò)程中出現(xiàn)的問(wèn)題和沖突。分析設(shè)計(jì)階段根據(jù)確認(rèn)后的軟件需求規(guī)格說(shuō)明書(shū)，制定項(xiàng)目進(jìn)度計(jì)劃，工作任務(wù)分解(WBS)；資源申請(qǐng)，項(xiàng)目涉及到的開(kāi)發(fā)資源、測(cè)試資源、設(shè)計(jì)資源(包括人員和軟硬件資源)；數(shù)據(jù)庫(kù)設(shè)計(jì)；系統(tǒng)設(shè)計(jì)；文檔(包括Use Case、Demo系統(tǒng)原型、Test Case等)；評(píng)審會(huì)議。結(jié)束階段 產(chǎn)品交付，項(xiàng)目總結(jié)會(huì)。對(duì)于這樣的難點(diǎn)，開(kāi)發(fā)者沒(méi)有相關(guān)的代碼可以參考，自己也沒(méi)有經(jīng)驗(yàn)，所以需要投入一些時(shí)間研究解決。 C、業(yè)務(wù)邏輯比較復(fù)雜的由對(duì)這塊邏輯比較了解的人負(fù)責(zé)。Code Review Code Review是保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié)，在這一環(huán)中我們公司做的非常欠缺，把關(guān)不嚴(yán)格；這是導(dǎo)致每次測(cè)試后出現(xiàn)大量bug的主要原因，這一環(huán)需要納入績(jī)效考核中，實(shí)行責(zé)任追究制，實(shí)施重點(diǎn)監(jiān)控。代碼需要一行一行靜下心來(lái)看。 對(duì)待需求變更的態(tài)度：需求變更是不可避免的。將以User Case作為需求基準(zhǔn)線，在User Case確認(rèn)之后的任何需求改變，都需要走需求變更流程，這一環(huán)節(jié)我們基本沒(méi)有，期間有時(shí)候使的工作很混亂，也就是因?yàn)闆](méi)有一個(gè)規(guī)范的變更流程而造成的；如果建立了這么一個(gè)流程規(guī)范和機(jī)制，需求變更沒(méi)有走這個(gè)流程的將不被認(rèn)可。需求變更確認(rèn)后由專人將需求變更記錄下來(lái)，通知給項(xiàng)目中所有成員。開(kāi)發(fā)人員修改代碼中的相關(guān)部分。影響項(xiàng)目成敗的因素涉及方方面面，并且風(fēng)險(xiǎn)伴隨著項(xiàng)目的始終，是客觀存在的，作為一個(gè)項(xiàng)目管理者，應(yīng)該具備良好的風(fēng)險(xiǎn)控制意識(shí)
醫(yī)療健康相關(guān)推薦
鄂ICP備17016276號(hào)-1