Scrum для двоих по удаленке
Традиционный Scrum - это командная работа, Product Owner, Scrum Master, команда - в общем, толпа народу. Эта радость доступна достаточно большим студиям, ведь средняя скрам-команда из 5 человек будет кушать около 500т.р./мес. и далеко не каждый проект расчитан на такой бюджет.
А что делать маленькой студии, когда мы начинаем потихоньку набирать свою команду на фул-тайм? (а быстро хорошая команда не набирается, хоть тресни!)
В работе обычно оказывается несколько направлений разработки и на каждый нужен свой исполнитель, потому что два одновременных проекта на одного разработчика (бич всех фрилансеров) не приводит ни к чему, кроме падения производительности и провала сроков.
При этом, у хозяина такой конторки голова все равно, вероятно, расколется, потому что он уже не разработчик и ему-то как раз надо вести все направления сразу. А чтобы этого не произошло - самое время взять Agile и приложить к нему голову. Вот что при этом получается:
Роли
Не будем мудрствовать: у нас на один проект всего два персонажа - это:
- шеф, который и заказчика находит, и ТЗ внятно пишет, и деятельность планирует
- разработчик, 1 человек
Как здесь не крути, а и "Владельцем продукта" и "Скрам-мастером" (и за одно Тимлидом) быть шефу.
Бэклог
Поэтому, наобщавшись с заказчиком, смиренно берем ТЗ и начинаем его дробить на истории, как мы их видим. Список этих историй - и есть наш бэклог.
Можно все делать и на бумажке, но мы используем scrum plugin для Redmine. Это удобно и, к тому же, позволяет работать по удаленке.
Кстати, об удаленке: если у вас разработчик на удаленке, что противоречит всякому классическому скраму - смиритесь и адаптируйтесь, в конце концов, телепортацию только начинают изобретать, а проекты надо делать прямо сегодня.
Так вот, бэклог: расписали ТЗ на истории и рассортировали по приоритету выполнения. Дальше прикинули для себя - как эти истоии кодить, и какие задачи при этом надо будет решать - прикинули и записали в описание этих историй.
Торжественный момент - все готово к планированию!
Планнинг по спринту проводим либо лично, либо голосом в скайпе. Чатиться неэффективно, как бы наша аутичная натура к этому не стремилась.
Если в живую - открываем спринт на компе и обсуждаем. Если по удаленке - то каждый открывает на своем компе и обсуждаем.
Берем истории по приоритету одна за другой, смотрим описание, смотрим пометки по разбивке на задачи, обсуждаем.
Заканчиваем обсуждение истории оценкой времени выполнения. Хитрость в том, что эту оценку не сделать, если непонятен состав задачи - и в этот момент вся неосказанность и недодуманность всплывает и устраняется.
Конечная цель обсуждения истории - выявить все ее подзадачи и на каждую навесить оценку времени.
Как оценивать?
Если в живую, то не поленитесь и распечатайте пару колод planning poker - с ним веселее. Вроде как не работаешь, а маешься дурью, а дело движется :)
Если по удаленке - не усложняйте, технология прозрачна, как утренняя роса: дайте себе оценку задачи, но не произносите ее, после этого потребуйте чтобы разработчик дал оценку вслух. Затем сверяйтесь и приходите к консенсусу.
Переходим к следующей задаче и далее, по списку, пока не надоест (правда осмечивать больше чем на спринт пользы нет).
Когда истории на спринт набраны, отпускаем разработчика кодить, а сами тратим немного времени, чтобы создать задачи к историям и вписать оценки времени.
Сприиинт - сприинт - спринт!
Дальше неделю все просто:
Каждое утро (ну или не совсем утро) требуем от нашего разработчика трех простых действий до начала сеанса связи:
1. Перетащить все задачи, которые в работе - в колонку "В работе", завершенные задачи - в колонку "Тестирование" (обычно задачи перетаскиваются прямо по ходу работы, так что начало брифинга - это просто контрольная точка, чтобы все подчистить).
2. Отметить время, потраченное на задачи.
3. Исправить время, необходимое для завершения каждой задачи.
Далее, лично, или просто в чате, спрашиваем:
Есть ли какие-то вопросы или проблемы?
Если это по удаленке - то голосом обсуждаем по необходимости.
И так каждый день до конца спринта.
По ходу дела пыримся в Burndown диаграмму - при хорошем темпе она как мед на сердце, при плохом - сразу видна проблема.
Вот примерно такая премудрость.
Главное в ней - здоровая педантичность и рациональность.
Если вы педантичны, то и разработчик, даже не знакомый с методой и изначально ее не очень принимающий, привыкает и настраивается на ваш ритм.
Если вы рациональны, то возьмете из методики то, что вам действительно удобно и без сожаления избавитесь от утомительного соблюдения красиво описанных в книжке процессов, смысл которых вам в моменте не до конца понятен.
А результат - свежая голова, в которой не надо держать все то, что можно посмотреть на scrum board и возможность осваивать новые гризонты.