kafka积压_是时候消除您的技术积压了

kafka积压

公认的真理： (The Accepted Truth:)

Most teams working with Scrum or Agile for any period tend to have accumulated Technical Debt and work to pay it back. This is good practice as without it things will get out of hand. Actively managing Tech Debt demonstrates maturity. Teams are proud that they have stories or a separate backlog to deal with Technical Debt. They may even reserve a percentage of sprint capacity to clear this down.

大多数在任何时期使用Scrum或Agile的团队都倾向于积累技术债务并努力偿还。 这是一个好习惯，因为如果没有它，事情将会变得一发不可收拾。 积极管理技术债务可以证明其成熟度。 团队为拥有处理技术债务的故事或单独的积压而感到自豪。 他们甚至可以保留一定比例的冲刺能力来解决这一问题。

This is the Technical Debt Dragon which needs to be slayed to free the team.

这是技术债务巨龙，需要解雇以释放团队。

真实的真相。 (The Real Truth.)

The Technical Debt Dragon is a myth. It only exists because you believe it must. Technical Debt should be thought of in the same way that we do Father Christmas, [Spoiler Alert].

技术债务龙是一个神话。 它之所以存在是因为您相信它必须这样做。 应该像处理“圣诞节父亲”(扰流板警报)一样对待技术债务。

When we are young we believe he exists. An entire industry exists to promote and support this myth. As we mature we realize that he does not exist. But we still promote the myth to those who are not as mature as we are.

我们年轻的时候就相信他的存在。 存在着整个行业来促进和支持这一神话。 随着我们的成熟，我们意识到他不存在。 但是我们仍然向那些不如我们成熟的人宣扬神话。

[Sorry I did warn you]. When we begin our Agile journey we believe that backlogs must contain Technical Debt items. But once we achieve a level of maturity and understanding we no longer need it. The creation of Technical Debt is not an inevitable consequence of software development.

[抱歉，我警告过您]。 当我们开始敏捷之旅时，我们认为积压的订单必须包含技术债务项目。 但是，一旦我们达到了成熟和理解的水平，就不再需要它。 技术债务的产生并不是软件开发的必然结果。

技术债务，一个经常被误解的概念。 (Technical Debt, an Often-Misunderstood Concept.)

The term Technical Debt was first coined by Ward Cunningham, one of the authors of the Agile Manifesto. Technical Debt is an analogy that compares the way we develop and deploy software with the concept of borrowing and then paying back with interest.

“技术债务”一词最早由“ 敏捷宣言”的作者之一Ward Cunningham提出。 技术债务是一个类比，将我们开发和部署软件的方式与借贷的概念进行比较，然后偿还利息。

“some problems with code are like financial debt. It’s OK to borrow against the future, as long as you pay it off.” Ward Cunningham.

“代码的某些问题就像是财务债务。 只要您还清未来，就可以借用未来。” 病房坎宁安。

“When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.” Agile Alliance introduction to Tech Debt

“在采取捷径并交付当前不适合当前编程任务的代码时，开发团队会招致技术债务。 这种债务降低了生产率。 生产力的损失是技术债务的利益。” 敏捷联盟技术债务简介

Is Technical Debt really the burden that a developer has given themselves?

技术债务真的是开发商负担的重担吗？

The core of the original Technical Debt concept is about the increase in time and effort that having badly structured and constructed code presents when making changes. This is summed up by the following statement:

原始技术债务概念的核心在于，在进行更改时，结构和构造不良的代码会增加时间和精力。 以下语句总结了这一点：

“I have a confusing module structure in my code base. I need to add a new feature. If the module structure was clear, then it would take me four days to add the feature but with [Technical Debt], it takes me six days. The two-day difference is the interest on the debt.” Martin Fowler

“我的代码库中的模块结构令人困惑。 我需要添加一个新功能。 如果模块结构清晰，则添加功能将花费我四天，而使用[技术债务]则需要六天。 两天的差额就是债务的利息。” 马丁·福勒

QUESTION? Look at the Technical Debt items on your backlog. Count how many concentrate on the quality of the deployed code. Exclude code changes that are linked to architecture or “ if I knew then what I know now”. How many do you have? [Spoiler Alert]. It is usually zero.

题？ 查看待办事项上的技术债务项目。 计算有多少人专注于已部署代码的质量。 排除与架构或“如果我知道那么我现在知道的东西”相关的代码更改。 你有多少？ [扰流板警报]。 通常为零。

Do you still believe your backlog has valid Technical Debt items on it?

您是否仍然认为积压的订单上有有效的技术债务项目？

Consider this. Technical Debt is the extra time you spend making changes that would NOT be necessary if the code were easier to work with. If you know you have an old or cumbersome code base then it is a given that changes would take longer. Based on previous experience you can make an estimate of how much effort would be required. So, have you created a separate backlog item for the Technical Debt portion of each change backlog item? Or do you include this in the estimates you create for the change?

考虑一下。 技术债务是您花费在进行更改上的额外时间，如果代码更易于使用，则不必要。 如果您知道自己的代码库过旧或笨拙，那么更改将需要更长的时间。 根据以前的经验，您可以估算需要多少精力。 那么，您是否为每个变更待办事项的技术债务部分创建了单独的待办事项？ 还是将其包括在为更改创建的估算中？

