精益软件工程

Estimation is one of the hardest problems in software development. Trying to calculate the time required to solve complex technical and organizational problems is more magic than art. As Kelly Vaughn on Twitter put it…

估计是软件开发中最困难的问题之一。 尝试计算解决复杂的技术和组织问题所需的时间比艺术更具魔力。 正如Kelly Vaughn在Twitter上所说的那样…

When you give a developer 5 hours for a task, they’ll let you know they need 50 hours once they’ve used up 10.

如果您给开发人员5个小时的时间来完成任务，他们会在用完10个小时后告诉您，他们需要50个小时。

Even looking at the most atomic of these calculations — estimating an engineering task or user story — it’s clear to see that estimations are no exact science. We engineers size stories based on technical complexity, but even that is no exact correlation to time spent, as there are countless variables to this measure — skillset, experience, motivation, relationships — just to name a few.

即使查看这些计算中最原子的内容(估算工程任务或用户情况)，也很清楚地看到，估算并不是一门精确的科学。 我们根据技术复杂性来设计故事的大小，但是即使如此，也不会与所花费的时间完全相关，因为此度量标准存在无数变量，例如技能，经验，动力，人际关系等。

Now multiply that complexity by the number tasks or user stories required to make up a feature. Consider how those variables expand beyond one developer to a team, or group of teams as the complexity of the compounded problems build on each other. As features combine to form epics, and epics may be combined to form a product release, we start to spiral out of control.

现在，将复杂性乘以构成功能所需的任务或用户故事的数量。 考虑一下这些变量如何扩展到一个开发人员之外的团队或一组团队，因为复杂问题的复杂性是相互叠加的。 随着功能组合形成史诗，而史诗可能组合形成产品发布，我们开始失控。

Just as a 1 point story means something completely different team-to-team, the same is true of user story comparison or epic comparison. Estimates on this order of magnitude are practically meaningless, as even the most seasoned teams are only just estimating — and on a much smaller scale. Remember the tweet: 5 could be 50 when you’re standing in front of a pile of work. 5 months becomes 4 years.

正如1分的故事意味着团队之间完全不同的事情一样，用户故事比较或史诗般的比较也是如此。 如此数量级的估算实际上毫无意义，因为即使是经验最丰富的团队也只是估算而已，规模更小。 记住那条推文：当您站在一堆工作前面时，5可能是50。 5个月变成4年。

Excellent advice could be to shut up and plan the sprint, remembering that our agile frameworks like Lean teach us to make decisions late and focus on the most important things first. As an engineer, I know that is usually the right thing to do to be as efficient as possible. On the other hand, I’m offloading a lot of the mental energy that it takes to decide “what’s next” to our product teams.

最好的建议是关闭和计划冲刺 ，并记住我们像Lean这样的敏捷框架教会我们延迟决策，并首先关注最重要的事情。 作为一名工程师，我知道通常应该做的是尽可能提高效率。 另一方面，我要花很多精力去决定我们产品团队的“下一步计划”。

And in product, the eternal struggle is understanding how to plan. How to determine how to spend money and trying to calculate when investments are going to pay off. So the conversation turns to asking for commitments, and 2 weeks isn’t a very long time.

在产品上，永恒的斗争是了解如何计划。 如何确定如何花钱，以及如何计算何时才能获得回报。 因此，谈话变成了要求承诺，而且2周时间不是很长。

I fear the answer includes some nuance, but a few things I think you’ll need first.

我担心答案会有些细微差别，但我认为您首先需要注意一些事项。

• Trust (and invest) in your dev teams

  信任(并投资)您的开发团队

• Enable incremental improvement, and ask for proof

  进行渐进式改进，并要求证明

• Change as a result of tangible output, not perceived progress

  由于有形产出而不是预期的进步而发生的变化

信任(和投资)您的开发团队 (Trust (and Invest) in Your Dev Teams)

The entire agile philosophy is built on the idea of high-performing teams. If you go into the process doubting that your dev team is performing at their best, or that they’re not up to the task, the structure immediately begins to break down. When you don’t trust a developer’s estimate to be the truth — and instead some fake number meant to inflate the work or buy time — you’ve failed.

整个敏捷理念都建立在高绩效团队的思想之上。 如果您进入流程，怀疑开发团队的表现最佳，或者他们无法完成任务，则结构会立即崩溃。 如果您不相信开发人员的估计是事实-而是使用一些虚假的数字来夸大工作或购买时间-您就失败了。

