Куда уходит время?

Первый вопрос, который меня волновал при планировании трудозатрат: зачем прикидывать сроки реализации, если мы все равно всегда ошибаемся?

Основная причина, по которой нам нужно оценивать трудозатраты - необходимость в определении сроков и стоимости реализации проекта или конкретной задачи (срок реализации не то же самое, что трудозатраты, но сроки зависят от фактических трудозатрат).

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

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

Чаще всего цель проекта разбивается на пользовательские действия (User Stories), которые делятся на задачи, которые в свою очередь на подзадачи и т.д. И так до тех пор, пока каждая задача станет понятной человеку уровня младший специалист и будет иметь четкие критерии, как проверить ее реализацию. То есть фактически мы считаем трудозатраты элементарных задач (такие задачи длятся не более 40 часов) и складываем их для расчета времени на весь проект.

Поэтому здесь я опишу свои наблюдения, как аналитика: что влияет на длительность реализации, что нужно учитывать при планировании трудозатрат и какова роль аналитика в этом.

Подготовка

Начнем с того, что для того, чтобы оценить трудозатраты, нужно точно понимать, какой функционал нужно реализовать в рамках данной задачи. То есть необходимо проанализировать все бизнес требования и составить полное техническое задание (функциональные и нефункциональные требования + протестированные требования, проект интерфейса). Без ТЗ трудозатраты НЕ оцениваются. Если рамки задачи будут определены не точно, в процессе разработки может выясниться, что без реализации ранее пропущенного требования сделать задачу не получится или это требование принципиально для бизнеса и все же придется реализовывать этот функционал увеличивая трудозатраты.
Собранные требования также нужно протестировать - несоответствия могут обнаружиться уже на этом этапе.

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

Этапы реализации

Для того, чтобы понять, на что пойдет время, нужно понимать из каких этапов состоит реализация задачи:

• Разработка
• Анализ задачи (здесь - дополнительный анализ задачи)
• Тестирование
• Доставка нового функционала конечному пользователю
• Настройки системы
• Написание технической документации
• Написание документации для пользователей

Каждый из этих пунктов длится по-разному в зависимости от задачи, сотрудников, компании и иных обстоятельств, а может и вовсе отсутствовать. Например, где-то мало уделяют времени на тестирование, а где-то отсутствует code-review.
Не стоит браться оценивать задачу, если нет понимая, какие этапы нужны для ее реализации.

Все зависит от людей

Длительность выполнения зависит от того, кто будет выполнять задачу, а именно от характеристик сотрудника:

• уровень профессионализма - если задача достанется специалисту новичку, то это может занять больше времени, чем, если задачу берет сеньор, или если задачу нужно выполнить на в принципе незнакомой технологии, то на ее изучение тоже уйдет дополнительное время
• знание предметной области - человек, который хорошо ориентируется в предметной области, вероятно, быстрее поймет, что нужно сделать и быстрее реализует или протестирует задачу
• внимательность и добросовестность сотрудника - если разработчик, работает невнимательно, часто допускает ошибки, то тестировщик часто будет возвращать задачу обратно с найденными багами, исправления кода будут требовать повторного ревью и так далее
• подход к работе - кто-то работает быстро и качественно, кто-то делает все медленно, не торопится и 10 раз попьет кофе или поболтает с коллегами

Почти всегда команда состоит из сотрудников разного уровня и разного опыта работы в данной предметной области, поэтому, создавая задачу бывает так, что мы заранее не знаем, кому она достанется: задачи назначаются в зависимости от командной нагрузки. Тогда одну и ту же задачу один сотрудник может сделать неделю, а другой за 1 день.

Разработка

При разработке время тратится на:

• изучение ТЗ, предметной области
• написание кода
• ревью кода
• решение технических сложностей
• изучение новой технологии
• собрания, обсуждения реализации задачи с коллегами
• правки при обнаружении ошибок

Влияние различных факторов на этапы разработки:

