引言:
我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记,里面会有一些经验教训总结心得,以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵,当然我更希望大家多多提宝贵意见,读者的支持是我最大的动力。(之一,之二,之三,之四,之五,之六)
============================================================================================
这篇将是这个系列文章的最后一篇,主要把我们项目总结会议的一些结论给大家做一个分享:
会议议题
一、如何开好Iteration Planning Meeting迭代计划会议
1. 会议的目的是什么
2. 会议的流程是什么
3. 如何提高会议中的估算效率
二、本项目中的敏捷实践方法
1. 沟通机制的建立
2. 开发流程的定义
3. 敏捷宣讲Training
4. Team所有成员主动性(RD直接参与设计)
5. 测试的早期参与
一、Iteration Planning Meeting
1. 会议目的
ü 全体成员了解Story,PO讲解本次迭代的所有Story
ü 估算本次迭代的规模
ü 划定范围,下一个Iteration我们将要完成什么
ü 制定本次迭代计划,产出修正的Sprint Backlog
ü 产出任务看板或者与之相类似的东西(我们用的是Excel看板)
2. 会议流程
2.1 会前准备:
2.1.1 根据Product Backlog挑选出本次迭代会议可能完成的Sprint Backlog列表(可能包括上个Iteration演示后的客户反馈以及技术改进重构等,列表必须已经按优先级排序)。
2.1.2 提前把此Sprint Backlog列表发给团队所有成员,大家事情可以预习,并尽可能对列表中的Story提出问题记录疑点。
2.1.3 在会议前,还要根据本次计划会议要讨论的Story的个数以及难易度,对每个Story的讲解以及评估计划好时间。以便在会议中主持人可以控制好时间,如果超时可考虑跳过。
2.2 计算本次迭代可以利用的资源时间,根据上次Iteration经验计算本次Iteration可能完成的SP(Story Point)。
2.3 请PO或者SA按照初步的Sprint Backlog条目顺序讲解需求,讲解完后团队所有成员与PO或者SA进行Q&A。之后团队对Story进行评估,估算SP。
2.3.1 Q&A的技巧,我们总结了一下做了一个Q&A checklist如下(一致认为最后三点最为重要):
ü 要做什么功能?有什么特殊要求?如性能等
ü 有无UI界面?有特殊操作上的要求吗?
ü 与系统中其他功能的关系是什么?
ü 检出点是什么,最重要的几个Test Case
ü 验收标准是什么或者说是如何Demo
2.3.2 估算技巧(文章后面单独列出)
2.4 估算完一条后再进行下一条,直到团队本次Iteration时间饱和为止。
2.5 大家一起最后再确认一次确定好的Sprint Backlog,并维护任务看板或与之相类似的东西(我们用的是Excel看板)。
2.6 维护看板时,如果有充足的时间最好每个Story都要被分解完Task,团队一起对Task过一遍看有无异议。
2.7 确认完毕后退出会议。
3. 如何提高会议中的估算效率
PO讲解需求,直到可评估即可,细化内容下去和单独沟通;
只对Story进行SP评估,不评估Task;
PO澄清需求并做Q&A后,利用评估纸牌法做SP评估;
三个六,6分钟PO讲解需求,6分钟Q&A,30秒内出牌。如果有异议6分钟PK(并无绝对,总之要控制时间);
二、敏捷实践
版本发布顺利原因总结,四步骤走:
1. Lock code;
2. 确定范围;
3. To do list 验证;
4. 可交付范围。
具体动作:
1. 发布前一天:
2. 清楚要发布的范围;
3. 自测通过,锁定代码;
4. 准备工作充分,List检查项,一一检查,包括安装手册、数据库脚本、程序包、干净环境(虚拟机)安装;
5. 发布当天:
6. Sanity test执行到位;
7. 发布范围核实与确认;
---------------------------------------------------------------------------------------------------
最后再次感谢大家,感谢公司,感谢团队,感谢我的老婆一直以来最我的支持!!!你们的支持是我最大的动力。