《Scrum的敏捷实践与总结课件》由会员分享，可在线阅读，更多相关《Scrum的敏捷实践与总结课件（19页珍藏版）》请在金锄头文库上搜索。
1、敏捷宣言,人和交互重于过程和工具。 可以工作的软件重于求全责备的文档客户合作重于合同谈判随时应对变化重于循规蹈矩,成员彼此信任 人不求多，但求精干 开发人员具有技术权威性 拥有开放的工作环境，能自由沟通，两地团队基本上不适合使用敏捷开发,敏捷要以人为本,需求澄清 估算、排定计划 开发人员认领需求 头脑风暴 每日站立会，更新计划，更新燃烧图 每日ICP，UT，自动化测试 Show Case story 转测试 设计验证测试 Sprint回顾会议,开展敏捷,Scrum团队主要包含如下的角色，包括： Scrum Master 类似于项目经理 product own类似于客户 Scrum tem研发团
2、队 59个人为最佳的团队构成人数,团队组成,1、增量开发项目 2、需求变更非常频繁的项目 3、小型团队（建议10人以内） 4、一体化团队,适用项目,1、大型项目的基线开发 2、大型团队（沟通代价会很大） 3、对质量要求极高的项目 4、不能短期交付一个可以工作的产品的项目 5、异地团队,不适用项目,迭代周期其实是非常敏捷的 1、不建议超过6周 2、一般我们认为3周为宜 3、迭代周期是非常敏捷的甚至可以是一周 4、关键是如果确定了迭代周期以后不要随意的修改，也尽力不要在迭代周期内进行需求变更,迭代周期,计划纸牌能够极大的提高估算的速度，一次估算中如果两个人的估算之间相差过大，需要停下来澄清以后继续
3、进行在重新估算，但是如果相差比较小，则可以采用加权平均的办法。 估算的时候不由某一个人例如product master 来完成，应该由整个项目组共同完成 /首先应该知道项目组的真实的工作量，一般来说每一个人的每周的工作时长是40个小时但是这个可不是真实的工作量，一般来说项目成员的每天的真正的工作时长只能是5个小时。这样我们就能计算出项目组每周的真正的工作时长5*5*项目组成员数量（单独计算开发团队和测试团队因为他们的工作的目标和产品都不相同），从上面我们可以看出一个叫做负荷指标的指标：=5/8=60%这样也可以算出我们项目组，真实的总的工作时长。当遇到低的负荷指标的时候，需要找出原因。来提高效
4、率。 必须要为每一个细化的任务定义Done（结束）的标准 一般来说每一个任务应该控制在216个小时之间 对于细化的任务应该有开发人员如认领而不是分配。 如果估算的时候最高值和最低值之间相差一半以上的时候需要两个人沟通一下确认为什么会产生如此大的差距 如果项目组成员很多的时候可以采用分组讨论的方式，这样大家的参与效率都会很高。 乐观者赢：如果两个人的估算相差不大，则可以采用乐观者赢的方式,Scrum的任务分配与估算,1、参与人 Story相关的所有人员 2、时间 估算结束，所有相关人进行初步的分析以后，就可以进行。 3、要求 过程中产生的思想，所有人产生的思想不应该被否定。同时思想应该迅速记录下
5、来不管用什么方式，最终产生的决议迅速记录到JRIA，或者其他敏捷管理工具中,头脑风暴会议,Daily Scrum 站立会七个规则 大家应该站立围成一个圈，但是不能围坐在一起 而且来的最晚的人向大家报告工作进展的情况 所有成员汇报四个问题：1、上次立会后你做了什么；2、你负责的部分还有多少没有完成；3、在下次立会前你要做什么；4、你的开发被阻碍了么，如果没有更新工作量应该给出最新的估算 按照顺时针执行汇报，一般不能打断 每人汇报完成后有Scrum Master带领大家讨论 Scrum Master 宣布Daily Scrum结束 会后由Scrum Master/team Leader对每一个人反
6、映的障碍进行跟踪交流解决,Daily Scrum的七个规则,第一指导原则：主题明确不能掺杂其他无关的话题，主要回答4个问题 上次立会后你做了什么，不要过分详细， 你负责的部分还有多少没有完成，需要多少的工作量和时间，给出最新的估算，如果使用了敏捷的跟踪工具就可以省略这个步骤 在下次立会前你要做什么，给其他成员一个提示，可能中间有依赖关系 你的开发被阻碍了么，如果在这个时候讨论了技术细节，如果几句话的话就继续，如果全面的分析了就需要打断 站立会只能允许猪说话，鸡不能插嘴：只允许直接相关人说话，不能出现实质性的讨论，因为这样会浪费时间 大家应该站立围成一个圈，但是不能围坐在一起，站立暗示大家会议很
7、短，强迫大家注意力集中 确保每一个Scrum团队都参加会议 每日Scrum站立会议是交流会议，不是报告会议 每日的站立会议应该控制在15分钟以内 不要把站立会议作为一天的开始，一般在10：00到10：30之间开始最合适 Scrum站立会议应该在同一时间，同一地点开始 在大家汇报完成后可以有ScrumMaster 带领大家讨论。 在站立会议结束以后Scrum Master需要更新燃烧图（Sprint Burndown Chart）,Daily Scrum的八个指导原则,每日TCP持续集成是非常必要的 注意这里集成的代码应该是已经宣布转测试的Story代码 UT，自动化的代价很大建议按照项目需求确
8、定是否需要,每日ICP，UT，自动化测试,一个story开发进入一个可以展示的阶段的时候，可能还会有很多Bug没有解决。可以召集项目干系人，PM，客户，PL，TE，其他开发人员，向他们展示自己的作品。 好处： 1、通过show Case，可以及时的展示自己的工作产品是否符合需求，以期及早的调整开发方向，避免在代码集成，甚至交付的时候发现，工作产品偏离了预定的目标 2、通过show Case，让项目干系人给自己的作品提意见，更加完善开发产品 3、通过show Case，可以让自己及时的发现自己开发过程中的一些问题。,Show Case,Story开发完成前，测试人员应该完成测试用例并且抽取AT用
9、例，提交给开发人员 Story转测试前，开发人员需要先执行AT，全部通过以后可以宣布转测试 测试人员在接收到版本以后先执行AT用例，如果发现有不通过或者是部分不通过，可以根据项目进度选择Story打回或者是异常转测试,story 转测试,我们叫SDV测试 1、主要目的回归Story阶段的问题单 2、针对Story测试中的问题单集中区域进行重点测试 3、根据开发给出的测试建议制定重点测试区域,设计验证测试,一些思想和做法 让团队成员在总结的会议上展示自己的成果或者是作品、可以运行的软件 出席该会议的有，Product Own、开发团队、ScrumMaster，加上客户、项目管理者、高层、专家、以
10、及任何对此感兴趣的人 可以十分钟也可以一两个小时，,Sprint回顾，评审,在白板上写出主要的指导原则 在白板上画出至少三页纸连起来的时间轴 在白板上写出“我们的成功经验是什么” 在白板上写出“有什么可以改进” 在白板上写出由“谁负责”，然后分成两个区域 “团队”“公司” 但是Sprint回顾的会议最好由中立的者主持 /这个我还没有理解是为什么 每一个演示完成以后可以建议大家鼓掌为其庆祝 另外在一个Sprint开始的时候就要确定在Sprint结束的时候要演示哪些东西，同时要避免在演示的时候，有人强调理由，这些东西为什么没有完成，否则到了后期，这样的理由会泛滥成灾，强调我们重视的是可交付的版本。
11、 同时在会议中找到问题的所在是一个方面，重要的是我们要将问题分门别类，划分问题的“责任田”，并在后面的项目执行的过程中，加以改善。,Sprint回顾会议的流程,1、产品订单：（product backlog）这是项目所需要做的所有事情的高层次的列表，需要有优先级列表的，以使项目一直关注与最重要的事情上面 2、冲刺：（sprint）为了完成摸一个特定的目标的迭代，一般为两到四周。 3、冲刺订单：（sprint backlog） 来自于product backlog中的最高优先级的一部分的任务以及产生的附加的任务，每一个任务都应该有一个明确的结束（done）的定义 4、产品负责人（product own）负责维护产品订单和优先级。 每一次sprint结束以后都应该又一次回顾，从团队的角度审视下那些做得好，哪些还需要改进，而且每一次sprint结束后都应该重新调整产品订单，重新做计划，然后在开始下一个计划。,一些有用的概念,1、站立会变成讨论会 2、站立会汇报对象从整个团队变成PM 3、项目估算变成PM一个人的事情 4、过分轻视文档使得诸如数据库描述都会缺失 5、团队成员过于兴奋，作出超出自己能力的估算 6、sprint回顾会议变成批判会议 7、流程执行不彻底，最容易忽略的是Show Case，Story转测试把关 8、 其他想起来再说,非常容易犯的错误,
