WCS，作为公司云化迁移改革的首个盈利项目，应该说整体上是比较成功的。首次作为项目负责人，我在这3个月中成长了太多太多。12月23日，我对公司全体员工做了WCS的项目汇报演讲，以下是经过整理的讲稿。
大家下午好
今天跟大家分享一下我们最近做的一个项目——Weixin Coupon Service，简称WCS。但是大家可以看到这个副标题：From Sprint 0 to more possiblity，这个是什么意思呢？待会儿解释。
大家在京东、天猫这些网店或是线下的一些卖场经常会看到五花八门的促销类型，比如满2件打9折，满3打7折，诸如此类。那么我们Eland时装能不能实现这些复杂的促销和发券的方式呢？WCS之前，答案是NO。这就是我们项目的起源，通过提供新的促销和发券方式，为活动创造更多的可能性，提升品牌的营业额。
所以从9月下旬，我开始参与WCS的设计，经过N次会议，整个设计一再的更改，就连项目的名字也是经过多次修改：一开始叫WxCRM，后来改成BizEvent Management（活动管理系统），最后终于确定是Weixin Coupon Service，之后经过1周的开发，11月3号，我们的第一个正式版本上线。之后我们引入了敏捷开发，经过一个半月的时间，发布了两个Release版本，逐步把系统做完善，易用性和稳定性不断提高。其实在座的很多都做过不少项目了，所以单纯介绍项目没什么意思，今天我想讲讲，和以前相比我们这个项目不一样的地方，以及我们做出的尝试和探索。
以前当我们要做一个项目的时候，是首先确定人员，确定一个大的方向，然后由上海或者是韩国的业务部门做设计，我们所要做的，就是拿着页面定义书开发就可以了。那如果在运维阶段想要新的功能了怎么办？一般就是添加页面，所以我记得当时运维EFMS的时候，几百个页面，非常可怕，但是顾客真的用的了那么多页面吗？
所以我在参加设计会议的时候，得到的信息是非常多而且没有头绪的概念。那么我应该如何组织梳理这些概念，把它们转化为代码逻辑呢？我的思路就是：
产品视角
我首先站在顾客角度，思考这个系统应该具有什么样的功能，操作流程是怎样的，然后画出UI，之后根据UI，大家再来讨论。举个例子：上海提出一项需求，就是按顾客等级每天发券现金券。如果是以前的项目，可能我们想都不用想，加一个页面来实现这个功能，就OK了，但是，我们现在在做产品，如果还是这样设计，这个产品是不可持续发展的，今天顾客提出要按照顾客等级每天发现金券，明天可能就要发折扣券，那大家发现没有，就像写软件一样，相同的类型应该抽取出来，把它放在一起，这样系统才更加灵活，以后才更能方便扩展。但是顾客是不会考虑这么多的，顾客只会想，你的这个系统能不能满足我的这个需求。所以在需求收集的过程中，我们的业务负责人也是非常给力，一方面把不合理的需求挡回去，比如不属于我们这个系统的一些功能，我们有其他的产品可以提供，而不是硬塞进WCS里面；另一方面，和我们一起，站在产品的角度，把我们的思想尽可能地传达给顾客，让他觉得我们的系统和以前不一样，有些功能他们没想到，我们做了，就让他们去尝试一下，很有可能会带来更高的业绩。
说完了业务，说说技术。与现在PangPang其他团队保持同步，我们所采用的技术：像前端的React+Redux，后端的.NET Core，也都是非常新的技术。刚才说了，我们第一个版本只用了一周时间。我很庆幸我们的开发团队，人不多，但是非常的强大，负责EventCoupon微服务的丽先，负责SaleEvent微服务的刘彦辉，负责WCS前台开发晓旭，都是在非常短的时间学习新的技术，然后自己搭框架，自己做代码管理和发布管理。可以说是远远超过我的预期。
虽然说第一阶段按时上线了，但是我们从项目和团队还是存在很多问题。比如沟通不畅，因为一般都是我去参加设计会议，然后确定了设计，确定了技术方案，把要开发的内容分配到每个开发者。这样每个人负责一块开发，对于业务的理解很片面，不能从整体考虑业务，容易遗漏很多细节；也不能准确地估算开发时间，往往是一个人很忙，其他人很闲。而敏捷开发恰好能解决以上问题。11月7日，我们请伟伟作为项目的SM（Scrum Master），来指导我们做敏捷开发的一整套流程，把控项目质量。
那其实这一块应该是由伟伟姐来做发表，但是后来我想了一下，因为伟伟姐是敏捷开发的布道师，也在很多场合，包括之前的PangPang团队讲过、实践过敏捷开发了。那我就从一个实践者的角度，谈谈我对敏捷的理解，我们团队在用了敏捷开发之后有哪些变化。
这是第一次计划会列出的迭代任务分解图。没有敏捷开发的时候，因为对项目无法完全把控，往往手忙脚乱，压力非常大；引进了敏捷开发之后，我们的项目从质量和开发效率上有了很大的进步，同时因为一起讨论业务和技术，大家的工作氛围变得非常融洽。
这是Release2第1个迭代的Backlog，任务拆分后，再困难的需求都变得简单了。
讲一个我们最近的改进。大家看这个图，这是我们WCS与其他8个微服务之间的联系，箭头方向代表数据流动的方向。那这么复杂的系统间的联动，必然会使发布管理变得困难。比如我要上线一个新功能，可能需要其中的某几个微服务也跟着我们发布，那我就需要一个一个去找相关的负责人，告诉他们，要发布了，这样对我来说很累，而且可能有遗漏。如果发布时间不统一，轻则，那段时间顾客没法使用系统，重则产生错误数据，后果非常严重。所以我和伟伟姐说了这方面存在的问题，她第二天就带着我们制定了一套发布管理的流程。就是下面这张表格。
（介绍表格，略）
这种管理方式的转变让我想起了服务器的概念，就是下面这张图。以前我们都是单线联系，非常混乱，有了QA组帮我们做发布管理之后，相当于我们有了一个中枢调度系统，这样就避免了很多低效率的沟通。
最后我想讲一个我们开发团队在技术上做出的探索，敏捷开发下的代码管理。
按照敏捷的快速发布原则，理论上一个项目应该每周都有新版本发布，甚至一周内要发布多次。那按照原来的模式，显然是达不到这样的要求的。这就会导致下面这种情况。
我们每周都有回顾会，会回顾上一个迭代的做的好的和不好的部分。但是通常来说这个回顾会都是对一些工作模式的讨论，很少涉及技术。那我就在想，我们是不是应该抽出时间来回顾一下我们的技术，这样通过大家的交流，互相学习，也能够更好地提高项目的质量。我和伟伟姐说了这样的想法之后，伟伟姐非常支持，让我们每周有半天的时间去做技术回顾。那正好在半个月之前我们遇到了这个问题，就去查资料，想办法，最终找到了这样一种解决方案。
（介绍 A successful Git branching model，略）
以下是Release2上线时的页面截图，由于时间有限只能展示活动设定页面。
我想说的是：
（感谢语，略）
从第0个迭代到更多可能，我们会继续努力！
最后是问答环节
2月23日更新：
经过2个月漫长的重构，WCS 2.0终于在今天上线了。新版采用AntDesign作为UI框架，以下是实例。
