软件公司 敏捷开发材料(概念普及)ppt课件.ppt
2022/11/25,软件公司 敏捷应用推行小组 2008-11,软件公司敏捷开发简介（推广普及）,Page 2,目录,敏捷引入：效率提升的需要行业敏捷引入的案例参考,Page 3,软件公司提升研发效率目标（08-09）,废弃版本比例降低20(准),研发过程效率提高15%（省）,软调基线工时降低9%,BugFix版本比例降低15,端到端交付效率提升30%,需求TTM提升20,版本维护成本降低15%,每需求耗研发工时降低5,版本交付周期缩短10%(快）,版本交付缺陷率降低5（好）,业软效率提升目标：端到端交付效率提升30%效率提升措施四维度：准、快、好、省,上图摘自软件公司研发效率提升材料 2008,Page 4,准快好省的要求和现状？,准需求交付要准确、准时现状: 交付后的需求，都多少存在不满足客户要求情况，从而导致后续不断的补丁、增量小版本的开发、发布，也从而导致交付延期，不准时。快客户需求交付快现状：07年业软需求平均交付周期143天，采用集中收集进行版本特性开发，开发测试串行的瀑布式都是需求交付周期长的原因。好交付能满足客户需求现状：版本交付后都会存在需求不满足客户要求情况，导致客户满意下降。如果能够使得交付的特性满足客户需要，则能提升客户满意度。省开发活动更有效，投入成本更低现状：是否可把传统开发活动中冗余的活动去除？比如多余的文档、多余的团队间信息传递成本？要求更有效、更精简地进行软件开发,Page 5,敏捷是什么？,敏捷 =“迅速、快捷”=“又快又好”敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法。敏捷能否帮助达成”准快好省“的效率提升目标？,Page 6,敏捷宣言,个体和交互 胜过 过程和工具关注人和项目团队内外的沟通交流，而不是简单的依赖过程和工具。可以工作的软件 胜过 面面俱到的文档没有文档和过多的文档都是不可取。对团队来说，维护一份系统原理和结构方面的文档总是必须的，但那份文档应该短小精悍，主题突出，并始终和代码保持一致。源代码是最好的软件设计文档。客户合作 胜过 合同谈判用户参与，双方沟通达成双赢响应变化 胜过 遵循计划客户需求变化，外部环境变化，因地制宜制订和调整计划，比简单的死守计划更有效。虽然右边也有效，但左边的项更有价值,Page 7,典型的敏捷方法,XP -eXtreme Programming极限编程，思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历，极限的含义是把软件开发中的有效实践都发挥到极致(Kent Beck).SCRUM：是一种迭代的增量化过程，用于产品开发或工作管理 。水晶方法Crystal:由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。 FDD特性驱动 Feature Driven Development，由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。 DSDM-Dynamic System Development Methodology，它倡导以业务为核心，快速而有效地进行系统开发， 在英国等欧洲国家比较流行。ASD-Adaptive Software Development，由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive）,Page 8,XP的13个实践,编程方法,小组实践,项目团队,XP实践洋葱图1层：面向编程方法2层：小组团队活动3层：面向项目和交付,Sustainable Pace-稳定的步伐，保持开发在一个稳定的步伐,Page 9,SCRUM的过程图,SCRUM来源于橄榄球运动，指：“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。”,Page 10,Scrum中的3、3、3,三个基本角色(Role)Product OwnerScrum Master：不是团队的经理团队成员(Scrum Team）：猪和鸡三种会议(Meeting)迭代计划会议(Sprint Planning Meeting)每日晨会(Daily Scrum Meeting)迭代回顾会议(Sprint Review Meeting)三项工件(Artifact)待开发任务列表(The Sprint Backlog)待修复缺陷列表(The defect backlog)进度图、燃尽图(Burn Down Chart),/24.,10,Page 11,软件开发的敏捷过程,分析阶段,迭代开发,1、分析通常是系统组和开发组共同进行2、最好的方式是系统组与开发在一个团队中3、推荐用User Story方式分析需求，传统方式也认可,1、按迭代进行开发2、开发、测试和资料一定是一个整体的团队3、验证时，根据实际情况让客户参与验证,Page 12,迭代内的活动,迭代计划,迭代设计,承担Task,分解Task,Pair进行测试驱动的开发,持续集成,迭代评估,划分迭代,分析需求产生Story,多个迭代,在全部完成后，类似传统的SDV测试（尤其针对自动化测试不全面的系统）,补充测试用例测试人员编写黑盒用例，开发人员编写白盒用例,Page 13,软件公司敏捷的实施,为了达到效率提升目标，有效实施”准快好省“，1、迭代的管理和跟踪方法，引入SCRUM2、迭代中如何更有效地开发，引入XP各实践3、用精益的消除浪费思想，从浪费角度出发，引入敏捷相关实践。,Page 14,精益Lean的消除浪费思想,精益思想（Lean）来自丰田汽车制造的思想，核心思想是”消除浪费“用精益的消除浪费思想来识别软件开发中的冗余活动，并寻求敏捷的方法来解决,Page 15,敏捷实施的要点,采用SCRUM和XP结合，以及精益思想的分析，敏捷有如下几个实施要点：1、迭代式的开发和管理（迭代划分，迭代计划会议、评估会议和简短的每日站立会议）2、一体化的版本开发团队（含系统、开发、测试、资料等，系统分析人员充当需求Product Owner角色，带领分析出分级的User Story）3、简化的文档交付件（一份根据原始需求分析分解的User Story，一份系统整体架构描述文档，User Story是做什么的、测什么、资料写什么的主线）4、持续集成系统，及时构建完成的User Story，从而验证其正确性。,Page 16,敏捷实践同效率提升“准快好省”的分析,Page 17,敏捷的一些常见疑问,敏捷就是XP（极限编程）通过前面的介绍，应该可以回答这个问题了吧。迭代就是敏捷？迭代是敏捷的过程模型，XP是短周期迭代，SCRUM是严格为30天的迭代。但使用迭代模型的还有其他很多方法论，比如RUP/MSF/EVO。敏捷是反文档的？敏捷并不是走极端，在敏捷项目里面，也需要一些必要的文档。虽然敏捷中也有人提到“代码就是最好的设计文档”，但仅仅在软件的设计上，比如敏捷的系统隐喻，就是对架构文档的要求；User Story的记录，就是对需求类文档的要求。敏捷是自由无约束的？不管采用哪种敏捷，需要遵循必须的活动和要求，并不是自由散漫的。敏捷是CMM(I)的反义词？敏捷同CMM的关系，业界已经有很多人进行过分析，采用敏捷也可满足CMM2、3级的多数KPA要求。CMM更多是一种成熟度模型。为了敏捷而敏捷？为什么会采用比传统不同的敏捷，最重要的是要能够提升软件开发效率。系统、测试和资料如何参与敏捷项目？在分析UserStory的时侯，系统分析人员组织分析需求，制定出Story; 测试人员和资料人员同开发一起承担User Story的制作工作；然后每次迭代时，测试人员根据Story准备测试用例，资料人员根据Story写作操作手册。,Page 18,敏捷开发同公司流程的对应,IPD是投资决策流程，面向业务管理；敏捷是软件开发的使能流程，面向软件实现。软件公司各增强特性版本的开发，概念上同IPD可进行对应。比如迭代结束点，就对应TR5的点。,IPD,Concept,Plan,Development,Launch,Qualify,Lifecycle,CDCP,PDCP,ADCP,Sprint1,Sprint2,Sprint.,Sprint X,TR1,TR5,Agile Project,敏捷开发,Page 19,目录,敏捷引入：效率提升的需要行业敏捷引入的案例参考,Page 20,行业参考-爱立信多媒体部敏捷转型,爱立信为什么转型敏捷？爱立信05年目标：在4年时间内，将产品从研发到市场的时间(TTM)缩短50。为了实现这个目标，爱立信引入了“streamline”概念，“time boxing”，平均的time-box变成大约3个月，而不是以往的6至12个月 。Streamline的引入，引入敏捷也成为很自然的事情。结果达成（2007年底）减少浪费：在项目期间，需求平均删减率从25降到9。缩短产品从开发到市场的时间：平均TTM降到2005年平均TTM的大约50。减少产品20的维护成本，降低产品遗留缺陷。注:本参考案例描述爱立信多媒体部的敏捷引入经验。多媒体部，面向手机、互连网、多媒体市场，同业软多项产品有直接竞争关系。,Page 21,行业参考-爱立信多媒体部敏捷转型,如何转型敏捷？（组织级)两种顾问角色，一个敏捷顾问做了一天的培训，并且在一天内协助团队制定了包括计划的开工会；另一个敏捷顾问，作为敏捷指导员，长时间(超过一年)地参与敏捷实践的引入过程。包括：制定计划、每天的站立会议、跨功能团队、测试驱动开发和结对开发、短开发周期(2到3周) 、给“客户”演示以及不断地回顾、总结经验和改进。敏捷引入团队的组成一个“owner”，一个PDU管理团队成员。这个“owner”作为产品责任人，为引入团队收集和编写“user story”。引入团队包括一个change driver，一般由具有scrum管理资格和PMI项目管理资格的人员担任，还包括一个敏捷顾问和一个引导项目各阶段的项目经理。个体和部门有一个本地的(内部)指导员引导实施过程，通常自愿担任，敏捷顾问负责培训本地指导员。PDU管理团队成员是主要的stakeholders(利益主体)。,Page 22,行业参考-爱立信多媒体部敏捷转型,如何转型敏捷？（项目级)multi-disciplinary(多种规则)团队，部门之间的界限被打破。Multi-disciplinary团队由多个软件设计人员、功能测试人员以及集成验证工程师组成，从项目启动开始，他们就共同工作。团队指导员：是主要的接口人，外部stakeholders(类似产品负责人和架构师)将与团队一起工作而不是一个代表。团队指导员是一个新角色，一般由团队内部人员担任。产品负责人代表客户，他实际上也是产品经理。当然，总会存在阻力。例如：测试人员要承担一些通常由开发人员负责的工作。刚开始，团队成员有点害怕提供评估报告，有些人害怕无法及时完成“user stories”以及事后被评价。经验、能力和逐步改善的相互信任，会让这些恐惧慢慢消失。,Page 23,行业参考-爱立信多媒体部敏捷转型,结果如何？（组织级)客户满意度上升客户关系仍旧遵从传统形式的合同，所以项目经理仍会对客户满意度负责；团队能更好地交付，而且动力得到加强 遇到的阻碍在整个过程中，遇到阻碍显而易见。大多数的阻碍是以前被忽视的老问题。解决阻碍是好的，但是需要不断改进。超越团队范围之外，能真正解决这些阻碍的方案，仍然面临预算、责任主体以及如何管理增长的老问题。 质量结果遗留缺陷(FST)是一项度量指标，它能度量软件发布后的缺陷 ；敏捷项目中新增代码遗留缺陷在增长，但是相比普通项目，却能识别更多的“设计方面的缺陷” 。,Page 24,行业参考-爱立信多媒体部敏捷转型,结果如何？（组织级 续上页）单个需求时间敏捷项目中，平均成本在多个迭代之后呈下降趋势员工动力初始的引入过程是自上而下，而执行是自下而上 ；2007年5月，团队中71的人有责任感和主动性，这个数字到了2007年10月上升到81。,Page 25,行业参考-爱立信多媒体部敏捷转型,经验一夜引入，长时间改变在一个项目层次上，可以毫无障碍地在一夜之间开始敏捷过程 ；敏捷实践更多适用于“time boxing”而不是“scope boxing” ，所以改变的焦点集中在缩短迭代周期以及“人们/组织”的工作方式上。 跨越价值流，聚焦于持续学习。对于大规模组织而言，单一的方法是不存在的。团队可以使用Scrum或XP方法，但是要获得真正的客户融合、使服务团队和发布团队以同样的合作方式协调工作，仍然需要做更多的工作。首先，持续改进客户需求到客户发布的完整价值链，然后，运用敏捷方法，软件开发团队将获得不断增长的效益。,行业参考：Siemens的敏捷实施,行业参考：Siemens敏捷和产品开发的结合,Page 28,附：参考材料,参考书籍scrum_primer_1_04_cn_SCRUM 简介Extreme Programming Exploredagile project management creating innovative products敏捷开发的必要技巧内部参考材料软件公司 敏捷开发介绍（介绍）.ppt软件公司 敏捷开发介绍（应用）.pptiSAP敏捷实施经验可以从http:/D敏捷迭代栏目获取更多材料。,
