問題之二：工作團隊過于龐大
我經常遇到這種情況：一支處理定義工作的團隊被建立起來，會議被預定、里程碑被確定——機構就最終的目標達成了一致。這并不是一種敏捷的方法。盡管這類方法可能代表大多數公司的文化，但是它較之最適宜相距甚遠，并且您應當努力避免這種反模式。更糟糕的是，團隊經常會過于龐大，這是因為每一個領域都有可能使用新的、小型的處理過程框架潛在的增加工作量。這導致臃腫的團隊很難就某件事情作出一致的決定。每個人都聲稱“自己是不同的”，并且每當作出變更時都會有人提出“這將不適合我們”。
一種被客戶端反復地有效處理的方法就是，從整個項目中找到一個在這個“較小型的”范疇中所占比重最大的區域。一個客戶端站點擁有一個開發區域，它專門關注一個頻繁需要更新的面向外部的網絡應用程序。令人驚愕的是，他們擁有一個輕量的處理過程，并且很高興地同意協作定義一個最小化的處理過程，而這個處理過程的使用完全不會向他們的項目中引入一個不可接受的風險級別。我們能夠用幾周的時間裁剪一個更小型的、更敏捷的標準處理過程版本。這個版本并不是整個機構中的每個人所最終需要的東西，但是它為我們提供了一個基于實際結果的起步點。這一方法并不能一下子解決所有問題，但是它能夠結束沒完沒了的會議和談判。
問題之三：工作團隊的成員缺乏近期的經驗
被典型地分配到這些努力的代表通常都擁有“項目經理”或者“領導者”的頭銜。這些都是具備豐富經驗的高級人員。然而，大多數人卻是在很長一段時間里沒有從事過開發軟件的工作了。他們的角色往往就是從一個會議到另一個會議，表現他們的功能區域以及匯報他們的進展情況、風險和問題。
其結果就是本應在幾周內完成的事情現在卻需要花上幾個月的時間。由于他們不具備使用現已存在的處理過程的經驗，所以即使是很小的細節都要在作出任何決定之前進行沒完沒了的討論。最后的結果往往就是標準處理過程的一個略微小型的定制版本并沒有在實踐中為項目團隊提供太多的幫助。我曾經看到過這種方法使得公司花費了大量的金錢，但是用戶卻只得到了很小的投資回報。
制作一個較小型的、更加敏捷的 RUP 版本的團隊必須由項目的從業者所組成，這些人已經通過將其所在機構的標準版本的 RUP 使用在實際的項目中從而積累了經驗和教訓。這些人感到痛苦的原因就在于缺乏處理過程的最優化，以便使得他們能夠向出資方提供高質量的、可使用的應用程序。對于一個近期的客戶，我們能夠選擇一些參與過最初的 RUP 項目的團隊成員作為我們在這一“領域”中的專家。他們對于處理過程在實際的項目中的管理費用是如何扼殺小型的工作量這一問題提供了深入的見解。某些我們最初在內部審計和依從代表方面所遇到的障礙都將迎刃而解。抽象的討論一個問題是一回事，實際去做又是另外一回事。當人們親身經歷過現實生活中的痛苦之后，是很難用理論案例來戰勝他們的實際需求的。
以上這些只是我所看到的一些機構在試圖將敏捷性引入其“標準”的 RUP 的過程中所常見的三個問題。我將在后續的文章中繼續展開關于解決/避免這三個問題的討論。
地理上分布式的敏捷團隊：使個體以及它同處理過程和工具之間的交互發揮作用
由 Julian Holmes 撰寫
許多敏捷的技術和迭代的方法都將項目團隊跨學科協作所提出的需求引入到軟件開發之中。當我們考慮迭代計劃和開發的實踐時，當敏捷團隊將文檔的使用最小化為團隊成員之間溝通的方法時，這種協作就變得尤其重要。
這是由于他們這種有效的協作，即小型的同處一地的團隊采用每天例會的方法不斷地將每個人的努力綜合起來，相比地理上分布的團隊來說能夠更加成功地向客戶交付連續的價值。
然而，不同的業務策略和壓力能夠導致一個機構沒有能力以同處一地的方式處理每一個項目。我們可以舉出許多這樣的例子：
- 辦公室空間的限制；
- 所需要的專業技術不能由本地所提供；
- 客戶和項目位于不同的地方；
- 外包策略利用了第三方提供商所提供的特定技巧集；
- 海外發展策略打破了遠和近的界限；
- 等等……
所以一個機構如何才能在分布式的情況下實現潛在的協作和敏捷技術呢？這個問題由于 Dr. Dobb's Journal 于 2007 年所撰寫的 Agile Adoption Survey 而尤其引起關注。 4 他發現某些機構正在試圖以分布式團隊的方式變得敏捷；其中一些獲得了成功，然而他們的成功率卻低于同處一地的團隊。
敏捷的實踐為軟件開發項目中所需要完成的工作提供了極好的結構化方法。然而，它們幾乎都依賴于以一種一致的和高質量的方式執行實際軟件開發工作的團隊的經驗和協作。一旦該團隊被分散，保持團隊工作的方法、交付、甚至其活動和交付之間溝通的一致性就會成為一個巨大的挑戰。
這些團隊所面臨的大多數挑戰都是和保持分布式團隊之間的協作這一困難相關的，其中三個關鍵的挑戰就是：
- 如何開發一個協作的團隊文化？
- 如何保持方法和交付的一致性？
- 如何管理共享工作產品的開發？
