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

1、第三方工程开发管理阅历总结分享主讲人： 蔡小春2021年12月天珑挪动UED高效和快速反响的矫捷开发工程团队工程团队成员和各自职责矫捷工程开发团队的成员由软件开发人员，前段测试人员，UE设计师，UI设计师，软件工程经理(SPM)，矫捷组长，技术担任人(各专业模块的小组长) 所组成的一个团队。工程团队成员和各自职责 SPM管理整个团队并担任项 目的开发进度和风险的管控并主持版本级的迭代回想会议技术担任人担任各专业组的功能的评审,义务的分解，开发时间的评价和风险的分析等。矫捷组长担任搜集和反响日常开发中影响工程进度和质量的问题给SPM，并主持召开专业级的迭代回想会专业级包括影像组，运用组，网络组，

2、系统UI组等前段测试人员跟开发并行的进展各模块运用的测试在软件工程的开发过程中，有三大类方案，总体方案：主要确定工程的范围，工程完成时间。发布方案：是在总体方案的根底上，确定分阶段推出软件实现的功能。开发方案：是在发布方案的根底上，为保证如期发布功能而制定的方案。1方案的用途总体方案：普通是开发方在初步了解需求后做出的一种时间上的承诺，明确工程的范围和规定工程完成的日期，普通工程的范围运用功能表示。发布方案：是根据每个功能优先级、每个功能的能够变卦程度，来确定各功能的开发顺序，分阶段制定功能的发布时间。开发方案：是针对每个功能做出的开发方案，同时，经过制定开发方案也进一步对需求进展分析、确认，

3、对技术难度进展评价。2方案的制定21发布方案在制定发布方案时，根据功能的价值和风险的优先级进展综合考量来确定功能的实现顺序，确定实现顺序后参考以前的工程或根据阅历估算实现每个功能的时间，制定发布时间和发布内容。22开发方案制定开发过程中应对每个功能再细化，同时将已确定的功能集中从实现技术角度思索划分成软件义务。在确定开发义务后与开发人员讨论完成时间，同时SPM还应思索单元测试时间。确定的时间应与发布方案中的功能发布时间比对，如超出发布方案准许的时间，应修正开发方案。3几点本卷须知1：因最开场制定的发布方案未覆盖全部的功能，所以SPM应在制定发布方案时切不可呵斥前线宽松后面紧张的情况，应尽量加快

4、已明确的功能的开发速度。2：在制定发布方案时，应运用 “需求复杂性、技术复杂性的系数等方法，估算每个功能的开发时间。3：制定的软件开发义务应尽量做到每天可以度量，以便保证方案的顺利执行。矫捷开发的中心在于迭代化开发，即采用短的迭代周期继续交付可任务的软件 迭代开发的过程 4个重要特性 对一切任务条目结合开发风险与功能重要性进展优先级排序每个迭代都选取高优先级功能进展开发风险-价值驱动开发将整个开发过程拆分为多迭代周期每个迭代都要交付可以被用户运用、能给用户带来价值的产品迭代化开发每天将最新功能集成到产品中开展并行测试，在开发的最早期发现并处理产品中的缺陷继续集成与并行测试主张用户可以全程参与到

5、整个开发过程中对需求变化和用户反响进展动态管理并及时集成到产品中继续反响工程发布方案需求的搜集,分析 和提炼并设计交互文档 用 户 需 求 评 审用户需求廓清用户需求优先级排序用户需求开发难度的评价开发团队才干评价功能开发的风险评价组织评审团，评价开发完成时间每轮迭代完成后的迭代回想会议制定刷新迭代开发过程中工程初始阶段123456需求录入到 RTC中工程总体功能规划 每轮迭代的操作流程工程启动前的发布方案和和启动后的迭代方案内容迭代数量迭代周期工程交付范围工程风险关键义务时间结点目的协助团队了解当前工程形状指点迭代方案的制定内容当前迭代的交付范围工程风险与迭代风险目的指点团队成员开展日常任务

6、跟踪并刷新发布方案 发布方案 迭代方案 经过对需求的优先级和风险的高和低，纳入到不同时段的迭代开发中价值优先级(PV)分类描述价值优先级必须有公司要求的标准化功能 能提升用户满意度，增强产品竞争力的功能需求具有创新性的功能，提高产品买点和产品竞争力 79应该有 市面上已经有的功能，但在交互方式和功能上有创新 46可以有在项目时间允许的情况下，可被交付的功能需求 14这次不会有 本项目暂不考虑实现的功能 0风险优先级(PR)风险等级描述价值优先级紧急风险发生的可能性非常高，一旦发生会对项目产生很大的影响，并且难以消解 79严重风险发生的概率非常高，一旦发生会对项目产生较大影响，对项目进度可能造成

