新媒体研发主要干什么，新媒体研发主要干什么工作？

「声动派」，专注互联网价值传播，为你分享大连接时代的一切！

大家都知道，现今互联网行业的趋势，是持续、快速地进行新概念、新产品的试错，并不断地进行产品、战略上的调整。而敏捷的指导思想正是小步快跑、不断试错、持续改进，这正好顺应了互联网公司做产品的演进模式。

因此，现在的主流互联网公司大多数都采用了敏捷和迭代的方式进行产品的开发。所以，今天笔者要跟大家分享一下关于互联网新媒体产品研发的敏捷转型。

敏捷团队从0到1

对于一些新兴的创业公司，在进行敏捷转型的初期，并不一定马上能组建跨职能的团队。常见的原因例如：

1. 公司刚刚成立，很多职位还在陆续招聘中，一个萝卜一个坑，先把需要的人招聘到是首要任务。

2. 按照以往的企业架构组织划分，每个部门各司其职，分：研发部、软件开发部、产品部、运营部、设计部等等。

3. 办公场地有限，只能尽量安排同一个部门的员工在同一个办公场所。

在这种情况下，再加上必然存在的跨部门沟通，就很容易导致一个后果：信息传递滞后，甚至偏差。

沟通的效率

以我们公司以前开发一款APP的情况为例：在早期的开发过程中，界面的开发有以下工序：

1. 产品出线框图；

2. 设计部做UI设计；

3. 产品评审UI设计；

4. 美工与开发人员定义切图方式，美工切图，交付开发人员；

5. 开发人员进行UI开发；

6. 开发完毕之后交付测试人员进行测试；

7. 测试通过后交付产品进行验收；

8. 上线；

类似下图所表述的情况：

这个流程其实涉及到多方进行协作，我们遇到的问题是：美工切的图有时候没有达到开发人员定义的要求，例如图片大小不对、dpi不对、不同机型下图片素材缺失等等。这些情况导致开发工程师无法交付产品，拖慢开发进度。

由于分布在不同的办公室，开发工程师与美工的交流方式大多数时候是通过及时通信工具进行的。有时候一个美工需要对付多个开发工程师，会出现消息满天飞的情况，也分不清问题的优先级，往往完成了A工程师的要求却漏掉了B工程师要求的工作。开发工程师也会因为美工交付的多个素材版本而乱套。

关于沟通的效率问题，有个著名的7-38-55规则，可以简单理解为对应于文字、语音、视觉语言这三种沟通方式被听众接收的程度。虽然准确地讲，这个比例更适用于涉及情感情绪的那类沟通，但基本原理还是相通的。

在上面的例子里，可能有人会有疑问：为什么不当面沟通呢？因为当时的人员分布是按部门的，要找到你的上游或下游人员，需要跑进跑出，甚至要跑到另外的楼层，当面沟通的成本还是相对较大的。

为了改善这个状况，我们尝试过几种方法，例如：让美工把切图素材上传git做版本管理，并且在git上设置webhook与我们使用的IM工具集成起来，实现素材更新后就能通知到相应的群。同理在产品方面，需求有更新，也通过这种方式通知到群或者是通过邮件通知相关人员。另外，有一些在线协同工具，也能起到改进作用，比如用在线卡片的方式把相关的信息和人员组织在一起，也支持通知。

大办公室

在敏捷宣言里面有一句话：个体和互动高于工具和流程。上述种种，都是在工具这个层面上设法增进个体之间的互动。我们也通过实践体会到：组建一个在同一个办公室的跨职能团队有多重要。工具虽然好用，但是如果没有养成即时沟通的习惯，达到减少沟通成本的目的，我们还是不够敏捷的。

于是我们还是争取到了相应的资源，把产品团队需要的角色都安排到了同一间办公室，正式组成了跨职能的团队。

这项表面上看似有些“劳民伤财”的举动，事实上带来了不少好处：?对?的沟通降低了沟通成本；开展Scrum活动更方便；增强了团队凝聚?；团队成员更容易提起互相学习提高的动力；有利于营造组织?化和氛围。无论是否感觉到，实际上在潜移默化中，团队中的每个人都能体会到这种“济济一堂”所带来的改变。

