面向 IT 经理的敏捷入门

在最近一期《CIO》杂志中，John Paul Mueller 发表了一篇新文章《 ABC: An Introduction to Agile Programming（敏捷开发入门）》，向 IT 经理们介绍了敏捷方法的总体概念。John 简明扼要地为刚刚听说敏捷的人们回答了以下问题：

• 使用敏捷的商业原因是什么？
• 是什么似的敏捷开发与众不同？
• 我是否需要完成许多额外工作？
• 除了按迭代工作以外，还存在哪些不同？
• 以这种方式进行工作，难道不会改变我们的企业文化吗？
• 在哪些情况下应当避免使用敏捷开发技术？
• 敏捷开发只存在一种模式吗？

文章中对敏捷实践的称道溢于言表，但 John 在回答“在哪些情况下应当避免使用敏捷开发技术？”时举了一些范例。John 列举了 IT 经理必须避免使用敏捷方法的四种情况：

• 创建的是一个大型应用，这个应用无法被分解成一个个小部分。
• 需要进行分布式开发的应用
• 构建的是一个关键任务应用，应用的每个部分都必须在一开始能够正常工作。
• 公司的管理方式如果是命令 - 控制型的

尽管管理层对上述情况存在忧虑可以理解，但 Joshua Kerievsky 对此表态到：

要是在 2001 年，您在“在哪些情况下应当避免使用敏捷开发技术？”一节中提到的内容确实无可厚非，但直到 2007 年还这么说就显得有失偏颇了……在 XP/ 敏捷世界中，关于 XP/ 敏捷对于超过 20 人的团队或者分布式项目水土不服的说话，早已被证明是无稽之谈了……

Industry Logic（我所在的公司）的开发工作百分之百使用了分布式 XP，结果令我们相当满意。我们使用实时计划软件（ProjectCards）举行分布式计划会议（Distributed Planning Sessions），使用 Skype 进行语音和视频会议，使用 VNC 共享桌面，并使用共享知识库（Repository）来整合我们的工作。这一切都运转得非常顺畅，以至于我们现在雇人的时候都不需要关心地理问题，因为我们很清楚，通过分布式敏捷，我们可以和来自世界各地优秀的人们协同工作。

这是一个强有力的反驳观点。然而，尽管有 Joshua 的成功经验，任何第一次采用敏捷实践的组织，都不应当低估在分布式开发团队中实施敏捷或者在一个大型关键任务应用中推行敏捷的难度。尤其值得注意的是，在组织内部进行敏捷实践探索的人们应当多加留心 John 的第四个例子——管理方式属于命令 - 控制型的公司。这是一个大问题的其中一部分：试图在一个坦率真诚的沟通不被重视的组织内推行坦率和真诚的沟通。改变组织内部的价值系统，必须不断朝社区建设的方向进行努力。通常，除了最有进取心的敏捷团队以外，一般开发团队很少将眼光投向这个层面。