愉快的舞会c++

by Roy Yuen

袁y

项目经理和开发人员如何才能(愉快地！)给出实际的发货日期 (How project managers and developers can both (happily!) give realistic ship dates)

Project managers (PMs) are deadline chasers. They think clients want the earliest possible ship date to reduce costs. But that’s a common misconception. What clients really want is the best possible product with the earliest possible ship date. Quality products need well-written code. Developers should use the 12 development approaches on the Joel Test to ensure good source control, encourage daily builds, and make use of QA testers. Realistic deadlines need to be based on estimations from track records. Our project teams wanted to verify the accuracy of our estimations and create a feedback loop for our PMs and developers. We’ve been doing evidence-based scheduling (EBS) with Fog Creek for two months, and I’d like to share what we’ve learned so far.

项目经理(PM)是最后期限的追赶者。 他们认为客户希望尽快发货以降低成本。 但这是一个普遍的误解。 客户真正想要的是在最早的出货日期下获得最好的产品 。 优质的产品需要精心编写的代码。 开发人员应在Joel测试中使用12种开发方法，以确保良好的源代码控制，鼓励日常构建并使用QA测试人员。 实际的截止日期需要基于跟踪记录的估计。 我们的项目团队希望验证我们估计的准确性，并为我们的PM和开发人员创建一个反馈环。 我们已经与Fog Creek进行了基于证据的调度 (EBS)两个月了，我想分享到目前为止所学到的知识。

无需强迫症的基于证据的计划 (Evidence-Based Scheduling without being OCD)

We used Fog Creek’s EBS to track developers’ estimates compared to their actual time spent on a project. This data helped us make better project schedules, and also provided a feedback loop for PMs and developers to improve their estimates for individual tasks.

我们使用Fog Creek的EBS来跟踪开发人员的估计值与他们实际花费在项目上的时间相比。 这些数据帮助我们制定了更好的项目进度，还为PM和开发人员提供了反馈循环，以改善他们对单个任务的估计。

But the emphasis is not on OCD time tracking tools — we trust our developers and PMs to input their times in the project spreadsheet. Besides what Fog Creek mentions in their EBS blog post, here’s what we learned in our implementation.

但是重点不在OCD时间跟踪工具上，我们相信我们的开发人员和项目经理可以在项目电子表格中输入他们的时间。 除了Fog Creek在其EBS博客文章中提到的内容之外，这也是我们在实现过程中所学的内容。

将项目分解为少于2天的任务 (Break down projects into less than 2-day tasks)

As I mentioned above, our EBS tracks estimates vs time spent for user stories and features. The individual features are broken down into tasks (GitHub Issues) that should be completed within two days.

如上所述，我们的EBS会跟踪估算与用户故事和功能花费的时间。 各个功能细分为任务(GitHub问题)，应在两天内完成。

Developers still need to map out exactly how a feature will be put together by creating small enough tasks. For example, rather than just saying “Create shopping cart,” we can break these tasks down into various items, such as “Layout cart product list.” This tracking also benefits our clients, because they can see exactly what we are working on for each bi-weekly sprint. They will be notified if features are completed ahead of or behind schedule, and there will be no surprises. We also track our PMs’ time estimates, because they are not just account managers. They must have some technical understanding. It is important for PMs to learn from their miscalculations and improve their future estimates.

开发人员仍然需要通过创建足够小的任务来精确规划功能的组合方式。 例如，我们不仅可以说“创建购物车”，还可以将这些任务分解为多个项目，例如“布局购物车产品列表”。 这种跟踪也使我们的客户受益，因为他们可以准确地看到我们每两周进行一次冲刺的工作。 如果功能提前完成或延迟完成，则会通知他们，这不会让人感到意外。 我们还跟踪PM的时间估计，因为它们不仅是客户经理。 他们必须具有一些技术知识。 对于PM来说，从他们的错误计算中学习并改进其未来估计非常重要。

By comparing their estimates with the developer’s for the same feature, they can ask questions when there is a large deviation. They learn what takes more time, how technical debt affects a project, and how things work better technically. Our PMs help find the sweet spot: they give their developers enough time to architect and code well while providing a reasonable time frame (and cost) to clients.