看板 or not 看板

在 Scrum 活动里把信息可视化的较佳实践是使用看板。看板是支持整个生产系统运行的有效工具，并且是促进改进的极好方式。通过看板，能够有效地反映工作的进展情况，以及团队自身的状况。

看板形式多种多样，电子版的产品国内外都有，选择甚多，使用物理看板的也大有人在。使用何种形式因人而异：

▎电子看版：

特点是：随时随地有网络就能访问；修改方便。

适用于：跨地域团队；对电子看板有使用上的共识和默契，并遵照共识、积极主动开展协同的团队。

▎物理看版：

特点是：促使团队“不得不”聚到一起沟通；物理卡片使用起来更有感觉——无论是任务的归属感、还是团队进度的时间感。

适用于：坐在一起的团队；比较“安静内向”，需要鼓励多碰面说事、谈问题的团队。

自组织

我们常说敏捷团队应当做到自组织（而不是被组织）。

▎什么是自组织呢？

自组织是从最初的无序系统中各部分之间的局部相互作用，产生某种全局有序或协调的形式的一种过程。这种过程是自发产生的，它不由任何中介或系统内部或外部的子系统所主导或控制。网上搜“节拍器 共振 视频”，便能感受到自组织带来的奇观。

自组织并不是放任不管、让大家各做各的，而应该是引导团队、让大家得出一致共识，从而统一目标进行协作，劲往一处使。

自组织隐含着“独立自主”、“当家作主”的意味。团队的 ScrumMaster 需要想办法建立团队的勇气，鼓励成员通过完成给出的承诺来赢得大家的尊重，才能建立起自组织的文化。

在敏捷转型的初期，ScrumMaster可能会经常忍不住参与到团队的讨论当中，影响成员的决策和承诺，这样其实并不利于自组织工作方式的养成。更好的做法应该是鼓励团队每个人都积极参与到scrum的各个事件当中，并尽可能多的发表自己的意见。

当团队中的某个成员的意见越来越多地被其他成员认可之后，这位成员也会逐渐变得更有自信，也更有影响力。而一个积极讨论和沟通的组织，也就能更迅速地达成共识，协作起来才会更协调，从而自组织的效果才会更好。

大局观

还有一个决定团队自组织效果的因素，那就是大局观。团队在敏捷转型初期容易陷入一个误区：进入日常工作以后，每天就只知道按部就班完成自己的任务，只低头赶路，却不抬头看路，往往忽略了整体迭代的状况，往往到了最后一两天，发现怎么看似简单的几件工作，居然样样都无法干净利落地交付生产。

作为ScrumMaster，有责任在站立会上提醒团队需要兼顾迭代的整体状况，在必要的时候进行调整。燃尽图是一种很好的工具，供我们实时追踪当前迭代的进度。主流的电子看板基本都能自动生成燃尽图，物理看板也很容易导出燃尽图。根据燃尽图，我们能直观地看到进度是否滞后，从而提醒团队进行应对。

（电子看板的燃尽图)

(根据物理看板算出的燃尽图)

站立会时，成员更新完各自的状态，移动完卡片，对于电子看板，就能自动算出燃尽图，摆出来展示了；对于物理看板，可以由 ScrumMaster 在会后更新图表，再群发给团队。

关于物理看板再还有一点经验可供分享：推荐采用上面例子的 burn up 图，而不是常见的 burn down 图，因为前者比较便于手工修改。这个burn up 图采用类似下面的电子表格制作生成：

当天完成的点数，很容易更新在那一天的“完成点数”栏。而总体的点数每天可能会有变化（一般是增加），那么就可以更新在每天的“总点数”栏。这样预期趋势线就可以实时自动更新，从而反映出在新的情况下，团队是否仍能“赶得上”总目标。

冲刺回顾

