[个人心得]敏捷管理Agile中Epic, story 和task的用途和管理目标

1. 背景

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

欢迎大家把管理中遇到的问题提出来,一起讨论解决方案

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

目前团队有使用Epic以及Story,Story会根据颗粒度拆分成子Story,每个sprint会讨论包含哪些Story,然后Scrum Master就根据story管理进度了。

一接手这个团队,跟SM的沟通,SM说没办法管控进度,Sprint中的Story,如果有延时的话,都是到测试开始进入的时间,才知道原来开发没完成。

一句话:目前无法在过程中监控每个Sprint的情况,只有在Sprint结束的时候,才知道哪些完成了,哪些没有完成。

经过细节的讨论,发现目前管理如下

讨论点当前做法造成问题
是否有Epic有Epic,并且归类相对清晰没有问题
是否有Story有Story,并且能根据客户需求归类没有问题
Story颗粒度是否细化有细化到最小颗粒度没有问题
Story point是否估算团队集体估算,但估算后的story point没有和开发人天联系起来无法定义人天基准,就无法进行计划
开发及测试是否有Task没有task,开发及测试直接在Story上assign1. 工作任务没有明确划分
2. 整体上,不到最后,不知道前序任务是否超时
3. 并行任务无法体现
团队成员是否每天更新状态没有,也无法做到,因为前后端,测试都是针对同一个story工作并指派团队成员无处更新状态

3. 问题分析

抛开大的项目计划管理,在sprint的细节管理上,对每个sprint的task完成度及管控都是非常必要的,因为一般一个sprint的周期是2周,一开始3天就相当于过去30%的时间,5天就相当于50%的时间过去了。也就是一天不管理,就很有可能产生10%的偏差,半周不管理,产生的30%偏差,几乎不大可能在剩下的7天里拉回来。

所以敏捷提倡的每日站会这个原则,就是为了避免10%的偏差而存在的。

在本文案例中,因为所用的工具,没有细分到task,导致开发成员不去(也没地方)更新每日的开发情况,仅靠站会说自己昨天做了什么,及时是没遇到问题,也无法管理偏差分析的。组员不做,是执行问题,方法没制定好,是管理问题,所以要从管理制度和方法上进行解决。

对本案例中的问题进行一一分析

3.1 问题1,Story Point和工作人天混肴或工作人天缺失

因为只有使用Story进行管理,虽然从需求上分解了story,但在开发的过程中,不能将Story Point 直接向开发人天进行转换。而开发人天预估是很基本的管理基准,缺失了人天的预估基准,就无法对后续的工作进行偏差分析。

3.2 问题2,系统上没有将开发责任定位到人

一个story,可能涉及到前端,后端,通用模块开发及测试共同协作,目前是在story上只能指派一个责任人,任务安排就不准确,虽然SM在Excel上有记录,但这个记录就失去了管理的及时性。

3.3 问题3,开发团队成员没有地方自行更新状态

虽然SM可以时不时对成员进行询问,以便更新状态,但这样做很耗费时间,并且SM也很难坚持每天找各个询问状态

综合上述几个问题,造成了目前管理者无法对项目进行有效的管理。

4. 解决思路及原则

  1. Epic归类清晰,不需要改进
  2. 因为敏捷是没有风险管理,每个story要拆分到5天内能完成,这样在sprint结束时可以及时的给PO进行展示,如果团队理解及开发错误,在下一个sprint可以变更。目前的story粒度够细,可以在一个sprint内完成,这点暂时不需要改进。
  3. 需要将Story Point与开发人天进行明确的分离,并且表达不同的含义,以便进行需求与开发的管理
  4. 需要将任务指派到每一个人,在评估sprint进度的同时,也能从单个人的维度上分析每个人在sprint中的工作任务是否安排满。
  5. 每个人能针对自己的任务进行更新,SM及TL可以根据工作燃尽图就能知晓各个人的情况,除了站会成员反馈问题之外,可以主动对有问题的成员或任务进行关怀及指导(感觉这点对有很多新人的团队非常重要,因为很多新人不大敢把问题向上反馈,这里会涉及到另外一个问题:新人在更新状态时也不敢让状态变红,这个将来找机会再写)

5. 具体方案及措施

5.1 明确划分Story Point与人天的关系及用途

确定将Story Point作为衡量产品复杂度的标准,Story与Story横向比较,如果Story A需要50 Story Points, 而Story B为100 Story Points,那在管理Story的时候,可以很明确的知道Story B是A的2倍复杂度。

同样的Story Point,不同的开发者估算的时间可以不同,因为现实情况下,资深开发人员5天可以开发完的代码,菜鸟开发可能需要10天或更多。也就是说,一个50 Story points的Story,资深开发可能需要10人天,而菜鸟开发需要20人天。当然,这个可能涉及到每个人估算的正确率。比如资深开发需要10人天的,预估了8人天;菜鸟开发需要20人天的,估算了14人天,这个可以通过后续分析逐渐让团队成员对自己的估算更加准确。

综合来看,当估算正确的情况下,对于同一个开发人员,估算Story Points为100的任务,是比Story Points为50的人多花费一倍的时间。也就是说,对于不同的开发人员,Story Points/人天的比值,应该是一样的。而这个比值越大,代表这个程序员的效率越高。

5.2 使用Story与Task分别承载Story Point与人天,确定用途

明确了Story Point与人天用途之后,Story与Task的更高一步用途就可以定下来了。Story用来管理产品功能的基准与进度,Task用来管理开发的基准与进度。Story可以直接产生对外的汇报数据,而Task可以直接产生对内的管理数据。

Story与Task不一定成固定比例关系,比如一个大型系统,底层架构与核心功能task需要到达100%,可能Story的进度才为1%。或者一个Story,安排在一个Sprint的Task都完成了,结果验收不通过,那各个Task=100%,Story可能=0%或20%,这意味着在下一个Sprint中,要增加Task进行修改(当增加之后,Task整体完成度就<100%了)。但整体来说,当一个Story下的task都完成的时候,Story也应当是100%完成。

5.3 Task分配到人,以便进行管理

团队中每一个成员的工作都应该受到管理,因此,一个story在sprint中分配到3个人,就必须至少有3个tasks或者更多。只有每个人的任务都在系统中有体现了,才能进行下一步的管理。

5.4 团队成员每日都应该更新自己的Task使用时间和进度。

一开始的时候,估计成员没有养成更新自己task的习惯,这个已经与SM打好招呼,让她每天从系统上拉出一份报表,看谁没有更新的,提醒他在站会之前更新,希望将来能做到的是每天下班前更新,SM,PM及TL可以查看状态信息,以便在第二天站会的时候能有效的解决问题。

6. 总结

无论是瀑布还是敏捷,管理方式都是不断进步的,团队的成熟度,会影响方案及措施的执行结果,选择最适合的方法,才是最好的。

  • 3
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值