通过将他们的估算值与开发人员针对同一功能的估算值进行比较，他们可以在偏差较大时提出问题。 他们了解需要花费更多时间的时间，技术债务如何影响项目以及技术上如何更好地运作。 我们的PM可以帮助您找到最佳的位置：他们为开发人员提供了足够的时间来进行良好的架构和编码，同时为客户提供了合理的时间范围(和成本)。

追踪经过时间 (Tracking elapsed time)

Since our company has casual working hours, many colleagues may take coffee breaks or go for a chat. For EBS, these breaks are counted in the time spent for that feature. Some developers may take frequent breaks and work in quick sprints, while others may work continuously for four hours.

由于我们公司的工作时间很漫长，因此许多同事可能会休息喝咖啡或聊天。 对于EBS，这些中断计入该功能所花费的时间。 一些开发人员可能会经常休息并进行快速冲刺，而其他一些开发人员可能会连续工作四个小时。

In the end, if the estimated time and the actual time spent are the same, then both developers are still accurate. You can check your own working estimates with the app Toggl, leaving the timer on through breaks (however frequent or long) until a feature is completed. But this isn’t really necessary. Because many tasks do take at least a few hours, developers can quickly log the issues they complete daily. Estimates such as 0.25 days are good enough. This is why we do not require time trackers. We measure estimated versus actual time spent as “velocity.” If an estimate and tracked time are the same, we give it a 1. If a developer finished a task in 2 days, but estimated it would take 2.5 days, their velocity was 0.8, meaning they underestimated their speed. The goal with tracking is not to become faster for the sake of it. The goal of EBS is consistency and accuracy. Consistency means that team members can predict each other’s delivery dates based on past performance. Accuracy means consistently achieving a velocity as close to 1 as possible (low range).

最后，如果估计时间和实际花费的时间相同，那么两个开发人员仍然是准确的。 您可以使用Toggl应用程序查看自己的工作估算值，将计时器暂停 (无论是频繁还是长时间)，直到功能完成。 但这不是真的必要。 由于许多任务至少要花费几个小时，因此开发人员可以快速记录他们每天完成的问题。 像0.25天这样的估算值就足够了。 这就是为什么我们不需要时间跟踪器的原因。 我们将估算的时间与实际花费的时间称为“速度”。 如果估计时间和跟踪时间相同，则给它1。如果开发人员在2天之内完成任务，但估计需要2.5天，则其速度为0.8，这意味着他们低估了速度。 跟踪的目的不是为此而变得更快。 EBS的目标是一致性和准确性。 一致性意味着团队成员可以根据过去的表现预测彼此的交货日期。 精度意味着始终如一地获得尽可能接近1的速度(低范围)。

将开发人员估算纳入项目估算 (Factoring developer estimates into project estimates)

When a client comes to us with a project, our PMs break down the features and then estimate how much time is needed for each feature. By adding up all the features, including code reviews and QA, we can give a standard project estimate. EBS helps us see how individual developers can affect projects. Since we started tracking, we have learned interesting patterns. For example, some developers may consistently overestimate their velocity, and are therefore behind their estimates. However, they may still end up finishing features faster than “average” and be on schedule.

当客户来到我们的项目中时，我们的项目经理分解功能，然后估算每个功能需要多少时间。 通过将所有功能加在一起，包括代码审查和质量检查，我们可以提供标准的项目估计。 EBS帮助我们了解各个开发人员如何影响项目。 自开始跟踪以来，我们已经学习了有趣的模式。 例如，某些开发人员可能会持续高估他们的速度，因此落后于他们的估计。 但是，最终完成功能的速度可能仍然比“平均”速度快，并且按计划进行。

Since this behavior is still predictable, our PMs now know how to adjust the estimates given to clients. In contrast, if we had a developer who constantly delivered ahead of time, our PMs would know that they might be able to give clients a tighter estimate.

