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