Scrum中的技术实践(1): 拥抱变化和短期迭代

就我个人理解，敏捷开发大多强调拥抱变化和短期迭代。

拥抱变化是敏捷开发的精神内涵之一。传统瀑布模型一个很大的缺点就在于无法应对变化，瀑布模型把软件的功能在需求分析阶段就固化了下来，而需求分析本身就是（大多情况下）无法做形式化精确定义的，这样的开发过程理论上也就无法交付一个完全满足客户需要的软件。如果再考虑到客户需求本身就在动态变化（比如客户企业的组织结构调整了，业务流程调整了），那么软件的不可控因素又更多了。敏捷开发正是从这一点上向瀑布模型猛烈开火，所以在敏捷开发的基本假设和哲学里，软件需求就是不断变化的，软件开发过程要做的是迎合这一点，而不是回避。

短期迭代则是拥抱变化在软件开发过程上的自然外延。为什么短期迭代能够解决不精确需求的问题呢？从控制论的角度来看，短期迭代把软件开发过程变成了一种负反馈的过程。举个控制论里会谈到的例子，鹰为什么能捕捉住身手敏捷的兔子，只是因为飞行速度快？事实上鹰把整个捕捉的过程变成了一个负反馈的过程，它在远处看到的兔子的时候就快速地飞过去，而飞行的过程中兔子已经撒腿跑了，鹰再动态继续调整飞行方向，就这样不断的靠近兔子直至捉到它。短期迭代也类似，把一个项目周期分成了多个小的周期，然后在小周期的间隙处调整项目需求、目标。这种小周期在Scrum中就是Sprint。

虽然Scrum理论上解决了需求变化的问题，但仍然不是歌舞升平的时候。这里是一个常见的Scrum过程图，在这里面你会发现传统开发过程中的需求分析、软件架构、概要设计等等不见了，那么是不是Scrum摈弃了这些旧世界的东西呢？一般Scrum相关的资料里并不说要或者不要这些东西，在这方面Scrum远没有XP那么旗帜鲜明。

看来Scrum似乎只是作为一种项目管理、开发流程方法论而存在，而把技术实践留给了使用者。这也是Scrum被一些其他敏捷社区诟病的地方，我个人也认为这给Scrum的使用带来了很多隐患。