第三方项目开发管理经验总结分享(PPT 46页)

SPM
管理整个团队并负责项 目的开发进度和风险的管 控并主持版本级的迭代回 顾会议
技术负责人
负责各专业组的功能的 评审,任务的分解，开发 时间的评估和风险的分 析等。
前段测试人员
跟开发并行的进行各模 块应用的测试
在软件项目的开发过程中，有三大类计划，总体计划：主要确定项目的范围，项目完成时间。发布计划：是在总 体计划的基础上，确定分阶段推出软件实现的功能。开发计划：是在发布计划的基础上，为保证如期发布功能而 制定的计划。
▪ 每个迭代都选取高优 先级功能进行开发
▪ 每天将最新功能集成到 产品中
▪ 开展并行测试，在开发 的最早期发现并解决产 品中的缺陷
▪ 主张用户能够全程参与 到整个开发过程中
▪ 对需求变化和用户反馈 进行动态管理并及时集 成到产品中
每轮迭代的操作流程
需求录入到 RTC中
项目总体 功能规划
1 需求的收集,分析 和 提炼并设计交互文档
3．几点注意事项 （1）： 因最开始制定的发布计划未覆盖全部的功能，所以SPM应在制定发布计划时切不可造成前线宽松后面紧 张的情况，应尽量加快已明确的功能的开发速度。 （2）： 在制定发布计划时，应使用 “需求复杂性”、”技术复杂性的系数”等方法，估算每个功能的开发时间。 （3）： 制定的软件开发任务应尽量做到每天可以度量，以便保证计划的顺利执行。
状态 ▪ 指导迭代计划的制定
迭代计划
内容 ▪ 当前迭代的交付范围 ▪ 项目风险与迭代风险 目的 ▪ 指导团队成员开展日
常工作 ▪ 跟踪并刷新发布计划
通过对需求的优先级和风险的高和低，纳入到不同时段的迭代开发中
分类
价
值 优 先 级 (PV)
必须有 应该有 可以有
描述
公司要求的标准化功能 能提升用户满意度，增强产品竞争力的功能需求 具有创新性的功能，提高产品买点和产品竞争力 市面上已经有的功能，但在交互方式和功能上有创
风险发生的概率一般或对项目造成的影响较弱
风险发生的概率一般并不会对项目照成严重影响
价值优先级
7~9 4~6 2~4 0、1
需求优先级
= PV*10+PR
用户需求开发工作量和风险系数的度量单位
用户需求开发工作量的度量单位
单位： 采用点数来计算，按照1点/1人 1天来估算
说明： 用户需求开发工作量点数是功能实现难度的
2．计划的制定 2．1发布计划 在制定发布计划时，根据功能的价值和风险的优先级进行综合考量来确定功能的实现顺序，确定实现顺序后参考 以前的项目或根据经验估算实现每个功能的时间，制定发布时间和发布内容。
2．2开发计划 制定开发过程中应对每个功能再细化，同时将已确定的功能集中从实现技术角度考虑划分成软件任务。在确定开 发任务后与开发人员讨论完成时间，同时SPM还应考虑单元测试时间。确定的时间应与发布计划中的功能发布时 间比对，如超出发布计划准许的时间，应修改开发计划。
新
在项目时间允许的情况下，可被交付的功能需求
这次不会有
本项目暂不考虑实现的功能
价值优先级
7~9
4~6 1~4
0
风 险 优 先 级 (PR)
风险等级
紧急 严重 中等 低
wenku.baidu.com描述
风险发生的可能性非常高，一旦发生会对项目产生 很大的影响，并且难以消解
风险发生的概率非常高，一旦发生会对项目产生较 大影响，对项目进度可能造成影响
用户需求开发工作量的评估会议操作指导说明
用户需求任务分配会议操作指导说明
参与人员：
参与人员：
− UE,SPM,专业组组长,敏捷组长,测试人员,UI,和 3～5名相关模块软件工程师
SPM, UE,UI,专业组组长,敏捷组长, 相关模块 所有软件开发人员
− 原则： − 用户需求的开发工作量的评估要充分考虑所有
敏捷开发的核心在于迭代化开发，即采用短的迭代周期持续交付可工作的软件 迭代开发的过程
迭代化开发
4个重要特性
风险-价值 驱动开发
持续集成 与并行测试
持续反馈
▪ 将整个开发过程拆分 为多迭代周期
▪ 每个迭代都要交付可 以被用户使用、能给 用户带来价值的产品
▪ 对所有工作条目结合 开发风险与功能重要 性进行优先级排序
高效和快速反应的敏捷开发项目团队
项目团队成员和各自职责
敏捷项目开发团队的成员由软件开发人员，前段测试人员，UE设计师，UI设计
师，软件项目经理(SPM)，敏捷组长，技术负责人(各专业模块的小组长) 所组成的 一个团队。
项目团队成员和各自职责
敏捷组长
负责收集和反馈日常开发 中影响项目进度和质量的 问题给SPM，并主持召开 专业级的迭代回顾会（专 业级包括影像组，应用组， 网络组，系统UI组等）
角色的工作量，并采用团队参与的形式进行评 估，提高评估的准确性
− 评估方法： − UE澄清需求点 − 软件工程师将点数写在便签纸上 − SPM收集工作量，若评估点数相差3点以下，
则取平均值；若超过3点，则进行讨论达成一 致意见
− 分配方法：
客观 描述，是随人员而变动，且随着时间 改变的，用于估算工作量作为迭代化开发 中当前迭代工作量的估算以及人力的安排。
用户需求开发风险系数的度量单位
单位： 用户需求的开发风险的范围为1-9 级，数值 越大表示实现难度越大
说明： 风险值是根据用户需求实现的技术难度以及 实现后可能出现问题的几率来决定的
每轮迭代工作量的确定和任务分配
用 户 需 2求 评 审
用户需求澄清 用户需求优先级排序
用户需求开发难度的评估
6 每轮迭代完成后的
迭代回顾会议
刷新
迭代开发过程中
3 开发团 队能力 评估
4 功能开发的风险 评估
5 组织评审团，评 估开发完成时间
项目初始 阶段
制定
项目发布 计划
项目启动前的发布计划和和启动后的迭代计划
发布计划
内容 ▪ 迭代数量 ▪ 迭代周期 ▪ 项目交付范围 ▪ 项目风险 ▪ 关键任务时间结点 目的 ▪ 帮助团队了解当前项目
1．计划的用途 总体计划：一般是开发方在初步了解需求后做出的一种时间上的承诺，明确项目的范围和规定项目完成的日期， 一般项目的范围使用功能表示。发布计划：是根据每个功能优先级、每个功能的可能变更程度，来确定各功能的 开发顺序，分阶段制定功能的发布时间。开发计划：是针对每个功能做出的开发计划，同时，通过制定开发计划 也进一步对需求进行分析、确认，对技术难度进行评估。