JavaRush/Java блог/Random/Дедлайн близко! Как делать правильные эстимейты проектов

Дедлайн близко! Как делать правильные эстимейты проектов

Статья из группы Random
участников
В современной индустрии разработки ПО есть один аспект, при упоминании которого у многих опытных программистов наверняка всплывают недобрые воспоминания, связанные с головной болью из-за необходимости закончить проект до дедлайна, работой овертайм и т.д. Речь идет о сроках и оценке времени, а точнее, количества человеко-часов, которые необходимы для выполнения проекта. Дедлайн близко! Как делать правильные эстимейты проектов - 1Как отмечают эксперты, и с ними трудно спорить, оценка количества времени на разработку тех или иных проектов — это просто-таки ахиллесова пята для многих, если не для большинства разработчиков. По данным исследования компании McKinsey, 66% проектов по разработке корпоративного программного обеспечения требуют больших расходов, чем планировалось изначально. Из этих 66%, треть выходят за рамки изначального графика, а около 20% не выполняют поставленные задачи и цели вообще. Это еще не все. Исследователи выяснили, что 17% всех ИТ-проектов на практике реализуются настолько не в соответствии с изначальными планами, что начинают угрожать самому существованию компании. А общая сумма перерасхода средств из-за неправильных эстимейтов при планировании проектов и вовсе колоссальна. “В рамках совместного исследования, специалисты McKinsey и Оксфордского университета проанализировали более 5400 ИТ-проектов в разных индустриях. Сравнив бюджеты, графики и прогнозируемые улучшения в производительности с реальными затратами и результатами, мы выяснили, что общий объем перерасходов бюджетных средств в ходе реализации данных проектов превысил $66 млрд — это больше, чем ВВП Люксембурга,” — говорится в исследовании. “Мы также обнаружили, что чем дольше по плану должен продлиться проект, тем более вероятно, что он выйдет за рамки времени и бюджета. С каждым следующим годом работы над проектом перерасход средств увеличивается на 15%,” — добавляют аналитики. В сегодняшнем материале мы поговорим о том, как проводить оценку времени на разработку наиболее эффективно и на что обращать внимание в первую очередь. А также узнаем, как опытные разработчики советуют подходить к эстимейтам. Дедлайн близко! Как делать правильные эстимейты проектов - 2

Методы оценки времени на реализацию программных проектов

1. Сравнение с уже реализованными проектами (метод по аналогу)

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

2. Командная оценка

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

3. Снизу вверх и сверху вниз

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

4. Сторонняя оценка

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

5. Тройная оценка

В рамках данного метода команда формирует три варианта оценки времени на реализацию проекта: оптимистичный (О), пессимистичный (П) и наиболее приближенный к реальному (Р). Далее финальная оценка вычисляется по одной из двух формул: (О+П+Р)/3 или (О+4Р+П)/6. Дедлайн близко! Как делать правильные эстимейты проектов - 3

Советы и мнения бывалых

1. Индивидуальные эстимейты не могут переходить к другим членам команды без изменений

Как отмечают многие опытные разработчики, при планировании нужно помнить о том, что разные программисты сильно отличаются друг от друга по способностям и опыту, как с индивидуальной точки зрения, так и в работе с определенными языками и технологиями. Именно это одна из основных причин, по которым компаниям и командам разработчиков бывает очень сложно точно рассчитать время на реализацию того или иного проекта. Поэтому при оценке времени, которое понадобится члену команды для выполнения работы, следует оценивать индивидуальный уровень и опыт каждого разработчика, а не “среднюю температуру по больнице.”

2. Закладывайте в план на 15-20% больше времени, чтобы застраховаться от рисков

Еще один распространенный совет — закладывать в официальный план на 15-20% больше времени, чем требуется согласно первоначальной оценке, чтобы застраховаться от возможного перерасхода времени в случае непредвиденных проблем и задержек. Наиболее рискованными с точки зрения временных затрат, как правило, являются самые сложные и/или самые непонятные части проекта.

3. Не забывайте о времени, которое уходит на коммуникации