• изучение ТЗ, предметной области - написанное ТЗ, опыт разработчика в предметной области (специалист с большим опытом в данной области, вероятно, быстрее поймет, что нужно сделать)
• написание кода - профессионализм разработчика, полнота написанного ТЗ, подходы к разработке (TDD, парное и тд), особенности существующей системы (иногда код приложения содержит много легаси-кусков, из за которых приходится сильно заморачиваться, чтобы выполнить элементарную задачу)
• ревью кода - влияет подход к ревью, опыт ревьюеров (в некоторых командах ревью не проводят совсем, в некоторых стремятся к идеальному коду, поэтому часто приходится исправлять код)
• решение технических сложностей - влияет сложность и особенности системы, а также профессионализм разработчиков, умение находить лучшие решения (например, в процессе реализации может выясниться, что применяемый алгоритм неоптимальный, или нужно добавлять индексы, или использовать кэширование - это дополнительная разработка и тестирование)
• изучение новой технологии - влияет способность к обучению, сложность технологии
• собрания - влияет понятность ТЗ, насколько сложная система, опыт в предметной области (иногда предметная область настолько сложная, что приходится часто обсуждать, что именно делаем, так как у команды слабое понимание, как это должно работать)
• правки при обнаружении ошибок - профессионализм разработчика, особенности существующей системы, подробность описания ошибок, локализация ошибок

Тестирование

При тестировании время тратится на:

• изучение ТЗ, предметной области
• создание тест плана, тест кейсов
• проверка функционала
• регрессионная проверка
• написание баг репортов
• собрания, обсуждения реализации задачи с коллегами
• подготовка тестовых примеров, подготовка данных

Тестирование будет занимать 30-50 % от времени написания кода

Влияние различных факторов на процесс тестирования:

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

Общий вывод про этапы выполнения следующий: длительность реализации каждого этапа будет зависеть от сложности системы, от уровня профессионализма сотрудников и от полноты написанного ТЗ. Так же на все этапы влияет количество проектов и задач в команде, переключение с задачи на задачу также отнимает дополнительное время. Дополнительно стоит учитывать, что разработчик, тестировщик и другие члены команды (и даже люди других профессий) не могут каждый день бесперерывно работать 8 часов в день. Поэтому по сути в день будет около 6 часов эффективной работы.

Длительность по частям

Зная все этапы реализации задачи, для планирования трудозатрат нужно оценить длительность каждого, и сложить вместе.

Написание конкретных частей ПО лучше всего оценит опытный разработчик.

Задачи по тестированию займут 30-50% от времени, потраченного на разработку.

Остается учесть примерные трудозатраты на самые распространенные этапы:

• доработка и исправление неисправностей, refactoring – 25% от разработки
• время на риски – по крайней мере, 10% от общего времени
• время на изменения – по крайней мере, 10% от общего времени
• управление проектом – 15% от всего времени проекта
• доставка функционала конечному пользователю - минимум 5% от общего времени

Оптимистичный и пессимистичный прогноз

В некоторых командах принято давать две оценки - оптимистичную и пессимистичную. Оптимистичная - та, к которой мы стремимся, если все будет идеально. Пессимистичная - это та, оценка которая учитывает определенные риски. Это больше применяется к большим задачам.

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

Сильно завышенное планируемое время тоже не является хорошим показателем, так как команда любит использовать выделенное время по полной, наводя идеальный порядок, а также это подрывает доверие заказчика.

Вывод

Дать 100% точную оценку невозможно, это зависит от большого количества факторов, но в наших силах сделать все возможное, чтобы снизить уровень неопределенности.

По сути при планировании трудозатрат, мы планируем все этапы реализации, это намного лучше, чем просто сесть и начать писать код, не зная, что в итоге получим.
Самое важное для подготовки к оценке трудозатрат - наличие ТЗ.

Навык планирования приходит с опытом и с повышением уровня знания системы. Главное, постоянно анализировать фактические и планируемые трудозатраты и выделять моменты, по которым были неверные предположения.