敏捷开发流程与方法.ppt

敏捷开发流程与方法 strictlyprivateandconfidential bgcn交付管理部 目录 1 1 敏捷的起源 2 敏捷系列 1 2 敏捷方法体系 1 敏捷开发简介 3 敏捷开发的误区 1 3 敏捷宣言 1 4 为什么要敏捷 敏捷开发的起源 上个世纪90年代 2001年 2004年以后 萌芽 产生敏捷方法 敏捷方法是从上个世纪90年代开始发展起来的一组方法学的总称 包括极限编程等等 这些方法学之间有一些差异 但是差异不是特别大 正规 成立敏捷联盟 每种方法学的领导人共同起草了敏捷软件开发宣言 总结出方法之间的共同点 最终就是价值 并且用敏捷这个词给这种方法学一个统称 发展 开始广为流行 500强公司中众多公司应用敏捷 如hp microsoft ibm等 什么是敏捷开发 敏捷开发 agiledevelopment 是一种以人为核心 迭代 循序渐进的开发方法 目录 1 1 敏捷的起源 1 2 敏捷方法体系 1 敏捷开发简介 1 3 敏捷宣言 1 4 为什么要敏捷 2 敏捷系列 3 敏捷开发的误区 敏捷方法 xp extremeprograming极限编程 思想源自kentbeck和wardcunningham在软件项目中的合作经历 scrum 是一种迭代的增量化过程 用于产品开发或工作管理 水晶方法crystal 由alistaircockburn在1990年代末提出 把不同类型的项目采用不同的方法 fdd 特性驱动featuredrivendevelopment 由petercoad jeffdeluca ericlefebvre共同开发 是一套针对中小型软件开发项目的开发模式 它强调的是简化 实用 易于被开发团队接受 适用于需求经常变动的项目 dsdm dynamicsystemdevelopmentmethodology 它倡导以业务为核心 快速而有效地进行系统开发 在英国等欧洲国家比较流行 asd adaptivesoftwaredevelopment 由jimhighsmith在1999年正式提出 asd强调开发方法的适应性 adaptive 敏捷开发特点 敏捷开发包括很多方法 例如xp和fdd 同重量级的文档驱动的开发过程相比较 敏捷方法在灵活性等方面更有吸引力 这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践 很多方法很难独立的使用 如 测试驱动的开发 结对开发 计划调整周期以及持续改进 不过 后来的结果证实 这些方法都取得了成功 使用这些方法并不能保证一定成功 开发者的经验和技术仍旧是影响开发结果的最主要因素 对于合适的人 基于敏捷原则的开发方法可以产生更好的结果 同时形成一个愉快地 有激情的工作环境 目录 1 1 敏捷的起源 1 2 敏捷方法体系 1 敏捷开发简介 1 3 敏捷宣言 1 4 为什么要敏捷 2 敏捷系列 3 敏捷开发的误区 敏捷宣言 核心理念 适应和以人为本 客户合作胜过合同谈判 响应变化胜过遵循计划 可以工作的软件胜过面面俱到的文档 个体和交互胜过过程和工具 敏捷规则 最高目标是能持续地 及早地向客户交付软件 拥抱变化 频繁地发布可运行的软件 客户和开发人员在一起工作 以人为本 最重要的衡量开发过程的手段 是可工作的软件 稳定的开发速度 敏捷高效的设计 简单有效 重视teamwork 积极的调整 目录 1 1 敏捷的起源 1 2 敏捷方法体系 1 敏捷开发简介 1 3 敏捷宣言 1 4 为什么要敏捷 2 敏捷系列 3 敏捷开发的误区 我们为什么需要敏捷 我们为什么需要敏捷 部门 1 培养团队合作精神 稳定开发队伍 2 提高开发人员的水平 3 提高项目成功率 降低开发成本 提升软件开发效率项目经理 1 更好地和用户沟通 更清晰地理解用户需求 2 更充分地使用资源 更科学地调配资源 更精确地掌握开发进度 系统分析设计 1 设计更加完善 2 更有效地更新知识 得到其他成员更多的尊重 程序员 1 学习系统设计和项目管理 2 提高学习和工作效率 受到重视 减少加班时间 工作更高效 谁在用敏捷 fortune500公司中成功应用xp的公司包括ford daimler chrysler firstunionnationalbank ibm hp等等 通信业ns ericsson alcatel等都号称在转向敏捷更多是小规模开发队伍 小规模开发队伍小规模项目 越来越多的公司开始使用敏捷开发过程 敏捷开发成功的因素 知识和技能 文化和氛围 自组织团队 开放的心态 目录 2 1 xp extremeprograming 2 敏捷系列 2 2 scrum 1 敏捷开发简介 3 敏捷开发的误区 敏捷实践 在敏捷的两个门派 xp scrum中 整理归纳了很多可以用于协助软件开发的实践 后面统称为敏捷实践 什么是xp xpisalightweightmethodologyforsmalltomediumsizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingrequirements kentbeck kentbeck wardcunningham martinfowler ronjeffries于2000年创立xp是软件开发过程中的纪律 它规定你 必须在编程前些测试 必须两个人一起编程 必须遵守编程规范 xp是把最好的实践经验提取出来 形成了一个崭新的开发方法 什么是xp 极限的含义 软件开发中的优点发挥到极致 kentbeck xp 给程序员提供了明确的方法 使得程序员尽管面对需求的改变 却能够从容应对 即使着重变化发生在项目的后期 仍然能够编出代码 xp核心 沟通 简明 反馈和勇气xp重视沟通 客户 开发人员 管理者共同组成团队 xp是一个实践系统13个实践xp方法的贡献以拥抱变化的思想 协作的团队 简单的规则等为原则的13个具体实践是知名度最高的敏捷开发方法 xp的计划 反馈循环 xp开发工作流 xp的关键实践 编程方法 交付和管理 小组实践 xp的关键实践 结对编程 测试驱动开发 重构 简单设计 代码集体所有 编码标准 稳定高速的步伐 持续集成 隐喻 现场客户 完整的团队 小规模发布 计划游戏 编程方法 小组实践 交付和管理 交付和管理 交付和管理1 完整的团队 wholeteam productmanager projectmanagercoachteamleaddeveloperstrackertester on site customers 所有的小组成员应在同一个工作地点工作 成员中必须有一个用户代表 on siteuser 由他 她来提出需求 确定开发优先级 把握开发的动向 通常还设一个教练 coach 角色 来指导xp方法的实施及与外部的沟通协调等 小组每个成员都应围绕用户代表 充分贡献自己的技能 交付和管理2 计划游戏 planninggame 交付和管理3 现场客户 on sitecustomer 客户是team成员 在开发现场和开发人员一起工作 传统的客户任务一般是讲解需求 运行验收测试 接收发布的系统 xp新增加的任务 1 写userstory 2 评估userstory的商业优先级 3 为每个userstory定义验收测试 4 计划开发内容 5 调控开发过程 6 建立商业模型 把隐藏在客户需求下的原则传授给开发人员 8 程序员分担任务的过程支解了对他们商业模型的理解 9 参加设计过程 10 和程序员一起找出metaphor 导引设计方向 11 在metaphor的帮助下 定义更有效更实际的功能测试 给程序员的设计制定了规范 交付和管理4 小规模发布 降低开发风险 保证客户有足够的依据调控开发过程 增加 删除或改变userstory 客户使用发布的系统 可以保证频繁地反馈和交流 发布过程应该尽可能地自动化 规范化 不断地发布可用的系统可以告诉客户你在做正确的事情 低风险 智能化 适应调整 频繁交流 知会客户 频繁发布 经过验证 随着开发的推进 发布越来越频繁 所有的发布都要经过功能测试 小规模发布 小组实践 小组实践1 持续集成 continuousintegration 持续集成指不断地把完成的功能模块整合在一起 目的在于不断获得客户反馈以及尽早发现bug 随时整合 越频繁越好 集成及测试过程的自动化程度越高越好 atestaday takesthebugsaway siemens 小组实践1 持续集成 continuousintegration 1 自动化编译质量度量 2 3 自动化测试 持续反馈 团队实践2 隐喻 systemmetaphor thesystemmetaphorisastorythateveryone customers programmers andmanagers cantellabouthowthesystemworks kentbeckteam将domain sub domainmodel design sub designmodel以及一些关键概念等等抽象化为比喻 通过这些比喻 加强客户和程序员之间的相互理解 消化积累知识 指导设计开发的方向 例 market 发布 浏览 价格洽谈 生成和履行合同 string tree package chartroom spider robot 电影后期制作 邮递 电影院播放电影 小组实践2 隐喻 systemmetaphor metaphor的形成过程 是客户建立并抽象商业模型和商业概念的过程 是程序员建立并抽象设计模型和设计概念的过程 metaphor使客户和程序员用共通的模型和语言进行交流 oneteam onelanguage metaphor可以帮助减少 知识泄露 和 支解知识 metaphor是设计过程的航标 真正灵活有效的设计是针对商业原则的设计 而不是针对商业原则表现形式的设计 更不是脱离商业需求目的的学术设计 随着开发的继续 team会找到更好的metaphor 这是知识细化 深化的结果 是 持续学习 continuouslearning 的过程 是对商业模型和设计模型的持续重构 小组实践3 编码标准 codingstandards 编码标准的目的 防止团队被一些无关紧要的愚蠢争论搞得不知所措 不要预先花费太多时间 目标应该是团队中没有人辨认各自的代码 以团队为单位对某一标准达成协议 然后遵守这一标准 不是事无巨细的规则列表 而是确保代码可交流的指导方针 七个原则 编码标准开始时应很简单 然后根据团队经验逐步进化 创建能够工作的最简单标准 然后逐步发展 只制订适合本团队的 小组实践4 集体拥有代码 我们 的代码 而不是 我 的代码 任何人可以改动任何一段代码 但改动后的代码必须通过所有相关的测试 简单设计 编码标准和结对编程 使阅读和修改team内其他人的代码变得实际可行 思考 同公司信息安全可能有冲突 在一定范围内进行集体拥有代码还是可行的 小组实践5 稳定高速的步伐 40 hourweek 每天早晨都感到有活力有激情 每天晚上都感到疲惫而满足 kentbeck 编程方法 编程方法1 测试驱动开发 tdd 编程方法2 重构 refactoring 减少重复设计 优化设计结构 提高技术上的重用性和可扩展性 重构和编程前的计划型设计 planneddesign 结合 使xp的简单设计可行有效 xp提倡毫不留情的重构 refactormercilessly 任何人可以重构任何代码 前提是重构后的代码一定要通过100 测试单元测试后才能被check in 可以根据需要 将一个迭代的全部目标定为重构 不要太在意什么是最简单的设计 愿意在最后重构 比知道如何做简单的设计重要得多 在metaphor指引下的重构 是为商业模型服务的 不要把重构变成不断的盲目精简代码 编程方法3 简单设计 简单设计dothesimplestthingthatcouldpossiblywork youaren tgoingtoneedit如果没有它和众多惯例规则之间的耦合 xp的演化设计就蜕化成code fix xp的演化设计是在up frontdesign和refactoring之间找到新的平衡 编程方法3 简单设计 标准 依重要性 通过所有测试 可读性高的代码 避免重复 最少数量的类别或方法 systemmetaphor给设计提供了指引 加强team对设计的理解 第一个迭代搭建了基本的系统框架 以后的迭代过程 是在反馈和编程的基础上做交互式设计 减少了设计的投机性 迭代过程中的crc卡帮助team交流设计思想 简化了设计文档 构对设计进行优化 xp认为设计非常重要 因此应该是一个持续的事务 我们总是先尝试使用能够工作的最简单的设计 然后随着现实的不断显现来更改它 对简单设计的需求并不是说所有设计都很小 也不表示它们是无足轻重的 它们只不过需要尽可能简单 但是仍能工作 编程方法4 结对编程 pairprogramming 所有设计决策都牵涉到至少两个人 至少有两个人熟悉系统的每一部分 几乎不可能出现两个人同时疏忽测试或其它任务 改变各对的组合在可以在团队范围内传播知识 代码总是由至少一人复查 结对的编程比单独编程更有效 xp中最有争议的实践之一 目录 2 1 xp extremeprograming 2 敏捷系列 2 2 scrum 1 敏捷开发简介 3 敏捷与cmm 4 敏捷开发的误区 scrum scrum来源于橄榄球运动 指 在橄榄球比赛中 双方前锋站在一起紧密相连 当球在他们之间投掷时他们奋力争球 scrum提供了一种经验方法 它使得团队成员能够独立地 集中地在创造性的环境下工作 它发现了软件工程的社会意义 这一过程是迅速 有适应性 自组织的 它代表了从顺序开发过程以来的重大变化 kenschwaber scrum是一种灵活的软件管理过程 它可以帮助驾驭迭代 递增的软件开发过程 scrum于1995年提出 并在2001年同其他方法论一起组成 敏捷联盟 agilealliance scrum这个轻量的过程可以作为包装器 也就是说你可以把scrum与其它灵活的过程框架组合起来 scrum的过程图 scrum实践 1 scrum团队 5 7个人的小项目团队 团队的负责人可能担负起scrummaster的角色 2 backlog 急待完成的一系列任务 包括 未细化的产品功能要求 bugs 缺陷 用户提出的改进 具竞争力的功能及技术升级等 按优先级定义出来 这些任务可能不是完整的 甚至可能随时会更改或添加 3 sprint 冲刺 通常为30天的迭代时间 把backlog中的每一项安排在sprint中 由团队估算出所需要的时间 按小时记 每一次sprint之后 一定要有可以交付使用的功能 4 scrum会议 这是与传统方式最大的区别 每天15 20分钟的scrum会议 通常在每天的同一时间和同一个房间内举行 scrum团队所有人都参加 也可以有旁听者 但不允许旁听者指手划脚 在这个15分钟的会议上 scrummaster会询问每个成员三个问题 a 自上次scrum会议后的1天里你做了什么 b 从现在到下次scrum会议的1天时间里你准备做什么 c 你在工作中遇到了哪些困难 每个成员在backlog条目上所花费的时间会被记录到springbacklog中 scrummaster在会上对存在的问题提出即时的解决方案或指导 使团队不断向着目标前进 scrum会议不同于项目会议 对团队来说 它起到了快速简报的作用 5 通过sprintbacklog的分析 可以了解backlog的进度 尽早的了解所发生的问题6 管理者不在是项目或者团队的 老板 而是帮助团队解决问题的 协调者 或是 助手 7 每一次sprint之后要review 团队按照既定的sprintbacklog目标来演示完成的内容 scrum中的3 3 3 三种工件 三种会议 三种角色 待开发任务列表 thesprintbacklog 待修复缺陷列表 thedefectbacklog 进度图 燃尽图 brundownchart productownerscrummaster团队成员 scrumteam 迭代计划会议 sprintplanningmeeting 每日晨会 dailyscrummeeting 迭代回顾会议 sprintreviewmeeting productbacklog sprint划分示意 sprint会议 根据backlog 制定每次sprint的计划 目录 2 敏捷系列 1 敏捷开发简介 3 敏捷开发的误区 讨论 误区一 敏捷是 一个 过程 误区二 敏捷仅是个软件过程 误区三 敏捷是反文档的 误区四 为了敏捷而敏捷 误区五 重做就是重构 误区一 敏捷是 一个 过程 敏捷不是一个过程 是一类过程的统称 它们有一个共性 就是符合敏捷价值观 遵循敏捷的原则 误区二 敏捷仅是个软件过程 敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上 正如敏捷宣言的第一条 个体和交互胜过过程和工具 所说