eta策略_ETA的艺术

eta策略

How to give precise development time estimations for your feature

如何为您的功能提供精确的开发时间估计

信守承诺 (Making promises you can’t keep)

Imagine the following scenario: Greg is a Front-end developer at a startup. He’s been given a new feature to work on. His manager, Anne, is asking him for a time estimation. Greg looks over the design and ballparks “5 days”. Anne thanks him and goes on to report it to her manager.

想象以下情形：Greg是一家初创公司的前端开发人员。 他被赋予了一项新功能，可以继续工作。 他的经理安妮(Anne)要求他提供时间估计。 格雷格(Greg)负责“ 5天”设计和规划。 安妮感谢他，并继续向她的经理报告。

Greg, much like most of us, did what he always does — tried to estimate the overall time it would take him, and give a very general estimation. The issue? this feature will actually take Greg 14 days. It will need to be tested by QA, reviewed by the Designer and Product manager, and gradually released to test groups until its release is complete.

与我们大多数人一样，格雷格(Greg)像他大多数人一样，做了他总是做的事情–试图估计他所需要的总时间，并给出一个非常笼统的估计。 问题？ 此功能实际上需要Greg 14天。 它将需要质量检查进行测试，由设计者和产品经理进行审查，并逐步发布给测试组，直到完成发布。

The result? Greg started working on the feature but kept postponing the due date because of issues he “couldn’t predict”. He had to work weekends to make time and his manager, Anne, was frustrated with the delay.

结果？ Greg开始研究该功能，但由于他“无法预测”的问题而推迟了截止日期。 他必须周末工作才能抽出时间，而他的经理安妮(Anne)对延误感到沮丧。

How could this have been avoided? simple — Greg should have done a proper technical design process before giving his ETA, communicating it better to Anne.

如何避免这种情况？ 很简单-格雷格(Greg)在提供他的ETA之前应该已经进行了正确的技术设计流程，可以更好地与Anne交流。

什么是“ ETA”？ (What is “ETA”?)

ETA stands for Estimated Time of Arrival. In the development world, it often refers to an estimated due date of a project. When asked to give an ETA you are asked to estimate the effort of a task and the subsequent time it will take you to accomplish it.

ETA代表预计到达时间。 在开发世界中，它通常是指项目的预计到期日。 当要求您提供ETA时，您需要估计任务的工作量以及随后需要花费的时间才能完成任务。

ETA与截止日期有何不同？ (How does an ETA differ from a Deadline?)

In tech-speak, a Deadline is a non-negotiable date up until which the project needs to be done. There is little room for negotiating deadlines — most of the time they are set by external factors like public release dates, Campaigns, Competition, Board, and various other factors.

从技术角度讲，截止日期是不可协商的日期，直到需要完成项目为止。 谈判截止日期的余地很小-大多数情况下，它们是由外部因素(例如公开发布日期，竞选，竞赛，董事会和其他各种因素)设定的。

An ETA is much more flexible and depends on your internal estimation of the feature. As the name suggests, it is an estimation — it can vary and can end up being a bit shorter or longer. That does not mean that giving an accurate estimation is not important; ETAs are relied on for sprint planning and other departments' road maps.

ETA更加灵活，取决于您对该功能的内部估计。 顾名思义，这是一种估计 ，它可能会有所不同，最终可能会变短或变长。 这并不意味着给出准确的估计并不重要。 依靠ETA来进行冲刺计划和其他部门的路线图。

为什么要给出精确的估计？ (Why should I give precise estimations?)

这是一项难得的技能，可反映您的专业水平 (It’s a rare skill that reflects on your professionalism)

When you give estimations and follow through with them consistently you are perceived as more accountable, reliable, professional & technically apt. Your managers rely on your estimations — and standing by them means standing by your word.

当您给出估算并始终如一地遵循它们时，您会被认为是更负责任，可靠，专业和技术上更贴切的。 您的经理依赖于您的估计，而站在他们身边就意味着您在信守诺言。

它创造更好的产品 (It builds better products)

The process through which you reach an estimation will lead to a better-built product since you take the time to plan it based on code architecture and not make rash decisions due to time restraints or after-thought patchwork.

进行估算的过程将导致产品质量提高，因为您需要花时间根据代码体系结构进行计划，而不会由于时间限制或事后的拼凑而做出轻率的决定。

进行良好的时间估算 (Getting to a good time estimation)

The key to giving a good estimation is making the core decisions before development starts, making sure to answer any open questions.

做出正确评估的关键是在开发开始之前做出核心决策，并确保回答所有未解决的问题。

1.规格 (1. Spec)

Every feature should start with a proper spec. A spec is a written document, usually created by a Product Manager, that describes the feature in detail. It will usually explain the motivation for the feature and metrics it is predicted to effect. It serves as one source of truth for feature requirements and would describe the user flow and expected behavior of the UI.