В своем бестселлере Manage the Unmanageable об управлении командой разработчиков авторы Микки Мантл (Mickey W. Mantle) и Рон Лишти (Ron Lichty) утверждают, что в среднем у девелоперов уходит на кодинг только около 55% времени, тогда как остальные 45% они тратят на взаимодействие и общение с коллегами, менеджерами, тестерами, дизайнерами, представителями клиента и т.д. Кроме того, эксперты пишут, что только одна шестая от общего времени работы над проектом приходится непосредственно на написание кода. Половина времени, а то и больше, уходит на тестирование и исправление ошибок. Поэтому опытные разработчики советуют всегда помнить эту статистику и учитывать ее при составлении планов. Особенно это важно для команд, которые насчитывают достаточно много разработчиков. По наблюдениям, добавление новых кодеров в команду, как только их общее число начинает превышать определенный порог (обычно это 5-6 человек максимум), начинает неизбежно замедлять работу над проектом в целом. Происходит это из-за того, что новому разработчику всегда требуется какое-то время на то, чтобы познакомиться с членами команды и уже существующим кодом проекта. Дедлайн близко! Как делать правильные эстимейты проектов - 4

Своевременно корректируйте ошибки в эстимейтах

“Обновлять и корректировать первоначальную оценку после того, как проект запущен и находится в процессе реализации, совершенно нормально. Чем больше информации предоставляет клиент, тем лучше вы понимаете, сколько человеко-часов потребуется на его реализацию. И чем быстрее вы поймете, что план нужно скорректировать, и сделаете это — тем лучше. Не стесняйтесь обсуждать этот вопрос с клиентом, даже если требуется перенести дедлайн или добавить в команду новых специалистов,” — советует Серхио Акоста (Sergio Acosta), опытный разработчик мультиплатформенных приложений. “Конечно, прежде всего за всем этим должен следить проджект менеджер или тимлид, но в реальности им часто не обойтись без участия рядовых разработчиков. Особенно в тех случаях, когда проджект менеджер/тимлид занимается несколькими проектами одновременно или слишком занят, чтобы следить за деталями реализации той или иной составной части проекта,” — добавил Акоста.

5. Варианты оценки времени на проект для клиента не должны сильно различаться

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

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

Также эксперты советуют оценивать ключевые виды работы над проектом отдельно. Это поможет увеличить точность эстимейта и быстрее вычислять его слабые стороны. Так, отдельно можно и даже нужно оценивать следующие виды работ: кодинг, дизайн, аналитика, менеджмент, QA и тестирование, анализ кода, создание документации и руководств пользователя, автоматизацию и т.д. Дедлайн близко! Как делать правильные эстимейты проектов - 6

Вместо эпилога

Впрочем, некоторые эксперты считают, что эстимейты в сфере разработки софта — это зло, и от них нужно отказаться совсем, по крайней мере в жесткой форме. Об этом в своей статье Software Estimation is a Losing Game пишет Ричард Клейтон (Richard Clayton), старший разработчик в компании LotMonkey. “Нужны ли нам эстимейты времени при разработке ПО? Я задавал этот вопрос проджект-менеджерам и корпоративным боссам неоднократно, когда меня просили сделать оценку для какого-нибудь клиента, совершенно не имея достаточной информации и понимания задач. “Конечно нужны, ведь иначе клиент не подпишет с нами контракт,” отвечали они. И, к сожалению, это верный ответ. Он верный, потому что мы позволяем системе работать таким образом, несмотря на то, что разработка софта плохо подходит под данную систему,” — пишет Клейтон. “В реальности команда разработчиков может только реализовать набор возможностей, пропорционально тому количеству времени и ресурсов, которые были выделены. В каком-то смысле, в этом мы похожи на туристическую индустрию — мы не можем гарантировать гостю, что за неделю в нашем резорте он отлично отдохнет и полностью восстановится. Все что мы можем — пообещать, что чем дольше гость у нас остается, тем более отдохнувшим он будет уезжать,” — считает эксперт. Пишите в комментариях, что вы думаете по этому поводу. Какие методы эстимейтов вам кажутся наиболее эффективными, устраивает ли вас нынешний подход к оценке проектов, и стоит ли в корне менять данную систему, как предлагает Ричард?
Комментарии (8)
  • популярные
  • новые
  • старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Vladislav Kuzmenko
