關於軟體開發流程規範,有感於最近做技術顧問(一)
文/何其甚
2018年過年的前幾天,有個老朋友找到了我,說是有個網際網路軟體專案開發了大半年沒有開發完成要我幫忙去看看。當時聽到感覺這裡面事情肯定少不了,因為一個普通的正常的軟體開發專案很少會超過兩個月,更甭提開發了大半年。
抽一天時間和老朋友一起去見了專案方。專案方公司是個新公司,沒有經驗豐富的技術人員,但是老闆著急要做這個網際網路專案。剛開始的時候四處找開發公司,擔心會出現各種開發過程中的問題,最後好不容易經過熟人找到了一家開發公司A,以為是熟人介紹的公司沒什麼好擔心,然後匆忙就開始了開發。開發了一個來月,公司看軟體開發成果,結果可想而知與老闆所想所需的功能大相徑庭,本來裡面就需要的一個輔助功能(網上商城)當成了主體功能。老闆看後自然是十分不滿意,於是繼續找下一家開發公司,最後好不容易又找到了一家,是一家校企合作企業。鑑於前面的教訓,老闆指定了專門的需求人員,為了方便管理便將開發人員劃歸公司所有,承擔員工工資,同時開發公司負責人也打保票絕對包您滿意。然而還得說然而,專案拖了大半年一直到現在也沒有開發完成。老闆最後著了急,拖朋友說趕緊找個技術懂行的,能給我們做技術顧問的,給看看到到是什麼問題。
不知道怎麼七拐八拐,他們找到了老朋友,老朋友就找到了我。到公司後,老闆親自接待了我們,將專案的來龍去脈介紹了一下,然後對我說以你們專業技術的角度快給我分析分析到底是哪裡出了問題。我說這個專案就從當前我瞭解到的內容看,多半有需求描述不清楚的問題,需求不明確,不知道有沒有需求文件,可以給我看看,再有應該就是過程控制涉及技術管理工作不夠,其中可能還有開發人員能力問題,我現在不大好判斷到底是哪裡出現了問題,給我點時間進入你們專案讓我好好看一看了解一下,包括要了解一下開發人員具體情況。老闆當場答應,並說先預支一些顧問費用,等專案上線立即結算剩餘費用。因為馬上要過年了,所以工作接觸只能安排到了年後。
過完年後,我如約到了公司,開始進行專案梳理。
進入專案,首先得到第一個訊息是專案開發很快就能完成,但是並不知道按功能需求已經完成了多少,還有多少沒有完成,估計彙報工作進展一直就是這個樣子,要知道這個樣子的開發進展工作報告基本是句廢話,有經驗的都知道在催促開發團隊時會經常得到這樣的答覆,得到這個答覆感覺真的專案很快就能完成了,其實不然,其中可能不少問題被隱瞞。得到這樣的答覆時候,不用糾結是否有隱瞞(為什麼不用糾結看完全部你就會明白),請一定記住要反問一句具體開發完成時間。開發進展工作要有個時間點,哪怕是個不準的時間點也沒關係,但是一定要有,開發跳票是常見的事情,但是不能因為有跳票,就不能確定一個完成的時間點。因此我當場要求要給出開發完成時間點。開發團隊給出了開發完成時間點,然後我說,開發完成後你們要先自己內測,內測做好BUG記錄,修改完內測BUG要標註修改結果、誰修改的、修改時間和誰檢測的,最後提交內測文件,然後召集所有相關人員進行一次成果演示,具體最終內測完成時間,請開發負責人考慮後當天給我。
很好,開發負責人在當天下午就給出了我內測完成時間。到現在我有了兩個時間點和一個內測時長,功能開發完成時間點、內測完成時間點和內測時長。將時間做好記錄,向老闆及相關同事進行了說明,說明的時候一併說明完成時間只是開發預估的時間可能最終時間還會有出入,但控制這個時間大體是這個時間段。
開發時間確定後,我需要了解具體專案開發的功能有哪些,它到底有哪些開發難度,說不定裡面有一個說起來比較容易但是開發起來比較難的技術點,因此我需要專案需求文件。要知道專案需求文件可是專案開發的最重要依據,不僅僅是技術開發需要確定程式流程以及引數的出處,還是最終專案的驗收依據,要是沒有需求文件或者沒有和當前專案同步的需求文件,結果可想而知。當我提出要完整需求文件的時候,所有同事都有些面露難色,說沒有完整的需求文件, 只有早期的一個文件,還不完整。這個結果其實在我預料之中,專案開發過程中最常遇到的第一個難題就是精準需求,沒有精準需求,而只是一個想法就要去做一個專案,這種做軟體專案的想法真的很危險,這也是很多專案開發週期長的通病。因為只是一個想法,不是精準需求,一旦進行開發發現邏輯不通,最常出現的問題就是需求一日三改,開發在一個功能開發上反覆修改,這種專案要是能正常完成開發簡直見了鬼了。
好吧,沒有完整需求文件。我說把所有現在有的開發相關文件都給我,包括需求文件、程式概要設計文件或者程式詳細設計文件和資料庫設計文件,如果還有其他相關記錄文件也一併給我。很快文件給了過來,需求文件真的很簡單,裡面的描述幾乎都是想法描述,很少見到定性定量描述,真的是夠難為開發怎麼開發的,可以想象的到開發過程中一定打了不少嘴仗;資料設計文件,同樣也很簡單,就是資料庫匯出的表格,一些欄位描述都沒有,這個還好,我最擔心就是資料庫文件不是現在開發進行中的文件,有些欄位變化也可能沒有。
後面如何進展感覺真有點難度,感覺軟體開發過程中坑都要踩一遍,困難也得繼續,一個一個梳理吧。
今天先寫到這裡未完待續。
相關文章
- 探索基於WebRTC的有感錄屏技術開發流程Web
- 關於SQL開發規範中的那些誤區!SQL
- 關於研發規範化的一些思考
- 軟體開發丨關於軟體重構的靈魂四問
- 關於IT,關於技術
- 關於Swap去中心化交易所繫統軟體開發(技術支援)中心化
- 軟體專案研發流程該怎麼規範
- 關於FDF迴圈互助智慧合約技術系統開發搭建流程
- DDD統一通用語言:軟體工程不是關於技術,而是關於溝通軟體工程
- 開發流程規範機制
- 【odoo】關於odoo二開模組規範的一點思考Odoo
- CRM軟體的不同銷售流程規範
- 資料開發流程及規範
- 基於軟體分析的智慧化開發新型服務與技術
- 關於多鏈錢包系統開發技術邏輯及規則(開發原始碼)原始碼
- 軟體研發安全規範
- 關於技術文件
- 關於技術方案
- 【軟體設計】專案設計流程規範
- 關於園子求救信有感
- 關於開啟軟體提示各種缺少dll問題
- 基於版本控制的分散與聚集軟體開發流程 - industriallogic
- 團隊的效率在於規範和溝通,而不僅僅在於技術
- 關於SolaRoad持幣生息模式軟體開發方案模式
- 關於一對一軟體如何搭建PHP直播系統原始碼的流程PHP原始碼
- 關於最近開發小程式中踩過的那些坑
- 關於文化課(語文)老師的隨機點學號軟體有感隨機
- 軟體開發流程
- 2021年度總結 | 葡萄城軟體開發技術回顧(下)
- 2021年度總結 | 葡萄城軟體開發技術回顧(上)
- 分享個人用於開發相關的軟體/工具
- 關於軟體專案開發的分析與設計
- 關於最近面試的一些心得面試
- 關於軟體測試七個核心問題
- Java技術轉(兼顧)產品經理——讀《快速轉行做產品經理》有感Java
- 關於馬蹄鏈DAPP系統開發技術專案方案(成熟開發)APP
- 關於技術的選型
- 關於合約跟單交易所模式軟體開發模式