关于Scrum的学习和总结

   敏捷开发，在大学的时候就接触过，但是一直以来，很少有应用到。不过今年准备参加软考系统架构设计师，买了希赛网的教程，里面有一个章节就是讲敏捷开发方法的，总体学习下来，觉得敏捷开发中的Scrum比较实用，所以也借这个机会，整理一下思路，巩固一下最近这段时间的学习。

敏捷软件开发宣言

The Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Scrum简介

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，我们陈这个迭代周期为一个Sprint（冲刺），每一个Sprint的建议长度为2~4个星期（如果产品迭代比较快，可以采用1周一个迭代的节奏）。每个迭代结束之后，Scrum团队就可以递交一个可交付的产品增量。Scrum的基本流程如图：

Scrum的基本流程

Scrum的5个活动

Scrum包含5个活动：Product Backlog梳理、Sprint计划会议、每日站立晨会、Sprint评审会议、Sprint回顾会议等。

• 1、Product Backlog梳理
  Product Backlog是由用户故事（UserStory）组成，它是一个按照优先级排好序的需求列表，整个需求列表非常庞大，用户的优先级时常会根据市场情况等进行变化，需求也会发生变更，Product Backlog也是随着项目的推进而不断在变化的，所以，Product Backlog的梳理，是贯穿于整个Scrum项目的活动的。在这个活动中，我们需要不断地对Product Backlog中的UserStory进行升级、降级、移除（有些需求可能不再重要或者不再需要了）、增加、分解或归并，并对相关事项进行估算。因为Product Backlog涉及到需求以及后续的设计评估，所以整个项目组的成员都需要参加，主要由产品负责人把控。在进行Product Backlog梳理的过程中，我们可以很好的预估一下整个项目需要拆分成多少个Sprint，这为后续的计划做了一个很好的铺垫。

• 2、Sprint计划会议
  在开始一个Sprint之前，我们都会召开一次Sprint计划会议，会议一般保持在2个小时之内。主要讨论这次Sprint需要做完成哪些需求开发，以及如何去实现这些需求。决定本次迭代完成哪些内容，是由项目的产品负责人（PO）进行把控的，确立本次Sprint的目标，而如何设计去实现这些功能，是有开发团队进行把控，一般情况下，开发团队会将前几天的工作进行分解，每个工作单元不超过一天的时间，之后需要完成的开发任务可以稍微大一些，后续可以进行持续分解。
  总而言之，Sprint计划会议旨在讨论并决定本次迭代需要完成的任务，而且这个任务是可实现的，项目的全体人员都非常有信心完成这个目标，这点非常重要。所以，这次会议也要求让所有项目成员都彻底了解Sprint的每一个需求。会议的最终输出是从Product Backlog中挑选出的一些优先级高且能够在规定时间内完成的待办，我们称之为Sprint Backlog。

• 3、每日站立晨会
  说到每日晨会，主要是应用于开发团队中的，其实在工作之初我就用到了，效果确实很不错。基本上就是开发团队的成员围成一圈，相互之间都可以看到每一个人，每个人对着工作面板（Sprint Workboard），讲述自己昨天已完成的开发项（一般情况下，我们会将开发的每个开发项写到一个小贴纸上，可以在贴纸上面写上开发人员的名字，也可以在工作面板的左边第一行上写上每一个开发人员的名字，如图），并讲述自己当天计划完成的开发项，及时更新工作面板。最后一项就是开发人员可以讲述一些今天工作中可能遇到的问题或者存在的风险，一般站立晨会上面不会进行展开讨论，会在晨会结束之后另外组织专题会议进行讨论。
  

  站立晨会-Sprint Workboard

总体来说，站立晨会让每个开发人员了解到项目组其他开发人员的工作情况，一方面可以达到互相监督、促进的积极作用，另一方面也为开发人员提供了一个更轻便的沟通途径，提高开发之间的沟通互动。一般情况下，每日的站立晨会时长建议保持在15min以内，也可以让开发人员轮流主持，这样可以更充分地调动开发人员的主动性。

• 4、Sprint评审会议
  在每个Sprint完成之后，项目团队就会产生一个可交付的产品增量，这个时候就会组织进行一次Sprint评审会议，主要是针对该产品增量进行演示，产品负责人以及相关测试人员、开发人员都必须在场。项目经理在会议上对整个项目的进度进行总结，根据演示的结果，以及需求的变化等进行Product Backlog更新，会议时间建议控制在1至2个小时内。

• 5、Sprint回顾会议
  Sprint回顾会议是在Sprint的所有工作项完成之后举行的，主要针对本次Sprint开发进程中，项目团队协作存在的问题进行总结，讨论项目中是否存在工具使用等问题，哪些地方做得好，哪些地方做得不好，以及未来需要改进的地方，并列出具体的修改计划，将相关遗留项整理进Product Backlog。

最后，总结一下个人的一些使用体验。通过上面的介绍，我们知道Scrum是由这五个活动环环相扣组成，但在实际应用中并不是说一定要严格按照这个流程执行，也可以根据项目的情况进行动态调整，例如可以去掉Sprint评审会议，或者将评审会议和回顾会议合在一。另外，见过很多项目，都是单纯因为敏捷而敏捷，并不考虑项目是否适合使用敏捷开发方法，所以，建议在执行敏捷开发方法之前，先对考虑一下项目组的情况是否适合使用敏捷开发，而且在实施敏捷开发之前，必须和项目组的所有成员提前做好沟通，因为只有项目组所有成员都乐于执行敏捷，体会到敏捷的精神和真谛，敏捷开发才能发挥出它应有的效果。

PS：附上自己整理思路画的一个关于Scrum的图，帮助大家理解。 Scrum个人板书