Scrum敏捷开发实战分享（上篇）：方法介绍、敏捷团队和敏捷流程

一、方法介绍

先从一则故事说起：

 

一天，一头猪和一只鸡在路上散步 

鸡对猪说：“嘿，伙计，我们合伙开一家餐馆怎么样？” 

猪看了一下鸡说：“好主意，那我们给它取什么名字呢？” 

鸡想了想说：“叫‘火腿和鸡蛋’怎么样？” 

猪说：“那不行，我要全身投入，而你只是参与而已。”

这是在Scrum推出的系列故事中最有代表性的一个故事，它向我们展示了两种角色：猪和鸡。

在敏捷开发中，Scrum是一种增量迭代式的开发过程，它包含了一系列的实践和角色定义的过程骨架；

主要角色包括产品负责人（Product Owner即PO）、敏捷教练（Scrum Master即SM）、开发团队成员等，他们在项目中承担实际工作，是Scrum团队中的核心成员，扮演着“猪”类的角色，是必须要全身心投入的；而用户、客户、老板们则代表着“鸡”类角色，他们是项目的需求方和参与者，不会为项目跟进的结果负责，但他们对产品的意见至关重要，因此也必须考虑到他们，这就要求PO和SM必须处理好两种角色的关系，这在实际操作中是最难的一个环节。

在正式介绍Scrum之前，我们先说下传统开发和敏捷开发的对比。

1.传统开发

传统的软件开发采用的是瀑布式开发流程，它把整个开发过程分成了需求、设计、编码、测试、发布等阶段，只有前面阶段达成后再进入下一个阶段，整个过程按照事先制定的计划前进。

这种预定计划的方法，带来的问题也是显而易见的，每个阶段之间都有强烈的依赖关系，前一个阶段被视为后一个阶段的输入，如果输入的质量不高则会严重影响后续阶段的输出质量，随即带来后续一些列阶段的停滞，最终导致开发周期拉长项目延期，甚至以失败告终；

我们的市场需求瞬息万变，很难实现产品需求明确完整的收集，项目早期的承诺也导致对后期需求的变化难以调整、代价高昂。

同时，技术的发展也日新月异，对于所定义的功能可能实现也面临着多重不确定性的因素，所以从需求的明确性和功能实现的确定性两个维度出发，当需求的不明确性和功能实现的不确定性均超出一定范围之后，呈现出复杂系统的特征，瀑布式开发这种结构化的方法便不再适用，而敏捷开发方法便是在这样的背景下诞生。

 

Fix Feature，Flextime（传统开发固定范围，弹性时间）

2.敏捷开发

敏捷开发的一个核心思想的转换是，从瀑布式开发所代表的“Fix Feature, Flex time”（固定范围，弹性时间）转向“Fixtime, Flex Feature”（固定时间，弹性范围）。

 

Fixtime，Flex Feature（敏捷开发固定时间，弹性范围）

在市场变化和技术变化的背景下，既然市场需求和产品定义所代表的“范围”无法实现固化，因而无法确定应该投入多少资源来完成，那不妨固定好已有资源的，以资源位约束，实现“范围”的最大实现，从“计划驱动”转向为“价值驱动”。在敏捷开发的思维模式提出后，2001年，敏捷宣言诞生。

个体和交互 胜过 过程和工具

可工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

精益求精 胜过 简单执行

（注意：这里的胜过不是不要做，而是当两者出现冲突的时候，我们进行选择的判断依据）

对比瀑布式开发，敏捷开发更加贴近最终的市场环境，它有着更好的适应性，同时在敏捷宣言的指引下，更强调发挥人的价值，能更好的挖掘出团队的潜能。

敏捷开发充分发挥“人”在软件开发中的价值，强调追求有价值的产品结果，发挥每个人的主动性和创造力。

在敏捷宣言的指引下，产生了很多种敏捷开发方法，而冲刺和迭代式的“Scrum”方法，更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。

3.Scrum介绍

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。

Sprint则是指竭尽全力的冲刺短跑，为球队争得利益，球队队员为一个整体，按照阵型发挥各自的价值，最终的结果取决于团队的配合和取胜的决心，而不是教练在场下的指挥。

 1986年，Scrum首次应用于产品开发，竹内弘高和野中郁次郎在 《The New New Product Development Game》文章首次提到将Scrum应用于产品开发。 

1993年，Jeff Sutherland在首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。

1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。

2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

2002年，Ken Schwaber和MikeCohn共同创办了Scrum联盟。

