改变很难，但有时又不得不改变。如果作为团队自己不能改变去适应新情况，那么只有等外界改变团队。外界改变团队导致团队挣扎，坠入深渊，抱怨，甚至不复存在。表面上的改变很简单，但思想上的改变很难。钉子钉进石头里很难，把它取出来更难。钉得越深，取出来越难。越辉煌的历史有时导致越沉重的负担。
团队现状采访录：
基本情况：主要承担基于行业领域的信息化软件开发。
开发人员A：遗留项目中维护困难，一个模块散布在不同项目中代码是不同的，并且找不到源代码。
开发人员B:庞大的平台中代码只增加不重构，拷贝代码现象普遍存在，代码中许多问题追踪起来困难，整个部署文件发布后有接近1G 。
开发人员C:工期紧，经常整日加班，但做出的成果不多，心里沮丧。
测试人员：测试部署环境和现场的差异较大，部署配置项目非常繁琐。代码质量有待提高，bug率过多，基本功能未完成就提交代码测试，流程来回反复大；测试时间得不到保证，经常被压缩时间。
版本控制人员：开发提交的版本、测试提交的版本和现场发布版本存在差异，开发为了赶项目进度有时考虑到修改较小，不走流程直接修改代码也缺乏监控，最后导致发布的版本的源代码和版本库中的不同；源代码过大导致发布需要专门要一台机器部署并且一次部署需要很长时间。
市场人员: 开发不能很快的跟上市场需求，经常一个功能要很长时间才能完成，而且完成的功能跟预想的不一样，用户满意度不高；网页打开速度慢，不流畅。
这些谈话生动的再现了一个团队的情况，除去一些抱怨之言，可以从里面挖掘出一些本质可以改进的问题:
1. 生成制品缺乏版本管理，缺乏一套有效的机制来对代码进行解耦提炼的过程。
2. 缺少对开发，测试，入库，部署的一套有效管理机制来对开发过程进行管理。
基于上述问题，
1. 首先介绍一套开发管理过程的方法，来激发大家对此问题的讨论。同时了解此种方法的受益者，并逐步使其认识到此种方法能够解决其遇到的困境，并使之成为思想的积极推进者。
2. 再介绍一套开发管理过程工具，来结合实际解决其开发中实现的问题，并逐步让其享受到其带来的效益。
但在具体实施过程中，一方面，发现由于推广者对公司内部的代码架构，人员结构，业务需求不了解，所提出的概念激起了大家的兴趣,但是不能立即迅速的解决面临的已有问题而同时需要消耗大家的精力和时间；另一方面，公司人员对推广者理念只有了初步了解，并不知道如何应用到开发过程中去解决其所碰到的问题，还觉得其要学习新东西比较耗费时间。
于是管理者就给推广者一个项目去实践，但是推广者由于对环境不熟悉，以及大家对此工具认识还停留在表面，还希望用原有的思想去使用此工具，造成两难的境地。特别是广大开发人员，对于由于积累原因造成项目的痛苦以及工作的劳累，对于新方法概念益处是欢迎的，但考虑到要其接受约束，就有了抵触情绪，使之变成了鸡肋，而如方法较大受益者配置管理员势单力薄，无法形成强有力的声音。同盟者（意识到此问题并采用一些方案去解决此问题的人）中也有对此版本管理问题进行研究的，并取得了初步的成果。
应用老毛的阶级分析理论，我们要支持并培养积极推进者，和有共同目标者结成同盟，慢慢地用事实（枪杆子才能出政权理论）来说服管理者，同时要深入基层，从问题的本源解决问题，最后在管理者支持下，和同盟者来促成此方案的实施。基于形势对比，于是此方案暂时就被搁置，不过也撒下了一些种子。
既然此路不通，那么只有靠自己去深入理解现有系统，并用自己的理念去贯彻项目的执行来给管理者展示优点。因为开发管理过程的最大受益人还是管理者，其他人只是执行者兼短期内的投入者，基于个人分工导致的短视，也难以被接受。
接下来接手一个项目，并在此项目中开始施行方法。此项目是老旧的代码结构，也是用过去的方法进行管理的，那就考虑到项目进度，就先吃透此项目的架构，然后在这项目开展过程中，逐步用上开发管理过程的方法，并在这过程中逐步展示其开发效率的优越性，比如代码由于依赖统一管理后的迅速缩小，发布的便捷性，灵活接受需求变更的能力。
最后借此项目的成功来推广此概念，并团结原有的同盟者中，让其慢慢理解和接受此理念,并用事实加以阐述，这就是星星之火的第一阶段。
在推广的第二阶段，我们的主要目标是进行试点探索，就是扩大根据点，在根据地中，我们要对公司现有的问题作个性化的支持，并解答开发者的问题，帮助开发者逐步意识到此方案的优点，并让其放下抵触情绪，培养出一批能够对推进此方案的积极拥护者，甚至是此理念的布道师。这样才能将星星之火，蔓延到整个团队。
在最后的阶段，就是培养一个开发过程管理的实施、监控和优化团队，就是让现有的角色融合进入开发管理，贯彻开发过程管理的实施。同时解决开发过程管理应用的具体问题，持续的改进优化开发过程管理的实施，以是否有利于提高开发效率来对其作具体的提高。
参考文章：