«Это займет от 3 до 6 месяцев»
Точно так же, как курица предшествует яйцу (да ладно, вы знаете, что я прав), оценка проводится перед каждым проектом разработки программного обеспечения. На самом деле, многое зависит от оценки, и во многих случаях это решающий фактор, будет ли проект вообще. Надеюсь, вы понимаете, к чему я клоню - оценки чрезвычайно важны.
В Code Runners недавно мы провели небольшой внутренний семинар для наших молодых разработчиков, посвященный практике выполнения оценок. Мы понимаем, что большая часть успеха проекта зависит от правильного начала работы и управления ожиданиями как в команде, так и в наших клиентах. Вот что мы обсуждали.
Зачем нужны оценки?
Наиболее очевидная причина - указать размер, стоимость и дату проекта. Ни один клиент не предоставит вам подробное описание того, чего он хочет, с временной шкалой «всякий раз» и бюджетом «не имеет значения».
Вам необходимо иметь конкретные числа, которые можно измерить. На самом деле это можно применить ко всему. Вам нужны данные, которые можно дать количественной оценке и на основе которых можно принимать осознанные решения. Справедливая оценка позволит вам решить, какие инвестиции являются разумными. Чем более подробная оценка, тем больше она позволяет вам идти на компромисс между отдельными функциями в пользу бюджета и / или времени.
Внутренняя точная оценка дает вам информацию о скорости работы команды и о том, какой объем работы может быть выполнен за одну итерацию. Он вписывается в гибкий контекст, позволяя разбивать разработку на более мелкие интервалы, зная, сколько можно завершить и выпустить.
Почему сложно оценить?
По определению, «оценка» - это грубый расчет стоимости или количества чего-либо, основанный на личном суждении. Все в этом термине выражает неточность и жесты "давать или брать". Неудивительно, что это так сложно сделать. Учитывая, что требования клиентов часто неясны из-за отсутствия углубленного бизнес-анализа, оценка предложения по проекту кажется выстрелом в темноту.
Оценка может стать все труднее, если технология, которую необходимо внедрить, незнакома. Новая технология не означает полностью новый язык программирования, но даже новая структура или библиотека могут вызвать невообразимые проблемы, особенно если рассматриваемая технология является предварительной версией, в которой все еще есть некоторые скрытые ошибки и ограничения.
Наконец, оценка зависит от личного мнения и опыта, что означает, что отдельные люди могут давать разные оценки на основе своих профессиональных взглядов. Это начинает становиться проблемой, когда программисты пытаются оценить задачу для других членов команды. Бывают даже случаи, когда личная гордость мешает точной оценке - старшие разработчики могут не захотеть признать, что функция займёт у них слишком много времени.
Действия, которые следует включить в оценку.
Чтобы точно спрогнозировать, сколько времени потребуется вашей команде на выполнение задачи, вам необходимо принять во внимание все, что входит в этот процесс. Исходя из нашего опыта, деятельность можно условно разделить на 7 категорий.
Планирование и анализ
Это предварительная стадия разработки, которая включает в себя участие бизнес-аналитика (либо с вашей стороны, либо со стороны клиента). Его можно структурировать в виде так называемых «сессий по уходу», где отдельные детали задачи обсуждаются всей командой и решаются вопросы неопределенности. На этом этапе важно понять, зачем эта функция нужна и что с ней нужно делать.
Дизайн и развитие
Довольно просто. Этап начинается с обсуждения таких тем, как архитектура и дизайн кода в команде разработчиков. Затем он переходит к собственно кодированию.
Тестирование
Не всегда необходимо, но зависит от клиента и конкретного проекта. Он может состоять из модульного тестирования, интеграционного тестирования, регрессионного тестирования и / или ручного тестирования в среде разработки.
Проверка кода и интеграция
Опять же, не всегда необходимо, но в целом полезно иметь. Вы можете значительно уменьшить количество ошибок или других недостатков кода, добавив в процесс еще одну пару глаз. На этом этапе вам нужно подумать о времени для проверки самого кода и возможных изменений после проверки. Далее идет интеграция с основной веткой и развертывание для разработки.
Документация
Там, где это применимо, необходимо надлежащим образом вести полезную документацию. Считайте это вложением времени в будущее.
Коммуникация
Неизбежный, но часто игнорируемый при рассмотрении оценок - встречи занимают не менее 20% времени в процессе разработки. Это также часть разработки функции и, как таковая, должна быть включена в планирование. Разные члены команды (BA, QA, внешняя сторона и т. Д.) Имеют разные обязанности и должны передавать свои знания и работу следующему «игроку».
Буферы
Наконец, всегда включайте до 30% буферного времени в каждую оценку. Это объясняет нечеткие требования, которые могут измениться со временем, незнакомые технологии, которые необходимо исследовать разработчикам, а также потенциальные регрессии и сложности.
Следите за обновлениями Часть 2, где я поделюсь некоторыми советами о том, как повысить эффективность оценки программного обеспечения.
Вы можете посмотреть исходное сообщение на нашей домашней странице.
