由某手機廠商現狀漫談靈活

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

據他觀察，該公司内部是出現了這個幾個問題：

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 就使得這些變化能被客戶感覺和認同，讓客戶盡可能主動思考現實問題域中的複雜性是否有改進的地方，規避了可能的風險，也有利于培養出長期積極的合作關系。這是一個很良性的互動過程，也是一個逐漸走向雙赢的過程。這也是項目管理層和公司決策層會喜歡看到的結果。

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