软件工程软件工程软件工程 (22).pdf

《软件工程软件工程软件工程 (22).pdf》由会员分享，可在线阅读，更多相关《软件工程软件工程软件工程 (22).pdf（22页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、敏捷开发之敏捷开发之Scrum Scrum方法 方法 Scrum方法是1995年由Ken Schwaber和Jeff Sutherland博士共同提出，已被众多软件企业广泛使用，如Yahoo,Microsoft,Google,Motorola,SAP,IBM 等。Scrum框架 框架 Scrum框架 框架 一个Sprint是一个1-4周的迭代，它是一个时间盒。Sprint的长度一旦确定，将保持不变。Sprint的产出是“完成”的、可用的、潜在可发布的产品增量。Sprint1 Sprint2 Sprint3 SprintN 需求在一个Sprint内是不允许变化的 Scrum框架框架 角色 制品

2、活动 产品负责人 Product Owner Scrum主管 Scrum Manager 团队成员 Team 迭代计划会议 Sprint Planning 每日站立会议 Daily Scrum Meeting 迭代评审会议 Sprint Review 迭代回顾会议 Sprint Retrospective 产品订单 Product Backlog 迭代订单 Sprint Backlog 燃尽图 Burndown Charts Scrum框架框架 角色 制品 活动 产品负责人 Product Owner Scrum主管 Scrum Manager 团队成员 Team 迭代计划会议 Sprint

3、Planning 每日站立会议 Daily Scrum Meeting 迭代评审会议 Sprint Review 迭代回顾会议 Sprint Retrospective 产品订单 Product Backlog 迭代订单 Sprint Backlog 燃尽图 Burndown Charts Scrum团队角色团队角色 产品负责人 Scrum主管 定义产品需求 确定产品发布计划 对产品收益负责 确定需求优先级 调整需求和优先级 验收迭代结果 团队 其他干系人 用户 直接管理项目 帮助团队制定冲刺计划 组织每日站立会议 引导团队正确应用敏捷实践 确保团队功能完备富有效率 促进团队紧密协作 排除团队

4、遇到的障碍 保护团队不受打扰 一般是5-9人 团队是跨职能的 成员都全职工作 自我组织和管理 合作完成冲刺开发工作 保证每一次冲刺的成功 Scrum团队团队 自组织团队是敏捷软件开发的基本观念，即团队被授权自己管理他们的工作过程和进度，并且团队决定如何完成工作。Scrum团队 团队 自组织团队是敏捷软件开发的基本观念，即团队被授权自己管理他们的工作过程和进度，并且团队决定如何完成工作。团队决定谁做什么，即任务的分配 团队决定如何做，如何实现目标，即团队做技术决策 团队需要在确保目标的前提下制定团队内的行为准则 团队有义务保持过程的透明性 团队监督和管理他们的过程和进度 Scrum框架框架 角色

5、 制品 活动 产品负责人 Product Owner Scrum主管 Scrum Manager 团队成员 Team 迭代计划会议 Sprint Planning 每日站立会议 Daily Scrum Meeting 迭代评审会议 Sprint Review 迭代回顾会议 Sprint Retrospective 产品订单 Product Backlog 迭代订单 Sprint Backlog 燃尽图 Burndown Charts Scrum制品制品 产品订单是从客户价值角度理解的产品功能列表。功能、缺陷、增强等都可以是产品订单项 整体上从客户价值进行优先级排序 迭代订单是从开发技术角度理解

6、的迭代开发任务。简单环境：可直接把产品订单项分配到迭代中 复杂环境：可把一个产品订单项分为Web/后台软件/硬件程序/美工等开发任务 可工作软件是可交付的软件产品。“可交付”应视不同情况提前设定和选定交付标准。正式产品可能包括使用文档，在新产品开发初期可能只需要交付勉强看到效果的产品。Product Backlog Sprint Backlog Working Software 产品订单 产品订单 在迭代计划时，产品负责人告诉开发团队需要完成产品订单中的哪些订单项，开发团队决定在下一次迭代中他们能够承诺完成多少订单项。在迭代的过程中，没有人能够变更迭代订单，这意味着在一次迭代中需求是被冻结的。