Scrum敏捷开发让团队以一个整体走完全程，产品开发过程从一个精心挑选的多学科团队的不断互动中产生，团队成员从开始到结束都在一起工作，该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的。

4.Scrum的特点

4.1内置的不稳定性

高层通过发出一个宽泛的总体战略方向的信号来启动项目，并设置了一个极具有挑战的目标，同时赋予项目团队极大的自由来完成这个项目，这样既给团队压力，同时把团队推到墙边并把他们逼到极致发挥他们的创造力。

4.2自组织的项目团队

当项目团队被驱动到“零信息”的状态时，他们就会呈现出一种自组织的特征，这种状态存在模糊性和波动性，因此需要项目团队像初创团队一样运作，承担主动性和风险，并制定独立的议程，当一个群体表现出三个条件：自治、自我超越和异花授粉，这个群体就拥有了自组织的能力。

自治：公司的参与仅限于在一开始的指导、资金和道义支持，日常工作中高层很少介入，团队可以自由地设定自己的方向。

自我超越：项目团队全神贯注于对“极限”的永无止境的追求，从总部提出的指导方针开始，他们开始建立自己的目标，并在整个开发过程中不断提升目标。

异花授粉：由具有不同职能专业、思想过程和行为模式的成员组成的项目团队进行新产品研发，这种多样性孕育了新的思想和概念（这里和黑客增长理念接近，多样团队的观点碰撞，获得更具创意的实验方案）。

4.3重叠的开发阶段

在瀑布式方法下，一个项目以循序渐进的方式经历几个阶段，只有在满足了前一阶段的所有需求之后，才能从一个阶段过渡到下一个阶段，通过一些检查点控制风险，但这种方法几乎没有为集成留下空间，某个阶段的瓶颈可能会减慢甚至停止整个开发过程。而在整体或橄榄球方法下，这些阶段有相当大的重叠，这使得团队能够吸收整个开发过程中产生的振动或“噪音”，重叠方法加强了共同责任和合作，激发了参与和承诺，团队必须同步进度以满足最后期限，突出了解决问题的重点，鼓励主动采取行动，发展多样化的技能，并提高对市场条件变化的敏感性。

4.4多重学习

由于项目团队的成员与外部信息来源保持密切联系，他们可以快速响应变化的市场条件。团队成员参与一个不断尝试和犯错的过程，以减少他们必须考虑的选择的数量。他们也获得了广泛的知识和多样化的技能，这有助于他们创建一个能够快速解决一系列问题的多才多艺的团队。

4.5微妙的控制

尽管项目团队在很大程度上是独立的，但他们并不是不受控制的，管理层建立了足够的检查点，以防止不稳定、含糊不清和紧张局势演变成混乱。与此同时，管理避免了那种损害创造力和自发性的严格控制。相反，它强调的是“自我控制”、“通过同伴压力的控制”和“通过热爱的控制”，我们统称它们为“微妙的控制”。

4.6学习的组织转移跨

层次和跨职能积累知识的动力只是学习的一个方面，项目成员也有同样强烈的动力将他们的学习成果转移给小组以外的其他人，将学习内容转移到后续的新产品开发项目或组织内的其他部门。

Scrum敏捷开发的实施让开发团队有了一定自主权，已安排好的计划很大程度上不会被打断，同时上下游相互配合，为一个共同的目标而努力，每个人都清楚团队其他人的工作内容，每天都知道项目的实时进度，团队是一个整体的存在，而不是每个人独立工作下的个体，有着很强的集体荣誉感。

但Scrum能否成功实施，关键要先获得高层的认同和理解，让高层们理解Scrum的要义、利弊，如果Scrum能带来高效、优质的开发成果，那就在制定绩效结果并在实施过程中放权，让每个成员真正意识到项目成果是自己的事，而不是领导的事。如果是职能型的研发团队，同时也要获得各需求方的认可和支持，分享在这种方法下对整体的收益最大化，否则可能会面临各种不理解，最终可能导致实施失败。

因此，我们要落地Scrum敏捷开发，就要做好“猪”与“鸡”两种角色之间心理上的平衡与和谐，“鸡爷爷”切不可把“小猪”们看成是一群猪八戒，空有一身本领，但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮，只会半夜鸡叫，影响正常的开发进度。猪和鸡双方相互理解，达到项目开展过程中的平衡点，才能让整个项目顺利的完成。

敏捷开发的落地，人是最重要的，在做敏捷开发之前，需要先组建一直敏捷的团队，而作为这个团队的负责人，必须要对于敏捷有着清晰的认知。

