美文网首页敏捷转型敏捷之旅@产品
未来三个月团队敏捷实践推进落地计划

未来三个月团队敏捷实践推进落地计划

作者: 而立不惑之年 | 来源:发表于2017-11-24 12:50 被阅读45次

    前言

    在前面项目结项时,团队进行项目反思会,大家提了很多有关质量方面的担忧。担忧是两个方面的:一个方面前期项目技术穿刺的特点,以进度优先,质量方面还有不足;另外团队未来开发测试比例调整到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

    相关文章

      网友评论

      本文标题:未来三个月团队敏捷实践推进落地计划

      本文链接:https://www.haomeiwen.com/subject/bokgvxtx.html