• 敏捷转型历程


    我: Tech Leader

    团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员。另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面.

    迭代: 双周

    主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.

    现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3开始,外部教练基本上没有看我们的状况,由我指导着团队和远程的SM进行敏捷活动。

    -------------------------以上是基本背景----------------------------------------------------

    名称:演示会

    参加人员:Scrum Team, PO, SM

    主持:Scrum Master

    时长:1 小时

    昨天星期五,昨天早上,我们按计划开了演示会,演示会一上来QA就直接说按照上次回顾会的DoD,本次Sprint所有的story都没有达标,我是扮演PO的角色,一直在观察状况,我也注意到他们在演示会了前两天,也没有将代码部署到SIT环境中,所以我也没有看效果,昨天早上也是我第一次看效果,为了让演示会进行下去,好让团队看到反馈,我还是告诉他们继续演示会。

    我让SM一条一条过story, SM先念story,QA和开发人员边解释完成的东西,我做为PO边提意见,但是今天的演示会真的是非常糟糕,首先,所有的story,没有一个是达到上次回顾会达成一致的DoD;其次,团队对演示会准备不足,导致有些功能演示不了;部分story工作还没开始;部分story开发功能没完成;团队的承诺无效。

    做为PO,没有看到一个story是完整过关的,完全是不可接受的事实摆在面前,我愤怒了;做为开发人员,为了准备演示会,加了一个晚上的班(演示会前一天,团队在加班准备并集成),得到的是不认可的事实,开发人员也找借口抵赖了;需求没有被传递;需求不清晰;开发人员不主动;工作太赶;质量太差;缺乏设计,等等这样的问题在演示中爆发了出来。最后,SM提醒这是演示会,问题留到第二天的回顾会再提出来并讨论, 团队所有的成员都带着一脸的不开心结束了会议。

    我来总结一下演示会的问题。

    1. 演示会前,没有准备好环境演示,导致浪费时间需要重新布置环境去演示某些功能。

    2. 集成太晚,导致准备仓促。

    3. 开发人员不主动,导致沟通不顺畅。

    4. SM兼顾其它工作,导致难分身,与PO也缺少沟通。

    5. 上一个Sprint的工作积压,导致团队赶工,质量赶不上,导致达不到DoD的要求。

    6. PO对story缺乏更加详细的描述,而且缺少AC,导致开发人员理解不清晰。

    让我们来看一看下一篇的回顾会吧。

  • 相关阅读:
    最小生成树(二)Prim算法
    红黑树
    最短路径:Dijstra(迪杰斯特拉)算法
    30岁的程序员,未来之路-写于疫情笼罩下的北京-中国-地球
    Spring Cloud 系列之Hystrix、Ribbon、Feign 源码剖析(一)引子
    A left join B B表有多条记录,max(create_time)取最新一条
    最新idea破解码,亲测可用
    Spring Cloud Gateway简单使用
    开源的C#实现WebSocket协议客户端和服务器websocket-sharp组件解析
    简单易用的.NET免费开源RabbitMQ操作组件EasyNetQ解析
  • 原文地址:https://www.cnblogs.com/even-ctit/p/5789533.html
Copyright © 2020-2023  润新知