一個有實際應用價值的敏捷過程并不是簡單地照章辦事就可以實現(xiàn)，

從調整敏捷到適應敏捷的最佳實踐

    一個有實際應用價值的敏捷過程并不是簡單地照章辦事就可以實現(xiàn)的。它需要根據環(huán)境有意識地對最佳實踐進行調整，使之適應這個環(huán)境并充分發(fā)展。其中，還要考慮對這個過程有引導作用的三個關鍵問題：

怎么保證工作完成時有充分的完整性？

怎么保證所做工作有合適的透明度？

企業(yè)層面上有什么約束條件能避免中途發(fā)生變化？

    注意解決這些問題不但可以使IT企業(yè)掌握新的工作方式，還能使業(yè)務方面受到的損失減小到最低程度。

    設計最佳實踐：保證完成時的完整性

    敏捷開發(fā)的一個特點是它不會增加將來的負擔，也就是說它不會把一些諸如構建、集成和測試的活動推遲到下一階段。在敏捷過程中，這些活動幾乎都是和代碼編寫同步完成的：在編寫可執(zhí)行的代碼之前做出項目成功的標準，即時將所編寫的代碼提交到構建和自動測試中，并讓開發(fā)人員結對工作以更好地保證所做工作產生滿意的結果。這樣，如果有什么需要通過敏捷項目來完成，那么它便只需要走一個客觀的過程，從而減少主觀因素的影響。

    雖然已有一系列敏捷實踐可以用來開始這一過程，但這個過程不能簡單依靠任何實踐直接完成。每個項目的情況和特點決定了各個實踐的應用程度。過分的應用可能只實現(xiàn)很小的價值；而應用得太過保守，又無法產生可驗證的效益。

    比如一個持續(xù)集成的過程，C++和COBOL等技術可能對此并不支持，但并不因為它們不支持持續(xù)集成，就意味著敏捷構建實踐毫無用處。減少代碼提交與構建之間的時間差顯然是有好處的。所以，在此情況下，即使是一天即可完成的工作，也能最大程度地提高構建效率，從而增加效益。CruiseControl這類構建工具可以支持各種非典型的敏捷技術和構建循環(huán)。

    構建的實現(xiàn)能對代碼質量的監(jiān)督起到多大作用還取決于團隊的特點。對于一個掌握各種技術、在地理位置上分散的大型團隊來說，如果能在每次代碼提交時都進行測試和代碼質量分析，其價值將是無法估量的。相比之下，對于地理位置分布較集中的小型團隊來說，這可能就只是一種時間上的浪費，因為這種團隊通常只需要一個構建信息入口。

    一味追求更高的單元測試覆蓋率并不是好事。比如，在一個需求經常發(fā)生急劇變化的、高度動態(tài)的業(yè)務領域中，必須在有限時間內完成一個項目。這種情況下，相比時間與功能，質量可能會處于一個較低的優(yōu)先級。這時，過高的單元測試覆蓋率將是一種精力上的浪費，因為有大量代碼會被直接處理掉。而根據需求編寫最貼切的單元測試會更為有效；然后在對業(yè)務領域有了更好的了解之后，再考慮增加單元測試覆蓋率的問題。另外，技術上也會有所限制，比如當前開發(fā)語言可能并不支持單元測試，而使之支持單元測試的第三方機制又稍顯尷尬（比如在CICS系統(tǒng)中使用.NET包裝器對MQ進行包裝以調用COBOL程序）。因此，所能達到的覆蓋率也是有限的。盡管如此，創(chuàng)建一個可測試的架構、并取得一定程度的單元測試覆蓋率總比什么都不做要好。

    很顯然，無法給任何實現(xiàn)敏捷過程的活動做出廣泛通用的定義。因為每一種活動都是在不同程度上實踐的，而其實踐程度又決定了項目完成時的置信度。

    管理最佳實踐：透明度

    牽涉到完成時的完整性，盡可能詳細地了解正在做的事情就變得很更要。在應用敏捷管理實踐過程中，如果沒有項目管理實踐，那么獲得的將是提交質量上的提升而不是IT響應性的提升。要獲得更好的響應性，就需要使所進行的工作透明化。

    敏捷方法可以通過以下途徑實現(xiàn)透明化：需求的表達方式、團隊的組織方式、協(xié)作方式和過程追蹤方式。當然支持這些的主要敏捷實踐，如用需求卡片表示需求、協(xié)作方式、迭代交付等，并不是全部的解決方案，其本身也需要適當的調整以適應特定的環(huán)境。

    例如，一個地理位置上分散的、幾百人組成的團隊，通常會把項目分解到幾個團隊由其獨立完成，而不是所有人都去研究同一類需求。這些獨立的團隊將影響到需求的實現(xiàn)方式：高層次的需求可能需要多個團隊各自完成一些子部分，而各子部分之間則通過消息來傳遞信息，

