敏捷改进与敏捷转型

用什么词来描述某个组织采用敏捷呢？ 敏捷采用？敏捷导入？敏捷转型？敏捷引入？敏捷改进？ 从这些词当中可以发现不同级别的组织采用敏捷是不一样的，大体可以分为项目级、部门级和公司级，不同组织级别的敏捷导入or转型or改进得到的高层支持不一样，可以采取的手段不一样。

#敏捷转型#在得到了组织管理者支持情况下，从原来的非敏捷或者无意识的敏捷转变到有意识的敏捷，可以采取包括调整改变岗位、改变考核办法在内的各种手段。 从影响的范围来分类的话，大体可以分为 项目级敏捷转型，部门级敏捷转型，公司级敏捷转型三个层次。 缺省的一般指公司级敏捷转型。

相对于敏捷转型，还存在另一种做法，可以称为“敏捷改进”。指在原有基础上，在未必获得组织最高领导赞成（比如不反对，允许先试试）的情况下，采用渐进式改进的做法，有选择的利用具体的敏捷类的实践方法。敏捷转型所需要的外在条件要高于敏捷改进，在敏捷转型条件不具备的时候，不妨先来敏捷改进。

敏捷改进以敏捷软件开发宣言和宣言背后的原则为方向，结合组织实际情况，采用渐进式步骤，针对人员、工具、过程、文化、价值观等等各方面进行改进。

agile transfomation 一般翻译为敏捷转型，敏捷改进的英文为agile improvement。两者的区别在于1，敏捷转型已经获得了高层管理者明确的支持，甚至于得到了战略决策，而敏捷改进不要求一定有高层管理者的明确支持，没有高层支持，敏捷改进照样可以搞的，虽然有些限制；2，敏捷转型的要求是在总体上符合敏捷宣言及原则，而敏捷改进就未必。不一定非要遵循所有的敏捷实践或者过程，敏捷可以是在项目现有的基础上进行改进，目标首先是持续改进，在改进过程中不断引入敏捷实践帮助团队前进。开始的时候可以只引入迭代增量开发就好。

#敏捷改进#需要考虑团队现状，看看已经使用了什么工具？使用得如何？团队成员水平如何？项目或产品进展如何？最大的痛苦在什么地方？质量问题？来不及开发新需求？加班太多？在一个判断的基础上选择合适的方法，敏捷软件开发提供了大量备选的方法。

#敏捷改进#力求从一开始选择快速见效的改进，试图快速获得好处，哪怕是小小的好处，并报告给包括领导在内的各方干系人，同样也值得持续的获得好处，并通报到各方。以实际的正面效果来让各方认可，从而获取更多的资源来开展更多的敏捷改进，放大正面效果。也许最终能够促成敏捷转型。

组织#敏捷改进#对敏捷价值观的扩展提议：组织整体协同改进并重于团队自身提高。组织一般由多个团队组成。原来的敏捷开发主要论及的是一个团队，注重团队自组织、自身提高。在实践中，团队经验的分享是非常值得的，在同一个组织里，后进团队可以参考先行团队的很多经验和教训。

对于敏捷存有疑虑的组织，可以从敏捷改进起步，通过敏捷的反馈来判断是否继续，或者停止，或者下决心来进行敏捷转型。

敏捷改进是轻量的，基于组织和团队的现状。