花儿@Oscar Dream makes me always full of confidence…

敏捷软件开发日益得到各方追捧。但是，“敏捷”二字到底意味着什么呢？是单元测试，持续集成，还是遵循 XP 或者 Scrum？在本文中，我们将探讨如何将敏捷方法引入出现问题和尚未使用敏捷方法的项目中。

敏捷方法学
这些年以来，已经有一些敏捷方法陆续浮出水面：极限编程（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》的共同作者。
译者 Jason Lai 发布于 http://www.infoq.com/cn/articles/Being-Agile-Without-Going

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Max__Payne/archive/2008/12/26/3616179.aspx

为了探寻敏捷实践的技术内幕，这个阶段，看了不少文章，癫狂啊癫狂。。。整理了一些关于 敏捷项目管理，敏捷实践的文章内容。基本都是转载，期间也许会加载几篇原创。看完这些，相信门外汉也能小有精通了。

休假期间回了躺北京，见了很多同学，坐在colin的“马车”里一路找回忆。路过鸟巢，我看到一旁的奥体中心，开始“炫耀”起来，所以在兄弟们的建议下我决定还是写出来留个回忆。

2003年3月27，微软“新一代软件技术”大会我来过一次。虽然之后也陆续参加过不少微软的技术大会，但是这一天我见到了所有人的偶像Bill Gates，对于刚接触这一领域的我来说，在那个年代参加这个活动，见到Bill真是一个难以形容的化学反应。热血沸腾了好久好久，这一天也自然成为难忘的一天。

找了些老照片，哈哈 回忆一下

会场内外：

认识了传说中的天才张亚勤博士

第一次听说了.net

终于见到了传说种的Bill

还有第一次见到日后的偶像李开复 

一切都还记得很清楚，还是让我热血沸腾，这一天对我的激励我觉得很难度量，但是这一天会永远伴随我。

周末，天气不错，好朋友，放声歌唱。

痛快痛快。

苏打绿，五月天，阿岳，阿信，张学友，张国荣，好多好多…

放松心情，很开心。

新的一周积累好充沛的战斗力。。加油~~

青峰的妖娆不羁

小威的可爱

阿贡的古典美丽

阿福的憨厚幽默

嘉凯的腼腆专注

馨怡的与众不同

当然还有爱睡的玮哲老师的诙谐幽默

我喜欢苏打绿，因为他们是一群将梦想能坚持到底的年轻人

我喜欢青峰，因为他毫不吝惜表达自己的情感，他的真实能感动所有人

我喜欢他们的音乐，因为在这里我能找到与众不同，找到让我共鸣的许多…

我会成长并获得成就感吗？

“Don’t grow old; grow up”，成长不应该只是年龄的变化，应该是我们的灵魂。

一个人的成长包括能力的成长，阅历的成长和智慧的成长。

“活到老，学到老”时时回响在我们耳边，人生成长没有止境，也正以为如此，人生才充满乐趣和惊喜，因为我们总能发现新的领域并且从学习中得到乐趣。

善于成长的人是那种对生命充满热情和渴望的人，即使在困顿之中，他也知道未来有着各种不可知的机会在等待他。

成长的人关心的不是自己的物质财富的增长，而是自己能力和智慧的增加。他们更加懂得如何长久地把精神上的丰富和物质上的丰富结合起来。

成长是一种心态，当我们拥有一种积极向上，充满好奇和探索精神的心态时，便拥有了成长的土壤和种子。

在成长过程中不断获得成就感来激励自己。成就感存在于每天的学习，生活和工作中，是我们走向未来的兴奋剂。每一天过好了，就能过好一辈子；每一天有所收获，一生就有大的成就。

大家在体验新产品的时候往往有一种经验，作为菜鸟，我如何快速读懂这个产品，快速成为中级用户是对一个产品质量的最佳体现。往往所有产品都会提供一份无比详细，充满文字图示的help文档。但是往往这些死气沉沉的长篇大论是无法让人长期依赖。开发方面也常常无法让help的内容跟上产品更新的速度。这让help文档很快成为了产品环节的一个鸡肋。

最近在体验facebook的过程中，发现了一些简单但是非常悦目的体验，请看如下图示：

1.我们在产品中如果有新特性，如果友好的让客户知晓，难道只有通过频繁的邮件或者是传统的发布list来告知用户吗，如果只有这些客户又会花多少耐心来听取这些呢，我们看这个案例：

这里是一个 添加 Badge的预留位，当客户看到这个特性预留位，尝试性的会点击这个提示。

2.点击后大家直觉会跳到哪里呢，是不是大家都觉得跳去 create Badge页面呢？ok，我们看第二个图示：

确实与我们的第一直觉有些异同，我们可以看到这个跳转是来到了一个简单的介绍页面，其实就是我们所谓的help。在这个页面，我们看到一些简单的图示加以文字介绍让用户在最短的时间内忍受了help的冲击，顺理成章的接受了这个特性的洗脑。在了解了什么是“Badge”之后，我们可以从这个页面选择Creater Badge，跳转到真正的Create页面。这么做避免了过于“理性”跳转，即使让客户进入了Create页面，用户在未对新特性有完全了解的前提下，猜疑和不信任的心里会让客户轻易的放弃此功能。所以在加入中间这个简单的过度跳转，让客户有了非常好的体验。

总结一下这个简单的体验，其实我们在开发我们的产品过程总会有一个心态。希望我们的产品特性以最小的推广代价让客户了解，并且希望以最小的沟通代价让客户迅速摆脱菜鸟阶段。这时候我们必然要依赖help文档，但是我们如何将这两者发挥到极致，我们需要的就是分流我们的help，让help无处不再，让help变得更加人性化，用不超过用户忍耐程度help去征服用户。通过这些我们就让原本鸡肋的help从此走向无与伦比的美丽。