發表文章

目前顯示的是 10月, 2020的文章

DDD 中為人所忽略的『軟體工程』與『工程實踐』方法

圖片
圖片來源:https://zhuanlan.zhihu.com/p/32196548?from_voters_page=true 我們知道架構設計需要從業務角度出發,我也寫過許多類似的內容,像是:『從使用者需求、談架構設計』、『您的軟體架構夠敏捷嗎?』等等、這些都是從業務角度出發嗎?這可以說對,但也可以說不完全對。。。怎麼說呢? 我們談論 軟體開發/架構設計 時,常聽到有人說,技術團隊與業務團隊溝通不良,導致技術團隊做白工!或者是技術團隊聽不懂業務團隊在說什麼?搞不清楚重點。而業務團隊也常常抱怨技術團隊沒辦法溝通,總是說著一堆技術專有(名詞/詞彙)導致無法溝通下去! 很熟悉吧?相信這是大家常聽到許多人嘴巴在說的。 我們再回到我一開始講的,業務角度出發,這出發點是對的沒有錯, 但是我講的是我們開發軟體系統是要開發出符合客戶期望 + 能夠替客戶解決問題 + 符合客戶所想的,對!所以即便你與業務單位溝通融洽、沒有聽不懂的、雙方也沒有疑問,但是這不代表你做出來的系統就完全符合客戶所期望,還有,也不代表實作出來的系統是不是很容易地在這個客戶的『商業需求』上很容易地擴充 與 能夠進行最低成本的修改,對!不見得喔!XD 業務與技術單位溝通沒有隔閡,不代表技術完成品是妥當的! 業務與技術單位溝通沒有隔閡,不代表技術完成品是妥當的! 業務與技術單位溝通沒有隔閡,不代表技術完成品是妥當的! 敏捷有一個非常重要的出發點就是,替客戶創造價值,並在反覆設計/反饋/ Retro 中修正方向以達成客戶期望,但是... 這個過程走得不扎實,光是技術債爾後就會把你壓死,也就是說: 能否達成客戶期望是一回事 !達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 能否達成客戶期望是一回事 !達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 能否達成客戶期望是一回事 !達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 近年來我的文章 & 教學大部分圍繞在一個重點就是在需求內使用適當的技術下【產生】適當的軟體架構來解決 商業需求 ,產生的過程、如何產生?甚至如何讓你商業需求直接(對應/轉換)程式碼一直是我研究的重點,近幾年來開始盛行的 DDD 也是在降低業務團隊 (我這裡精確的是 USER,USER 不等同於業務團隊這是有差別的!) 開發團隊 的溝通成本,而降