如果你是这几年才听说敏捷的，真是挺“可怜的”
邓辉
我承认，我标题党了，呵呵。
不过，有些事情，确实得仔细思考才能搞清楚，才能不会被牵着走。
软件开发这回事，和管理有关的东西，《人月神话》已经讲透了，只要你在工作中
仔细观察，认真思考，多做实验，隔个半载一年把这本书再读一遍，你对软件开发
管理这件事情的认识上就不会走弯路，不会被忽悠。
关于如何才能做好软件这件事情上，其实没啥新东西，只有角度不同，CMM从一个试图
从一个角度来描述这个问题，敏捷只是从另外一个角度描述而已。CMM的黑暗面在于，
试图让人们相信，只要遵循了过程就能做出好的软件。敏捷的发起本来是想强调过程
应该服务于人，服务于团队，强调产品质量本身，而非过程质量，但是这个黑暗面实在
是太强大了，以至于现在的敏捷几乎沦为自己本来希望避免的东西。
Scrum的流行就是一个实证，在很多人眼里，Scrum现在就等同于敏捷。一些资深的XPer
开玩笑说：Scrum就是一个阉割了技术实践的XP。的确，没了这些技术实践，敏捷很容易做。
而总是选择做容易的事情是最大的问题所在
从2006年，有人说Scrum将杀死敏捷开始，到如今，敏捷基本上已经成了一个“负面”词，
成为大家在各种场合调侃的对象。为什么每种方法都难逃这种宿命？
一个新方法的提出并不都是为了解决或者补充现有方法存在的问题或者不足，有时更多的是
提醒人们不要陷入“黑暗面”的陷阱。敏捷就是如此。一些“原力”比较强大的人试图把人们从黑暗
面中拉出来，发出了敏捷宣言这样的呐喊。于是，一小撮原力相对强大的人被唤醒，加入到呐喊
的队伍中，随着这个队伍的逐渐壮大，商机出现了。
其实，敏捷宣言之于软件开发就像“早睡早起”之于健康一样，都是一些基础的常识。当人
们清醒过来了，明白了，注意一点，干自己的事情就完了。但是仅仅说敏捷是个呐喊，是
个提醒显然没啥商业利益可图，必须要包装，炒作。
包装的第一步就是混淆，比如：把“早睡早起”等同于健康，也就是把一些敏捷中的一些提醒
等同于成功，为了使得内容看起来更丰富，更具吸引力，再另外“臆想”出一些内容。第二步，
为了增加诱惑力，设计出一些容易操作的实践步骤，给人造成按照这种步骤做了就敏捷了的感觉。
他们在宣传中不断地增强这种暗示。
也许你会发现，这些实践确实有点作用，此时一定要谨慎，你得仔细想想到底是什么在其作用，
是这些实践吗？比如：有人说结对编程很有用，很好。结果发现是因为结对了，大家都不好意
思QQ、MSN、IM了，所以造成效率提升（代码量上去了）的结果，根本不是由于结对编程强
调的评审和简单设计带来的质量的提升。
如果你做的事情本来就很简单，用什么方法都无所谓，如果你做的事情很难，那么什么方法也
帮不到你。过程方法成功与否之说根本就是错误的，成功和失败的只是你自己的开发团队。
当然，有些“负责”的商业机构也会在合适的场合和时机说，我们可从没说过这样做就
能做好软件了，你这样想是你的问题。
靠，你总是把人往河边引，然后人掉河里了，你说完全是别人的问题。另外，你要是给人说实话，
人家会找你吗
所以说，如果你在敏捷刚刚开始时，听说了敏捷，并且你在工作中是一个勤于思考的人，那么你会
有心有戚戚的共鸣，但是会有些寂寞。如果你是在最近几年才被敏捷了，只能说有些可怜了。
其实为啥我们总是期望寻找银弹，为啥我们这么容易被忽悠，为啥我们这么容易被诱惑，
归根到底是我们不理解软件开发活动这件事。理解软件开发活动不是一个静态的结果，
而是一个持续的、动态的学习过程。学习的唯一方法就是坚持参与编程、坚持思考编程
这件事。作为一个软件开发项目的管理者，我认为其首要管理任务就是参与编程。有人
说，管理者很忙，有很多事情要处理，没时间编程。那你有没有想过，这些让你忙的事
情是不是因为你不参与编程，以至于不理解软件开发这件事造成的？有人说我也曾经编
过程序的，正是还没有理解软件开发这件事，所以才会这么说。
只有你真正参与了，你才能真正感受到软件产品中各个要素的流动和交互，才能明白真正
的问题所在，才能找到做好事情的方法,才能知道什么是真正的健康。
如果一个软件开发项目的管理者，不参与编程，就是自废武功。
没有银弹，软件开发是件极其困难的事情，根本解决之道就是人的能力的提升，这是一个
漫长的学习、实践的过程。我们大家都要有清醒的认识和坚持，这样做了，质量和效率的
提升是自然而然的事情。
如果说，以“文档化”来推动CMM是个悲剧的话，那么以“娱乐化”来推动敏捷就是一场闹剧。
May the force be with you！