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 and managing it shows the maturity of the team. Teams are proud that they have stories or a separate backlog to deal with Technical Debt and may even reserve a percentage of sprint capacity to clear this down. This is the Technical Debt Dragon which needs to be slayed to free the team.

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

The Real Truth:

真相：

The Technical Debt Dragon is a myth. It does not exist. 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 and a whole industry exists to support the myth. As we mature we realise 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]. Technical Debt as items on your backlog is something we believe exists when we begin our Agile journey, but disappears with a certain level of maturity.

技术债务龙是一个神话。 它不存在。 应该像处理“圣诞节父亲”(扰流板警报)一样对待技术债务。 当我们年轻时，我们相信他的存在和整个行业的存在都支持神话。 随着我们的成熟，我们意识到他不存在了，但是我们仍然向那些不如我们成熟的人推广神话，[对不起，我警告过您]。 我们认为，当您开始积压工作时，技术债务即已存在，但随着一定的成熟度而消失。

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 intro to Tech Debt

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

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 changes are made. 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? Have a look at all the Technical Debt items in your backlog and count how many concentrate on the quality of the deployed code. (Exclude code changes linked to architecture and, “ 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 and you can make an estimate based on previous experience. 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?

您是否仍然认为积压的订单上有有效的技术债务项目？ 考虑到这一点，技术债务是您花费额外的时间进行更改的时间，如果代码更易于使用，则无需花费这些时间。 如果您知道自己的代码库过旧或笨拙，那么更改将花费更长的时间，并且可以根据以前的经验进行估算。 那么，您是否为每个变更待办事项的技术债务部分创建了单独的待办事项？ 还是将其包括在为更改创建的估算中？

How Technical Debt is Used and Abused:

如何使用和滥用技术债务：

Working with and coaching many teams across many sectors, for far too many years I have found that Technical Debt always gets misused in the same ways. I have lost count of the number of times that teams or especially Tech Architects (TA) have quoted that you should spend 20% of the time on Technical Debt. To which end they maintain a Technical Backlog and ensure 20% of the teams’ capacity is expended on these items every sprint. This is due to a fundamental misunderstanding of a quote summarised as “good teams spend about 20% of their time working on Tech Debt”. The TA or in some cases a manager, often uses this argument to justify getting the work they want into a sprint instead of following the correct practice of assessing against all the backlog items, and then, only working on the ones that deliver the most value.

与许多部门的许多团队合作并为其提供指导，多年来，我发现技术债务总是以相同的方式被滥用。 我没有计算团队或特别是技术架构师(TA)引用您应将20％的时间花在技术债务上的次数。 为此，他们维护技术积压，并确保每次冲刺都将20％的团队能力用于这些项目。 这是由于对一个报价的根本误解，总结为“好的团队花费大约20％的时间来处理技术债务”。 TA或在某些情况下是经理，通常使用此参数来证明将他们想要的工作纳入冲刺状态，而不是遵循对所有积压项目进行评估的正确做法，然后仅对交付最大价值的项目进行工作。 。

Teams tend to classify a lot of items under the heading of Technical Debt as a matter of convenience instead of adding them to the backlog as technical stories along with all the exciting new features. All of the following should be stories and not classed 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.
  纳入新的编码标准或惯例。

An observation that I have made within many teams where they have maintained a separation between Technical and Business aspects, or where the Product Owner is only performing what they consider the sexy part of the role, is, that the Backlog only contains the new features for a product while everything else is considered as technical problems that are of no interest to the Product Owner. These form a Technical Backlog. This is even true in organisations who believe that they have embraced DevOps, lean practices and Agile delivery. The argument is usually that the Product Owner has no technical knowledge so how can they judge the relative merits of these items against the business ones. The answer to this is simple. All items on the backlog should be refined by the team as whole. The team has the technical knowledge and can therefore have the relevant conversations to ensure they get prioritised correctly.

我在许多团队中发现，他们在技术和业务方面保持着分离，或者产品负责人仅在执行他们认为是角色的性感部分时所做的一项观察，是，待办事项仅包含以下新功能：产品，而其他所有问题都被视为技术问题，而产品所有者则不感兴趣。 这些构成技术待办事项。 甚至在相信已接受DevOps，精益实践和敏捷交付的组织中也是如此。 通常认为，产品负责人不具备技术知识，因此他们如何判断这些项目与业务项目的相对优劣。 答案很简单。 整个团队应完善待办事项上的所有项目。 团队具有技术知识，因此可以进行相关对话，以确保正确确定他们的优先级。

Also in the early stages of Agile adoption where the team and organisation are struggling with Openness and Transparency, especially when transitioning from a command and control culture that have always looked to allocate blame. The Technical Backlog becomes a mechanism for hiding uncomfortable truths. The Backlog which only contains the new features is used in reviews and communications with stakeholders and all the issues contained in the Technical Backlog are kept within the team and never communicated to the stakeholders.

同样，在采用敏捷的早期阶段，团队和组织正努力争取开放性和透明性，尤其是在从一直希望分配责任的命令和控制文化过渡时。 技术待办事项成为隐藏不真实事实的机制。 仅包含新功能的Backlog用于与利益相关者进行审查和沟通，而技术Backlog中包含的所有问题均保留在团队中，并且从未与利益相关者进行沟通。

Show Me The Value and I will Show You The Priority:

向我展示价值，我将向您展示优先事项：

The 20% capacity approach for Technical Stories (previously known as Technical Debt) along with a separate Technical Backlog is commonly used to hide that the TA cannot assign meaningful value to the items. Although they can specify the engineering sequence, so this is how the Technical Backlog is ordered. They then use the 20% approach to address the items. The key concept to remember here is that Agile exists to deliver business advantage as this is the heart of True Agility. Sadly most technologists are focused solely on the internal infrastructure and what is possible and not on what delivers business advantage. The result of this thinking is that the overall budget allocates a blanket 20% for Technical. This is then treated as an obligation to spend every sprint without ever justifying the value returned, or if this is the best thing to fund this sprint, instead of working with the Product Owner to prioritise all the potential work.

技术故事(以前称为技术债务)的20％容量方法以及单独的技术待办事项列表通常用于掩盖技术援助无法为项目分配有意义的价值。 尽管他们可以指定工程序列，但这是订购技术积压订单的方式。 然后，他们使用20％的方法解决这些问题。 这里要记住的关键概念是敏捷的存在是为了提供业务优势，因为这是True Agility的核心。 可悲的是，大多数技术人员只专注于内部基础架构以及可能的内容，而不关注于提供业务优势的内容。 这种想法的结果是，总预算为技术人员分配了20％的总费用。 然后，这被视为在不证明返回值合理的情况下花费每个Sprint的义务，或者这是否是为此Sprint筹集资金的最佳选择，而不是与产品负责人一起对所有潜在工作进行优先级排序。

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. And 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 to eliminate all types of Technical Debt, resulting in greater effectiveness and allowing focus on delivery of real value.

尽管技术债务确实不存在，但已被接受为敏捷工作的基本特征。 因为它是如此广泛，所以我发现它可以用作评估敏捷成熟度的晴雨表。 与敏捷中的所有内容一样，没有一种技术可以完全孤立地存在。 而且可以在令人惊讶的地方找到成熟的证据，例如技术债务管理。 通过采用并遵循良好做法，可以消除所有类型的技术债务，从而提高效力并专注于交付实际价值。

If your team is already following the Scrum Framework you have all the structures needed to identify, explore and resolve every issue you encounter. The key is realising 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框架，那么您将拥有识别，探索和解决遇到的每个问题所需的所有结构。 关键是要意识到存在问题，并致力于采取行动解决该问题。 但是请确保您正在解决潜在的疾病，而不仅仅是可见的症状。

Quick End Note: The real Technical Debt, the extra effort to work with bad code will that always be there? No as a truly mature team will eliminate this as well. By embedding good coding practices that focus on refactoring and standards from day 1, the team will minimise or eliminate Technical Debt (focusing on this aspect as number 1 priority in any Agile adoption will give you the biggest benefit and ensure you are setting yourself up to succeed long term). Also, 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.

始终牢记“真正敏捷”的关键-如果它不能带来业务优势，那么它就不是真正的敏捷。

Do you want to write for Serious Scrum or seriously discuss Scrum? 您要为《严重的Scrum》撰写文章还是认真讨论Scrum？

翻译自: https://medium.com/serious-scrum/its-time-to-kill-your-technical-backlog-3f19e2347538

kafka积压