2017.3.20, 深圳, Ken Fang
最近和許多朋友們聚聚；有件事, 一直讓我很沒法理解：
我今年已 52 歲了。
我卻發現許多現在 30 多歲的年輕人, 還在用我 30 多歲時候的方法在設計軟件, 開發軟件。
我所沒法理解的是，用我在 30 多歲時候的方法在設計軟件, 開發軟件, 所會發生的問題, 應該是非常顯而易見的⋯
＠ 認爲軟件開發就只是寫只代碼; 其實只是一直在無知的狀態下, 進行軟件產品的開發。
@ 產生一堆笨重又沒法指導開發、測試的設計文檔。
@ 笨重的設計文檔, 根本就沒法與代碼匹配。
@ 毫無意義的評審設計文檔；最終, 只是一堆所謂的專家, 在評審設計模板寫的完不完整。一堆所謂的專家, 其實是沒人知道, 軟件設計的本質與目的爲何？更沒人關注, 產品真正所需的架構設計上的決策爲何？
@ 折騰了一堆文檔, 評審，充其量只是證明自己沒做錯事；但，就是因爲沒人做錯事, 所以, 開發效率才那麼差, 產品質量才那麼爛。
@ 市場都已經發生變化了, 團隊內部還在跑項目起動流程；以瀑布的思維, 評審團隊有沒有需求文檔？有沒有設計文檔？
對這些會斷送產品競爭力、會斷送團隊生存發展的問題, 大家爲何都視而不見？ 卻還自認爲自己很專業？
2017 年了, 爲何大家還是分不清楚：
@ 瀑布
@ 迭代
2017 年了, 爲何大家還是不明白：
@ 產品開發、敏捷與軟件工程間的關係
我們其實真正需要的不是去搞一些表面看起來很專業, 高深的流程、模板、審計。
我們更不應該是在無知的狀態下, 開發軟件產品。
產品級敏捷、微服務產品級敏捷, 結合了敏捷與軟件工程, 提供了:
**@ 對團隊在產品有價值、可先行開發的業務場景識別
@ 軟件架構持續設計
@ 軟件架構風險管理
@ Story 的設計與開發代碼的無縫結合
@ Story 開發完成的定義
@ Story 的開發每日風險管理**
產品級敏捷、微服務產品級敏捷經由可視化、輕量級的工程實踐, 使得團隊各不同角色的成員, 可共同的協作, 高效, 簡單卻不簡化的完成上述與產品開發至關重要的工作 (活動)。
我們其實真正需要的只是：簡單卻不簡化, 實實在在的在做 “產品” 罷了。
