然支持這些的主要敏捷實踐，如用需求卡片表示需求、協(xié)作方式、迭代交付等，并不是全部的解決方案，其本身也需要適當(dāng)?shù)恼{(diào)整以適應(yīng)特定的環(huán)境。
例如，一個地理位置上分散的、幾百人組成的團隊，通常會把項目分解到幾個團隊由其獨立完成，而不是所有人都去研究同一類需求。這些獨立的團隊將 影響到需求的實現(xiàn)方式：高層次的需求可能需要多個團隊各自完成一些子部分，而各子部分之間則通過消息來傳遞信息。而這并不會減少需求卡片所帶來的價值，這 種“準(zhǔn)需求”能使各團隊完成各自獨立的（至少是分離的）、可測試的需求，從而很好地實現(xiàn)業(yè)務(wù)價值。
此外，還要考慮到項目管理方式的模式化程度。分布集中的團隊可能會體驗到“需求卡片墻”生動地將需求分階段展示出來的好處，它將包括已完成的、 待定的、正在實現(xiàn)中的和準(zhǔn)備解決的。然而，地理位置分散的團隊無法使用真正的需求卡片“墻”。在此情況下，可以使用項目追蹤報告（比如借用Mingle等 工具）使團隊掌握項目狀態(tài)。團隊的分布形式也會影響到業(yè)務(wù)的協(xié)調(diào)程度。雖然業(yè)務(wù)應(yīng)該與開發(fā)團隊分布于同一地理位置，但對于分散的團隊來說這不可能。但這并 不意味著對本地業(yè)務(wù)的了解沒有用處，因此可以在本地設(shè)置一個業(yè)務(wù)代理——如請一位業(yè)務(wù)方面的分析專家，可以取得同樣的效果。
版本發(fā)布計劃的實踐會根據(jù)環(huán)境不同而有相當(dāng)大的變化。在一個高度動態(tài)的領(lǐng)域里，版本發(fā)布計劃基本就是一種“一廂情愿”的想法。在這種情況下發(fā)布 計劃很可能會誤導(dǎo)項目的利益相關(guān)人并損害團隊的利益。這時，XP方法中的“昨日氣象”法應(yīng)該是管理發(fā)布過程最安全的方式。在一個較穩(wěn)定的領(lǐng)域里，版本發(fā)布 計劃就能在很大程度上改善項目檔案管理。
另一個需要根據(jù)情況考慮的是某種環(huán)境下的緊張程度。Scrum方法可能會對經(jīng)常在生產(chǎn)中遇到故障或者發(fā)現(xiàn)缺陷從而急需危機管理的項目很有效，我 們可以一個中等長度的時間（比如一個月）劃分工作段，在各階段每天舉行站立會議。但對于無法規(guī)律地得到發(fā)布版本的客戶，可能更喜歡敏捷方法中常見的、一致 性更好、時間更長的迭代和發(fā)布周期。
總之，透明度并不是在做任務(wù)的時候順便獲得的，而是通過諸多在特定情況下可以最大化透明度的實踐來實現(xiàn)的。
困難的解決與管理上的約束
以上所述并不是說敏捷實踐僅僅是一種如何選擇的問題，它還需要考慮更多可驗證的、協(xié)作上的效益。我們需要看到，當(dāng)這些實踐完全實施以后，質(zhì)量與 響應(yīng)性都會得到極大的提升。雖然不同種類的敏捷實踐——Crystal、XP、Scrum等——提供了不同的敏捷實現(xiàn)方法，但不等于這些就是全套的解決方 案。比如，在一個高度動態(tài)的領(lǐng)域中，XP中的“昨日氣象”預(yù)測方法可能有極其重要的價值，但是由于它強調(diào)100%的單元測試覆蓋率，因此即使在這樣的環(huán)境 下，也可能造成相當(dāng)大的精力上的浪費。同樣，只采用Scrum管理方法卻沒有相應(yīng)的敏捷實踐可能導(dǎo)致項目管理與技術(shù)執(zhí)行不完全一致。不管采用什么方法，都 應(yīng)該對其有粒度化的了解和調(diào)整。
必須了解敏捷實踐還會受到環(huán)境中各種條件的限制。敏捷實踐通常是為了解決企業(yè)中的一些問題而引入，比如質(zhì)量、一致性，或者響應(yīng)性等問題。但如果 只解決了問題，卻仍然有各種各樣的約束，是無法產(chǎn)生最佳效果的。比如，敏捷的版本發(fā)布計劃會假定有一個“代碼所有者群體”，整個代碼庫都由這個團隊“掌管 ”。如果只采用了各團隊獨立的開發(fā)方式，管理方式卻跟不上，就會導(dǎo)致“泳道”式的結(jié)果。特別是有高度耦合性的代碼會產(chǎn)生依賴性，而使敏捷發(fā)布計劃變成瀑布 模式。同樣，如果質(zhì)量保證是由處于某一地理位置的一個團隊獨自實現(xiàn)的，那么很可能會使這個團隊疲于奔命，無法及時響應(yīng)來自敏捷開發(fā)團隊的各種變化。這樣， 開發(fā)響應(yīng)