敏捷起来嘿哟嘿
今天和大家分享一下蜂窝正在经历的敏捷开发Scrum，Scrum是什么呢？就是前段时间微信之父张小龙絮絮叨叨的给几千名同事强调，一定要使用敏捷开发，一定要小团队作战。文末附链接。
那蜂窝为什么也在使用敏捷开发Scrum呢？
在今年的4月蜂窝从小规模的实验课程的过程中发现找到了需要更佳成型的课程。而这个阶段我遇到了一个问题，就是：
蜂窝该如何保证产品有持续的供给，到达用户，并进行迭代。
之前蜂窝在使用的是设计思维和精益的方法进行找用户问题，找解决方法，但是在我们找到用户问题，找到解决方案的时候，我们没有办法能保证我们的解决方案能变成一个可持续供给的产品。用人话来说，我遇到了几个问题，而这几个问题其实也属于管理问题：
- 管理团队共识：不知道如何在建立整个产品终点以及节点的共识。也就是最终，我们想象产品的样子，以及我们MVP之后每一次迭代阶段节点。
- 管理团队工作进度：有效的用户反馈。如果产品开发没有节点，是溜西瓜皮，那我们也不知道在什么时候能更好的去对用户进行访谈，对产品进行迭代了。
- 管理团队工作时间：团队人员协作分工。团队中每一个人能力都很强，但是我不知道如何评估大家在做事的过程中耗费了多少时间，是否需要帮助。
作为一个团队的 leader 很头疼这个问题……正好和Aha的社会创新学院的周贤聊到这些困扰的时候，她让我去搜搜敏捷开发，以及可以让我先尝试一下。（嗯……又是Aha社会创新学院，在蜂窝的创业上，确实我们有几个好老师～
随后我就开始通过维基百科以及知乎去了解别人是怎么用敏捷的，在这之中我发现敏捷开发与精益思维是一脉相承的，它既能保证蜂窝的产品从溜西瓜皮的方式转移到持续不断的产品交付给用户（家长和孩子）又能天然的适用教育产品中，因为教育产品有相对稳定的到达用户时间，又需要对用户提出需求之后有快速的响应机制，以及用户其实也是敏捷开发中的参与者。最重要的是让我如此心动的敏捷宣言，这也是蜂窝团队所追求的工作方式：
敏捷宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。
由此我们建立了如下价值观：
- 个体和互动：高于 流程和工具。
- 工作的软件：高于 详尽的文档。
- 客户合作：高于 合同谈判。
- 响应变化：高于 遵循计划。
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷开发的的过程方法有一个特别有意思的名字： [Scrum], Scrum 在英语是橄榄球运动中争球的意思。这里很形象的比喻了开发过程中看似混乱的场景，可是，这个过程中其实每一个参与Scrum的运动员都是有一个强烈的目标的。进球！
敏捷实操
下面我来说说，敏捷开发如何解决我们之前的三个问题的：我先简单介绍一下Scrum的流程吧（以蜂窝在线直播课为例），详细内容下文附超链接。
参与Scrum要求：当然要是认同敏捷宣言的。
参与人数：每个任务小组7人左右，保证有效的沟通。
Scrum角色：
全身投入：
** 产品负责人(product owner)：**目前是简长长担任。
她代表了家长与孩子的意愿。这保证了蜂窝做的迭代开发是正确的。
Scrum主管（或促进者）(scrum master)：目前是我来担任。
我的主要工作是去除那些影响团队交付冲刺目标的障碍。SM并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者，也是整个敏捷开发能否进行的关键角色。
开发团队(dev team)：目前是全团队的人有参加，原因是我们人少。负责参与产品任务的
不是实际Scrum过程的一部分，但是必须考虑他们
用户： 蜂窝所服务的孩子，以及为孩子购买服务的家长。
Scrum 过程
*准备工作
1.建立Scrum故事地图：
整个团队讨论，蜂窝的直播课程的最终样子。
以作为……（身份）
希望／需要…… （功能）
达到……（目的／需求）
这个时候，很好的解决的团队没有共识性的问题了，因为大家通过贴出故事卡片，所有人都明白，最终我们的产品的形态了。
2.找到MVP最小可行性开发方法。
通过Scrum的故事地图，找到可到达用户的最小可行性方案。
解决：管理团队共识
开始冲刺
确定冲刺周期：
由于蜂窝的课程是每周都要和孩子一起上课一次，那我们就以一周作为我们的冲刺周期。
确定冲刺宏观故事：
因为我们能看见产品的功能太多了，然而这么多的功能怎么能保证哪一个到达优先冲刺呢。即使我们有了MVP的方案，我们还是需要知道，我们的灯塔是什么。
比如蜂窝最近几个月的宏观故事是：
作为蜂窝，我们需要在未来4个月内达成收支平衡，让我们能活着完成蜂窝的使命。
那这样其实我们所有的故事都会指向，我们这样的开发会影响我们未来四个月的收支问题吗？
确定每周的冲刺故事：
由 ** 产品负责人(product owner) ** 带领大家筛选出这周的故事，然后进行评分／估时。这个过程中就会产生谁负责此项故事的开发工作。
评分：是作为大家一起来判断这个事情对于用户／蜂窝的宏观故事／收支／开发难度等进行几何数值。如果分数过大，可能会拆分成小故事。 蜂窝用斐波那契数列：1, 2, 3, 5, 8, 13, 21 进行来估分，这样方便我们来进行拆分故事大小。
估时：完成此项任务所需要的时间。
解决：工作进度的管理，以及对工作时间的管理。
以上就是整个过程，是如何解决蜂窝遇到的问题的。不过，仅仅走完这几步只是开始，最重要的是需要完成Scrum里面的4个例会。
Scrum会议一共包含以下四种：
- 冲刺计划会议
- 每日站立会议 不能多余15min
- 评审会议
- 回顾会议
蜂窝在执行的时候只分为两个。
- 每日站会
分享昨天你完成了那些工作？今天你打算做什么？完成你的目标是否存在什么障碍，需要什么样的帮助。 - 评审+回顾+冲刺计划会
对每一轮冲刺的过程中，故事卡片停留在什么位置，为什么会停留在那里，遇到什么问题，进行追踪。同时回顾这一轮冲刺完成后感受，马上建立下一轮的冲刺计划。不过经历的时间由点长，我还在准备持续优化一下。
这里其实也工作进度的管理，以及对工作时间的管理，而且在会议的过程中优化工作进度／时间管理
意外发现的亮点
在敏捷的过程中，其实还解决了一些我试图想在团队中体现，并没有方法实现的价值观。
- 共建：故事是大家根据用户发现的，不是谁想象出来的东西。
团队中的每个人对项目与产品的拥有感极高。
- 分权：每一个项目都有一个项目拥有者。
- 效率：可基于故事卡片对整个团队效率管理。
这样可以化解了一些在讨论事情的时候对方会误解是在评论人。这样我们可以很轻松的讨论故事卡片，而不用在意对方是否是在对人不对事。
一些贴士：
- 每一个故事执行前需要验证故事真实性，以及验收标准。
- 大家是都是针对故事，而不是针对人。
- 需要质疑，需要摩擦，才能让大家面对真实的用户故事，而不是想象出来的故事。
感谢Aha社会创新学院，ThoughtWorks的P3团队对蜂窝敏捷Scrum的指导。
张小龙文章：微信之父张小龙最新内部讲话：警惕KPI和流程
敏捷开发 维基百科词条
Scrum 维基百科词条
推荐两本书：
《轻松Scrum之旅》《硝烟中的Scrum和XP》
