【CTO CLUB微课】理论到实践，金牌讲师全面剖析Scrum精髓
7月27日，CSDN CTO CLUB微课正式上线，首期邀请到京东敏捷教练、金牌讲师姜信宝（Bob）带来深入剖析。
分享嘉宾简介：姜信宝（Bob Jiang）
中国北方第一位CST（Certified Scrum Trainer） ，京东敏捷教练、金牌讲师，旨在帮助企业改进工作方法以取得更好的商业价值。Certified LeSS Practitioner，《Scrum精髓》的译者。中国敏捷社区的守望者，从2011年起组织或参与了敏捷之旅、ScrumGathering China 、敏捷中国等大会。
目前,姜信宝老师也在全力推进CSM（Certified Scrum Master）课程，如感兴趣，请点击此处了解详细课程信息。
微课分享内容：
姜信宝： 大家好，今天我分享的话题是Scrum精髓。在开始之前先问大家一个问题，你理解Scrum的精髓是什么？我对于Scrum的理解，其精髓是反馈。今天我的分享就围绕着反馈来展开，分别从人、透明、产品、流程，4个部分进行描述。
先介绍一下，为什么反馈是Scrum精髓。为什么反馈如此重要。
大家看一下这个图，图中有两种开发方法，方法1：传统开发；方法2：Scrum。
对于方法1：什么点第一次获得客户的反馈？
对于方法2：什么点第一次获得客户的反馈？
对于Scrum，我们可以非常早获得反馈，这有哪些好处呢？
及早获得反馈的好处：
- 更早知道客户的真实想法，从而激发频繁的客户协作
- 拥抱变化，从而及时响应需求变更
反馈的内容，都是来自人，所以大家看下图，我会把今天的分享全部展开。反馈都是人提出来的。有一个点需要注意的是，反馈不能针对人，或者说指责人。反馈的内容，一定要基于事实。这些事实包括产品和流程，所有这些的基础是来自于透明。
这里的人，（或者说Scrum中的角色）分为三类：ScrumMaster，产品负责人，开发团队。
ScrumMaster，是一个全新的角色，Scrum中提出来的。那么谁适合来当ScrumMaster，ScrumMaster都有哪些职责？
ScrumMaster是全职的，他的职责有牧羊犬（保护团队在Sprint内不受外界干扰），教练（辅导开发团队、产品负责人以及组织，有关于Scrum的知识），引导师（引导开发团队有关Scrum的会议或者其他问题解决），变革大师（不仅仅帮助团队Scrum转型，还要帮助组织进行Scrum转型）。
产品负责人，主要负责Say no。来决定哪些产品功能是不需要的。还有一个很重要的职责是最大化投入产出比，即保证团队在当前Sprint完成的需求，一定是当前最重要的。
开发团队，从名字上来看很容易混淆，而实际上开发团队包含了完成所有端到端工作的团队成员，而不仅仅是开发。可能有研发、测试、UX、DBA等。
这些角色在平时的工作中是相互协作，尽可能面对面的沟通。从而即时的反馈是非常重要的。
那么在反馈之前，我们需要把重要的信息，关键的信息，都可视化出来（透明）。
如下面的一些图片：
敏捷软件开发当中最重要的点就是，需要透明。回想一下上面的案例中，团队转型一定要尽量让团队坐在一起。这是保证透明的基础。团队坐在一起之后，团队间的沟通会比原来顺畅很多，信息也就很容易的暴露出来，即团队信息状态的透明。
还有，敏捷转型中的另一个很重要的基础设施是任务板。对于一开始实施敏捷转型的团队，我强烈建议使用物理的任务板。这会有非常多的好处。
- 团队信息以及团队进展的公开。
- 每个人每天都需要更新自己的任务，受到同僚压力，团队中滥竽充数的人几乎不存在。
- 任务板可以任意的进行重新规划和设计。（相比电子任务板）。
下面我们再来一起看看对于产品（内容）的反馈：
Sprint计划会，下面介绍两种开计划会的方式：
方式一：传统的两段式会议 – 第一部分由产品负责人和开发团队一起决定要完成什么（What），第二部分由开发团队来决定如何完成（How）。
方式二：循环式 – 1 产品负责人和开发团队选择产品Backlog最上面的那个用户故事，2 开发团队根据团队能力和以往的速率决定是否可以完成这个用户故事， 3 如果可以完成，那么拆分用户故事为任务，否则选择结束Sprint计划会议。4 重复上述1，2，3直到团队无法承诺更多的用户故事。
通过计划会，产品负责人可以知道在当前的Sprint中团队的关注点（重点）在什么地方。团队中每个人都知道什么是目标，整个Sprint大家会努力达成目标。因此计划会是对于整个产品版本的一个反馈。
每日站会
先说一下如何开每日站会：
团队围成圈，面对彼此，回答如下3个问题：1. 从上次例会到现在为了帮助团队实现Sprint目标我完成了什么？ 2.从现在到下次例会为了帮助团队实现Sprint目标我将会完成什么？ 3. 这个过程中我碰到什么障碍或问题？
可能有的朋友会问，我们团队的每日站会，可不可以每周二、周四开？感觉没必要天天开。
我的回答：不可以。
原因如下：
每日站会中，每个团队成员需要回答3个问题。通过这3个问题，我们可以得到两个层面的信息：
团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；
同时是否存在障碍
每天团队都会得到反馈，并可以根据得到的反馈做出调整。
如果不是每天开站会，那么就可能：
（1）团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；
（2）团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；
（3）团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。
Sprint评审会
常常我会听到有人说Sprint演示会议或 “演示”。这看起来只是说法问题，但是把评审叫做演示，它破坏了sprint评审会议的真正目的。
尽管演示是sprint评审会议中很有用的一部分，但这不是评审会议的目的。sprint评审会议最重要的方面是深度交谈和参与者之间的协作，以及使产品知识浮现出来并开发。
已经构建好的内容演示，只是一种激发围绕具体事情交谈的、非常有效的方式。而忽略了关于产品是如何工作的交谈。
sprint评审会议的目标是检视与调整构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。
同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个检视和调整产品的预定机会。应该叫做sprint评审会议，而不是sprint演示会议，
最后我们再来一起看看Sprint回顾会议。
曾子曰：吾日三省吾身。作为个人尚且如此，作为一个团队如何才能做到这点呢？在Scrum中提供了一个非常好的工具，就是回顾会议。
回顾会议可以帮助团队一起来反思，什么地方做的非常棒，我们需要继续坚持，甚至我们可以把优秀的经验传递给其他团队。另外团队可以反思什么地方做的有待提高和改进，团队一起找出原因制定改进行动计划。
这里非常推荐一本书《敏捷回顾》，这本书不仅仅介绍了回顾会议的5大步骤1.设置环境，2.收集数据，3.产生洞察，4.制定行动计划，5.结束：。还介绍了很多实用的小工具和技巧。
最后总结一下，Scrum的精髓其实就2个字：反馈。
扩展开来看，反馈是针对事实的，而事实需要透明，事实包含产品和流程两方面。