每个功能都应以适当的规格开头。 规格是通常由产品经理创建的书面文档，详细描述了该功能。 通常，它将解释功能预期的动机和度量。 它是功能需求的真实来源之一 ，并且将描述用户流程和UI的预期行为。

Starting the technical design process without a Spec is a recipe for trouble since you will be working off of your understanding of the design or off-hand statements- which may not match the Product Manager’s vision.

启动无规格的技术设计过程是麻烦，因为你将你的设计报表─这可能不符合产品经理的视野或副手理解合作过的配方。

2.开球 (2. Kick-off)

A kick-off is a meeting in which the feature is presented to all those who will participate in the development process. It sometimes precedes the Spec which may be created following the kick-off. The goal of the meeting is to present the feature and explain the motivation for it; which pains is it going to solve? which users is it targeting?

开幕式是一次会议，其中向所有将参与开发过程的人员介绍该功能。 有时它会在启动之后创建的规范之前。 会议的目的是介绍功能并解释其动机； 它要解决哪些难题？ 它定位到哪些用户？

During the meeting, an initial design or wireframe is usually presented, and the general flow is described. All stakeholders should be present in this meeting — the product manager, designer, developers (Front end & Back end), QA person, BI person, and whoever else is involved. It is a chance for all of those to understand the feature, ask questions, and raise potential issues.

在会议期间，通常会提出初始设计或线框，并描述总体流程。 所有利益相关者都应出席会议-产品经理，设计师，开发人员(前端和后端)，质量保证人员，商务智能人员以及其他参与人员。 所有这些人都有机会了解此功能，提出问题并提出潜在问题。

3.技术设计 (3. Technical Design)

This is where the magic happens. Technical Design is a process made by the developer working on the feature. It will eventually produce a document which details the development changes that need to be made.This is your time to plan out the architecture of your code, plan out the logic, and make sure you understand what you’re going to build and how.

这就是魔术发生的地方。 技术设计是开发人员开发功能的过程。 最终将产生一个文档，其中详细说明了需要进行的开发更改。这是您的时间 规划代码的体系结构，逻辑，并确保您了解要构建的内容以及构建方式。

In the Technical Design document, I recommend writing down the following things which should help you come up with a development plan:

我建议在技术设计文档中写下以下内容，以帮助您制定开发计划：

Feature descriptionDescribe the feature to make sure you understand the main goals and the impact it would make. Note who will be your collaborators on the feature — who will do the Front end, Backend, QA, or PR reviews.

功能说明描述功能，以确保您了解主要目标及其可能产生的影响。 注意谁将成为您在功能上的合作者-谁将进行前端，后端，质量检查或PR审查。

Target usersDifferent features target different user segments, such as first-time users, logged in/out users, etc. Make sure you understand which users this feature is for as it will probably affect development.

目标用户不同的功能针对不同的用户群，例如初次用户，登录/注销用户等。请确保您了解此功能适用于哪些用户，因为它可能会影响开发。

3rd party toolsUnderstand if you can and want to use any external tools or packages for certain parts of the feature. Compare the various options and choose which one fits your needs the best.

第三方工具了解是否可以并且想要对功能的某些部分使用任何外部工具或软件包。 比较各种选项，然后选择最适合您需求的选项。

Current code structureThis is relevant if you are refactoring an existing feature or adding onto an existing one. It’s important to understand the current code and preferably speak to the original code owner to understand it better.

当前代码结构如果要重构现有功能或将其添加到现有功能中，则这是相关的。 了解当前代码很重要，最好与原始代码所有者联系以更好地理解它。

API contractDecide on the API for the Backend/Front end communication; Which routes will you need to create or fetch data from, and how will the response object look like.

API合同确定用于后端/前端通信的API； 您需要从哪些路由创建或获取数据，以及响应对象的外观。

Development changes (Yes, this is the hard part)Plan out your architecture- the components that should be added, object types, classes, DB changes, files that would be added. Describe the main changes in the code that this feature will require.

发展变化 (是的，这是困难的部分) 规划您的体系结构-应该添加的组件，对象类型，类，数据库更改以及要添加的文件。 描述此功能所需的代码中的主要更改。

Mobile / BI / TestingBe aware of any changes needed for Mobile-web, or how it relates to the mobile-app (if exists). Understand which events would need to be tracked for analytics purposes, and which unit/E2E tests need to be added.

移动/ BI /测试请注意移动Web所需的任何更改，或与移动应用的关系(如果存在)。 了解出于分析目的需要跟踪哪些事件，以及需要添加哪些单元/ E2E测试。

