▶ Большинство проектов взаимодействуют с Внешними сервисами. Например, авторизуют пользователей через социальные сети или рассчитывают стоимость доставки товара. Для этого разработчики выполняют интеграцию через API. Подробности в главе 10.
▶ Наконец, в зрелом проекте обязана быть Документация. Ее главная задача – отчуждение знаний о проекте из голов конкретных исполнителей. Документация снижает риски.
1.1.1. Прогулка по картине мира
Итак, мы героически вляпались в задачу «довести сайт до ума». Как бы я действовал (кое-где – чужими руками)?
Жуть, этот план даже читать больно! А ведь вам завтра крутить окровавленную и облитую слезами ручку digital-разработки:)
▶ Поинтересовался, почему расстались с предыдущим разработчиком, на какой ноте, кто это был. Навел бы справки. По возможности переговорил с разработчиком, составил свое мнение.
▶ Получил от клиента предварительный список требований и задач. Рассказал всю процедуру и описал риски. Запланировал время на то, чтобы вникнуть в чужой код. Возможно, его придется полностью удалить, и все написать по новой. Первое время наша скорость будет ниже, чем у предыдущей команды, и у нас будет больше ошибок, потому что мы не знаем всех взаимосвязей. Также обсудил условия, при которых можно попробовать взяться за задачу.
▶ Грубо оценил стоимость проекта (вилочно, от-до), получил подтверждение бюджета у клиента.
▶ Согласовал работу по Time & Material. Работать с чужим проектом по Fixed Price – самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие дальнейшие планы на сотрудничество. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали – в этом случае посоветовал бы закончить проект с предыдущей командой.
▶ Запросил доступы к коду.
▶ Провел код-ревью – процедуру анализа и оценки качества кода.
▶ Изучил текущую документацию. Если документации нет – это тоже показатель.
▶ Принял решение, можно ли работать с текущим кодом или нужно выбросить и все делать с нуля.
▶ Подписал контракт.
▶ Получил предоплату.
▶ Еще раз уточнил требования. Собрал их в бэклог. Отсортировал по приоритетам. Организовал работу спринтами.
☐ Нарисовал прототипы. Сдал клиенту.
☐ Нарисовал дизайн, если задача это предполагает. Также сдал клиенту.
☐ Еще раз проговорил голосом результат с заказчиком, убедился, что мы все одинаково понимаем.
☐ Доформировал требования на уровне задач в тикет-системе с учетом изменений, которые появились в дизайне и прототипе. Обычно это мелочи, но иногда все разворачивается на 180°.
☐ Дал вычитать требования разработчикам.
☐ Проговорил задачи голосом с командой, ответил на вопросы. Получил оценки от команды, например, методом Planning Poker (подробнее в главе 3).
☐ При необходимости провел рисерч. Это нужно для задач, с которыми команда никогда не сталкивалась.
☐ Запланировал разработку в календарном плане.
☐ Написал тест-кейсы или критерии приемки по каждой из задач.
☐ Запрограммировал. Следил за ходом работ, решал «затыки».
☐ По итогам разработки провел код-ревью нового кода.
☐ Протестировал, исправил баги.
☐ Проверил производительность.
☐ Сдал заказчику проект на тестовом сервере, получил и обработал обратную связь. Мелкие недочеты исправил сразу, остальное перенес в будущие спринты.
☐ Провел ретроспективу с командой, посмотрел, что можно улучшить в проекте и процессах работы.
☐ Актуализировал документацию.
☐ Провел деплой (выкладку на боевые сервера).
☐ Обновил контент.
☐ Проверил работу на боевом сервере.
☐ Подписал акты, получил постоплату.