您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 项目/工程管理 > 第三方项目开发管理经验总结分享
第三方项目开发管理经验总结分享主讲人:蔡小春2014年12月天珑移动UED高效和快速反应的敏捷开发项目团队项目团队成员和各自职责敏捷项目开发团队的成员由软件开发人员,前段测试人员,UE设计师,UI设计师,软件项目经理(SPM),敏捷组长,技术负责人(各专业模块的小组长)所组成的一个团队。项目团队成员和各自职责UE负责交互的设计,编写用户故事和功能的验收条件,并验收需求点的完成情况UI负责图片和动画的输出,并验证视觉效果软件开发人员负责各功能模块的开发SPM管理整个团队并负责项目的开发进度和风险的管控并主持版本级的迭代回顾会议技术负责人负责各专业组的功能的评审,任务的分解,开发时间的评估和风险的分析等。敏捷组长负责收集和反馈日常开发中影响项目进度和质量的问题给SPM,并主持召开专业级的迭代回顾会(专业级包括影像组,应用组,网络组,系统UI组等)前段测试人员跟开发并行的进行各模块应用的测试在软件项目的开发过程中,有三大类计划,总体计划:主要确定项目的范围,项目完成时间。发布计划:是在总体计划的基础上,确定分阶段推出软件实现的功能。开发计划:是在发布计划的基础上,为保证如期发布功能而制定的计划。1.计划的用途总体计划:一般是开发方在初步了解需求后做出的一种时间上的承诺,明确项目的范围和规定项目完成的日期,一般项目的范围使用功能表示。发布计划:是根据每个功能优先级、每个功能的可能变更程度,来确定各功能的开发顺序,分阶段制定功能的发布时间。开发计划:是针对每个功能做出的开发计划,同时,通过制定开发计划也进一步对需求进行分析、确认,对技术难度进行评估。2.计划的制定2.1发布计划在制定发布计划时,根据功能的价值和风险的优先级进行综合考量来确定功能的实现顺序,确定实现顺序后参考以前的项目或根据经验估算实现每个功能的时间,制定发布时间和发布内容。2.2开发计划制定开发过程中应对每个功能再细化,同时将已确定的功能集中从实现技术角度考虑划分成软件任务。在确定开发任务后与开发人员讨论完成时间,同时SPM还应考虑单元测试时间。确定的时间应与发布计划中的功能发布时间比对,如超出发布计划准许的时间,应修改开发计划。3.几点注意事项(1):因最开始制定的发布计划未覆盖全部的功能,所以SPM应在制定发布计划时切不可造成前线宽松后面紧张的情况,应尽量加快已明确的功能的开发速度。(2):在制定发布计划时,应使用“需求复杂性”、”技术复杂性的系数”等方法,估算每个功能的开发时间。(3):制定的软件开发任务应尽量做到每天可以度量,以便保证计划的顺利执行。敏捷开发的核心在于迭代化开发,即采用短的迭代周期持续交付可工作的软件迭代开发的过程4个重要特性▪对所有工作条目结合开发风险与功能重要性进行优先级排序▪每个迭代都选取高优先级功能进行开发风险-价值驱动开发▪将整个开发过程拆分为多迭代周期▪每个迭代都要交付可以被用户使用、能给用户带来价值的产品迭代化开发▪每天将最新功能集成到产品中▪开展并行测试,在开发的最早期发现并解决产品中的缺陷持续集成与并行测试▪主张用户能够全程参与到整个开发过程中▪对需求变化和用户反馈进行动态管理并及时集成到产品中持续反馈项目发布计划需求的收集,分析和提炼并设计交互文档用户需求评审用户需求澄清用户需求优先级排序用户需求开发难度的评估开发团队能力评估功能开发的风险评估组织评审团,评估开发完成时间每轮迭代完成后的迭代回顾会议制定刷新迭代开发过程中项目初始阶段123456需求录入到RTC中项目总体功能规划每轮迭代的操作流程项目启动前的发布计划和和启动后的迭代计划内容▪迭代数量▪迭代周期▪项目交付范围▪项目风险▪关键任务时间结点目的▪帮助团队了解当前项目状态▪指导迭代计划的制定内容▪当前迭代的交付范围▪项目风险与迭代风险目的▪指导团队成员开展日常工作▪跟踪并刷新发布计划发布计划迭代计划通过对需求的优先级和风险的高和低,纳入到不同时段的迭代开发中价值优先级(PV)分类描述价值优先级必须有公司要求的标准化功能能提升用户满意度,增强产品竞争力的功能需求具有创新性的功能,提高产品买点和产品竞争力7~9应该有市面上已经有的功能,但在交互方式和功能上有创新4~6可以有在项目时间允许的情况下,可被交付的功能需求1~4这次不会有本项目暂不考虑实现的功能0风险优先级(PR)风险等级描述价值优先级紧急风险发生的可能性非常高,一旦发生会对项目产生很大的影响,并且难以消解7~9严重风险发生的概率非常高,一旦发生会对项目产生较大影响,对项目进度可能造成影响4~6中等风险发生的概率一般或对项目造成的影响较弱2~4低风险发生的概率一般并不会对项目照成严重影响0、1需求优先级=PV*10+PR单位:采用点数来计算,按照1点/1人1天来估算说明:用户需求开发工作量点数是功能实现难度的客观描述,是随人员而变动,且随着时间改变的,用于估算工作量作为迭代化开发中当前迭代工作量的估算以及人力的安排。单位:用户需求的开发风险的范围为1-9级,数值越大表示实现难度越大说明:风险值是根据用户需求实现的技术难度以及实现后可能出现问题的几率来决定的用户需求开发工作量的度量单位用户需求开发风险系数的度量单位用户需求开发工作量和风险系数的度量单位每轮迭代工作量的确定和任务分配用户需求开发工作量的评估会议操作指导说明参与人员:−UE,SPM,专业组组长,敏捷组长,测试人员,UI,和3~5名相关模块软件工程师−原则:−用户需求的开发工作量的评估要充分考虑所有角色的工作量,并采用团队参与的形式进行评估,提高评估的准确性−评估方法:−UE澄清需求点−软件工程师将点数写在便签纸上−SPM收集工作量,若评估点数相差3点以下,则取平均值;若超过3点,则进行讨论达成一致意见用户需求任务分配会议操作指导说明参与人员:SPM,UE,UI,专业组组长,敏捷组长,相关模块所有软件开发人员−分配方法:−专业组长根据每轮迭代周期,迭代任务和需求工作量的点数来具体把各需求分配给不同的工程师,需求的UE负责人记录对应责任人和开发完成时间并在会后录入到RTC系统中,方便后续需求的跟踪管理。每天简短的例行沟通早站会例会步骤▪Step1:各成员各自汇报需要什么支持,各自的迭代目标能否按时完成,有什么问题和风险)备注:QT对当前状态进行预警▪Step2:风险问题跟进▪Step3:总结,指出改进项例会目的▪清晰并承诺自己的工作计划▪了解其他成员的工作进展进而了解项目组的工作进展▪根据其他成员和项目组的工作进展,以及其他团队成员支持情况,调整自身工作▪寻求和给予团队成员工作配合和支持▪暴露及跟踪风险和问题迭代式开发的并行测试和瀑布式开发测试参与阶段对比迭代周期迭代软件版本发布持续代码开发持续集成并行测试开发人员前段测试人员综合测试版本发布需求设计编码综合测试版本发布VS缺点:▪所有模块开发完并集成后才释放版本给测试导致大量的缺陷在项目后期被发现,质量和风险难以控制,项目进度的延迟。▪项目后期测试才介入,看到的往往是开发人员理解过的需求,而不是真正客户的需求,通过测试之后的产品,客户却发现不是他所想要的或UE规划的产品。优点:▪在整个迭代过程中与开发并行开展的测试,阻止把测试作为一个单独的活动压缩到迭代末或版本末开展,提前发现并解决问题,软件质量提前被度量。▪可以及时纠正软件开发的功能与UE规划的功能或客户需求保证一致,避免最后开发完了才发现与客户要求或UE规划的要求相差甚远,最终导致产品进度的延迟和资源的浪费和项目成本的增加。VS迭代式开发模式下的并行测试与传统的瀑布式开发模式的测试优缺点对比建立版本级和专业级迭代回顾机制迭代回顾目的分析现状分析前几轮的迭代数据,为下一轮迭代计划制定提供依据控制风险识别风险,制定并跟踪执行风险消解计划持续改善分享好的经验推而广之、提出问题警醒他人并解决问题,促进团队持续进步分析现状迭代回顾会议的议题,会议内容概要参与人员(角色)职责版本级项目迭代状况分析关注项目级风险解决组间协作问题解决跨职能协作问题制定版本级团队改善计划刷新发布计划SPM组织团队开展迭代回顾UE/UI代表总结项目UE/UI方面的迭代状况测试代表总结项目测试方面的迭代状况敏捷组长总结各小组迭代状况专业级小组迭代状况分析关注小组级风险解决跨职能协作问题制定小组级团队改善计划各模块的UE/UI负责人总结小组UE/UI方面的迭代状况测试人员总结小组测试方面的迭代状况敏捷组长组织小组开展迭代回顾软件工程师总结故事实现方面的迭代状况会前准备会议议程会后执行收集并分析迭代数据跟踪执行会议决议事项(1)分析现状(2)风险控制与问题解决(3)持续改善(4)刷新发布计划(仅版本级)迭代分析数据来源(RTC)会议议程1:分析现状分析现状敏捷组长▪汇报会前的数据分析结果,组织团队成员对数据分析结果进行讨论前端QT、UE、UI、软件工程师▪参与数据分析结果讨论,反馈问题!注意事项:1.数据分析讨论的时候要综合考虑前几轮的情况2.分析未完成的需求时要分析是否因为模块间的依赖关系或者需求开发难度大所造成,并给出解决思路3.未修复的严重BUG时不要深入讨论如何解决,会后再讨论解决方案,要关注其是否可能带来风险以及对后期工作量的影响4.迭代需求的完成速率相对前几轮有较大波动时要分析波动原因会议议程2:风险控制与问题解决风险控制与问题解决敏捷组长▪检讨上轮迭代的工作完成情况,如果没有完成,将剩余工作移动到本轮迭代▪组织小组成员根据迭代数据分析讨论结果,结合项目现状识别项目中可能存在的风险▪对于讨论出来的风险和问题,需要在RTC创建风险工作项▪组织小组成员反馈组间、跨职能协作方面的问题,并制定解决方案前端测试人员、UE、UI、软件工程师▪回顾前期发现的风险跟踪结果▪识别风险并参与风险跟踪计划的制定▪反馈组间、跨职能协作问题,参与制定解决方案!注意事项:1.遗留未按计划完成的需求和问题需要给出跟踪计划,并要有解决方案、负责人、跟踪人以及时间点等要素2.组间、跨职能协作问题一定要知会相关人员,要有跟踪责任人3.检讨出来的问题和风险以及改善对策,需要作为小组长的任务录入RTC中跟进处理会议议程3:持续改善持续改善敏捷组长▪汇报上一轮迭代形成的决议事项的完成情况,对于未完成的需要说明原因和解决方案,并落实责任人▪组织团队成员讨论团队出现的问题,列举做的好的,做的不好的,并多问为什么▪组织团队成员讨论问题的解决方案,制定对策和行动计划前端测试人员、UE、UI、软件工程师▪提出团队做的好的和不好的,并积极思考问题的解决方案!注意事项:1.总结经验教训时一定要形成决议和改善对策,2.持续改善方案重点要关注在项目管理与过程执行上,具体技术问题的解决不要在此讨论项目管控工具RTC项目管理系统功能简介RTC(IBM公司开发的一个集软件开发和项目管理的团队协同工作的一个工具)作为新一代的软件交付协作环境,为软件开发团队提供了从需求到计划,从开发到最终交付的完整平台。它提供的功能丰富而灵活,一个团队如果能够熟练运用RTC进行软件开发活动的支持管理,必将大大提高生产效率,减少管理和沟通协作的成本,它强大的代码管理和版本控制功能也为软件开发团队很好地解决了协作开发中繁琐而复杂的问,RTC这个强大的工具能够更好地支持软件开发团队的工作,交付更多更好的产品.RTC中主要人员角色人员角色前段测试人员独立测试团队UE/UI设计人员软件PM其他干系人产品经理测试Leader技术负责人研发人员主要功能各专业团队人员,项目干系人的配置和管理项目需求管理整个项目团队,各专业小组和个人工作进度的管控BUG和风险的跟踪管理交互设计图的管理项目报告的管理RTC主要功能简介各专业团队人员,项目干系人的配置和管理1,组建团队区域,主要是是本组组员的添加和删除,角色配置等.具体可看下面截图的演示2.点击“管理项目”后,在弹出的窗口的右边有个团队区域层次结构,找到到自己的小组,按如下图所示的方式,添加组员(小组—添加输入组员名称添加并关闭保存),以外销中间件组为例,如下图所示3.鼠标高亮到组员,高亮栏右
本文标题:第三方项目开发管理经验总结分享
链接地址:https://www.777doc.com/doc-782051 .html