敏捷培训材料(pmo)


奔跑在敏捷的阳光下 --- Scrum 基础培训 PMO 2012.08 分享什么? 什么是敏捷开发 ? 为什么要敏捷? Scrum 角色 Scrum实施的基础知识 敏捷实践经验分享 总结 什么是敏捷开发  什么是敏捷开发? 敏捷开发,Agile Development,就是指能够在需求迅速变化的情况 下快速开发软件。我们接触最多敏捷实践方式有:极限编程(XP)、 结对编程、测试驱动开发(TDD)等。 什么是敏捷开发 敏捷联盟宣言:2001年 、17位牛人、敏捷联盟 我们一直在实践中探寻更好的软件开发方法, 身体力行的同时也帮助他人。由此我们建立了如下价值观: 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说,尽管右项有其价值, 我们更重视左项的价值。 来源:http://www.agilemanifesto.org/iso/zhchs/ 什么是敏捷开发 敏捷原则: 1、尽早地、持续地交付有价值的软件来满足客户的需求 2、欢迎需求的变化,即使是项目后期的变更。敏捷过程能够驾驭变化,为客户 带来竞争优势 3、经常交付可以工作的软件,时间间隔越短越好 4、整个项目开发期间,业务人员与开发人员应该工作在一起 5、围绕斗志高昂的人构建项目,给他们提供所需的环境,满足他们的需要,并 信任他们 6、最有效的信息传达方式和与团队相处的方法是面对面交流 7、可以工作的软件是进度主要的度量标准 8、敏捷过程提倡可持续开发。投资方、开发者和用户应该总是保持一致的步伐 9、不断追求卓越技术和良好设计有助于加强敏捷性 10、简单--尽量减少工作量是非常重要的 11、最好的架构、需求和设计都出自于自我组织的团队 12、每隔一段时间,团队都要反思如何更有效率,并相应地调整自己的行为 为什么要敏捷  关于需求的三个假设:  客户知道他想要什么  开发人员知道该怎样实现  没有变更  理想 vs. 现实  客户不断发现他想要什么  开发人员不断发现怎样去实现  一切都在变,唯一不变的是变化 预测式 vs. 经验式 Scrum – 一种敏捷框架 Scrum的流程示意图 Scrum角色 产品经理 Scrum Master Scrum Team 成员 让我们来动手吧---准备我们的作战室! 准备一间我们的作战室: 让我们来动手吧---准备我们的作战室! 准备一面任务墙: 让我们来动手吧---准备我们的作战室! 建议:  大家能尽量坐在一起:至少要能看得见彼此  尽量和其他团队或者部门不要混居  产品经理和开发主管不要坐在开发团队中间  Scrum Master 也不要坐在开发团队中间 我们打算做点什么呢---编故事,定需求! 编制我们的产品清单(product backlog): ID、Name、Importance、Initial Estimate、Demo、Notes Product Backlog ID Name Imp Est Demo Notes 1 存款 30 5 登录,打开存款界 面,存入10欧元, 转到我的账户余额 界面,检查我的余 额增加了10欧元。 需要UML顺序图。 目前不需要考虑加 密的问题 2 察看明细 10 8 登录,点击“交 易”,存入一笔款 项。返回交易页面, 看到新的存款显示 在页面上。 使用分页技术避免 大规模的数据库查 询。和查看用户列 表的设计相似。 我们打算做点什么呢---编故事,定需求!  什么是用户故事? 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包 括三个要素: 1. 角色:谁要使用这个功能。 2. 活动:需要完成什么样的功能。 3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。  Ron Jeffries的3个C 关于用户故事,Ron Jeffries用3个C来描述它:  卡片(Card)- 用户故事一般写在小的记事卡片上。卡片上可能会写 上故事的简短描述,工作量估算等。  交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负 责人的交流沟通。  确认(Confirmation)- 通过验收测试确认用户故事被正确完成。 我们打算做点什么呢---编故事,定需求!  用户故事通常按照如下的格式来表达: 英文: As a , I want to , so that . 中文: 作为一个<角色>, 我想要<活动>, 以便于<商业价值>  举例: 作为一个―网站管理员‖,我想要―统计每天有多少人访问了我的网站 ‖,以便于―我的赞助商了解我的网站会给他们带来什么收益。‖ 我们打算做点什么呢---编故事,定需求! 用户故事的六个特性- INVEST (INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable ) 一个好的用户故事应该遵循INVEST原则。  独立性(Independent)— 要尽可能的让一个用户故事独立于其他的 用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估 算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减 少依赖性。 可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用 户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描 述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡 带有了太多的细节,实际上限制了和用户的沟通。 有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还 是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一 旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商 的时候,他们将非常乐意写下故事。 我们打算做点什么呢---编故事,定需求! 可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确 定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来 自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太 大了(这时需要把故事切分成小些的)。 短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过 10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完 成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。 可测试性(Testable)—一个用户故事要是可以测试的,以便于确认 它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它 什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使 用的。 我们打算做点什么呢---编故事,定需求! 划分用户故事:从客户角度来划分 具体可以分为: 按照不同操作 - 添加、删除、修改、浏览等 按照数据不同 - 可以浏览产品名和介绍、可以浏览产品价格 按照特性 - 易用性、性能、兼容性、并发性等等按照角色 (从不 同用户角度) 按照投入的人力 - 比如要完成信用卡支付(Visa, Master, AmericanExperess),可以分成三个故事来实现  按照独立的功能 我们打算做点什么呢---编故事,定需求! 编故事的原则: 给Event 表 添加一个索引 提高在后台系 统中搜索并生 成表单的响应 速度 1.我们讲的是故事,不是实现方法! 2.我们讲的是小故事!(翠西定律) 我们打算做点什么呢---编故事,定需求! 用户故事1:作为一个经常使用手机的用户,我能够快 速给我的手机充电,因此我可以随时打电话。 用户故事2:作为一个经常使用手机的用户,我希望我 的手机能够保持长时间在线,因此我可以随时打电话。 • 超长待机时间,超过一个星期 • 多送一块电池 • 使用太阳能,核能 • 将人们活动时候机械动能转化为电能 开会啦!---Sprint 计划会议 冲刺(Sprint) 计划会议的准备  产品清单已经准备好了  每个故事都有自己的优先级或重要性评级了  想好怎么给大家讲述这些故事了:用卡片将每个故事写下 来;在桌子上排好故事„„  准备好给大家投票用的工具: 20人*日/10人*日/5人*日/2 人*日/1人*日„„  我们要在这个计划会议里干什么? 产品经理介绍我们的故事---产品清单 确立一个合适的sprint长度 根据重要性高低为每个故事估计一个完成时间(人*日为单位) 把选出的故事放入一个sprint 计划中并开始拆分每个故事得出 任务清单。 制定sprint 目标:总得告诉点老板什么呀 开会啦!---Sprint 计划会议 Sprint 计划会议怎么开? 充分讨论:大家都要畅所欲言。大家要能积极参与来把故事拆分 任务 猪们,鸡们:开会啦!---Sprint 计划会议 Sprint 计划会议怎么开? 时间评估:投票要避免互相干扰。估算时间是要考虑投入度因素和预留 机动时间。 70/20原则:员工投入度以 70%为佳;20%左右的时间 处理意外情况。 开会啦!---Sprint 计划会议 开会啦!---Sprint 计划会议 一个典型的时间表 这个日程不是绝对的。Scrum master根据会议进程的需要,可以对各个 阶段的子进程时间安排进行调整。 Sprint 计划会议:13:00 – 17:00 (每小时休息5到10分钟) • 13:00 – 14:00 产品负责人对sprint目标进行总体介绍,概括产品backlog。所有重 要性高的backlog条目都要填写“如何演示” • 14:10 – 15:30 团队估算时间,在必要的情况下拆分backlog条目。产品负责人在必 要时修改重要性评分。理清每个条目的含义。 • 15:40 – 16:30 团队选择要放入sprint中的故事。 • 16:40 – 17:00 为每日scrum会议(以下简称每日例会)安排固定的时间地点(如果 和上次不同的话)。把故事进一步拆分成任务。 团队名称: XXXXXX项目组 Sprint1 目标: 完成计费系统部分存储过程优化和CBS改造 Sprint1 清单 (预计工作量): 优先级 预估(man*day) Sprint Backlog 100 4 银行卡渠道处理 95 3 充积分 80 2 充值赠送积分 预计工作量总计:73.5 man*day 计划: Sprint 周期: 2 weeks (2010年3月24 日 至 2010年4月8日) 每日站会: 9:30AM – 9:45AM, 任务墙前 Sprint 演示: 2010年4月9日 团队构成: 产品经理:XXX Scrum Master:XX 开发工程师:XXX、XXX、XX、XX、XX、XXX 开会啦!---Sprint 计划会议 终于开工啦!--- Daily Meeting Every Day! 我们都要站在这: 15分钟! 终于开工啦!--- Daily Meeting Every Day! 我们都要站在这干什么呢  我们昨天做了什么  我们今天要做什么  有啥问题? 15 minutes 什么是好的Daily Meeting? 1. Scrum Master不会逐个的问每个人问题,如果是,那么这个会议 已经沦为了报告会。 2. 团队成员互相讨论,不是向Scrum Master报告。 3. 每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确 的方式开会,你就不需要再担心超时了。 4. 站会结束后,Scrum Master知道哪些问题需要帮助团队成员解决。 终于开工啦!--- Daily Meeting 为什么站会会失败?  是不是一个“安全”的会议环境?  站会不等于晨会!  隐士是不受欢迎的!  Scrum创造的透明性是否被管理者不恰当地行 为破坏了? 终于开工啦!--- Daily Meeting 我们的任务墙: 终于开工啦!--- 任务墙的使用 对我们的进度保持警惕--- 燃尽图 终于开工啦!--- 燃尽图的使用  对完成的定义(DoD):  团队要统一什么是完成的标准。  团队成员要尊重完成的标准。  完成的标准中应该包括测试:单元测试、验收测试  完成的标准中要包含必要的文档:接口、参数定 义、流程图等。 终于开工啦!--- 定义好完成的标准  注意我们报告的方式:报告健康情况,而不是现 状 讨论Scrum团队的情况时,使用“sprint健康状况”比“sprint现状”更加有 用。尝试使用以下基于当前sprint燃尽图的线性预测的健康状况用词: 卓越——团队将至少提前两天完成sprint目标。在这种情况下,该团队可能要考 虑从产品Backlog中承担额外的故事。  很好——团队将按时完成sprint目标;它们的趋势线显示了团队能按时完成 sprint,或甚至提前一天完成。该团队不用做任何修改;他们已做得非常到位!  较差——团队不能按时完成sprint目标;它们的趋势线显示,还需要额外的1至2 天才能完成sprint目标。该团队应审查他们的障碍,并确保他们正在解决中。他们 可能还需要审查任务分配。然而,任何的改变都需要谨慎地决定。太多的变化可 能比完全不改变更具破坏性。  严重——团队不能按时完成sprint目标;它们的趋势线显示,还需要3天或者以 上才能完成sprint目标。这就是需要从sprint目标降低范围的时候了。团队和产品 负责人应处理该情况,并努力使团队恢复到“很好”的健康状况。 终于开工啦!--- 注意我们的报告方式 良好的质量控制是成功的保证 我们在冲刺中采取的质量控制措施:  代码每天持续集成  结对进行code review  每完成一个业务模块都需要画出相应的流程图并按统一格式整理好接 口和参数文档。  公共的框架或者模块一定会在团队中充分讨论并形成书面文档约定。  引入测评进行验收测试。 墨菲定律和不信任原则 老板:我#@%*! 你们这么久干了些什么? Sprint 结束了 --- 总算是结束啦! 通常我们会: •“哦,我们真的必须做演示么?没啥好东西能展示的!” •“我们没时间准备&%$#的演示!” •“我没时间参加其他团队的演示!” 所以,我们一定要做演示! 收工了!东西呢?--- Sprint 演示 但是,我们一定要做演示! Sprint 演示对团队有什么好处? 团队的成果得到认可。他们会感觉很好。 其他人可以了解你的团队在做些什么。 演示可以吸引相关干系人的注意,并得到重要反馈。 演示是(或者说应该是)一种社会活动,不同的团队可以在这里 相互交流,讨论各自的工作。这很有意义。 做演示会迫使团队真正完成一些工作。 收工了!东西呢?--- Sprint 演示 收工了!东西呢?--- Sprint 演示 Sprint 演示怎么做? 确保清晰阐述了sprint目标。 不要花太多时间准备演示,集中精力演示可以实际工作的代码。 节奏要快,也就是说要把准备的精力放在保持演示的快节奏上, 而不是让它看上去好看。 让演示关注于业务层次,不要管技术细节。告诉大家“我们做了 什么”,而不是“我们怎么做的”。 可能的话,让观众自己试一下产品。 不要演示一大堆细碎的bug修复和微不足道的特性。 有多少爱可以重来?--- Sprint 回顾 问自己几个问题: 我们是否承诺了太多(或者太少)? 如果重头开始,哪个我需要更加珍惜? 是不是该搞定那个总是骚扰我们的销售或者老板? 有多少爱可以重来?--- Sprint 回顾 投票---让我们找出最需要马上改进的地方! 总结 Scrum的流程示意图 总结 Scrum模式的核心价值观: 自适应 沟通 成果 • 迭代的开发过程需要团队通过经验积累和不断总 结来找到适合自己的节奏。 • 团队需要进行自我激励和自我管理。 • 用业务语言来描述目标。 • 团队需要彼此沟通来协调一致。 • 永远让老板知道我们在做什么。 • 计划的制定依赖于可见的成果。 • 计划的完成决定于可见的成果。 ---Scrum is very simple to understand but extremely hard to adopt and practice. 敏捷实践 – 持续集成 源自丰田精益生产模 式—警报灯 改进代码质量,减少 风险 尽早地发现和 修复缺陷 可以测量软件 的健康度 减少重复性的人 工活动 自动构建和测试 把人从重复性的 活动中解放出来 增强项目透明性 有助于决策 显示质量趋势 建立更强的信心 持续集成的重要性 Nightly Build (Hudson) All implementation projects have nightly build 敏捷实践 – 每日构建 敏捷实践经验分享 人 方法工具 敏捷实践经验分享 人---- 敏捷团队是敏 捷实施的前提 1. 互相分享、互相帮助、不断总结、 共同进步,共担质量目标,也共担 同样的质量责仸 2. 开发人员与测试人员的界线变得日 益模糊 3. 开发人员要保证有足够的单元测试 代码覆盖率 4. 测试人员应该提前介入需求讨论, 编写测试用例,准备测试数据,编 写自动化测试脚本 5. 测试人员必须通过与开发团队的密 切合作获取产品信息,制定测试计 划而不是依赖文档 6. 测试人员必须密切介入开发过程, 参与设计,甚至是代码 敏捷实践经验分享 – 工具 Scrum管理工具: ScrumWorks 单元测试:JUnit, HttpUnit, HtmlUnit 代码静态检查工具:PMD,CheckStyle, FindBugs 单元测试代码覆盖率: EMMA 测试自动化:Selenium, JMeter 持续集成:Hudson 敏捷实践经验分享 – 工具 敏捷实践经验分享 – 工具 Sprint View 敏捷实践经验分享 – 工具 Product Backlog Web Client 敏捷实践经验分享 – 工具 Daily Build 敏捷实践经验分享 – 工具 Q&A
还剩55页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

悦悦12718

贡献于2013-09-18

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf