敏捷思维仅仅是用于软件开发吗？再想想！

在这个敏捷已经迅速走红的时代，我们已经在专业服务中看到敏捷的优势，特别是在面对持续的目标变化以及资源挑战的时候。

为什么敏捷能立足于专业服务呢？它针对客户反馈、客户变化以及项目范围都是灵活的，允许你在过程中随时发现问题、解决问题，而不仅仅只能在最后才做这些。

敏捷还可以在一个项目偏离轨道前进行纠正，会更频繁的面对最后期限。

今天我想集中讨论敏捷的三大优势，它们非常适合专业服务驾驶舱：敏捷使得团队合作非常好；敏捷可以将复杂的项目打散成最重要的基础部分；敏捷通过持续过程很快的凸显了价值。

我为人人，人人为我

如果你已经阅读过我写的有关团队博客，你会发现我将团队合作视为成功交付客户成果的关键。敏捷用已被证实的专业服务最佳实践在临时的跨职能团队中分享其知识。跨职能团队避开了传统的简仓效应（近邻的相互隔绝），在会议上为了共同的目标而合作。

由于专业服务团队总是在多个地点办公，无论是当地或者是远程，要实行敏捷是会多一点挑战性的，但还是可以实行的。

在敏捷的跨职能团队中（通常在五到十个成员之间），每个成员的经验和贡献起到更加重要的作用，因为小团队更能激起个人的主动性，不存在闲人。

每个团队成员负责具体的可交付成果，促成了整个工作。所以有一个或者多个成员不在工作，那这很快就会暴露，并且得到及时纠正。

敏捷也推动了更高层次的团队合作，促进团队灵活性，其他团队成员可以帮助完成工作，而这在瀑布开发模式中是根本不会发生的。

为了授权每个组件的负责人，你已经将项目分解成最基本的部分，团队成员对整体项目的理解能力成指数型增长。

当问题出现时，这理解起来是很方便的。使用瀑布模式开发时，你专注于里程碑–打地基，然后是墙壁、屋顶、电气、管道。你不能打破这种进度，因为你必须按照规定顺序完成。

敏捷允许你更进一步打破组件，如果从侧面看，敏捷比瀑布模式更容易纠正错误。瀑布模式中，一个暴露的问题可能几个礼拜都没人发现，只是因为此刻它不在关键路径中。

敏捷可以应用到任何项目中。在这个时候，你获取backlog(待办事项），WIP（制品区），优先级某些项目，决定你接下来想做什么，并且保证这个组件与你最终的目标是一致的。

敏捷是显示实质性进展的好途径，尤其是在面对巨大复杂的目标的时候。团队活力的提升以及高节奏的追踪问题使得团队能完成工作，显现真正的进度。

如果你忠于优先级并且能勤奋的追踪过程中的所有组件，这样你就能提交你真正完成的工作量，你可以在两个礼拜或者两个月的sprint里显现进度，而不管正确的节奏是怎么样的。

像所有成功的企业一样，CA服务正帮助其专家通过学习新而不同的工具不断发展日趋成熟。我们的锤子仍像以往一样有用，但是更新更先进的工具以及更新更进步的思维方式也是有价值的。

我们的专家认为领导者建议客户选择工具以应对特定的挑战，无论是瀑布、敏捷或者是混合型，领导者会根据客户的能力使用我们推荐的工具。敏捷是严重依赖客户参与的，他们会有助于整个敏捷流程，因此我们只针对合适的客户推荐敏捷。

不过将一些敏捷属性应用到瀑布模型是有可能的，导致一种折中的办法，同时给项目带来一些并行性和时间价值阶段。

有关更多基于敏捷方法的替代方法，请参看Adam Frary新的白皮书，为什么传统服务方法对于企业软件项目不再起作用。

本文文字及图片出自 coyee.com