第三方项目开发管理经验总结分享

▪ 项目后期测试才介入,看到的
往往是开发人员理解过的需求, 而不是真正客户的需求，通过 测试之后的产品，客户却发现 不是他所想要的或UE规划的 产品。
建立版本级和专业级迭代回顾机制
迭代回顾目的
分析现状 分析前几轮的迭代数据，为下一轮迭代计划制定提供依据 控制风险 识别风险，制定并跟踪执行风险消解计划 持续改善 分享好的经验推而广之、提出问题警醒他人并解决问题， 促进团队持续进步
并行测试
VS
编码 综合测试
迭代软件 版本发布 综合测试 版本发布
版本发布
迭代式开发模式下的并行测试 与 传统的瀑布式开发模式的测试 优缺点 对比
优点： 缺点：
▪ 在整个迭代过程中与开发并行开展的测试
，阻止把测试作为一个单独的活动压缩到 迭代末或版本末开展，提前发现并解决问 题，软件质量提前被度量。
管理整个团队并负责项 目的开发进度和风险的管 控并主持版本级的迭代回 顾会议
SPM
技术负责人
前段测试人员
跟开发并行的进行各模 块应用的测试
负责各专业组的功能的 评审,任务的分解，开发 时间的评估和风险的分 析等。
在软件项目的开发过程中，有三大类计划，总体计划：主要确定项目的范围，项目完成时间。发布计划：是在总 体计划的基础上，确定分阶段推出软件实现的功能。开发计划：是在发布计划的基础上，为保证如期发布功能而 制定的计划。 1．计划的用途 总体计划：一般是开发方在初步了解需求后做出的一种时间上的承诺，明确项目的范围和规定项目完成的日期， 一般项目的范围使用功能表示。发布计划：是根据每个功能优先级、每个功能的可能变更程度，来确定各功能的 开发顺序，分阶段制定功能的发布时间。开发计划：是针对每个功能做出的开发计划，同时，通过制定开发计划 也进一步对需求进行分析、确认，对技术难度进行评估。 2．计划的制定 2．1发布计划 在制定发布计划时，根据功能的价值和风险的优先级进行综合考量来确定功能的实现顺序，确定实现顺序后参考 以前的项目或根据经验估算实现每个功能的时间，制定发布时间和发布内容。 2．2开发计划 制定开发过程中应对每个功能再细化，同时将已确定的功能集中从实现技术角度考虑划分成软件任务。在确定开 发任务后与开发人员讨论完成时间，同时SPM还应考虑单元测试时间。确定的时间应与发布计划中的功能发布时 间比对，如超出发布计划准许的时间，应修改开发计划。
项目团队成员和各自职责
UE
负责交互的设计，编写用户故事和功能
的验收条件，并验收需求点的完成情况
UI
负责图片和动画的输出，并验证视觉效
果
软件开发人员
负责各功能模块的开发
敏捷组长
负责收集和反馈日常开发 中影响项目进度和质量的 问题给SPM，并主持召开 专业级的迭代回顾会（专 业级包括影像组，应用组， 网络组，系统UI组等）
3．几点注意事项 （1）： 因最开始制定的发布计划未覆盖全部的功能，所以SPM应在制定发布计划时切不可造成前线宽松后面紧 张的情况，应尽量加快已明确的功能的开发速度。 （2）： 在制定发布计划时，应使用 “需求复杂性”、”技术复杂性的系数”等方法，估算每个功能的开发时间。 （3）： 制定的软件开发任务应尽量做到每天可以度量，以便保证计划的顺利执行。
版本级
UE/UI 代表 测试代表 敏捷组长
专业级
小组迭代状况分析 关注小组级风险 解决跨职能协作问题 制定小组级团队改善计划
各模块的UE/UI 负责人 测试人员 敏捷组长 软件工程师
会前准备
收集并分析迭代数据 (1)分析现状 (3)持续改善
会议议程
(2)风险控制与问题解决 (4)刷新发布计划(仅版本级)
持续集成 与并行测试
▪ 每天将最新功能集成到 产品中 ▪ 开展并行测试，在开发 的最早期发现并解决产 品中的缺陷
持续反馈
▪ 主张用户能够全程参与 到整个开发过程中 ▪ 对需求变化和用户反馈 进行动态管理并及时集 成到产品中
每轮迭代的操作流程
需求录入到 RTC中
1
需求的收集,分析 和 提炼并设计交互文档
▪组织小组成员反馈组间、跨职能协作方面的问题，并制定解决方案 前端测试人员、 UE、UI、软件工程师 ▪回顾前期发现的风险跟踪结果 ▪识别风险并参与风险跟踪计划的制定 ▪反馈组间、跨职能协作问题，参与制定解决方案
!注意事项： 1. 遗留未按计划完成的需求和问题需要给出跟踪计划，并要有解决方案、负责人、跟踪人以及时间点等 要素 2. 组间、跨职能协作问题一定要知会相关人员，要有跟踪责任人 3. 检讨出来的问题和风险以及改善对策，需要作为小组长的任务录入RTC中跟进处理
用户需求澄清 用户需求优先级排序
用户需求开发难度的评估
5 3
6
每轮迭代完成后的 迭代回顾会议
迭代开发过程中
刷新
项目总体 功能规划
用 户 需 2 求 评 审
开发团 队能力 评估
4
功能开发的风险 评估
项目初始 阶段
项目发布 计划
组织评审团，评 估开发完成时间
制定
项目启动前的发布计划和和启动后的迭代计划
会后执行
跟踪执行会议决议事项
迭代分析数据来源（RTC）
会议议程1：分析现状
敏捷组长
分析 现状
▪汇报会前的数据分析结果，组织团队成员对数据分析结果进行讨论 前端QT、UE、UI、软件工程师 ▪参与数据分析结果讨论，反馈问题
!注意事项：
1. 数据分析讨论的时候要综合考虑前几轮的情况
2. 分析未完成的需求时要分析是否因为模块间的依赖关系或者需求开发难度大所造成，并给出解决思路 3. 未修复的严重BUG时不要深入讨论如何解决，会后再讨论解决方案，要关注其是否可能带来风险以及对后 期工作量的影响
分析现状
会议内容概要
项目迭代状况分析 关注项目级风险 解决组间协作问题 解决跨职能协作问题 制定版本级团队改善计划 刷新发布计划
参与人员（角色） SPM
迭代回顾会议的议题，
职责
组织团队开展迭代回顾 总结项目UE/UI方面的迭代状况 总结项目测试方面的迭代状况 总结各小组迭代状况 总结小组UE/UI方面的迭代状况 总结小组测试方面的迭代状况 组织小组开展迭代回顾 总结故事实现方面的迭代状况
!注意事项： 1. 总结经验教训时一定要形成决议和改善对策， 2. 持续改善方案重点要关注在项目管理与过程执行上，具体技术问题的解决不要在此讨论
项目管控工具
RTC 项目管理系统功能简介
RTC（IBM公司开发的一个集软件开发和项目管理的团队协同工作的一个工具）
作为新一代的软件交付协作环境，为软件开发团队提供了从需求到计划，从开发到最 终交付的完整平台。它提供的功能丰富而灵活，一个团队如果能够熟练运用 RTC 进行 软件开发活动的支持管理，必将大大提高生产效率，减少管理和沟通协作的成本，它 强大的代码管理和版本控制功能也为软件开发团队很好地解决了协作开发中繁琐而复 杂的问,RTC这个强大的工具能够更好地支持软件开发团队的工作，交付更多更好的产 品.
− 原则： − 用户需求的开发工作量的评估要充分考虑所有 角色的工作量，并采用团队参与的形式进行评 估，提高评估的准确性 − − − − 评估方法： UE澄清需求点 软件工程师将点数写在便签纸上 SPM收集工作量，若评估点数相差3点以下， 则取平均值；若超过3点，则进行讨论达成一 致意见
SPM, UE,UI,专业组组长,敏捷组长, 相关模块 所有软件开发人员

