敏捷,但不简单
企业里面都在喊敏捷开发,仿佛敏捷就是一切提升效率的源泉。
但其实实施敏捷开发并不简单,甚至很多企业、很多团队都在实施一种“伪敏捷”。“伪敏捷”非但不能真正提高效率,反而让组员频繁返工,影响产品质量,从而导致产品的失败。
在实施敏捷方法中,不可避免会由一些仪式,而过度关注这些仪式反而有时会掩盖了敏捷的核心思想,就是迭代式地对反馈进行回应。我们不需要过度的计划,不需要过度的设计,也不需要过度的架构。我们已经看到了这一点,但如果我们稍不留意,就会从光谱的一边跑到相反的另一边。在这一边的做法是繁重的前期计划与设计,或者说瀑布模型或其它传统方式。而另一边的做法是完全不考虑任何东西、不进行任何设计、不进行任何头脑风暴,只是沿着车轮前进,不断踩下油门,前进、前进、前进,编码、编码、编码,测试、测试、测试……我们天真地相信这种方式最终会带来良好的结果。但其实这两种极端都不是正确的方式。
软件开发是一件艺术创作,绝不是谁都可以胜任的简单工作。在真正动手编码前,你需要做很多的思考。我们的前进方向是什么?这个模块与API看起来应该是怎样的?我们所需要处理的关注点是什么,到底是难以为它编写测试,还是说我们根本不知道要为什么编写测试?所以,当思考遇到难题,我们或许应当退一步,找一个房间,挂起一块白板,把一切设计都画在上面。但我们不是要将这些图形转变为重量级的正规UML文档,进行轻量级的架构与设计是完全有可能的,但首先你要意识到,在开始动手敲键盘之前,工作应当已经在你的头脑中进行了。
因此,就像软件工程中的所有问题一样,软件开发没有银弹。在这两个极端之间必定存在着某个适合你团队的正确答案,你必须把问题放到你所试图解决的问题上下文中以找到答案,也就是你需要多少架构实践、以及多少文档工作才能最终实现你的目标。如果你能够退一步,将敏捷当作某种保持反馈循环运作的手段,即获取反馈、对它进行回应、进行方向修正、并打造正确的产品,那么剩余的部分会自动朝着正确的方向前进。反之,如果是每日站会走走形式,或者压根不沟通实际问题,那么“伪敏捷”最终将失败。