前言
在前面项目结项时，团队进行项目反思会，大家提了很多有关质量方面的担忧。担忧是两个方面的：一个方面前期项目技术穿刺的特点，以进度优先，质量方面还有不足；另外团队未来开发测试比例调整到4：1以后，如果用单元测试来保障功能，是否可行。最近两个迭代也尝试推进需求实例化有一些进步，也暴露出一些问题。可能需要一些更系统的思路来使得敏捷继续前行。
和产品经理宇总讨论后，结合Thoughtwork方教练的诊断，确定未来3-6个月的敏捷实践落地计划。主要有个以下几个方面：
1、敏捷过程重构
当前的敏捷运行模式以实用为主导，结合前期项目特点，以技术预研和快速实现为准。在技术验证，代码质量改进（修改告警和圈复杂度），架构提示以及TDD试行方面，进步很大。在和产品经理确认以后，和方教练请教以后，确认一下提升点：
1）故事地图梳理
现状：Backlog以Excel保存，每次PO根据项目阶段提供一个故事范围，拆分成故事以后，在需求会议进行评审讨论。后续依次进行迭代计划安排。
改进思路：
用户故事地图已经成为敏捷需求规划中的一个流行方法。用户故事地图可以将你的backlog变成一张二维地图。 主要用于解决敏捷需求分析过程中的问题：
– 只见树木不见林，重要的待办项容易淹没在各种细节中看不到全貌，因而难以排列优先级
– 不能明显地聚焦于用户需求– 很难了解不同粒度故事(史诗故事、主题故事以及故事)之间的关系
– 不能方便地了解系统提供的功能的完整性
– 不能方便地了解系统提供的工作流以及价值流
– 不能方便地利用递增和迭代的方式去确定发布计划以及发布目标
– 每个用户故事地图代表一个完整的用户故事
– 地图的核心是一条从左到右的时间线
– 时间线的上部放置最大粒度的内容（可以理解为Epic）
– 时间线的下部的第一行放置二级粒度内容（可以理解为backlog item），并在每个一级粒度下按照从左到右的优先级进行放置
– 每个二级粒度内容的下面，自上而下放置三级粒度内容（可以理解为task）
最终我们绘制出来一个完整的端到端的用户故事。
实践计划: leangoo上有用户故事地图的模板（可以参考下图模板），后续用户故事地图在此维护。12月份开始试点，后续逐步统一在此维护。责任人：PO，SM
2）N-1迭代第二周中期进行N迭代故事评估
现状：一般迭代开始前进行故事澄清。内容较多时，单独成会。焦点集中在需求本身。
改进：
时间提前-单独成会，在前一个迭代的第二周的中期。
故事澄清-由PO进行故事说明，并排列优先级。
故事估算-对于下个迭代的故事进行评估，给出团队整体工作量（可以是人天也可以是故事点）
基于承诺”Commitment”：Product Owner从Product Backlog中取下一个用户故事（按照优先级），对这个用户故事进行解释，团队对用户故事进行讨论，明确需要解决的问题，整个团队确定是否能够在下一个迭代周期中完成这个故事，如果团队没有信心完成该故事，计划会议结束，或者把这个用户故事进一步划分成更小的用户故事重复第一步。如果团队有信心完成该任务，重复第一步。
基于速率”Velocity”：确定Product Backlog中用户故事的规模（用“故事点”）确定团队迭代的开发速度（“昨天的天气”）从Product Backlog中取出相应量的用户故事。
3）提前1个迭代故事测试用例分析及评审
现状：当前基于事后分析。
改进：结合故事评估的改进，将测试用例分析和评审前移至前一个迭代。采用故事（特性/需求）->用例（场景）两级模式，采用GitLab+MarkDown的方式来管理。
4）4+1会议不超过1个小时
提倡流畅高效运作，需要提前准备内容，缩短会议时间，有更多时间聚焦研发本身。
2. TDD持续推进
TDD进展很快，也存在一些问题，具体参见《TDD落地时间总结和展望》 。
3. 架构诊断及持续改进
在11月份和C++敏捷教练进行沟通兄弟版本的诊断问题时，他提到了架构问题。理想国是DDD来整体重构，对我们来说，不现实。我们的版本相对于兄弟团队框架有了很大提多，因为视野技能原因，应该还有不足。只有不断改进，才可能保证良好架构，保证未来响应需求时，容易实现而不是频繁做大的架构调整。
4. 高效代码走查
代码走查一直都是有的。如何高效的定时3点半走查，对我们来说是一个难题。后续结合兄弟团队的一些良好做法，形成一个高效的3点半代码走查。是未来改进的一个目标。
小结
敏捷过程持续改进、TDD持续推进、高效代码走查和架构持续改进，是未来三个月敏捷实践推进的重点。敏捷过程持续改进和TDD持续推进已经有了具体思路。高效代码走查和架构持续改进未来在继续细化方案。
参考：https://www.leangoo.com/9944.html
http://www.woshipm.com/pd/270289.html
