scrum计划

敏捷学习计划
本周计划
 学习敏捷基础知识
1；敏捷技术：《硝烟中的scrum和xp》  所有成员
2；持续集成技术：cruisecontrol和junit，findbugs等； 刘亮 负责指导
 结果检查
1；周五：上午9.00  4—1讨论学习心得，以及大家对敏捷的理解和认知程度；
2；周五下午：14.00刘亮讲解cruisecontrol如何使用，以及集成的框架。时间定为1个小时。
 达到效果
1；所有人对敏捷有一个理论上的了解，能理解scrum的流程。
2；每个人都必须掌握持续集成的释放方法，并且学会编写集成脚本

下周计划
 学习XP基础知识和尝试实践
1；《解析极限编程-拥抱变化》 所有成员；
2；TDD 知识：书籍《测试驱动的面向对象软件开发》
3；试点每日例会：例会时间（3月23日开始）9.00—9.15 主要汇报学习到的内容以及理解、遇到的问题。
4；例会地点：三楼乒乓球室

 结果检查
1；周五：上午9.00  4—1重点讨论TDD的理解、如何实施；

 达到效果
1；确定模拟测试选型框架：jmock还是其他的框架等，评估jmock学习曲线。
2；每个人都掌握TDD的使用，并且尝试编写过测试代码和打桩；

实施准备计划
准备计划：
 RMT方案分解
1；RMT方案和功能点讲解和规划  黄斌（3.28上午）
2；功能点分解，目的为了更加细化方案和功能点，方便估算。  黄斌（3.28下午）
3；对方案不合理的地方进行完善，相关模块负责人一共完成。（3.29）
4；尝试故事点估算：利用实践经验和卡片工具对故事进行故事点估算。（3.30）
5；详细设计文档输出：各个模块需要按照HPPD要求输出详细设计文档，测试方案文档等（3.31—4.2）.
 集成环境搭建
1；持续集成软件安装和环境搭建，以及模板脚本编写完成，运行起来持续集成服务器。（3.30） 刘亮
2；定好会议室以及准备插座，路由器等 准备搬家（3.31） 王四海

 过程文档模板
1；backlog文档模板写出来，放置到svn和论坛上（4.3） 王四海
2；tdd backlog跟踪文档写出来，放置到svn和论坛上（4.3） 王四海
实施计划
迭代分成四个阶段：
 Sprint 1 周期：4.4—4.22
 Sprint 2 周期：4.25—5.13
 Sprint 3 周期：5.16—6.3
 Sprint 4 周期：6.6—6.24

下面给出sprint 1 的详细执行计划和内容，后续每个计划会在前一个迭代结束前给出，因为要总结上一次迭代的经验和教训，重新制定计划。
具体实施计划
 Sprint 1 周期
三周
 Sprint 1 目标
通过测试
 sprint 1 计划会议
时间：4月4日
会议持续时间：4小时15分钟
Sprint 1 计划会议：13:00 – 17:00 （每小时休息10分钟）
• 13:00 – 13:30。产品负责人对sprint目标进行总体介绍，概括产品backlog。定下演示的时间地点
• 13:30 – 15:00。团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。
• 15:00 – 16:00。团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
• 16:00 – 17:00。为每日scrum会议（以下简称每日例会）安排固定的时间地点（如果和上次不同的话）。把故事进一步拆分成任务。
• 17:00 – 17:15。团队分工，根据个人喜好以及整体项目需要进行分工。
这个日程绝不是强制执行的。Scrum master根据会议进程的需要，可以对各个阶段的子进程时间安排进行调整。

 user story
由于很难找到一个既有丰富的需求知识、又有权利设置优先级的产品负责人。所以要用几个人一起扮演产品负责人的角色。团队所有成员一起作为产品负责人来计划用户故事。
 story point 数目
1；人数：5人
2；投入程度：50%（平均投入程度，第一阶段需要一段时间进入状态，另外需要边学习边实施）
3；理论可以完成故事点：5（人）×50%×15（天）=37（个）
4；实际准备完成故事点：32个。
 TDD
1；需要先完成单元测试，而后按照单元测试编写代码。
2；每个故事点执行顺序：先单元测试后代码的形式编写，每天自动执行测试代码。
 持续集成
