今天的主角是下面这张图，它全景式展现了敏捷开发在不同粒度上的关注点。（看不清可以看最后的Slideshare）
这张图主体上是要给敏捷在不同粒度上下一个定义，并且告诉我们它的产出是“Working software”
从最内部的环开始看，什么是持续要做的呢？测试驱动开发（TDD），编译构建，集成，代码重构，协作开发，这些事情仿佛是心跳一样，不仅不能停还要保持一定的节奏。《Continuous Integration》一文对此做了很好的注解。《Continuous Integration》源文档 <http://martinfowler.com/articles/continuousIntegration.html>
外一层要描述的就是敏捷开发每天要做的事情了：站立会议和验收测试。站立式会议在团队范围内实现信息共享，简单，直接，有效。
较之每天的行为，一个粗粒度的概念就是迭代，我个人认为这里是最能体现敏捷精神的地方。我们先看一下迭代需要做的工作：检查，回顾，制定迭代计划。检查是对已完成工作的质量保证的手段，回顾是对之前项目进行中的得失进行反思，而制定计划是在一个有更多参考参数的情况下安排下一步工作。现在敏捷社区在提倡“精益”思想，即根据历史数据动态的调整优化。敏捷开发是一套活理论，不是一堆死方法，这一点我深信不疑。
发布处于迭代外层，可以看到这阶段会制定发布计划，梳理积压未完成的事情，做出评估。
处于最外层的是策略层，这一层我们看到了目标、视角等等元素。虽然身处开发第一线的我们往往感受不到这些东西的存在，但是这些方面如果没有人考虑或者考虑错了的影响远大于一段糟糕的代码。
圆圈两侧我们可以看到敏捷开发的倡导的价值观和代表了其可量化的指标。
从传统的或者习惯的开发模型迁移到敏捷会有种种困难，需要有形式和行为上的真正变化。如果抛开这种想法呢，换一个角度呢？不搞大变革，大动作，我们能否从敏捷开发中取经来改善我们现有的情况呢？比如我们加快了构建的效率，我们坚持做代码检查和站立会议，见缝插针对糟糕的代码进行重构… …实践了这些之后或许我们还不是敏捷开发，但是我们已经拥有了“敏捷态度”。
总结
敏捷：不动摇，不懈怠，不折腾
565
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
