快速开发后的思考

 

　　一个月前咱们启动了一个看起来像是“闪电计划”的项目，用两周的时间完成系统的改版，内容包括原型设计、界面设计、开发、测试、上线。时间紧任务重，看起来有点像不可完成的任务。最终经过整个团队的密切配合，和包括周末在内的加班加点按时完成了任务。但仅仅是完成，并未出彩。这是我第一次和整个团队一块儿参与较为完整的一次项目开发，从上线前到上线后，整个过程当中彷佛老是不那么平坦，有许多细节值得思考。可是时间紧急来不及追究，如今有必要静下来回顾思考，有哪些好的地方是能够继续沿用的，有哪些差的地方是须要改进的。

　　咱们如今的团队和小的创业团队没什么差异：

1. 成员之间没有一块儿开发过完整的项目，缺乏磨合
2. 咱们的工做流程、沟通方式、开发流程没有严格规范，大部分是经过即时沟通来达成意见一致，说好听了是敏捷，说难听了就是原始。
3. 需求的修改、代码的联调没有明确的流程，没有造成规范的文档，之后想要翻看以前的记录将比较困难
4. 为了追求快速完成项目，牺牲了代码设计架构的时间。没有良好的架构，之后需求改动或扩展会比较费力

 

　　这些特征决定了咱们必然会以如今的流程来进行开发，但由此产生的问题咱们有没有方法来改善呢？答案确定是有的，如今须要回顾一下整个流程，慢慢来寻找答案。

 

　　在肯定需求的时候，咱们所有的人员开了一次会，5个小时左右，把全部要作的东西过了一遍，有疑惑的地方当场拍板应该怎么作。应该说是解决了全部的疑惑，由于咱们明白这样的会议不会再来一次的，接下来就要进行开发了。我以为作的比较好的是，咱们在讨论事后总会得出一个结论，这一块该怎么作，那一块改怎么作。能够说咱们的会是“有结果的”，这至关重要。若是仅仅是停留在发现问题、提出问题的层面，那这个会也就和没开同样了。这是值得沿用的一点。

　　可是咱们的会就没有缺陷吗？显然不是。咱们此次改版涉及到的功能点太多，由于是改版而不是从新作一个东西，因此有不少是咱们没看到的。所谓没看到的就是一些隐藏的业务逻辑，须要在特定的场景下才会发生。咱们的旧系统逻辑比较复杂，咱们的人员从产品到开发都是新的，对老系统缺少总体全面的了解。咱们整理出了新的需求，但有一个致命的缺陷：咱们没有全面的考虑新的需求与旧的逻辑有哪些冲突，咱们没有考虑旧逻辑之因此那样作的缘由，功能点之间存在的关联或是前置条件，这些都没有清楚的了解。

　　这个致命的缺陷直接致使咱们在开发的过程当中不断发现有遗漏的地方，以致于不得不先完善遗漏的东西，最终的开发量粗略估计有需求文档上面的1.5倍。

　　其实过来人都有这样的经历，甚至以为这是喜闻乐见的，项目开发大都如此嘛，没有不会变的需求。但这样的状况并不是是什么好事，那咱们该如何改善呢？咱们开了5个小时的需求讨论会，难道还不够吗？固然不够，由于咱们只开了一次。由于咱们是在改版，是在重构，在开发的过程当中必然会发现第一次讨论没考虑到的东西，在积累了必定的问题后，咱们是否是须要从新拿起需求文档，从新审视一遍，再来一次简短的讨论会，该添哪些东西，或者是时间不够了该砍哪些东西。

 

　　咱们的开发流程仍是比较顺利的，由于明白时间有限，因此采起了简单处理、重复迭代、快速成形的方案，有一些新的设计想法都没有采用，而是沿用了原来的较为稳妥的作法。好比咱们计划想减小请求数，把一些页面内容作成异步获取的，但最终考虑到改动的东西会比较多，就放弃了，仍是复制粘贴了很多代码，每一个页面还像原来那样单独请求。页面加载速度没有提高，但保证了稳妥不出问题。再谈优雅什么的，那更是没有了。

　　咱们天天早晨开一个15分钟左右碰头会，通报一下昨天的进度，核对一下今天的任务。让每一个人都内心有数，这一点仍是作的不错的。

　　如今须要反问一句了，开发的过程当中有什么问题吗？有。由于咱们仍是发生过返工的。除去需求变化的缘由，因为考虑欠缺，没有明确方案就急于写代码，致使写了一大半的时候发现方案有误，最终更改方案从新开发，这一点仍是很伤的。如今须要告诉本身一句了：就算时间再紧急，也要想清楚了再动手。事实上，有明确且正确的方案后，编码是占用不了多少时间的，这一点一直会给人形成误区，认为作项目主要就是写代码。

 

