摘要: 关于敏捷方法论的文章已经很多了。其中，相当一部分文章讲述了敏捷方法技术方面的问题，比如测试驱动开发和持续集成。同样，还有相当一部分文章讨论了敏捷 方法论的应用问题，例如发布计划，跟踪生产率，如何使 ...
关于敏捷方法论的文章已经很多了。其中，相当一部分文章讲述了敏捷方法技术方面的问题，比如测试驱动开发和持续集成。同样，还有相当一部分文章讨论了敏捷 方法论的应用问题，例如发布计划，跟踪生产率，如何使用度量数据对过程“调优”，甚至让公司里的业务人员确信需要采纳一种特别的方法。读过这些有关敏捷方 法的文章后，很容易让人产生一种感觉，即通过购买一套工具并遵从一系列看上去很简单的实践，就算采纳了像极限编程和Scrum这样的敏捷方法。然而，现实 世界的经验表明，成功地采纳敏捷要比那复杂得多。它涉及到如何培养一些正确的做事态度来建立信任，鼓励交流与协作，最终让人们更加适应，并产生高效。 敏捷方法常常被描述为以人为中心，而不是强调技术，并有充分的理由来说明这一点。然而，虽然敏捷宣言强 调了“个体和交互胜于过程和工具”的重要性，但它并没有清晰地阐明如何处理这个重要的社会性维度。在强调技术的业务中，这些都太简单，无法概观个人态度在 项目团队中的强大影响力。要想知道哪种态度可以促进（或阻挠）敏捷的采纳，我们要问一个问题：“在成功的开发者和管理者之中，我们能发现那些与众不同的行 为吗？”，更重要的问题是 “这些行为是由什么态度驱动的呢？” 成长中的敏捷开发者 很多开发者习惯于独立工作，花费大部分的时间来阅读规范，并完成设计和编码。在前敏捷环境（pre-agile environment）中，一些开发者甚至戴耳机听音乐，不听来自办公室的“噪音”。采纳极限编程的开发者发现其自身已经融入到更加社会化的环境了，在 这种环境下，成功依赖于与同伴和客户更紧密的协作。另外，经典的前敏捷开发是个体独自“拥有”那些设计和编码。在敏捷环境下，工作任务由团队共同决定： 没有谁能独自拥有某段代码。这种态度的调整可能特别具有挑战性。 刚接触敏捷开发的人可能习惯于在那种将自身划分成子系统再进行开发的项目。他们习惯于依据各子系统之间互联的高层次规范，独自负责某个子系统的设计。刚接 触集体代码所有制的开发者很容易被他们不得不掌握的代码的数量吓倒。与此同时，很少的技术文档（甚至没有技术文档）和快速变化的代码基线（包括那些熟悉的 类名和方法名都有可能在短时间内发生变化）很可能加剧这种情况。但是，敏捷方法论（特别是极限编程）要求编程人员有很强的编码能力。通过对缺乏经验和富有 经验的敏捷开发人员的观察，很容易就可以看出不仅仅是技能问题，态度也是非常关键的。 表1：传统团队与敏捷团队的对比 表一在代码级别上列出了一些传统团队与敏捷团队的不同。富有经验的敏捷开发者有不同的编码方法。他们倾向于灵活编码，而不是等到整个设计都很完善了再进行 开发。另外，他们还倾向于把编码视为学习和探索的机会。例如，遇到一个问题时，他们总是通过编写一个小的概念验证模型或“技术原型（spike solution）”使问题具体化，而不是构建一个复杂的模型或者通过自然语言描述来说明各种行为。同样，敏捷开发者更愿意去阅读第三方的代码。有时候， 他们想做一些力所能及的改进；有时候他们这么做只是为了学习一种新的设计方法。最后，通过尽可能地让类、方法以及与潜在的方法调用链等相互独立，以便仅了 解局部代码就足够了，这样就不用去花很多时间去研究整个子系统或应用。所有这些差异能更好地使开发者发现并处理编码中出现的问题，而不是仅仅使用高超的编 码技能完成任务而已。 拿结对编程为例。对于采纳敏捷方法论（尤其是极限编程）的团队来说，结对编程是最有争议的几个问题之一，因为它需要两个开发人员共同完成同一段代码。虽然 一个开发者可能具有杰出的设计能力并精通开发平台，但作为一个高效的XP开发者，他还必须能够沟通思想，协作进行测试，提供可能的实现方案，并在某个实现 策略上达成共识。很多开发者不愿意进行结对编程，并不是因为他们不会编码，而是因为他们不熟悉结对编程。有个开发者在他的blog中写道：“结对编程会使 他们暴露他们真正的知识和技能水平”。独立编程时，别人只会看到编码结果。而结对编程时，不顺利的开始和早期犯的错误都会被别人看到。这时肯定会有一种压 迫感，甚至对高水平的开发者也是一样，要花上一段时间才能习惯。值得牢记的是：当你了解了其它团队成员，并且熟悉每个参与者的个性之后，结对编程就会变得 容易起来。 大多数成功的极限编程者对使用各种语言编程、学习新的设计方法都相当感兴趣，特别是阅读已存在的代码。这些成功的开发者愿意通过尝试做一些小的练习来“实 践”编码。他们可能会通过编写一些小工具或参与开源项目进行实验。在这里，着重强调“实践”是非常重要的。好的敏捷开发者常常通做一些事情来掌握知识和技 术，而不仅仅通过阅读了解它。 |
