Относится ли правило 80/20 к управлению временем к разработчикам?

Question

Недавняя статья Джеффа , связанная с примером управления временем алгоритма First Fit Decreasing , в котором говорится о принципе Парето ( или правило 80/20) управления временем, то есть 80% работы, которую мы производим, в 20% нашего времени.

Теперь мы все слышали, как программист цитата :

Первые 90% кода составляют первые 90% времени разработки. Оставшиеся 10% кодовых аккаунтов для остальных 90% развития время.

Но все шутки в стороне, часто 20% вашего кода делается для того, что вы хотите, а остальные 80% для обработки исключений ... так действительно ли правило 80/20 применимо к разработчикам?

У кого-нибудь есть примеры того, почему это не относится к нам?

Answer 1

Я думаю, что применяется закон Хофштадтера.

Это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера.

- Дуглас Хофштадтер

На более серьезной ноте взгляните на Управление проектами критической цепочки . Рекомендуется дать две оценки для каждого шага в вашем проекте. Одним из них является оптимистичная оценка, что вы примерно на 50% уверены, что сможете встретиться, если все пойдет хорошо. Другая - более реалистичная оценка, которая учитывает потерянное время и ошибки (моя перефразировка, не вините автора). Со временем и из нескольких проектов вы узнаете, какая оценка является более точной и на сколько. Это зависит от разработчика, поэтому вам нужно отслеживать.

Answer 2

абсолютно! 80% моего времени тратится на stackoverflow.com, а 20% фактически работают.

как ни странно, моя производительность такая же, как и раньше ...

... как всегда!

; -)

Answer 3

По-моему, Козячук правильно понял:

Проблема не столько в плохих оценках времени, сколько в плохих / невозможных оценках объема.

Отображение результата или макеты результатов клиенту / менеджеру как можно раньше, при проверке правильности кодов, приводит к лучшему пониманию целей / требований.

Помните: Проект считается успешным, если он «делает клиентов счастливыми», когда он выполнен, а не когда он удовлетворяет требованиям, известным аналитику, когда проект был изначально запущен. Естественно, это означает, что " движущаяся цель " - это правило, не плохая вещь, и нечего бояться. Это также означает, что я, как руководитель проекта / архитектор, должен обеспечить, чтобы стоимость / изменения в области была / будет сообщена и покрыта .

Как это сделать?

• Ранняя демонстрация, частая демонстрация (для пользователей и их менеджеров в одной комнате)
• Изменить запрос менталитета. (Таким образом, клиент знает, что это за изменения и сколько стоят эти изменения, и поэтому клиент может использовать их для изменения своего проекта по выбору)
• Будьте честны, поговорите с заказчиками и разработчиками ... и убедитесь, что они также общаются друг с другом.

Это всегда работает? NO

Answer 4

2 часа написания юнит-тестов и функциональности демонстрации для ваших клиентов рано сэкономят вам 8 часов на отладку и переписывание.

Answer 5

Я трачу 20% своего времени, делая то, что хочу, и 80% делаю рефакторинг.

Итак, да, если вы считаете, что это "работает" в эти первые 20%. Но эти последние 80% делают его пригодным для повторного использования, его стоит поддерживать и доставлять удовольствие (а не бремя) в будущем.

Answer 6

Почему вы вообще спрашиваете о правиле 80/20? Вы правильно процитировали правило 90/90. Вы уже знаете, что правила 90/90 применяются к разработчикам.

(Извините, что отвечаю фактами вместо шутки.)

Answer 7

Принцип Перето очень применим к разработчикам. Некоторые говорят, что 80% работы делают 20% разработчиков. Кроме того, 80% ошибок генерируются 20% разработчиков. Кроме того, 80% функций используются 20% пользователей. Это те примеры, о которых я слышал.

Answer 8

Да, закон 80/20 применяется к развитию, но вы должны интерпретировать его по-разному:

• Первые 80% кода выполняются за 20% времени.
• Оставшихся 80% времени недостаточно для выполнения оставшихся 20% кода.

Answer 9

Я с Биллом Ящерицей. Это ВСЕГДА занимает больше времени, чем ожидалось, из-за очень неожиданных вещей или, вероятно, вещей, которые не были приняты во внимание.