Нулевая цена копирования, молодость индустрии, отсутствие фундаментального образования и устоявшихся практик постоянно заставляют разработчиков создавать новое. А новое часто приносит неопределенность. И риски, которые трудно угадать заранее. Поэтому, чтобы разработка из “наверное, неделя” не превращалась в “третий месяц почти-почти готово”, придумали Agile методологии. Как методологии помогают? Традиционное “лучше день потерять, потом за полчаса долететь” меняется на “попробовали сделать минимально рабочую версию. Если получилось — переходим к следующей итерации. Если не получилось — меняем концепцию”.
Итерации приносят много разной пользы
Итерации в Agile делают много всего. Фокус команды на небольших, хорошо укладывающихся в кошелек Миллера, целях. Отсутствие “рыскающего курса”, когда заказчик меняет требования каждый день, а через месяц сам в них запутывается. Всегда “готовый к релизу” продукт, достающийся в наследство от предыдущей итерации. Уверенность в том, что ничего не забыли, и не придется сразу после “все готово” два месяца делать инсталляционный пакет.
Со всем этим мешком плюшек от итераций нередко забывают об основной цели: борьбе с неопределенностью. Agile естественным образом сокращает неопределенность до размера одной итерации: у команды через две недели или получиться сделать следующую версию, или нет. Но две недели — это долго.
Можно быстрее. Если использовать знание о том, что наш мозг — не самый совершенный инструмент. Который любит экономить сахар, 95% времени функционирует на автопилоте и имеет склонность использовать самую “сильную” из имеющихся моделей действительности. А “сильная” — не значит “правильная”. “Сильная” — значит “привычная”. Здравый смысл, житейская мудрость, вот это вот всё.
Житейская мудрость — для житейских ситуаций
Чем программирование действительно похоже на математику — так это трудностями в проведении аналогий с привычными вещами. Можно сколько угодно рассказывать начинающим программистам, что “переменные — это такие коробочки для циферок, только в компьютере”. Первый же проект сложнее hello world покажет, насколько концепции программирования отличаются от привычных концепций реального мира.
Получаем интересную ситуацию. С одной стороны, мозг любит экономить ресурсы и всегда использовать самую привычную модель для описания действительности. С другой стороны, привычные модели, здравый смысл и житейская мудрость в программировании не работают. Одно из неприятных последствий: у разработчиков не получается предсказывать, в каких из новых задач могут возникнуть проблемы. Логичные и разумные предположения, что “раз на PHP сделали — то и на Python сможем” просто не работают.
Правильные эксперименты и где они обитают
Эксперименты сами себя не поставят. Устройство нашего мозга таково, что за исключением самых очевидных ситуаций, разработчики будут верить, что ничего сложного в новых задачах нет. Просто потому, что мозг всегда экономит ресурсы. Один из хороших способов борьбы с физиологией — это введение и поддержание ритуалов разработки. Очень хорошим примером такого ритуала является утренний стендап. А эксперименты — они ведь ничем не хуже! И ничто не мешает вам добавить для них отдельный ритуал. Конечно, если вы не используете “жесткую” методологию, вроде SCRUM, где место под эксперименты не предусмотрено. Но про SCRUM я уже писал — использовать его рекомендуется аккуратно и модифицировать под свои нужды при первой возможности.
Хорошей идеей будет вести и постоянно обновлять таблицу компетенций команды: кто что умеет делать, какими технологиями интересуется, что делал за последние несколько лет. Перед началом каждой итерации задачи осматриваются на предмет новых, отсутствующих в таблице штук. После чего тим лид тратит некоторое время на организацию минимальных экспериментов. В ходе которых команда проверяет, что новые штуки не таят в себе сюрпризов и не помешают им закончить итерацию через две недели.
По этой же причины опытные тим лиды стараются сразу начинать проект с черновой версии всей инфраструктуры: автоматическая сборка, тестирование, развертывание, помещение “пустых” приложений в тестовую часть магазинов приложений. Не только чтобы иметь “готовый продукт” в конце каждой итерации. Какой толк от “готового продукта” через неделю разработки, который умеет только запускаться и показывать окно “About”? Это делается больше для того, чтобы проверить весь стек используемых технологий и убедиться, что нигде не затаились сюрпризы. Потому что здравый смысл и житейская мудрость в программировании не работают.