1.解释Scrum 是一种框架--3355（3角色、3工件、5事件、5价值观）,一种新的团队管理工作可以高效并创造性地交付尽可能高价值的产品，比如需求沟通完需要等整个开发完成才能看到系统面貌，使用Scrum后，每隔一段时间就可以看到，中间发现问题可以及时进行修正
2.在后续的沟通中一点点融入我们采用3355，帮助大家认识并运用
3.需要业务利益干系人参加：产品待办清单、Sprint 评审会、Sprint回顾会
3个角色
Product Owner：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 作为产品负责人，PO清楚地知道产品的愿景，需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What，一般可以对应为我们理解的产品经理和业务分析师的角色。
Scrum Master：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，一般可以对应为我们理解的项目经理的角色。
Scrum Team：主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面（开发、测试），要求团队有很强的自组织能力，能够交付一个端到端的真正对客户有价值的产品
3个工件：
Product Backlog：产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。它具有以下特点：。
是项目的需求列表
以用户故事的形式表示
包含功能性以及非功能性需求
每项需求应该描述其商业价值
PO负责进行对Product Backlog Item（产品待办事项）优先级排序
每个Sprint开始之前要重新进行排序，以确定最重要的事项
随着项目的进行，可能新增、变更或减少条目
Sprint Backlog：冲刺待办事项列表，一个冲刺目标阶段内的用户故事列表。
这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级最高的用户故事放入迭代。它具有如下特点：
从产品Backlog中取出前面若干项，在当前Sprint中被实现
每个用户故事应该能够在当前Sprint中被实现
每一个用户故事都会被分解并关联到若干个子任务（Task）
团队成员自愿挑选任务
每日更新任务剩余时间
团队成员均可按需在Sprint Backlog中增加、修改、删除任务
如果Sprint工作不清晰，创建Sprint Backlog时先估算一个比较大的时间段，在后续阶段再做进一步的缩短
伴随着任务的逐步清晰化，及时更新剩余时间
对于用户故事的完成，团队一起定义“完成”的标准（DoD）
DoD代表了各种用于确保sprint backlog中质量、准确性、业务关联性活动
潜在可交付的产品增量：要求每一个Sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI）。能否每个Sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。因此这里关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队DOD内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定
5个活动：
Sprint计划会，
在每个Spring开始之时召开，由Product Owner、Scrum Master和Scrum Team全体人员参加。这个会议主要有两件事情要确定：
要确定当前Sprint的目标
选定当前Sprint要处理的最具价值的用户故事，创建Sprint Backlog
Sprint backlog的创建是团队协作的结果，而不是由Scrum Master单独完成。必要时候，技术分析和设计任务也可以被添加到Sprint Backlog。
Sprint计划会上，团队要：
确定当前Sprint的目标（Goal）
从产品Backlog中选择他们承诺可以完成的工作项
对选定的用户故事进行估算
创建Sprint Backlog
识别任务，且每个任务都完成了估算
可以考虑概括设计
对每个选定的用户故事，如有问题，当场向PO进行咨询，请求进行澄清。
Sprint就是Scrum里面的迭代时间盒，是一个固定时间长度的软件开发、交付周期。Sprint 具有如下特点：
Scrum通过一系列Sprint落实开发任务，实现项目进展
典型Sprint时长2-4周，最长一个自然月
固定Sprint时长有助于保持好的团队节奏
在每个Sprint中团队对产品进行设计、开发以及测试
Sprint具有固定时间段，按时结束，每次Sprint成果则可能因实际情况而有所不同
Daily Standup Meeting: 每日站会
是Scrum用来沟通、通报当前进展及后续计划的主要场合，因其提倡大家都站着开会而得名。每日站会不是用来解决问题的会议，会上不讨论具体的问题细节、解决方式等占用时间的细节内容。项目遇到的问题或障碍，应当会后通过专门的问题解决会议或其他方式进行解决。
每日站会通常不超过15分钟，提倡每天在同一时间、同一地点举行。
全体团队成员、有兴趣的项目干系人均可参加，但只有团队成员、产品负责人和Scrum Master可以发言。确保分清Scrum的“猪”类角色和“鸡”类角色对团队非常有帮助。
Scrum每日站会上，每个团队成员都要回答三个问题：
本次会议之前，自己做了什么？
本次会议之后，自己打算或计划做什么？
目前，是否遇到了阻碍自己的问题？
特别强调，每日站会不是用来向 Scrum Master 或 Product Owner 汇报个人状态或进展的，它是用来在团队面前确认自己的个人承诺并展示当前进展和问题的。
Sprint Review Meeting
Sprint评审会，又叫Sprint演示会、Sprint展示会等，是团队用来展示当前Sprint开发成果的会议。Sprint评审会上，团队直接向相关干系人演示当前Sprint所开发出来的软件产品。Sprint评审会有如下特点：
团队展示当前Sprint的成果
一般采取演示新特性、底层架构、可工作软件等形式
通常是非正式的，不需要特意准备
不需要复杂的事先准备，尤其不要进行幻灯片的展示
整个团队全员参与
邀请所有项目干系人参与
会议时间依据Sprint的长短而定，通常每个Sprint中，每周1个小时的原则
PO确认sprint目标是否实现
PO可以拒绝接受团队的软件成果。
Sprint Retrospective Meeting
Sprint回顾会，用来回顾在当前结束的Sprint中的工作，进行经验的总结、反思，并拟定相应的改进措施。Sprint回顾会通常具有如下特点：
用于周期性检视团队最佳实践以及存在的问题
每个Sprint中，一周45分钟原则
每个Sprint结束时举行
整个团队全员参与，还包括 Scrum Master、产品负责人、客户以及其他项目干系人