2020年2月28日00:54:40
第一次做记录,总是很像流水仗,凑合的看吧。
看板
因为特殊时期,原计划的看板由电子看板所代替,最后的样子如下:
| 任务池 |
已计划 |
研发中 |
研发完成 |
测试中 |
测试完成 |
已验收 |
已发布 |
| 9.任务 A |
6.任务 D |
8.任务 F(a) |
2.任务 I |
4.任务 J(d) |
3.任务 K |
1.任务 L |
|
| 10.任务 B |
12.任务 E |
7.任务 G(b) |
|
|
|
|
|
| 11.任务 C |
|
5.任务 H(c) |
|
|
|
|
|
因为原来仅仅拆分了 “故事”,并没有对 “故事” 进行任务的拆分,所以在 “故事” 拆分完之后的一天,我和每个开发对优先级高的 “故事” 进行了任务的拆分(这部分操作 X 指导要在线下,不能在线上),根据大家原来的工时评估,进行了更新的任务时间评估(在此,真心感谢开发小伙伴的对我的支持)。并且在当天下午,和产品负责人反馈了 2 周后可交付的内容(后来还是不承认了。。邮件的重要性体现出来了)。
- BTW:有几个问题,我用了比较笨的方法解决了下。
- 同一任务前后端如何标记的问题。
后端开发会比前端快很多,所以大概就遵循 3 个原则。第一,同时开始标记后台是负责人,前端那是参与人。第二,前端或后端先开始标注对应开发人员。第三,后端开发结束后,前端作为负责人,后端作为参与人。
- 看板与需求对应
我在每个看板任务前加了和对应 prd 文档对应的编号,所以可以比较容易的去找 prd 文档。
- 在过程中发现工作量大,拆分处理
如果发现过程中某一个 “故事” 或者任务太大,就重新建立新的需求(比如 8.任务 F,就会拆分出 8-A.任务 F)
- 故事点和团队效能
故事点按照实际的工时来代替了,团队效能的问题,我记录了每个人实际的工时,打算最后按比例进行评估。
顺便吐槽一下(也可能是我用的比较差),公司推进的 worktile,没办法把故事拆分的子任务显示在看板上,没法标注阻塞问题,看板优先级显示不太明显,没法显示当前进度,进度状态只能向前不能修改。。。
当然都是我的笨办法,如果有一天有好的办法,我再重新修改吧。
后记
刚翻了下第一篇记录,发现计划和实际差了很多。还是鼓励自己一下,路漫漫其修远兮,吾将上下而求索。
↙↙↙阅读原文可查看相关链接,并与作者交流