背景

本打算分多个小主题阐述敏捷思考，但苦于不是多版本紧急上线或出差或在抱娃喂奶（例如现在），估计要迭代产出了，且还有多本业界经典等待学习，书读百遍其义自见，读万卷书行万里路终有异解。曾做过一天IM系统重构，实践了XP极限编程，通过结编程将复杂的IM信令处理重构为异步状态机。而本次产品新需求，合肥武汉两地异地开发，加上新产品新任务新成员新技术架构调整，加上繁琐到说都难以说清楚的原研发上线流程，既然都是风险，这么有挑战探索性质的事情，不如更猛烈一些吧，也就豁出去了坚定跑敏捷，打造团队探索新产品驱动流程精简优化。（本文将切实落实面向持续交付价值理念，充分利用碎片化时间以段落交付，交付段落一）

原流程

原流程其中一种解释：研发dev构建自测->研发提测邮件，合并至test->测试构建部署测试->测试完成，发布测试报告，明确版本质量->产品确认是否上线->研发合并至matser->测试master构建提交产物->运维部署上线->测试验证。请问该流程有问题吗？请仔细思考，是不是都很熟悉？

由于团队快速扩张，出现了一图多解，因为这个流程以及和流程配套的没有规划的环境、还有留在心中的设计、每个过程大量相关人参与、并发开发、测试排队等等，交接团队士气达到了冰点（还有小伙伴因为混乱看不到希望萌生去意）。做开发的都懂，大部分情况下宁愿自己做一套都不愿意维护别人的，虽然很不符合敏捷开发理念，换个团队开发维护异常艰难。请注意，这就是敏捷闪亮登场的时候，有问题不可怕，最可怕的是没有敏捷心态！

正题

原始需求story：为了满足客户需求和业务发展需要，我们希望在一个月内研发并上线一套AI医疗新产品，以完善AI医疗某业务方向。（敏捷story推荐写法，交付段落二）

初始需求解释：这个需求很简单，按照原来那套系统改一改差不多就可以上线，应该问题不大。

是不是又很熟悉，不过我们要以敏捷心态看淡这个需求，冲动的去打人就不对了，不符合价值观。先不纠结需求本身，先统一观点，把当前系统研发的问题一板一眼的列出来，说服大家坚定走敏捷，尽管很清楚大部分人对敏捷的理解仅仅到了迭代，这样也没关系，至少明确了目标和要求。第一个迭代要求产品经理将思维导图需求转成更明确的Product Backlog，细节补充交互和UI，然后按照我细化的敏捷步骤走，先上套路后续再迭代优化。研发人员比较简单，跟着走就可以。（做动态颜色手机壳的产品经理该不该打？交付段落三）

敏捷实操手册

在团队同意敏捷方法论之后，立即着手完善了敏捷实操手册，但是多年经验表明，大部分研发是不看手册的，手册是给我或者你们看的，当然最终还是给你们看的。在Sprint1迭代开始之前，我需要提前将实操手册落地拆分为实物，让懂不懂敏捷的人都知道傻傻的跟节奏，那么我用了1周做了个sprint0，主要是我在不断输出，不断拉团队开会宣贯，给团队预热，当然重点需要关注PO和后续培养的SM，Sprint0后续再详细分解。（为什么会有Sprint0？交付段落4）

Sprint0交付物概览

Day1-2：产品产出PB、需求任务会、物理看板、JIRA、wiki、SVN准备；注意点：故事点比较难评估，可以先从任务工时评估，看板要有仪式感，这是团队氛围很重要的一步；

Day3-5：测试计划和方案评审、架构设计方案及评审、拉基线；注意点：测试架构评审整个团队需要全程参与，该有的重要产出物一定要有，不能盲目追求敏捷去省略重要产出物；

Day4-13：前端任务、后端任务、测试任务，按照story完成即交付；注意点：每天晨会每人三句话，昨天完成了什么、今天准备做什么、有什么风险，SM负责记录风险；同时将初始的串行流程改为了按照功能持续交付，所有人的工作都开始串行，这样才有了更高的完成率；

Day14：上线；注意点：完善部署方案，提前预案，因为是线上系统，和用户相关的一定是最重要的；

Day15：产品发布会；总结复盘；改进计划；注意点：第一个环节，产品经理要有和团队一起开产品发布会的仪式感，让大家看到努力获得的成就感；复盘每个人轮流自由发言，不要随意点评；改进计划明确改进时间，到时间去复盘是否真改了；

敏捷总结

本次迭代持续三周，14个工作日，最终实现了AI医疗产品的从零到上线，作为敏捷教练，从一开始是怀疑整个事情的，但是我没有直接否定整个计划，因为既然带敏捷，希望是建设好个人能力团队能力都很强的敏捷团队，带团队的最好方法是和团队一起冲锋打仗，如果给团队无法完成的任务但最终完成了，更会让每一个参与者都会有很强的成就感。养兵千日用兵一时，该冲锋就该有血性，当然持续加班也一定不是最好的状态。大家很辛苦连续加班完成了任务，为了感谢大家和自己的努力，所以最终忽悠产品请吃了一顿火锅，团建要及时。

本次迭代的结果很顺利，但是过程一直一波三折，因为涉及到第三方团队的服务调研，大量时间在协调沟通，为了快速解决问题，针对关键问题制定了架构师作为核心接口人，敏捷架构师一定是下层到团队，用经验和视野去提前消除系统级风险，只写方案的一定不是敏捷架构师。同时因为拿了PMP和正在拿敏捷ACP的证书，以前一直对PMP项目管理和敏捷项目管理理念的冲突没想清楚，这次在实践中证明两者并不冲突，也能找到很好的平衡点。

最后来看下结果展示，5个开发2个测试一个PO，当然拆任务的时候团队经验不足，不少故事拆的任务过大了，导致任务时间评估过于乐观，团队赶任务过程中拼命加班（作为项目经理这才感到踏实）。自己挖的坑含着泪也要填完，经历艰难才有更有恒心学习改进并完善。