我的敏捷观
上次说了敏捷是怎么产生的，那么到底什么才是敏捷？
一万个人心中，有一万个哈姆雷特。一万个敏捷教练口中，也有一万个敏捷的定义。有人可能会说，将软件分成若干个冲刺活动，进行迭代开发就是敏捷。也有人说，每日站会和频繁交付才是敏捷的特征。甚至有激进的专家说，没有建立完整的DevOps就不是真敏捷。那么到底什么是敏捷？
其实我们不用纠结到底怎么去定义敏捷，因为那没有意义。敏捷宣言的17位革命者，也没有对敏捷下一个具体的定义，教导人们应该怎么做，因为敏捷是一种精神，它不涉及到任何做法。如果说的直白一点，敏捷其实是一个形容词，而不是一个名词。所以，我更倾向于把它作为一种革新的方向，而不是将其作为行动的桎梏来看待。我们不能说我们采用了迭代的开发方式，我们就是敏捷的，或者采用了站会的沟通形式，我们就是敏捷的。但是如果我们以前是在最后交付才能和用户进行沟通确认，不符合期望的功能在最后才能更改，导致软件交付时常延误；而后来我们引入了迭代的做法，使得我们的功能设计在每个冲刺期结束就能得到确认，大大提高了沟通效率。我认为，这就是敏捷。因我们的做法是符合敏捷宣言精神的。
敏捷，应该是一个改进的方向，而不是任何形式上的桎梏。我们应该充分认识到，敏捷是一个形容词，而不是名词
那么，到底应该如何实行敏捷方向的改进呢？
首先，我觉得应该搞清楚，哪些是组织里很难改变的，哪些是组织里通过团队的努力可以改变的。然后我们逐步改变能变的，使其逐渐的敏捷化。
我不赞同一上来就全面的抄作业，将外边培训的东西全员照搬。因为涉及到的方面太多，而任何改革都会造成一段时间内的完全混乱。我是保守主义者，希望改革能一步一步的缓慢进行，因为敏捷的很多方面，可能很难被我们这种单位接受。比如，当下甲方要求，我们在固定的节点和里程碑必须提交过程文件进行外部评审。相当于外部节点我们无法改变，但是其实内部的开发安排，我们是不是可以考虑采用冲刺，让甲方进行阶段确认？或者使用站会和燃尽图的形式，让过程变得高效？
在做软件测试之前，我在某工程一线做软件，当时刚参加工作，对外认识的人不多，工程上的软件需求也都是总师下给我的，软件做好后会经过两次确认，一次是在内部联试时的确认，一次是在外部总体联试时的确认，两次之间总是经过很久，久到我自己都忘了一些代码到底是什么意思了。我想说的是如果能建立尽早确认的机制，加强三方的沟通，将确认“敏捷”一些，是不是当时的软件的质量会变得更好？
其次，敏捷虽然灵活，但不是胡乱做，建立固定的流程管控也是必要的。
我自己在刚参加工作的时候，也是很反感各种质量流程，当时觉得工作我自己做好就行了，能交给你符合要求的代码和其他产品就OK了，你管我怎么搞呢？后来学了MBA的工程过程管理，又自学了六西格玛管理后，逐渐也对此事多了一些肤浅的认识。
我们为什么