浅谈敏捷项目管理ppt课件

浅谈敏捷项目管理,目录,软件开发的七个基本定律,软件项目管理的七个基本原则敏捷开发的基本概念为什么用敏捷敏捷的基础知识总结,软件开发的七个基本定律,1:10:100定律,1我们有哪些措施预防需求的错误？2我们有哪些措施发现需求的错误？3我们的质量成本是如何分布的？,反思,需求错误导致的成本是修复程序错误成本的100倍,改进质量的途径-尽早消除缺陷,需求,设计,编码,单元测试,系统测试,集成测试,交付使用,缺陷数,在总体注入缺陷相同的情况下，尽早地消除缺陷可以使交付产品的质量大大提高,1:2定律,在开发中，每花费1美元，在维护中就得花费2美元，因此要注意度量改进维护的度量元,1在我们公司的项目中维护成本与开发成本的比例是多少？2我们在需求开发、设计过程中为了降低维护的成本采取了哪些措施？,反思,Weinberg可靠性零定律,如果一个系统不要求是可靠的，那么它能够满足任何的其他目的换句话说，如果对实际工作的程序没有要求，那么你能满足任何设置的编程交付期,在限定了资源，而项目工期又比较紧张时，我们通常牺牲了什么？我们是否真的加快了进度呢？,反思,1:3:9定律,随着软件系统规模的增大，其成本成倍增长，呈现1:3:9的关系，称之为软件产业的非规模经济现象,1我们如何降低软件的开发成本？2为什么提倡采用迭代的生命周期模型？3为什么提倡小项目、小团队？,反思,帕金森定律（ParkinsonsLaw）,工作总是用完所有可利用的时间（Workexpandstofillthetimeavailable）如果你给自己安排了充裕的时间从事一项工作，你会放慢你的节奏以便用掉所有分配的时间容易达到的目标将使员工工作上变得松懈,1如何规避帕金森定律？2如果整个项目有20%的缓冲时间，你会如何分配这,反,思,20%的缓冲？,布鲁克斯定律（BrooksLaw）,人月=人*月，但是：月人月/人投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟BarryBohem：可以将软件开发进度压缩25%，但是不能再多了200/20/6X现象：人数增加1倍，工期缩短20%，缺陷增加6倍,1在实践中，我们是否经常通过给项目组增加人手的方式加快进度？,反,思,2有哪些合理的加快进度的措施？,80-20定律,Boehm提出的有关软件项目管理的“二八定理”，构成了现代软件管理过程框架的理论基础80%的缺陷是由20%的构件引起的80%的软件废品和返工是由20%的缺陷引起的80%的资源是由20%的构件消耗的80%的工程活动是通过20%的工具完成的80%的进展是20%的人完成的,在实践中我们应该如何运用80-20定律？,反思,软件项目管理的七个基本原则,原则一:四要素的平衡原则,原则二:高效原则,要选择精英成员目标要明确，范围要清楚沟通要及时、充分要在激励成员上下工夫要有充分的技术复用,原则三:分解原则,化繁为简，各个击破,大项目组分成几个小项目组长周期分解为几个阶段定义生命周期模型进行WBS分解版本化发布,原则四:实时控制原则,逐日跟踪,PM检查过了?是否自检过了?是否测试过了?是否纳入CM库了?每日联调,原则五:分类管理,根据项目的特点，制订不同的项目管理的方针政策,对于不同的软件项目其项目目标差别很大，项目规模也是不同的，应用领域是不同的，采用的技术路线差别也很大，因而，针对每个项目的不同特点，其管理的方法、管理的侧重点应该是不同的。,原则六:简单有效,简单就是美每一个活动是否都有价值?每一个文档是否都有价值?每一个度量数据是否有价值?是否有更简单有效的管理方法?,原则七:选择称职的项目经理,要公正无私要有良好的职业道德要具有管理的基本技能与知识要具有很好的沟通与表达能力要有很强的分析问题解决问题的能力要懂技术，不要求精通，但是要全面要谦虚，不能不懂装懂要平易进人，不要摆架子,敏捷开发的基本概念,理解敏捷,敏捷开发是“一种以人为核心、迭代、循序渐进的开发方法!”,在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。,理解敏捷,敏捷开发核心价值观是什么呢？,答案是：沟通，简单，反馈，勇气,理解敏捷,敏捷开发的核心思想是：以人为本，适应变化。,敏捷宣言,谁在用敏捷,为什么用敏捷,传统瀑布型开发模式风险,用户只有等到开发后期才能看到结果,早期的错误要等到后期测试才能发现,敏捷更符合软件开发规律,软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品,传统开发,敏捷开发,敏捷能不能提高“开发效率”？,敏捷开发中更加强调沟通，沟通成本会增加,敏捷开发对人员的要求更高，学习成本会增加,快速的迭代使重构工作量增加,信息的透明性要求较多的数据收集，使成本增加,敏捷开发不是用来解决所谓的“开发效率”问题的，如果真是开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏捷反而会降低所谓的效率。因为这里的“效率”被理解为相同的人，在更短的时间内开发完成既定的功能，或者在相同的时间内能够开发更多的功能。原因如下：,正确认识敏捷开发的目的,敏捷开发是解决什么问题的呢？它是解决企业效益（ROI，投资回报率）最大化的问题，评价敏捷开发的成功与否要从转型后企业效益的整体提升情况评价，而不能单单从主观判断上看开发人员完成的功能数量与速度来评价，敏捷开发主要从以下方面来帮助企业提升整体效益：拥抱变化快速响应,快速将功能推向市场变现,在有限的资源条件下，做最值得做的事,拥抱变化,唯一不变的就是变化长期的计划很难制定得可行“人月神话”只是个神话，需求的变化不可避免“人”本身就是变化的因素,快速响应,市场环境的变化需产品服务及时响应传统方式变化的成本奇高,当前市场环境要求能在成本可控范围内，产品和服务能及时响应市场多变的需求,快速将功能推向市场变现,成为第一，胜过做得最好敏捷真正的价值在于能快速交付，赢得市场契机,在有限的资源条件下，做最值得做的事,因为Backlog的每一项都具有按唯一优先级顺序,ROI是评价需求优先级的唯一指标,敏捷的基础知识,敏捷开发流程,Scrum要素,Scrum的角色,Scrum角色分类-各种“猪”,ProductOwner传递来自市场的声音、提升项目的回报确定产品Backlog中的优先级从产品的角度确保团队工作方向ScrumMaster管理Scrum流程，确保Scrum运转确保每个Sprint目标的实现与产出，不受外界干扰团队由5-9人组成（开发，测试等）、评估每个Sprint工作,Scrum角色职责,非Scrum角色-“鸡”,利益相关者（客户，供应商）产品使用者、项目相关者仅在Sprint回顾展示中参加会议经理设置环境的产品开发组织管理层公司管理层（比如总裁办公室等）垂直职能经理层（比如开发经理等）,Scrum物件,ProductBacklog所有需要完成的产品清单，包括优先级、商业诉求，PO负责SprintBacklog由团队主动选择完成的每个Sprint需要完成的Story列表每个Story包括了需求、优先级、工作量一旦确定，不亦更改SprintBurndown显示工作量趋势变化的图表每天由ScrumMaster更新,Scrum物件-productbacklog,ID一个唯一的标示名称简单描述重要性相对值(10和11没有区别)故事点相对值(10点的工作量是5点的两倍)也可以用人天来估算完成定义如何演示性能指标数据备注,Scrum物件-SprintBacklog,拆分Backlog一个Item拆分成若干个Task估算故事点每个Task的故事点不超过8小时的工作量,Scrum物件-SprintBurndown,横轴时间(天)纵轴故事点更新每日站会后,Scrum看板,Scrum仪式-sprint计划会议,每个Sprint开始前召开，参加人员有PO、SM、ST和其他感兴趣的人ProductOwner按重要性从产品Backlog中挑选待加入SprintBacklog中的条目ScrumTeam将Backlog条目分解成小任务，并评估完成每个条目需要的概时间ProductOwner和ScrumTeam共同调整和决定下一个SprintBacklog,估算时间(storypoint)计划纸牌,Scrum仪式每日站立会议,最好在每天早上，时间控制在15分钟每天在同一时间、同一地点三个问题：昨天完成了什么；今天计划做什么；遇到哪些障碍ScrumMaster更新燃尽图谁都可以参加，但只允许团队成员发言，其他人只能旁听,Scrum仪式sprint评审会议,了解相关人员获得团队和项目最新进展的直接印象反馈客户或ProductOwner对阶段性成果提出反馈激励演示可以工作的软件，鼓舞团队士气原则我们交付的是可以工作的软件，而不是口头的功能完成,Scrum仪式sprint回顾会议,上个Sprint哪些地方做得好，继续保持上个Sprint哪些地方做得不好，改进措施原则：所有的回顾都“对事不对人”理解并信任每个人对自己的工作都已全力以赴团队中没有破坏者，没有替罪羊，只有整个团队的利益,Sprint三大杀手,冲刺过程中加入新需求估算不精确-对需求理解不明确-能力不足-投入度不够Defect,Scrum如何改善,结合XP（极限编程）实践-持续集成-测试驱动开发-结对编程-不断重构-代码检查,总结,误解,误解一：敏捷开发意味着可以不需要文档、设计和计划误解二：敏捷只是一些优秀实践，或者是优秀实践的结合误解三：敏捷只适用于小项目开发误解四：敏捷只会对研发产生改变误解五：管理者不需要亲自了解敏捷，只需要管理上支持就可以了误解六：引入敏捷只需要按照既定的步骤去做就可以了误解七：敏捷是CMM的替代品，是另一种流程误解八：敏捷只注重特性的快速交付，在敏捷下架构不重要了,统一认识：敏捷=理念+优秀实践+具体应用,理念,优秀实践,具体应用,理念（敏捷核心思想）敏捷包括3个层次优秀实践（敏捷的经验积累）具体应用（能够结合自身灵活应