管理資料

    此外，還要考慮到項目管理方式的模式化程度。分布集中的團隊可能會體驗到“需求卡片墻”生動地將需求分階段展示出來的好處，它將包括已完成的、待定的、正在實現(xiàn)中的和準備解決的。然而，地理位置分散的團隊無法使用真正的需求卡片“墻”。在此情況下，可以使用項目追蹤報告（比如借用Mingle等工具）使團隊掌握項目狀態(tài)。團隊的分布形式也會影響到業(yè)務的協(xié)調程度。雖然業(yè)務應該與開發(fā)團隊分布于同一地理位置，但對于分散的團隊來說這不可能。但這并不意味著對本地業(yè)務的了解沒有用處，因此可以在本地設置一個業(yè)務代理——如請一位業(yè)務方面的分析專家，可以取得同樣的效果。

    版本發(fā)布計劃的實踐會根據環(huán)境不同而有相當大的變化。在一個高度動態(tài)的領域里，版本發(fā)布計劃基本就是一種“一廂情愿”的想法。在這種情況下發(fā)布計劃很可能會誤導項目的利益相關人并損害團隊的利益。這時，XP方法中的“昨日氣象”法應該是管理發(fā)布過程最安全的方式。在一個較穩(wěn)定的領域里，版本發(fā)布計劃就能在很大程度上改善項目檔案管理。

    另一個需要根據情況考慮的是某種環(huán)境下的緊張程度。Scrum方法可能會對經常在生產中遇到故障或者發(fā)現(xiàn)缺陷從而急需危機管理的項目很有效，我們可以一個中等長度的時間（比如一個月）劃分工作段，在各階段每天舉行站立會議。但對于無法規(guī)律地得到發(fā)布版本的客戶，可能更喜歡敏捷方法中常見的、一致性更好、時間更長的迭代和發(fā)布周期。

    總之，透明度并不是在做任務的時候順便獲得的，而是通過諸多在特定情況下可以最大化透明度的實踐來實現(xiàn)的。

    困難的解決與管理上的約束

    以上所述并不是說敏捷實踐僅僅是一種如何選擇的問題，它還需要考慮更多可驗證的、協(xié)作上的效益。我們需要看到，當這些實踐完全實施以后，質量與響應性都會得到極大的提升。雖然不同種類的敏捷實踐——Crystal、XP、Scrum等——提供了不同的敏捷實現(xiàn)方法，但不等于這些就是全套的解決方案。比如，在一個高度動態(tài)的領域中，XP中的“昨日氣象”預測方法可能有極其重要的價值，但是由于它強調100%的單元測試覆蓋率，因此即使在這樣的環(huán)境下，也可能造成相當大的精力上的浪費。同樣，只采用Scrum管理方法卻沒有相應的敏捷實踐可能導致項目管理與技術執(zhí)行不完全一致。不管采用什么方法，都應該對其有粒度化的了解和調整。

    必須了解敏捷實踐還會受到環(huán)境中各種條件的限制。敏捷實踐通常是為了解決企業(yè)中的一些問題而引入，比如質量、一致性，或者響應性等問題。但如果只解決了問題，卻仍然有各種各樣的約束，是無法產生最佳效果的。比如，敏捷的版本發(fā)布計劃會假定有一個“代碼所有者群體”，整個代碼庫都由這個團隊“掌管”。如果只采用了各團隊獨立的開發(fā)方式，管理方式卻跟不上，就會導致“泳道”式的結果。特別是有高度耦合性的代碼會產生依賴性，而使敏捷發(fā)布計劃變成瀑布模式。同樣，如果質量保證是由處于某一地理位置的一個團隊獨自實現(xiàn)的，那么很可能會使這個團隊疲于奔命，無法及時響應來自敏捷開發(fā)團隊的各種變化。這樣，開發(fā)響應性將完全無法得到提升。

    所以，敏捷方法的采用，既要使敏捷方法適應一個環(huán)境，也要調整環(huán)境使其有更好的響應性。這可能需要重新調整應用架構，并積極地促使開發(fā)人員結對工作以逐漸增加各團隊的工作寬度，同時達到徹底消除特征化代碼的目的。這還可能需要QA部門的徹底改組，研究業(yè)務領域并調查技術能力，使開發(fā)團隊以業(yè)務實現(xiàn)為主要目標，而不是IT實踐。不管最終采用什么方案，都必須以解決問題為主，而不是研究約束條件。各種約束會扼殺甚至徹底排除可能產生更好敏捷性的嘗試。

    與過程相關的人員

    雖然敏捷實踐經過調整適應了環(huán)境，環(huán)境也經過改變開始產生更高的敏捷性，但還有一個過程需要執(zhí)行。只有做這項工作的人掌握了這些變化，才能說這些變化是成功的。因此，在設計敏捷過程的時候，一定要明白個體的價值不是通過上級的命令，而是通過主動參與實現(xiàn)的。設計過程的構建方案是一種可以提高效率的做法，而讓參與者成為這個設計的一部分則是取得成功的根本。