Скрумы, Агили или еще что у вас, это неважно, если вы работаете циклами / итерациями / спринтами, то вам может быть полезно.
Звонок для учителя, а итерация для заказчика и команды
Вы должны помнить, что итерации нужны не только для «контроля процесса разработки», но и для людей, а именно заказчика и команды: в конце каждой итерации приглашайте на отдельную встречу всю команду и заказчика.
Это называется All-hands meeting.
Во время этой встречи вы расскажите об успехах и планах на новую итерацию, зададите критические вопросы, дадите возможность задать вопросы заказчику и просто посмеетесь.
Когда команда узнает заказчика, как человека, она проникается к нему симпатией и начинает понимать, что «данный проект принесет вот этому конкретному человеку пользу» и эта мысль сильно мотивирует работать.
А Заказчику становиться спокойнее, поскольку он понимает, что его проект делают люди, которых он хоть немного, но знает, а значит может доверять кому-то конкретному, а не «отделу разработки».
50 оттенков тасков
Обязательно различайте и фиксируйте все типы новых задач:
- Новый важный функционал (50-80%)
- Новый неважный функционал (20-50%)
- Правками ошибок (10%) (непредвиденные ошибки, потенциальная регрессия)
- «Чистка» существующего функционала (0-15%) (технический рефакторинг)
- Переделка того, что уже было сделано (0-10%) (бизнес-рефакторинг, регрессия)
- Переход задач из предыдущей итерации в новую (0%)
Прям создайте специальные флажки/тэги/пометки с такими названиями и добавляйте их к задачам.
Дальше следите за процентами в спринтах:
Новый критичный функционал (50-80%) — именно этот функционал двигает продукт и его доля в проекте должна быть наибольшей
Новый некритичный функционал (20-50%) — если этих задач много, значит, вы или успешно справляетесь и критического функционала не остается, или ваш продуктолог глупенький и не умеет приоритезировать фичи. Перепроверяйте себя, когда количество подобного функционала перевешивает в спринте «новый критичный функционал».
Правки ошибок (10%) — важно понимать, является ли это «случайностью» или даже заведомо известным местом. Если эта ошибка могла быть спрогнозирована или вызвана конкретными ошибками конкретного разработчика, то ставьте счетчик таких ошибок у этого человека. Когда в одной итерации счетчик перевалил за 3 ошибки, то пора вмешаться.
«Чистка» существующего функционала (0-15%) — рефакторинга быть не должно, но он бывает. Часто так бывает, что принцип «работает не трожь» жизненно необходим для проекта. Выделите красного архитектора, который будет следить за балансом «говнокода» и «почти-говнокода». Такой архитектор будет аналогом red team отдела ЦРУ, который проверяет все решения на уязвимости — доверяйте такому человеку всецело, когда он говорит на какую из качелей можно подкинуть новый код.
Переделка того, что уже было сделано (0-10%) — тут вопрос: «Вы переделываете, потому что сделано плохо/не так, как просили»? Ставите счетчик факапов на разработчика + на того, кто выставляет задачу и следите.
Попадает из предыдущей итерации в новую (0%) — самая частая вещь, но ее процент нужно понижать до самого минимума, поскольку несоблюдение именно этого правила полностью рушит смысл итеративной разработки.
Алгоритм формирования задач и вероятности проёба
Не понимаете команда перегружена или недогружена? Попробуйте посчитать время:
Берете срок спринта, например, 2 недели = 10 рабочих дней. Умножаете на 8 часовой рабочий день = 80 часов на человека. Умножаете на количество людей, например 10 = 800 часов. Поздравляю, ваш пул времени = 800 часов.
Далее показываете задачи, чтобы команда их себе набрала и просите каждого отдельного разработчика оценить их и считаете полученное количество часов. Например 640 часов.
Значит, 800 — 640 = 160 часов – это ваш страховой бюджет на ошибки при просчете времени + на неожиданные ситуации.
По итогу спринта посмотрите насколько удалось израсходовать это время и не при этом не перерасходовать нервы.
Если же при расчете получиться 1200 часов, то есть огромный шанс, что вы или не успеете, или ебнетесь в процессе.
В общем, такой просчет просто один из удобных инструментов прогнозирования ситуации.
Как передавать задачи
О хорошем способом передачи задач рассказывает Федор Борщев – техника «пуш» и «пулл» (читать обязательно)
«Пуш» – это когда вы впихиваете задачи в исполнителей, даже если не впихуется.
«Пулл» – это когда вы показываете задачи спринта и исполнители сами выбирают какие будут делать.
Как бить по часам
При оценке задачи советую использовать количество часов 1, 2, 4, 8, 16, 24 — все что выше стоит бить на более маленькие задачи, чтобы они помещались в эти временные отрезки.
Всегда нужен свободный карман
В идеале, при пуле времени на 800 часов, нужно оставить 20% (160 ч.) на ту «критику» которая появится в процессе спринта (например, супер критическая ошибка на проде из-за ошибки провайдера), 10% (80 ч.) времени на то, что неправильно оценил даже тимлид и остальные 70% уже на задачи (560 ч.)
Все еще проблемы?
Так и не получилось у вашей команды въехать в Скрумы и Агили? Тогда напишите мне, попробую помочь настроить ваши процесс.
Немного про меня
Последние 6 лет я занимаюсь запуском, развитием и сопровождением IT-проектов. Работаю быстро, честно, открыто. Нахожу уникальные решения под каждый отдельный кейс.
А еще я пишу о своем опыте в Телеграме. Опасайтесь подделки: я никогда не напишу целую статью хотя бы без одной грамматической ошибки и слова «хуй», потому что это будет противоречить моему бренду («чистый код, грязное письмо»).
Давид Шекунц — outsource технический директор с расширенным функционалом.
Интересно поработать вместе? Пишите
