迭代计划 培训笔记

1.产品流程

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

 

2.项目周期【循环】

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

 

3.发布计划

 

阶段一

用户表设计数据迁移
用户应用逻辑
论坛用户代码重构
故事四
故事五
故事六

…

 

阶段二

故事十
故事十一
故事十二
故事十三
故事十四
故事十五
…

 

阶段三

故事二十一
故事二十二
故事二十三
故事二十四
故事二十五
故事二十六
…

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

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

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

 

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

 

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

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

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

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

前提
发布计划，昨日的天气，bugs
目标
选取下个迭代需要完成的故事，并附带明确的优先级
时间
下个迭代开始前一天
与会人员
客户，主要程序员，项目经理
时长
通常1-2个小时
目标
了解昨日工作进度和今日工作计划
发现问题
时间
每个工作日早上或者下午下班前
与会人员
所有团队成员，包括客户和项目经理
时长
5-15分钟
目标
向客户和管理者报告项目进展，小版本发布会议
增强团队自信心
时间
迭代最后一天
与会人员
客户的负责人，客户和项目经理，公司任何其他成员。
备注
会后有小型酒会，提供低度酒、咖啡、甜点、其他零食等。
目标
回顾得失
时间
发布会议结束后
与会人员
全体程序员+项目经理
备注
收集该类信息，作为下个迭代的回顾会的参考

 

项目经理职责

处理和外部团队的关系
组建团队
获取必要的资源
管理团队
解决团队中的问题
准备和完成各种统计报表(向管理层或者是客户报告)
及时更新项目计划和Velocity

 

程序员权利和义务

有权知道需求是什么，并有清晰的优先级
无论何时都要保证高质量的工作
有权从同事、上级或者是客户那里获取帮助
有权制定并更新自己的预估时间
有权主动申请任务，而不是被动的接受分配的任务

 

管理者和客户的权利

有权负责整体规划，有权了解什么可以实现、何时可以实现以及实现的成本
有权从每周的编程中获得最大价值
有权查看系统的运行状况，并确保系统能多次通过你指定的测试
有权更改计划、更换功能和改变工作优先级，而无须支付额外的费用
有权知道时间的安排的变化，以便及时作出选择，缩小范围，以便同预定日期同步。可以随时取消上述选择，从而得到体现投资的系统。

 

Xplanner实战

项目
迭代
故事
任务
报告进度
迭代进度报表
成员报表
团队报表