關(guān)于軟件開發(fā)項(xiàng)目任務(wù)的橫向分解和縱向分解

凝望長(zhǎng)空

關(guān)于軟件開發(fā)項(xiàng)目任務(wù)的橫向分解和縱向分解

在一個(gè)軟件研發(fā)項(xiàng)目的管理實(shí)踐中，項(xiàng)目任務(wù)的分解一直是一個(gè)很重要的工作，但是不同的項(xiàng)目經(jīng)理對(duì)這個(gè)問題的操作方式又常常會(huì)千差萬別，其中一個(gè)很常見的分歧在于，是橫向分解還是縱向分解？本文試圖對(duì)此進(jìn)行一個(gè)簡(jiǎn)單的探討，希望能給處于項(xiàng)目任務(wù)分解困惑中的項(xiàng)目經(jīng)理們一點(diǎn)借鑒。

首先解釋一下這兩個(gè)概念：

橫向分解是指基于技術(shù)架構(gòu)層次進(jìn)行的人員角色分工和任務(wù)分解。比較常見的一種情況是，項(xiàng)目的技術(shù)架構(gòu)采用表示層、業(yè)務(wù)層和持久層三層架構(gòu)，然后這三層分別采用struts、spring和hibernate框架，于是人員招聘時(shí)分別對(duì)相應(yīng)的框架使用提出要求，具體任務(wù)分解時(shí)先由項(xiàng)目經(jīng)理分解好模塊任務(wù)計(jì)劃，然后由設(shè)計(jì)師定義好各模塊的層次間接口，再將具體編碼任務(wù)分解給程序員。

縱向分解是指基于業(yè)務(wù)模塊的任務(wù)分解。比較常見的一種情況是，項(xiàng)目經(jīng)理首先擬定出整體項(xiàng)目進(jìn)度計(jì)劃，再按模塊對(duì)項(xiàng)目任務(wù)進(jìn)行分解，設(shè)計(jì)師關(guān)注模塊間的接口和技術(shù)體系的一致性，具體模塊內(nèi)的設(shè)計(jì)和實(shí)現(xiàn)由各模塊的責(zé)任人相對(duì)獨(dú)立地完成。

橫向分解是目前普遍采用的方法，優(yōu)點(diǎn)就不多說了，網(wǎng)上應(yīng)該有很多相關(guān)的介紹，缺點(diǎn)卻是很明顯的：首先，對(duì)于普通編程人員來說，配置文件編寫起來相當(dāng)煩瑣，常常缺乏編譯期檢查，就算有工具支持往往也沒有編寫代碼來得順暢。其次，看懂一個(gè)簡(jiǎn)單模塊的代碼通常也要在代碼和配置文件間轉(zhuǎn)來轉(zhuǎn)去，比較吃力，特別對(duì)于接手前人工作的程序員來說，簡(jiǎn)直是個(gè)災(zāi)難。再次，橫向分解是建立在模塊內(nèi)層次間良好溝通的基礎(chǔ)上的，對(duì)于層次間的溝通要求很高，如果這一項(xiàng)工作做不好會(huì)使整個(gè)項(xiàng)目陷入泥潭。

當(dāng)然指出橫向分解的缺點(diǎn)并不是要對(duì)此種方案進(jìn)行全盤否定，而且方案的缺點(diǎn)有很多在項(xiàng)目中是可以規(guī)避的，只是這種方案的成功實(shí)施是建立在很多假設(shè)的基礎(chǔ)上的，比如說項(xiàng)目具有一定的規(guī)模，相關(guān)人員具有從事相關(guān)崗位工作的技術(shù)能力，層次間接口能夠良好定義，項(xiàng)目成員間能夠進(jìn)行良好溝通等等，如果這些假設(shè)很多都不具備，那實(shí)施這個(gè)方案就會(huì)帶來災(zāi)難。

筆者曾經(jīng)碰到過一個(gè)案例，是個(gè)視頻門戶的運(yùn)維系統(tǒng)項(xiàng)目，項(xiàng)目總共只有10人，項(xiàng)目經(jīng)理卻堅(jiān)持要采用橫向分解，說是大公司像微軟、IBM都是采用的這種方案，我只問了他兩句話：你從哪兒知道大公司都是采用這種方案？你是大公司嗎？當(dāng)然他并沒有認(rèn)真考慮我提的問題，依然大刀闊斧地實(shí)施起了他的項(xiàng)目管理策略：首先設(shè)置兩名QA負(fù)責(zé)測(cè)試，一名美工負(fù)責(zé)做頁面效果圖，剩下的六人分為前臺(tái)三人負(fù)責(zé)表示層和后臺(tái)三人負(fù)責(zé)持久層，他自己只做項(xiàng)目進(jìn)度計(jì)劃。

剛分完他就發(fā)現(xiàn)業(yè)務(wù)層沒人做了，由于業(yè)務(wù)層跟表示層聯(lián)系比較緊密，自然這個(gè)任務(wù)就落到了前臺(tái)三個(gè)人的頭上，但很快就出現(xiàn)了前后臺(tái)進(jìn)度落差巨大的問題，于是業(yè)務(wù)層任務(wù)又改為由后臺(tái)來做了，但由于接口沒有很好地討論好，集成測(cè)試又出現(xiàn)了很多問題。

其實(shí)很多剛起步或規(guī)模相對(duì)較小的軟件公司都采用的是縱向分解的方案，由于資源有限，項(xiàng)目較多，又缺乏高水平的系統(tǒng)分析和設(shè)計(jì)人員，有的項(xiàng)目甚至從需求分析到編碼測(cè)試都由一人完成，機(jī)械地套用橫向分解的方案是根本行不通的。當(dāng)然縱向分解方案對(duì)人員素質(zhì)提出了較高的要求，不但要熟悉表示層的相關(guān)技術(shù)，也要了解持久層的基礎(chǔ)知識(shí)，還要熟悉業(yè)務(wù)流程，重要的是市面上缺乏面向應(yīng)用的分層的整合型的框架，能夠方便程序設(shè)計(jì)人員快速地開發(fā)出設(shè)計(jì)良好的企業(yè)應(yīng)用。