有些事情，确实得仔细思考才能搞清楚，才能不会被牵着走。

    软件开发这回事，和管理有关的东西，《人月神话》已经讲透了，只要你在工作中
仔细观察，认真思考，多做实验，隔个半载一年把这本书再读一遍，你对软件开发
管理这件事情的认识上不会走弯路，不会被忽悠。

    关于如何才能做好软件这件事情上，其实没啥新东西，只有角度不同，CMM从一个试图
从一个角度来描述这个问题，敏捷只是从另外一个角度描述而已。CMM的黑暗面在于，
试图让人们相信，只要遵循了过程能做出好的软件。敏捷的发起本来是想强调过程
应该服务于人，服务于团队，强调产品质量本身，而非过程质量，但是这个黑暗面实在
是太强大了，以至于现在的敏捷几乎沦为自己本来希望避免的东西。

     Scrum的流行是一个实证，在很多人眼里，Scrum现在等同于敏捷。一些的XPer

开玩笑说：Scrum是一个阉割了技术实践的XP。的确，没了这些技术实践，敏捷很容易做。

而总是选择做容易的事情是大的问题所在。

     从2006年，有人说Scrum将杀死敏捷开始，到如今，敏捷基本上已经成了一个“负面”词，
成为大家在各种场合调侃的对象。为什么每种方法都难逃这种宿命？

     一个新方法的提出并不都是为了解决或者补充现有方法存在的问题或者不足，有时更多的是

提醒人们不要陷入“黑暗面”的陷阱。敏捷是如此。一些“原力”比较强大的人试图把人们从黑暗面中拉出来，发出了敏捷宣言这样的呐喊。于是，一小撮原力相对强大的人被唤醒，加入到呐喊

的队伍中，随着这个队伍的逐渐壮大，商机出现了。

      其实，敏捷宣言之于软件开发像“早睡早起”之于健康一样，都是一些基础的常识。当人

们清醒过来了，明白了，注意一点，干自己的事情完了。但是仅仅说敏捷是个呐喊，是

个提醒显然没啥商业利益可图，必须要包装，炒作。

       包装的第一步是混淆，比如：把“早睡早起”等同于健康，也是把一些敏捷中的一些提醒

等同于成功，为了使得内容看起来更丰富，更具吸引力，再另外“臆想”出一些内容。第二步，

为了增加诱惑力，设计出一些容易操作的实践步骤，给人造成按照这种步骤做了敏捷了的感觉。

他们在宣传中不断地增强这种暗示。

       也许你会发现，这些实践确实有点作用，此时一定要谨慎，你得仔细想想到底是什么在其作用，是这些实践吗？比如：有人说结对编程很有用，很好。结果发现是因为结对了，大家都不好意

思QQ、MSN、IM了，所以造成效率提升（代码量上去了）的结果，根本不是由于结对编程强

调的评审和简单设计带来的质量的提升。

       如果你做的事情本来很简单，用什么方法都无所谓，如果你做的事情很难，那么什么方法也

帮不到你。过程方法成功与否之说根本是错误的，成功和失败的只是你自己的开发团队。

当然，有些“负责”的商业机构也会在合适的场合和时机说，我们可从没说过这样做
能做好软件了，你这样想是你的问题。

      你总是把人往河边引，然后人掉河里了，你说完全是别人的问题。另外，你要是给人说实话，

人家会找你吗？所以说，如果你在敏捷刚刚开始时，听说了敏捷，并且你在工作中是一个勤于思考的人，那么你会有心有戚戚的共鸣，但是会有些寂寞。如果你是在近几年才被敏捷了，只能说有些可怜了。

       其实为啥我们总是期望寻找银弹，为啥我们这么容易被忽悠，为啥我们这么容易被诱惑，

归根到底是我们不理解软件开发活动这件事。理解软件开发活动不是一个静态的结果，

而是一个持续的、动态的学习过程。学习的方法是坚持参与编程、坚持思考编程

这件事。作为一个软件开发项目的管理者，我认为其首要管理任务是参与编程。有人

说，管理者很忙，有很多事情要处理，没时间编程。那你有没有想过，这些让你忙的事

情是不是因为你不参与编程，以至于不理解软件开发这件事造成的？有人说我也曾经编

过程序的，正是还没有理解软件开发这件事，所以才会这么说。

        只有你真正参与了，你才能真正感受到软件产品中各个要素的流动和交互，才能明白真正的问题所在，才能找到做好事情的方法，才能知道什么是真正的健康。如果一个软件开发项目的管理者，不参与编程，是自废武功。没有银弹，软件开发是件极其困难的事情，根本解决之道是人的能力的提升，这是一个漫长的学习、实践的过程。我们大家都要有清醒的认识和坚持，这样做了，质量和效率的提升是自然而然的事情。

        如果说，以“文档化”来推动CMM是个悲剧的话，那么以“娱乐化”来推动敏捷是一场闹剧。