Task breakdownExtract the development changes into an ordered list of tasks. Think of the steps you need to take in order for the feature to be complete and the logical order you would do them in. This breakdown can be later translated into tasks on your Task management platform (like Jira or Asana).

任务分解将开发更改提取到任务的有序列表中。 考虑一下完成该功能所需采取的步骤以及执行这些功能所遵循的逻辑顺序。此细目分类以后可以转换为任务管理平台上的任务(例如Jira或Asana)。

4.设计评审 (4. Design Review)

The Design Review is where your teammates review the technical design that you made. It can be a meeting where you present the design review document to a few other developers, to allow them to give feedback. If making a presentation sounds like overkill, sharing the document for comments will also do. It is sometimes the last chance to make sure you didn’t miss anything and get another pair of eyes on it!

您的队友可以在“设计审查”中审查您所做的技术设计。 这可能是一次会议，您可以向其他一些开发人员出示设计审查文档，以使他们提供反馈。 如果进行演示听起来有些矫kill过正，则共享文档以进行评论也可以。 有时这是确保您没有错过任何东西并获得另一双眼球的最后机会！

估算工作量 (Estimating effort)

After you got your Technical Design reviewed and you have the final version, you can start evaluating the overall effort. You should start with the task breakdown- break each task into smaller sub-tasks and evaluate the time it will take you to finish them. Small sub-tasks are much easier to estimate than larger tasks.

在对技术设计进行审查并获得最终版本之后，您可以开始评估总体工作。 您应该从任务分解开始-将每个任务分解为较小的子任务，并评估完成这些任务所花费的时间。 小的子任务比大的任务容易估计。

When you have the list of tasks & subtasks with effort estimation you can sum them up- This is your initial estimation.

当您具有带有工作量估算值的任务和子任务的列表时，可以将它们加总-这是您的初始估算值。

Consider the average time it takes to get your PRs reviewed. Make sure you add that time to the estimate, along with time for QA rounds, review with the Designer and Product manager, or other processes in your team’s workflow. I would also recommend adding more time if you are delving into an unfamiliar codebase or using a new tool for the first time.

考虑一下使您的PR复审所需的平均时间。 确保将时间与估算时间相加，并与设计者和产品经理一起检查，或与团队工作流程中的其他过程一起进行。 如果您不熟悉陌生的代码库或第一次使用新工具，我还建议增加更多时间。

给出最终估计 (Giving a final estimation)

Now it’s time to take your estimation (let’s say it’s 14 days) and spread it out on the calendar. Count only the business days (no weekends), and take into account short days, holidays, or meeting-packed days where you won’t get much done. There you have it — your final ETA!

现在是时候进行估算了(假设是14天)，并将其分散到日历中。 仅计算工作日(不包括周末)，并考虑短时间，假期或会议忙碌的日子，而这些事情您将不会做很多事情。 一切准备就绪-您的最终ETA！

交流ETA (Communicating the ETA)

When communicating the ETA to your manager or colleagues — use dates and not days. When speaking with dates it is much more clear when everything will be done. I also recommend explaining the release process and if your final ETA is the public release date or an initial release.

与您的经理或同事交流ETA时-使用日期而不是天。 与日期交谈时，将更清楚何时完成所有操作。 我还建议解释发布过程，以及最终的ETA是公开发布日期还是初始发布。

后推 (The push-back)

More often than not, you will receive push-backs and raised eyebrows for your comprehensive estimation. This is the case when you give a thought out estimation based on technical design and include testing, PR time, and reviews — it gets longer and more realistic.

通常，您会收到推receive和扬起的眉毛，以进行全面的估计。 当您基于技术设计进行深思熟虑的评估并包括测试，PR时间和审查时，就是这种情况，评估会变得更长，更现实。

I believe it is better to give a real, planned-out estimation that may be a few days longer, than a general — mostly mistaken— short estimation, that would eventually bloat and grow.

我认为，最好给出一个实际的，经过计划的估算，比一般的(通常是错误的)短期估算要长几天，而这种估算最终会膨胀并不断增长。

When facing push backs, refer people to the technical design. Explain the process that you have made and what is included in the feature. Ideally, involve your manager in the Design Review so they can see exactly what comprises the effort.

面对后推时，请帮助人们进行技术设计。 说明您完成的过程以及功能中包含的内容。 理想情况下，请您的经理参与“设计审查”，以便他们可以准确地了解工作量。

Good luck and enjoy the process!

祝你好运，享受过程！

Note: This is a summary of a Talk that I gave for the Israeli Women-in-Tech group “Baot”.

注意：这是 我为以色列妇女科技团体“ Baot ” 进行的一次 演讲 的摘要 。

翻译自: https://levelup.gitconnected.com/the-art-of-eta-6ec69664ee89

eta策略