Оценка трудоемкости атомарной задачи

Дисклеймер

Для понимания статьи крайне желательно знание современных теорий управления. В первую очередь теории ограничений Голдратта.

Я могу быть не прав. Если эксперименты покажут, что я не прав, я это приму.
Проблематика

Оценка трудоемкости атомарных задач очень популярна среди менеджмента. Это одна из техник управления разработкой ПО. Она может быть как полезной, так и вредной. Грамотный исследователь при выборе той или иной техники сначала  формулирует требования, при которых имеет смысл использовать метод, технику, инструменты. Затем ищет экспериментальные данные или ставит эксперимент, в ходе которого проверят, удовлетворяются ли эти требования. Желательно методом двойной слепой выборки.

Требования:

  • Оценка трудоемкости должна приносить пользу. Т.е. улучшать производственный поток.
  • Оценка трудоемкости не должна приносить вреда. Или вред должен быть меньше, чем польза.
  • Оценка трудоемкости должна быть возможной. Если погрешность оценки более 100%, то, может быть, не стоит и давать оценку?

Если вы с этим не согласны, то далее статью можно не читать.

Рисуем фон

Как можно использовать оценку трудоемкости? Или «Какую пользу это принесет?» Будем исходить из того, что наш заказчик умеет считать деньги.

Оценка трудоемкости должна приносить пользу

Для внешнего заказчика важны сроки и цена. Трудоемкость не имеет значения. Нормальный заказчик, заказывая в интернет-магазине стиральную машинку, не спрашивает, сколько часов было потрачено на ее изготовление. Его интересует «когда привезете?» и «сколько стоит?». Но при разработке софта на заказчиков иногда находит помутнение. Рассмотрим два варианта:

  1. срок поставки – неделя, трудоемкость один час, выставленная цена - $10000
  2. срок поставки – две недели, трудоемкость пятьсот часов, выставленная цена - $50000

Существуют менеджеры, которые выберут второй вариант . Но мне интересней иметь дело с теми, кто выбирает первый.

Для внешнего заказчика польза от оценки трудоемкости нулевая.

Для внутреннего заказчика ценность также нулевая. В разработке ПО (как и в любом другом бизнесе) есть только два варианта с размещением ограничения системы. Ограничение системы может быть или внутри производства, или вне. Если вне, то бизнес не беспокоит, какова трудоемкость атомарной задачи - полчаса или два дня. Но может беспокоить, будет ли выведен хотфикс через час или через неделю. Сроки важнее. Для фичи иногда ситуация другая. Там может быть расчет по ROI . Если же ограничение внутри производства, срок выхода задачи в релиз определяется исключительно местом в очереди задач. Совершенно не важно, какая трудоемкость: полчаса или день. Если впереди сотня других задач, то срок выпуска – ориентировочно полгода. По имеющимся у меня статистическим данным, снятым с нескольких фирм: «Эффективность жизненного цикла атомарной задачи, при условии нахождения ограничения внутри разработки ПО, составляет порядка 1%. Это означает, что атомарная задача трудоемкостью в один день будет сделана в среднем через 100 рабочих дней. Но календарное время выпуска можно менять, изменяя очередность в очереди задач». Смотри «Историю одной доски» от Макса Дорофеева.

Польза от оценки трудоемкости нулевая.

Оценка трудоемкости не должна приносить вреда

Сам факт наличия оценки трудоемкости приводит к уменьшению производительности программиста. Исследования Лоуренса и Джеффи от 1985 года (Jeffry, D.R. and M) показали, что производительность падает в полтора – два раза. Смотри книгу «Peopleware». Теоретические выкладки Голдратта в книге «Критическая цепь» это подтверждают. Теоретический расчет Голдратта соответствует  полученным экспериментальным результатам.

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

Несколько лет назад я проводил эксперимент по разбросу трудоемкости типовой атомарной задачи сам. Не «rocket science». Обычной стандартной задачи. Такие задачи программисты решают сотнями. И да, я не предупреждал участников, что я измеряю. Смотри «двойная слепая выборка».

Результат удивил даже меня. Фактический результат показал, что в зависимости от того:

  • выпил ли программист кофе до или после решения задачи,
  • встал с левой или правой ноги,
  • прогулялся после чтения условия или нет,
  • начал с клавиатуры или с мыши

фактическая трудоемкость отличается. Примерно в пятнадцать раз. На одну и ту же стандартную задачу программист может потратить 15 минут. А может полдня. А может час. Фактической трудоемкости. Без учета перекуров и прерываний. Фактической трудоемкости! С прерываниями разница может быть и большей. Т.е. общая причина вариации (термин Шухарта) делает невозможной оценку трудоемкости атомарной задачи.

Примечание. Справедливости ради надо упомянуть еще об особой причине вариаций оценки трудоемкости. Смотри исследование «Ошибка планирования» от 1994 года. Но особую ошибку хотя бы компенсировать можно. А вот попытка компенсации общей причины приводит только к ухудшению ситуации. Смотри пятую главу книги «Пространство доктора Деминга» Генри Нива.

Итог
Оценка трудоемкости атомарной задачи:

  • не приносит пользы с точки зрения определения срока выпуска
  • ухудшает производительность
  • невозможна

Вы можете поставить под сомнение результаты экспериментов. Это нормально. Поставьте свои.

И что делать?

Что делать, если нам для хорошего управления разработкой ПО нужна декомпозиция до атомарных задач, размером в среднем менее двух дней? Об этом в следующих статьях.

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

Вы должны войти, чтобы оставить свой комментарий.