1. 同一个 proj 下为啥要分开？他的理由是什么？没有特殊原因当然应该引用唯一定义
2.
纯单量考评是比较扯淡，至少得算上story point啊
但是你们的jira用法看上去也有很多问题
超过一周的工作一个任务，而且不可拆分？你们团队中间不沟通进度吗？没有中间里程碑？
那你什么时候能发现要超期了？
临时任务不进jira就直接开始做，全做完了再回头补，中间都不需要记录和同步吗？而且按你说法，这种任务数量不少，也就是经常团队里有一些人干的活没人管的意思？
然后既然有的不在jira中的问题可能比jira里的问题更为严重，那这些任务为什么不放进jira管理？

整段看下来你们就没把jira作为日常项目管理的核心工具，就是写个需求计划往那儿一放完事。那当然问题多多。如果真做到了“围绕jira的任务管理功能展开项目工作”那有些问题就不存在了。

话说你在团队中是什么角色？

【 在 wuzhiqiu1 的大作中提到: 】
: 问题1：
: 在依赖QT的C/S项目中（同一个pro下），c端和s端的不同类中定义了相同的结构体定义，用于C/S传输和解析socket数据。我review时，认为此法不妥，应该唯一定义，以此理由要求同事修改是否妥当？
: 问题2：
: 如何使用jira工具做好项目工作管理？
: 我简单说一下我当前面临的情况，团队之前在jira记录主要功能需求和问题记录，会预设完成时间，但非强制，根据实际完成情况提前结束或延期。
: 最近，leader要求团队成员必须围绕jira的任务管理功能展开项目工作，同时固话角色分工和责任，以后季度绩效考评就看每个人完成和剩余的任务数量，用量化数据明确考核标准。
: 对此，我持怀疑态度和抵触情绪，原因如下：
: 1.任务的时间分配不均衡。如果要求完成和剩余任务数量作为考核标准，则前提条件是不同开发人员开发任务涵盖的工作量应该大致相同，否则无法得出相对公平的评价。但是，实际工作中很难实现，因为不同人员维护的功能模块不同，开发需求不同，所以不同任务的工作量往往不一样，
: ∪挝褚惶炜梢酝瓿珊眉父觯话闳挝裥枰1-3天，偶尔会有一些难改的问题超过一周，但由于任务整体性强很难继续拆分，且存在工作估计不准确的情况，所以很难保证所有任务的工作量相等；
: 2.任务记录跟随效果不充分。jira可以记录预先计划的任务，但是对于突发问题，往往只能事后补齐，但是现阶段工作中插队需求和线上突发问题常常发生，所以这部分工作量不小。
: 3.加剧了工作中的机械化。如果只为jira任务论，我担心开发人员发现不在jira上记录的程序问题时会比以前更倾向于忽视该问题，而将时间花费于jira中的任务，哪怕被忽视的问题可能更严重。
: 4.评价维度单一。我认为这是机械的评价他人工作成果，反而应该从代码质量、解决共性问题的贡献程度、任务的难度和数量等多维度考量，并且工作成果是依靠自驱力的，这种机械式的量化方法看似公平，但仅是局部公平，可能会伤害团队成员主动性。（还有一个原因，我不想投入更多
: 奔湓诩锹急鹑巳挝裆希懈枰易龅氖虑椋
--
修改:cybereagle FROM 220.249.170.*
FROM 220.200.24.*