OOPAA

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

據(jù)他觀察，該公司內(nèi)部是出現(xiàn)了這個幾個問題：
1. 基礎(chǔ)平臺不穩(wěn)定，大量功能被任意加到平臺里面，導(dǎo)致越來越復(fù)雜，后期維護(hù)擴(kuò)展完全不可能
2. 產(chǎn)品設(shè)計部的設(shè)計到產(chǎn)品研發(fā)，中間經(jīng)歷太長時間，不能響應(yīng)市場需求
3. 產(chǎn)品研發(fā)到最后才發(fā)現(xiàn)功能缺陷或者性能缺陷，最后只能 cancel

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

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

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

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

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

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

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