冲刺回顾会议是Scrum团队检验自身并建立改进计划的机会。但是在敏捷转型初期，冲刺回顾应该是团队觉得压力最大的一项 Scrum 活动了，为什么呢？因为转型的初期，前几次冲刺往往难免失败。这应该是大部分敏捷团队经历过的普遍现象。

其实有一种说法颇有些道理：作为 ScrumMaster，有时候应该踹团队一脚，加速迭代的失败，因为这样才能快速地让团队发现问题，尽快试错，进行改进。

迭代的失败可能因为技能不足、任务复杂、考虑不够全面等原因，但是团队从中亲身体会到问题，吸取教训，才能迫使自己思考问题的原因，以及改进的方法。

想要让团队在轻松愉快的环境下畅所欲言，说出团队需要改善的地方并进行承诺，对于 ScrumMaster 来说其实是挺有挑战性的；起初，在我们的组织冲刺回顾会议上，大家轮流发言，会议的总体气氛还是比较沉闷的，而且效果比较差，每个人发言完毕之后也容易开小差。

其实冲刺回顾既然是冲刺的一部分，它也应该可以在冲刺回顾上进行讨论。作为ScrumMaster，可以在回顾会议上发起“如何开一个好的冲刺回顾会议”的讨论，也可以在其他时间单独和成员们聊天，了解他们倾向的冲刺回顾形式。ScrumMaster 还可以通过问卷调查的方式收集团队对 Scrum 的看法、接受程度和建议。总之，形式多种多样，ScrumMaster 可以大开脑洞寻找适合自己团队的形式。

这里跟大家分享一个小例子：

有一个 Scrum 团队，他们有一次的冲刺回顾用写信的方式进行，分别写一封情书和分手信，同时 ScrumMaster 还制定了一个奖励机制，谁信写得好， ScrumMaster 个人请他喝咖啡。

有人就这么写了：

?情书：

亲爱的TDD：

自从认识了你，让我对测试有了新的认识。用了你之后，我的开发效率得到了很大的提升，代码质量也好了很多。最怕你生气脸红，最喜欢你展现的那一抹绿色。有了你之后，我能够大胆地对代码进行重构。希望能和你一起在开发的路上一直同行。

?分手信：

不好的变量命名：

由于你的存在，给我在代码的可读性和可维护性上造成了很大的困扰。因为你，我的代码好几次不能通过代码评审。再见吧，愿你也不会出现在其他人的代码世界里。

敏捷路上刷经验值

任务拆分的进阶之路

任务拆分是个技术活，看似简单，其实太难。下面看看我们亲身踏过的进阶之路。

▎第一阶段：

负责人：Product Owner

拆分方式：按照大功能点拆分为前后端两个任务

范例：比如注册功能，分为“注册功能前端”、“注册功能后端”

结果：任务过大，没办法跟踪任务进行状况；任务开发周期过久，开发压力山大。

▎第二阶段：

负责人：Product Owner

拆分方式：按照大功能点拆分为小功能点，再分前后端两个任务

范例：比如注册功能细分为账号验证功能、密码校验功能、手机验证码功能等，针对每种功能再分为前后端，如“账号验证前端”、“账号验证后端”。

结果：开发任务状态大致可以了解进度，但往往前端是某一个前端开发来包干，每个后端是某个后端开发来负责；任务开发的时候存在并行交叉的情况，什么时候能够完成交付一个完整的功能？没人知道，似乎也没人在意；测试介入也需要整个大功能点完成后才能测试。

▎第三阶段：

负责人：Product Owner

拆分方式：按照验收条件拆分任务

范例：比如“注册账号格式检查（字母和数字组合，长度不超过20个字符）”，再分前后端，“注册账号格式检查前端”、“注册账号格式检查后端”

结果：验收条件并不能很好的总结任务，任务之间存在交叉；开发上仍是多任务乱序并发进行。不能很好的反映开发人员正在进行的任务。

▎第四阶段：

负责人：Product Owner + 开发团队

拆分方式：产品经理只列大功能点需求，由开发人员自己拆分细节任务，拆解成端到端的完整的可交付用户故事。

