V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
yiyiniu
V2EX  ›  程序员

请教使用 Jira 的项目团队或公司,如何用它更好的提高工作效率?

  •  1
     
  •   yiyiniu · 128 天前 · 2581 次点击
    这是一个创建于 128 天前的主题,其中的信息可能已经有所发展或是发生改变。

    例如项目开始后,如何分配 WBS

    针对某一问题,如何通过 Jira 中哪些功能,能看出该人的工作效率、质量等完成情况,如何对人进行客观的评价

    请教各位 V 友们,使用过 Jira 并对 Jira 有一定认识的朋友们给点建议。

    第 1 条附言  ·  128 天前
    主要是看使用什么软件能尽可能缩短这个工期延期的时间。
    28 条回复    2024-08-07 12:21:07 +08:00
    wildmaker
        1
    wildmaker  
       128 天前 via iPhone
    看样子只能用报表横向对比故事点消耗速率和 Bug 数量?前提是用的比较规范,及时填写故事点和实际工时
    RandomJoke
        2
    RandomJoke  
       128 天前
    本质就是不断更新 jira issue 的状态,通过各种状态来统计。事实上 jira 并不能提高多少效率,只是对 issue 的追踪比较好,然后可以做一些分析罢了。提升效率还是要从研发流程,沟通基准,自动化程度来做的。毕竟是死板的工具,你只要定规则,那么必定就有漏洞可以钻,一项任务的复杂度,难易程度,都会影响他的工时,人员技术能力以及业务的熟悉程度也会影响它的工时,单纯从 jira 很难解决这些问题,而这些问题又是影响评判的主要因素之一。
    我司基本只用 jira 来做:
    1. 提需求,投票评判需求
    2. bug 追踪,设计好流程,记录原因,解决方案
    3. 分析 bug ,某些反复触发或者相关问题,需要梳理重新解决的
    4. 一次上线内需求拆分成多个 issue ,这里其实并没有太多作用,只是象征性记录,更多的还是靠组内沟通
    liuliancao
        3
    liuliancao  
       128 天前
    使用 gant 图相关插件 比如 structure.gant 和 biggant
    YDDDD
        4
    YDDDD  
       128 天前
    效率用 jira 感觉不好使吧,我们 jira 只用来跟踪进度,记录下状态和最终结论,一个需求做个几天,具体都是用日报那种来看的。
    yiyiniu
        5
    yiyiniu  
    OP
       128 天前
    @RandomJoke @liuliancao @YDDDD @wildmaker 请教那你们项目的开发效率,或者说项目工期例如要求 30 天,如何保障这个工期的呢?
    RandomJoke
        6
    RandomJoke  
       128 天前
    @yiyiniu 软件其实保障不了啊。。。30 天能不能完成主要是看研发真实时间能不能搞定,和 jira 这种软件有啥关系。jira 最多也就把任务拆解,然后每个任务上写好预估时间,只能说如果你更新的勤快,软件也许能告诉你做到一半的时候来不及或者也许可以提前。对工期本身其实没多大影响,甚至人少的时候可能还是负作用。
    yiyiniu
        7
    yiyiniu  
    OP
       128 天前
    现在主要是要解决项目延期的问题,或者说尽可能延期时间越短越好。不能说软件保障不了,对客户更不能这么说吧。 @RandomJoke
    ilovey482i
        8
    ilovey482i  
       128 天前
    项目延期应该用项目管理软件来管理项目进度,JIRA 是需求管理和 BUG 追踪
    RandomJoke
        9
    RandomJoke  
       128 天前
    @yiyiniu 项目延期肯定是多方面,多因素的, 合理的工期,合理的评估,团队的激励,团队的能力等等。靠你一个软件就能解决延期问题,那这个行业就不存在延期了😄,软件本身的作用就是记录分析,辅助你管理,比如你记录了 jira 的进度,那么在中期可能发现不能按时交付,这个时候要么激励加班,要么加人,这个本身是团队的管理模式而不是软件能解决的。就比如种销售 CRM ,他帮你解决的是数据分析发现问题,而不是帮你卖产品啊。。
    Mithril
        10
    Mithril  
       128 天前
    你用纸笔文件无法解决的问题,用 Jira 也解决不了。他只是个代替纸笔的工具,能提升的效率也仅限于你花在处理纸笔文档上的时间。

    项目经常延期,你需要考虑的是提升项目管理能力,而非诉诸于 xx 工具。要想办法找到,总结延期的原因,然后针对性的解决。到底是工期分配不合理,还是意外太多,或者项目目标设定的过于模糊等。

    这些都是“人”的工作,你想着让 Jira 帮你解决这些问题实在是南辕北辙了。
    XXWHCA
        11
    XXWHCA  
       128 天前
    用了好几年了,使用的功能主要是 bug 管理,任务报表和任务备忘或者说任务池,感觉页面不太好用,有一定的门槛。每天都需要花一些时间来处理任务分配和维护任务状态,定期看一下任务分布、时长这些报表,感觉并没有提高效率。在协作开发时,任务怎么做到更合理的拆分,然后还有就是每个人能及时的维护任务,包括时间、状态,不同的项目和公司可能场景不抬相同
    li746224
        12
    li746224  
       128 天前
    jira 这东西怎么可能提高效率。我们本来一些小的需求变动只要同事座位间动动嘴说一声就行,用了 jira 后,现在已经发展到不建卡不做。建卡等审批 pm ,开发过完 2 天过去了,本来只要 1 分钟就能搞定。
    yuedun
        13
    yuedun  
       128 天前
    12 楼说的是事实。jira 这种东西是给管理者和 pm 使用的,开发人员谁愿意使用?一天有一半时间用来更新 jira 能提高效率吗?
    wanniwa
        14
    wanniwa  
       128 天前
    基础的项目管理,如何拆分需求,怎么细化量化还是看项目经理能力,会管理的用 excel 表格都能管的井井有条。至于怎么管理你不如多去看看相关的视频把。。工具真的不是那么重要,只要能把一个个要做的事列出来,每个都有校准确的故事点评估,按故事点总数和开发人数尽量合理的平均到每个人。
    想要完全不延期就一定要在一开始彻底决定好需求,别动不动哪边逻辑漏漏了个大场景,哪边又要大改。除非方向完全错误,定死了就死在这个迭代里,改动放下个迭代提需求。
    还有需求最好是让底下负责的组长或者就是基础开发,列出他自己要实现这个功能的步骤和需要故事点,和项目经理评估的对齐一下,别需求啥都没看,开需求会啥问题没有,做的时候一堆问题。
    评估故事点最好最后再*1.1-1.3 的系数,留个容错时间
    luozic
        15
    luozic  
       128 天前
    效率不是使用啥软件能解决的。

    jira 最好的是看板和插件多,可以有效总结和保存过程信息。
    luozic
        16
    luozic  
       128 天前
    如果长期工期延迟,需要切实的通过 jira +大家一起总结哪部分导致最严重的延期。

    最常见的就是改需求 加需求还不改时间。 -----这种如果是客户长期的搞法,那直接评估时间的时候直接把这部分也加进去,并且控制需求变更 新增数量。
    mark2025
        17
    mark2025  
       128 天前
    @RandomJoke
    “一次上线内需求拆分成多个 issue ,这里其实并没有太多作用,只是象征性记录,更多的还是靠组内沟通”
    =====
    GitLab 的 issue 系统可以实现追踪一个 issue 被分解成多个 issue 然后每个 issue 链接 MR ,然后统计每个 issue 的完成时间
    luozic
        18
    luozic  
       128 天前
    这一类软件是能记录信息,方便你分析问题。但是解决问题不能靠软件。
    zhuangzhuang1988
        19
    zhuangzhuang1988  
       128 天前
    记录生命周期的。
    不能真正的复杂问题,复杂的问题还是靠牛逼的人解决的。
    当然这个有比没有好。
    wobuhuicode
        20
    wobuhuicode  
       128 天前
    作为同时在两个不同 team 使用过 jira 的人太有感触了。

    A team 有个 50 多岁的 leader ,每一个 Task 都是他负责发布的。一个大的任务给他分割成各种小任务分布到各个人下面,团队每一个人只需要管自己的部分就可以了。team 内的进度推进的非常平稳和准时

    B team 是全是有经验的开发者(人均 30+)。一个大任务下来大家讨论分配之后领取自己的任务去完成。一开始也能准时完成。后来加入一些新人之后就经常延期,因为新人基本都很难准确评估自己的任务。

    要提高效率和准时完成任务。本质上还是需要能准确针对每一个人的能力去分割任务。
    RandomJoke
        21
    RandomJoke  
       127 天前
    @mark2025 jira 你说的这些其实 jira 都能做,很多项目其实是多 repo 的,gitlab 其实也并不合适。统计这些时间本身意义不大,你说进度吧,其实做项目的不如组内沟通一下,你说关代码和 issue 的关联性吧,这个倒是有那么一点用( jira 也能关联 gitlab ),但一般来说 jira 的需求 issue 都不太会去重新打开看的。
    YDDDD
        22
    YDDDD  
       127 天前
    @yiyiniu 软件工期这个感觉想保证就只能每天对一次?用什么工具感觉不是重点吧,我们 jira 的更新状态甚至大部分都是 ld 做的,我们只管 mr 合了粘过去。不过我们每天早会,会把手里需求进度更新(不是用 jira ),但是遇到一些预料之外的问题延期也是没办法的。
    mark2025
        23
    mark2025  
       127 天前
    @RandomJoke jira 偏重管理,关注的是流程; gitlab 的 issue 是基于代码的偏重于开发, 比如可以在基于 issue 创建 MR 的时候同时创建代码分支,让开发人员里面切入到开发中,并且基于 web 的代码审核方式也提供了同事口头交流之外的比较高效的沟通方式——直接在页面显示的代码上面通过评论进行交流沟通。开发人员应该更喜欢用 gitlab 的这个流程管理方式吧。
    RandomJoke
        24
    RandomJoke  
       127 天前
    @mark2025 并不见得是这样,一般同端的协作是相对较少的,MR 作用于 review 还行,其他的情况并不适合用于沟通,issue 系统也仅限于一个 repo ,更适合对 repo 的讨论。一个项目基本都是由多端多 repo 组成的,比如后端微服务 3-5 个,前端,小程序,app 等等。这个时候用 gitlab 来管理项目就太困难了,而这种项目往往是最常见的。
    mark2025
        25
    mark2025  
       127 天前
    @RandomJoke 不会吧。gitalb 的 issue 是可以跨 group 的: 创建一个项目组,其下包含多端的多个仓库,可以在 group 级别的看板查看管理相关的 issue 啊。
    gitlab 的 issue 我觉得拿来作简单的项目管理也不错的:wbs 任务分解、任务状态管理、任务流转、里程碑管理。
    Akiya
        26
    Akiya  
       127 天前
    延期的问题不是一个软件能解决的,得从需求规划开始就下功夫。能做项目管理的人才在全球都是稀缺的,不然也没这么多项目延期了
    liuliancao
        27
    liuliancao  
       127 天前
    @yiyiniu 这个比较复杂 也有很多中管理方式和理念吧 我们是 milestone 和 sprint 管理的 比如两周一个 sprint,然后分支放到这些里面,上一周开发,下一周去跟进度,这个和整个团队有关了,你要感兴趣就看看项目管理相关的吧,我也不是项目经理 PM
    yiyiniu
        28
    yiyiniu  
    OP
       126 天前
    @RandomJoke @luozic @wobuhuicode @liuliancao 请教,有的项目比较长,开发人员在工期长的项目中,往往会刚开始很有激情每个人自己的任务往前推进,在后期往往会疲惫,拖拉,进度缓慢。大家是怎么处理这种情况的呢?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   857 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 22:11 · PVG 06:11 · LAX 14:11 · JFK 17:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.