原创 使產品發生運營事故的概率大幅的降低 ?

2017.3.31, 深圳, Ken Fang 我們是否有輕量級、可視化的工程實踐、工具、架構模式, 可使產品發生運營事故的概率能大幅的降低? 答案是有的: @ 使代碼是可測試性的:可由產品級敏捷的 Story 場景樹, 所產出

原创 只是寫設計文檔的設計, 就是瞎折騰

2017.3.26, 深圳, Ken Fang 做產品, 需要的是 “產品軟件設計”, 而不是 “設計文檔”。 做產品, 需要的是可按照產品的不同, 而可 “自組合” 的工程實踐,而不是隻有一 “標準答案” 的 “流程”。

原创 企業為何需要產品級敏捷?

2017.3.8, 深圳, Ken Fang 企業獲利只剩個位數;但企業內每個員工, 都已加班、加點、拚死拚活到了最大的極限。 問題到底出在那裏? 很簡單;大家都把每天在企業的 16, 18個小時的時間、精力, 都用在錯誤的地方

原创 我是一名工程師, 我真的夠牛逼, 能要求人性化的管理嗎?!

2017.5.7, 深圳, Ken Fang 企業的文化是人性化的管理, 是尊重工程師;工程師可自由的上下班, 自身決定產品的質量, 甚至可決定版本的需求可做, 可不做⋯ 這樣的企業文化, 前提是:工程師要真正的夠牛逼。 假如,

原创 是時候, 該好好定義什麼是敏捷了...

2016.11.27, 深圳, Ken Fang 只是做到項目管理、文化、思維、流程,是對敏捷十分偏差且狹隘的見解與做法。 這樣的見解與做法,所產出的所謂的 “敏捷”,對於產品開發的效率與質量上的提升,是沒有任何絲毫的幫助的。 因爲,產

原创 當互聯網企業遇到了 SAFe, 是一拍即合? 還是存在著誤解?!

2017.4.16, 深圳, Ken Fang 客觀的說, 互聯網企業的特點是:許多的產品 (不是所有的產品)在研發的時候, 並沒有特定的客戶、使用者。更不用說分析需求了。 互聯網企業的許多產品, 在研發剛開始的時候,往往是隻

原创 企業不需要方法論?

2016.12.4, 北京, Ken Fang 企業內最糟糕的便是: @ 將做方法論、敏捷、看板與做產品(磨豆腐)完全的割裂;做方法論、敏捷、看板是一個任務,做產品(磨豆腐)又是另一個任務。 @ 只會刻板、硬搬方法論、敏捷、看板到做產品

原创 2010 - 2017, 我在華爲的諮詢

2017.01.22, 臺北, Ken Fang 2010 - 2017, 近 7 年的諮詢; 我在華爲, 結合了敏捷與軟件工程, 成功的創建了: 特性開發、產品級敏捷與微服務產品級敏捷。 特性開發、產品級敏捷與微服務產品級敏捷

原创 機器人會取代部分人類, 卻永遠沒法超越人類

2017.03.31, 深圳, Ken Fang 汽車跑的比你快, 你會擔憂嗎?當然不會, 因爲, 你會開車, 你會坐車;你會使用汽車。 機器人學習的比你快, 你會需要擔憂嗎?當然不需要。只要你會使用機器人已經學會的知識, 再去

原创 機器人經濟學

2017.03.30, 深圳, Ken Fang 現行許多機器人的發展方向, 都是朝着如何讓機器人來取代人類? 其實, 這種 十九 世紀的思維, 只是讓 “機器人” 與 “人類” 共同走入所謂的 “人力價格戰” 的死衚衕裏;最終

原创 從面向對象到函數式編程: 我們正在構建更成熟的關注點隔離生態系統

2016.11.17, 深圳, Ken Fang 在談論關注點隔離生態系統前, 我想,首先需要談談 Procedure Programming, Functional Programming , Object Oriented Prog

原创 產品級敏捷

2017.3.4, 深圳, Ken Fang 前言: 產品開發最危險的一件事便是: 開發人員往往是在無知的情況下, 寫代碼。 產品開發最不可思議的一件事便是: 開發人員開發汽車; 測試人員測試飛機 。 產品開發最悲催的一

原创 你的產品開發流程, 斷送了你的產品的競爭力與團隊的生存發展

2017.3.20, 深圳, Ken Fang 最近和許多朋友們聚聚;有件事, 一直讓我很沒法理解: 我今年已 52 歲了。 我卻發現許多現在 30 多歲的年輕人, 還在用我 30 多歲時候的方法在設計軟件, 開發軟件。 我所沒

原创 Scala 函數響應式編程: 靜態類型 (Static Types)

2016.12.3,  北京, Ken Fang 函數響應式編程爲使函數內的代碼更加的強壯, 便需在代碼編譯的階段時, 就要能確定傳入函數的參數類型, 是符合領域模型中的商業規則。也就是說, 藉由編譯器形成一過濾器; 只讓符合領域模型中

原创 架構師,真的懂得架構設計?真的有能力做架構設計?

2016.12.22, 深圳, Ken Fang @ 全世界優秀的架構師,都能用 “程序語言”;而不只是用文檔;與團隊成員溝通的。 @ 全世界優秀的架構師,都能根據事物的本質,做出 “決策”;而不是根據 “定義”、“過去的經驗”做