启程前的路途
10年毕业，进公司，进入项目告警团队。那时候恰逢项目大规模商用。刚进公司不到一个月的我，一周能改100多个故障，当然有许许多多的国际化或空指针等低级的故障，由科长分配这周大家要完成的需求到每一个人头上。但需求大部分没有经过太仔细的分析，刚踏入工作岗位的我们也是云里雾里，完全按照我们的主观的理解去做。还记得那年，科室里资深的同事全部被出差到上海是封闭开发，剩下几个小喽啰的我们，就更加迷茫了。很多需求做了半年以后，当客户拿到需求时，发现这完全不是他们想要的。然后又开始改故障出补丁。
项目上出版本很困难:整个项目有七八个科室，每次要出版本的时候，需要把大家的代码集成出来。那时候出一个版本基本上要一周左右的时间。每次版本经理去集成版本的时候，总是少不了先从一堆编译不过，再从一堆冒烟测试不过。过五关斩六将，才能把版本集成出来。然后再进入漫长的集成测试，系统测试阶段。
版本周期很长，版本质量不好，需求返工率高。
启程:团队级小规模，初尝试
当我们意识到，团队故障太多，需求返工很多，团队成员压力不均衡时，我们开始了新的尝试。当开始这些尝试时，我其实并不知道他们跟敏捷有什么关系。但，这些事情，我们就这样慢慢做起来了:
- 持续集成，让我们每次都很自豪。当项目出版本的时候，我们基本上不会有代码编译不过的问题。
- 从传纸条开始的SCRUM和看板的尝试。这个阶段我们团队持续了两年左右的时间。从SCRUM到看板，最后又回到SCRUM，我们总是在不停地尝试，不断的适应外部的变化。也是这样的尝试，让我们逐步开始习惯去理解持续改进这件事情，理解到节奏感，MVP和快速反馈。
- 从分担压力开始的人员职责共享。这件事情我们花了两年左右的时间去完全实现告警领域的职责共享。从一开始告警团队两个UST各自内部的模块拉通和指责共享。到后来人员抽调和合并后，整个领域的职责共享和拉通。
关于职责共享这件事，这几年慢慢的每个阶段都有完全不同的理解。一开始，以为他能帮助我们实现人员的备份和复用，实现压力的共担。到后来才发现他是我们团队建设的一个基础，是我们搭建一个人员培养平台的基础，更是我们各项技术实践的基础。更重要的是，这件事情，把我们团队的所有人都粘到一起，每天都有共同的目标。这样的团队，才有自组织团队的可能性。 - 一些技术实践:单元测试，clean code，重构，结对编程等。一直到现在，这些技术实践都是我们的基石。他是我们团队质量保证、人力技能提升的目标和关键手段，也是培养每一位小伙伴的质量意识很重要的手段。
- 最重要的基础，其实有三个:
- 团队知识库建设:这是我们一直引以为傲的东西。从10年以前到现在的的团队的业务演变都可以做到准确的信息完整可追溯，到今天我们做特性树建设，需求体系化。现在看来，那么早以前我们的知识库建设其实就是需求体系化的雏形。
- 用最好的工具提升我们的效率:
团队一直非常关注好的工具的引入，共享，打造了一个工具共享平台。让每一位加入团队的小伙伴都能快速搭建起来日常所需的工具环境。一些小小的工具，却有大大的运用。个体和交付重于流程和工具。但好的工具的引入却能大大提升我们的效率。 - 关注团队学习，关注人员培养:我们从来不担心会有小伙伴离开。在合适的时机，有更好的平台，离开也是一件特别好的事情。团队的学习和人员培养机制，让我们可以快速让新人成长起来，承担起重任。关于这一点，当然和前面的所有改变和尝试都是分不开的。关于这一点，项目这几年，慢慢的有老员工被抽走去做新的项目以后，或是有骨干员工离开后，对原有业务团队的交付能力的影响，实在有太深刻的体会。
走得更远，项目级铺开
12-13年左右，我们的团队级敏捷有了基础，恰逢公司也开始关注敏捷转型，可以申请到一些外部资源。当有第三方外部资源进驻时，总有一些新的契机。当时TW的一个技术教练和一个管理教练进来，管理实践从三个试点团队开始，给更多的团队引入了“看板”，引入了SCRUM。技术实践，引入了“clean code”“单元测试”“TDD”和“重构”。现在回想起来，在项目级去铺开来做的时候，管理实践从可视化的流程改进开始，当信息可视化出来，基本SCRUM流程运转起来后，才有可能会帮助团队去意识到一些问题。而本身SCRUM的PDCA的思想就提供了很好的机会让团队一起去不断反思和持续改进。而技术实践，从一线员工最关注的代码质量相关的实践开始，还关注到大家的编码习惯和人员技能培养。当引入一个新玩意儿的时候，首先让大家尝到甜头，才有可能会有继续下去的意愿。
在这个过程中，我们又逐步引入了项目级CI，逐步去解决版本集成的问题，越来越多的自动化手段，去缩短反馈周期。让项目出版本更容易。节约测试人员搭建环节和测试的时间。能更快的帮助开发团队提前发现他们的代码中的问题。同时，外部的咨询师的引入，和项目几个试点团队一起，把代码走查做起来。
回过头来看，即使现在组织里依然有一些小伙伴会对“敏捷转型”这件事情，有一些悲观的想法。可如果让我们把现在这些实践，这些CI的工具链都去掉，再回到几年以前，大家一定会觉得难以忍受。因为，这些改变不是一蹴而就，经历了很长的时间。但再往前几年对比看看的时候，我们不得不承认，敏捷转型这件事情，给我们带来的好处和进步是很大的。
从项目级到部门级，更系统化的敏捷转型
14年左右，公司越来越关注“敏捷转型”，基本上部门所有的项目都要去做这件事情。而当有了一些最佳实践和先行者出来以后，这件事情，在部门的铺开就变得容易了许多。这个时候，我们的idea talk平台就自然而然的应运而生，有了教头作为部门敏捷转型的牵头人。就把几个项目的先锋队连接在一起。那时候，我们出现了各种COP，这些COP让我们能很快速的进行知识和技能的传递。帮助每一个项目把第一批人员培养起来。当然，这件事情对于我们已有的教练也是非常好的技能提升的机会。一方去帮助其他项目做一些辅导，另一方面走出自己项目，能看到更多的项目的复杂性，在辅助不同项目做敏捷转型的过程，也是自身的技能不断提升的过程。
当然，变革本身是比较痛苦的。尤其是当各个项目本身业务压力很大的情况下，想要去推进这件事情很难。这个时候，借助外力就显得特别的重要。也是在这个关键的时候，一方面技术部开始做教练认证，吸引到更多愿意尝试新新东西的小伙伴，加入到这个排头兵和赋能者的行列，培养他们成为各个项目敏捷转型的重要基石。另一方面，分中心给各个项目下达了项目AMM过级的要求。这个举动，在我们公司这样金字塔形式的橙色组织里会比较有效。因为有外力的驱动，也有了内部的一批先行者的带动我们的部门转型就这样一步步开展起来。
现在，再回过头看看我们的，AMM一级和二级的过级评估。之所以，很多时候还是关注到条目本身。是因为，当很多项目还不知道怎么去做的时候，给出一些最佳实践，在项目中先去尝试，去做起来，做的过程中，结合项目实际情况去评估不同实践对于项目的价值和有效性。因此，1和2是基石，是我们从无到有的一个过程。
短短两年左右的时间，基本上部门的的所有项目都有了很好的基础。
继续走，前方会有更多惊喜
1和2级，我们对敏捷，对模型的认识和理解不够深入。基本处于被动接受的阶段。而到了3级，在关注价值交付的目标导向之下。各个项目结合各自的特点，有了很多的可能性。
比如，某些面向外部客户的产品，可以在需求定义，需求挖掘，需求实体化等方面有更多的创新型尝试。关注于质量的项目，可以在需求体系化建设、需求实例化和MFQ上有更多的实践。
总体上来说，各个项目围绕价值和交付，基于度量和工具链，都可以把项目的改进有机的整合成一个鲜活的生命体。
下一步？我们将去往何方？
在各个项目的生命体里，就可以去观察项目的成长和进化。但这个生命系统中，最核心的还是“每一个人”，每一个人的成长和进化。
这又让我想起“U型变革”里的四个阶段:
- 对立和对抗
- 对话
- 利益相关者可协商
- 生态和共建
在我们的金字塔式的组织架构中，上下级的关系基本处于1或2阶段。如果在组织进化中，能充分的看见和尊重每一个人，我们能构建一个3甚至4阶段的组织文化。
让组织里的每一个人，都是很鲜活的，灵动的，充满创造力的去投入到我们每一天的工作中。
每一个人都像一个被激活的生命，在我们的生态系统中去扮演不同的角色。他们可以有更多的机会去尝试自己想要做的事情，可以把个人的使命和愿景与组织的进化和发展有一个很好结合，那我们的组织一定会有无限的能量去创造出无限的可能性。
经过这次评估的交流，越来越多的项目关注到“自组织”，关注到“人员激活”，而事实上，我们的组织转型也到了这样一个阶段。恰逢外部大环境，不管是国内，还是国外，“青色组织”、“合弄制”、“自由组织”，越来越多的实践和案例出来了。期待着，在这样一个美好的时代，我们的组织进化能够朝着这个方向走得越来越远，越来越好。
期待着有一天，我们每一个小伙伴，都可以以“完整的人”的状态去投入到工作中，开开心心过好每一个当下。
