[企业管理]敏捷培训材料PMO

《[企业管理]敏捷培训材料PMO》由会员分享，可在线阅读，更多相关《[企业管理]敏捷培训材料PMO（56页珍藏版）》请在金锄头文库上搜索。

1、奔跑在敏捷的阳光下 - Scrum 基础培训PMO 2012.08分享什么？什么是敏捷开发 ？为什么要敏捷？Scrum 角色Scrum实施的基础知识敏捷实践经验分享总结什么是敏捷开发 什么是敏捷开发什么是敏捷开发?敏捷开发，Agile Development，就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多敏捷实践方式有：极限编程（XP）、结对编程、测试驱动开发（TDD）等。什么是敏捷开发敏捷联盟宣言：敏捷联盟宣言：2001年年 、17位牛人、敏捷联盟位牛人、敏捷联盟我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动高于流程和工具

2、 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划也就是说，尽管右项有其价值， 我们更重视左项的价值。来源：http:/www.agilemanifesto.org/iso/zhchs/什么是敏捷开发敏捷原则：敏捷原则：1、尽早地、持续地交付有价值的软件来满足客户的需求 2、欢迎需求的变化，即使是项目后期的变更。敏捷过程能够驾驭变化，为客户 带来竞争优势 3、经常交付可以工作的软件，时间间隔越短越好 4、整个项目开发期间，业务人员与开发人员应该工作在一起 5、围绕斗志高昂的人构建项目，给他们提供所需的环境，满足他们的需要，并 信任他们 6、最有效的信息传达方式和与团队相处的

3、方法是面对面交流 7、可以工作的软件是进度主要的度量标准可以工作的软件是进度主要的度量标准 8、敏捷过程提倡可持续开发。投资方、开发者和用户应该总是保持一致的步伐 9、不断追求卓越技术和良好设计有助于加强敏捷性 10、简单-尽量减少工作量是非常重要的 11、最好的架构、需求和设计都出自于自我组织的团队 12、每隔一段时间，团队都要反思如何更有效率，并相应地调整自己的行为为什么要敏捷 关于需求的三个假设：关于需求的三个假设：客户知道他想要什么开发人员知道该怎样实现没有变更 理想理想 vs. 现实现实客户不断发现他想要什么开发人员不断发现怎样去实现一切都在变，唯一不变的是变化预测式 vs. 经验式

4、Scrum 一种敏捷框架Scrum的流程示意图Scrum角色产品经理产品经理Scrum MasterScrum Team 成员成员让我们来动手吧-准备我们的作战室!准备一间我们的作战室准备一间我们的作战室:让我们来动手吧-准备我们的作战室!准备一面任务墙：准备一面任务墙：让我们来动手吧-准备我们的作战室!建议：建议：大家能尽量坐在一起：至少要能看得见彼此尽量和其他团队或者部门不要混居产品经理和开发主管不要坐在开发团队中间Scrum Master 也不要坐在开发团队中间我们打算做点什么呢-编故事,定需求!编制我们的产品清单（编制我们的产品清单（product backlog）：）：ID、Name

5、、Importance、Initial Estimate、Demo、NotesProduct BacklogIDNameImpEstDemoNotes1存款305登录，打开存款界 面，存入10欧元， 转到我的账户余额 界面，检查我的余 额增加了10欧元。需要UML顺序图。 目前不需要考虑加 密的问题2察看明细108登录，点击“交 易”，存入一笔款 项。返回交易页面， 看到新的存款显示 在页面上。使用分页技术避免 大规模的数据库查 询。和查看用户列 表的设计相似。我们打算做点什么呢-编故事,定需求!什么是用户故事？什么是用户故事？用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包

6、 括三个要素： 1.角色：谁要使用这个功能。 2.活动：需要完成什么样的功能。3.商业价值：为什么需要这个功能，这个功能带来什么样的价值。Ron Jeffries的的3个个C关于用户故事，Ron Jeffries用3个C来描述它：卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写 上故事的简短描述，工作量估算等。交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负 责人的交流沟通。确认（Confirmation）- 通过验收测试确认用户故事被正确完成。我们打算做点什么呢-编故事,定需求!用户故事通常按照如下的格式来表达：用户故事通常按照如下的格式来表达

7、：英文： As a , I want to , so that . 中文： 作为一个, 我想要, 以便于举例：举例：作为一个网站管理员，我想要统计每天有多少人访问了我的网站 ，以便于我的赞助商了解我的网站会给他们带来什么收益。我们打算做点什么呢-编故事,定需求!用户故事的六个特性用户故事的六个特性- INVEST（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable ） 一个好的用户故事应该遵循INVEST原则。独立性（独立性（Independent） 要尽可能的让一个用户故事独立于其他的 用户故事。用户故

8、事之间的依赖使得制定计划，确定优先级，工作量估 算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减 少依赖性。可协商性（可协商性（Negotiable） 一个用户故事的内容要是可以协商的，用 户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描 述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡 带有了太多的细节，实际上限制了和用户的沟通。有价值（有价值（Valuable） 每个故事必须对客户具有价值（无论是用户还 是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一 旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商 的时候，他们将非常

