链接复制成功！
转型方案实施
通过试点项目落地敏捷实践，探索出一套适合客户的敏捷运作指南，指南内容包括：需求管理、可视化管理、迭代管理、持续集成、分支管理等，并在过程中结合运作指南探索工具的使用。
试点团队的选取
ThoughtWorks咨询团队和客户一起基于以下几个原则条件选择试点团队：
- 团队主动意愿强烈
- 业务风险较低
- 产品属性比较强
- 专职的人员配备（例如：业务、需求、研发、测试等）
试点项目也将成为客户敏捷试点优选项目，建立端到端的敏捷开发和运作流程。
敏捷改进小组的建立
用敏捷的方式管理敏捷转型，改进工作本身就是一个敏捷项目，需要团队协作及适应性地去制定改进目标、计划和实施方案。
敏捷改进小组为敏捷转型项目的特性团队，包含领导层与各个角色的种子选手。建立敏捷改进工作圈迭代运作，建立敏捷转型工作坊持续总结与改进，建立敏捷改进工作墙，实时可视化敏捷转型的状态及进度。在管理敏捷转型的同时，让敏捷改进小组对敏捷转型本身有更加深入的理解。
试点项目的敏捷实践
ThoughtWorks会依据AMM敏捷成熟度评估结果，为客户试点团队定制敏捷实践的导入，敏捷实践包括但不限于：全功能团队，需求管理，迭代规范化，可视化管理，持续集成，分支管理等。
- 全功能团队
试点团队打造围绕价值的全功能团队，优化快速反馈。
全功能团队——长期、跨功能逐个完成端到端客户特性的团队。
全功能团队的特征：
- 授权：在开发工作最前线的专家们是最精通该领域的人，理当找到一种方法让专家掌控自己熟悉的工作。
- 责任：如果一个团队的成员一起对设计、开发、调试、质量保证、产品交付等全方面负责，那么大家就能找到相互提出批评意见的方法。因为团队成员对产品都负有责任。
- 归属感：在跨功能的全功能团队中，每个人逐渐开始与部分产品密切结合，而不是锁定在某一很窄的专业技能上。
- 共识：团队因为有共同的交付目标而走到一起，并且 共同承担每项特性的责任，所以一定程度的开放是必须的。很多团队 重新组织、规划远景、再分配资源、改变计划都没有遇到棘手的分歧。
- 均衡：全功能团队中的均衡指的是不同技能、不同任务、不同观点的均衡。
全功能团队的优势：
- 推动增量和迭代的思维方式
- 促进学习
- 全局优化（价值驱动）
- 计划和协调工作量降低
- 励代码整洁
- 需求管理
需求管理方法和工具：通过培训、工作坊、实例需求执行等方式，培养PO人员能力，掌握价值分析模型、用户故事地图、用户画像等方法，并进行实践操作，提升业务需求的分析和管理能力。
敏捷实践：用户故事地图
用户故事地图将用户面对一个品牌或一款产品时的关键接触点描述出来。跟随一个典型的有序“生命周期”，通常从一个典型用户行动的 “触发点”开始，从而帮助团队明确产品的需求。
用户故事地图是根据真实用户来建模的，应该基于严谨的用户研究。这项活动通常在用户画像建立及场景定义之后。
- 迭代规范化
迭代规范化：通过教练引导，优化Scrum活动，指导Scrum Master有效引导计划、回顾等活动，帮助团队进行DoD涌现等活动，尝试Scrum和看板融合，对项目进行预测和有效管理。
敏捷实践：Scrum活动规范。
团队通过实施Scrum，可以加强团队成员的协作，使得开发及交付变得有“节奏感”，提高团队的响应速度。
- 可视化管理（Kanban与Scrum融合）
通过看板可以透明团队现状，找到团队的瓶颈并进行改进。
敏捷实践：Kanban
搭建看板：
- 价值流程（任务墙的列）
- 卡片类型及颗粒度（任务墙的卡片）
- 范围（时间）
- 任务负责人
- 各阶段的准入条件
- 移动卡片
- 持续集成
敏捷实践：持续集成流水线（CI）
根据现有持续集成流水线水平，然后根据各团队产品特点给出具体的方案。业界有一些良好的工具和CI实践将作为参考。咨询师会根据方案，进一步协助搭建CI流水线，包括培训、技术答疑等方式。
敏捷实践：持续集成质量基线
- 在项目团队内部达成对软件质量标准的共识——项目软件的质量应该是什么水平
- 在项目团队内部达成对软件质量意识的共识——不允许项目软件质量低于基线
- 通过持续提高项目持续集成基线的水平，不断推动项目团队提升产出软件的质量
- 将项目的软件质量具象化为一组高度关联、可以通过CI技术手段无侵入式采集的指标
针对当前CI采集的统计指标，结合项目团队的实际情况，为每个项目团队制定特定的CI质量基线。一旦团队认可基线标准，CI流水线将只显示两种状态：红、绿，低于该基线即为红。不允许项目团队低于该基线。
敏捷实践：持续集成纪律
- 在项目团队内树立软件质量的认知意识，真正在日常的开发中内建质量
- 在项目团队内贯彻对软件质量的坚持意识，避免“破窗”的不良影响
- 保障软件产品的质量
- 分支管理
敏捷实践：分支管理
代码分支策略的目的在于解决如下问题：
- 项目团队往往使用多组并行的版本分支，分支何时才需要创建、分支的生命周期缺乏梳理和规范。
- 项目团队在使用版本分支时，未能使用正确的合并策略，导致不同的分支合并出现各种问题。
- 帮助团队尽量采用单一主干开发的方式
基本策略：
- 梳理各项目团队代码分支和合并的策略
- 梳理各项目团队对于版本管理的机制
- 与应用运维、数据中心等部门达成版本管理的策略
