敏捷方法学
这些年以来，已经有一些敏捷方法陆续浮出水面：极限编程（Extreme Programming，XP）、Scrum、Crystal、精益开发方法（Lean Development，LD）、动态系统开发方法（Dynamic System Development Method，DSDM）和特性驱动开发（Feature Driven Development，FDD）等等。尽管这些方法所强调的地方各有千秋，但是它们之间存在一些共同主题：成功完成开发，使设计能够演进，创建健壮的代码，还有，最重要的是通过与客户的交互寻求反馈。
不同的方法对于不同的人来说，意义各有不同。某些人认为，假如你不照本宣科地遵循XP的所有核心实践，那么你就不是在实践XP。XP有一些重要实践，Scrum也有自己的重要实践。此外，还有其它的重要实践可供使用，并取得成功。
开发者们会问：“我应该遵循哪个方法？”“我应该用 XP，还是 Scrum？对于项目出现的不利局面，我该做些什么才能扭转乾坤呢？”这些问题都非常具有实质性，我们将在本文中逐一解决。
为失败的项目引入敏捷特性
方法学常常伴随着一些规程（ceremonies）而来。一些重量级的开发过程会非常规程化（或者说正规化）——它们会要求你遵循一系列的步骤，编写某些文档，等等。假如它真的能为你的成功带来影响的话，一定程度的规程是很好的。通常，敏捷方法会期望你去实践单元测试，举行站立会议（standup meetings）等等。这些同样也是规程，并且敏捷方法支持者们（包括你谦恭的作者）都会表示，这是一些应当遵从的好规程。但是，这些是你应当第一顺序采用的实践方法吗？你应当采用所有提供给你的实践方法吗？你应该立刻全部采用它们吗？不必，当然不必。
让我们打个比方。我们会同意，健康饮食加上锻炼是保持强健体魄的好习惯。然而，如果一个病人患了严重的胸痛，你肯定不会（也不想）听到医生说：“如果你饮食健康并且加强锻炼的话，你就不用到这儿来了。所以说现在给我爬起来，马上来跑步机上锻炼！”这么做着实荒唐可笑，弄不好还可能把病人的性命搞丢。我们必须先将病人稳定下来，直到病情得到改善，才能用强化训练的方法进行调整。
假如你想在出现麻烦的项目中全盘引入敏捷方法，其结果也有可能是全盘皆输。在引入其它优秀的实践之前，让我们先探讨一些能帮助我们重建项目，并使其恢复元气的实践吧。
采用迭代的步伐迈向敏捷
假定你只有几个月时间来完成你的项目，然而项目团队仍远远地落在计划之后。此外，假设你的团队并不熟悉诸如单元测试和持续集成之类的大多数重要的敏捷实践。为这样的团队引入单元测试，可能需要时间理解和熟练应用。尽管单元测试可以带来显著的益处，但是对你的团队来说，目前却可能并非合适的时间。
比较稳健的做法，可以是一个渐进的（迭代且递增的）方式，使你的团队迈向敏捷。在入手解决问题之前，第一件事情应该是去了解问题到底是什么。为什么你的团队会落后于计划？有哪些东西在妨碍他们？至少，世界上所有的好方法都无法马上见效。了解首要和迫切问题是什么，并且解决它们，是很重要的。一旦你解决了首要问题，你就可以继续前进，进行改进和调整。
使用迭代式敏捷方法的尝试
我曾有这样一个机会参与到一个处于危机状态的项目中——一位翘首企盼的客户在为他行将崩溃的项目紧急求援。这个项目进行了很长时间，却成效甚微。整个项目团队并没有采取任何敏捷方法，他们没有进行交流，项目没有迭代周期。他们痛苦地挣扎着，以期能跟上进度，并努力尝试在编写新代码和修正 bug 之间寻找平衡。
他们只剩下很短的几个月来完成这个项目；整个团队陷于一片恐慌之中，项目经理几近绝望。要求团队采取例如单元测试的方法，在当时看起来并不是一个稳当的做法。那么我能尽可能少地采取哪些敏捷方法实践，来为这个项目逆转乾坤呢？根据当时项目和团队的现状，我们决定以其时看来最合乎逻辑的三个方法开始：每周迭代并提交演示版本，每天举行站立会，以及划分优先级和回溯。
每周迭代并提交演示版本
整个团队埋头苦干，发了疯似地想把事情做好。他们看到的项目范围和任务列表上的任何时间满得让人脑袋发晕。团队成员中存在一些合理的顾虑：我应该修改这些 bug 吗？我应该添加新特性吗？该是哪些新特性？那上周我开始着手的东西又该怎么办呢？还有两周前的呢？你要我一口气处理所有这些东西？就在现在？！
如果项目团队能够清楚地专注于他们应该做的工作，那么结果肯定是颇有裨益的。通过确定按照以周为单位的迭代进行工作（不同的敏捷方法推荐一至六周的时间作为迭代周期），我们可以每次定义出一周的工作范围。这样就为团队的每个成员和项目经理提供了一个让大家坐下来制定当前一周工作目标的机会。一旦用于迭代的任务列表被制定下来以后，团队的每个人参与评审。谁也不想搞出一个失败的计划——整个团队都必须统一口径，决定哪些要完成的东西是合理的。
每个周末，我们向可能为项目提供关键性反馈的核心客户进行项目演示。项目团队进行这些演示的目标，就是为了符合客户的期望，每周进行一次。在演示中，项目团队展示哪些东西已经被实际构建出来，阐明他们完成的特性，并且寻求反馈，从而了解哪些可以改进，哪些需要更改。我们也决定哪些任务应当在下周优先执行。
每天举行站立会议
团队的成员们抱怨说，他们能听到的，仅仅是行军号角声，但没有人知道其他人到底走到了那儿。他们之间缺乏有效的交流。
我们在这个项目中引入的第二个方法就是每天举行站立会（最先在 Scrum 方法中提出，并在 XP 中被采用）。每个团队成员都有机会进行一个简短的演讲。他们被要求集中讨论三件事情：前一天他们做了些什么，今天他们打算做些什么，还有哪些东西在妨碍他们（如果有的话）。
这样做使整个团队得以了解每个人在做哪些东西。而且，这对当天的准备也起到帮助作用，促使每个开发人员把重心放在自己当天的任务上。
划分优先级和回溯
一个困扰项目团队的问题是，他们很难将注意力集中在他们应当完成的工作上。开发工作就像玩“抓螃蟹”游戏一样——他们被修复那些看似毫无规律地不断冒出的问题，搞得手忙脚乱。他们主要使用电子邮件报告问题。不幸的是，这些邮件常常丢失，或者被其他堆积成山的正常邮件和垃圾邮件所掩埋。通过使用一个简单的追踪系统，我们可以输入问题和错误，为它们分配优先级，并且检查开发人员的进度。这样也为项目带来了一些好处。
其他实践方法
在这个项目中，我们又进一步引入了其他有用的实践方法，但并不是一蹴而就的。这么做的目的，不是为了变得敏捷，而是为了成功。我们采取了一种为项目团队带来自信的方式进行工作，并且让大家明白项目在前进。我们否决或者推迟了不会带来即时收益的方法，把带来长期收益的方法保留到之后进行。通过遵循一些经过选择的有意义的方法，以及团队的帮助和对成功的恳切追求，项目提前于计划完成了——这在以前是不可想象的。
结语
Ron Jeffries 明智而又贴切地表达了这样一个观点：“采用XP本身并不能带来任何奖励。真正的奖励来自使用正确的实践组合做事，那就是成功。”你要做的，是把注意力集中在如何取得成功上，而不是照本宣科地去实践敏捷。首先，选好能实际解决你问题并且带来进展的实践方法。然后，继续采用其他使你和你的团队变得更好的方法。你怎么知道你做的是正确的呢？除了成功，没有更好的证明方式。
参考文献
Kent Beck and Cynthia Andres, "Extreme Programming Explained: Embrace Change", Addison-Wesley Professional.
Ron Jeffries, nn Anderson, and Chet Hendrickson, "Extreme Programming Installed", Addison-Wesley Professional.
Ken Schwaber and Mike Beedle, "Agile Software Development with SCRUM", Prentice Hall.
Venkat Subramaniam and Andy Hunt, "Practices of an Agile Developer", The Pragmatic Bookshelf.
关于作者
Venkat Subramaniam 博士（venkats@agiledeveloper.com）是 Agile Developer, Inc.的创始人。他培训并指导了美国、加拿大、欧洲和印度的3000多名软件开发人员。Venkat帮助他的客户有效地在软件项目中实施敏捷方法并取得成功，并且他本人多次在大会上进行演讲。同时他是休斯顿大学的助理教员（在那里他获得了2004年计算机系教学优秀奖），此外他还在莱斯大学继续教育学院教授专业软件开发人员系列课程。他是《.NET Gotchas》的作者，以及《Practices of an Agile Developer》的共同作者。
文章来源于领测软件测试网 https://www.ltesting.net/