范例：比如产品经理只登记“账号注册功能”，大任务下用备注说明所有细部要求，包括字段长度格式等；开发人员了解需求后根据实际情况，自己拆分细节任务，比如 “账号功能领域分析”、“账号注册功能接口合约定义”、“账号验证功能”、“密码校验功能”、“手机验证码功能”、“账号注册接口整合测试脚本开发”等。

结果：能较好的反应实际的工作任务，任务状态能够良好的跟踪，测试也可以提早接入进行整合测试。

简单总结一个坑：横切的方式（例如XX前端、XX后端），看似自然，但实际将负责人分割到不同的自然人身上，很容易出现“三个和尚没水吃”的情况：各自做自己的活，总认为有些公共的活会有别人做，结果到最后才发现真的没人做。而纵切的方式，一个人挑大梁，往往就能激发个人的主人翁意识和行动力，而且干的是全栈的活，什么本事都能锻炼，最终反而更能够交付高质量的成果。这也就是为什么一个和尚反而能挑水吃的道理。

结对编程

无论代码评审，还是结对编程，都是为了多几双眼睛，来检查代码里的潜在问题，或者提出改进的想法。代码评审相对常见，下面主要聊聊结对编程。

结对编程是存在一些不太适用的场景，例如：结对的双方各持己见、难以达成共识，或者思路走不到一起，那可能各自分开按照自己想法做一套、再来比较优劣，更加有效。而除去这些极端情况之外，结对还是有其积极意义的：

1.配对压力

这种机制很容易理解。两人坐一起的时候，他们会花更多时间进行实际的编码和决策，而不至于随随便便就开小差。此外，当遇到需要思考的问题或者遇到很大的困难时，两个人很自然就会进入讨论或者攻关状态，而一个人可能干脆就给自己放假了。同时，也是因为这种压力的存在，结对的时间不宜过长，一般每天一个小时就好。

2.谈判交锋

当两个人在一台电脑前碰面时，他们会带来两套不同的体验、技能、态度和想法。双方最终建立的是这两种方法的谈判效果。谈判出来的解决方案往往比其中任何一个人想简单完工所想出的方案要好得多，尤其是完善得多。

3.配对评论

代码审查很困难，大多数团队最终要么放慢流程，要么没能从审查中获益太多。此外，代码审查发生在代码编写之后，因此许多决定已经定形并且很难撤回。而在配对的时候，代码评审自然而然成为无法回避的事情，从而会迫使主笔人必须专业地对待自己写下的每一行代码。

4.配对学习

团队通过循环进行配对编程，比单枪匹马的人学得更快。速度不好说具体有多快，但毫无疑问，结对时的学习速度快很多。这意味着，如果你在从事结对，那么在一个季度以后，你的水平会比独行侠高出一大截，半年后差异更大，并在一年后……（你懂的）。

这个事实会对某种人尤其有影响，就是那些6点准时下班然后“没有时间学习”的人。他们中的很多人都很聪明而且雄心勃勃，只是不想花时间学习。这类人为数众多。对于这些人来说，配对编程会让他们的成长速度产生非常巨大的变化。

5.配对信任

结对编程的团队会增进信任。他们会知道彼此的强项和弱点。信任度较高的团队工作得更好，交付速度更快。

6.配对勇气

编程可能会在很多场合下令人恐惧。做出好的设计或架构决策是很困难的。触摸一段遗留的代码并重构它需要勇气。当产品人员提出个糟糕的时，说“不”也需要勇气。双人往往有更多的勇气去做正确的事情。每一个好的决定都会带来回报。

7.配对调试

最后是结对调试。很多情况下，调试的人没法一下子知道问题在哪，而且通常需要花费很多时间才能查出来。所以当一个人正在查这个bug、并且被卡住时，另一个人可能因为旁观者清，反而更容易发现问题。

所有这些加起来，并随着时间的推移，会使得团队更高效。

以上，就是敏捷团队转型中的一些经验分享，希望能对您的团队有借鉴意义，助您打造更强的敏捷团队。

*本文著作权归作者所有，转载请联系作者获得授权。