我们公司之前用 jira 所以一个工作流整合需求 - 研发任务 - 测试任务 - 缺陷
现在用 ones，需求、任务、缺陷分开管理了
手机测试软件文章源自玩技e族-https://www.playezu.com/183380.html 文章源自玩技e族-https://www.playezu.com/183380.html
玩技站长微信
添加好友自动发送入群邀请
rainbow-shownow
玩技官方公众号
官方微信公众号
PLAYEZU
- 版权提示：本站仅供存储任何法律责任由作者承担▷诈骗举报◁▷新闻不符◁▷我要投稿◁
风险通知：非原创文章均为网络投稿真实性无法判断，侵权联系2523030730
免责声明：内容来自用户上传发布或新闻客户端自媒体，切勿！切勿！切勿！添加联系方式以免受骗。 - 原创转载：https://www.playezu.com/183380.html
转载说明： 点我前往阅读>>>
未知地区 1F
我们之前用的 ones ，基本就是需求产品负责记录和管理，然后开发和测试排期估时用任务（通过把任务拆细到最大预估完成时间不超过 6h 来进行排期），测试时有 bug 就记录缺陷。是会比较割裂，不过大部分情况除了领导大家也没啥要把这些东西串起来的需要，而且好像也可以自定义设置，给表单里加上关联某某需求/任务/缺陷之类的字段。
最近顺应公司换飞书的节奏，换了新出的飞书项目，思想差异挺大，比较偏向于快速看到某个需求的研发流程全貌及各节点进展情况。需求内部拆分为多个节点（如需求评审、ios 开发、android 开发等），每个节点又可以建子任务啥的，而且有自己的生命周期，还在适应中。
说实话，除了 jira 是可以非常自由定制工作流和各种任务类型外，其他大部分项目管理类工具都是基于自己的项目管理思想来建立的，不见得可以很自由地设定工作流，有时候甚至要反过来团队的工作流去适应系统。所以选系统的时候就相当于已经选择了工作流了。我司最早推行敏捷开发，使用的是：Trello（免费的在线多人协作看板系统），后来不知道怎么推行不起来就换了其他的小平台，但是因为不好用，最终不了了之。我们用的 jira,产品建需求，研发&测试在需求底下创建开发测试任务，遇到 bug 就在需求下面提，问题就分为需求相关 bug&历史 bug，总的来说对个人对领导都挺好用（过滤数据非常灵活）以前用 jira，不过要收费就没用了。现在瞎搞搞，都割裂的。从产品出文档开始吧，原型需求评审–>敲定研发方案（UI 出图）–>测试写用例（开始开发）–>用例评审–>提测–>测试–>上准生产环境–>产品验收–>上线分析会–>上线。
应该就这些了，还有些异常情况，啥原型不通过啊，产品验收不通过啊乱七八糟确实如此 以前用 jira 的时候也是像现在的飞书一样 设置一个看到需求任务的全貌状态的工作流 现在用 ones 也设置过状态联动，但需要你手动关联两个工作项 开发不由得会不耐烦 就没强制要求了 所以各类任务比较割裂管理我们的需求拆分工作还做不到位 每个需求细粒度把控不好
其他大部分项目管理类工具都是基于自己的项目管理思想来建立的，不见得可以很自由地设定工作流，有时候甚至要反过来团队的工作流去适应系统。
往往自研这些工具主要就是为了固化和沉淀一些组织级的流程或者规范，当然 JIRA 通过 ScriptRunner 这些插件配合起来也可以实现。
JIRA 有个不好的地方就是，大家都知道可以变流程，就各种提需求、争吵，最后通过很多项目就会搞出一堆乱七八糟的东西出来，做度量和组织级改进的时候非常操蛋。
自研优势就是告诉项目组，这是组织级流程的固化，不符合流程规范的进行不下去，可以避免很多失误和口水战，比外来的和尚念经有时候效果还要好一些。变流程这个，我理解是一个管理问题了，怎么限制大家随意改变系统的流程。自研的话灵活度更高，其实也更容易被提这类需求。不过自研成本也不低，团队没有一定规模，用外部已有的工具可能性价比更高。