计应 212七组对Scrum团队流程的理解：
Scrum的来源：
来自英式橄榄球运动，本质含义就是一群人你推我搡地去抢球和控球。用球赛来类比确实是一个形象又合适的比喻，在赛场上尽管队员们努力按照既定计划推进，但是场上瞬息万变，不可能实时按照教练或者队长的指令亦步亦趋的去行事，只能靠平时训练中形成的素养见机行事，达成目标。
Scrum的核心思路
Scrum的核心思路，是首先承认我们的客户(或者我们的产品服务的用户)并不清楚自己的需求，并且人类的需求会不断变化(“requirements churn”：就是需求本身在不断地倒腾)，所以我们默认需求是变化的需求，并且制定出一套策略能让整个组按照小功能快速开发，并且后续不断迭代。回归 Scrum 的英文含义：把开发就搞成一堆人在合力拼抢，把功能分成小块，快速开发和迭代。
实践框架
Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集，Scrum避免了说软件团队应该如何开发软件，它坚持认为：人们在自己的工作中和处理问题时，应该像一个成熟的成年人一样，因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能，这些都需要其他相关理论和技能来补充。另外，如同其他项目一样，需要软件团队在其业务领域的专业能力来确保软件项目的成功。
Scrum价值观
承诺- 愿意对目标做出承诺
专注– 把你的心思和能力都用到你承诺的工作上去
开放– Scrum 把项目中的一切开放给每个人看
尊重– 每个人都有他独特的背景和经验
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
以上价值观和敏捷宣言相互呼应，很多人都会忽略这些核心价值和核心思想，而是追求Scrum的一套开发流程或者开发框架。但流程框架这些都只是一个规范，不是每个团队都能直接硬套上去使用。需要有一定的调整，甚至结合其他开发方法一起使用，没有领悟敏捷开发思想是没有办法灵活使用Scrum的。
Scrum角色
Product Owner(李金胜)：
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
Scrum Master(高志辉)：
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
Development Team(张书铭，吴玉鹏，段豪洋，王钟正)：
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力;成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum相应活动
产品待办事项列表梳理
保持产品待办事项列表有序
把看起来不再重要的事项移除或者降级
增加或提升涌现出来的或变得更重要的事项
将事项分解成更小的事项
将事项归并为更大的事项
对事项进行估算(按团队平均水平计算人时)
Sprint计划会议
在这个会议中，Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。
Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少，开发团队需要考虑当前产品增量的状态，团队过去的工作情况，团队当前的生产能力，以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人，都不能给开发 团队强加更多的工作量。
决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。
总而言之：在Sprint计划会议中，开发团队和产品负责人一起考虑并讨论产品待办事项，确保他们对这些事项的理解，选择一些他们预测能完成的事项，创建足够详细的计划来确保他们能够完成这些事项。
每日Scrum会议
每日Scrum既不是向管理层汇报，也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议，来保证他们对现状有一致的了解。
每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)
Sprint评审会议
所有Scrum会议都是限定时⻓长 的，Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如，一个Sprint 包含2个星期，则Sprint评审会议时⻓长为2个小时)。
团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量，整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。
Sprint回顾会议
在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在 的改进事项，为将来的改进制定计划。
Scrum团队总是在Scrum的框架内，改进他们自己的流程。这句话很重要。
满足条件
Scrum虽然十分热门，但是要成功，正确的实现它，并达到一定的效果，不是简简单单的一个命令就可以做到。特别是国内的一些传统企业，或者一些组织架构死板的公司，内部改造并不容易。当然也不是扁平化管理的初创公司就能很好的实现Scrum，人员素质，管理者经验的都是初创公司的短板。所以个人总结了要实现Scrum先要满足的几大条件。
理解思想
对Scrum的核心思想和理念真正深入的了解，而不是看中Scrum其管理流程的实现，需要结合敏捷方法的理论，从本质上了解为何Scrum要如此管理开发流程。
适配模型
熟悉Scrum提出的模型，遵循其规范的流程，但又不能被条条框框限定死，需要相关人员结合公司或者团队本身情况进行适当的调整，只要符合核心思想即可。这需要有一定智慧，知识和经验的人去了解公司业务，人员素质，再思考总结，才能制定出一套规范的开发流程，并将这套流程严格执行，这个过程甚至可能会改变公司架构。
人员素质和有效协定
团队人员的素质是一个非常重要的，决定Scrum能否有效实施的条件，它包括自我管理，技术能力，知识积累，做事原则，思想智慧等，是一个综合素质的考量。
Sprint评审会议
所有Scrum会议都是限定时⻓长 的，Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如，一个Sprint 包含2个星期，则Sprint评审会议时⻓长为2个小时)。
团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量，整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。
Sprint回顾会议
在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在 的改进事项，为将来的改进制定计划。
Scrum团队总是在Scrum的框架内，改进他们自己的流程。这句话很重要。
满足条件
Scrum虽然十分热门，但是要成功，正确的实现它，并达到一定的效果，不是简简单单的一个命令就可以做到。特别是国内的一些传统企业，或者一些组织架构死板的公司，内部改造并不容易。当然也不是扁平化管理的初创公司就能很好的实现Scrum，人员素质，管理者经验的都是初创公司的短板。所以个人总结了要实现Scrum先要满足的几大条件。
理解思想
对Scrum的核心思想和理念真正深入的了解，而不是看中Scrum其管理流程的实现，需要结合敏捷方法的理论，从本质上了解为何Scrum要如此管理开发流程。
适配模型
熟悉Scrum提出的模型，遵循其规范的流程，但又不能被条条框框限定死，需要相关人员结合公司或者团队本身情况进行适当的调整，只要符合核心思想即可。这需要有一定智慧，知识和经验的人去了解公司业务，人员素质，再思考总结，才能制定出一套规范的开发流程，并将这套流程严格执行，这个过程甚至可能会改变公司架构。
人员素质和有效协定
团队人员的素质是一个非常重要的，决定Scrum能否有效实施的条件，它包括自我管理，技术能力，知识积累，做事原则，思想智慧等，是一个综合素质的考量。