《经验分享敏捷开发流程课件》由会员分享，可在线阅读，更多相关《经验分享敏捷开发流程课件（24页珍藏版）》请在装配图网上搜索。
1、经验分享敏捷开发流程1 敏捷开发流程介绍经验分享敏捷开发流程2目录什么是软件开发方法什么是敏捷开发方法我们该采用什么方法经验分享敏捷开发流程3什么是软件开发方法什么是软件开发方法软件开发定义软件开发定义 根据用户需求建造出软件系统的产品开发过程。包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制。 - 维基百科维基百科常见种类常见种类瀑布式开发迭代式开发敏捷式开发经验分享敏捷开发流程4瀑布式开发最典型的预见性方法，严格遵循预先计划按照需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果用以衡量进度，例如需求规格，设计文档，测试计划等，方便定义里程碑主要问题是严格分级
2、导致自由度降低，早期承诺导致对后期需求变化难以调整，代价高昂 经验分享敏捷开发流程5迭代式开发弥补传统开发方式的一些弱点，具有更高的成功率和生产率开发被分为一系列的小的、固定长度的小项目，称为一系列的迭代。每次都包括需求分析、设计、实现与测试。开发工作可在需求被完全确定前启动，并在一次迭代中完成部分功能。再通过客户反馈来细化需求，开始新一轮迭代。 经验分享敏捷开发流程6Agile software development什么是敏捷开发方法什么是敏捷开发方法主要原则：主要原则：个体和互动个体和互动：高于流程和工具工作的软件工作的软件：高于详尽的文档客户合作客户合作：高于合同谈判响应变化响应变化：
3、高于遵循计划vs迭代：迭代：都强调在短的开发周期提交软件，敏捷的周期可能更短，更强调人的高度协作vs瀑布：瀑布：敏捷强调尽早将小的可用功能交付使用，在项目周期中持续改善，自由度高主要方法：主要方法：极限编程极限编程测试驱动开发测试驱动开发Scrum机制机制看板文化看板文化经验分享敏捷开发流程7极限编程Extreme programming，缩写为XP，强调可适应性而不是可预测性认为软件需求变化是自然现象在项目周期的任何阶段去适应变化，降低因需求变更而带来的成本快速反馈：快速反馈：对客户反馈做到及时、迅速，重视单元测试假设简单：假设简单：认为任何问题都可以“极度简单”地解决，拒绝预测需求，拒绝为
4、了未来而考虑重用 增量变化：增量变化：一次完成大的改造是不可能的，采用增量变化，小步前进包容变化：包容变化：强调不反抗变化，应该包容变化经验分享敏捷开发流程8测试驱动开发Test-Driven Development，简称TDD。它要求在编写代码之前先写测试代码，只编写使测试通过的功能代码，通过测试来推动整个开发的进行。编写简洁可用和高质量的代码，并加速开发过程。 （FDD, DDD）根据客户需求编写测试用例，从使用者角度设计代码易测试和测试独立性的要求使设计松耦合频繁地运行测试，尽早地发现错误，提高代码质量持续的回归测试，持续地跟踪整个系统的状态单元测试代码可作为文档，展示所有的API该如何
5、使用和运作经验分享敏捷开发流程9主要角色：主要角色：Scrum Master ：Scrum教练和团队带头人，确保团队合理的运作Scrum产品负责人（产品负责人（Product Owner）:确定产品方向，定义产品内容、优先级及交付时间开发团队（开发团队（Team）: 跨职能的小团队（5-9人），拥有交付软件需要的各种技能一种迭代式增量软件开发过程，包括了一系列实践和预定义角色的过程骨架，通常用于敏捷软件开发。英语是橄榄球中争球的意思Scrum经验分享敏捷开发流程10Scrum过程总览经验分享敏捷开发流程11Scrum阶段1：制定产品Backlog 产品 backlog 是 Scrum 的核心
6、由需求或特性等组成的列表 用客户的术语加以描述 按照重要性的级别进行排序 backlog 条目称为故事（story）每个故事包括如下字段： ID(统一标识符) Name（名称） Importance（重要性） Initial estimate（初始估算工作量） How to demo（如何做演示） Notes（注解） Bug tracking ID（Bug 跟踪 ID）产品产品 BACKLOG（示例）（示例）IDNameImpEstHow to demoNotes1存款305登录，打开存款界面，存入 10 欧元，转到我的账户余额界面，检查我的余额增加了 10 欧元。需要需要 UML 顺顺序图。
7、目前不序图。目前不需要考虑加需要考虑加密的问题。密的问题。2查看自己的查看自己的交易明细交易明细108登录，点击登录，点击“交易交易”，存入一笔款项。返存入一笔款项。返回交易页面，看到回交易页面，看到新的存款显示在页新的存款显示在页面上。面上。使用分页技使用分页技术避免大规术避免大规模的数据库模的数据库查询。和查看查询。和查看用户列表的用户列表的设计相似。设计相似。经验分享敏捷开发流程12 独立 基本相当于一个feature 对客户有价值 易于评估时间和难度 不易太大或太小 可测试Story的准则的准则-+ValueRiskLowHighHigh优先级评估优先级评估经验分享敏捷开发流程13工作
8、量的估算 最小单位为一个故事点（story point），相当于一个理想的人天 投入最适合的人员，完全没有打扰，需要几天给出一个经过验证，可以交付的完整实现 不需要绝对无误，保证相对准确（即:两个点的时间应该是四个点的一半） 估算全部工作，而不只是自己的部分 把故事分拆成更小的故事以达到更精确 最小值是 0.5，太小的任务要么被移除，要么就给 0.5经验分享敏捷开发流程14Scrum阶段2:制定Sprint Backlog sprint 目标 团队成员名单（以及投入程度） 确定sprint backlog（即 故事列表） 确定好 sprint 演示日期 确定每日 scrum 会议时间地点 协商
9、sprint的时间长度经验分享敏捷开发流程15召开Sprint 会议Sprint 计划会议：13:00 17:00 （每小时休息 10 分钟）13:00 13:30 产品负责人对 sprint 目标进行总体介绍，概 括产品 backlog。定下演示的时间地点。13:30 15:00 团队估算时间，在必要的情况下拆分 backlog 条目。产品负责人在必要时修改重要性评分。理清每个条 目的含义。所有重要性高的 backlog 条目都要填写“如何演 示”。15:00 16:00 团队选择要放入 sprint 中的故事。计算生产率，用作核查工作安排的基础。16:00 17:00 为每日 scrum
10、会议安排固定的时间地点，把故事进一步拆分成任务。经验分享敏捷开发流程16确定Sprint生产力如果没有参考怎么办？随便猜一个，只会在第一个 sprint 里面使用，以后有了历史数据然后做改进。新团队中使用的“默认”投入程度通常是 70%，大多数团队都能达到的数值。经验分享敏捷开发流程17Scrum阶段阶段3：每天站会：每天站会经验分享敏捷开发流程18看板和站会 用户体验比投影仪好，大家保持清醒，并留心会议进展，更多的参与感 多个故事可以同时编辑 重新划分优先级变得易如反掌挪动索引卡就行 互相看到, 所有人都可以看到彼此，都能看到任务板 例会结束时算出剩余工作量之和，在 sprint 燃尽图上画
11、上一个新的点 处理迟到，惩罚机制经验分享敏捷开发流程19看板经验分享敏捷开发流程20燃尽图经验分享敏捷开发流程21Scrum阶段4：Sprint演示 清晰阐述 sprint 目标 不要花太多时间准备演示，集中精力演示实际工作的代码 节奏要快，保持演示的快节奏 关注业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的” 可能的话，让观众自己试一下产品 不要演示一大堆细碎的 bug 修复和微不足道的特性经验分享敏捷开发流程22Scrum阶段5：Sprint总结设定时间为 1 至 3 个小时参与者：产品负责人，整个团队 向大家展示 sprint backlog，对sprint 做总结 每个人轮流发言，讲出自己的想法，什么是好的，哪些可以更好，哪些需要在下个 sprint 中改变 对预估生产率和实际生产率比较，差异大的话，分析原因 对建议进行总结，得出下个 sprint 需要改进的地方经验分享敏捷开发流程23我们该采用什么流程？学习敏捷对沟通的重视，对项目状态的紧密跟踪学习敏捷对沟通的重视，对项目状态的紧密跟踪学习瀑布对于设计和文档的重视学习瀑布对于设计和文档的重视学习测试驱动开发对于测试的重视学习测试驱动开发对于测试的重视经验分享敏捷开发流程24此课件下载可自行编辑修改，供参考！感谢您的支持，我们努力做得更好！
经验分享敏捷开发流程课件
