Всем, кто занимается разработкой программного обеспечения в той или иной степени приходилось сталкиваться с оценками сроков разработки. В этой статье мы бы хотели попробовать разобраться, можно ли сделать точную оценку или, все же, это невозможно и мы можем говорить только о примерных сроках.
Оценки разработки программного обеспечения, хоть и служат важным инструментом, часто оказываются сложными и ненадежными из-за самой природы работы в IT-сфере. Данная проблема существует давно и до сих пор вызывает затруднения. Несмотря на это, мы продолжаем полагаться на оценки в процессе разработки.
Суть проблемы заключается в том, что разработка ПО часто требует творческого мышления, анализа и решения проблем, что делает ее в какой-то степень непредсказуемой. Разработчикам приходится глубоко погружаться в задачу, размышлять и искать нестандартные подходы. Оценки, в свою очередь, пытаются ввести определенную степень структурированности и предсказуемости в процесс, который по своей природе не поддается жестким рамкам предсказания.
Получение точных оценок для программных проектов действительно представляет собой сложную задачу из-за множества факторов, которые несут в себе элементы вариативности. Давайте рассмотрим более подробно, почему это происходит.
Технологический фактор. Технологии постоянно развиваются, предлагая широкий выбор языков программирования, библиотек и инструментов. При внедрении новых технологий неожиданные проблемы могут возникнуть из-за несовместимости версий или ошибок в коде. Даже небольшое изменение, которое на первый взгляд казалось очень простым, может привести к серьезным временным затратам на устранение проблем.
Второй фактор - это люди. В оценках задач мы предполагаем одинаковую продуктивность всех участников команды, но в реальности люди различаются по своей способности работать на постоянно высоком уровне. Такие факторы, как уровень подготовки, знание проекта, усталость, личные обстоятельства, могут повлиять на производительность и сроки выполнения задач.
Третий фактор - требования. Часто требования к проекту могут быть нечеткими или меняться по мере выполнения задачи. Разработчику может потребоваться дополнительное время на пояснение деталей или уточнение требований. Отсутствие своевременной обратной связи или нечеткая обратная связь может привести к задержкам и пересмотру оценок.
Четвертый фактор - внешние зависимости. Часто проекты зависят от сторонних поставщиков, команд или внешних сервисов, поэтому контроль над временем выполнения может оказаться затруднительным. Проблемы с внешними API или сервисами могут вызвать задержки в проекте, поскольку решение проблемы может зависеть от действий сторонних организаций.
В целом, получение точных оценок для программных проектов требует не только тщательного анализа технических моментов, но и учета человеческого фактора, изменчивости требований и управления внешними зависимостями. Только учитывая все эти аспекты, команды могут более точно планировать и управлять проектами, минимизируя риски и возможные задержки.
Еще одна часто возникающая ошибка при оценке - считать, что задачу можно разделить между специалистами. Давайте рассмотрим более подробно, почему простое деление времени на количество разработчиков может оказаться ошибочным.
Представим ситуацию, когда оценка времени на разработку задачи составляет 10 дней. Сразу возникает вопрос: смогут ли два разработчика выполнить эту работу за пять дней каждый? Или, возможно, десять разработчиков справятся за один день? Здесь важно понимать, что в разработке программного обеспечения не всегда справедливо применять простую математику деления времени на количество людей. Это связано с тем, что разработка программного продукта требует не только выполнения задач, но и координации усилий, обмена информацией и согласованной работы команды. Добавление большего числа разработчиков не всегда приводит к пропорциональному увеличению производительности. На практике, слишком много участников в проекте может вызвать дополнительные затраты на коммуникацию, согласование и управление, что, в конечном итоге, может замедлить процесс разработки. Подобно примеру с девятью женщинами, которые не могут родить ребенка за месяц, в разработке ПО есть свои ограничения, которые не могут быть преодолены простым увеличением числа участников.
Почему же заинтересованные стороны стремятся к получению оценок?
Понимание мотивов стейкхолдеров в получении оценок является ключевым аспектом успешного выполнения проектов. Рассмотрим более подробно, почему эти оценки так важны и как они влияют на процесс принятия решений.
Важность оценок становится очевидной, если учесть, что заинтересованные стороны, будь то клиенты, инвесторы или руководство компании, несут ответственность за финансовые и временные составляющие проекта. У них есть четкие бюджеты, строгие сроки и ожидания относительно результата. Получив оценки, они могут более точно планировать свои действия, принимать обоснованные решения и управлять ресурсами эффективно.
В некоторых других отраслях промышленности задачи могут быть достаточно четко определены и могут быть точно оценены. Например, есть производственная линию по сборке и мы знаем, что на сборку одной единицы продукции уходит ровно 10 минут. Таким образом, можно вычислить, что на сборку шести единиц продукции нужен час. В приведенном примере единица продукции строго стандартизирована (в отличие от нашего программного обеспечения), поэтому, если производственная линия не остановится, маловероятно, что будет какое-то отступление от оценки. Но ту оценку, которая работает в других отраслях, нельзя распространить на разработку программного обеспечения. Каждое программное решение, которое разрабатывается, в большинстве случаев предполагает решение новой проблемы. И при оценке мы можем опираться лишь на прошлый опыт, так как у нас нет производственной линии.
Популярные подходы к оценке ПО
Оценка в часах.
При этом способе оценки разработчик (участник команды) говорит: “Эту задачу я смогу сделать за определенное количество часов”. Но на практике это не всегда работает, постоянно присутствует риск недооценки или переоценки задачи. Также оценка будет зависеть от опыта участника команды — двухчасовая задача для разработчика с 10-летним опытом, скорее всего, не будет двухчасовой задачей для молодого специалиста.
Оценка в Story Points - подход, предложенный Scrum.
Story Points - это метод оценки, который помогает сравнивать сложность задач между собой. Определите начальную, простую задачу, пусть это будет задача "разработать экран с пятью полями". Оцените её в Story Points - пусть это будет пять story points. Далее можно взять следующую задачу - "разработать экран с десятью полями" - понятно, что она будет чуть сложнее и ей может быть присвоено, скажем, восемь story points. Таким образом, story points не отражают время, а сложность оцениваемой задачи.
Затем можно рассчитать количество story points, которые команда может сделать за спринт, - помогает определить "скорость" работы команды. Этот показатель основан на коллективной работе команды, а не на индивидуальных усилиях.
Процесс оценки story points, известен как "Planning Poker", проводится во время сессий по подготовке бэклога, где участвуют все члены команды разработчиков. У такого процесса оценки есть много сторонников и противников, но сложно поспорить с тем, что такой процесс позволяет команде обсудить и лучше понять задачи.
Как же можно упростить процесс оценки?
Для упрощения процесса оценки в разработке программного обеспечения существуют несколько эффективных подходов:
- Совместная работа:
Вместо того, чтобы каждый разработчик работал отдельно, парное программирование или групповое программирование могут значительно упростить процесс. Это не просто деление задач, а совместное решение проблемы. Объединение умов позволяет быстрее находить решения, так как две головы лучше, чем одна. - Прозрачность:
Важно держать заинтересованные стороны в курсе вашего прогресса и возможных проблем. Избегайте неожиданностей, делая коммуникацию открытой и прозрачной. - Дробление задач:
Разбивайте задачи на маленькие, детализированные блоки. Это поможет лучше контролировать процесс разработки, упростит тестирование и делает работу более предсказуемой. - Четкие условия оценки:
Если необходимо предоставить оценку, то четко укажите, каковы предварительные условия вашей оценки. В качестве примера, ваша оценка трех дней на реализацию функциональности может предполагать, что требования не изменятся, что не будет никаких конфликтов библиотек и что все внешние API будут доступны в любое время. Это может показаться нереалистичным, но, будучи откровенным, вы также помогаете своим заинтересованным сторонам понять лежащую в основе сложность.
В заключение можно сказать — оценка сложна. Используйте это в качестве ориентира и цели, но помните, что ваши оценки, скорее всего, будут неверными. Вместо того чтобы пытаться получить 100% верные оценки, сосредоточьтесь на понимании задач, постепенно выполняйте небольшие части работы, часто приносите пользу и будьте прозрачны с заинтересованными сторонами.
При оценке проектов, объема работы мы, в компании L-TECH, стараемся со всех сторон подойти к задаче, тем самым минимизируя риски сорвать сроки и перерасходовать бюджет. При работе над проектами используем передовые практики как в разработке, так и в управлении проектами. Напишите нам!