二、敏捷开发的理解

很多人对敏捷开发的理解就是快，做项目中如果不快就对不起敏捷这两个字，但快到什么程度却没有概念，因此往往没有参与过完整敏捷开发项目的人，遇到一些问题之后“比如不是他想象的那么快”，就对敏捷开发提出质疑，觉得敏捷开发也就那样，究其根本是对敏捷开发的片面理解，或者只是了解了皮毛就觉得掌握了全部，而忽略其本质；

敏捷开发的目的是用来适应快速变化的市场，就像冲浪一样，一直处在动态、不停的变化当中，而在项目研发过程中遇到的需求变化和沟通平衡的挑战，就是你在冲浪时遇到的海浪，它们从不停止且永远在变化，所以我们要快速的适应变化。

首先，敏捷开发是一种做事情的方法。

它适用于范围软件、运维、服务等领域，但在硬件领域就不太适用，硬件一般不允许需求中途改变；

它适用于竞争激烈的市场，这种情况下，赶在对手之前交付一个不完美但能用的产品，并通过用户反馈不断优化就非常重要了；

它适用于快速变化的市场，研发团队和外部信息保持紧密联系，不仅能让产品能够适用于当前的外部市场，而且还能按时交付；

它适用于小团队，一般为5~9人，这样能使敏捷开发提倡的“面对面”沟通方式是可行的；

所以它的快在于应对市场变化的灵活度，在于团队配合的沟通和协作效率，在于对按时交付可使用软件信念的坚定，而不是某个项目原本开发需要3个月，简单的认为用了敏捷开发就一个半月就能交付了。

其次，它是一套工具集。

你可以通过各种最佳实践提炼出自己的敏捷实践方法，也可以选择其中几个你认为有用的来提高团队的工作效率，比如站会，看板，用户故事，演示、计划会、评审会、反思会等活动工具。

最后，敏捷开发也是一种企业管理方式。

它专注于团队的整体绩效，而不是个人的单打独斗能力，在实际工作中将决策权交给团队，以人为核心，发挥个人的主观能动性，提倡创新和效率，也需要负责人日常工作要不断强调的核心理念；

它把大项目拆成小项目去做，每次使用Sprint作为一个冲刺版本，每个Sprint控制在2~4周内，持续输出有价值的软件；

综合以上内容，敏捷开发是指在高度协作的环境中，持续不断地快速输出可交付的产品，通过反馈进行自我调整和完善的方法。

1.敏捷原则

围绕着敏捷宣言，在实际工作中，我们总结出一系列的原则，使敏捷开发更具可操作性；

可工作的软件是主要的进度度量标准

我们最优先要做的是通过尽早，经常性地交付可以工作的软件来使客户满意

要持续不断交付可用的软件，周期从几周到几个月不等，时间越短越好

最好的需求调研、产品架构、和产品设计来自于自组织的团队

善于激励项目员工，给他们提供所需环境和支持，并信任他们能胜任工作

在团队内部，最有效果和最有效率的传递信息的方式是面对面交流

敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度

要做到简洁，尽最大可能减少不必要的工作

即使到了开发后期，也欢迎需求变化，要善于利用需求变更，帮助客户获得竞争优势

开发团队每隔一段时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整

不断地关注最优秀的技术和良好的设计能增强敏捷能力

项目开发过程中，业务人员与开发人员需要在一起工作

随着敏捷的不断实践和理解，团队还可以提出自己的敏捷原则，最终让每个人认可并执行，打造出整体输出的高效团队。

2.团队组成

在一个敏捷开发团队中，有以下几种角色：

 

Product Owner 产品负责人

产品负责人是需求的制定者，代表了用户的意愿，保证Scrum团队从业务角度来说做正确的事情，产品负责人负责编写用户故事，排出优先级，并确定好每次Sprint的冲刺内容；

他是产品的既得利益者，也同时是部门负责人/项目负责人，责任是制定团队的目标，把握方向，为产品是否为客户想要的结果负责，同时也承担着团队管理的责任，给团队赋能，协调公司资源，激励团队成员，以及对弱能力成员进行辅导，最终让团队成员整体作出成绩。

Scrum Master 敏捷教练

为项目进度和交付结果负责的人，是团队的负责者，提供服务要满足团队最高优先级需要；同时确保Scrum的正确理解和使用，使得每次Sprint的收益最大化，他必须了解完整的开发过程，以及开发过程中上下游的关系，擅长使用Scrum各种工具，并在实际的工作中引导团队成员；