9、乐意写下故事。我们打算做点什么呢-编故事,定需求!可以估算性（可以估算性（Estimable）开发团队需要去估计一个用户故事以便确 定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来 自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太 大了（这时需要把故事切分成小些的）。短小（短小（Small） 一个好的故事在工作量上要尽量短小，最好不要超过 10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完 成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。可测试性（可测试性（Testable）一个用户故事要是可以测试的，以便于确认 它是可以完成的。如

10、果一个用户故事不能够测试，那么你就无法知道它 什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使 用的。我们打算做点什么呢-编故事,定需求!划分用户故事：从客户角度来划分划分用户故事：从客户角度来划分具体可以分为：按照不同操作 - 添加、删除、修改、浏览等按照数据不同 - 可以浏览产品名和介绍、可以浏览产品价格按照特性 - 易用性、性能、兼容性、并发性等等按照角色 （从不同用户角度）按照投入的人力 - 比如要完成信用卡支付(Visa, Master, AmericanExperess)，可以分成三个故事来实现按照独立的功能我们打算做点什么呢-编故事,定需求!编故事的原则：编故事的原

11、则：给给Event 表表 添加一个索引添加一个索引提高在后台系提高在后台系 统中搜索并生统中搜索并生 成表单的响应成表单的响应 速度速度1.我们讲的是故事，不是实现方法！我们讲的是故事，不是实现方法！2.我们讲的是小故事！（翠西定律）我们讲的是小故事！（翠西定律）我们打算做点什么呢-编故事,定需求!用户故事1：作为一个经常使用手机的用户，我能够快 速给我的手机充电，因此我可以随时打电话。用户故事2：作为一个经常使用手机的用户，我希望我 的手机能够保持长时间在线，因此我可以随时打电话。超长待机时间，超过一个星期 多送一块电池 使用太阳能，核能 将人们活动时候机械动能转化为电能开会啦！-Sprin

12、t 计划会议冲刺（冲刺（Sprint） 计划会议的准备计划会议的准备 产品清单已经准备好了 每个故事都有自己的优先级或重要性评级了 想好怎么给大家讲述这些故事了：用卡片将每个故事写下来；在桌子上排好故事 准备好给大家投票用的工具: 20人*日/10人*日/5人*日/2人*日/1人*日 我们要在这个计划会议里干什么我们要在这个计划会议里干什么?产品经理介绍我们的故事-产品清单确立一个合适的sprint长度根据重要性高低为每个故事估计一个完成时间（人*日为单位）把选出的故事放入一个sprint 计划中并开始拆分每个故事得出 任务清单。制定sprint 目标：总得告诉点老板什么呀开会啦！-Sprin

13、t 计划会议Sprint 计划会议怎么开计划会议怎么开?充分讨论充分讨论：大家都要畅所欲言。大家要能积极参与来把故事拆分任务猪们，鸡们：开会啦！-Sprint 计划会议Sprint 计划会议怎么开计划会议怎么开?时间评估时间评估：投票要避免互相干扰。估算时间是要考虑投入度投入度因素和预留机动时间。70/20原则原则：员工投入度以70%为佳；20%左右的时间处理意外情况。开会啦！-Sprint 计划会议开会啦！-Sprint 计划会议一个典型的时间表一个典型的时间表这个日程不是绝对的。这个日程不是绝对的。Scrum masterScrum master根据会议进程的需要，可以对各个根据会议进程的

14、需要，可以对各个阶段的子进程时间安排进行调整。阶段的子进程时间安排进行调整。Sprint Sprint 计划会议：计划会议：13:00 13:00 17:00 17:00 （每小时休息（每小时休息5 5到到1010分钟）分钟） 13:00 13:00 14:0014:00产品负责人对sprint目标进行总体介绍，概括产品backlog。所有重要性高的backlog条目都要填写“如何演示” 14:10 14:10 15:3015:30团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。 15:40 15:40 16:3016:30团队选择要放

15、入sprint中的故事。 16:40 16:40 1717：0000为每日scrum会议（以下简称每日例会）安排固定的时间地点（如果和上次不同的话）。把故事进一步拆分成任务。团队名称团队名称: XXXXXX项目组项目组Sprint1 目标：目标： 完成计费系统部分存储过程优化和完成计费系统部分存储过程优化和CBS改造改造Sprint1 清单清单 （预计工作量）（预计工作量）:优先级优先级预估预估(man*day)Sprint Backlog1004银行卡渠道处理953充积分802充值赠送积分预计工作量总计预计工作量总计：73.5 man*day计划：计划： Sprint 周期： 2 weeks

16、 (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 MeetingEvery Day! 我们都要站在这: 15分钟!终于开工啦！- Daily MeetingEvery Day! 我们都要站在这干什么呢我们昨天做了什么我们今天要做什么有啥问题？15minutes什么是好的什么是好的Daily Meeting?1.Scrum Master不会逐个的问每个人问题，如果是，那么这个会议 已经沦为了报告会。2.团队成