软件工程第10章汇编.ppt

* * * * WIP是一个精益的概念，是指正在加工的产品或者准备加工的原料或半成品 由于WIP占用了资金和资源而不能立即交付给客户，在精益生产中被看做一种浪费 凡是已经开始且没有完成的制品，例如开发准备、实现、系统测试、客户确认阶段的制品，都属于WIP 通过限制WIP，可以实现拉动系统 周期时间是一个需求在整个开发环节流动的时间。周期时间越短，对客户的响应越迅速 通过度量周期时间，软件开发组织能够了解当前的现状，并且为下一步的改善设定目标 过程准则明确的约定了制品在不同阶段之间跳转的规则。例如： 开发准备阶段应该做到什么程度？ 实现阶段是否应该包含代码质量检查？是否应该包含自动化测试?？ 过程准则帮助软件团队准确了解项目状态，进行进一步的改善 看板中的工作流并不是一成不变的 看板方法不会告诉软件团队应该如何做，但是它会要求软件团队就这个问题进行讨论，然后提出解决方案 软件团队会在实践中逐步发现更好的工作流 * * * * * * * * * * * * * * * * * * * * * * * * * * * * Scrum的规则要求开发团队在每个Sprint的交付物都应该达到“完成”（done） “完成”标准由开发团队定义，并且进行了清晰的描述 只有达到了“完成”标准，开发团队在Sprint的输出才能被看做是合格的交付物，才可以声称完成了某个产品增量 需求是逐步细化的 需求可能在项目中间发生变化 需求应当被估算并指定优先级 第1部分 产品负责人介绍产品Backlog中的高优先级的条目 团队基于历史速率，从高到低按照优先级选择将要开发的条目 第2部分 团队分析选择的条目，结合交付标准，讨论需要完成哪些工作 Scrum团队每天召开的短会，保证团队能够了解和分享全局的项目信息。 每日例会的参加者是开发团队成员和Scrum Master，产品负责人可以根据需要决定是否参加。 团队成员在每日例会上回答3个问题： 上次例会后做了什么？ 遇到了哪些困难？ 计划在下次例会前做些什么？ Scrum要求开发团队在每个Sprint结束时都对本Sprint完成的功能进行演示.其基本目标是反馈和适应。 Scrum鼓励各种各样的角色参加 演示，而不仅仅局限于客户、产品负责人和开发团队成员。 Scrum建议Sprint评审尽量使用非正式的方式进行。 参加者： 开发团队、产品负责人和Scrum Master 步骤 准备 数据收集 问题分析 确定方案 结束 敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法 1996年，Kent Beck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念 1999年，Kent Beck撰写了《解析极限编程：拥抱变化》，对极限编程的价值观、原则和实践进行了阐述 最新版本 发布计划 用户认可 用户 故事 (user stories) 下一迭代 Bugs 新用户故事 测试用例 迭代 开发 体系结 构骨架(spike) 系统比喻 制订交 付计划 验收 测试 小发布 需求 不确定的估计 确定的估计 难点 骨架 探索阶段 计划阶段 迭代与发布阶段 产品化阶段 维护阶段 探索阶段 探索阶段的主要工作是开发初始的用户故事（User Stories ）和体系结构骨架（architecture spike） 用户故事描述了系统高层的需求，它是制订发布计划的输入 在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用 探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用 计划阶段 计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划 使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之间的关系 通常图形方式（可以是草图）比文字描述更直观 尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定其工作量估算 迭代到发布阶段 迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本 根据在探索阶段编写的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作 在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或调整 产品化阶段 产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备 在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等 另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调“可