среда, 10 июня 2009 г.

Оценки времени выполнения задачи

У Брюса Эккеля в его "Философии C++" натолкнулся на замечательную оценку времени необходимого для выполнения задачи:

"Прикиньте, сколько времени потребует ваш проект, затем удвойте это число и прибавьте еще 10 %. Скорее всего, ваше внутреннее ощущениевас не подводит; вам действительно удастся получить нечто работоспособное за это время. Еще столько же времени уйдет на то, чтобы привести это «нечто» к более или менее приличномувиду, а последние 10 % уйдут на шлифовку и всякие мелочи...

В последнее время мнение автора по этому вопросу изменилось. Удвоение и прибавление 10 % дает довольно точную оценку (при небольшом количестве непредсказуемых факторов), но чтобы уложиться в это время, необходимо прилежно работать. Если вы захотите сделать программу элегантной и получить удовольствие от своей работы, лучше умножать на 3 или на 4."

Собственно это классическая оценка с помощью числа Pi : "возьмите вашу оценку времени выполнения задачи и умножьте её на Pi, при этом Pi в зависимости от опыта может колебаться от 1,5 до 4"... :) Просто не ожидал её встретить у “самого Брюса”.

Хотя для понимания откуда берётся это Pi в реальной оценке, лучше посмотреть следущее сообщение с rsdn.ru. Оно как-то более точно позволяет оценить время на выполнение задачи. Сам уже начал пользоваться этими пунктами :)

Теперь разберем из чего состоит задача.
1. Если код незнакомый, знакомство. Понимание через отладку. Если нужно рефакторинг. Понимание через рефакторинг.
2. Проектирование нового функционала. Подробное. А не в уме, как на совещании было.
3. Подготовка кода к внесению изменений. Опять рефакторинг.
4. Собственно кодирование. Говорит неделя, ну так 40 часов и запишем. И это только на пункт 4. А вы говорите 16-32.
5. Интеграция с остальным кодом. Это то что в пункте 3 делали, но теперь уже начисто.
6. Тестирование (в это время можно программеру дать другое задание), либо дать на проверку код
соседа, попросить отревьювить код и т.д. Опять же старые баги есть наверно.
7. А теперь откровение. Оказывается после тестирования надо баги поправить. Иначе зачем тестировать-то. А потом снова на тестирование и снова баги.

Ну допустим у меня один баг в неделю на 20 коммитов. Но это в неторопливой обстановке. А ктоме того еще штук десять в неделю "not a bug" и половинка "a change request"

Далее пункты выполняемые совместно с остальными:
8. Покрытие тестами.
9. Документирование.
10. Коммуникации с коллегами по работе, совещание.
11. Коммуникации с начальством, отчеты, совещания.
12. Чтение проф литературы, блогов, RSDN и т.д.
13. Перерывы на отдых, чай, сигареты (кто курит), поболтать на различные темы.
14. Обязательно поболтать с любимой/любимым по ICQ.

А теперь начинаем думать. Я тут 14 пунктов перечислил, а программист (и я тож из таких) думает только про пункт 4.
Причем если вам пункты 12 - 14 не нравятся, то программистам, да и вообще здоровым людям, они необходимы. За пункт 14 вообще перегрызу горло

Комментариев нет:

Отправить комментарий