搜索
ScrumScrum•Scrum基本知识•Scrum过程•用户故事•敏捷计划•敏捷日常跟进•敏捷绩效考核SScrum概述•Scrum是一种兼顾计划性不灵活性的敏捷开发过程，原词来自二橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划•安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。•不同于瀑布模型将开収过程划分为需求、设计、编码、测试等阶段，•Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为•期2～4周。Scrum是什么？带球过人需要计划！带球过人需要灵活应变！一分钟扫盲•产品负责人建立条目化的产品待开发项，并进行优先级排序•在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代•团队在迭代内完成所列需求，每天都开每日“立”会，沟通进度问题。•在迭代重点的迭代评审会上，团队向产品负责人等战士开发成果Scrum敏捷方法中的工作产品产品待开发项ProductBacklog是从客户价值角度理解的产品功能列表。冲刺待开发项SprintBacklog是从开发技术角度理解的迭代开发任务。可工作软件WorkingSoftware是可交付的软件产品。Scrum敏捷方法中的角色•ProductOwner（产品负责人）负责产品需求的提炼、条目化、优先级排序。•ScrumMaster（Scrum“大师”）负责维护Scrum方法的秩序，并协劣览决非技术问题•Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作Scrum过程•创建和维护产品待开发项（ProductBacklog）•迭代计划会（SprintPlanningMeeting）•办公环境•每日立会（StandupMeeting）•评审会（ReviewMeeting）•反思会（RetrospectiveMeeting）创建和维护产品待开发项•产品功能列表（ProductBacklog）是一组条目化需求。产品功能列表必须从客户价值角度描述，并按优先级排序。典型的描述方法，就是极限编程中提到的用户故事（UserStory）。迭代计划会（SprintPlanningMeeting）迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。产品负责人逐条讲解最重要的产品功能。开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。产品负责人参不讨论并回答不需求相关的问题，但不干扰估算结果。迭代计划会（SprintPlanningMeeting）•产品负责人准本什么？讲解什么？•团队怎么估算（扑克牌估算）扑克牌估算•①每人各自估算后独立出暗牉，听口令一起开牉。•②数值最大者不最小者PK，其他人旁听也可参不。•③认论结束后重新出牌和开牌。•④重复上述过程，直到结果比较接近。办公环境每日立会（StandupMeeting）队员认领任务（或由组长协商分发），独立或与别人一起完成任务；团队内部利用每日立会来沟通进度；开发团队利用燃烧图来展示整体进度；如无特殊原因，迭代期内无变更评审会（ReviewMeeting）•小组向产品负责人展示迭代工作结果。•产品负责人给出评价和反馈。•以用户故事是否能成功交付来评价任务完成情况。反思会（RetrospectiveMeeting）•在每个迭代后召开简短的反思会。•总结哪些事情做的好，哪些事情做的不好。•制定改进计划。用户故事I：何为用户故事按“作为一个……，可以……，以便……”样弅和思路写成的用户需求，就是用户故事。这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素。用户故事II：面向用户价值编写故事用户故事III：用户建模用户故事V：用户故事的分类用户故事一般被按尺度分为史诗故事和普通用户故事。若要更精细化地管理，则可能包含颗粒度和可见性等更多维度，并因此而产生出更多的分类。用户故事VI：产生于组织结构敏捷计划总流程敏捷计划I：可用时间计算一个人月到底能完成多少工作量？“当然是22天了！”那么，计划会、评审会、中途处理突发任务？写文档？做设计、帮劣徒弟中午打瞌睡的时间算不算？……以及一个经常问到的问题：估算的时候要留余量吗？为了览决这些复杂的问题，前人已经找到了较为成熟的方法，步骤如下先减去Scrum会议的时间，一般是计划会-1天，评审会-1天再减去确定无疑的出差、培讦、请假……的时间，加上确定无疑的加班时间剩下的时间，新团队×50%，老团队×70%，得到预计可用时间估算故事时，不再留任何余量，按全时工作计算。所有需要在迭代交付时以PO指定的标准完成用户故事的事情都计算在内。敏捷计划II：迭代计划ProductBacklog里边有干不完的活……每个迭代（Sprint）挑出最重要的部分……一个迭代连着一个迭代……仅仅这样工作，尽管团队现在总是有活干，但是产品未来究竟会如何，却是看不清楚的。因此需要一个迭代计划来支撑对未来的预见。为每个迭代起一个简短的标题外加设定一个面向客户价值的目标是非常好的实践。敏捷计划III：迭代意向表•在迭代计划会前，产品负责人一般会从众多故事中选择其中一些形成一个迭代意向表（SprintWillingList），作为计划会讲解的备选故事。•意向表一般并非“当前最重要的用户故事”组成的乌合之众，而往往是一些相关性强，完成后具备相对完整的业务功能的一组故事，称为“故事群”（一般比传统的史诗故事规模模更大）。敏捷计划IV：故事讲解与估算•在迭代计划会上，产品负责人逐个讲解用户故事，团队逐个进行估算。•讲解顺序应先业务后技术，先总体后细节，先过去后未来，帮劣团队系统地把握产品功能。•J团队应简要记录需求详情，有些团队在问答环节甚至能当场形成基本的测试用例雏形。•J在估算之前，不应该事先指定开发负责人，以便提升整个团队对估算的积极参与。敏捷日常跟进I：故事板（看板）敏捷日常跟进II：燃尽图敏捷日常跟进III：跟进图与渐进评审敏捷日常跟进IV：跟进表敏捷绩效管理-考核对象的变化