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