ScrumMaster是团队的保护伞，确保团队集中精力完成冲刺，同时他要扫清妨碍团队生产效率的一切障碍；ScrumMaster还要帮助他人理解变革的需要，在Scrum团队之外Scrum所带来的影响及Scrum能帮助达到的广泛而深远的收益。ScrumMaster还要确保组织的各个层面都发生有效的变革，不仅能够促成短期的成功，而且能够得到长期的收益。

这个角色可以是一个专职岗位，专职的好处是项目管理更加专注和专业，引入快，但可能会工作不饱和，因此一个专职的ScrumMaster可以参与多个项目；也可以从团队中选一个资深的团队成员兼任，兼任的好处是降低了人力成，对项目和产品理解更深，协作效率更高，但对ScrumMaster能力要求较高，对于成员的工作会有一定影响；

但不管是专职还是兼任的，这个角色要有很强的责任心才能按时交付、足够细心才能控制好进度，擅长沟通才能扫清障碍，善于提问才能给团队启发，让开发团队自己找到答案，实现自组织管理；

Scrum Team 开发团队

人数不宜过多，5~7人比较理想，包含产品、设计、前端、后端、测试等多角色，是实际价值产出者；

开发团队的职责是合理评估好工作量，每天完成既定的工作内容，遇到阻碍要积极解决，解决不了需要及时需求帮助，承诺按时交付可工作的软件。

敏捷开发的团队是一个自组织的团队，这个团队接受外部给与的任务和约束条件，自行决定如何完成任务，在团队中，团队成员自己决定做什么，如何做；就像一个篮球队，上场之后教练和老板就失去了球队的控制权，场上的任何决定只能靠团队成员自己来做；而角色的区分，让项目成败不全压在团队负责人身上，整个团队要去承担相应的责任。

4.自组织团队特点

 

在一个自组织的团队中，具备以下6个特点：

尊重：是指团队成员之间和团队外部之间彼此尊重，公司放心授权，团队间彼此信任，才能建立起高效的合作；每个成员敢说、敢做、敢犯错，不不断试错中快速找到正确的路径。

透明：透明是建立信任和尊重关系最好的方法，讲明原则，制定规则，在各种实践中保持透明，尽量将一切活动可视化，使用看板、燃尽图等工具。

目标：团队要有明确的目标，团队才有前进的动力和方向；让团队明白项目背后的意义，团队成员才能明白自己付出的价值，在团队中达成价值、完成标准、验收标准等共识。

承诺：有了目标就要有承诺，团队各成员之间相互承诺，完成彼此的责任和任务，做到当天的事情当天毕，对团队承诺的事情，一定要做到。

团队：一个项目团队就是一个整体，在项目开发过程中，要时刻强调以团队作战，团队共同进退，增强每个人的集体荣誉感。

辅导：互相辅导是提升团队能力的最佳途径，也是实现团队间尊重、承诺的好方法，比如师徒制、Code Review、反思会等。

同时，定义好每个角色的责任边界。

产品负责人：为团队的配合度负责，为员工的流失负责，为最终交付产品的客户使用满意度负责；为打造高效的敏捷流程负责；

敏捷教练：要为项目交付时间负责，为没拦住开发过程中需求变更负责，为长期加班状态负责，为线上bug负间接责任，为员工流失负间接责任；

产品经理：要做到项目启动会时，为PRD完备负责；在DL日期之前，不再变更需求，也不再插新需求，也就要求产品的逻辑要思考全面；为交付时间负责间接责任，为拦住需求方提负担过重的需求负责；

开发团队：要为里程碑进度负责；要为交付时间负责；为线上bug负间接的责任；

测试：为线上的bug负责。

想要打造自组织的团队，需要负责人坚信敏捷开发带来的团队变化，倡导敏捷文化，打造诚实守信、精益求精的团队氛围，在一个一个项目实践中磨合；

如果是新团队建议刚开始就使用敏捷工作方法，形成部门规矩，后续新人融入之后能够快速适应；而成熟团队需要潜移默化，切勿着急改变，挑选合适的成员来进行试点，有了一定结果之后再推广到其他的项目团队中。

三、完整开发流程

 

一个软件产品的完整开发流程分为4个部分，分别是：

1) 需求确定阶段

2) 产品研发阶段

3) 产品验收阶段

4) 全量测试发布阶段

在实际的开发过程中，为了提高效率，②③是有可能重叠交替进行，Scrum框架为每一个阶段都设定了对应的解决方案。

