敏捷导入过程和感想

2019年8月19日正式加入敏捷内部教练团队，本着好记性不如烂笔头的信念、为了纪念初涉敏捷的这一天、顺便贯彻敏捷文化精神-分享，文笔很差的我操起键盘把当天A小队的敏捷导入会过程记录了下来，记下敏捷老师的一系列套路，方便本人和各路小白后面的模仿和升华。

一、准备背景：

队长意向：小队长都有意向接受敏捷转型辅导（作为首批导入敏捷的小队，尽量选择意向比较强、接受度比较高的，能更快建立标杆效应）

小队人员安排：4个行方项目经理，10个左右外包人员

需求情况：目前在建的需求是一个大需求，其他以解决生产问题或小功能需求为主，开发中的需求大概10多个，队长提出目前想优先考虑这个比较受业务关注的大需求。

二、导入会内容：

会议一开始队长提出个问题，希望我们敏捷转型能优先解决业务需求问题，业务需求文档质量差、需求繁多、需求评审不到位一直被公认为是研发质量和效率的瓶颈。项目经理每天疲于大小需求的澄清沟通工作、生产问题排查、跟进需求进度、关联系统评审、测试资源协调等日常工作。但是攘外必先安内，我们目前最重要的是先把自己工作内容理清理顺、回归项目管理初衷、提高项目质量，把我们自己从繁杂错乱的需求中解脱出来，解决我们的“忙-盲-茫”。教练提出以下敏捷导入计划：

1、看板可视化

通过知微或物理看板实现项目过程可视化，知微原理是把IT管理平台上业务提出的需求导入，在知微形成3个任务卡片：业务需求（对应平台需求）、系统任务（对应需求关联系统和测试任务）、个人任务，将导入进来的系统任务拆分（创建）为2周内能完成迭代（标准是SIT测试完成）的系统任务，团队里每个人再把创建后的系统任务拆分为1天内能完成的个人任务。

2、导入迭代

通过迭代计划会、每日站会、迭代回顾会导入迭代管理模式。每日站会落实24小时对齐机制，计划会和回顾会是两周一次，计划会团队成员一起对齐下个迭代的目标、系统任务计划、开发容量，回顾会总结前一个迭代实施的成效和改进点。

3、业务需求

需求管理是下一步目标，到目前我们已经在业务部门宣贯需控制需求颗粒度、年度或季度需求拆分为月度需求提。

三、Q&A：

1、任务卡片谁来拆？

前期建议小队长拆系统任务、包括个人任务，拆完后分派给大家认领，后期让开发人员自己拆。

2、团队里有些外包资源还在兼顾其他系统开发或测试，是否需协调全工作量投入？

建议团队里一半以上的人100%投入到敏捷转型，保证交付质量。

3、第二次拆系统任务是等第一轮迭代完成后再拆吗？

拆系统任务动作和执行动作不同步，拆的动作在前/拆完后要给对方确认是否需调整，双方沟通无误后启动迭代启动会开始执行；

4、质量手段何时导入？

敏捷的原则是交付+成长，在保证每一个任务交付质量/每一次站会和回顾会的时候，作为敏捷教练都可以观察是否存在改进点，每个改进点的提出和落地都是质量提升手段，通过这些辅导让团队和教练一起成长。

四、会后安排：

小队将厂商资源清单发给PMO，由PMO创建看板权限和整理小队看板需求；

小队长熟悉看板操作流程，提出问题；

小队长可先对看板需求进行系统任务和个人任务拆分，敏捷教练团队提供指导或培训。

五、写在2020年的回顾心得：

关于敏捷导入：整个敏捷导入全过程类似一个项目的策划，每个环节都有核心目的和计划：从前期找小队长调研访谈、筛选意向小队、到启动导入会、导入敏捷工具和活动、再到后期的跟踪辅导不断调优，A小队实际上在19年10月已可独立运行所有敏捷活动并持续至今。我作为内部教练也在A小队跟着一起成长：在思想上，从对敏捷的观望态度到逐渐接受再到完全接纳“不确定性”；行动上，作为部落的PMO已逐渐推动部落所有小队启动迭代、组织业务部门联合排期、召开部落回顾计划会，我感觉我有点布道者的味道了。

关于自身价值：敏捷导入前，部门所有人陷入“忙-盲-茫”，我作为科技部一枚QA真的感觉无从下手（因为我也自身难保）、所有人都知道有质量问题，但是完全进入不到问题中，没有工具支持量化、更没有人和时间聚焦质量问题、全员缺乏质量文化和意识，对于我来说当下推质量犹如撼动一座大山。从19年带着QA的身份加入敏捷内部教练、深入到项目组详细了解项目困难、需求实施、协助优化项目管理工具和方式、在看板工具支持下研发流程数据可量化了、QA在科技部的信任度提高了，带着敏捷教练身份的QA不仅是警察还可以是医生。