三方项目开发管理经验总结分享(46张)课件.pptx
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《三方项目开发管理经验总结分享(46张)课件.pptx》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 开发 管理 经验总结 分享 46 课件
- 资源描述:
-
1、方项目开发管理经验总结分享2014年12月天珑移动UED第1页,共47页。高效和快速反应的敏捷开发项目团队第2页,共47页。项目团队成员和各自职责敏捷项目开发团队的成员由软件开发人员,前段测试人员,UE设计师,UI设计师,软件项目经理(SPM),敏捷组长,技术负责人(各专业模块的小组长)所组成的一个团队。第3页,共47页。项目团队成员和各自职责 SPM管理整个团队并负责项 目的开发进度和风险的管控并主持版本级的迭代回顾会议技术负责人负责各专业组的功能的评审,任务的分解,开发时间的评估和风险的分析等。敏捷组长负责收集和反馈日常开发中影响项目进度和质量的问题给SPM,并主持召开专业级的迭代回顾会(
2、专业级包括影像组,应用组,网络组,系统UI组等)前段测试人员跟开发并行的进行各模块应用的测试第4页,共47页。第5页,共47页。在软件项目的开发过程中,有三大类计划,总体计划:主要确定项目的范围,项目完成时间。发布计划:是在总体计划的基础上,确定分阶段推出软件实现的功能。开发计划:是在发布计划的基础上,为保证如期发布功能而制定的计划。1计划的用途总体计划:一般是开发方在初步了解需求后做出的一种时间上的承诺,明确项目的范围和规定项目完成的日期,一般项目的范围使用功能表示。发布计划:是根据每个功能优先级、每个功能的可能变更程度,来确定各功能的开发顺序,分阶段制定功能的发布时间。开发计划:是针对每个
3、功能做出的开发计划,同时,通过制定开发计划也进一步对需求进行分析、确认,对技术难度进行评估。2计划的制定21发布计划在制定发布计划时,根据功能的价值和风险的优先级进行综合考量来确定功能的实现顺序,确定实现顺序后参考以前的项目或根据经验估算实现每个功能的时间,制定发布时间和发布内容。22开发计划制定开发过程中应对每个功能再细化,同时将已确定的功能集中从实现技术角度考虑划分成软件任务。在确定开发任务后与开发人员讨论完成时间,同时SPM还应考虑单元测试时间。确定的时间应与发布计划中的功能发布时间比对,如超出发布计划准许的时间,应修改开发计划。3几点注意事项(1):因最开始制定的发布计划未覆盖全部的功
4、能,所以SPM应在制定发布计划时切不可造成前线宽松后面紧张的情况,应尽量加快已明确的功能的开发速度。(2):在制定发布计划时,应使用 “需求复杂性”、”技术复杂性的系数”等方法,估算每个功能的开发时间。(3):制定的软件开发任务应尽量做到每天可以度量,以便保证计划的顺利执行。第6页,共47页。敏捷开发的核心在于迭代化开发,即采用短的迭代周期持续交付可工作的软件 迭代开发的过程 4个重要特性 对所有工作条目结合开发风险与功能重要性进行优先级排序 每个迭代都选取高优先级功能进行开发风险风险-价值价值驱动开发驱动开发 将整个开发过程拆分为多迭代周期 每个迭代都要交付可以被用户使用、能给用户带来价值的
5、产品迭代化开发迭代化开发 每天将最新功能集成到产品中 开展并行测试,在开发的最早期发现并解决产品中的缺陷持续集成持续集成与并行测试与并行测试 主张用户能够全程参与到整个开发过程中 对需求变化和用户反馈进行动态管理并及时集成到产品中持续反馈持续反馈第7页,共47页。项目发布计划需求的收集,分析 和提炼并设计交互文档 用 户 需 求 评 审用户需求澄清用户需求优先级排序用户需求开发难度的评估开发团队能力评估功能开发的风险评估组织评审团,评估开发完成时间每轮迭代完成后的迭代回顾会议制定刷新迭代开发过程中项目初始阶段123456需求录入到 RTC中项目总体功能规划 每轮迭代的操作流程第8页,共47页。
6、项目启动前的发布计划和和启动后的迭代计划内容 迭代数量 迭代周期 项目交付范围 项目风险 关键任务时间结点目的 帮助团队了解当前项目状态 指导迭代计划的制定内容 当前迭代的交付范围 项目风险与迭代风险目的 指导团队成员开展日常工作 跟踪并刷新发布计划 发布计划发布计划 迭代计划迭代计划第9页,共47页。通过对需求的优先级和风险的高和低,纳入到不同时段的迭代开发中价价值值优优先先级级(PV)(PV)分类描述价值优先级必须有n公司要求的标准化功能 n能提升用户满意度,增强产品竞争力的功能需求n具有创新性的功能,提高产品买点和产品竞争力 79应该有 n市面上已经有的功能,但在交互方式和功能上有创新
7、46可以有n在项目时间允许的情况下,可被交付的功能需求 14这次不会有 n本项目暂不考虑实现的功能 0风风险险优优先先级级(PR)(PR)风险等级描述价值优先级紧急n风险发生的可能性非常高,一旦发生会对项目产生很大的影响,并且难以消解 79严重n风险发生的概率非常高,一旦发生会对项目产生较大影响,对项目进度可能造成影响 46中等n风险发生的概率一般或对项目造成的影响较弱 24低n风险发生的概率一般并不会对项目照成严重影响0、1需求优先级需求优先级=PV*10+PR第10页,共47页。单位:采用点数来计算,按照1点/1人 1天来估算说明:用户需求开发工作量点数是功能实现难度的客观 描述,是随人员
8、而变动,且随着时间改变的,用于估算工作量作为迭代化开发中当前迭代工作量的估算以及人力的安排。单位:用户需求的开发风险的范围为1-9 级,数值越大表示实现难度越大说明:风险值是根据用户需求实现的技术难度以及实现后可能出现问题的几率来决定的用户需求开发工作量的度量单位用户需求开发风险系数的度量单位用户需求开发工作量和风险系数的度量单位第11页,共47页。每轮迭代工作量的确定和任务分配 用户需求开发工作量的评估会议操作指导说明 参与人员:UE,SPM,专业组组长,敏捷组长,测试人员,UI,和35名相关模块软件工程师原则:用户需求的开发工作量的评估要充分考虑所有角色的工作量,并采用团队参与的形式进行评
9、估,提高评估的准确性 评估方法:UE澄清需求点 软件工程师将点数写在便签纸上 SPM收集工作量,若评估点数相差3点以下,则取平均值;若超过3点,则进行讨论达成一致意见用户需求任务分配会议操作指导说明 参与人员:SPM,UE,UI,专业组组长,敏捷组长,相关模块所有软件开发人员 分配方法:专业组长根据每轮迭代周期,迭代任务和需求工作量的点数来具体把各需求分配给不同的工程师,需求的UE 负责人记录对应责任人和开发完成时间并在会后 录入到RTC 系统中,方便后续需求的跟踪管理。第12页,共47页。每天简短的例行沟通 早站会例会步骤 Step1:各成员各自汇报需要什么支持,各自的迭代目标能否按时完成,
10、有什么问题和风险)备注:QT对当前状态进行预警Step2:风险问题跟进Step3:总结,指出改进项例会目的 清晰并承诺自己的工作计划了解其他成员的工作进展进而了解项目组的工作进展 根据其他成员和项目组的工作进展,以及其他团队成员支持情况,调整自身工作 寻求和给予团队成员工作配合和支持 暴露及跟踪风险和问题第13页,共47页。迭代式开发的并行测试和瀑布式开发测试参与阶段对比迭代周期迭代软件版本发布持续代码开发持续集成并行测试并行测试开发人员前段测试人员综合测试版本发布需求需求设计设计编码编码综合测试综合测试版本发布版本发布 VS第14页,共47页。缺点:所有模块开发完并集成后才释放版本给测试导致
11、大量的缺陷在项目后期被发现,质量和风险难以控制,项目进度的延迟。项目后期测试才介入,看到的往往是开发人员理解过的需求,而不是真正客户的需求,通过测试之后的产品,客户却发现不是他所想要的或UE规划的产品。优点:在整个迭代过程中与开发并行开展的测试,阻止把测试作为一个单独的活动压缩到迭代末或版本末开展,提前发现并解决问题,软件质量提前被度量。可以及时纠正软件开发的功能与UE规划的功能或客户需求保证一致,避免最后开发完了才发现与客户要求或UE规划的要求相差甚远,最终导致产品进度的延迟和资源的浪费和项目成本的增加。VS 迭代式开发模式下的并行测试 与 传统的瀑布式开发模式的测试 优缺点 对比第15页,
展开阅读全文