1.Scrum框架-334

 

完整的Scrum流程包含了3个角色、3个物件，以及4个会议；

3个角色：

Product Owner 产品负责人

Scrum Master 敏捷教练

Scrum Team 开发团队

3个物件：

Product Backlog 产品功能列表

Sprint Backlog 迭代任务列表

燃尽图

4个仪式：

Sprint冲刺计划会

每日站会

Sprint冲刺评审会

Sprint冲刺回顾会

3个角色我们在前文已经详细介绍，这里就不做过多的阐述；

3个物件属于敏捷工具，会使用即可，其中“产品功能列表”由产品负责人维护，然后进行优先级排序，以用户故事的形式展示，能够让团队成员容易理解；

“迭代任务列表”是当前冲刺迭代版本的任务集，由产品将用户故事拆成任务，并让团队成员各自领取；

“燃尽图”则是一个公开的图表，是项目进度的一种看板表现形式，有助于项目成员能够直观的理解项目进展，直到所有任务开发完毕。

4个仪式贯穿整个敏捷流程，领悟每个会议的作用，将决定整个敏捷开发的质量。

2.Sprint冲刺会

每个冲刺版本都由一个Sprint冲刺计划会开始，产品负责人PO或团队成员选择用户故事，然后由产品负责人详细讲解用户故事，产品经理负责讲解满足用户故事的产品功能解决方案，开发团队进行任务估算；

冲刺会最终产出1张表和3个时间节点：

Sprint里程碑任务计划表；

可测试介入的时间节点、整体开发完成的时间节点、上线时间节点；

冲刺计划会要注意几个关键点：

一个Sprint的周期不宜过长，控制在4周内，而且以2周为佳；

每次会议全员必须参加，每个人都要清楚本次版本的目标，我们能交付什么，明确各自的职责和责任；

全员承诺，PO不死压完不成的任务量；

任务估算时可以讨价还价，但一旦接受则所有人都要对里程碑no delay，做到当日事当日毕；

尽量不要压缩测试的时间；

在任务进度表没有出来之前，不要中断会议；

3.任务估算

任务估算是冲刺计划会中最重要的一个环节，只有理解了本次会议的需求内容，才能估算出准确的时间，确保里程碑的进度可控，SM要在这个环节把控全局，确认好里程碑的时间节点。

如果团队内岗位都不相同，团队成员分别编写自己的任务卡，而如果有相同的岗位，应当以小组的形式来估时，比如一个团队中有2个后端，那他们就要对本次里程碑的所有任务都进行估时（可参考扑克牌估算法），双结果不同需要讨论并重新出牌，结果比较接近即结束。

4.任务卡

一张完整的任务卡要包含三个内容：

明确的交付内容

责任人（可以使用代号，只要不重复即可）

任务完成时间（可以用小时H或天D作单位）

 

敏捷教练SM在和每个人确认任务卡片时，需要注意以下几点：

4.1 目标一致：

做最后确认，确保所有人都清楚本次里程碑的目的和逻辑细节，只有理解了业务细节才能很好的拆解任务卡片，确保不丢失业务逻辑；

4.2 任务拆解：

单个任务1天为最佳，最多不能超过2天，绝大多数的任务都是可以拆解的，很多人无法拆解是没有掌握正确的拆解方法，我们可以按照页面数量、接口数量、制作步骤等方法进行拆解。

例：我们要画一张原画，正常需要7天，我们可以按照步骤拆解：

找参考（可省略）→ 画草稿 → 画线稿（将草稿清晰化）→ 上色（上底色、上阴影色、上第二层阴影色）→ 加特效（画背景、光影）→ 优化细节 → 完稿。

拆解到人天的好处就是让每个人都知道每天要完成什么内容，工作目标清晰透明，验收时只有两个结果是和否，不存在模糊不清的进度（比如完成30%这种），既让成员有一定压力，也能够有效的减少工作不饱和的情况；

第二个好处是SM每天都知道谁交付了什么，如果没有完成第二天也能及时风控，而不是等几天之后才发现某人完成不了；

4.3明确信息：

任务卡片里的内容要清晰准确，要有量化的内容，不能用模糊不清的概念，SM要能够理解每个卡片上交付的内容，如果不理解需要让成员修改，并检查每个人卡片上三要素是否齐全；

例如

错误：完成接口的开发（不具体）

正确：完成用户注册5个接口开发

4.4消除瓶颈：

