敏捷开发初学体会

这篇文是7月份左右写的了，回头看写得还可以，所以发出来，以供大家讨论。

    刚接触敏捷开发一词时，难以理解它。总觉得它是一种新的项目管理方式，以为它有一套解救我们程序猿的完整方法。所以看书时越看越迷惑，总觉得每本书都没说到点子上，只说一些思路和概念。 这周参加了公司的敏捷培训，虽然课上内容还是重复了书上看到的，但是一些练习加上与同学们的交流，我发现开始悟到了一点东西。所以在这里记下来，作为分享也好，作为自己的笔记也好。

    敏捷开发这个词，翻译得很不好，但也翻译得很好。不好之处在于看词无法了解到这种开发是什么，翻译得好是敏捷一词在深意上的确与这种思维高度吻合。综合起来，我觉得应该叫做“敏捷的开发思维”。敏捷，指的是在变化中快速做出反应以应对不断出现的变化，而反应做得越快就越是敏捷。就如人们从前打猎时一样，猎物不可能站着不动等你来抓，也不可能按你要求的路线跑。所以猎人就要因应猎物的反应而作出反应，甚至因应环境而改变猎杀的目标。敏捷开发就是这种思路。需求虽然听起来是一样东西，但是它却是不断变化的。程序员总抱怨给需求的人想法变得快，但是事实上需求本身就是在变化的。如果需求分析者不因应环境而变更需求，那最终出来的东西也只不过是垃圾，虽然它是完成了，也只不过是完整，精美的垃圾。得到“需求会不断变化”这一点共识后，事情似乎就简单得多了，人只要不断地将自己正在作的事情与需求做对比就行了，就像猎人打猎时一样，根据目标做出最快的调整。

    如果软件是由一个人做的，那咱们的研究就可以结束了。可是，真实世界不是这样的，一个软件不可能只由一个人完成。时间越向后推移，软件的规模就越大，越需要多人协作来完成。敏捷开发出现的原因就是在于这一点，总结起来，我想所有实践都是围绕着怎么让多个人在面对不断的变化时表现得像一个人一样，或者是说作出反应的时间是所有人一致的。一群人跟一个人在作出反应的条件中有什么主要的区别?我认为是信息的掌握程度。一个人时，他掌握了这一件事的所有信息（仅指他需要的信息），表示他已经有作出判断的条件。而一群人协作时，往往每个人只掌握部分信息，而别人手上的信息却又是这个人作出判断的依据。比如需求分析师拿到了需求变更的内容，而程序员却一无所知地按旧需求在开发，测试也在写着测试用例。所以我认为，敏捷开发的很多实践，都是想尽办法让信息流通起来，以最快的速度让项目成员掌握他们需要的信息。站立会，看板，测试尽早介入等，这些都是为了让大家尽早得到可以判断下一步动作的信息。持续集成，自动化测试之类的，是借用机器来尽早告诉人，刚才做的事情是对的还是错的。如果从这个角度去看敏捷，那事情就容易理解得多了。各种实践是一种参与，而如何才能将信息最好最快地传递，则还是需要因地制宜的，每家公司，每个项目，每个团队都不太一样。

    除了让信息流动之外，敏捷还在尽力做的，就是去中心化。以前的项目都是由项目经理或少数几个人作为项目的“脑袋”，向执行者发号司令。虽然敏捷想尽了一切办法让信息流动，也想尽办法让“脑袋”了解一切，可是人的能力还是有限的，不可能处理全信息。当大家尝试为这个“大脑”增加人手以应对处理量时，却发现信息又不再能同步了。而另一方面，参与软件开发的同事们都是绝顶聪明的人，每家公司都想尽办法招聘有想法，又聪明的人员加入。可是当他们进入公司后，却又想尽一切办法让他们很听话地按步就班地工作，让他们只做最小程度的决定。这是何等矛盾啊?敏捷的团队强调没有“命令”，一切都是自发的，PO看起来是权力所有者，但实际上还是各司其职，做自己职责内的决定。SM被很多人看成是从前的项目经理，但是其实他就是球场上那位不上场比赛的教练。他只是为大家指明方式，解决让成员不能全力施展能力的一切问题，可是他不下命令，也不卷起袖子参与项目细节。事实上，大量的决策是由团队自行作出的，很多技术细节是由团队自行处理的。回想起《失控》，最好的机器人并不是将所有的信息传到一个中央处理中心，而是让分散的部件和处理器自行处理它自己的行为，我们唯一要做的是让这些处理器知道整个身体当前的情况，而且是这个部件所需知道的情况。这不就是敏捷开发正在做的吗?每个人都是整个项目中的部件，而每个人都只需要知道他必需知道的信息，剩下的交给他聪明的大脑去处理就行了。

    扩大到企业管理，未来的企业是否也应该以“敏捷”的方式管理，去中心化?CEO只需要指出方向，然后一切交给成千上万的分散组织。唯一要做的是让这些组织实时分享到一切他们所需的信息。处理和应对则可以全权交给他们自己。如何做得到让庞大的信息量在企业内部流动?我想信聪明的人类一定能找到这样的工具，就像敏捷的先行者们找到了许多工具和实践让敏捷团队更为敏捷。