敏捷和反馈

继续搬自己的blog.

最近在开始使用敏捷，我也参与其中。

其实我在A公司的流程就已经算是很敏捷，只是我们没有这么叫。我们有每日构建, 持续集成等等一些实践，我们是一个小团队，我们承受不了任何浪费，所以我们会尽量的自动化，我们有很大的自主权，我们可以选择做些什么，不作些什么。

而我现在的团队，有上百人，以前是传统的瀑布模型，现在想转向敏捷，使用Scrum框架来做开发。而且是从上到下来推行的，大家的热情很高，也没有太多的对培训，大家就开始了，首先实行的有daily standup meeting, 计划游戏. 我很高兴能参加这么一个转变的过程，其间必然能体会到一些新的东西。

这些是我所体会到的：

1. 组织结构很重要。功能团队（feature crew)能更好的使用敏捷，这种团队包括：PM, 开发和测试人员，这些人员都是全职在这个项目上，都是为完成一个项目/功能服务的。如果一个人同时忙多个项目，有切换成本，会降低效率；另外，你很难精确的知道这个人明天要做什么，不利于项目控制。但是组织结构是一时半会很难改的，要知道这个问题，但是不要过于纠结。

2. 敏捷，其实就是提高反馈的速度，加快正反馈，消除负反馈。瀑布式开发，到了最后才整合，才能测试，这时候得到反馈，已经晚了。而在敏捷开发里面：daily standup meeting, TDD, daily build, continous integration，code review, iteration 等等其实都是在提高反馈的速度，让你即时的发现错误和做的好的地方，改掉错了，加强好的。

3. 敏捷不是没有计划。计划的好处在于：你可以先在脑子里面构思和验证你所要做的东西，如果这时候发现问题，改掉问题的成本是最小的，不管你是使用敏捷还是传统开发，这一点是不会改变的。

4。领导们更喜欢Scrum,而不是XP. Scrum侧重于项目管理，这个佷容易引起管理层的共鸣，而XP侧重于软件工程实践，工程师可能更喜欢。没有XP的实践，敏捷是不可能成功的。所以要在公司推敏捷，两个一定要结合起来。