[个人心得][案例]敏捷中还需不需要进行需求审批及变更管理

1. 背景

1.1 个人背景

笔者没系统学习过敏捷管理,之前只是在所处团队中跟随使用,因此并没有思考过各个行为背后的原因。为什么现在要做敏捷管理的心得记录,是因为新被指派到管理一个敏捷项目的团队,成熟度几乎为0,百废待兴。看到各种问题(因为之前在敏捷团队中工作过,所以感觉非常不对劲),然后才去思考敏捷各个方法的实践,这个系列的文章,纯粹针对各个问题进行拆招,并无一定的顺序。

1.2 团队背景

80%的团队成员入职不到3个月,大多数没有敏捷项目经验,或者是伪敏捷经验,虽有其形但不知所以然。

团队没有有经验的Scrum Master,目前的Scrum Master是之前的BA临时担任。

Product Owner都在国外,并且隶属于业务团第,具有流利英语交流能力的只有BA,开发成员基本只能进行书面交流而不能进行口语交流。

2. 团队之前的做法及遇到问题

2.1 之前怎么做

团队有使用backlog的概念,BA会提前将所有的story提前录入到backlog里面,进行前期梳理。与Product Owner把story确定之后,会针对某个story进行审批,然后会进行sprint开发。

2.2 遇到的问题

因为时差问题,以及团队中只有BA能流畅与Product Owner沟通,导致Story的审批比较慢,经常是Sprint要开始了,当前Sprint的Story还没审批,导致Sprint中的Story无法开工,有时候Product Owner放了几天假找不到人,团队就不知道怎么做

2.3 对策及遇到的新问题

因为Story审批不及时而影响到Sprint的开发,团队尝试过取消Story审批这个步骤,到Sprint开始的时候,如果来得及审批,就按照之前的做法;如果来不及审批的,按照优先级也将重要的Story放到Sprint里开始开发。

然而,这样导致出现了2个新的问题:

  1. 开始了Sprint之后,Product Owner发现Story里面的逻辑错了,要求把里面的逻辑改正,这导致前期估算不准,有可能导致原先计划的功能无法在本Sprint完成,需要推迟到下一个Sprint里。
  2. 这个是极个别的例子,其中一个敏捷团队,正好处于把产品部署到一个新国家的时期,其中这个新的国家用户在UAT阶段提出了一个需要变更的要点,否则不审批在这个国家上线,开发团队在没有通知我及Product Owner的情况下,将这个需求作为紧急需求指定进行开发,做了三四天发现赶不及原定的上线时间,汇报到我这里,才发现有这个紧急需求。(之后是叫停了这个需求的)

3. 问题分析及应对

3.1 问题分析

因为原公司原团队是从瀑布模式转变而来,对项目的开发理念仍然是以需求审批和变更为前提。对需求的变更仍然定的比较死,导致无法在敏捷中快速进行迭代开发。

而一旦放松,又会导致从一个极端走向另外一个极端,原先的极端是完全控制,需要Product Owner审批之后才能开始开发;后来的极端是完全放开审批,由敏捷团队自行根据优先级进行排序。

这说明无论是任何的流程或方法,都必须要有一定的弹性,不可以限制得太死,也不可放的太松。抓得太紧导致推进困难,放的太松容易混乱。

3.2 敏捷宣言及考虑思路

在敏捷宣言中,有一条是:
响应变化 高于 遵循计划
但从案例中可以看到,随时的响应任何变化不是一件好事,但从例子中可以看到,既不能A,也不能B。那么如何在中间获得取舍呢?

那么就要解决2个问题:

  1. 如果PO对backlog进行最后审批之前,有可能导致审批的需求不充足,令到开发团队迟迟无法开始下一个sprint。
  2. 如果不需要对backlog进行审批,团队自由选择,会导致做一些PO不愿意看到的事情。

PO为什么迟迟不愿意审批,因为PO属于业务部门,大部分情况下,业务部门对IT的要求都是:既要,也要,还要,但你不能不经我同意随便做…。这里涉及到对业务部门进行敏捷培训,达成共识,这个属于后话,因为本公司中,确实是IT先行转变成敏捷,而业务部门仍然以年度预算及目标为导向,相信这也是大部分公司的问题。这个另外开一篇文章进行描述。

思路:那么在这种情况下,如果假设审批的story为100%完成,那么,backlog中必定存在分析到90%,80%, 60%的story,既然PO不愿意担负审批未完成的story的责任,而作为IT管理者必须合理利用团队资源(否则团队成员就没有任务安排,导致公司资源浪费),可以从story的完成度上做文章。

3.3 应对策略

问题的分析与思路都弄清楚,接下来的应对策略就比较简单了,目前给到团队的规则是:

  1. 如果sprint开始之前,已经有充足的完成度为100%的story,那么团队可以按照正常的敏捷方式运作
  2. 如果sprint开始之前,没有足够的完成度为100%的story,那么SM需要和BA沟通,明确剩余的80%以上的story是否足够,并且要预演剩下的story是否能在下一个周期形成足够的80% story,如果可以,项目状态仍然是green的。
  3. 如果第二条中,BA预见到下一个周期无法形成足够的80%,需要向项目经理汇报,项目经理与PO及业务上级进行沟通,看是否需要推进项目优先级,让PO更多时间侧重于本项目,或者业务能接受80%完成度以下的story进入开发,导致改错成本增加。
  4. 如果前面都无法达成共识,作为团队管理的我可以提前将资源释放到其他的敏捷团队。

4 总结

团队管理,项目管理并不是非黑即白,敏捷也并不是只有一种方式,因为团队中PO并不属于IT团队,隶属于业务部门,本案例应该会是常见情况。团队规则的制定,也要根据实际情况考虑。如有其他的不同案例,欢迎留言讨论。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值