万万没想到 —— 我是这样减少与产品的“撕逼”

我是一个德智体美育全面发展的程序猿,在互联网“搬砖”的生涯一片无悔,想起每天夕阳下不断被修改的需求以及与产品的“撕逼”经历,那是我逝去的青春。

自从用了码云之后,我减少了与产品的“撕逼”,提高了工作效率,相信用不了多久我就会升职加薪当上总经理,出任CEO,迎娶白富美,走向人生巅峰。想想,还有点小激动。

需求评审

在产品妹纸整理好需求,规划好迭代目标后,会和我们开发一同对迭代中的 需求进行评审,产品妹纸会说明需求的背景及想达到的效果,我们会从技术的角度提出建议。 待产品妹纸重新调整完需求和迭代内容,我们会从优先级和类型的角度对需求行评估,并填在码云“需求”任务中。

需求评估完成,我们就要根据自己的情况来认领任务啦,并在任务负责人或协作者中给需求添加上当前处理人与协作者。完成认领之后,我们就可以在平台上跟进自己的任务啦。

任务领取完成之后,我就可以很方便地 在工作台中查看自己被指派的任务 了,四不四很简单(^0^)

当需求完成后,我们会在需求任务页面的状态栏 修改需求任务的状态,从“待办的”转为“进行中”。因为各个公司内部开发流程是多元化的,所以这里的 任务状态是可以自定义 的,非常方便。

任务开发完成后,更改任务状态并指派给产品妹纸确认效果,没有问题之后,产品妹纸会再 将任务指派给测试。

开发完了就高枕无忧?测试那边还有一波 Bug 等着修复。。。。。

发现某个任务存在 Bug ,测试会创建一个缺陷任务并关联对应的任务,并指派该任务的开发者为缺陷的处理人。呵呵,当你再次刷新工作台后就会发现突然多了许多 新指派的 Bug

每次开发过程都是一次再学习与自我审核的过程,作为一个想要逆袭高帅富的有志程序猿,我都会在 WIKI 里将自己的感受与经验进行总结和沉淀,这样会让团队成员少走弯路,提升工作效率。

我是一个呆萌的程序猿,万万没想到最后竟然被产品逼着写了篇不是软文的软文!

各位看官如果要打我,跪求能不能不打脸么?

转载自:

文章出处: 开源中国