我生活中的创伤之一是错误跟踪器、问题跟踪器和项目管理工具。完成版本控制日志以形成开发等效于复式记账的工具集。
与其会计等价物一样，这些工具实际上是有用的。虽然我们共同学会了避免首席执行官MBA，他们只根据公司的会计账簿来管理公司，而忽略了潜在的业务。我认为我们还没有学会避免那些只靠票证来管理软件开发而忽视底层软件交付的经理。
问题跟踪成为了一个行业，它的软件获得了意识，并开始成为一个社交网络，显然是优化了参与度和花在产品上的时间，而不是帮助你完成事情。这往往与那些工作保障与确保项目相关的人联系在一起，这些人的工作足够复杂，需要项目经理1来运行这些项目，由此产生的文书工作量令人难以置信。对这种状态的广泛接受带来了吉拉的创造者公众。
我不能反驳配置合理、速度快的Jira的存在，但我还没有体验过-而且我一直在努力。在我的一份工作中，我们把特雷洛2号推到了极限，作为回应，退伍军人们极力争取吉拉。我确信这个产品现在是我记忆中的完全不同的东西。嗯，几个月后(以及一些高薪、微调的配置)，我看到了与我记忆中相同的基于周转率的会计策略。
我认为问题中需要的属性相对较少，使处理高效的规则也相对较少。
至关重要的是，这个问题需要找到能够解决的人。这通常是通过将其提交给正确的董事会来完成的，但在较大的公司中可能会很棘手，而且通常需要工程部门内部的人进行可靠的分类。
这不是我非常不喜欢的“组件”属性。如果“组件”是由工程师创建的，它们通常是任意的，它们在重构过程中无法幸存，并且会随着时间的推移导致责任的淡化。如果它们是由产品所有者创建的，则它们与客户的感知相对应，而不一定与内部结构相对应，因此需要翻译层。3个。
分配给一个人4.如果你不知道那个人是谁，应该没有所有者，应该有一个明确指定的人(我们使用的是当前的OnCall座席)来处理他们并相应地分配。
对于一个项目组织来说，这是最重要的一件事。每个小组必须具有单个有序的任务队列。当一个工程师有多个队列从上面取货时，就会出现很多项目管理混乱。
它经常发生，而且是以不透明的形式发生的。当然，没有人会故意分散任务。但在实践中，有计划在优先级存储桶(如高、中、低)中分配标签，并在其内部进行不清楚的排序。然后，一张高优先级的客户罚单就进来了。然后发生了一件事。然后我们有内部的bug追踪器，还有一系列的Github问题，我们决定同时做这两件事。另外，我刚收到我们营销人员发来的一封电子邮件，内容是我们页面上的一个打字错误。这段话会让人感到困惑吗？一点儿没错!。
有一种方法可以把所有这些放在一个地方，并确保每一个都相对优先。当坐在电脑前实现流程时，应该有一个最重要的项目，只要看着它们就可以拿起来。
如果流程比较复杂，应该有一个大家都同意的算法。例如：
如果发生事故，这是随叫随到座席的首要任务。
通过电子邮件收到的客户上报。对于有效的事件，请创建事件并将其委派给随叫随到。对于无效的邮件，请回复、道歉并提供客户支持链接。
这就是事情变得丑陋的地方。可能的票证状态通常是由建筑师设计的，而不是由实际要使用它的人设计的。我看到了一张问题状态转换的地图，看起来绝对是图灵完整的。
我建议从“TODO”、“DO”和“Done”三合一开始，只有在绝对必要的情况下才增加更多。将问题从一个状态移动到另一个状态需要与显式操作相关联。如果您添加更多，请确保您与每个人都有明确的协议，即最新阶段的票证具有最高优先级，除非您要让所有票证都停留在最无聊的阶段，例如“验证”阶段。
每个具有状态的票据都应该对应于单个部署(在连续交付环境中不是很大)。如果是较大的，应该把它分成一张子票，并记录它们之间的关系。
就这样。如果您真的要扩展，可能需要更多的…。但比你想象的要少。虽然以下属性是常见的，但大多数属性绝对不应该。
一个问题没有绝对的优先级，只有相对于其他问题的相对优先级。一旦你开始从列表中分配优先级，除了“最高”以外的任何事情都是一种被动攻击性的说“不”的方式。
如果优先级只是一个带有值列表的属性，它很快就会成为滥用最多的字段。迟早，你也会开始添加额外的“真正最高、最直接”的优先事项，也就是所谓的“CEO电话”。
该类型通常是包含“增强”、“错误”、“任务”和“文档”等值的列表。我的问题是：你为什么想要这些信息，它将被用来做什么？
“类型”一栏引发了我一生中最无意义的讨论之一。“这不是一个错误，这是一个功能”这句话的意思是我可能不是一个人。我们大家都不应该在意。当人们尖叫“这是个虫子”时，它是由什么引起的都无关紧要。这是一场重大预期失配的尖叫。团队应该努力解决这个问题，无论是由于开发人员偏离了设计意图还是因为最初的意图出错造成的。
喜欢通过分门别类来拖延的完美主义者，而我支持每个人都有自己的爱好，如果团队因此而受损，那是很不幸的。找到一种方法来就有用性达成一致，并帮助完美主义者管理不完美的地方。我建议他们买一个便携式禅宗花园作为补偿。
喜欢饼图的顶级经理。这通常是通过比较团队产生的缺陷数量来比较团队的质量。剩下的唯一一件事就是把你的奖金与它捆绑在一起，然后你就可以把你的正式公司歌写成“这是一个功能，而不是一个错误”6。在一个功能不那么混乱、更有效的情况下，它是评估“我们为维护和开发新事物付出了多少努力”，我认为这在某些情况下是合理的--但“维护”和“新”应该是罚单类型。
顾客。“Bug”用来表示“高优先级”或“你的错，把它修好，甚至不要试图向我们收费”。
每当推流到来时，注意挖掘出请求的实际根本原因，其他方式解决效果较好。
跟踪版本对于已发货的库和内建包很有意义。对于持续交付的SaaS来说，这毫无意义。
严重程度要求被视为等同于优先级。但是严重程度对于不同的角色来说是非常不同的，它的优先级总是考虑到劳动强度的相对优先级的决定。
考虑一下页面上的文本中的一个打字错误。当它在页面中间时，你怎么处理它？当它出现在登陆页的行动号召主页面上的时候？什么时候是琐碎的固定，什么时候需要五个人的批准，什么时候需要进入第三方的系统？
最具挑战性的事情是有一个卫生问题。说“不”是硬道理，但没有硬道理，发行系统就会变得一团糟。该系统的设计应该鼓励以积极和轻松的方式结束问题。这最终是看板董事会的吸引力所在：要达到的目标是一个问题公开的时间越短越好，并提供积极清理队列的激励。
否则，门票数量就会变得难以管理，开始变得像沼泽一样。你小心翼翼地走进去，结果却被吸走了，再也不会露面了。
恢复的一种方式是在一段时间后自动关闭票证。这可能是一种微妙的说“不”的方式，但我认为这是它的位置，特别是如果我们在谈论公共追踪器的话。
有一个很好的论据支持它：软件在不断变化，因此旧的问题可能是无效的。为了把它们印上印记，需要对它们进行检查-在某些情况下，这实际上比问题本身要做得更多。
为了继续拥有一个跟踪器而不是一个数据库，放弃是一个合理的反应。
为了实现这一点，需要有一个独立于公司其他人员的系统来处理开发团队的问题。
这对沟通文化至关重要。我认为另一种选择是给随机的工程师或他们的组长写一条信息，这会导致滥用。使该频道比任何其他收件箱更具响应性和可靠性是很重要的。
另一种选择是开具不明确的开发票，这条路通向一片沼泽。很容易压倒团队对所有门票进行分类的能力，这时整个队列都会被忽略，你就会发现门票沼泽服用了类固醇。
郑重声明，我实际上曾与一位优秀的项目经理共事过。他的特点是理解他是推动轮子旋转的油，而不是最大的，也是中心最重要的轮子。这当然使他成为最受尊敬的同事之一。我在重复这段难忘的经历时遇到了困难。更严肃的是，我被要求支持这一点，当然，我所能做的只有轶事证据。然而，我确实认为这实际上是任何工作岗位的一种属性：人们很少希望自己的工作消失。一旦你创造了一个职位，它就会转移。创建一个专门的$TECHING忍者位置并观察↩︎。
对于较大的团队，这可以是一个团队帐户，但在这种情况下，团队负责人有责任定期检查所有团队拥有的票证，并将其委派给↩︎。
看起来很荒唐吗？嗯，我也看到过“故事点是抽象的，特定于团队的，无与伦比的，所以让我们把所有团队的工作倦怠图表放在走廊的这个单一的大型显示器上，你知道，显然只是为了让团队知道他们是如何站稳脚跟的，没有其他隐藏的议程暗示”完全↩︎