三方项目开发管理经验总结分享(46张)课件.pptx

上传人(卖家):三亚风情 文档编号:3578327 上传时间:2022-09-20 格式:PPTX 页数:47 大小:21.19MB
下载 相关 举报
三方项目开发管理经验总结分享(46张)课件.pptx_第1页
第1页 / 共47页
三方项目开发管理经验总结分享(46张)课件.pptx_第2页
第2页 / 共47页
三方项目开发管理经验总结分享(46张)课件.pptx_第3页
第3页 / 共47页
三方项目开发管理经验总结分享(46张)课件.pptx_第4页
第4页 / 共47页
三方项目开发管理经验总结分享(46张)课件.pptx_第5页
第5页 / 共47页
点击查看更多>>
资源描述

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页,

12、共47页。建立版本级和专业级迭代回顾机制 迭代回顾目的分析现状分析前几轮的迭代数据,为下一轮迭代计划制定提供依据控制风险识别风险,制定并跟踪执行风险消解计划持续改善分享好的经验推而广之、提出问题警醒他人并解决问题,促进团队持续进步分析现状控制风险持续改善第16页,共47页。迭代回顾会议的议题,会议内容概要参与人员(角色)职责版本级项目迭代状况分析关注项目级风险解决组间协作问题解决跨职能协作问题制定版本级团队改善计划刷新发布计划SPM组织团队开展迭代回顾UE/UI 代表总结项目UE/UI方面的迭代状况测试代表总结项目测试方面的迭代状况敏捷组长总结各小组迭代状况专业级小组迭代状况分析关注小组级风险

13、解决跨职能协作问题制定小组级团队改善计划各模块的UE/UI负责人总结小组UE/UI方面的迭代状况测试人员总结小组测试方面的迭代状况敏捷组长组织小组开展迭代回顾软件工程师总结故事实现方面的迭代状况会前准备会前准备会议议程会议议程会后执行会后执行收集并分析迭代数据跟踪执行会议决议事项(1)分析现状(2)风险控制与问题解决(3)持续改善(4)刷新发布计划(仅版本级)第17页,共47页。迭代分析数据来源(RTC)第18页,共47页。会议议程1:分析现状分析现状敏捷组长汇报会前的数据分析结果,组织团队成员对数据分析结果进行讨论前端QT、UE、UI、软件工程师参与数据分析结果讨论,反馈问题!注意事项:注意

14、事项:1.数据分析讨论的时候要综合考虑前几轮的情况2.分析未完成的需求时要分析是否因为模块间的依赖关系或者需求开发难度大所造成,并给出解决思路3.未修复的严重BUG时不要深入讨论如何解决,会后再讨论解决方案,要关注其是否可能带来风险以及对后期工作量的影响4.迭代需求的完成速率相对前几轮有较大波动时要分析波动原因第19页,共47页。会议议程2:风险控制与问题解决风险控制与问题解决敏捷组长检讨上轮迭代的工作完成情况,如果没有完成,将剩余工作移动到本轮迭代组织小组成员根据迭代数据分析讨论结果,结合项目现状识别项目中可能存在的风险对于讨论出来的风险和问题,需要在RTC创建风险工作项组织小组成员反馈组间

15、、跨职能协作方面的问题,并制定解决方案前端测试人员、UE、UI、软件工程师回顾前期发现的风险跟踪结果识别风险并参与风险跟踪计划的制定反馈组间、跨职能协作问题,参与制定解决方案!注意事项:1.遗留未按计划完成的需求和问题需要给出跟踪计划,并要有解决方案、负责人、跟踪人以及时间点等要素2.组间、跨职能协作问题一定要知会相关人员,要有跟踪责任人3.检讨出来的问题和风险以及改善对策,需要作为小组长的任务录入RTC中跟进处理第20页,共47页。会议议程3:持续改善持续改善敏捷组长汇报上一轮迭代形成的决议事项的完成情况,对于未完成的需要说明原因和解决方案,并落实责任人组织团队成员讨论团队出现的问题,列举做

16、的好的,做的不好的,并多问为什么组织团队成员讨论问题的解决方案,制定对策和行动计划前端测试人员、UE、UI、软件工程师提出团队做的好的和不好的,并积极思考问题的解决方案!注意事项:1.总结经验教训时一定要形成决议和改善对策,2.持续改善方案重点要关注在项目管理与过程执行上,具体技术问题的解决不要在此讨论第21页,共47页。项目管控工具第22页,共47页。RTC 项目管理系统功能简介RTC(IBM公司开发的一个集软件开发和项目管理的团队协同工作的一个工具)作为新一代的软件交付协作环境,为软件开发团队提供了从需求到计划,从开发到最终交付的完整平台。它提供的功能丰富而灵活,一个团队如果能够熟练运用R

17、TC进行软件开发活动的支持管理,必将大大提高生产效率,减少管理和沟通协作的成本,它强大的代码管理和版本控制功能也为软件开发团队很好地解决了协作开发中繁琐而复杂的问,RTC这个强大的工具能够更好地支持软件开发团队的工作,交付更多更好的产品.第23页,共47页。RTC中主要人员角色人员角色前段测试人员独立测试团队UE/UI设计人员软件PM其他干系人产品经理测试Leader技术负责人研发人员第24页,共47页。RTC主要功能简介第25页,共47页。各专业团队人员,项目干系人的配置和管理1,组建团队区域,主要是是本组组员的添加和删除,角色配置等.具体可看下面截图的演示第26页,共47页。2.点击“管理

