行軍

相信,放手,檢討,改正

要捨,Fix 一個將要 Deploy 的版本,新功能或要修改的功能加到下一個版本。Fix 的版本要專人測試,以既有的規劃全力修 Bug。要有專人與測試專案,固定周期性遞廻測試。

任何的修改都可能有非表面的影響,且有資源排他性,要計算 man/day 成本。修改要以全部團隊的需求排優先順序,非僅子團隊的優先順序。

三十多個廠,若沒有 Fix 的正式部屬版本,三十多個廠邊佈署邊依新需求、新 bug 改程式,導致三十多個各廠版本,將無從維護。

線上環境的安全規範不一致,測試環境與 Production 不同,部署變成考驗執行者全部資訊技術的經驗。

要橫向開發,彼此有溝通聯繫,橫向開發任一層(Data、Business、UI)的規範只要跟該層的達成協議,追究責任時,也只針對幾個人。若縱向開發,每個人負責一個功能的所有層,則任何規範變成要求所有人。

版本要有比較,差異報告要定期產生,且每個人都看得見報告。要由 Developer 把差異彌平,成百上千的物件不是 DBA 可以離得清原委

底層的物件更動要先比較查核,最起碼 DB 要嘗試用 VSTS DB Edition 去比較受影響的物件,並發布通知

加班變成常態,沒有士氣,不會自發性地求好,不主動溝通協調,Bug 會不斷。軟體是靠腦力非勞力,鞭子的效應不如胡蘿蔔

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: