Scrum模拟微信看一看“疫情专区”的敏捷开发过程
无论作为产品用户还是管理咨询顾问，都非常非常喜欢微信。自认感情比较克制属于“高冷”挂，但从很多方面都太佩服太崇拜张小龙了（新书里微信也会是最喜欢的案例之一，真的不只是一个产品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆发后，微信的响应大概最快速也相对最到位的了，看一看立马有了“疫情专区”（不知道官方名称是什么，以下暂以此代称），对于了解疫情整体数据和最新动态都很有帮助，真是觉得太棒了。
之前了解到微信也是使用敏捷开发，最近也在筹备ASM实战课程和Scrum咨询服务产品，奇葩开个脑洞用Scrum YY一下看一看“疫情专区”开发过程，也通过这种方式简单科普一下敏捷开发基本理念与价值以及Scrum的流程实践吧。
本文包括4部分：
- 敏捷开发基本理念与价值
- 敏捷开发实践方法
- Scrum的3个角色与5个活动
- 如何通过Scrum实现微信看一看“疫情专区”
敏捷开发基本理念与价值
敏捷开发根源于适应性项目管理和精益开发，相较于传统基于“预测+规划+控制”的瀑布式开发方式，能够适应需求变化的风险，及时理解与响应客户需求，通过周期迭代交付可工作的增量产品的方式，增强项目管理灵活性与可预测性，并基于团队责任制的工作理念运行，借鉴精益管理理念与优秀实践，流程效能高，能够显著优化开发成本，提升产品质量与竞争力、客户满意度、团队及干系人满意度。
就像微信看一看的“疫情专区”，这肯定不是在原来的开发计划之内的。当外部发生变化，敏捷团队不会还按原来的计划生硬刻板执行，而是及时识别需求，并且能够快速在产品层面实现，从而应对变化，就是敏捷对优秀产品竞争力的赋能。
敏捷开发实践方法
Scrum是敏捷开发的具体实践方法之一，优点在于覆盖开发环节广，具体方法的执行意见最全并且可实施性最强，定义了非常详细的团队角色职责与实施流程步骤，量级轻很容易理解上手，不过想要精通会有难度。
Scrum可以概括为“3355”，也就是“3个角色、3个工件、5个活动和5大价值观”。下面就用Scrum模拟一下微信看一看的“疫情专区”可能是怎么实现的。
Scrum的3个角色与5个活动
先简要同步一下Scrum的3个角色与5个活动。
Scrum的3个角色包括SM(Scrum Master), PO(Product Owner)和Dev Team(Development Team)，职责如图所示。
Scrum的5个活动包括Plan Meeting, Sprint, Daily, Review和Retro，简介如图所示。
如何通过Scrum实现微信看一看“疫情专区”
回到微信看一看“疫情专区”，用Scrum来模拟一下，包括Product Backlog, Plan Meeting&Sprint Backlog, Sprint&Daily, Reveiw&Increment和Retro5个环节。从软件开发整体过程来看，首先是规划。
4.1 | Product Backlog
这里涉及到Scrum的2个工件，就是Product Backlog和Sprint Backlog。Product Backlog需要PO定义产品愿景，再根据产品路线图和版本发布规划（决定项目范围、日程和资源）规划Sprint Backlog。
Product Backlog根据需求的层级和颗粒度可以分为史诗、特性和用户故事。
比如微信这个产品可能是一个开发项目集，“看一看”有可能只是其中的项目之一，“朋友在看”可能是一个“史诗”需求，“疫情专区”是一个特性，在这之下再创建颗粒度更细的用户故事。
用户故事（User Story）是从需要该新功能的用户角度对需求进行短小简单的描述。标准格式是：As a <Role>, I want <Activity>, so that <User Story/Business Value>（作为一个<角色>， 我想要<活动>, 以便于<商业价值>）
比如大家点击看一看顶部的这个数据仪表盘，可能是这样的一个用户故事。
相较于传统的文档而言，用户故事的优点在于把需求编写和责任划分转移到沟通与理解。Product Backlog是一个动态管理的过程，不需要一下把所有的需求都写完，而且需求的内容和优先级等可能随时会变化，PO保证一定数量的用户故事比较详细可以用于接下来Spirnt Backlog的规划即可，过程中对Product Backlog进行动态的持续梳理维护。
4.2 | Plan Meeting&Sprint Backlog
下面Scrum的第一个活动可以开展了，就是Plan Meeting。假定一个迭代两周，这个迭代的目标就是“上线‘疫情专区’帮助微信用户快速了解疫情相关信息”（敏捷开发灵活响应变化的优势很明显不是吗？）。
Plan Meeting在确定Sprint目标后，需要理解和估算User Story确定Sprint Backlog。
比如现在，我们就会根据优先级把待规划的需求一个一个讨论，PO需要回答Dev Team提出的问题，确保Dev Team对用户故事都充分理解，从而更好地规划之后的工作。比如针对刚才这个用户故事，Dev Team可能就会开始讨论：要不要通过手机定位优先推送本地信息？要不要加入新增数据？累计治愈是绿色的，其它的是白色还是忘了选颜色？PO会根据这些问题逐步细化需求，最终打开团队共识。
在充分沟通理解用户故事之后，Dev Team对用户故事进行effort估算。估算可以采取故事点（Story Points）或理想小时/天数（Ideal Hours/Days）。
Product Backlog中的用户故事就这样从右边进入左边的Sprint Backlog。至于放入多少合适呢？
根据过去的数据统计，我们的团队速率（Velocity，即每个Sprint完成的用户故事故事点均值）是18.58个故事点，现在已进入Sprint Backlog的用户故事故事点已经18了，那么我们就先放入这么多的用户故事，不再添加了。
接下来Dev Team会规划用户故事下的具体工作，不是被动地执行被分配好的工作，而是看哪些工作需要进行才能够很好地实现用户故事。成员自主领取工作任务后，我们就正式愉快地开始Sprint啦。
4.3 | Sprint&Daily
Sprint期间每天要开Daily（每日站会），同步接下来一天的工作。Dev Team成员直接对着任务板轮流回答三个重要的问题（不是“你是谁”、“从哪儿来”和“到哪儿去”，虽然本质类似）：
- 前一天做了什么帮助达成Sprint Goal；
- 今天计划做什么；
- 遇到的问题和困难，或者看到了哪些问题可能会导致Goal无法达成，但不就问题的解决展开讨论。
过程中跟踪进度常使用的工具包括任务板、燃尽图、停车场图和甘特图等。
4.4 | Review&Increment
Sprint工作完成后通过Review验收Scrum的第三个工件-增量（Increment），即可工作的软件。之前看到一个团队竟然Review的时候是一堆程序猿面红耳赤地评审代码？嗯？这操作就有点儿迷了。正确的姿势是Dev Team直接进行产品演示，确保交付增量是可工作的软件。比如对于“疫情专区”，Review可能是工程师们手机投屏直接演示功能是可用的。
4.5 | Retro
Review之后是Retro，回顾哪些方面执行比较好应该坚持做、哪里需要改善以及具体如何改善，可以在Review直接连在一起开。
然后的然后就是我们打开微信看一看，就有这么一个非常棒的“疫情专区”了。
当然，以上内容只是通过Scrum基本流程简单模拟一下，中间还有很多内容和细节没有展开。就像前文提到的，Scrum量级轻容易实践，然而想要做得很好其实是非常难的，可产生的效益以及对效能提升的帮助，却也正在于实践的深度。
像去年接触研发团队格外多，发现绝大部分团队说是敏捷转型几年了，实际都不到文化层面，实践层面还有很多非常不敏捷的地方，刚才的“代码评审式Review”就是一个例子。大部分团队的“敏捷”只是“短周期瀑布式开发”，开发模式完全没变，只是把周期缩短为半个月或一个月，其实跟敏捷毫无关系，所以转型几年依然没有产生任何效益。
敏捷开发的优势已无需证明，关键在于从价值的认知到行动去践行、享受价值。Worktile的新使命也是“智简研发”，产品和咨询服务都会在助力研发效能提升方面持续发力。从咨询服务方面而言，除了适用于企业整体运营管理的OKR，在疫情平稳后，会上线全新的敏捷咨询服务，首期服务就是基于EXIN ASM课程体系的实战Scrum课程与咨询服务。
这一服务产品还是秉承WMC团队一贯的实战风格，不是讲讲空洞的理念和基本的方法做些游戏就可以了，而是融入了团队几位微软MVP与业内资深敏捷专家近十年的实践经验总结，设计实用性极高的内容、教材与实践手册等，通过对Scrum体系的全方位深入实践讲解、应用模拟、实战问题全面识别解析以及变革全流程管理，帮助企业真正做到“We do Scrum”，更是实现“We are Scrum”的进阶。放一个课件的部分preview，整个产品正在反复打磨，期待春暖上线，给更多研发团队敏捷转型提供到一些实在的帮助。
最后从产品角度作为迷妹再次表白两个人，一位当然是张小龙，还有一位是Worktile CTO-Terry。微信在我看来不仅仅是一款产品那么简单，而是一个强大的生态，是很多优秀管理实践的最佳化身，之后也会针对微信做更深入的案例剖析。
另外表白的就是Terry~本文中演示Scrum流程使用的产品截图就是去年Worktile六周岁时发布的全新研发系列产品之一：Agile-敏捷开发，也是国内唯一一款标准的即开即用专业Scrum管理平台。除了Agile，目前正式发布的还有Testhub-测试管理，还有更多重磅产品真心值得期待。Terry是Worktile产品的灵魂工程师，包括之前Teams这个产品，真的是在极致专业之下才能打造出这么强大流畅好用的产品，细节之处尤见用心（话说Terry迷妹迷弟也是多到也排不上号sigh······）。对于管理实践落地与固化，尤其是研发场景，产品的价值尤为显著。也希望Agile、Testhub和接下来的咨询服务，能够一起帮助更多研发团队更好地实现敏捷转型，以更高效也更愉悦的工作体验解放研发生产力，创造出更多惊艳的优秀产品。
产品角度之外还要表白一下我们Worktile首席科学家徐子岩老师~徐老师是前微软高级项目经理，连续六年获微软MVP，研发管理实战经验非常丰富，在研发管理咨询服务产品开发过程中提供了莫大的宝贵支持，也是我的Scrum最佳第一老师，希望之后的服务产品能够把徐老师的一线独到经验更好地传播到更多敏捷团队~还要特别感谢男神对本文的专业支持，手动笔芯~
本文作者：王晓萱