做程序2年多了,相比大牛來(lái)說(shuō),時(shí)間不長(zhǎng)!
做一個(gè)小小的總結(jié)!
問題現(xiàn)狀,
目前國(guó)內(nèi)很多軟件公司還是處于小作坊式的工作模式!
接到個(gè)項(xiàng)目,大家湊一起商議下怎么做,老大拍板決定后,大家分頭行動(dòng)!
于是一個(gè)項(xiàng)目開始了,前期大家忙的不亦樂乎!
每個(gè)人都有自己的工作, (有的公司分配不均的,如果有閑著的人說(shuō)明管理有問題)
有的干脆就是一個(gè)人接管一個(gè)項(xiàng)目!
隨著時(shí)間的改變,代碼越來(lái)越多,bug也越來(lái)越多,更要命的客戶說(shuō)得加個(gè)功能,更更要命的是客戶說(shuō)功能得改!
一個(gè)人接項(xiàng)目的到了后期基本上就撐不住了.加班能搞定就是燒香拜佛了!結(jié)果就是項(xiàng)目失敗.錢收不到.
團(tuán)隊(duì)接的,后期基本上是加班不斷!牢騷一大片啊! 結(jié)果基本上是錢能收到或者只能收到一部分,客戶牢騷不斷!
如果你的公司有以上現(xiàn)象的,說(shuō)明你的公司需要change
哪里需要change? 開發(fā)流程需要change
跟各位看官討論個(gè)問題,
到底是什么決定了軟件項(xiàng)目的成功或失敗,又是什么決定了軟件的質(zhì)量?
下面的先別看,自己先想一下,待會(huì)再看,看看是不是和我想的一樣!
我前幾天看軟件考試大綱中共分3個(gè)高級(jí)的級(jí)別
分別是項(xiàng)目管理.系統(tǒng)分析師,軟件構(gòu)架師
看到這里我豁然開朗,原來(lái)國(guó)家大綱的劃分是有道理的,我以前一直不認(rèn)為it證書有什么用.(現(xiàn)在看也還是沒啥用,背背書就會(huì)的東西,做起來(lái)大眼瞪小眼)
說(shuō)下我的看法,
項(xiàng)目管理者決定了軟件項(xiàng)目的按時(shí)完成, 項(xiàng)目管理者負(fù)責(zé)軟件開發(fā)任務(wù)的分包安排,物資和人力調(diào)度,等等一切資源的調(diào)配,目的只有一個(gè),按計(jì)劃完成項(xiàng)目!
系統(tǒng)分析師應(yīng)該是第一個(gè)接手項(xiàng)目的人,這個(gè)人很重要,重要到直接決定了這個(gè)項(xiàng)目的成敗.如果系統(tǒng)分析師分析錯(cuò)誤,分析出了一個(gè)不正確的需求.結(jié)果....
系統(tǒng)分析師的要求比較高,程序可以不寫,但是最起碼知道有哪些方案,知道軟件怎么實(shí)現(xiàn). 系統(tǒng)分析師有點(diǎn)看似重要卻又是個(gè)程序員都能干的職位!
但是有幾點(diǎn)要求是程序員做不到的
第一,溝通能力應(yīng)該非常非常的好,不然怎么和客戶溝通?
第二,有點(diǎn)程序經(jīng)驗(yàn),能總結(jié)出實(shí)際需求!挖掘出真實(shí)需求,避免需求偏離! 如果這一點(diǎn)做不到,還不如不要系統(tǒng)分析師!
第三,親和力或者領(lǐng)導(dǎo)力還有說(shuō)服力比較高!
項(xiàng)目通過(guò)系統(tǒng)分析師分析后要確定哪些東西呢?
第一,系統(tǒng)要實(shí)現(xiàn)哪些功能. (確定后要客戶簽字,增加或者變更需求是要收費(fèi)的!!^V^)
第二,每個(gè)功能的重要次序
第三,每個(gè)功能實(shí)現(xiàn)的意義
第四,每個(gè)功能的詳細(xì)說(shuō)明.說(shuō)清楚是這樣的而不是那樣的?最重要的是說(shuō)明不是那樣的!
第五,用例圖(UML中的第一種圖)確定
第六,軟件價(jià)格基本上確定個(gè)差不多了.
第七,分析系統(tǒng)可能會(huì)變的地方,還有"必定會(huì)變"的地方(把變更扼殺在系統(tǒng)分析階段.一個(gè)好的系統(tǒng)分析員應(yīng)該能夠分析出哪些需求會(huì)變)
第八,砍掉不合理或者不重要的需求.
到現(xiàn)在為止我們的項(xiàng)目要不要接已經(jīng)能確定了.多少錢也確定個(gè)差不多了!
需求還不確定,千萬(wàn)不要報(bào)價(jià).否則只有賠本!
建議項(xiàng)目確定后先讓客戶交一點(diǎn)需求分析費(fèi),系統(tǒng)分析出來(lái)后,自己報(bào)價(jià)方便,客戶付錢放心!
系統(tǒng)分析師和客戶的交流應(yīng)該建立在用例圖上,用例圖本來(lái)就是給客戶看的.
說(shuō)到這里,各位要注意了,不要小看用例圖,一定要保存好哦,后面每個(gè)人都用得到!
客戶看到用例圖也愿意付錢,嘴巴說(shuō)的過(guò)會(huì)就忘了!俗話說(shuō)空口無(wú)憑,白紙黑字的才放心!
下面的工作重點(diǎn)轉(zhuǎn)到軟件構(gòu)架師了
軟件構(gòu)架師做什么呢?
確定采用技術(shù)框架,環(huán)境,系統(tǒng)框架等等.
軟件構(gòu)架師需要作出那些東西呢?
第一,系統(tǒng)總體的說(shuō)明,1頁(yè)word文檔夠了,多了嫌煩.
第二,系統(tǒng)的運(yùn)行環(huán)境和硬件設(shè)備,網(wǎng)絡(luò)環(huán)境
第三,系統(tǒng)的總體架構(gòu)和部署方案,(比如:MVC結(jié)構(gòu),5層結(jié)構(gòu),代理結(jié)構(gòu)...)
第四,系統(tǒng)詳細(xì)設(shè)計(jì)方案.分解技術(shù)實(shí)現(xiàn)方法.
第五,系統(tǒng)數(shù)據(jù)格式示例, 各功能模塊之間或各層次之間的接口,通訊數(shù)據(jù)格式
//這一步是為了方便程序同步開發(fā)和分發(fā),而且縮小了技術(shù)范圍,降低了程序的耦合度, 測(cè)試人員可以根據(jù)這些接口和數(shù)據(jù)格式寫單元測(cè)試. 當(dāng)然增加了系統(tǒng)的集成問題
第六,如果遇到特別辣手的技術(shù)問題還需要讓大家明白解決方法!
這里要說(shuō)明一點(diǎn),無(wú)論是用"文檔" 還是用 "圖" 或者"會(huì)議錄像",只要構(gòu)架師的概念能夠讓組員能夠全部理解吸收就算達(dá)到目的,考慮到以后維護(hù)方便和程序員通常不會(huì)寫文檔和畫圖 還是會(huì)議錄像比較容易接受. 會(huì)議錄像不必每次都錄, 構(gòu)架師在不能確定技術(shù)方案時(shí)肯定是要和其它程序員探討的.這個(gè)不需要錄 . 只需要記錄構(gòu)架師決定方案后向大家宣布決定的會(huì)議
下面的工作重點(diǎn)轉(zhuǎn)到項(xiàng)目管理者了,下面的步驟才應(yīng)該算是瀑布模型或者敏捷開發(fā)的起點(diǎn).
傳統(tǒng)的將瀑布模型將前面的需求分析放進(jìn)瀑布中是不合理的
項(xiàng)目管理者在接手到這個(gè)項(xiàng)目后,該做什么呢?
第一,配置資源,包括硬件,人力,財(cái)力,物力.還有客戶資源.
第二,劃分模塊,模塊分解,分包.分清初次,指定開發(fā)任務(wù)時(shí)間表 //建議采用敏捷模型安排進(jìn)度表,每周|月提交一次產(chǎn)品,時(shí)間太長(zhǎng)不好.太短也不好
第三,將合適的模塊分給合適的員工,技術(shù)無(wú)法達(dá)到時(shí),需要聘請(qǐng)技術(shù)高手做技術(shù)指導(dǎo),
//這里要說(shuō)明一下, 如果項(xiàng)目技術(shù)問題比較辣手應(yīng)該提前考慮聘請(qǐng)專業(yè)技術(shù)指導(dǎo)員.以作決策.而且技術(shù)指導(dǎo)員可以抵抗技術(shù)風(fēng)險(xiǎn). 技術(shù)指導(dǎo)員是把好的阻擊槍,但不是萬(wàn)能的,不要把技術(shù)員當(dāng)沖鋒槍用!技術(shù)員是用來(lái)配合的!用來(lái)解決技術(shù)難題的!另外還可以幫助軟件構(gòu)架師做決策,做產(chǎn)品創(chuàng)新!
說(shuō)到這里,各位實(shí)習(xí)生可能要喝彩了,自己不會(huì)也可以的啊!是的,按照這種流程下去的話,即時(shí)不會(huì)的話,也有人做技術(shù)指導(dǎo). 新手得到鍛煉,產(chǎn)品得以開發(fā),質(zhì)量得到保證.我們目前的情況是要求每個(gè)程序員都是高手,豈不知這樣是有問題的,高手要寫代碼的話,思緒很專一不好打擾的. 每個(gè)人都是高手,每個(gè)人都有自己的一套方案!結(jié)果就是倆字 ----混亂. 新手有新手的好處. 老手有老手的好處! 新手是沖鋒槍, 老手是狙擊槍! 各有各的用途!
安排錯(cuò)了就看運(yùn)氣了!
第四,合理安排測(cè)試時(shí)間,發(fā)布時(shí)間.
第五,管理好項(xiàng)目文件,項(xiàng)目資源. 包括源代碼,源代碼數(shù)據(jù)庫(kù),數(shù)據(jù)庫(kù),硬件,網(wǎng)絡(luò),操作系統(tǒng),文件,運(yùn)行環(huán)境,與系統(tǒng)相關(guān)的各種資源理論上應(yīng)該都做備份!
第六, 給各位員工-->端茶倒水. ^V^
下面這個(gè)項(xiàng)目到了實(shí)際開發(fā)階段,
這一步大家都在做不用我說(shuō)怎么做了吧?
咳!咳!
我還要羅嗦兩句
從設(shè)計(jì)師哪里拿來(lái)的接口和數(shù)據(jù)格式,還有需求 只能模糊的告訴我們要做成什么樣!
不能明確的告訴我們需要幾個(gè)按鈕,需要什么控件.需要什么樣的界面. 采用樹形控件還是下拉列表,這些是需要每個(gè)程序員決定的!
根據(jù)我的經(jīng)驗(yàn),在開始寫程序之前先畫個(gè)界面,或者先寫個(gè)測(cè)試程序,將會(huì)有效的提高你的開發(fā)速度!降低程序開發(fā)失誤率!
而先畫界面的好處是可以把界面設(shè)計(jì)專門獨(dú)立出去由專業(yè)的用戶體驗(yàn)設(shè)計(jì)者來(lái)設(shè)計(jì)界面. 軟件的用戶評(píng)價(jià)將會(huì)大大提高!
到了這里大家應(yīng)該會(huì)豁然開朗了吧,原來(lái)測(cè)試驅(qū)動(dòng)開發(fā)是在這里用的,用戶體驗(yàn)設(shè)計(jì)也是在這里用的!
根據(jù)項(xiàng)目管理者的安排,每周|月發(fā)布一次產(chǎn)品.(敏捷開發(fā)模式)敏捷模式有啥好處? 我就不說(shuō)了,太多了.!^V^
經(jīng)過(guò)一段時(shí)間后,項(xiàng)目逐步得到完善!
OK當(dāng)所有主要的功能完成時(shí),一個(gè)里程碑完成了.項(xiàng)目經(jīng)理過(guò)來(lái)備份下
主要功能完成后,不要急于開發(fā)剩下的,先停一停,走的太快容易跌倒.
開開反省大會(huì).寫一下說(shuō)明文檔,先讓用戶測(cè)試一下,發(fā)現(xiàn)bug及時(shí)修改.
該重構(gòu)的及時(shí)重構(gòu).該刪除的及時(shí)刪除!該patch的patch
用戶極度不滿意的話,損失也小一點(diǎn).
或者重來(lái)或者放棄!
發(fā)現(xiàn)需求變更的時(shí)候,大家的磚頭一直朝向系統(tǒng)分析師,不敢的話拍自己吧!
發(fā)現(xiàn)代碼大部分只是Copy 的時(shí)候,大家趕緊停下,磚頭拍向軟件構(gòu)架師,現(xiàn)在不拍到時(shí)候拍的是自己!
發(fā)現(xiàn)數(shù)據(jù)庫(kù)連不上了,網(wǎng)絡(luò)不通了,鍵盤壞了,沒茶沒水了...大聲呼叫"管理員"
如果被客戶發(fā)現(xiàn)了你的bug,就是老板拍你的時(shí)候了!
聯(lián)系客服