7、影响 46中等风险发生的概率一般或对项目造成的影响较弱 24低风险发生的概率一般并不会对项目照成严重影响0、1需求优先级=PV*10+PR单位：采用点数来计算，按照1点/1人 1天来估算阐明：用户需求开发任务量点数是功能实现难度的客观 描画，是随人员而变动，且随着时间改动的，用于估算任务量作为迭代化开发中当前迭代任务量的估算以及人力的安排。单位：用户需求的开发风险的范围为1-9 级，数值越大表示实现难度越大阐明：风险值是根据用户需务虚现的技术难度以及实现后能够出现问题的几率来决议的用户需求开发任务量的度量单位用户需求开发风险系数的度量单位用户需求开发任务量和风险系数的度量单位每轮迭代任务量确实

8、定和义务分配 用户需求开发任务量的评价会议操作指点阐明 参与人员：UE,SPM,专业组组长,矫捷组长,测试人员,UI,和35名相关模块软件工程师原那么：用户需求的开发任务量的评价要充分思索一切角色的任务量，并采用团队参与的方式进展评价，提高评价的准确性评价方法：UE廓清需求点软件工程师将点数写在便签纸上SPM搜集任务量，假设评价点数相差3点以下，那么取平均值；假设超越3点，那么进展讨论达成一致意见用户需求义务分配会议操作指点阐明 参与人员： SPM, UE,UI,专业组组长,矫捷组长, 相关模块一切软件开发人员分配方法：专业组长根据每轮迭代周期，迭代义务和需求任务量的点数来详细把各需求分配给不

9、同的工程师，需求的UE 担任人记录对应责任人和开发完成时间并在会后 录入到RTC 系统中，方便后续需求的跟踪管理。每天简短的例行沟通 早站会例会步骤Step1：各成员各自汇报需求什么支持， 各自的迭代目的能否按时完成， 有什么问题和风险 备注：QT对当前形状进展预警Step2：风险问题跟进Step3：总结，指出改良项例会目的明晰并承诺本人的任务方案了解其他成员的任务进展进而了解工程组的任务进展根据其他成员和工程组的任务进展，以及其他团队成员支持情况，调整本身任务寻求和给予团队成员任务配合和支持暴露及跟踪风险和问题 迭代式开发的并行测试和瀑布式开发测试参与阶段对比迭代周期迭代软件版本发布继续代码

10、开发继续集成并行测试开发人员前段测试人员综合测试版本发布需求设计编码综合测试版本发布 VS 缺陷：一切模块开发完并集成后才释放版本给测试导致大量的缺陷在工程后期被发现，质量和风险难以控制，工程进度的延迟。工程后期测试才介入,看到的往往是开发人员了解过的需求,而不是真正客户的需求，经过测试之后的产品，客户却发现不是他所想要的或UE规划的产品。优点：在整个迭代过程中与开发并行开展的测试，阻止把测试作为一个单独的活动紧缩到迭代末或版本末开展，提早发现并处理问题，软件质量提早被度量。可以及时纠正软件开发的功能与UE规划的功能或客户需求保证一致，防止最后开发完了才发现与客户要求或UE规划的要求相差甚远，

11、最终导致产品进度的延迟和资源的浪费和工程本钱的添加。 VS 迭代式开发方式下的并行测试 与 传统的瀑布式开发方式的测试 优缺陷 对比建立版本级和专业级迭代回想机制 迭代回想目的分析现状分析前几轮的迭代数据，为下一轮迭代方案制定提供根据控制风险识别风险，制定并跟踪执行风险消解方案继续改善分享好的阅历推而广之、提出问题警醒他人并处理问题，促进团队继续提高分析现状控制风险继续改善迭代回想会议的议题，会议内容概要参与人员（角色）职责版本级项目迭代状况分析关注项目级风险解决组间协作问题解决跨职能协作问题制定版本级团队改善计划刷新发布计划SPM组织团队开展迭代回顾UE/UI 代表总结项目UE/UI方面的迭

12、代状况测试代表总结项目测试方面的迭代状况敏捷组长总结各小组迭代状况专业级小组迭代状况分析关注小组级风险解决跨职能协作问题制定小组级团队改善计划各模块的UE/UI负责人总结小组UE/UI方面的迭代状况测试人员总结小组测试方面的迭代状况敏捷组长组织小组开展迭代回顾软件工程师总结故事实现方面的迭代状况会前预备会议议程会后执行搜集并分析迭代数据跟踪执行会议决议事项(1)分析现状(2)风险控制与问题处理(3)继续改善(4)刷新发布方案(仅版本级)迭代分析数据来源RTC会议议程1：分析现状分析现状矫捷组长汇报会前的数据分析结果，组织团队成员对数据分析结果进展讨论前端QT、UE、UI、软件工程师参与数据分析

