运用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. 发布范围核实与确认；
---------------------------------------------------------------------------------------------------
最后再次感谢大家，感谢公司，感谢团队，感谢我的老婆一直以来最我的支持！！！你们的支持是我最大的动力。