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