- 1、本文档共85页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
常见的最完整的Scrum敏捷软件开发过程
* 迭代回顾会议 Sprint Retrospective 回顾的目的是评价本次迭代并酝酿改进,使得下一个迭代进行的更好. 类似于项目的最终评审,但经常举行. 障碍列表具有很好的参考价值! Scrum Master主持召开, 持续半天, Scrum团队参加 (产品所有者也可参加). 简单流程: Scrum Master 总结本次迭代; 迭代任务清单, 重要的事情和决策, 预期的/实际进度. 每个组员陈述迭代中那些方法进行的较好、哪些需要改进, Scrum Master 进行记录. 对重要的问题计划相应的措施:团队自己解决, 或者提交给公司的管理层. Scrum方法应用 * 敏捷开发中使用扑克Poker方法进行估计(1/3) 尽管名字有好笑, 但却非常可靠和有效. 可以来估算产品需求清单中每项的规模(规模估算: 用例点story point)以及迭代任务清单中任务的估计 (工作量估算: 人时). Scrum Master推动活动的进行, 一个以上的专家参与估算, 而且最好是项目团队中的人. 估算时使用卡片:写有一系列的离散数据,如0, 1, 2, 3, 5, 8, 13, ? (无法估计). * 敏捷开发中使用扑克Poker方法进行估计(2/3) 前提条件: 提前准备好要估算的任务、User Stories等; 迭代任务清单和产品需求清单都已经起草好. 对某个任务最有经验的开发者做一个简短的概述. 可以通过简短的讨论澄清任务的具体含义,找出存在的风险以及不确定性. 各自对任务进行估计,所有的人将写有各自估计数据的扑克/卡片扣上。 (单位事先进行约定:工时、事件点). 大家同时把扑克/卡片翻过来. 如果扑克/卡片上的数差距比较明显 (如一个13,2个5,一个1), 就要讨论一下为什么会出现这么大的差距,估计值所基于的假定要进行澄清. 如果差距较小 (如三个8两个5) ,主持人帮助确定最终的估值. 对于不确定性,估算数据中可以多包含一些余量. 不断的重复该过程直到达成一致. 将这些估值记录到相应的文档中 (产品需求清单, 迭代任务清单). * 敏捷开发中使用扑克Poker方法进行估计 (3/3) 为什么使用离散的数字? 比使用任意数字更加容易进行估算. 在整个项目中或者迭代中, 每个人估计值的错误会相互抵消掉. 对每个任务, 16 小时是上限, 不确定性会随着规模的增加而增加. 为什么要有 “?”. 将较大的任务进行分解,帮助更加精确的估计同时减少不确定性. 为什么要 “讨论并重复”? 弄清不同的假设 (利用重用代码或者重新编码) 和可能的误解 ? 更为可靠的估计. 对于那些偏离平均值的估计,即使由有经验的人给出的,也必须要有充分的理由. * 练习 在一个小时之内编写一个三只小猪的连环画册 使用Scrum 实践 自组织团队 迭代 每日Scrum会议 产品需求清单 迭代任务清单 * 练习-进度安排 5 分钟: 迭代目标 团队与产品所有者共同协作,从产品需求列表中选择本次迭代要完成的项目 5 分钟: 迭代任务清单 团队从所选择的产品需求列表中产生任务 10 分钟: 第一天 团队完成任务和产品需求列表中的项目 产品所有者负责回答问题 5 分钟: “每日”“Scrum会议 每个人回答三个问题 10 分钟: 第二天 团队继续完成任务和产品需求列表中的项目 产品所有者负责回答问题 5 分钟: “每日”“Scrum会议 每个人回答三个问题 10 分钟: 第三天 团队完成产品的一个版本 产品所有者负责回答问题 每组5 分钟: 演示 团队向产品所有者展示完成的连环画册 * 练习 – 给出优先级的产品需求清单 展示基本的故事 用铅笔画展示的故事 每页图画配有说明 给出写有标题的封面 故事用9页进行说明 展示版权信息 添加色彩 广告 教小孩数数1,2,3 寓教于乐:坚固的重要性 封皮吸引人 硬的封皮 3D效果的卡通形象 展示所有的故事内容 产品所有者- Product Owner 充分考虑市场情况,对产品进行规划并进行简要地说明 规划当前该产品如何占有更多的市场份额 规划今后该产品的发展前景 Scrum团队根据产品所有者的产品规划进行开发 * 测试驱动开发 Test Driven Development 什么是测试驱动? 一种能够支持Scrum的敏捷实践方法,开发满足DoD的软件 首先创建测试用例,然后开发软件通过测试(在开发代码前,首先编写测试代码) 一种设计软件的方法,而不仅仅是一种测试方法 所创建的测试用例用来指导和约束项目中的各项工作,对未来的各项工作提供一个安全的保护 不需要测试的工作不需要完成 所创建的测试用例通常替代详细的业务和技术需求定 测试也有效地驱动设计,使设计更加趋向于可行的设计 通常情况下需要
文档评论(0)