背景介绍
○IT通信产品部门, 50% +全球市场份额, 年收入 = 20亿美金
○市场竞争激烈
○近5年的敏捷转型期
○人员
●在中国，大约170研发和产品管理人员待转型（最终转型为14 scrum团队）
●传统职能部门的组织形式（架构/开发/系统测试/Alpha/Beta/硬件/维护性开发组等）
●跨洋的异地PDCA
○交付时的版本质量被视为最高优先级
○传统瀑布式项目评审流程（Q-Gate）
敏捷转型在管理实践方面的小结
○从团队级到跨团队（发布），再到跨发布级的规模化敏捷
●固定的发布节奏（～3个月），有相应的跨发布级，发布级和团队级的流程作保证。
●几乎所有的软件相关人员都分散到了固定的敏捷特性团队之中。明确的职业发展路径。自组织团队起码能管理团队自身的进度和流程。
●工具方面，Rally和其它项目管理工具被逐步的适配和定制化。
○敏捷需求 - 用户故事的管理
●用户故事计划图（US mapping）在跨多团队的发布中被频繁使用。具体使用时，有多个发布级别的计划，也有发布内多Sprint级别的计划。
●用户故事的文字表达在逐步改进后，有了这样的基本结构：3W -Who/What/Why；ADS - Assumption/Dependencies/ScopeNotIn；AC - Given/When/Then。用户故事的拆分按AC来进行。
●缺陷和测试用例和用户故事相挂钩，由定制化的工具来实现。
○CoP按角色和技术类别来展开，能够让敏捷积极分子多一个分享传播经验的渠道。同时，也能让其他人员收益。
○敏捷项目治理和团队成熟度
●经理们既负责移除转型中的障碍，也负责驱动敏捷项目的评审。评审一般是看趋势，指标或对象，有：跨团队的障碍内容和趋势、风险、自动化覆盖率、DoR、团队交付速率、内部质量和外部质量趋势，等。
●成熟度评估。
敏捷转型在工程实践方面的小结
○ATDD对实例化需求，测试覆盖度，快速简单交付有益处。但在执行过程中，大家并没有一直做到验收测试用例先行。
○主干开发的代码配置用了Git。主干上的持续集成做到了每天4次自动构建和快速版本测试，每日和每周的自动化回归测试。如下图。
○本地CI的管道为团队代码质量作保障。主要是校验新特性代码和小范围的回归测试。
○由Gerrit +1/+2强制大家先本地校验，再进行专家级评审。通过后代码才会被正式签入。
○结对编程对质量和产能的提高有好处。如：在开发和测试之间，资深开发和一般开发之间，Scrum Master和测试之间。
○自动版本部署使用了基于Tcl的一个内部框架。而自动化框架使用了更加灵活的TNGpi
○自动化测试用例的覆盖率：总的回归测试达到了60%，新特性超过90%
转型有待继续改进之处
○敏捷转型本身可以采用小批量的迭代和增量式的方式。如：用户故事DoR的演进步骤小批量。团队级和跨团队级的流程演进也是如此。
○战略层和实施层的人员之间可以增强协作，使得转型更加反馈驱动式。也就是以观察或实验为依据的流程方法（Empirical）中的透明化，检视，调整为基本手段来实施转型的诸项实践。
○如果能让更多的敏捷积极分子参与建议和实施，转型的效果会更好。（自下向上的参与）。
○如果能为全员营造适当的紧迫感，配备更好的教练计划的话，大家的认知和情绪上的学习曲线能更为改善。
○更系统化地对落地的敏捷实践进行固化和推广，对表现杰出的敏捷积极分子予以适当的奖励，能让敏捷扎根。
○经理们的教练技能可以用更结构化的方式来提高。如采用ACI, CEC等方面的实践和技术。
○简而言之，敏捷转型的本身可以变得更敏捷和精益。有很多的良好社区实践可供选择。
作者：沈灏（Steve）13+年的IT项目管理经验，19+年的IT从业经验。担任过资深开发工程师，项目经理，测试团队经理，项目群经理，产品经理，项目群经理负责人，Scrum Master，敏捷Coach等职位。负责过Waterfall，迭代增量式-小瀑布，以及Agile项目/项目群。特别在项目群管理，敏捷项目和敏捷团队的服务和引导有丰富的经验。服务过的项目遍布多个公司，包括：思科，米么金服，微软，诺基亚，阿尔卡特上海贝尔等公司。