13、结果讨论，反响问题本卷须知：数据分析讨论的时候要综合思索前几轮的情况分析未完成的需求时要分析能否由于模块间的依赖关系或者需求开发难度大所呵斥，并给出处理思绪未修复的严重BUG时不要深化讨论如何处理，会后再讨论处理方案，要关注其能否能够带来风险以及对后期任务量的影响迭代需求的完成速率相对前几轮有较大动摇时要分析动摇缘由会议议程2：风险控制与问题处理风险控制与问题处理矫捷组长检讨上轮迭代的任务完成情况，假设没有完成，将剩余任务挪动到本轮迭代组织小组成员根据迭代数据分析讨论结果，结合工程现状识别工程中能够存在的风险对于讨论出来的风险和问题，需求在RTC创建风险任务项组织小组成员反响组间、跨职能协作方

14、面的问题，并制定处理方案前端测试人员、 UE、UI、软件工程师回想前期发现的风险跟踪结果识别风险并参与风险跟踪方案的制定反响组间、跨职能协作问题，参与制定处理方案本卷须知：遗留未按方案完成的需求和问题需求给出跟踪方案，并要有处理方案、担任人、跟踪人以及时间点等要素组间、跨职能协作问题一定要知会相关人员，要有跟踪责任人检讨出来的问题和风险以及改善对策，需求作为小组长的义务录入RTC中跟进处置会议议程3：继续改善继续改善矫捷组长汇报上一轮迭代构成的决议事项的完成情况，对于未完成的需求阐明缘由和处理方案，并落实责任人组织团队成员讨论团队出现的问题，列举做的好的，做的不好的，并多问为什么组织团队成员讨

15、论问题的处理方案，制定对策和行动方案前端测试人员、 UE、UI、软件工程师提出团队做的好的和不好的，并积极思索问题的处理方案本卷须知：总结阅历教训时一定要构成决议和改善对策，继续改善方案重点要关注在工程管理与过程执行上，详细技术问题的处理不要在此讨论工程管控工具RTC 工程管理系统功能简介RTCIBM公司开发的一个集软件开发和工程管理的团队协同任务的一个工具作为新一代的软件交付协作环境，为软件开发团队提供了从需求到方案，从开发到最终交付的完好平台。它提供的功能丰富而灵敏，一个团队假设可以熟练运用RTC进展软件开发活动的支持管理，必将大大提高消费效率，减少管理和沟通协作的本钱，它强大的代码管理和

16、版本控制功能也为软件开发团队很好地处理了协作开发中繁琐而复杂的问,RTC这个强大的工具可以更好地支持软件开发团队的任务，交付更多更好的产品.RTC中主要人员角色人员角色前段测试人员独立测试团队UE/UI设计人员软件PM其他干系人产品经理测试Leader技术担任人研发人员RTC主要功能简介各专业团队人员,工程干系人的配置和管理1，组建团队区域，主要是是本组组员的添加和删除，角色配置等.详细可看下面截图的演示2.点击“管理工程后，在弹出的窗口的右边有个团队区域层次构造，找到到本人的小组，按如以下图所示的方式，添加组员小组添加输入组员称号添加并封锁保管，以外销中间件组为例，如以下图所示 3.鼠标高亮

17、到组员，高亮栏右边点击图标，即可将当前组员移出本小组，假设以下图所示 4. 假设点击图标，在弹出框，对组员进展角色定义，如以下图所示 操作完后，角色就显示在称号的右边，如以下图所示 2.工程需求管理3.整个工程团队,各专业小组和个人任务进度的管控经过操作下面各功能控件可以非常清楚的了解整个工程团队完成工程的一个进度情况下面各专业小组完成工程的一个进度情况个人任务进度的管控4. BUG,风险和交互设计图的管理RTC系统的BUG和风险管理功能跟我司的JIRA系统中管理BUG功能相类似，在此不做详细描画。但RTC 还可以管理交互设计图，这个在JIRA 系统中是不详细的，详细可以从下面用红色圆圈标注的入口进入。5. 工程报告的管理工程各度量数据报告可以非常直观的展现当前工程需求完成率，版本达成率，版本BUG总数，版本重点BUG总数等各种数据视图，详细见下面 以下图为部分度量数据视图当前我们公司只需一个JIRA 系统来管控BUG和需求，但此系统呼应速度不