90分钟掌握Scrum框架.pptx

1、【周金根】出品2011-049090分钟掌握分钟掌握ScrumScrum框架框架概 念5min角色5min流程20min任务15min建议30min讨论15min内部培训资料坏消息：我们的主要问题怎么写故事？什么是好的故事？故事的任务量怎么估算？周永丽1、Sprint任务估时不准，目前总结了一下原因：对OEA应用不熟悉OEA不稳定2、希望能了解我们产品到底为用户提供了什么价值，应用情况如何，用户做了哪些事情，方便我们下一步的改进李智任务估时问题，怎么估计才能准确？1.不是自己做的，替别人估任务不会很细致的去估，但新手由于对技术业务的不熟悉，自己又估计不了。2.估任务的时候不管是需求还是开发，都

2、有个潜在的假设-东方已经实现过了，这会造成两个现象：估时乐观、需求简略。3过度依赖原型？我感觉都没有一个正式的需求文档，界面依赖原型，业务呢来源于两个：口口相传以及老的代码敖勇刚我想对整体的Scrum流程进行一下了解，在实施Scrum中，每个过程或活动中的关键点是什么？贺丹丹主要是计划会议中，需要把他人任务的需求掌握到一个什么度的问题胡庆访测试开始时间太长，有的时候需要4天任务完成率（14）/（137）*100%=10.2%计算标准错误，对DoneDone的理解错误好消息：我们就要开始进入Scrum第2级流程价值观度量优化概念概念5min5min实验室和孵化产品的一些共性客户不知道他们想要什么

3、客户时常改变想法虽然不知道客户想要什么，但我们需要知道怎么得到它敏捷目的：频繁的交付可以工作的软件以前我们是这么做的出现了一些问题信息反馈不及时需求框架和接口缺陷信息丢失沟通成本高、效率低项目管理负担片面的考虑问题代码不能集成更好的工作环境提高产能更高质量的产品关注用户需求清晰地功能优先级更早和频繁的监控工作进展尽早交付价值低开发风险更好的用户满意度Scrum带来的好处没有银弹广联达对敏捷的理解核心思想：精益优秀的管理实践优秀的开发实践以人为本，持续优化以保证目标和客户价值为基础不断追求最佳的投入产出比角色角色5min5min团队角色的转变客户、涉众Scrum团队开发团队ScrumMaster

4、产品负责人Scrum角色产品负责人=去哪开发团队=引擎ScrumMaster=技工协作寻宝建立愿景确认小组所有成员都在追求一个共同的项目愿景定义产品路标确定大的功能以及客户价值确定需求生成故事描述维护Backlog确定功能优先级，确保对即将开始的迭代故事进行了足够的细化客户验收让客户使用产品提供反馈吸引涉众参与让每一个对产品相关的人参与进来计划确定交付日期，跟踪进度协调外部资源从外部获得任何团队需要的资源产品负责人职责产品负责人要做的与不要做的要做的不要做的做什么如何做挑战团队恐吓团队承诺建立高绩效团队只关注短期团队交付业务价值驱动思考计划驱动思考在sprint之间考虑变更允许在sprint期

5、间蔓延变更确保流程的贯彻执行对如何执行上达成一致，保障团队一致的执行流程找到并去除障碍找到任何妨碍团队绩效的障碍，并去除这些障碍保证内部沟通的顺畅确保团队沟通舒畅、高效维持工作环境防止团队遭受外部打扰，保护团队专注，确保团队保持工作节奏团队提高确保团队的人是适合的人，在团队中进行跨技能培训。通过激发创造性与推动授权来提升开发团队的成员 ScrumMaster职责协作具有不同特长的团队成员（人数控制在 7个左右），团队形成高度的自我管理能力，在一起协作，保持节奏的实现本期 Sprint目标维护架构保障架构的稳定性和持续性掌握需求团队有责任明白客户的需求保证代码质量通过模式、代码标准、持续集成、配

6、置管理等保证代码质量设计方案决定如何编写代码实现需求，包括单元测试和自动化测试开发团队职责DoneDone1.Codeditworksonthedevelopersbox2.VerifiedUnittestedandtheyworkonIntegrationbox3.ValidatedacceptedbyProductOwnerasbeingwhatwasneeded4.ProductionReadyalladditionalstuffwasthere,likedocumentation,trainingforusers软件生成活动检查列表主要的报告范围现实的一种反馈例如：客户职责协作与PO合

7、作，积极参与需求确定、优先级排定工作提供资金为项目提供资金或购买软件反馈每期迭代提供产品的反馈，保证沟通及时、准确和有效性所有人都应有的职责从外部学习明白其他人是如何解决你面临的问题。从多种知识体系去学习，把外部知识应用到自己的团队中来对承诺的兑现Sprint会议、站立会议都是对他人的承诺，信守承诺是基本的做人准则风险管理通过小的尝试、快速反馈、早期学习和团队共享观点等来关注交付价值过程中的风险个人成长每个人都应对自己的成长复杂，硬技能和软技能的不断提高团队发展五阶段局限性该模型是用来描述小型团队的。实际上，团队发展轨迹不一定象Tuckman的描述是线形的，而有可能是循环式的。该模型描述的阶段

