1.首先来看一下什么是Scrum：
Scrum是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum在英语是橄榄球运动中争球的意思。
虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。
2.Scrum特点：
Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括：
- 'Scrum Master'是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
- 产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责；
- 开发团队，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各种技能。
在每一次冲刺或迭代（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工作需求。在迭代计划会议中，产品负责人告诉开发团队需要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们能够承诺完成多少订单项。 在迭代的过程中，没有人能够变更迭代订单，这意味着在一个迭代中需求是被冻结的。
管理Scrum过程有很多实施方法，如即时贴、白板、甚至软件包。Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不需要太多的投入。
3.Scrum中的角色：
Scrum当中定义了许多角色。按照对开发过程的参与情况，这些角色被分为两组，即猪组和鸡组。这个分组方法的由来是一个关于猪和鸡合伙开餐馆的笑话：
猪组的成员
猪是在Scrum过程中全身投入专案的各种人物，他们在专案中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。
- 产品负责人
- 产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。
- Scrum主管（或促进者）
- Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。
- 开发团队
- 负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。
鸡组的成员
鸡并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷 方法的一个重要方面是使得用户和利益相关者参与到过程中的实践。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
- 用户
- 软件是为了人而开发的。有人说，“假如森林里有一棵树倒下了，但没有被人听到，那么它算是发出了声音吗？”同样地，人们可以说，“假如软件没有被使用，那么它算是被开发出来了么？”
- 利益相关者（客户，提供商）
- 影响项目成功的人，但只直接参与冲刺评审过程。
- 经理
- 为产品开发团体搭建环境的人。
4.Scrum会议
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：
- 会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）
- 欢迎所有人参加，但只有"猪"可以发言。
- 不论团队规模大小，会议被限制在15分钟。
- 所有出席者都应站立。（有助于保持会议简短）
- 会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
- 昨天你完成了那些工作？
- 今天你打算做什么？
- 完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。
Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
Scrum会议一共包含以下四种：1） 冲刺计划会议；2） 每日站立会议；3） 评审会议；4） 回顾会议。
个人看法：
Scrum站立会议固然很好，主要是比较简单，保留了会议中最核心的部分，再在哪一部分上有删减，就会对功能有所损害，所以理论上说，Scrum站会是一种高效的会议。
但是，在实际应用中（我没有类似经验，只能猜想），该会议模式对成员的要求太高，技术能力和工作态度等。而大公司招人很难达到这样的水平，并且一旦落下了，卡住了，每一天的汇报工作几乎就没有意义。一旦团队有部分人对该会没有全力配合，那么就不会有预期的效果。并且教条式的理论不一定符合实际项目的需求。
以下是知乎上摘录的看法，比没有实际工作经历的人更有说服力：
1.只要我能说得算的项目, 我一定会取消每日例会.首先每日例会影响的并不止15分钟, 成员从刚一上班到开会这段时间不太能正经工作. 公司是弹性工作制的话, 例会时间要开在10点半到11点半, 这时候开完会也快吃中饭了, 导致整个上午工作效率都比较低.
每日例会的目标是让所有成员都能掌握团队的进度, 能及时反馈. 可说老实话, 团队中除了Team leader和PM(PO?), 没几个人在乎别人的进度. 大家工作都是为了挣那份工资, 没谁会多操那份心. '管好自己一亩三分地, 别人死活关我屁事'才是中国人的职场观念. 还不如想知道进度的人自己去看看板(或者用户故事之类的东西)呢.
各个程序员的效率差别非常大, 可以差上几倍甚至几十倍, 但是工资差距不大. 效率高的发现自己进度比别人快很多, 会自己放松. 效率低的每天都要发现一遍自己比别人慢, 压力山大, 但并没有什么卵用(我曾经周末去公司取东西时, 见到过有人因为几天都没有能汇报的进度,自己偷偷跑来加班的).
作者：匿名用户
链接：https://www.zhihu.com/question/36515179/answer/102129189
来源：知乎
著作权归作者所有，转载请联系作者获得授权。//匿名怎么联系嘛2.作者：张恂老师
链接：https://www.zhihu.com/question/36515179/answer/102530380
来源：知乎
著作权归作者所有，转载请联系作者获得授权。//正在联系，不同意就删除Daily Scrum 并不是敏捷开发必需的，只是 Scrum 或 XP 必需的（？）。每日站会（XP 中叫 Daily Standup Meeting）大概是 Agile 1.0 中最具程式化、仪式感的一个著名实践，Scrum 因此得名。可是这么做真的有必要吗？是全天下普适的吗？还是一种宗教传承？你们不用每日站会，就会愧疚、难过，对不起 Scrum，对不起 Scrum 大师，对不起你交的学费？
我的观点是：每日站会对于紧急的项目确是有必要的，例如 60 天（尤其 30 天）以内的项目，每一天都很重要，有必要大家每天了解、跟踪进度，针对发现的问题、障碍及时采取措施，进行应对和调整，把问题消灭在萌芽状态，否则可能真的来不及，因为工期实在太短。
至于工期 60 天以上的项目，我看就算了吧。隔一两天团队不见面不开会，会有什么恶劣影响呢？何必教条？
我想问的是：大家觉得每周一共要开几次团队会议，无论时间长短，才是合情合理的？有没有一个上限和下限？（这里指正式的 team meeting，不是几个人私下碰头的小会）
其实替代 Daily Scrum 的 Agile 2.0 实践肯定有多种，发挥大家的创造力。
下面介绍下 Taij/BP 的周三团队会议（WTM，Wednesday Team Meeting）和敏捷开发日志（Agile Devlog）等实践。
一般团队都会在周一、周末（如周五）开会。周一团队刚刚开过会，马上周二又要全体见面 Daily Scrum，有这个必要吗？这一天内究竟发生了多么重大的事，需要大家全体集合，再次紧急沟通呢？我们为什么不能取消周二、周四的 Daily Scrum，让大家只在周一、周三和周五全体聚会呢？于是，伟大的 WTM 诞生了。
。。。