Scrum文档格式.docx
《Scrum文档格式.docx》由会员分享，可在线阅读，更多相关《Scrum文档格式.docx（26页珍藏版）》请在冰点文库上搜索。
一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。
在为内部产品的公司中，负责批准项目预算的人就是客户。
Scrum中的产出物
ProductBacklog——Backlog待开发项，积压的任务。
产品Backlog包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个Backlog的优先级是可以调整的，需求是可以增减的，因此产品Backlog将根据不断增长来持续驱动维护。
SprintBacklog——Sprint本意为“冲刺”，指迭代周期，长度通常是一至六周。
在Sprint开始前，定义本次Sprint要讨论的“SprintBacklog”，从中产生本次Sprint要完成的“已定ProductBacklog”。
已定ProductBacklog
Sprint计划会议的产物，它定义了团队所接受的工作量，在整个Sprint过程中它将保持不变。
UserStory、Task——用户故事、任务
用UserStory来描述SprintBacklog里的项目，UserStory是从用户的角度对系统的某个功能模块所作的简短描述。
一个UserStory描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。
一个UserStory的大小和复杂度应该以能在一个Sprint中完成为宜。
如果UserStory太大，可能会导致对它的开发横跨几个Sprint，此时就应该将这个UserStory分解。
为了能够及时，高效地完成每个Story，Scrum团队会把每个Story分解成若干个Task。
每个Task的时间最好不要超过8小时，保证在1个工作日内完成，如果Task的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。
障碍Backlog——问题列表，积压的待处理事务。
列举了所有团队内部和团队相关的和阻碍项目的进度的问题，ScrumMaster需要确保所有的障碍Backlog中的问题都已分配并可以得到解决。
通用会议规则
基本要求
∙每次会议都要准时开始、准时结束。
∙每次会议都采取开放形式，所有人都可以参加。
会前准备
∙提前邀请所有必须参会的人，让他们有时间准备。
∙发送带有会议目标和意图的会议纲要。
∙预订会议所需的全部资源：
房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
∙会前24小时发送提醒。
∙准备带有会议规则的挂图。
会议推进
∙展开讨论时，会议的推进人必须在场。
他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
∙推进人展示会议的目标和意图。
∙有必要时，推进人可以商定由某个撰写会议记录。
∙推进人可以记录团队的意见，或是教授团队如何自己记录文档；
而且推进人可能会在挂图上进行记录，将对话可视化。
∙推进人会对会议进行收尾，并进行非常简短的回顾。
会议输出
∙使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。
∙必须传达会议记录和大家对会议结果的明确共同认知。
让团队坐在一起！
∙大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！
∙互相听到：
所有人都可以彼此交谈，不必大声喊，不必离开座位。
∙互相看到：
所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
∙隔离：
如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。
团队建设
∙Scrum团队最佳人数控制在“5～9”人。
∙全职能性团队：
开发组（后台开发、前端开发、测试人员——3~8人）、ScrumMaster（项目经理）、产品负责人
∙兼职团队成员：
美工、DBA、运维
每日立会（DailyStandupMeeting）——建议下班前开始
会议目的
∙团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
∙任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。
构成部分
∙任务板、即时贴、马克笔
∙提示：
ScrumMaster不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。
∙成员：
团队、ScrumMaster
∙无法出席的团队成员要由同伴代表。
∙持续时间/举办地点：
每天15分钟，同样时间，同样地点。
团队成员在聆听他人发言时，都应该想这个问题：
“我该怎么帮他做得更快？
”
∙团队彼此明确知道各自的工作，最新的工作进度图。
∙得到最新的“障碍Backlog”
∙得到最新的“SprintBacklog”
会议过程
∙团队聚在故事板旁边，可以围成环形。
∙从左边第一个开始，向团队伙伴说明他到现在完成的工作。
∙然后该成员将任务板上的任务放到正确的列中。
∙如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。
∙如果该成员遇到问题或障碍，就要将其报告给ScrumMaster。
∙每个团队成员重复步骤2到步骤5。
每个人三个问题：
∙上次会议时的任务哪些已经完成？
：
把任务从“正在处理”状态转为“已完成”状态。
——今天完成了什么？
∙下次会议之前，你计划完成什么任务？
如果任务状态为“待处理”，转为“正在处理”状态。
如果任务不在SprintBacklog上，则添加这个任务。
如果任务不能在一天成，把这任务细分成多个任务。
如果任务可以在一天内完成，把任务状态设为“正在处理”。
如果任务状态已经是“正在处理”，询问是否存在阻碍任务完成得问题。
——明天做什么？
∙有什么问题阻碍了你的开发？
如果有阻碍你的开发进度的问题，把该障碍加入到障碍Backlog中。
——今天遇到了什么问题？
注意事项
∙不要迟到
∙不要超出限制时间
∙不要讨论技术问题
∙不要转变会议话题
∙不要在没有准备的情况下参加
∙ScrumMaster不要替团队成员移动任务卡片，不要替团队更新燃尽图。
∙ScrumMaster不要提出问题，团队成员不要向ScrumMaster或管理层人员报告。
∙如果不能出席会议，需要通知团队，并找一名代表参加。
任务板
∙任务板集合了选择好的ProductBacklog和SprintBacklog，并以可视化方式展示。
∙任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
∙尽量使用大白板，也可以使用软件。
任务板有4列：
∙选择好的ProductBacklog：
按照优先级，将团队在当前Sprint中要着手的ProductBacklog条目或是故事放在该列中。
∙待完成的任务：
要完成一个故事，你得完成一些任务。
在Sprint规划会议中，或是在进行当前Sprint中，收集所有特定Backlog条目需要完成的新任务，并将它们放入该列。
∙进行中的工作：
当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。
从上个每日Scrum例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。
如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小的部分，然后把新任务放到那一列，移除其所属大任务卡片。
如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，ScrumMaster就会记下一个障碍。
∙完成：
当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡。
燃尽图（BurnDownChart）
∙跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint的总时间，纵轴表示Sprint中所有的任务，其单位可以是小时，人天等。
一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
∙团队每天更新燃尽图。
∙如果燃尽图一直是上升状态，或当Sprint进行一段时间之后，Sprint燃尽图上的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的Story过多，要拿掉一些Story以保证这个Sprint能顺利完成。
如果Sprint燃尽图下降得很快，例如Sprint刚过半时Y值已经接近0了，则说明这个Sprint分配的任务太少，还要多加一些任务进来。
在Sprint计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。
（锻炼团队人员的自我估算时间）
∙燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。
Release燃尽图：
记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint，纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story的数量），人天等。
Sprint规划会议——第一部分（上午）
∙该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。
在会议的结束，团队将会决定他们能够交付哪些东西。
∙产品负责人在会前准备：
条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。
会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。
∙迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
∙只有团队成员才能决定团队在当前Sprint中能够领取多少个Backlog条目的工作。
构成部分：
∙经过估算和排序的ProductBacklog。
∙挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
∙假期计划表、重要人员的详细联系信息。
∙参会成员：
团队成员、ScrumMaster、产品负责人
持续时间：
在Sprint中，每周该会议占用时间为60分钟，在早上召开该会议，这样还有可能在同一天召开Sprint规划会议的第二部分。
∙选择好的ProductBacklog条目。
∙各个Backlog条目的需求。
∙各个Backlog条目的用户验收测试。
∙从第一个ProductBacklog条目（故事）开始。
∙讨论该ProductBacklog条目，以深入理解。
∙分析、明确用户验收测试。
∙找到非功能性需求（性能、稳定性...）
∙找到验收条件。
∙弄清楚需要“完成”到何种水平。
∙获得Backlog条目各个方面的清晰了解。
∙绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕UI设计等。
∙回到步骤1，选取下一个Backlog条目。
流程检查：
询问团队能否快速回答下列问题，只需要简要回答即可：
“我们能在这个Sprint中完成第一个Backlog条目吗？
”如果能得到肯定的回答，那么继续询问下一个Backlog条目，一直到已经分析完的最后一个Backlog条目。
——接下来，休息一下。
在休息后，对下一个Backlog条目展开上述流程。
结束流程：
∙在Sprint规划会议第一部分结束前留出20分钟。
∙再次提问——这次要更加严肃、正式：
“你们能否完成第一个Backlog条目，...第二个，...？
∙如果团队认为他们不能再接受更多的Backlog条目，那就停下来。
∙现在是非常重要的一步：
送走ProductOwner，除了团队和ScrumMaster之外的所有人，都得离开。
∙当其他人都离开后，再询问团队：
“说真的——你们相信自己可以完成这个列表？
∙希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
∙将结果与ProductOwner和最终用户沟通。
注意事项：
不要改变Backlog条目大小，不要估算任务。
Sprint规划会议——第二部分（下午）
∙该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前Sprint中要开发的功能。
∙只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。
∙能够帮助团队在该Sprint中构建解决方案的人，比如厂商或是来自其他团队的人员。
∙挂图......
不要估算任务，不要分配任务。
∙应用设计、架构设计图、相关图表
∙确保团队知道应该如何完成任务！
∙从第一个Backlog条目开始。
∙查看挂图，确定对于客户的需求理解正确。
∙围绕该Backlog条目进行设计，并基于下列类似问题：
o我们需要编写什么样的接口？
o我们需要创建什么样的架构？
o我们需要更新哪些表？
o我们需要更新或是编写哪些组件？
o......
当团队明确知道自己应该如何开发该功能后，就可以转向下一个Backlog条目了。
在会议的最后10分钟，团队成员使用即时贴写出初步的任务。
这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。
在Sprint规划会议第一部分完成后，召开该会议。
可以将午餐作为两次会议的一个更长久的休息。
但是要在同一天完成Sprint规划第一部分，在Sprint中，每周该会议占用时间为60分钟。
估算会议——根据项目情况合并到Sprint第二部分会议
∙要做好战略规划，你需要知道Backlog中各项的大小，这是版本规划的必要输入；
如果想知道团队在一个Sprint中能够完成多少工作，这个数据也是必须的。
∙团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。
∙只有团队才能作估算，ProductOwner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。
∙ProductOwner根据业务价值排定ProductBacklog各项顺序。
∙需要参加的人员：
Team、ProductOwner、User、ScrumMaster
∙不要估算工作量大小——只有团队能这么做。
∙ProductOwner不参与估算。
∙ProdcutOwner展示她希望得到估算的ProductBacklog条目。
∙团队使用规划扑克来估算Backlog条目。
∙如果某个Backlog条目过大，需要放到下一个或是后续的Sprint中，团队就会将该大Backlog条目划分为较小的几个Backlog条目，并对新的Backlog条目使用规划扑克进行估算。
∙重新估算Backlog中当前没有完成、但是可能会在接下来三个Sprint中要完成的条目。
该会议时间限制为不超过90分钟。
如果Sprint持续时间长于一周，那么每个Sprint举行两次估算会议比较合适。
∙经过估算的ProductBacklog。
∙更小的Backlog条目。
扑克牌估算（PlanningPoker）
具体步骤：
∙每个人各自估算后独立出暗牌，听口令一起开牌。
∙数值最大者与最小者PK，其他人旁听也可参考。
∙讨论结束后重新出牌和开牌。
∙重复上述过程，直到结果比较接近。
常见问题
1、为什么任务要分给组而不是个人？
答：
因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。
2、为什么不让最后领任务的人自己估算？
因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。
3、为什么不让师傅估算大家采纳，他不是最厉害吗？
师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
Sprint评审会议（ReviewMeeting）——根据项目需要举行
∙Scrum团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更Backlog条目。
∙Sprint复审会议允许所有的参与者尝试由团队展示的新功能。
∙有可能发布的产品增量，由团队展示。
∙来自最终用户的反馈。
∙障碍Backlog的输入。
∙团队Backlog的输入。
∙来自团队的反馈为ProductBacklog产生输入。
90分钟，在Sprint结束时进行。
∙ProductOwner欢迎大家来参加Sprint复审会议。
∙ProductOwner提醒大家关于本次Sprint的目的：
Sprint目标、Scrum团队在本次Sprint中选定要开发的故事。
∙产品开发团队展示新功能，并让最终用户尝试新功能。
∙ScrumMaster推进会议进程。
∙最终用户的反馈将会由ProductOwner和/或ScrumMaster记录在案。
∙不要展示不可能发布的产品增量。
∙ScrumMaster不要负责展示结果。
∙团队不要针对ProductOwner展示。
∙Sprint反思会议（RetrospectiveMeetin）——根据项目需要举行
∙该会议的对应隐喻：
医疗诊断！
其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。
∙参与人员：
团队成员、ScrumMaster
∙从过去中学习，指导将来。
∙改进团队的生产力。
∙不要让管理层人员参与会议。
∙不要在团队之外讨论找到的东西。
90分钟，在Sprint评审会议结束后几分钟开始。
∙准备一个写着“过去哪些做的不错？
”的挂图。
∙准备一个写着“哪些应该改进？
∙绘制一条带有开始和结束日期的时间线。
∙给每个团队成员发放一叠即时贴。
∙开始回顾。
∙做一个安全练习。
∙收集事实：
发放即时贴，用之构成一条时间线。
每个团队成员（包括ScrumMaster）在每张即时贴上写上一个重要的事件。
∙“过去哪些做的不错？
”：
采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。
∙做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。
∙“哪些应该改进？
像“过去哪些做的不错”那样进行。
∙现在将即时贴分组：
∙我们能做什么》团队Backlog的输入。
∙哪些不在我们掌控之内？
》障碍Backlog的输入。
∙根据团队成员的意见对两个列表排序。
∙将这两个列表作为下个Sprint的
升级会员 