1；从4月5日开始执行持续集成；
2；执行内容包括：单元测试，代码规范，findbugs以及clover（测试覆盖率），3；自动生成报告，确保团队所有成员都能够获得报告。
4；每天固定执行时间：17：00
5；不定时执行时间：代码提交svn，服务器即可检测执行。充分利用自动化工具。
 每日构建
由于前期项目代码很少无法达到构建的效果，所以构建时间后延；
1；从4月8日开始进行第一次构建；
2；固定构建时间：每天 17：00
4；产出构建报告，对于没有成功的构建要查找原因，避免下次再出现。

 进度跟踪
Scrum master必须每天认真查看和填写所有backlog以及燃尽图，对出现的问题进行及时修正。

 每日立会
1；决定找一间会议室，所有人都在这个会议室一起开发，然后将每日例会地点就在这个会议室的sprint墙前面，由每个人自己去更新scrum backlog画板。
2；每日例会时间：9点—9点15分。
3；需要所有人必须准时参加例会，没有理由不参加。。
1，每个人都描述三件事情：昨天做了什么事情？今天准备做什么事情？遇到了什么苦难？并根据这些是移动任务版上的及时贴。
3，立会不讨论问题，如果确实有不清楚需要讨论的地方，会后单独讨论；
4，scrum master更新燃尽图；
5，会议时间不多时，scrum master负责提示大家时间不多，时间到就建议大家结束会议。

 Sprint 1 演示
演示时间：4月21日9：00—10：00
演示的检查列表：
1，确保清晰阐述了sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
2，不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。
3，节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
4，让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。
5， 可能的话，让观众自己试一下产品。
6，不要演示一大堆细碎的bug修复和微不足道的特性。可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事。

 Sprint 1 回顾会议
会议时间：4月21日10：10—12：00
回顾是scrum第二重要的事情。第一重要的事情是sprint计划会议，因为回顾你改进的最佳时机。如果没有回顾就会让团队不断犯同样的错误，需要以下内容：
1， 产品负责人，整个团队都需要参加；
2， 根据讨论的范围设置时间为1到3个小时，最多不能超过3个小时，因为时间长了并不能提高效率，反而会让大家感觉到自己在开一些无聊的政治会议，毕竟我们不是公务员。
3， 单独选择一个会议室进行，不要在开发的房间进行，选一个相对正式和陌生的环境，避免大家注意力不集中；
4， Scrum master向大家展示sprint backlog，在团队的帮助下进行总结，包括重要事件和决策等。
5， 会上团队轮流发言，每个人都有机会在不被任何人打断的情况下说出自己的想法，他认为什么是好的，什么是不好的，那些还可以做得更加好一些等等，如果有问题请在其说完想法后提出异议。
6， 对预估的生产率和实际的生产率进行比较，如果差异比较大的话，我们就会分析是什么原因导致的这么大的差异，然后再下一个sprint进行改进，例如增加故事点、减少故事点或者重新拆分故事等。
7， 会议结束的时候scrum master对这次会议进行总结，得出下个sprint需要改进的地方。
8， 每个人都要按照哪里做得好，哪里还需要改进，哪里还可以做的更好这三点进行总结。然后团队所有的项目进行投票，找到下次需要改进的地方，一个人可以投同一个项目多次。

 团队凝聚力建设
1；时间：每周一次
2；活动形式：体育、娱乐均可，彻底放松身心；
3；俞翠负责组织和策划
 易用性迭代
Scrum master每周收集一次测试人员或者使用者对产品的使用评价和改进建议。

 要求
Sprint 1不要求一定严格按照故事点时间来完成，但是一定要保证质量，测试要认真编写，要求达到65%以上的覆盖率，对于没有完成的故事可以放到sprint 2迭代。

 希望达到的效果
1；让大家转变状态，进入紧张的敏捷流程中来；
2；掌握敏捷的标准动作，学会使用基本的工具；
3；学会TDD开发模式，并严格遵守，掌握基本要领，认识到TDD能带来的好处；
4；sprint 1 结束后，所有的测试代码全部通过验收测试。
5；掌握合理的任务量和时间估算，为下一步进行提供最有价值的参考，为重新评估团队提供依据。