Technical Debt is just an effort component that needs to be included during estimation.

技术债务只是估算中需要包括的工作量部分。

技术债务的滥用方式。 (How Technical Debt is Abused.)

Working with and coaching many teams from many sectors, for far too many years. I have found that Technical Debt always gets misused in the same ways.

与许多领域的许多团队合作并为其提供指导已有太多年了。 我发现技术债务总是以相同的方式被滥用。

• Teams or especially Tech Architects quoting that you should ‘spend 20% of your the time on Technical Debt’.
  团队或特别是技术架构师引用您应该“将20％的时间花费在技术债务上”。
• Maintaining a Technical Backlog.
  维护技术积压。
• Ensuring that 20% of the teams’ capacity is expended on Tech Debt items every sprint.
  确保每次冲刺都将团队能力的20％用于技术债务项目。

There is a fundamental misunderstanding of a quote from Martin Fowler summarized as

马丁·福勒(Martin Fowler)的一句话被误解为：

“teams spend about 20% of their time working on Tech Debt”.

“团队花费大约20％的时间来处理技术债务”。

This quote should be viewed in conjunction with the earlier quote from Martin Fowler. The intention is to quantify on average how much time the team spends on dealing with Tech Debt when implementing a change.

该引用应与Martin Fowler的早期引用一起查看。 目的是平均量化团队在实施变更时花在处理技术债务上的时间。

The tech architect or manager, often uses the 20% argument and a technical backlog to justify getting the work they want into a sprint. Instead of following the correct practice of assessing the items alongside all the other backlog items. And then, only working on the items that deliver the most value.

技术架构师或经理经常使用20％的论点和技术积压来证明使他们想要的工作进入冲刺是合理的。 而不是遵循与所有其他积压项目一起评估项目的正确做法。 然后，仅处理具有最大价值的项目。

Technical Debt gets used as a convenient catch all instead of adding technical stories to the backlog. The backlog should contain technical stories as well as all the exciting new features. The following are often wrongly generalized as Tech Debt:

技术债务被用作方便的工具，而不是在未完成的订单中添加技术故事。 待办事项应包含技术故事以及所有令人兴奋的新功能。 以下通常被错误地概括为技术债务：

• Identified issues,
  确定的问题，
• Lack of process or poor process (e.g. configuration management tool),
  缺乏流程或流程不佳(例如配置管理工具)，
• Features that are wrong or delayed (things we should have done in release X but),
  错误或延迟的功能(我们应该在版本X中完成的操作)
• UI issues, inconsistencies, or bad experience,
  用户界面问题，不一致之处或不良经验，
• Enhancements (including performance),
  增强功能(包括性能)，
• Lack of skills within the team,
  团队内部缺乏技能，
• Changes resulting from Architecture decisions,
  由架构决策产生的变化，
• Incorporation of new coding standards or practices.
  纳入新的编码标准或惯例。

All of the above represent work that the team may need to complete. The Product Backlog is the correct place for these items.

以上所有内容代表团队可能需要完成的工作。 产品待办事项列表是这些项目的正确地方。

The above issues usually occur in a team or organization that has not fully embraced Agile thinking. If a separation has been maintained between Technical and Business aspects. Or if the Product Owner is only performing what they consider the sexy part of the role. Then the Product Backlog may only contain the new features for a product. With everything else considered as a technical problem which are of no interest to the Product Owner. These items are then formed into a Technical Backlog.

以上问题通常发生在尚未完全接受敏捷思想的团队或组织中。 如果在技术和业务方面保持了隔离。 或者，如果产品负责人仅扮演他们认为是角色的性感角色的角色。 然后，产品待办列表可能仅包含产品的新功能。 其他所有问题都被视为技术问题，产品所有者对此毫无兴趣。 这些项目然后形成技术待办清单。

This is usually justified by stating that the Product Owner has no technical knowledge. Therefore, how can they judge the relative merits of the technical items against the business ones. The answer when working in a Agile manner is simple.

通常可以通过指出产品负责人不具备技术知识来证明这一点。 因此，他们如何判断技术项目相对于业务项目的相对优劣。 以敏捷方式工作时，答案很简单。

All items on the backlog should be refined by the team as a whole.

整个团队应完善待办事项上的所有项目。

The team has the technical knowledge and can therefore have the relevant conversations to ensure they get prioritized correctly.

该团队具有技术知识，因此可以进行相关对话，以确保正确确定他们的优先级。

During the early stage of an Agile adoption the team and organisation struggle with the concepts of Openness and Transparency. This is especially apparent when transitioning from a command, control and blame culture. In these circumstances the Technical Backlog becomes a mechanism for hiding uncomfortable truths. The Product Backlog only contains the new features is used in reviews and communications with stakeholders. All the issues and problems are contained in the Technical Backlog which is kept within the team and never communicated to the stakeholders.

