敏捷，但不简单

企业里面都在喊敏捷开发，仿佛敏捷就是一切提升效率的源泉。

但其实实施敏捷开发并不简单，甚至很多企业、很多团队都在实施一种“伪敏捷”。“伪敏捷”非但不能真正提高效率，反而让组员频繁返工，影响产品质量，从而导致产品的失败。

在实施敏捷方法中，不可避免会由一些仪式，而过度关注这些仪式反而有时会掩盖了敏捷的核心思想，就是迭代式地对反馈进行回应。我们不需要过度的计划，不需要过度的设计，也不需要过度的架构。我们已经看到了这一点，但如果我们稍不留意，就会从光谱的一边跑到相反的另一边。在这一边的做法是繁重的前期计划与设计，或者说瀑布模型或其它传统方式。而另一边的做法是完全不考虑任何东西、不进行任何设计、不进行任何头脑风暴，只是沿着车轮前进，不断踩下油门，前进、前进、前进，编码、编码、编码，测试、测试、测试……我们天真地相信这种方式最终会带来良好的结果。但其实这两种极端都不是正确的方式。

软件开发是一件艺术创作，绝不是谁都可以胜任的简单工作。在真正动手编码前，你需要做很多的思考。我们的前进方向是什么？这个模块与API看起来应该是怎样的？我们所需要处理的关注点是什么，到底是难以为它编写测试，还是说我们根本不知道要为什么编写测试？所以，当思考遇到难题，我们或许应当退一步，找一个房间，挂起一块白板，把一切设计都画在上面。但我们不是要将这些图形转变为重量级的正规UML文档，进行轻量级的架构与设计是完全有可能的，但首先你要意识到，在开始动手敲键盘之前，工作应当已经在你的头脑中进行了。

因此，就像软件工程中的所有问题一样，软件开发没有银弹。在这两个极端之间必定存在着某个适合你团队的正确答案，你必须把问题放到你所试图解决的问题上下文中以找到答案，也就是你需要多少架构实践、以及多少文档工作才能最终实现你的目标。如果你能够退一步，将敏捷当作某种保持反馈循环运作的手段，即获取反馈、对它进行回应、进行方向修正、并打造正确的产品，那么剩余的部分会自动朝着正确的方向前进。反之，如果是每日站会走走形式，或者压根不沟通实际问题，那么“伪敏捷”最终将失败。