迭代计划 培训笔记

1.产品流程

故事估算->发布计划->迭代计划->现场客户

2.项目周期
【循环】

发布计划 - 迭代计划 - 开发 - 最新版本 - 验收测试---在返回（发布计划）

3.发布计划

阶段一

用户表设计数据迁移

用户应用逻辑

论坛用户代码重构

故事四

故事五

故事六

…

阶段二

故事十

故事十一

故事十二

故事十三

故事十四

故事十五

…

阶段三

故事二十一

故事二十二

故事二十三

故事二十四

故事二十五

故事二十六

…

故事 是客户想要系统做的事情，适合在一至两个迭代内完成，并且是可测试的，他不一定是商业价值的直接体现。

迭代 是一个周期在2-4周，能够完成当前团队所能实现的，最具商业价值的功能，并可以提供一个可工作的小版本供发布。

Velocity 翻译为项目周转时间。代表团队在给定周期内能够完成多少商业价值，以便用于衡量将来该团队能够提供的商业价值。也即昨天的天气。

优先级 主要考虑商业价值，同时兼顾市场风险、商业风险、技术风险等因素在内的一个衡量数字，优先级越高通常意味着其商业价值越高

风险系数 综合商业环境、项目资源、技术以及项目环境等等因素在内的一个衡量数字，它是优先级的重要衡量指标之一。它通常出现在故事中。风险系数较大意味着优先级也较大。

负载因子 是综合项目成员的技术能力、技能集、精神状态等等因素，对于团队成员的一个负载系数。

理想时间 排除一切可能的外界干扰，同时排除自身的精神状态，职业态度等等因素，完成某项工作所需要的时间。

实际时间 理想时间乘上负载因子

任务 分配到项目成员，从故事切分的出来。通常任务时间不应该超过10个实际工作日。

前提

发布计划，昨日的天气，bugs

目标

选取下个迭代需要完成的故事，并附带明确的优先级

时间

下个迭代开始前一天

与会人员

客户，主要程序员，项目经理

时长

通常1-2个小时

目标

了解昨日工作进度和今日工作计划

发现问题

时间

每个工作日早上或者下午下班前

与会人员

所有团队成员，包括客户和项目经理

时长

5-15分钟

目标

向客户和管理者报告项目进展，小版本发布会议

增强团队自信心

时间

迭代最后一天

与会人员

客户的负责人，客户和项目经理，公司任何其他成员。

备注

会后有小型酒会，提供低度酒、咖啡、甜点、其他零食等。

目标

回顾得失

时间

发布会议结束后

与会人员

全体程序员+项目经理

备注

收集该类信息，作为下个迭代的回顾会的参考

项目经理职责

处理和外部团队的关系

组建团队

获取必要的资源

管理团队

解决团队中的问题

准备和完成各种统计报表(向管理层或者是客户报告)

及时更新项目计划和Velocity

程序员权利和义务

有权知道需求是什么，并有清晰的优先级

无论何时都要保证高质量的工作

有权从同事、上级或者是客户那里获取帮助

有权制定并更新自己的预估时间

有权主动申请任务，而不是被动的接受分配的任务

管理者和客户的权利

有权负责整体规划，有权了解什么可以实现、何时可以实现以及实现的成本

有权从每周的编程中获得最大价值

有权查看系统的运行状况，并确保系统能多次通过你指定的测试

有权更改计划、更换功能和改变工作优先级，而无须支付额外的费用

有权知道时间的安排的变化，以便及时作出选择，缩小范围，以便同预定日期同步。可以随时取消上述选择，从而得到体现投资的系统。

Xplanner实战

项目

迭代

故事

任务

报告进度

迭代进度报表

成员报表

团队报表