运用Scrum做项目管理真实案例之六

引言：

我会以系列文章的形式跟踪记录我现在正在做的一个完整运用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. 发布范围核实与确认；

---------------------------------------------------------------------------------------------------

最后再次感谢大家，感谢公司，感谢团队，感谢我的老婆一直以来最我的支持！！！你们的支持是我最大的动力。