在敏捷采用的早期阶段，团队和组织会与开放性和透明性概念作斗争。 从命令，控制和责备文化过渡时，这一点尤其明显。 在这种情况下，技术待办事项成为隐藏不真实事实的机制。 产品待办事项列表仅包含用于与利益相关者进行评论和沟通的新功能。 所有问题都包含在技术待办事项列表中，该待办事项保存在团队中，并且从未与利益相关者进行沟通。

向我展示价值，我将向您展示优先事项。 (Show Me The Value and I will Show You The Priority.)

The 20% capacity approach and Technical Backlog is often unknowingly used to hide some fundamental skill gaps. Without recognizing and addressing these skill gaps you can seriously affect the viability of the entire Product. At the core of the problem is that the technical architect cannot assign meaningful value to the items. They are able to specify the engineering sequence. So the Technical Backlog is ordered based on this. The mythical 20% rule is then used as the approach to address the items.

20％的容量方法和技术待办列表通常在不知不觉中被用来隐藏一些基本的技能差距。 如果不认识并解决这些技能差距，则会严重影响整个产品的生存能力。 问题的核心是技术架构师无法为项目分配有意义的价值。 他们能够指定工程序列。 因此，基于此订购技术待办事项列表。 然后将神话般的20％规则用作解决项目的方法。

A fundamental of Agile working is to ensure that we are always working on the items that deliver the most value to the business.

敏捷工作的基本原则是确保我们始终致力于为企业带来最大价值的项目。

Most technologists focus solely on the internal infrastructure and what is possible and not on what delivers the most business value. The result is that a blanket 20% of the overall budget is allocated for technical work. This is then treated as an obligation to spend every sprint without ever having to justify the value returned. If we decide to expend effort then we should always ask ourselves if this is the best thing to fund this sprint. This can only be accomplished by working with the Product Owner to prioritize all the potential work.

大多数技术人员只专注于内部基础架构以及可能的内容，而不关注于提供最大业务价值的内容。 结果是将全部预算的20％分配给技术工作。 然后，这被视为花费每次冲刺的义务，而不必证明返回的值是合理的。 如果我们决定花更多的精力，那么我们应该经常问自己，这是否是为此冲刺筹集资金的最佳选择。 这只能通过与产品负责人共同确定所有潜在工作的优先级来实现。

Only when the Technical and Business aspects work together can you ensure you are delivering value.

只有在技术和业务方面共同努力时，您才能确保交付价值。

如何永久使用技术债务。 (How to Use Technical Debt for Good.)

Although Technical Debt does not really exist, it has become accepted as a fundamental feature of Agile working. Because it is so widespread, I find it useful as a barometer to assess Agile maturity. As with everything in Agile, no one technique exists wholly in isolation. Evidence of maturity can be found in surprising places, such as the management of Technical Debt.

尽管技术债务确实不存在，但已被接受为敏捷工作的基本特征。 因为它是如此广泛，所以我发现它可以用作评估敏捷成熟度的晴雨表。 与敏捷中的所有内容一样，没有一种技术完全孤立地存在。 成熟的证据可以在令人惊讶的地方找到，例如技术债务的管理。

By adopting and following good practices it is possible over time to eliminate all types of Technical Debt. Resulting in greater effectiveness and allowing focus on delivery of real value. If you already follow the Scrum Framework you have all the structures needed to identify, explore and resolve every issue you encounter. The key is realizing that there is an issue and committing to a course of action to resolve it. But be sure that you are addressing the underlying disease and not just the visible symptoms.

通过采用并遵循良好实践，有可能随着时间的流逝消除所有类型的技术债务。 产生更大的效力，并专注于交付实际价值。 如果您已经遵循了Scrum框架，那么您将拥有识别，探索和解决遇到的每个问题所需的所有结构。 关键是要意识到存在问题，并致力于采取行动解决该问题。 但是请确保您正在解决潜在的疾病，而不仅仅是可见的症状 。

Slay the Technical Debt Dragon and free yourself

杀死技术债务巨龙，释放自己

尾注。 (End Note.)

The real Technical Debt, the extra effort to work with bad code, will that always be there?

真正的技术债务，使用错误代码的额外工作，会一直存在吗？

NO. A truly mature team will eliminate this as well. By embedding good coding practices that focus on refactoring and standards from day one, the team will minimize or eliminate Technical Debt (focusing on this aspect as top priority in any Agile adoption will give you the biggest benefit and ensure you are setting yourself up to succeed long term). If you are working with legacy code-bases over time by use of the same good coding practices, the Tech Debt overhead will reduce significantly.

不行 一个真正成熟的团队也会消除这种情况。 通过嵌入从一开始就专注于重构和标准的良好编码实践，团队将最大程度地减少或消除技术债务(将这一方面作为任何敏捷采用的重中之重将为您带来最大的收益，并确保您为成功做好准备长期)。 如果您通过使用相同的良好编码习惯逐步使用旧版代码库，则技术债务开销将大大减少。

Always keep in mind the key to True Agility — if it is not delivering a Business Advantage, then it’s not really Agile.

始终牢记“真正敏捷”的关键-如果它没有提供业务优势，那么它并不是真正的敏捷。

翻译自: https://medium.com/@mrgray.mark/its-time-to-kill-your-technical-backlog-3f19e2347538

kafka积压