Уровень 17
7 февраля 2020, 11:13
Добрый день. еще один пункт можно осветить про стори поинты. т.е., мы оцениваем сложность задачи и сравниваем ее с общей сложностью за период времени, который мы можем закрыть. т.е., если задача на 160 сторипоинтов, а в неделю мы можем закрыть 40, то пилить будем 4 недели. + необходимо дополнительно подстраховаться +-20% (для данного примера + одна неделя). итого 4-5 недель. это из видео it-бороды с ютуба.
Alex
Уровень 17
7 февраля 2020, 10:51
Как бесят эти нарочитые англицизмы, коверкающие язык. Эстимейты, овертаймы и прочее. Зачем? Мода такая?
Григорий
Уровень 24
7 февраля 2020, 11:19
К сожалению, уже устоявшаяся норма в этой отрасли. Менеджеры поголовно говорят на этом языке, что высмеивали даже в Камеди Клабе уже. "Проэскалируй эстимацию" - лично слышал при куче народа.
ディマ_オゾリン
Уровень 38
7 февраля 2020, 12:01
Не только в этой отрасли. Это профессиональный сленг, который имеет место во всех международных отраслях связанных с иностранными языками. РусИнглиш Когда я работал в компании связанной с авиаперевозкой, там тоже было куча слов: зарефандить, рафки, ассесы, просиды и т.д.
Justinian Judge в Mega City One Master
9 февраля 2020, 00:35
Ну, слово "мода" это такой же нарочитый латинизм, компьютер это тоже англицизм , есть же ЭВМ наш аналог. Слово метод - латинизм, функция, валидация, тестирование, копия, стримы, лямбды, база данных, джава кор.. Как джава кор называть, джава ядром? Дело не в моде, это профессиональная лексика и профессиональное общение, которое должно быть эффективным и понятным специалистам. Можно конечно попробовать "никак не могу этот способ джавы написать в собирателе в целое, да и все-равно последняя группа не через предмет подражается" я даже зная что имел ввиду, перечитал и сам не понял. Это все дело привычки, к латинизмам если привык, раз используешь слово мода и тысячи других, к слову компьютер привык, хотя исторически еще в тех же 90-ых слово ЭВМ боролось за существование, привыкнешь и эстимейтить ) ну не захочешь не будешь употреблять, дело каждого. Но слушать придется :)
Sergey Semendyaev
Уровень 41
13 февраля 2020, 14:10
тут всё в кучу мешать не надо. Методы, процедуры, функции и т.п. - да, достаточно давно и прочно вжились в русский язык и слишком неразрывны с теми сущностями, которые они описывают. Но называть оценку эстимэйтом? Про@б сроков овертаймом и пр. Ну давайте уже спикать комплитли на РусИнглише.
Justinian Judge в Mega City One Master
13 февраля 2020, 22:34
"давно", "прочно" это оценочные категории. И донднже тать на павечернице за садовие проливает, программисты спикают на русинглише. Такова профессия, у каждой специальности свой терминологический аппарат. Хотя конечно зависит от языка и компании, если пойти на фуллстека в сеть разливаек, может там и не будет такого. Но если это нормальная компания, с командировками к клиенту в Европу или США, с постоянным общением по всему земному шару, то тогда по другому никак. Как минимум слушать. А говорить дело добровольное, кто и в каком объеме использовать тоже.
14 февраля 2020, 18:42
Мы, программисты у себя в команде просто ржем над нашими менеджерАми, когда их слушаем. Они как малые дети, которые стараются изо всех сил походить на взрослых. Все эти слова англицизмы мы используем, конечно, но когда предметная область разговора тут же рядом java core - это область языка или пакет. его по другому не назовешь. Без фанатизма. Русский язык любим и стараемся не портить.