OOPAA

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

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

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

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

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

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

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

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

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