Как пасти (с)котов. Часть 1: Задачи
Про управление командой разработки, на собственном тяжком опыте.
Ну хорошо, вот наловили по подвалам наняли для вас этих самых программистов. Сидят в комнате, перед компьютерами.
А дальше-то что? Что вы будете с ними делать? Кроме очевидного?
Постановка
присаживайтесь, хотим предложить вам проект такой-то. Будем вашим софтом добывать бериллий на Марсе и телепортировать его на фабрики в поясе астероидов. Беретесь?
Как-то так это обычно и начинается.
Скорее всего к этому моменту у «the Big Boss» уже есть и план проекта и техническое задание, с той или иной глубиной проработки.
Если же нет — ваша первая задача эти два документа родить создать и утвердить.
Если тех.задание писали не вы сами — могут быть разногласия с планом проекта, потому что общие планы часто сочиняют «на глаз», а глазомер у всех разный. Поэтому придется корректировать либо тех.задание либо план до момента совпадения с реальностью и друг-другом.
Вообщем так или иначе у вас на руках оказывается техническое задание и план проекта, где отмечены ключевые этапы — дедлайны по реализации конкретного функционала.
Можно конечно попробовать взять оба документа и закинуть в отдел разработки, вместе с ящиком пива и закусью. Затем закрыть дверь на неделю и ждать что все создастся само: самозарождение жизни и все такое.
Но работает уже не всегда, времена другие.
Поэтому есть более надежный план, называется:
Задачи
Вам нужно нарезать большой документ тех.задания (ТЗ) на отдельные технические задачи, скажу сразу — это будет нихера не просто.
Если разработка начинается с нуля:
рекомендую сделать какой-то скелет проекта и даже базовый функционал сразу одним куском, до начала основной разработки. Часто для такого используется готовый шаблон проекта.
Идеальная постановка или правило «1-1-1»:
одну задачу выполняет один разработчик за один рабочий день.
Очень рекомендую придерживаться именно такой схемы, поскольку она оптимальна с точки зрения физиологии и психологии человека:
работа начинается утром, в момент максимальной концентрации и завершается к вечеру. В большинстве случаев, разработчик сможет укладываться в 8-часовой рабочий день и будет уходить с работы довольным т.к. есть очевидный результат и прогресс.
Также это сократит риск возможного пересечения с другими разработчиками и разруливания последствий в виде сведения правок в коде (merge).
они выматывают, требуют постоянных работ по сведению правок от других разработчиков а по завершению еще и сложного тестирования.
И чем больше и дольше задача — тем все эти процессы сложнее. Поэтому чем меньше длинных задач у вас будет — тем спокойнее будет сон.
Рабочий день
По поводу 8 часов и рабочего дня:
не стоит сильно переживать что какую-то задачу разработчик сделал слишком быстро и опускаться до подсчета часов.
В случае командной работы это не так важно — будет уходить время на сведение изменений, на обновление стендов и так далее. И эти временные затраты уже слабо предсказуемы.
Зато если вы полезете в з#лупу начнете выдавать новые задачи сразу по завершению текущих — разработчики обязательно забьют на начальное тестирование, проверку сборки и выкладывание на стенд. И кто-то рано или поздно сломает сборку — выложит некомпилируемый код или забудет выложить часть правок.
Дальше у вас вместо работы начнется выяснение и поиск виноватых, особенно весело получается если сам виновник сломанной сборки при этом недоступен, например в отпуске или на больничном.
Постановка задачи
Как выглядит хорошо описанная задача?
Максимально конкретно, с указанием к действию:
Необходимо реализовать ввод и отображение списка заказов. Список реализовать с сортировкой, пагинацией и фильтрами. Фильтры по дате создания заказа и статусу. По клику на элемент списка реализовать переход в форму с детализацией.
Не какие-то куски чатов или почтовой переписки, не прямой копипаст из ТЗ а именно отдельно написанный и сформулированный текст.
Помимо описательной части, задача на разработку должна включать технические детали, максимально подробные:
При реализации использовать в качестве шаблона классы Х,Y и Z , сортировку и пагинацию реализовать с использованием Pageable в Spring Data.
Если разработчик думает над реализацией дольше 10 минут — с задачей что-то не так и он гарантированно накосячит.
Постановка задачи считается идеальной, если разработчик может в понедельник утром, после загула на выходных, прочитать ее и сразу приступить к выполнению.
Но идеал конечно достигается с большим трудом, годами тренировок )
Спринты и беклог
Так или иначе, вся разработка придет у вас к какому-то подобию Agile. Даже в случае Waterfall и большого нового проекта — в самой разработке будет аджайл. Просто так удобнее.
Не знаю кто те фантастические твари использующие Kanban — на своей практике живых проектов построенных по Kanban я ни разу не видел. И почему-то видеть не особо хочу.
Вообщем у вас будет Аджайл, а значит будут спринты и беклог.
В беклог вы постоянно набиваете новые задачи, часть из них (из расчета 1 задача x 1 день x 1 разработчик) идет в набивку спринта, который затем запускается.
Есть три вещи в которые я не верю ввиду опыта:
бесплатные шлюхи, честные политики и спринты короче двух недель
Поэтому идеальная длина спринта это: две с половиной недели.
2.5 недельный спринт — это 100% гарантия что с проектом все хорошо, что все идет по плану. Если у вас стабильно получаются такие спринты — вы сможете предсказывать даты релиза с точностью Ванги, что безусловно порадует руководство.
В такое временное окно спокойно войдут как задачи на новый функционал так и исправления багов и недочетов.
Ближе к концу спринта начинается заморозка:
за пару дней до завершения запрещается добавлять какой-либо новый функционал — только мелкие правки и исправления ошибок. Если кто-то не успел закончить большую фичу — она уезжает на следующий спринт.
Последний день спринта отдается под одно сплошное тестирование: функциональное, интеграционное, нагрузочное — все что у вас есть.
Почему 2.5 недели а не просто две?
Дело в том что в случае чистых двух недель, релиз будет попадать на пятницу либо понедельник — плохие дни для такой задачи:
поставили новую сборку в пятницу вечером, в понедельник пользователи вышли на работу — а тут ничего не работает. Знакомо?
Вот чтобы не попадать постоянно на пятничные релизы — спринт и делается в 2.5 недели, чтобы выставить новую сборку посередине рабочей недели, получив и время для маневра (отката изменений) и спокойный фидбек от пользователей.
To be continued..
В следующей части расскажу про репозитории и версии. Вторая часть тут.