由于这种行为仍然是可以预测的，因此我们的项目经理现在知道如何调整提供给客户的估算值。 相反，如果我们有一个不断提早交付的开发人员，我们的项目经理将知道他们可以为客户提供更严格的估计。

It just goes to show that evidence is even better than experience.

它只是表明证据比经验更好。

其他EBS的观察和学习 (Other EBS observations and learnings)

We did learn something else interesting: more experienced developers don’t necessarily estimate better. One possible reason is because we delegate complex features to them. Even with detailed planning, there is a high level of uncertainty. Issues need to be addressed as development progresses.

我们确实学到了其他有趣的东西：更有经验的开发人员不一定会更好地进行估算。 一个可能的原因是因为我们将复杂的功能委派给了他们。 即使进行了详细的计划，仍然存在很大的不确定性。 随着开发的进展，需要解决一些问题。

The goal is to allow developers and PMs to give buffer time for tasks they cannot fully imagine yet, and use existing estimates for common tasks (such as login pages). Another observation is that even though every product is different, some common tasks will always remain just as time-consuming. We should not try to rush for “optimization” just to cut costs. EBS and task tracking on a spreadsheet has also helped us quickly identify recurring delay patterns with certain types of features. Having evidence helps us track patterns so we can better understand our working styles. However, every project is a new project.

目的是允许开发人员和PM为他们尚无法完全想象的任务提供缓冲时间，并使用常见任务(例如登录页面)的现有估算值。 另一个观察结果是，即使每个产品都是不同的，但一些常见的任务将始终保持耗时。 我们不应试图仅仅为了削减成本而急于“优化”。 电子表格上的EBS和任务跟踪还帮助我们快速识别具有某些类型功能的重复延迟模式。 有证据可以帮助我们跟踪模式，以便我们更好地了解我们的工作方式。 但是，每个项目都是一个新项目。

Joel showed how projects should use a Monte Carlo simulation, with 100 possible scenarios, each with 1% probability. This shows the full range of possible futures for a project based on a developer’s randomly selected historical velocity data. The goal is to narrow that range of ship dates for a client, not to fix a date and assume 100% accuracy every time.

乔尔(Joel)展示了项目应如何使用蒙特卡洛(Monte Carlo)模拟 ，其中包括100种可能的方案，每种方案的概率为1％。 这显示了根据开发商随机选择的历史速度数据得出的项目的全部可能期货。 目标是缩小客户的发货日期范围，而不是确定日期并每次假定100％的准确性。

EBS has confirmed that software development is a probability.

EBS已确认软件开发是一种可能性。

最后的想法 (Final thoughts)

For practical reasons, we still give clients an estimated delivery date for a project. We also invite our clients into a Basecamp projects so they know what we are working on each week. When a company or developer (colleagues included!) gives you a project estimation, don’t just look at total days. Regardless of project length, ask for estimates broken down into features, and past records for project ship dates. Understand how a team does their project estimations first, and then factor that in to the long-term budgeting for your product.

出于实际原因，我们仍然为客户提供项目的预计交付日期。 我们还邀请客户参加Basecamp项目，以便他们知道我们每周在做什么。 当公司或开发人员(包括同事！)为您提供项目估算时，不要只看总天数。 无论项目时间长短，都要求提供细分为功能的估算值以及项目发货日期的过去记录。 首先了解团队如何进行项目估算，然后将其纳入产品的长期预算。

Did you enjoy this post? If so, please hit the clap button so more people see it. Thank you!

你喜欢这个帖子吗？ 如果是这样，请点击拍手按钮，让更多的人看到它。 谢谢！

? At Oursky we’re all about helping brands and entrepreneurs make their ideas happen. Get in touch if you’re looking for a partner to help build your next digital product.

？ 在O ursky，我们致力于帮助品牌和企业家实现他们的想法。 如果您正在寻找可以帮助您构建下一个数字产品的合作伙伴，请与我们取得联系。

翻译自: https://www.freecodecamp.org/news/how-project-managers-and-developers-can-both-happily-give-realistic-ship-dates-2d5e4ec42df7/

愉快的舞会c++