中小项目敏捷实践之十（关于敏捷和对敏捷的误解）

**开发方法是一个系统工程，需要所有项目活动的相互配合。**

本心得是基于近两年两个中小项目(一个2000 Manday, 一个1500 Manday)的实践总结，希望能与大家一起探讨和进步。

关于敏捷
- 敏捷是一个系统工程
- 敏捷更多的是一种态度 - Jim Highsmith
- 做实践者而不是科学家《实例化需求如何交付正确的软件》
- 敏捷是一个从实践到理论的过程
- 敏捷学习是一个从理论到实践，再从实践到理论的过程
- 略过敏捷术语，关注背后的本质
- 将敏捷实践强加到团队中是不敏捷的做法《Scrum要素》
- 大项目可以采取多层次的敏捷团队 (未实践)

关于敏捷的误解《敏捷开发知识体系》
- 只有优秀的开发团队才可以搞敏捷
- 小项目才能搞敏捷

这两个误解的原因在中小项目敏捷实践之一（关于项目所有者和责任人） http://www.iteye.com/topic/1134228中已有阐述。它是由于敏捷管理中的柔性的特点，给人以一种不可控或者混乱的感觉，正是对于这些不可控或者混乱的恐惧而形成的以上两个误解。

敏捷，最怕的就是为了敏捷而敏捷，某大咖说过，将敏捷强加于一个团队本来就不是一件敏捷的事。

如果大家有了解“敏捷”这个词的产生过程，大家就会知道，敏捷并不是什么神奇的东西，它只是对一组优秀实践的总结。所以，大家完全没有必要把“敏捷”太当回事，而是应该去深刻理解那些大咖推荐的实践。



敏捷的学习，应当是一个从实践到理论的过程。在项目实践过程中发现的某些不足，总是可以在敏捷中找到与之对应的实践活动。所以，从这个角度看，敏捷只是一个工具集，需要则用之，不用则先*收*藏着(先*收*藏也是敏感字？)。就像在生活中，我要拧开一颗螺丝，不一定要把锤子，锯子也用上。

敏捷，也是一个系统工程。只有众多的实践互相配合，才能很好的完成项目。需求变更的控制做不好，Spirit计划就会受影响。单元测试做不好，持续集成就做不好。Review做不好，质量可能就会出问题，从而导致加班。加班就会导致士气低落。士气低落，则质量更受影响。诸如此类而形成的恶性循环。

所以，敏捷不是葵花宝典，它只是一组优秀的解决问题的工具集。