最近，有个很好的朋友在路上和我聊天，说我看你们老说敏捷，你能给我说说什么是敏捷吗？
我说：敏捷是一种价值观。
友问：哦，是什么价值观？
我说：遵守敏捷宣言的价值观？你知道敏捷宣言吗？
友说：不知道。
我说：敏捷价值观是，个体和交互胜过过程和文档。。。
友问：为什么个体和交互胜过过程和文档，为什么。。。
我说： 因为如是这般。。。
还没说完，就到站了，朋友要走了，回来我就开始思考如何让人对敏捷有个快速的了解，也就是短时间内了解敏捷的一些精髓。这个我们向客户推敏捷的时候其实也经常碰到上面的场景，客户也同样没有时间而且不可能有很多时间听我们讲敏捷。
随后，我回来仔细想了想，我们如何让别人很容易理解并接收敏捷呢？
1. 我们必须让他用自己的语言和经历可以轻松的理解。
2. 必须找出敏捷的最重要和最显著的特点。
3. 必须让他们明白敏捷带来的好处，而不只是工作流程的改变。
这两年我也一直学习和实践敏捷，正确使用敏捷确确实实可以解决很多问题，注意，我这里说的是很多，并没有说所有。同时，可以大大增加项目的成功率。
这里不说SCRUM, 不说XP, 下面是我给敏捷的一个很山寨的定义：
敏捷就是以客户商业价值驱动的增量的提交，每个迭代一般持续2到4周，每个迭代结束向客户提供迭代初承诺的高质量的可以工作的软件，整个团队持续改进同等时间的工作效率和工作质量。敏捷可以提高团队的战斗力，个人能力随着团队能力的提高同步提高，敏捷可以极大提高解决新问题或未知领域的能力。敏捷在提高工作效率和工作质量的同时可以提高个人的成就感和生活质量。敏捷最大的挑战就是找到敏捷的人（爱学习和上进的人）和一个好的敏捷教练来正确推行敏捷。敏捷是一种思想和价值观，不只是使用在软件领域。
之前，看了一篇文章，很多人错误的使用了敏捷，然后就很不愿意接受敏捷，这是不对的，我认为这并不是敏捷本身的错，而是少了一个好的敏捷教练。我见的大部分使用敏捷的失败的原因都是拿着瀑布的方式，或者命令和控制的管理方式来使用敏捷。我就发现很多人用WinForm的思想使用WPF,后者使用WebForm的方式来使用MVC. 然后说WPF太麻烦，说MVC不好，这并不是WPF和MVC的问题，我们应该使用一个东西的优点。
本篇文章，你只需看黑色字体就可以了，因为我的目的就是快速让一个人知道敏捷是什么东西，我觉得一个敏捷的人，如果他现在使用别的过程遇到问题的话，他自己会有更多的理解或者回去查资料去了解。
祝大家晚安，工作生活愉快
