#2018年中總結之二#項目問題淺思 領域驅動設計?敏捷開發?

十個月的時間,展轉六七個項目,雖以普通開發人員的視角管中窺豹,但項目中的問題弊病依然可見一斑.從幾個方面寫寫本身的見聞和淺析吧

1. 人天問題

軟件開發項目最大的成本就是人.人天預估的高了不容易中標,人天預估的低了又難以保證質量,其中的權衡拿捏不是我一個小技術能涉及的.可是真正落地實際狀況並不理想,在許多項目的承包上,項目預估的人天與實際所需嚴重不符,甚至有項目剛開始作需求分析的時候,工期已通過去了一半多.因此即便已經瘋狂壓榨開發人員(個別項目整月整月的加班到12點),不少項目仍是不得不延期,倉促趕工的項目質量不行與延期以後帶來的成本提高都在下降甲方的滿意度,同時也下降了乙方的利潤

2. 業務能力不足

多數項目中缺乏能從總體角度輔助客戶完成業務功能設計的出色業務顧問.不少項目中,甲方業務需求本身想方案完成方案設計,乙方業務能起到的做用小.

3. 盲目推行新模式

趕鴨子上架推行DDD,領域驅動設計的確要求與業務增強溝通,雙方共同設計出領域模型.可是在雙方對領域驅動設計都缺少了解的狀況下強行推動DDD很容易弄巧成拙.

一方面業務人員容易落入本來瀑布式開發的窠臼中(視各類需求分析文檔\開發文檔爲項目進度的里程碑)(這也有甲方的領導很難轉變思惟的緣由:有時候業務角色接受了新型的軟件開發方法,而他們的領導卻不能緊跟這種變化)

另外一方面,DDD要求技術人員也要轉變思惟,系統的設計,尤爲domain層的實現,與本來的mvc模式徹底不一樣.並且,領域模型驅動代碼的實現要求保證領域模型的設計是正確的.不然咱們沒法肯定領域模型能夠解決領域中的核心問題

這就致使,甲方由於缺少項目產出(特別是在項目前期,DDD由於重產品而輕文檔,缺乏能向甲方說明的項目進度的標的)會開始懷疑乙方的進度,而雙方對領域的不擅長致使遲遲不能推演出正確領域模型設計又繼續加劇這種不信任,而後由於時間有限,倉促趕出一個領域模型並進行開發,以致於模型沒法符合實際業務須要反而增長了開發難度...而項目的延期又會致使甲方進一步懷疑乙方能力...

總而言之,我認爲在實施DDD的過程當中,咱們缺少一個領域專家的角色帶領咱們向DDD過渡.

 

4. 技術與業務之間的隔閡

在項目中,業務在完成了項目前期業務模型設計以後的主要角色就變成了監工和功能測試人員.

許多業務顧問除了催進度以外就只會甩鍋,說什麼什麼問題是開發的問題,是他們寫的bug.而技術人員一樣會把鍋甩給其餘:好比設計的時候沒寫清楚,好比這個代碼不是我寫的而是以前的人寫的等等.

互相甩鍋致使乙方內部都沒法通力合做,大把的時間用來互相扯皮推脫任而不是解決問題.

5. 規範與標準化的缺失

1. 代碼倉庫管理分散,各個項目組有各個項目組的svn服務器.雖然很早就在客戶部署了統一的gitlab服務,可是項目遷移缺少動力,進展緩慢

2. 項目文檔管理混亂,這個比代碼管理還要混亂,代碼最差的狀況也至少有svn中央倉庫,而文檔要麼直接缺失,要麼就只保存在個別幾我的的本地電腦中.

3. 項目文檔沒有標準化,每一個項目的文檔都使用不一樣的模板,並且當代碼功能變動時,文檔一般沒有跟着變動.這給後續接手運維或者升級的人員帶來了很是多的困難.

4. 缺少代碼審計流程.大多數項目沒有代碼review環節,代碼質量徹底依賴開發人員自查,關於安全性的缺陷檢查與編程規範基本無從談起.

5. 缺少測試,大多數項目沒有規範的測試流程,大多數開發人員不寫測試類.單元測試無從談起.測試人員一般由甲乙雙方的業務人員兼任,一般也只是在頁面上點點點的黑盒測試.

6. 缺少開發規範,包\類\方法\字段的命名沒有規則,數據庫設計字段命名隨意,對如何拆分數據表缺少清楚的邏輯.

 

6.人員變更大

項目成員表來源複雜,組織結構複雜,項目成員來自公司內不一樣的事業部,直接彙報的領導各自不一樣.並且,由於壓力福利種種緣由,項目內持續有人離職,因此項目組不得不從公司的其餘部門調人同時從外面招人,而新招聘的員工質量沒法保證,從企業內其餘部門調來的員工又由於跨部門,帶來了管理上的麻煩

 

嘗試的改變與侷限

1. 推行容器化,由於容器化的推動依賴gitlab的CI/CD功能,容器化倒逼各個項目組向統一的gitlab遷移代碼,而容器化也同時簡化了發佈流程,提升了標準化.而推行容器化的侷限在於如下幾點:

   • 不少老項目部署在weblogic環境中,遷移難度大,並且部分老項目長期沒有技術人員維護,從接手到升級成本很高.

   • 即便是使用了gitlab管理代碼的項目,可是不少項目沒有嚴格執行gitflow的流程,致使分支管理混亂,各個分支代碼不統一,部署版本不肯定等等問題依然存在

 

2. 推行敏捷開發,在一些新項目中使用敏捷工具如看板等推動項目進展取得了不錯的成效,客戶能夠經過看板直觀的看到項目的進展,開發上的進度也更容易掌握. 侷限性在於推行敏捷須要有懂敏捷的人員參與,而不少項目人員沒有敏捷的培訓對敏捷工具不熟悉,也不瞭解敏捷方法.這就意味着敏捷開發難以大規模推廣.(頻繁的人員更迭也加重了這一點,由於新加入項目的同事廣泛並不瞭解敏捷)

 

3. 成立了測試小組專職進行自動化測試.這確定是一件好事,可是目前的測試仍是依舊停留在表面,使用的是eggplant模擬點擊網頁操做的測試工具作黑盒測試,雖然在必定程度上節約了測試時間成本.可是侷限性依舊很大:

   • 一方面是軟件學習成本高,本來作功能測試的業務人員很難學會使用.

   • 一方面這種測試依舊是黑盒測試,並且難以測試邊際值,只能測試正確的流程可否完整執行. 另外據我瞭解,測試人員在項目中地位不高,並且一般還須要兼職作開發工做.

 

4. 安排開發人員互審代碼. 這項工做初衷很好,可是實際執行中,代碼審計的優先級遠遠低於功能開發,在開發進度壓力大的狀況下沒有人在意功能是如何實現的,由於能定期交付就已經用盡全力了.