Even in the real scenario where your dev team isn’t so high-performing, trusting their work, estimates, and convictions is critical to the process.

即使在您的开发团队绩效不高的真实情况下，信任他们的工作，估计和信念对于该过程也至关重要。

To continue to build this trust, engineering teams should be invested in and empowered. It’s the goal of the engineering leadership to find, cultivate, and empower great engineers. They should be experts at helping engineers reach their high-performing potential, and clear-eyed about areas to be improved. The culture in the engineering organization should be one that reinforces leadership and learning. Good engineers should be rewarded.

为了继续建立这种信任，应该对工程团队进行投资并赋予他们权力 。 寻找，培养和授权优秀工程师是工程领导者的目标。 他们应该是帮助工程师发挥其高潜力的专家，并且对需要改进的领域保持清醒的头脑。 工程组织中的文化应该是一种加强领导和学习的文化。 好的工程师应该得到回报 。

启用渐进式改进，并要求证明 (Enable Incremental Improvement, and Ask For Proof)

The faster the product is in your hands, the faster you can start to learn. An unreleased product is a net drain on resources, whereas any code in production provides value to users and teams.

产品在您手中的速度越快，您开始学习的速度就越快。 未发布的产品是对资源的净消耗，而生产中的任何代码都会为用户和团队带来价值。

This means that moving a product from development to production is more important than how much value you’re providing per-release. Focus less on understanding the path to deliver on an entire feature or feature-set, and more on how you can start to iterate on the smallest changes possible. Let product ideas evolve instead of trying to decide on perfect early.

这意味着将产品从开发阶段转移到生产阶段比每个版本提供多少价值更为重要。 较少关注于了解交付整个功能或功能集的途径，而更多地关注如何开始迭代可能的最小更改。 让产品创意不断发展，而不是尽早决定完美。

Working software is preferred over planning. Meaning your team should be focused on building. Each sprint, or faster, your engineering team will deliver software that can be demonstrated. Asking for real work to be demonstrated is a cornerstone of the process. Focus less on the scope of work and more on the fact that work can be delivered every sprint.

工作软件优先于计划 。 意味着您的团队应该专注于建设。 您的工程团队每一次冲刺，或速度更快，都将交付可以证明的软件。 要求证明真实的工作是该过程的基石。 更少地关注工作范围，而更多地关注可以在每个冲刺中交付工作的事实。

作为输出结果的变化 (Change, as a Result of Output)

The concept of deciding late can be foreign to project teams used to slow, huge, disruptive releases. It’s scary to “let go and let Lean” when we aren’t used to seeing real code go fast.

决定迟到的概念对于习惯于缓慢，大量，破坏性发布的项目团队而言可能是陌生的。 当我们不习惯看到真正的代码快速发展时，“放手让精益”是令人恐惧的。

In a productive team, you should get used to letting things go to users un-polished, and learn how to react quickly to feedback. Try to resist the urge to change direction before getting feedback from users.

在富有成效的团队中，您应该习惯于让事情不受打扰，并学会如何对反馈做出快速React。 在获得用户反馈之前 ，尝试抵制改变方向的冲动。

Back to Kelly’s tweet — you aren’t going to be able to avoid engineers finding work that needs to be done. The point of the tweet is to focus on not putting too much time, effort, and value in zeroing in on a 5-hour estimate for something we don’t understand yet.

回到Kelly的推文—您将无法避免工程师找到需要完成的工作。 该推文的重点是，不要花太多时间，精力和价值来对我们尚不了解的事情进行5小时的估算。

Instead, let engineers invest that planning time in writing real code. Let them learn from the code they do write. Let them get that code to production — fast! And then, change based on the code in users’ hands.

取而代之的是，让工程师将计划时间投入到编写真实代码中。 让他们从自己编写的代码中学习。 让他们将代码快速投入生产！ 然后，根据用户手中的代码进行更改。

This post was originally published on my blog, at ajkueterman.dev

这篇文章最初是在我的博客 ajkueterman.dev上发布的

翻译自: https://medium.com/@ajkueterman/lean-software-estimation-16fe906feac7

精益软件工程

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208427 人正在系统学习中 相关资源：淘金币抵钱怎么用|淘金币自动领取工具v1.3绿色版.zip_淘金币自动…

来源：weixin_26712121