8、特征并不可靠，因为它主要考量的是人的行为，而当团队从一个阶段跨向另一个阶段的时候，团队成员的行为特征变化并不明显。它们也很有可能会发生交叠。模型没有考虑到团队成员的个人角色特征。在阶段发展跨越上没有给出时间框架指导，这是一个主客观相结合的模型组建期项目团队：刚刚组建，确定团队成员的相互关系。团队成员：行为具有相当大的独立性，成员只不过是单独的集合体，不清楚他们的角色和责任是什么。团队领导：指挥或“告知”式领导。在带领团队的过程中，要确保团队成员之间建立起一种互信的工作关系。与团队成员分享团队发展阶段的概念，达成共识。组建期：启蒙阶段激荡期激荡期：形成各种观念，激烈竞争、碰撞的局面 项目团队：获

9、取团队发展的信心，但是存在人际冲突、分化的问题。团队成员：面对其他成员的观点、见解，更想要展现个人性格特征。对于团队目标、期望、角色以及责任的不满和挫折感被表露出来。团队领导：教练式领导。指引项目团队度过激荡转型期，强调团队成员的差异，相互包容。规范期规范期：规则，价值，行为，方法，工具均已建立。项目团队：效能提高，团队开始形成自己的工作约定。团队成员：调节自己的行为，以使得团队发展更加自然、流畅，有意识地解决问题，实现组织和谐。团队领导：参与式领导。允许团队有更大的自治性。执行期执行期：人际结构成为执行任务活动的工具，团队角色更为灵活和功能化，团队能量积聚于一体。项目团队：运作如一个整体。工

10、作顺利、高效完成，没有任何冲突，不需要外部监督。团队成员：对于任务层面的工作职责有清晰的理解。没有监督，自治，即便在没有监督的情况下自己也能做出决策。随处可见“我能做”的积极工作态度，互助协作。团队领导：委任式领导。让团队自己执行必要的决策。休整期休整期：任务完成，团队解散。流程流程20min20min增量功能高优先级发布Backlog(粗粒度功能)迭代Backlog(细粒度功能/任务)发布、迭代规划3-6个月2-4周每日发布规划Sprint1Sprint2Sprint3-620points18points79pointssprint计划故事任务故事A5故事点故事B3故事点确定规则1编写类库4

11、任务11设计UI1自动化测试2任务23Scrum流程团队日历12345678910站立会议站立会议站立会议站立会议站立会议站立会议站立会议站立会议计划会议故事计划会议任务演示会议回顾会议看板流程演示Product BacklogProduct Backlog团队承诺计划会议Sprint计划会议PlanningMeetingSprintBacklogSprint计划会议优先级1优先级2优先级3开发团队PO这是最重要的。Sprint计划会议开发团队优先级2优先级1优先级3PO这是最简单的开发团队Sprint计划会议ScrumMaster我们把这个故事点定为3SPO开发团队Sprint计划会议优先级

12、2优先级1优先级3358我们的产品API工作前端工作数据库工作技术视角技术视角数据库工作API工作前端工作用户视角功能1功能2功能3用户视角根据价值选择故事UserStory1UserStory2根据价值选择故事UserStory1UserStory2根据价值选择故事UserStory1UserStory2根据价值选择故事UserStory2.1UserStory2.2UserStory2UserStory1用户视角大故事拆分UserStory1UserStory2.1UserStory2.2大故事拆分UserStory1UserStory2.1产品 BacklogSprint Backlog

13、UserStory2.2挑选故事SPO看板站立会议ScrumMasterScrumMasterSPO看板3站立会议1.你昨天现了什么？你做得如何？2.你今天要实现什么？3.你工作中有什么障碍？SPO看板3站立会议我们我们我们我们目的只看着一个人，做成汇报形式了只说what，不说whatabout（做的怎么样？）不注意倾听，开小会需要有人叫才姗姗来迟迟到站会问题更好的协调关注少量重要请每日承诺移除障碍站会目的计划会议问题成为需求讨论会sprint目标不明晰需求价值不突出开发人员对业务重视度不够测试对业务了解不够知道工作(明白、选择、任务、自愿)明白搞业务价值产品backlog的范围和大小选择本期

14、sprint适合做的生成任务自愿挑选任务一个新的开始承诺大家共有的目标计划会议目的回顾会议的问题改进项太多，没有落地效率不高适应和调整关注“怎么做”，而不是“做了什么”确定下次改进项回顾会议的目的任务任务15min15min写故事：INVESTIndependent独立Negotiable可协商的：捕获本质，而非细节Valuable有价值的：必须关心用户的价值Estimable可评估的Small小的Testable可测试的 如何沟通故事用户故事开发人员产品负责人普遍存在的问题：功能考虑的很多优先级都高对每个功能的描述也很详尽，但更多考虑自身，缺少全局体系的思考增量我们必须实现所有的“必要性”功

15、能，否则我们的软件是无法体现出价值的。前期sprint完成“必要性”功能之后的每个版本中，细化功能迭代迭代就是在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程；而增量，则是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。拆分故事故事拆任务：SMART建议建议30min30min选择迭代长度考虑的因素发布时间越短迭代时间越短，至少4-5次获得反馈、度量改进和调整开发路线的机会不确定性越多，迭代就应该越短获得公司内外反馈所具有的价值最大化迭代中不改变承诺的目标方向，实现新想法的平均时间是迭代时间长度的1.5倍迭代的系统开销，例如回归测试成本让团队产生有交付产品的紧迫感和创造性迭代长度建议2周的长度比较理想1周会匆忙紧迫，不易处理突发事件，除非已经具备自动化测试的能力4周的紧迫感会弱一些，但比较短迭代可以有更多时间来研究和追寻有创造性的方案6次2周迭代后加1周迭代处理技术负债 6*2+1讨论讨论15min15min周金根敏捷个人新浪微群谢谢!以保证目标和客户价值为基础不断追求最佳的投入产出比敏捷团队 承诺、专注、公开、敬重、勇气