在目前的互联网公司，敏捷（Agile）的概念已经有相当的普及，人人都在谈，似乎不谈敏捷就不那么互联网了。几乎所有的互联网公司都不同程度的实施了敏捷。采用敏捷开发的方法也有很多，主要包括极限编程（XP）、Scrum、水晶方法（Crystal Methods）、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发（DSDM）、轻量级RUP、测试驱动开发（TDD）等等。而在众多的敏捷开发方法中，尤以实施Scrum比较流行。
对于我本人来说，接触Scrum有几年的时间了。在软件开发项目中做了一些Scrum的实践，闲暇时间也经常与业界Scrum同仁们沟通交流一些心得。同时，也始终在关注业界对于Scrum的一些新的认识和实践的书籍材料。在这一过程中，也促使我对Scrum有了更深刻的理解。
结合我的Scrum实践，本文主要从Scrum的认识，Scrum的实施过程以及实施Scrum带来的变化几个方面进行分享，解读一个可运行的 Scrum是怎样的。希望能给大家带来不一样的认识，并对Scrum实践有所帮助。
一、Scrum的认识
首先来了解一下Scrum的定义。Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的长度是2到4周。
在Scrum中，使用产品Backlog来管理产品的需求。产品backlog按照实现的优先级进行排序，以商业价值作为排序的主要原则。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称它为Sprint backlog。当Scrum团队完成Sprint backlog列表中的所有任务时，本次Sprint结束，进入下一个Sprint迭代周期。
Scrum有很大的价值，然而在有些公司推行Scrum却困难重重，有些人说Scrum没有什么实质性的作用，然并卵。为什么会有这样的认识呢？深入分析，原因主要有：
- 项目团队缺乏对敏捷的正确认识，单纯的认为敏捷就是快，就是追赶进度,就可以不受任何制度约束。大家可能听说过这样的对联，“这个功能很简单，怎么实现我不管。”横批：“明天上线”。也曾听说有些公司要开发一个新功能，因为实施了scrum，于是要求项目团队加班加点，将2周甚至3周以上的开发任务在一周内就发布上线。实施Scrum意味着项目团队“漫无天日”的加班，这导致了项目团队对敏捷有一种“恐惧”感；
- PO不能胜任工作，无法拆分有效的用户故事，或者用户故事拆分的不合理，无法实现迭代增量开发；
- Scrum对于自组织的团队要求很高，但许多同学认为自己达不到自组织的标准；
- Scrum倡导工作透明化，项目实时完成情况和每个人的任务认领情况通过项目看板和项目燃尽图一览无余，许多人对此不太适应；
- 在迭代的过程中无法及时发现问题，或者发现问题，无法有效解决问题，使项目团队有一种挫败感。等等。
如果对Scrum的认识仅仅停留在“上午有个点子，下午就要实现，晚上就能上线，是不恰当的。在我看来，Scrum肯定是有价值的，Scrum的主要作用包括：
- Scrum能够保证优先开发对客户具有较高价值的需求，更好的满足用户的需求；
- 与瀑布流程下的开发方式相比较，通过实施Scrum，能够提升团队一倍的开发效率，最大限度的发挥团队的作用；
- Scrum能够缩短开发周期，提高项目的交付效率。
但是，实施Scrum并不意味着不受项目约束，任性而为。那么实施Scrum的正确姿势是什么呢？
二、如何实施Scrum
（一）确定PO
PO即Product owner,是一个角色，PO是管理产品待办列表的唯一责任人。当然，在有些公司PO也可能作为一个组织而存在，比如我们公司在实施Scrum中就将PO作为了一个组织。
如果将PO作为一个组织运行，在这一个组织中必须选出一个Owner。作为owner，必须具有大局观；深刻了解行业信息与走向；能够把握产品的方向，担负起产品短期以及中长期的规划与管理；能够根据公司战略要求，进行用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求，不断进行产品创新。
另外，如果将PO作为一个组织，在软件开发项目中，PO小组可能包括的成员有产品经理、业务方、视觉设计师、交互设计师以及架构师等，在多数情况下由产品经理或交互设计师担任Owner。
（二）组建team
team是产品蓝图的真正实施者，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。team主要包括开发及测试人员。team必须能够落实PO对产品的设想。team的规模宜小不宜大，一般5~9人较为合适。
在敏捷开发中倡导的是团队人员的“全栈”能力，但目前在大多数互联网公司可能难于落实，比如多数互联网公司前后端开发是分离的，所以在组建team团队时需要特别关注前后端开发人员投入的比例。
以我带的2017年开发的“小钢店”小程序为例，前端和后端人员投入的比例为2:3时，能够最大限度的提升项目的开发效率。当然，这个比例必须基于项目中前后端所承担的具体开发任务情况而定，而不是随性给出。
（三）、选择Scrum Master
Scrum Master为过程负责，服务于PO和开发团队。Scrum Master要有仪式感，能够有效地、高效的组织迭代计划会、每日站立会、功能演示会、迭代回顾会等；Scrum Master必须具有高度的执行力，并保持公信力，能够帮助团队聚焦交付目标和质量目标，确保团队高效交付高质量的产品；推动团队建立高效的流程，指导团队了解敏捷价值观、原则和敏捷实践；负责培训团队其他成员，确保Scrum得到正确运用；促进团队有效的交流协作、问题管理、冲突解决，帮助团队消除一切障碍。
（四）、维护产品需求池
产品需求池是所有用户故事的集合，由PO依据公司的战略和产品愿景进行的思考。PO按照产品实现的优先级顺序对产品需求池的所有用户故事进行排序，并形成产品待办事项列表，产品待办事项列表相当于产品研发的“路线图”，要想了解产品的脉络，产品待办事项是最好的参考依据。
我们每一天都面对着新的竞争者和用户新的诉求，这意味着PO必须不断地优化自己的产品设计，并对产品待办事项列表实现的优先顺序进行调整。在这一过程中，PO应该与所有利益相关者和团队进行协商，以确保产品待办事项能够反映用户的真实诉求。
（五）、故事点评估
相对精确的评估工作一般都是在冲刺计划会上进行，并由负责实际开发及测试工作的团队对产品待办事项做出评估。在实践过程中为了让冲刺计划会更高效，在冲刺计划会之前PO与Scrum Master会作出一个粗略的评估。看看冲刺计划是否切实可行？要完成这些事项，现有的信息是否足够？用户故事拆分是否合理？
在开发团队进行评估时，建议摒弃传统的“人天”评估法，采用故事点的方式，用斐波那契数列的数字（1，2，3，5，8，13，21……）的形式去评估。评估时team需要首先确定一个用户故事为作为评估的参照。另外，特别注意的是当评估的单个故事点大于21的时候，用户故事需要进行再次拆分，单个用户故事点数不超过8是最理性的状态。
（六）、冲刺计划会
这是第一场真正意义上的Scrum会议。Team、Scrum Master、PO坐到一起，规划冲刺的内容。作为软件开发项目，进入规划冲刺的用户故事，用户故事应该已拆分完成，并且完成了视觉设计。冲刺周期一般是固定的，大部分是2至4周。团队要从产品待办事项列表优先级最高的用户故事着手，看看一个冲刺迭代中能完成多少。
如果团队已经开展过多个冲刺迭代，通过参考前几次迭代中完成的“故事点数”，团队可能预估到本次迭代完成的大概故事点数。“故事点数”相当于团队的速度。Scrum Master与Team应努力在每一个冲刺迭代中提高这个数字。
对于冲刺目标，即在一个冲刺迭代需要完成的事项， team所有成员都应该形成共识。在冲刺计划会上，PO需要告诉team用户故事实现的优先级顺序。team承诺在下一次冲刺迭代中他们能够完成多少用户故事。在冲刺的过程中，任何人不能单方面擅自变更冲刺内容。
（七）、每日站立会
这是Scrum的活力源泉。站立会参加人员一般包括PO、Scrum Master、team。团队每天在固定地点、固定时间进行内部沟通，时间一般为早晨，时长不超过15分钟，且站立进行，Scrum Master向team成员提出下列问题：
- 你昨天完成了哪些工作？
- 你今天计划做哪些工作？
- 目前的困难及障碍？
这样做的意义在于让整个团队清楚地知道在这一个冲刺周期内各项任务的进展。所有任务是否能够按时完成？Team的任务都不是自上而下分派的，而是自主决定、自愿申领的。如果前一个任务没有完成时，不能申领下一个任务，不能同时申领2个在当天不能完成的任务。Scrum Master负责消除团队面临的障碍。
（八）、项目看板及燃尽图
在Scrum中，必须做到工作透明化，最常见的做法是实施项目看板制度。有的团队善于借助第三方工具使用电子看板，比如Redmine看板，Leangoo看板；有的团队乐于使用线下物理看板。
无论使用电子看板，还是物理看板，看板的栏目大致包括待办事项、进行中事项以及已完成事项三个部分。随着迭代进度的推进，由Team每天及时将事项转移到对应看板栏目下。
让工作透明化的另一个工具是燃尽图。在这张图中，一个轴代表工作量，另一个轴代表时间。每天Scrum Master都会记录待完成的剩余点数，而后画在燃尽图上。理想情况下，该图是一条向下的曲线，随着剩余工作的完成，“燃尽”至零。
（九）、功能演示
在《Scrum指南》中将此环节称为Sprint评审会议，书中认为Sprint评审会议应该包括开发团队演示完成的工作并解答关于所交付增量的问题、评审市场或者潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变、为下个产品版本功能或能力的发布评审时间表、预算、潜在功能和市场等多个会议主题。会议一般在在本次迭代冲刺发布前召开。不过，从实践来看，我更倾向于此次会议最重要的工作是功能和成果演示，验证用户故事的实现场景，并接受评价。
这是一场公开的会议，任何人都可以是参与者，不仅仅包括PO、Scrum Master及team，还包括利益相关者、业务方与管理者，乃至客户。
团队应该只展示那些符合“完成定义”的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完整的产品，但至少是一项完整的、可以使用的功能。
（十）、冲刺回顾会
冲刺回顾会一般在本次迭代发布之后的第二天召开，会议时间最好不做具体的限制。
冲刺回顾会要认真分析以下几个问题：
- 发生了哪些有待改进的事；
- 为什么会发生那件事；
- 为什么我们当时忽略了；
- 怎样才能加快工作进度。
作为一个团队，要让这个冲刺回顾过程有效，团队需要相互信任。必须记住基于项目和技术问题的讨论和争论；对事不对人，不当和事佬，鼓励技术碰撞；不能把技术和业务讨论牵扯到人身攻击上去；抵制带着有色眼睛看人，引导大家理性讨论；勇敢接受别人的挑战，接受自己的不完美 大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。这一点是至关重要的。
最后，团队确定一个最值得改善的地方，将其设定为下一个冲刺迭代的首要任务，当然，改善的结果必须通过“验收测试”。你如何证明自己成功地完成了改善？你需要用具体的、可操作的方式界定什么是“成功”，这样，在下一个冲刺回顾会议中才能很快判断出是否已完成改善。
上一个冲刺迭代结束之后，开始进入新的冲刺迭代。
三、实施Scrum带来的变化
通过在Scrum项目中的实践，给我们的团队和项目组带来的变化主要有：
- 组织：
在瀑布流程下，通常会设置包括业务方、产品经理、项目经理、开发人员、测试人员、交互设计师、视觉设计师等多个角色，由于强化了不同角色的定位，而且不同角色又隶属于不同的职能部门，无形中增加了项目协同的难度。
在Scrum项目实施中，仅设置了PO小组、master和team团队这样的角色和组织，而且大家在一起集中办公，很大程度上淡化了角色隶属关系，形成了团队合力和向心力。
- 内聚：
团队合作的要旨是提高团队的内聚性，内聚也体现在个人工作焦点上，避免了一个人同一时段身兼多责。每个人都需要长时间的深度思考和环境浸染，如果天天在会上赶会，必定是失败的。
- 节奏：
用用户故事和站立会、冲刺会的形式，重构项目过程，细致而又绵密，灵活而又紧凑，减少时间死角，让需求等人而非人等需求。
- 尽早与客户互动：
实施Scrum，极大的缩短了发布周期，让我们的用户及早的感知产品，这对保持正确的产品航道有极大的帮助，也能更好的帮助公司做好战略上的决策。
- 透明：
作为敏捷实践，项目看板制度是必不可少的，通过项目看板制度，项目成员每天完成的任务情况一目了然，团队目标感明确，显著增强了工作的主动性和能动性。
- 心态：
深刻剖析和本地化执行scrum敏捷方法论，持续自省，自我革命，破除僵化流程，解除自我保护，项目团队能够“就事论事”的讨论问题，解决了管理“人”的难题。
2018年，我们将继续在用户故事点数预评估，项目燃尽图使用，代码质量，持续集成、自动化等方面进行深入的探索。
如同《敏捷革命》所说的那样，Scrum需要实践和专注，只有持续不断地付出努力，才能达到新的状态。我们在前进的路上，我相信，我们会越来越好！