检查卡片时需要关注是否包含了所有的需求，是否有估算时长与预期、或和以往类似功能时间严重不符的任务卡片，单人的任务时间是否过长，评估整体里程碑时长是否过长；

如何评估任务估算过长？

里程碑的总时长是否和你预期的相差过长，如果是，和团队表达你的想法，一起寻找瓶颈点

培养自己的直觉，和历史同类任务进行对比进行判断

把握不准的，可以使用同岗位使用扑克牌估时法，找出差异大的估时逻辑

在前几次的里程碑中，观察和评估每个人的工作效率，用于后期对每个人的估时进行判断是否有很大的不饱和情况

那如果有人任务估算过长，应该如何处理呢？我们可以从以下几个角度进行分析解决：

信息缺失：有可能是对所负责的任务还不是很了解，或把解决方案想复杂了，或对项目不熟悉，不知道有些方法已存在，可以直接使用等等，这些都可以通过深度沟通来解决；

任务拆解：尽可能的拆细，查看每一天的任务的工作量是否饱和，直到无法再拆为止，拆到一个点就很容易评估时间；

能力不足：一些新人刚开始可能不知道如何拆解任何和评估，这个时候需要更资深的开发来进行辅导，梳理业务逻辑，输出合理的卡片，辅导2~3次之后即可解决该问题（如果没有资深开发可以考虑招聘一个，一个经验丰富的开发，对于消除瓶颈有极大的帮助）

态度问题：极个别的情况可能是员工的工作态度问题，态度问题很难在会议上进行解决，短期内也不太好解决，这时需要PO使用权威来推进，适当给予压力，日常工作中要进行引导，若发现还是没有改变的迹象，需要考虑替换；

4.5打通关联：

SM需要全局观察每个人的任务排序和时间，观察上下游任务衔接情况，合理调整顺序，确保任务的连贯性，尽早的交付可供测试的软件。

4.6交付承诺：

任务卡片确认完毕，明确三个时间节点，所有人达成共识，将任务按照优先级展示在看板上，输出里程碑计划表，全体成员承诺交付结果。

5.每日站会

里程碑确定之后，通过每日站会来推进项目进度，由SM发起，全体成员参加，PO和其他需求方选择性参加（但只参与、不说话），每日站会是快速专注的会议，用来分享进度和迭代看板进展，每个团队成员就他们将要完成的任务对其他人口头承诺；

所有人围绕在看板周围，每个人轮流上前回答一下三个问题：

昨天我为团队做了什么？

今天我将要做什么？

我需要哪些帮助？

回答完毕之后将已完成的任务移入Test泳道，将今天的任务移入Doing泳道。 

一个有效的站会需要做到以下原则：

固定时间、固定地点，养成习惯，迟到的人要有惩罚

全员参与、站立开会，保持专注，时长控制在10~15分钟

三个问题、更新进度，不要讨论技术问题，不要转移会议话题

注意聆听、回应问题，别人在讲时其他人要注意听，需要帮助时相关人员要及时回应

6.Sprint冲刺评审会

在开发完毕后，即将交付上线之前，由SM发起，全体成员参加，开发团队将可交付物演示给需求方，需要方进行功能评审，收集反馈意见；

评审会并不是必须的，但Scrum团队要经常和需求方保持信息互通，确保接受到最新的市场动态和用户反馈，交付的产品满足利益相关者的期望，让团队的产出有价值。

7.Sprint冲刺回顾会

每一个冲刺会完成后，都要举行一次冲刺回顾会议，在会议上所有团队成员对本次冲刺进行反思，包括：什么进展顺利？缺少什么？需要改变什么等等；

冲刺回顾会是针对迭代末期进行的时间盒会议，目的是帮助团队如何提高他们的工作效率和改进工作方式，就未来的迭代改进计划达成一致；同时梳理以往的项目缺陷和债务，对用户故事进行审视，是否需要新增、删除、修改用户故事，对用户故事进行优先级排序；

需要注意的是，让团队自己反思，PO尽量不参加，或者参加也尽量少说话，反思时要找出明确的问题和意见，不要情绪化，切勿开成批斗会。

Scrum敏捷流程让在早期发现可能的问题，可以用更快更小损失应对问题，“没有问题被扫入地毯下”，Scrum鼓励每个团队成员清楚的描述自己所遇到的困难，其他成员积极的响应解决，降低项目风险，SM必须有预警风控能力，能判断出可能的延迟或者偏差；

至此，正式踏上了敏捷之旅；

然而，敏捷之路，不可能一帆风顺，团队只有在不断遇到问题解决问题才能快速成长。