　　开发完后就是紧张的测试了。咱们没有专门的测试组，创业团队的风格嘛。因而从别的组拉来两个实习生，外加产品经理、开发人员、客服妹子，组成了一支测试队伍。利用周六周日的两天时间，完成了产品的测试。测试的方式是最原始的功能测试，说白了就是以用户的身份，在页面上点来点去，把各个功能块都跑一遍，看看哪里走不通了。咱们也没有bug库之类的辅助工具，测试人员测完一轮就群发邮件通知一下，或者直接经过IM来交流，而后开发根据邮件和讨论组中的bug来修改。

　　这样的测试流程很明显是有问题的。对比一下，若是咱们创建bug库，咱们规范了的流程大概是这个样子：测试人员提交bug到库=>开发经理/组长分配bug给组员=>开发修改bug=>开发提交给测试返测=>测试人员标记bug经过/bug仍存在再次提交到库。

　　上面的流程看似冗杂，但少了其中任一环都不能保证一个bug能被最终解决，而且让你们知道这个bug已经处理了。这个是很重要的，你们能对每个问题都有一个清晰的掌控，不然当用户来咱们咱们的时候，咱们的回答只能含糊不清，由于咱们本身都不清楚这个问题究竟是解决了仍是没有。就从咱们实际状况来看，咱们也确实遇到了如下问题：

1. 对照邮件来处理bug很容易会有遗漏，由于无法标记这个bug是已处理仍是未处理，或者是测试有误不处理。全凭人脑记忆。在讨论组里提bug则更容易遗漏，由于可能开发人员压根就没看到这条信息。
2. bug的认领问题。有些bug须要前端来改，有些须要后端来改，没有一我的来统一分配，分工不明确。组员本身认领本身的bug，或者相互沟通协调，时间成本都太大
3. 开发修改完bug后，没有给测试回复邮件来讲明bug的处理状况。bug最终的处理结果只有开发清楚，没有一份能够保持的文档来记录，测试并无百分百的返测他所提的bug，只是提完就算结束了。这样缺少互动沟通，你们最终对结果的了解都是含糊的。

　　这样看来咱们的测试流程确实是有不少问题的，这也直接致使了咱们的产品上线后，不断接到用户反馈，其中大多数都是bug。那咱们当初为何要这么作呢？答案只有一个字：快。在有限的时间内，一个创业团队，根本没法创建起来这么完善的测试流程，这也是客观事实。看来这问题是无解了，真的吗？或许这个时候咱们须要回归到问题的根本上，思考这样一个问题：花必定的时间创建一个完善的工做流程，最终下来是会浪费时间，仍是节省时间？咱们想答案并非那么绝对的。

 

　　经过原始的沟通方式，使用原始的工做流程，咱们终于把产品折腾上线了。产品上线后的稳按期持续了两周之久，不断有用户反馈发现了bug，客服那边都忙坏了。开发这头也是手忙脚乱，咱们创建了一个讨论组，你们都在里面反馈发现的问题，bug像炸弹同样向开发狂轰滥炸，场面可想而知。

　　在这个阶段，咱们陷入了像测试阶段同样的困境。太乱了。这个时候发现的问题都是零零散散的，甚至都没有邮件来汇总，因此都在讨论组里面提。开发人员一变修改代码，一边留意讨论组里又提了什么问题。有时候一个bug修改的时间长，讨论组了已经攒了n个bug，有时候你们发言太多就把一些问题遗漏了。并且这个时候都是靠人脑在记忆，很容易就忘记了到底有多少bug存在，这个时候就会出现有人在讨论组反映了一个问题，却没人回应的情况。与此同时，因为遗漏了反馈来的问题，客服、运营又会感受这边响应不及时，没法向用户交代。总而言之，就是一个字：乱。

　　问题在哪里实际上是显而易见的，咱们缺乏一我的来统筹工做，应该是项目经理的角色。可是像这样的创业团队，不管是产品仍是开发，每一个人都会奋斗在第一线，没有一我的能抽出身来统筹一下项目，或者说把全部反馈的问题整理一下，作成一个列表来挨个对过。若是咱们没办法专门有一我的来统筹进度，那么就必须抽一我的出来作这件事了，我想最合适的仍是产品经理，同时担当QA的角色。这个时候对产品经理的要求就比较高了，必须快速的与开发进行有效沟通，所谓有效沟通就是必定要得出一个结论来，这个问题该如何改，如今就动手。由产品经理来驱动整个过程。

 

　　有时候会感慨，项目节奏太快，都没有时间思考了。其实这是一件可怕的事情，像这样“闪电计划”似的项目开发，是很是宝贵的经历，若是不能从中学习到一些东西，真的是太惋惜了。如今有时间静下来进行思考了，咱们的不足暴漏的很明显，在从此的工做中必须针对性的进行调整，只有这样才有提高的可能，不然永远只是重复劳动的机器。

 

　　很久没有码字了，感受整个行文都有点生硬了，最近看了阮一峰老师写的 为何要坚持写博客，很是赞同里面的观点，由于写做能促使你不断的思考，而思考对于人的提高相当重要。