OOPAA

跟同事聊天，他原先是在一著名手機廠商研發中心工作，主要是做該廠商手持終端設備上的系統軟件，于是自然聊到“摩托，也要騾拉”上來。近幾年該廠的發展很不景氣，好幾年也沒見一款拿得出手的手機，在中國的市場占有率從前三降到排名之外，連在國貿的冠名大廈都賣掉了。同事說起來也是頗多無奈，講述了他看到的情況。

據他觀察，該公司內部是出現了這個幾個問題：
1. 基礎平臺不穩定，大量功能被任意加到平臺里面，導致越來越復雜，后期維護擴展完全不可能
2. 產品設計部的設計到產品研發，中間經歷太長時間，不能響應市場需求
3. 產品研發到最后才發現功能缺陷或者性能缺陷，最后只能 cancel

這些問題的產生原因相信見仁見智。撇開管理層和多部門間合作的問題，個人覺得這是傳統軟件開發模式下出現的典型問題，特別是基于瀑布模式的軟件開發。不能很快地響應變化，前期環節很難得到后面環節的反饋。由于開發模型是線性的，只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果。這樣就會導致很多啟動初期信心滿滿都看好的項目最后只能前赴后繼地陷入“焦泥坑”。實際過程中會加入更多的開發人員，使用更多的先進開發工具試圖解決問題，但對于開發問題的解決，這些都是作用不大的，甚至是幫倒忙的。Brooks' law 告訴我們，“Adding manpower to a late software project makes it later.”

“開發過程中變數太多了！”同事感慨到，于是又說到敏捷方法的擁抱變化。其實敏捷何嘗能減少變化。軟件開發的過程就是將問題域映射到軟件系統，然后提供軟件層面的解決方案。這里面天然存在兩個“再創造”的過程：問題域的分析建模，軟件的實現運行。任何一個環節的復雜性都會被放大累積進整個過程的復雜性，那么有沒有一勞永逸的辦法來解決這兩個問題？同樣是 Fred Brooks 告訴我們 “there is no Silver Bullet.”

軟件開發的復雜性可以分為兩種：本質復雜性和附加復雜性。其中附加復雜性包括人的復雜、工具技術的復雜，外部的復雜等。這些附加復雜性都是希望被限制到最小限度，可能造成的影響被限制在最小范圍內。這也是各種軟件開發方法試圖解決的主要問題。至于本質復雜性，主要是問題域本身的業務復雜，這是社會、組織，甚至各種因素造成的不可逃避的問題，是任何軟件方法都不可能抹掉的。因此，如何減少附加復雜性，盡可能解決本質復雜性，就是軟件開發方法的使命，也是判斷軟件方法是否有效的唯一標準。可悲的是，傳統的軟件開發大多是著眼于通過增加附加復雜性來解決本質復雜性，或者通過文檔、或者通過層層審批、或者通過freeze code base等等，但最后都被證明是刻舟求劍、緣木求魚。

與傳統方法不同，敏捷方法就是試圖解決軟件開發過程中的附加復雜性，把對解決本質復雜性的關注重新放到舞臺的中央，并提供應對本質復雜性的足夠可能。對于解決附加復雜性，敏捷宣言有“可工作的軟件勝于詳盡冗繁的文檔”，也有很多相關的實踐來保持對附加復雜性的不侵入，就不贅述了。那么敏捷是如何擁抱本質復雜性呢？那就是保持簡單和客戶 involved。

簡單，于是可以足夠輕量來調整原來的實現；簡單，于是團隊內部容易達到領域知識共享；簡單，于是開發過程透明性大大增強......這一切的結果都指向“響應變化”。user case 簡單了，就很容易來進行確認，包括前期和客戶的需求確認，也包括后期開發結果的確認。代碼簡單了，就很容易進行重構，增進設計，逐步兼容添加問題域中的復雜性。開發計劃簡單了，現在不用關心幾個月后的事情，只需要關注到下一個迭代和當前 release 涉及的需求。“簡約，而不簡單”，大家都輕松了，有時間培養自己的業余興趣了。

這是從開發團隊的角度來看到響應變化。客戶 involved 就使得這些變化能被客戶感知和認同，讓客戶盡可能主動思考現實問題域中的復雜性是否有改進的地方，規避了可能的風險，也有利于培養出長期積極的合作關系。這是一個很良性的互動過程，也是一個逐步走向雙贏的過程。這也是項目管理層和公司決策層會喜歡看到的結果。

“這些都很美好，但執行起來還得看人”，同事又拋出了這樣的論點。我默然，世界上最復雜的莫過于人了。不管方法理論上多么完美，實踐起來多么容易，只有真正有合適的人，讓合適的人去做合適的事，才能不致于明珠暗投，徒然神傷了。嗚呼