18、项目”后,在弹出的窗口的右边有个团队区域层次结构,找到到自己的小组,按如下图所示的方式,添加组员(小组添加输入组员名称添加并关闭保存),以外销中间件组为例,如下图所示 第27页,共47页。3.鼠标高亮到组员,高亮栏右边点击图标,即可将当前组员移出本小组,如果下图所示 第28页,共47页。4.如果点击图标,在弹出框,对组员进行角色定义,如下图所示 第29页,共47页。操作完后,角色就显示在名称的右边,如下图所示 第30页,共47页。2.项目需求管理第31页,共47页。3.整个项目团队,各专业小组和个人工作进度的管控通过操作下面各功能控件可以非常清楚的了解整个项目团队完成项目的一个进度情况第32页

19、,共47页。第33页,共47页。下面各专业小组完成项目的一个进度情况第34页,共47页。个人工作进度的管控第35页,共47页。4.BUG,风险和交互设计图的管理RTC系统的BUG和风险管理功能跟我司的JIRA系统中管理BUG功能相类似,在此不做详细描述。但RTC 还可以管理交互设计图,这个在JIRA 系统中是不具体的,具体可以从下面用红色圆圈标注的入口进入。第36页,共47页。5.项目报告的管理项目各度量数据报告可以非常直观的展现当前项目需求完成率,版本达成率,版本BUG总数,版本重点BUG总数等各种数据视图,具体见下面第37页,共47页。下图为部分度量数据视图第38页,共47页。当前我们公司

20、只有一个JIRA 系统来管控BUG和需求,但此系统响应速度不够快,而且功能重点侧重为BUG的管理,满足不了我司当前对各种项目(MyOS,ODM 项目)和BUG管理的要求。随着公司的壮大,工作效率必须重视,有必要引入一个功能比较完善的项目进度和质量管控的系统。公司的JIRA系统简介第39页,共47页。JIRA中主要人员角色人员角色各测试团队软件PM研发人员第40页,共47页。JIRA主要功能简介JIRA主要功能是BUG管理,所以需求也是当成BUG来管理,所以对整个项目的进度和质量管控的功能相对来说就很少薄弱,上面提到的RTC 系统,是涉及到一个项目的各个方面,包括BUG和风险的管理,应该大家对J

21、IRA比较了解,所以简单的介绍一下第41页,共47页。第42页,共47页。第43页,共47页。第44页,共47页。Thank You!第45页,共47页。第46页,共47页。激励学生学习的名言格言激励学生学习的名言格言220、每一个成功者都有一个开始。勇于开始,才能找到成功的路。221、世界会向那些有目标和远见的人让路(冯两努香港著名推销商)222、绊脚石乃是进身之阶。223、销售世界上第一号的产品不是汽车,而是自己。在你成功地把自己推销给别人之前,你必须百分之百的把自己推销给自己。224、即使爬到最高的山上,一次也只能脚踏实地地迈一步。225、积极思考造成积极人生,消极思考造成消极人生。22

22、6、人之所以有一张嘴,而有两只耳朵,原因是听的要比说的多一倍。227、别想一下造出大海,必须先由小河川开始。228、有事者,事竟成;破釜沉舟,百二秦关终归楚;苦心人,天不负;卧薪尝胆,三千越甲可吞吴。229、以诚感人者,人亦诚而应。230、积极的人在每一次忧患中都看到一个机会,而消极的人则在每个机会都看到某种忧患。231、出门走好路,出口说好话,出手做好事。232、旁观者的姓名永远爬不到比赛的计分板上。233、怠惰是贫穷的制造厂。234、莫找借口失败,只找理由成功。(不为失败找理由,要为成功找方法)235、如果我们想要更多的玫瑰花,就必须种植更多的玫瑰树。236、伟人之所以伟大,是因为他与别人

23、共处逆境时,别人失去了信心,他却下决心实现自己的目标。237、世上没有绝望的处境,只有对处境绝望的人。238、回避现实的人,未来将更不理想。239、当你感到悲哀痛苦时,最好是去学些什么东西。学习会使你永远立于不败之地。240、伟人所达到并保持着的高处,并不是一飞就到的,而是他们在同伴们都睡着的时候,一步步艰辛地向上爬241、世界上那些最容易的事情中,拖延时间最不费力。242、坚韧是成功的一大要素,只要在门上敲得够久、够大声,终会把人唤醒的。243、人之所以能,是相信能。244、没有口水与汗水,就没有成功的泪水。245、一个有信念者所开发出的力量,大于99个只有兴趣者。246、环境不会改变,解决之道在于改变自己。247、两粒种子,一片森林。248、每一发奋努力的背后,必有加倍的赏赐。249、如果你希望成功,以恒心为良友,以经验为参谋,以小心为兄弟,以希望为哨兵。250、大多数人想要改造这个世界,但却罕有人想改造自己。第47页,共47页。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 办公、行业 > 各类PPT课件(模板)
版权提示 | 免责声明

1,本文(三方项目开发管理经验总结分享(46张)课件.pptx)为本站会员(三亚风情)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!


侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|