Неправильный эстимейт готов!

Около года или более назад мы с коллегами обсуждали какие инженерные и управленческие практики в разработке софта нужно явно улучшать. Естественно с великой целью сделать нашим заказчикам еще лучше. Их оказалось не так уж много, и среди них мы определили проблему неточных оценок трудозатрат, не то чтобы это было мега критично, но захотелось что-то с этим сделать. И там же придумали метрику Effort Variance, которая бы показывала насколько мы улучшаемся, и которая была рекомендована для применения. Но эта проблема вместе с метрикой были подвешенными в воздухе вплоть до недавнего времени. Т.е. в силу не_мега_критичности мы ничего с этим не делали и метрику не применяли, и тем лучше. И вот, на днях некоторое стечение обстоятельств заставило посмотреть на неправильные эстимейты по другому.

В одном из обсуждений как-то все сразу согласились, что большая точность самих по себе эстимейтов нам не важна, т.к. практически все команды работают по контрактной модели «Выделенная команда». Где нет цели любой ценой выдержать плановые эстимейты, или же понижать затраты в угоду получения бОльшей прибыли. Не то чтобы такая модель расслабляла, но в силу возникновения определенного доверия между заказчиком и командой, на неточные эстимейты смотрят сквозь пальцы. Тут важнее желаемый результат, требования к которому могут постоянно меняться, а также уровень коммуникаций. Т.е. контрактная модель или же наличие внешних требований к точности эстимейта имеют значение.

С другой стороны согласились, что проблемы с эстимейтами на самом деле возникают несколько раньше. А именно из-за неполного и-или некорректного списка работ (WBS – Work Breakdown Structure). Ведь если что-то забыли в него включить, то естественно и оценивать нечего, и, как следствие, суммарный эстимейт получается неполным. Причем, проблема неполного WBS одна из самых распространенных. Что обычно забываем: ревью кода и документации, приобретения (люди, материалы, оборудование, визы, билеты и т.п.), юнит тестирование, разворачивание системы у заказчика, настройка continuous integration, совещания, исследование и т.п. Таким образом, неправильный эстимейт даже не успевает по настоящему сделать свое черное дело, за него это делает неправильный WBS.

Правила WBS довольно простые:

  • Полнота – т.е. должны быть включены ВСЕ работы
  • Разумная декомпозиция – не должно оставаться объемных и-или неясных работ
  • Вовлечение основных участников для определения полного вида работ
  • Применение шаблонов WBS и ревью WBS.

Ну и высшим пилотажем на пути к правильным эстимейтам (хотя не такой уж он и высший, не было бы лени) является использование каких-то еще моделей оценок, помимо экспертной. Наиболее доступные это аналоговая и параметрическая (модель размера). Их описания есть в других источниках, поэтому позвольте мне их опустить. Напомню лишь, что аналоговая использует данные (эстимейты, WBS и т.п.) аналогичных проектов (фаз), а параметрическая – определяет типичные объекты работ (форма контакта, интерфейс с платежной системой, добавление новости на портал и т.п.) и относительное взаимоотношение их размера между собой. Яркий пример – story points в SCRUM.

Несколько соображений о том, зачем они нужны:

  • Там, где важен точный эстимейт — рекомендуется применять больше одной модели, чтобы можно было сравнить полученные эстимейты, и при большой разбежности – пересмотреть. Плюс рекомендуется делать ревью, и эстимейтов, и WBS.
  • Там, где важен быстрый эстимейт, или же возможность обходиться без эскперта (без индивидуальных оценок). Т.е. в модель можно «забить» определенные входные данные и быстро получить результат. Пример – story points в SCRUM
  • Аналоговая еще может быть полезна и для предсказаний разнообразных  характеристик проекта. Например, если в аналогичном проекте было найдено 200 дефектов, то в планируемом в два раза бОльшего масштаба (масштаб – человеко-часы, story points и т.п.) их будет примерно в два раза больше. Такие же аналогии можно проводить и по рискам, и по проблемам, и по метрикам, и по точности эстимейтов. И принимать соответствующие меры. Только с предсказаниями надо поаккуратней – они информация к размышлению, а не руководство к действию :). Если интересно про предсказания, то есть очень научная методика COQUALMO. Сможете ли (нужно ли) ее применить – вопрос, но для общего развития рекомендую почитать.

Tags: , , , , , ,

Comments are closed.