#разработка #процессы #флоу
Во многих компаниях оценивают время на разработку по статье аналитика. Эта примерная оценка и закладывается в спринт. Иногда даже с хорошим запасом (х1.5-х2). И всё равно мимо. Потом выясняется, что для простой апишки (внезапно) нужно обмазаться легаси-кодом, к которому ни документации, ни комментариев. Потом что-то зависнет на другом отделе. Потом что-то придется переделывать, потому что на старте не уточнили. Хотели сделать за неделю, а сделали за месяц. Если повезло.

Да, обычно разработчики перед оценкой всё равно смотрят статью с тех. заданием, связанный код, возможные подводные камни, узнают детали у аналитика, но пока это не выделилось в отдельный осознанный шаг все вокруг (я тоже) сильно промахивались. Иногда чуть-чуть, а иногда очень даже сильно 🙂 Мне столько раз казалось, что ну вообще всё ясно и понятно, а потом приходилось страдать.

Цель этапа проектирования - разобрать задачу с технической стороны, погрузиться и детально продумать реализацию. Сюда входит декомпозиция на более мелкие задачи, PoC (если нужен), проектирование классов, поиск подходящих паттернов, а так же выделяются ограничения и возможные сложности. Всё это можно обсудить с командой, вместе подумать и найти самое удачное решение. По итогу мы получаем практически готовый план по разработке, которому можно следовать. Эти же статьи - отличная доп. документация для аналитиков, тестировщиков и конечно же разработчиков. Всегда можно вернуться и подробнее изучить контекст принятых решений.

Минусы тоже есть. Я выделяю два основных. На проектирование уходит время. И, конечно же, бывают расхождения реализации с документацией (можно тупо забыть обновить статью).

А как у вас построен этот процесс? Делитесь, очень интересно 🤓