流程，通俗来讲，就是许多人，在做一系列的事情时，怎样相互协调，安排好这一系列事情的先后顺序，有什么事先的约定，需要达到怎样的预期目标。

    在UED里，前端同学需要处理的需求比较多，早些时候，前端这里的开发流程还是比较模糊的，UED以外的同学也不清楚这边的工作具体是怎样进行的，所以难免会有需求插队的情况发生，打乱了大家的计划，因此今年Q3的时候，在与SCM团队同学的共同努力下，形成了一个前端的ASSETS发布流程。

    这个流程主要针对ASSETS发布的需求做了一些约定，制定了相关的几个时间点，包括审核需求、提交代码、daily测试、预发测试、正式发布到线上确认的时间。

ASSETS流程简述

    需求审核

    在提需求之前，需求方一般都会先找PM或者相应产品线的前端咨询一下，如果可行的话就会在周四之前将需求提到平台上，到了周四的时候，前端会结合自身的工作情况，将平台上的需求接收并纳入自己的日程中，预估完成时间、发布时间以及相关的发布简述。

    编码开发

    周四需求评估完以后，就会按计划开始处理需求，将涉及ASSETS发布的需求优先处理，不涉及ASSETS的放在靠后的时间处理，一般这段时间是从周四到下一周的周二。SCM会在每周四开一个新的ASSETS分枝供前端在下一周开发使用。

    提交代码，合并到daily测试以及预发测试

    如果有涉及到与后台开发相关的需求，前端的同学会在周一就把代码提交，这一天会有一次合并代码，方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交，在周二，会有多次合并代码到daily的操作，每次操作完后，SCM的同学会在前端的群里通知到大家，方便大家测试。

    周三早上，SCM的同学会将代码发布到预发环境，此时就可以在HOST中绑定IP，换用线上的地址来测试。

    正式发布

    周四上午，SCM的同学确认后，将没有问题的代码发布上线。

流程的作用

    在团队不断成长的过程中，处理的需求数量也在增长，需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素，这个流程能为我们解决很多相关的问题：

    督促需求方做好相关的规划

    有些时候，一些需求的细节还没完全确定，但需求方总希望能将他想到的各种细节都实现出来，然后再挑选其中一种做为他的方案，所以需求的变更会有些频繁，然而这样的成本有些高，一切应该在计划后再去实现，而非反其道而行。现在需求方会在提需求之前，会花时间地去考虑他们的需求，将尽可能多的情况都想清楚，做好必要的沟通工作，权衡各种利弊之后，再给出一个比较成形的方案。

    保证需求安排的有序性

    在一个大的团队中，不同部门的同学在一起合作，因为沟通及一些特殊情况，效率或多或少会受到一些影响，良好的规划能有助于提高开发的效率。

    通过每周的需求审核，安排好下一周的日程，由于需求的优先级和先后顺序都已排定，工作的条理性会更加清晰，需求插队的现象也有明显减少。当然我们也有紧急流程，但是它仅限于处理线上bug以及一些经过多方确认的紧急需求，有其自己的适用范围。

    统一测试，归避风险

    之前的日常处理中，可能会遇到这样的情况：甲、乙两个同学分别需要处理两个日常需求，他们的需要改动到的代码会有重合的部分，如果他们并不知道这个情况，那么在他们本地的单独测试中，一切都是OK的，然而当发布到线上去时，发现出了bug或者一方的改动没有同步到线上，查原因后发现是提交的代码相互覆盖了。

    现在要处理的需求数量越来越多，为了避免上述情况，新流程实行以后，大家会统一来做多次测试，这样就更容易发现bug，可以大大降低协作开发而产生的风险。

    流程本身就是一把双刃剑，有利有弊。一方面，它使我们的需求变得有序，使前端能够在处理一个需求时，不会频繁被其他插队的需求打断。并且因为发布有时间点的设定，所以测试工作会更加严谨，这有助于提升代码的质量。因此对于我们来讲，流程带来的好处是显而易见的；但另一方面，它额外地增加了做事的成本，涉及ASSETS发布的需求，就像赶某班火车一样，错过了就只能等下一班，所以也给需求方带来了许多不便，有待改进，不过这可以通过长期的合作而慢慢被弱化，双方达成了一种默契以后，情况会好很多，现在这样的情况已经比较少了。

    尽管在流程使用之初，会带来诸多不便，但是从长远来看，流程有助于使一个团队形成统一的工作方式和态度，将繁杂的事情化整为零，有条理地去处理它们。因为流程，每一个人的责任感都会增强，对风险考虑得会更多一些，这一切都会使产品有质的提升。而我们所有与这个流程有关的人，都会不断地去推动流程改进的工作，这其中还有很多需要思考的：

如何将我们的流程推广到整个公司，让大家都能了解我们的流程，这样在未来需要合作时，需求方需要注意些什么，相关的时间点以及开周时间的预估等，他们就会心中有数。ASSETS的发布还不够灵活，如果把和应用相关的ASSETS独立划分出去与应用一起发布，这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程，根据实际情况来发布。如何来简化流程上的一些细节，在保持效率的同时，降低实际操作中的成本。 每周二是一个特别的时间点，为了赶在这最后时间提交代码，之前的开发会有些紧张，这种情况也有待改善，比如未来可以一周有两次发布。

    流程不是生来就完美，但从现在它带给我们的好处来看，遵循并使用它，对我们的开发会起到很大的帮助作用。我们对待它的态度，决定了它对我们会有怎样的反馈，如果觉得它不合适了，就发出自己的声音，想办法去改进它，不要只是被动地等待。

    ―――――――――――-

    部分名词解释：

    daily环境：UED的一个日常测试环境

    预发环境：外网IP，需绑定访问，供内部使用测试

    ASSETS：脚本和样式存放的目录

    SCM：软件管理配置

    PM：项目经理

建议继续学习：

1. 使用线框图来简化你的产品设计流程    (阅读：2864)
2. 产品UI设计流程    (阅读：2306)
3. 研发流程中与其他岗位协作效率的提升    (阅读：2151)
4. 产品UED流程及交付物    (阅读：1983)
5. 也谈前端开发流程    (阅读：1919)
6. 线下项目工作流程(归纳篇）    (阅读：1840)
7. 线下项目工作流程（分析篇）    (阅读：1709)
8. 产品评审那点事    (阅读：1637)
9. 说说产品开发到发布过程中的问题    (阅读：1561)
10. 策划流程一枚    (阅读：1332)