4~6 1~4 0


风险等级 风 险 优 先 级 (PR)
紧急 严重 中等

描述
风险发生的可能性非常高，一旦发生会对项目产生 很大的影响，并且难以消解 风险发生的概率非常高，一旦发生会对项目产生较 大影响，对项目进度可能造成影响 风险发生的概率一般或对项目造成的影响较弱
价值优先级
7~9 4~6 2~4
敏捷开发的核心在于迭代化开发，即采用短的迭代周期持续交付可工作的软件
迭代开发的过程
4个重要特性
迭代化开发
▪ 将整个开发过程拆分 为多迭代周期 ▪ 每个迭代都要交付可 以被用户使用、能给 用户带来价值的产品
风险-价值 驱动开发
▪ 对所有工作条目结合 开发风险与功能重要 性进行优先级排序 ▪ 每个迭代都选取高优 先级功能进行开发
− 分配方法： − 专业组长根据每轮迭代周期，迭代任务和需求 工作量的点数来具体把各需求分配给不同的工 程师，需求的UE 负责人记录对应责任人和开 发完成时间并在会后 录入到RTC 系统中，方便后续需求的跟踪管 理。
每天简短的例行沟通 早站会
例会目的 例会步骤
▪ 清晰并承诺自己的工作计划 ▪ 了解其他成员的工作进展进而了解项 目组的工作进展 ▪ 根据其他成员和项目组的工作进展， 以及其他团队成员支持情况，调整自 身工作 ▪ 寻求和给予团队成员工作配合和支持 ▪ 暴露及跟踪风险和问题
会议议程3：持续改善
敏捷组长 ▪汇报上一轮迭代形成的决议事项的完成情况，对于未完成的需要说明原因和解决方案，并落 实责任人
持续 改善
▪组织团队成员讨论团队出现的问题，列举做的好的，做的不好的，并多问为什么
▪组织团队成员讨论问题的解决方案，制定对策和行动计划 前端测试人员、 UE、UI、软件工程师 ▪提出团队做的好的和不好的，并积极思考问题的解决方案
发布计划
内容 ▪ 迭代数量 ▪ 迭代周期 ▪ 项目交付范围 ▪ 项目风险 ▪ 关键任务时间结点
迭代计划
内容
▪ 当前迭代的交付范围 ▪ 项目风险与迭代风险 目的
▪ 指导团队成员开展日 常工作
▪ 跟踪并刷新发布计划
目的
▪ 帮助团队了解当前项目 状态 ▪ 指导迭代计划的制定
通过对需求的优先级和风险的高和低，纳入到不同时段的迭代开发中
第三方项目开发管理经验总结分享
主讲人： 蔡小春
2014年12月 天珑移动UED
高效和快速反应的敏捷开发项目团队
项目团队成员和各自职责
敏捷项目开发团队的成员由软件开发人员，前段测试人员，UE设计师，UI设计
师，软件项目经理(SPM)，敏捷组长，技术负责人(各专业模块的小组长) 所组成的 一个团队。
4. 迭代需求的完成速率相对前几轮有较大波动时要分析波动原因
会议议程2：风险控制与问题解决
敏捷组长 ▪检讨上轮迭代的工作完成情况，如果没有完成，将剩余工作移动到本轮迭代 ▪组织小组成员根据迭代数据分析讨论结果，结合项目现状识别项目中可能存在的风险
风险控制 与 问题解决
▪对于讨论出来的风险和问题，需要在RTC创建风险工作项
分类
描述


