Как мы дошли до Scrum

Перед тем как внедрить Скрам, мы работали по обычной методологии разработки (каскадная модель). Что это значит? Это работа по готовому ТЗ, где результат виден только в конце всех этапов разработки, заказчик принимает косвенное участие в проекте.

К чему это привело? В процессе разработки заказчик вносил поправки, которые не учитывались при расчете сроков. Задачи перекрывали друг друга, их количество увеличивалось, и разработчики не выделяли главное и второстепенное, так как все нерешенные задачи были срочными.

Минусы работы по обычной модели

Минусы для команды разработчиков

Прикладывая больше усилий, количество работы не уменьшалось, а даже увеличивалось. Мотивации и желания закончить проект у команды было все меньше. Ценное время разработчики тратили на выполнение второстепенных задач.

Минусы для заказчика

Заказчику важно качественное выполнение работы и соблюдение сроков. Исходя из принципов обычной методологии, заказчик не является участником процесса разработки. Клиент видит результат только в конце, когда внесение изменений становится еще одним этапом, а следовательно занимает дополнительное время.

Такая работа нас не устраивала, и мы решили — настало время перемен. Так мы внедрили Scrum.

Плюсы разработки по Скрам

• поэтапный запуск проекта 
• выполнение работы в более короткий срок
• тестирование функционала на каждом этапе
• прямое участие заказчика в процессе 
• изменение функционала в ходе разработки

Как мы внедрили Scrum

Внедрить Scrum за один день и получать результат невозможно. Это работа всей команды далеко не одной недели.
Для начала, мы объявили команде о внедрении такой методологии. Разбили команду на группы по 2 - 3 чел., выделили три основные роли (скрам-мастер, владелец продукта, команда) и назначили исполнителей.

Подробнее о ролях:

Скрам-мастер — истинный мотиватор команды, такой же ее участник, наделен дополнительным функционалом, направленным на повышение эффективности работы.

В задачи скрам-мастера входит:

• координация групп
• поддержание общей атмосферы в команде
• проведение скрам - митингов
• планирование и запуск задач
• мониторинг социальных аспектов команды, поддержание духа

Владелец продукта — член команды, ответственный за расстановку приоритетов среди задач.
Команда (в идеале +/- 7 чел.) — исполнители требований владельца продукта.

С момента перехода на гибкие методологии разработки, мы составили новый план взаимодействия с клиентом. Процесс основан на постоянном общении. После выполнения определенного ряда задач, мы демонстрируем отчет о проделанной работе. Оговариваем, что планируем сделать и какие технологии собираемся применять. Это дает нам возможность изменять и добавлять новый функционал, который будет полезен и сохранит ценное время.

Диалог с заказчиком

Конечно, лучший способ обсуждения проекта — личная встреча с клиентом. Личный контакт помогает лучше понять пожелания и ответить на интересующие вопросы. Мы готовим отчет - диаграмму выполненных задач, на которой видно сколько времени заняла у нас каждая задача, плюс демонстрируем проделанную работу.

Поэтапный запуск сайта (использование гибких методологий разработки) дает заказчику:

• готовый функционал каждые несколько недель и заработок на нем
• обновление сайта согласно изменениям в бизнесе
• регулируемые сроки и стоимость проекта, так как есть возможность остановить процесс разработки на любом этапе

Как выстроить диалог с заказчиком

Развитие взаимодействия можно и нужно начать с еженедельных встреч для обсуждения проекта. В этом заинтересованы и заказчик, и исполнители. Во-первых, работа над проектом предсказуема, во - вторых, выстраиваются доверительные отношения, и в-третьих, объем нецелесообразных задач сокращается.
Позже, можно приглашать заказчика на ретроспективы (одна из практик scrum, проходит в формате собрания, основана на командном подведении итогов проделанной работы), это позволит ускорять процесс и держать команду в тонусе.

В целом, внедрение Scrum помогло нам оптимизировать рабочий процесс, повысить тонус команды и эффективно работать над проектами.