给我们团队的建议

来到新的公司两个月了，工作体验不是太好。
测试同学是大厂转来的，给团队带来敏捷迭代的经验，结果设计倒是敏捷了，开发进度却跟不上。
我准备提点建议，酝酿了一番，请各位网友过目，给点建议。
​

我们讲敏捷开发是要“拥抱变化”，但是“拥抱变化”不是放任变化，变化是需要管理的。经常出现这样的情况：功能开发的过程中，对需求有了新的理解，于是就对设计进行了改进。在功能开发到一半的时候，或者说还有 bug 的时候，对代码进行改动很容易造成新的 bug。对于研发来说，更好的工作方式是，一次只做一件事，不能一边改 bug，一边修改逻辑。（在我们以前的团队，修改逻辑俗称写 bug。。。）
我希望我们的设计能够有一个版本管理。一个功能一旦设计好进入研发阶段，在验收通过之前都不再进行改动。在这期间，如果对需求有了新的理解，就放到下一版本的设计中。一定等到已有的逻辑没有问题了再对逻辑进行修改。这样可以避免思路被打断或者在设计的切换中漏考虑等。而且有的细节可能会多次出现改进，如果这几次改进都在设计文档上进行，代码就只需要根据最后一次完善的设计修改就可以了。我们知道，文档是自然语言描述的，代码是编程语言描述的，设计文档的修改成本肯定要比代码的修改成本低很多，省几次代码的修改可以节省很多时间，从而就提高了效率。
乍一看，对设计进行版本管理可能会使得产品迭代的更慢，其实不然。根据现在我们的情况来看，需求分析的很多，设计迭代的也很快，但是呢——开发进度跟不上。一个团队开发进度跟不上，还能称得上敏捷吗。这就好比一个人走路，只要每一小步踩的稳，小步也能快走。哪怕第一步偏左一些，第二步偏右一些，问题都不大。要是想在一大步内就找到正确的方向，就很容易出问题。腿抬的老高，一会往左一会往右，最后一脚踩下去，就摔了。
我们一定要正确看待现在的情形，把提高代码质量和减少 bug 数量放在更重要的地位。只要代码质量上去了，开发进度能跟上设计进度，总体上效率肯定是比现在更高的。
没有必要强求一有更好的设计就要立刻在代码上体现出来，不妨在设计文档上停留一段时间。经过一个设计的步骤，可以有一个统筹规划的作用，减少中间的无谓的修改。
特别需要提醒的是测试同学，在返工的过程中，返的一定是 bug，不要是建议或者想法。同一个功能，有的人觉得这样好，有的人觉得那样好，不如所有人都把建议或者想法提给专门设计的人，统一处理，效果会更好。还是那句话让研发一次只做一件事，不要一边改 bug，一边修改逻辑。