价值优先级
7~9
价
值 优 先 级 (PV)
必须有
公司要求的标准化功能 能提升用户满意度，增强产品竞争力的功能需求 具有创新性的功能，提高产品买点和产品竞争力
市面上已经有的功能，但在交互方式和功能上有创 新 在项目时间允许的情况下，可被交付的功能需求 本项目暂不考虑实现的功能
应该有 可以有 这次不会有
▪ Step1：各成员各自汇报需要什么支持， 各自的迭代目标能否按时完成， 有什么问题和风险） 备注：QT对当前状态进行预警 ▪ Step2：风险问题跟进 ▪ Step3：总结，指出改进项
迭代式开发的并行测试和瀑布式开发测试参与阶段对比
迭代周期
持续代码开发
需求
设计 持续集成
开发 人员 前段 测试 人员
需求优先级
= PV*10+PR


低

风险发生的概率一般并不会对项目照Hale Waihona Puke Baidu严重影响
0 、1
用户需求开发工作量和风险系数的度量单位
用户需求开发工作量的度量单位 用户需求开发风险系数的度量单位
单位： 采用点数来计算，按照1点/1人 1天来估算 说明： 用户需求开发工作量点数是功能实现难度的 客观 描述，是随人员而变动，且随着时间改 变的，用于估算工作量作为迭代化开发中当 前迭代工作量的估算以及人力的安排。
单位： 用户需求的开发风险的范围为1-9 级，数值 越大表示实现难度越大 说明： 风险值是根据用户需求实现的技术难度以及 实现后可能出现问题的几率来决定的
每轮迭代工作量的确定和任务分配
用户需求开发工作量的评估会议操作指导说明 用户需求任务分配会议操作指导说明
参与人员：
参与人员：
− UE,SPM,专业组组长,敏捷组长,测试人员,UI,和 3～5名相关模块软件工程师
▪ 所有模块开发完并集成后才释
放版本给测试导致大量的缺陷 在项目后期被发现，质量和风 险难以控制，项目进度的延迟。
▪ 可以及时纠正软件开发的功能与UE规划
的功能或客户需求保证一致，避免最后开 发完了才发现与客户要求或UE规划的要 求相差甚远，最终导致产品进度的延迟和 资源的浪费和项目成本的增加。
VS