问题之二：工作团队过于庞大
我经常遇到这种情况：一支处理定义工作的团队被建立起来，会议被预定、里程碑被确定——机构就最终的目标达成了一致。这并不是一种敏捷的方法。尽管这类方法可能代表大多数公司的文化，但是它较之最适宜相距甚远，并且您应当努力避免这种反模式。更糟糕的是，团队经常会过于庞大，这是因为每一个领域都有可能使用新的、小型的处理过程框架潜在的增加工作量。这导致臃肿的团队很难就某件事情作出一致的决定。每个人都声称“自己是不同的”，并且每当作出变更时都会有人提出“这将不适合我们”。
一种被客户端反复地有效处理的方法就是，从整个项目中找到一个在这个“较小型的”范畴中所占比重最大的区域。一个客户端站点拥有一个开发区域，它专门关注一个频繁需要更新的面向外部的网络应用程序。令人惊愕的是，他们拥有一个轻量的处理过程，并且很高兴地同意协作定义一个最小化的处理过程，而这个处理过程的使用完全不会向他们的项目中引入一个不可接受的风险级别。我们能够用几周的时间裁剪一个更小型的、更敏捷的标准处理过程版本。这个版本并不是整个机构中的每个人所最终需要的东西，但是它为我们提供了一个基于实际结果的起步点。这一方法并不能一下子解决所有问题，但是它能够结束没完没了的会议和谈判。
问题之三：工作团队的成员缺乏近期的经验
被典型地分配到这些努力的代表通常都拥有“项目经理”或者“领导者”的头衔。这些都是具备丰富经验的高级人员。然而，大多数人却是在很长一段时间里没有从事过开发软件的工作了。他们的角色往往就是从一个会议到另一个会议，表现他们的功能区域以及汇报他们的进展情况、风险和问题。
其结果就是本应在几周内完成的事情现在却需要花上几个月的时间。由于他们不具备使用现已存在的处理过程的经验，所以即使是很小的细节都要在作出任何决定之前进行没完没了的讨论。最后的结果往往就是标准处理过程的一个略微小型的定制版本并没有在实践中为项目团队提供太多的帮助。我曾经看到过这种方法使得公司花费了大量的金钱，但是用户却只得到了很小的投资回报。
制作一个较小型的、更加敏捷的 RUP 版本的团队必须由项目的从业者所组成，这些人已经通过将其所在机构的标准版本的 RUP 使用在实际的项目中从而积累了经验和教训。这些人感到痛苦的原因就在于缺乏处理过程的最优化，以便使得他们能够向出资方提供高质量的、可使用的应用程序。对于一个近期的客户，我们能够选择一些参与过最初的 RUP 项目的团队成员作为我们在这一“领域”中的专家。他们对于处理过程在实际的项目中的管理费用是如何扼杀小型的工作量这一问题提供了深入的见解。某些我们最初在内部审计和依从代表方面所遇到的障碍都将迎刃而解。抽象的讨论一个问题是一回事，实际去做又是另外一回事。当人们亲身经历过现实生活中的痛苦之后，是很难用理论案例来战胜他们的实际需求的。
以上这些只是我所看到的一些机构在试图将敏捷性引入其“标准”的 RUP 的过程中所常见的三个问题。我将在后续的文章中继续展开关于解决/避免这三个问题的讨论。
地理上分布式的敏捷团队：使个体以及它同处理过程和工具之间的交互发挥作用
由 Julian Holmes 撰写
许多敏捷的技术和迭代的方法都将项目团队跨学科协作所提出的需求引入到软件开发之中。当我们考虑迭代计划和开发的实践时，当敏捷团队将文档的使用最小化为团队成员之间沟通的方法时，这种协作就变得尤其重要。
这是由于他们这种有效的协作，即小型的同处一地的团队采用每天例会的方法不断地将每个人的努力综合起来，相比地理上分布的团队来说能够更加成功地向客户交付连续的价值。
然而，不同的业务策略和压力能够导致一个机构没有能力以同处一地的方式处理每一个项目。我们可以举出许多这样的例子：
- 办公室空间的限制；
- 所需要的专业技术不能由本地所提供；
- 客户和项目位于不同的地方；
- 外包策略利用了第三方提供商所提供的特定技巧集；
- 海外发展策略打破了远和近的界限；
- 等等……
所以一个机构如何才能在分布式的情况下实现潜在的协作和敏捷技术呢？这个问题由于 Dr. Dobb's Journal 于 2007 年所撰写的 Agile Adoption Survey 而尤其引起关注。 4 他发现某些机构正在试图以分布式团队的方式变得敏捷；其中一些获得了成功，然而他们的成功率却低于同处一地的团队。
敏捷的实践为软件开发项目中所需要完成的工作提供了极好的结构化方法。然而，它们几乎都依赖于以一种一致的和高质量的方式执行实际软件开发工作的团队的经验和协作。一旦该团队被分散，保持团队工作的方法、交付、甚至其活动和交付之间沟通的一致性就会成为一个巨大的挑战。
这些团队所面临的大多数挑战都是和保持分布式团队之间的协作这一困难相关的，其中三个关键的挑战就是：
- 如何开发一个协作的团队文化？
- 如何保持方法和交付的一致性？
- 如何管理共享工作产品的开发？
