一個有實際應(yīng)用價值的敏捷過程并不是簡單地照章辦事就可以實現(xiàn)。敏捷方法的采用，既要使敏捷方法適應(yīng)一個環(huán)境，也要調(diào)整環(huán)境使其有更好的敏捷性和響應(yīng)性。
一個有實際應(yīng)用價值的敏捷過程并不是簡單地照章辦事就可以實現(xiàn)的。它需要根據(jù)環(huán)境有意識地對最佳實踐進行調(diào)整，使之適應(yīng)這個環(huán)境并充分發(fā)展。其中，還要考慮對這個過程有引導(dǎo)作用的三個關(guān)鍵問題：
怎么保證工作完成時有充分的完整性？
怎么保證所做工作有合適的透明度？
企業(yè)層面上有什么約束條件能避免中途發(fā)生變化？
注意解決這些問題不但可以使IT企業(yè)掌握新的工作方式，還能使業(yè)務(wù)方面受到的損失減小到最低程度。
設(shè)計最佳實踐：保證完成時的完整性
敏捷開發(fā)的一個特點是它不會增加將來的負擔，也就是說它不會把一些諸如構(gòu)建、集成和測試的活動推遲到下一階段。在敏捷過程中，這些活動幾乎都是 和代碼編寫同步完成的：在編寫可執(zhí)行的代碼之前做出項目成功的標準，即時將所編寫的代碼提交到構(gòu)建和自動測試中，并讓開發(fā)人員結(jié)對工作以更好地保證所做工 作產(chǎn)生滿意的結(jié)果。這樣，如果有什么需要通過敏捷項目來完成，那么它便只需要走一個客觀的過程，從而減少主觀因素的影響。
雖然已有一系列敏捷實踐可以用來開始這一過程，但這個過程不能簡單依靠任何實踐直接完成。每個項目的情況和特點決定了各個實踐的應(yīng)用程度。過分的應(yīng)用可能只實現(xiàn)很小的價值；而應(yīng)用得太過保守，又無法產(chǎn)生可驗證的效益。
比如一個持續(xù)集成的過程，C++和COBOL等技術(shù)可能對此并不支持，但并不因為它們不支持持續(xù)集成，就意味著敏捷構(gòu)建實踐毫無用處。減少代碼 提交與構(gòu)建之間的時間差顯然是有好處的。所以，在此情況下，即使是一天即可完成的工作，也能最大程度地提高構(gòu)建效率，從而增加效益。 CruiseControl這類構(gòu)建工具可以支持各種非典型的敏捷技術(shù)和構(gòu)建循環(huán)。
構(gòu)建的實現(xiàn)能對代碼質(zhì)量的監(jiān)督起到多大作用還取決于團隊的特點。對于一個掌握各種技術(shù)、在地理位置上分散的大型團隊來說，如果能在每次代碼提交 時都進行測試和代碼質(zhì)量分析，其價值將是無法估量的。相比之下，對于地理位置分布較集中的小型團隊來說，這可能就只是一種時間上的浪費，因為這種團隊通常 只需要一個構(gòu)建信息入口。
一味追求更高的單元測試覆蓋率并不是好事。比如，在一個需求經(jīng)常發(fā)生急劇變化的、高度動態(tài)的業(yè)務(wù)領(lǐng)域中，必須在有限時間內(nèi)完成一個項目。這種情 況下，相比時間與功能，質(zhì)量可能會處于一個較低的優(yōu)先級。這時，過高的單元測試覆蓋率將是一種精力上的浪費，因為有大量代碼會被直接處理掉。而根據(jù)需求編 寫最貼切的單元測試會更為有效；然后在對業(yè)務(wù)領(lǐng)域有了更好的了解之后，再考慮增加單元測試覆蓋率的問題。另外，技術(shù)上也會有所限制，比如當前開發(fā)語言可能 并不支持單元測試，而使之支持單元測試的第三方機制又稍顯尷尬（比如在CICS系統(tǒng)中使用.NET包裝器對MQ進行包裝以調(diào)用COBOL程序）。因此，所 能達到的覆蓋率也是有限的。盡管如此，創(chuàng)建一個可測試的架構(gòu)、并取得一定程度的單元測試覆蓋率總比什么都不做要好。
很顯然，無法給任何實現(xiàn)敏捷過程的活動做出廣泛通用的定義。因為每一種活動都是在不同程度上實踐的，而其實踐程度又決定了項目完成時的置信度。
管理最佳實踐：透明度
牽涉到完成時的完整性，盡可能詳細地了解正在做的事情就變得很更要。在應(yīng)用敏捷管理實踐過程中，如果沒有項目管理實踐，那么獲得的將是提交質(zhì)量上的提升而不是IT響應(yīng)性的提升。要獲得更好的響應(yīng)性，就需要使所進行的工作透明化。
敏捷方法可以通過以下途徑實現(xiàn)透明化：需求的表達方式、團隊的組織方式、協(xié)作方式和過程追蹤方式。當