Scrum不是银弹，更不是灵丹妙药。                                                                                                                                                                 –《Scrum精髓 — 敏捷转型指南》

Scrum是一个框架，一种用于小团队开发的方法论，类比说来，这玩意和软件开发中的框架可以做个比较，比如Angular，开发中一定要用吗？你当然可以不用，够屌你裸写js都行（得到的结果还可能更好），但如果你不是那么屌，于开发效率和代码可维护性来说，在个人成长的初期，套用一些前人思考过的模板，照葫芦画瓢，然后通过总结和反思，把自己的东西加上去，慢慢形成自己的方法论。我想这无论于软件开发，还是团队架构，都是一条比较正确的道路。

这不是一篇介绍Scrum的文章，市面上介绍Scrum的文章多如牛毛，但如果不去践行，往往看不下去，因为都是high-level的东西，没有实践永远没有体会。这里我只想讲讲实习以来，Scrum在我们团队的应用，以及个人的一些反思。

Scrum如何应用于我们团队

Scrum中有三种角色– Product Owner(产品负责人，下称“PO”)，ScrumMaster以及开发团队。对应于产品的开发工作，其内容和流程大概是下面这张图（除了产品内部评审->预评审->验收->需求评审这一条时间线，其余工作没有明确的时间先后顺序）：

具体到我们团队来说，我们开发小组由3位前端，3位后端，2位产品，1位测试和1位组长共10人组成。上述中的验收回顾会议，需求评审会议以及每日站立晨会，如果没有特殊情况，这10个人都是需要参加的。

我们小组以一周为迭代周期，也就是说上面的流程每一周就会走一遍。更具体来说，周二上午需求评审（PO说明这周做什么，并且评定用户故事的故事点和开发时间），之后开发接用户故事去做，开发完成后给到测试，测试测完觉得没问题就把用户故事给组长（否则打回），组长review过代码后告知PO，PO确认所有任务后，就可以把代码合并了。周一由PO主导验收和回顾，顺利验收后周二进入下一个迭代。总的说来，因为做的是一个较新的领域，不断会有医院的需求加进来，所谓“小步快跑”，这样小的迭代也是为了保证用户爽。

有人可能已经注意到了，我们团队中没有ScrumMaster这个角色，这也是我们团队中欠缺的部分。我刚来时以为组长是代表ScrumMaster的，后来发现组长完全是代表开发团队的利益，而不是如很多教程中写的ScrumMaster的角色。用项目经理的话来说，这也是Scrum在我们团队中践行得不太好的一个因素。

我（PO）的工作

PO在我们的产品中就是产品经理的角色，也就是我实习的角色。PO的具体工作内容是什么呢？简短说来就是上面那张图我标红的部分。

对于一个PO来说，我每周的工作大概是这样的：

周一验收本次迭代完成的内容，主导验收回顾会议（所有开发人员都会参加）；

周二开评审会议（所有开发人员均参加），评定故事点，测试时间，和开发沟通并确认本次迭代的开发细节；

周三或周四开预评审会议（各开发总监和本组开发组长均参加），主要是评定某个需求技术上是否可行；

周五开内部评审会议（所有产品参加），主要是评定某个需求是否有做的价值和排列需求的优先级；

其余时间在准备用户故事，和开发人员沟通需求细节，参加每日站立晨会，下班前验收开发人员的工作，当然还有学习~~~

哪些地方可以优化

于开发团队来说（单指我们10人的小组），整个内部践行这种Scrum还算比较顺利的，但个人感觉无论于团队还是个人，都是有很多可以优化的部分的。对团队来说，主要表现在下面三个方面：

第一是由于我们有两个PO，迭代是轮值的，这样会导致一个问题–两个PO需要保持很顺畅的交流和对产品方向的高度一致，否则对产品的方向把握会产生问题，这或多或少会产生一些沟通上的问题或额外成本–比如我这个任务做不完，扔你的迭代做还是到下次再轮到我再做？这个我想这周做的，卧槽你怎么做了？当然这些问题都是因为沟通不顺导致的，如果产生这些问题只能说明PO的工作没做到位。

第二是如上述所说，我们没有ScrumMaster，而ScrumMaster是Scrum中一个很基本的职位。但翻看所有Scrum教程，ScrumMaster是一个有点“虚”的职位–保证项目推进过程中免受干扰，保证项目的推进效率… …这些都很重要，但是不是需要单独有一个人来做这件事呢？他又能怎么做呢？很少有书讲清楚这件事，这也是我最近在思考的问题。

第三是流程监控，每日晨会和当日验收是每次迭代中非常重要的部分，但如果控制得不好，很容易变得非常水–比如晨会上“我昨天在掰棒子，今天打算掰棒子，没遇到啥问题”，“今天就掰了下棒子吧，下班了”。我们把“掰棒子”换成工作内容，很可能就是开发人员所说的全部内容了。而开发人员有些敷衍的做法背后的原因很简单–你一个产品知道这些又没办法帮我解决问题，我遇到问题肯定找其他开发解决啊！这样就导致这两项工作很流于形式了，传递的信息量非常少，价值也有限。

有了对团队问题的反思，我接下来想讲讲我个人反思的几点：

第一，于我个人的性格来说，我不是那种很热情去沟通的人。比如团队另一位PO经常会下午大声提醒大家订饭，这种事情我做肯定比较尴尬… …但这是不是说我就做不好一个PO了呢？我想也不是这样，首先我们必须明确PO的目的是促进产品的推进和沟通的顺畅，只要开发人员都明晰开发细节，各环节的沟通都到位了，PO的任务就可以算履行得比较好了。至于与开发建立深厚的私交，这些都是bonus option了。当然这我会尽量注意，免得大家觉得我是个迂腐而不喜欢交流的人~~逃(>_<)

第二点来说，由于我们没有ScrumMaster，那么我PO能不能来承担这个职责呢？答案也是否定的。PO和ScrumMaster是代表不同的利益场的，PO要保证产品的及时发布，更多让用户爽。而ScrumMaster要保证开发内部的顺畅沟通和效率，更多让开发爽。一个人能同时做好这两件事，要么他是人际关系协调的高手，要么他就是人格分裂… ….

第三点的话，作为PO，应该对产品有更高的责任感，这点我确实是做得不够好的。其实PO这个角色其实挺有意思的，作为产品负责人，他应该管理产品的方方面面，这一点有点像一个工程的包工头，而手下的工人则是实现工程细节的人，于一般的工程来说，这是一种上下级的关系。而对应于Scrum软件开发来说，PO和开发人员是平级的，大家共同致力于打造好的产品，但负责的却是PO。相信大家已经看出来了，这是一种微妙的关系，如何处理真是一门哲学。

总结

还是那句话，Scrum只是一个框架和方法论，没有对错可言。如果一个团队的人能贯穿前后端，走通产品线，大多数事情能自己动手搞定，那我觉得这样的团队都不需要什么框架，一流人才自然能打造一流产品。不过在自己牛逼之前，还是先模仿，上升到技能，再慢慢培养成本能吧。

“没学会走想学跑从来不是问题，先问问自己是不是天才，如果不是，就要一步一步来。”                                                                                                                –《寒战2》