合同的第二部分，他希望根據(jù)第一階段的工作成果制定項目計劃，包括費用、人員、進度、范圍、交流、風險控制和變化等方面。Chris要求承包方每兩個星期提供一個可以工作的軟件版本并且可以簡單地部署到它的生產(chǎn)環(huán)境中。每兩到三個月，Chris要得到一個具有完整功能的系統(tǒng)，從而讓業(yè)務(wù)部門盡早使用信息系統(tǒng)，產(chǎn)生更多的商業(yè)價值。
擁有了這樣一份合同，Chris不再為以前的種種苦惱而憂心了。首先，項目的進展盡在IT和業(yè)務(wù)部門的掌控。每兩個星期開發(fā)團隊提供一個可工作的軟件，這樣業(yè)務(wù)部門就可以對這個軟件進行用戶測試，從而思考和矯正他們最初對需求的理解。這個過程使得業(yè)務(wù)部門更好地理解了他們到底需要什么，而不是片面的紙上談兵，從而大大減少了開發(fā)工作中的浪費。
Chris看到的這種方法的價值不僅于此。IT部門在這個過程中起的作用更大了，并且是開發(fā)部門和業(yè)務(wù)部門的融合劑、調(diào)和劑。業(yè)務(wù)部門對IT的看法改變了，他們不再是一個被動的提供技術(shù)支持的團隊，而是一個主動的幫助業(yè)務(wù)部門更快、更早、更高效地實現(xiàn)其價值的服務(wù)團隊。業(yè)務(wù)部門也不再擔心如果在開發(fā)工程中產(chǎn)生新需求或者需求變化時，開發(fā)部門不能及時應(yīng)對，因為一切是如此的靈活和敏捷。
Chris了解到，這樣的一種合作模式和開發(fā)方法是一種叫做敏捷的軟件開發(fā)方法。其中的兩條精髓是“客戶合作重于合同談判；響應(yīng)變化重于遵循計劃”。
這種敏捷的開發(fā)方法也改變了工作團隊間的交流方式。以前那種依靠詳盡的文檔和復(fù)雜開發(fā)過程的交流方式被以尊重個體的交流、以必要的文檔為交流媒質(zhì)的方法所取代�；叵肫鹨郧鞍殡S軟件交付而交付的厚厚文檔，Chris就發(fā)自內(nèi)心地感覺這本身就是一種浪費，因為這些文檔的大部分不會有人去讀。一個沒有讀者的文檔必然就是很大的浪費。敏捷方法的文檔形式新穎，大多是以圖表、界面原型、故事的方式，很容易被理解。
在鼓勵個體交流的同時，Chris看到了一些意想不到且欣喜的變化。各個團隊更多關(guān)注這個可工作的軟件，如何利用先進的Web2.0、SOA、 Ruby On Rails等技術(shù)來幫助業(yè)務(wù)部門實現(xiàn)其需求，而不是文檔所謂的準確性。交流的增加使團隊間增進了理解，團隊的工作氛圍也不同了，大家更享受這份工作。
如何保證軟件系統(tǒng)的
持續(xù)有效運行
軟件的維護一直是困擾Chris的一個大問題。這個問題主要體現(xiàn)在兩個方面：一是軟件的可擴展性差，二是軟件的可維護性不好。
擴展性差的原因在于，在傳統(tǒng)方法的軟件產(chǎn)品設(shè)計階段，需要為這個產(chǎn)品設(shè)計出一個“滿足各種需求”的架構(gòu)，這個架構(gòu)一經(jīng)確定就不能再變化了。并且這個設(shè)計是相對比較詳細的，靈活性很差。與這種方法不同，敏捷方法講究的是每一到兩周就可以發(fā)布一個可工作的產(chǎn)品，我們把這個時間段稱為一個迭代。這種可以連續(xù)發(fā)布的特性是建立在一個擴展性好的軟件基礎(chǔ)上的。好的擴展性的實現(xiàn)是通過在開發(fā)過程中不斷地對架構(gòu)和代碼重構(gòu)，從而適應(yīng)不斷變化的需求。這樣一來使用敏捷方法的軟件產(chǎn)品的擴展性就不成問題了。
此文章共有4頁 上一頁 1 2 3 4 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
