Конкуренция в IT-сфере требует оперативности и эффективности. Клиенты хотят получить оптимальные решения за короткий срок. Как организовать команду разработчиков, чтобы уровень производительности и мотивации зашкаливал, а сроки соблюдались?
Попробуйте гибкую методологию управления проектом SCRUM.
SCRUM делает коммуникацию в команде эффективной, мотивирует разработчиков и все участники процесса качественно взаимодействуют между собой. Кроме того методология позволяет оперативно решать проблемы, которые появляются «по ходу дела». Это повышает качество финального продукта.
Конкуренция в IT-сфере требует оперативности и эффективности. Клиенты хотят получить оптимальные решения за короткий срок. Как организовать команду разработчиков, чтобы уровень производительности и мотивации зашкаливал, а сроки соблюдались?
Scrum для вас, если...
Больше всего методология подходит для проектов, требующих кастомных технических решений (мобильные приложения, крупные веб-ресурсы). А команда должна быть самоорганизующейся и многофункциональной.
Продукт разрабатывается по SCRUM небольшими итерациями — спринтами. И в этой системе есть роли, которые помогают бежать спринт максимально эффективно.
Кто это: PO, SM DT?
Product owner (PO) — человек, который разбирается в бизнес-логике продукта. Как правило, это представитель клиента. PO видит конечную цель, как, например, мобильное приложение будет работать у пользователей. Он общается с ЛПР и доносит информацию команде разработки.
Именно PO формирует список задач для команды и проекта (Product Backlog). Все задачи выставлены по приоритетам, которым следует команда.
Scrum master (SM) — это лидер команды и фасилитатор. Он занимается мотивацией, максимизирует эффективность команды, работает над устранением препятствий, помогает разработчикам. Перед каждый новым спринтом SM формирует Sprint Backlog на основе Product Backlog. Проще говоря лидер команды разбивает задачи от PO на более мелкие, которые в конечном итоге приведут к результату.
Команда разработки (Development team, DT) состоит из специалистов, которые работают над продуктом.
Ключевые моменты для DT:
- Разработчики свободны в принятии технологических решений. Команда самостоятельно решает, как именно она выполняет задачи от PO и SM.
- Вся команда отвечает за выполнение задач, а не индивидуальный разработчик.
- Оптимальное количество людей в команде — плюс-минус 6 человек. Больше — разрыв в коммуникации, меньше — увеличение объема работы на одного человека.
- Команда самоорганизующаяся и взаимозаменяема.
Sprint — как это работает?
Как только с ролями определились, начинаются спринты. Sprint — короткий забег, ограниченный временем и списком задач для команды. Обычно спринт длится от 1 недели до месяца, во многом это зависит от сложности проекта. Пока команда доберется из точки A до конечной версии продукта B, пройдет несколько спринтов, а то и десятки.
Зачем это? Разве нельзя сразу четко сформировать финальное видение продукта?
В этом и есть главное достоинство SCRUM — каждый день команда встречается на “Daily” со скрам-мастером. Все разработчики обмениваются информацией о том, как идет работа, что сделал лично каждый человек, что он сделает завтра.
Такие встречи служат отличной мотивацией, способствуют развитию командного духа, позволяют мгновенно решать проблемы.
В завершении спринта все встречаются на "demo" и представляют результат работы.
В конце спринта команда встречается на Ретроспективе. Там обсуждаются и генерируются новые решения, анализируются успехи и неудачи. Главное — уйти с набором решений, а также пониманием, что можно улучшить.
А с "понедельника" начинается новый спринт, с новым пакетом задач. Это позволяет постоянно апдейтить финальный продукт. Плюс Scrum дает нам потенциально рабочий продукт в конце каждого Sprint'а.
Важный момент: Sprint Backlog нельзя дополнять новыми задачами до конца спринта. Это дает четкий фокус команде и устраняет возможность “навешивать” задания в течение двух недель. Каждый разработчик четко видит свою задачу и работает над ней, самоорганизуясь.
Как оценивать эффективность?
Итак, у нас есть Product Backlog — задачи, которые нужно выполнить, а PO имеет финальное видение продукта. Что еще нужно, чтобы понять, что разработчики сделали все правильно?
Чтобы убедиться, что все сделано хорошо, аналитики в команде пишут тесты по каждой задаче. В них подробно описано, какой результат должен получиться. Проще говоря, в них описано на какую кнопку нажать, и что при этом получится.
Отдельные тесты пишутся на конец каждого спринта, очень подробно, чтобы оценивать эффективность за две недели.
Преимущества методологии
Scrum ориентирован на клиента. В день завершения очередного спринта вы можете пригласить заказчиков, показать результаты работы, а клиент обновить свои требования. Дать возможность заказчику почувствовать себя частью процесса разработки — отличное конкурентное преимущество.
Интересности — Покер-планирование
В процессе планирования спринта нужно оценить задачи и выделить на них время. Оно исчисляется в StoryPoint'ах. Фактически это оценка сложности задачи.
В крупных IT-компаниях широко распространен опыт покер-планирования.
У каждого члена команды есть колода карт. Каждая карта имеет свой номинал - это по сути и есть StoryPoint'ы. И после обсуждения какой-либо задачи, все "игроки" выкладывают 1 карту, которая по его мнению отражает сложность выполнения.
Затем игроки, которые выложили максимальную и минимальную "ставку" аргументируют свой выбор. После этого обсуждения процедура повторяется до тех пор, пока мнения не сойдутся. Боитесь серьезных затрат времени? В "игре" есть строгий регламент.
Если детально и четко придерживаться идеологии Scrum, команда будет максимально мотивирована (ежедневные митинги с отчетами о процессе выполнения), все члены команды будут видеть прогресс и конечную точку (визию) продукта. Проблем с коммуникацией не будет, а все дедлайны будут соблюдаться.
Для большего погружения в SCRUM рекомендуем прочесть книгу «SCRUM . Революционный метод управления проектами» Джеффа Сазерленда.
