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