7、用户故事 用户故事 优先级 名称 用户故事描述 1 浏览商品 作为一名顾客想购买商品而不确定型号时，我希望能浏览网站在售的商品，按照商品类型和价格范围进行过滤。2 搜索商品 作为一名顾客在查找某种商品时，我希望能进行不限格式的文本搜索，例如按照短语或关键字。3 注册账户 作为一名新顾客，我希望注册并设置一个帐户，包括用户名、密码、信用卡和送货信息等。4 维护购物车 作为一名顾客，我希望能将指定商品放入购物车（稍后购买）、查看我的购物车内的商品以及移除我不想要的物品。5 结账 作为一名顾客，我希望能完成我购物车内所有商品的购买过程。6 编辑商品 规格 作为一名工作人员，我希望能够添加和编辑在售商

8、品的详细信息（包括介绍、规格说明、价格等）。7 查看订单 作为一名工作人员，我希望能登录并查看一段时间内应该完成或已经完成的所有订单。可视化管理 可视化管理 任务白板是团队开发的晴雨表，它将团队的任务和进度可视化地展现出来。而引入电子白板可能会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。可视化管理 可视化管理 燃尽图：以图形化方式展现了剩余工作量（Y轴）与时间（X轴）的关系。该团队的计划并不好，因为线根本就没有触到零点 该团队已经达成了目标，但并没有主动去更新数字 该团队计划良好，实现了足够故事，接近理想情况 剩余工作量时间 Scrum框架框架 角色 制品 活动 产品负

9、责人 Product Owner Scrum主管 Scrum Manager 团队成员 Team 迭代计划会议 Sprint Planning 每日站立会议 Daily Scrum Meeting 迭代评审会议 Sprint Review 迭代回顾会议 Sprint Retrospective 产品订单 Product Backlog 迭代订单 Sprint Backlog 燃尽图 Burndown Charts Scrum规划规划 20 points Sprint 1 18 points Sprint 2 79 points Sprint 3-6 发布规划 定义用户故事并进行优先级划分 估算

10、规模以及评估团队开发速度 制定发布计划 Story Story A 5 points Story B 3 points Task 确定规则 设计UI 编写类库 自动化测试 迭代规划 确定迭代目标并选择用户故事 将用户故事分解和细化到任务 对故事和任务进行时间估算 迭代计划会议 迭代计划会议 迭代计划会议在每次迭代（或冲刺）开始时召开，一般是24小时，目的是选择和估算本次迭代的工作项。第一部分：以需求分析为主，选择和排序本次迭代需要实现的订单条目 第二部分：以设计为主，确定系统设计方案和工作内容 每日站立会 每日站立会 会议目的：团队在会议中做计划，协调其每日活动，还可以报告和讨论遇到的障碍。任

11、务板帮助团队聚焦于每日活动上，应在这个时候更新任务板和燃尽图。每个团队成员需要回答三个问题：上次例会后完成了什么？遇到了什么困难（或障碍）？下次例会前计划做什么？迭代评审会议 迭代评审会议 会议目的：Scrum团队在会议中向最终用户展示迭代的工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。基本要求：由团队展示有可能发布的产品增量 允许所有参与者尝试由团队展示的新功能 用户对团队演示的产品功能进行反馈 迭代回顾会议 迭代回顾会议 每一次迭代完成后，都会举行一次迭代总结会，会上所有团队成员都要反思这个迭代。举行迭代总结会议是为了进行持续过程改进，时间限制在1小时左右。迭代回顾会议的关键要点：会议气氛：团队全员参加，气氛宽松自由，畅所欲言，发现问题和分析原因；关注重点：每次仅就1-3个关键问题做出可行的解决方案；跟踪闭环：可以放入下一次迭代订单中执行改进。谢谢大家谢谢大家！THANKS