Методологию SCRUM впервые описали Хиротака Такэути и Икудзиро Нонака. Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби».
Настоятельно рекомендую к прочтению книгу, которая является в нашей команде библией любого проекта - «Scrum. Революционный метод управления проектами» автора Джеффа Сазерленда. Благодаря этой книге Magneex добился грандиозных результатов в области разработки проектов.
Взять методологию полностью и использовать все существующие артефакты и ритуалы SCRUM мы не стали, но, как всегда, многое адаптировали под особенности нашего бизнеса.
В этой статье я планирую рассказать вам, что и как мы применяем в нашей компании, а заодно расскажу о внутренних процессах того, как творится магия разработки digital-проектов у нас.
Итак, техническое задание написано и согласовано, до этого момента ни о каких гибких методологиях речь не шла, была каскадная модель выполнения работы с четко сформированной последовательностью действий проект-менеджера.
После прочтения техническим директором задания на разработку, он составляет так называемый Product Backlog. По сути, это те самые модули, которые необходимо разработать в рамках проекта, описанные в смете. Затем собирается команда разработчиков проекта и производит неформальную оценку каждой из задач (Story points) проекта. В нашей компании мы используем механику Planing Pocker. Веса задач определены и проставлены, далее проект-менеджер связывается с владельцем продукта, в 95% случаев владельцем продукта является непосредственно заказчик, наш клиент. Совместно определяются наиболее приоритетные модули проекта, которые необходимо реализовать в первую очередь. Этот процесс называется Sprint Planning Meeting.
Чем быстрее продукт появится в свет и на него станет попадать целевая аудитория, тем быстрее он начнет окупать стоимость его разработки. Идеальный сайт – это лучезарная звезда, к которой мы можем только стремиться, постоянно улучшая и дорабатывая продукт, но совершенно недостижимая в столь стремительно изменяющемся мире. Поэтому не стоит бояться выпускать «сырой продукт». Невыпуск продукта или затягивание его релиза могут нанести непоправимый ущерб бизнесу и вашим нервным клеткам!
Эмпирически мы вычислили мощность нашей команды и сколько Story Pointов мы можем закрыть в рамках спринта. У нас спринт — это всегда одна неделя, чем короче спринт, тем более точную оценку трудозатрат мы можем провести, плюс частые встречи с клиентом и демонстрация работ никогда никому не вредили. Составляем и подписываем Sprint Backlog. По сути, это перечень задач, которые мы обязуемся реализовать в рамках спринта. Предварительно с клиентом оговаривается, каким образом мы будем демонстрировать результат нашей работы. В процессе работы программистов бывает так, что мы можем проектировать целый спринт сложную базу данных. И, по факту, это таблицы MySQL, которые показать клиенту очень сложно. Но и в этом случае проект-менеджеры выкручиваются и рисуют замечательные диаграммы связей таблиц базы данных для демонстрации, которые в последующем используются программистами для освежения памяти того, что было сделано.
Важно понимать, что после согласования Sprint Backlog никакие изменения не вносятся, т.к. это непременно повлияет на результат работы и в 9 случаях из 10 приведет к завалу спринта.
После всех предварительных работ спринт начинается. У нас началом каждого спринта является пятница, т.к. многие разработчики любят работать в выходные, а последний день перед планированием четверг.
Каждый день в 10:00 по местному времени собираются все проект-менеджеры с своими SCRUM-командами для контроля работы. Этот ритуал называется Daily meeting или Ежедневное планирование. Каждый участник SCRUM-команды встает и отвечает на 3 главных вопроса перед всей командой:
- что я сделал вчера?
- что я буду делать сегодня?
- есть ли какие-то проблемы?
В случае возникновения проблем проект-менеджер обязан в ближайшие сроки устранить их для того, чтобы ничто не отвлекало разработчика от выполнения его прямых обязательств в команде. Данная методика позволяет максимально быстро реагировать на нештатные ситуации и заниматься внутренним перераспределением ресурсов, если это необходимо для соблюдения качества и сроков работ.
По завершению спринта проект-менеджер связывается с владельцем продукта, демонстрирует недельный результат работы команды и формирует Sprint Backlog следующего спринта. В момент таких встреч заказчик в праве вносить изменения в Product backlog и изменять суть проекта так, как ему захочется, либо так, как требует того рынок, сложившиеся новые обстоятельства и т. д. Зачастую, в случае существенных изменений сайт перестает быть тем, что изначально описан в техническом задании, что ведет к пересмотру стоимости проекта в большую или меньшую сторону.
Так может повторяться неограниченное количество раз до тех пор, пока заказчик не захочет остановить разработку, либо Product Backlog будет полностью исчерпан. Многие наши проекты были начаты 3-5 лет назад и продолжают совершенствоваться и по сегодняшний день. Одни из проектов являются непрерывными, и спринты идут один за другим, другие имеют разрывы в исполнении в месяц или более, возможна любая схема работы благодаря гибкости методологии.
Выводы:
- при использование гибких методологий разработки изменения в проект вносятся максимально быстро;
- нет необходимости формирования долгих планов реализации проекта, которые зачастую бывают обманчивыми из-за невозможности учесть всего на ранних этапах;
- тесное сотрудничество с заказчиком через равные промежутки времени, что позволяет нам выпускать максимально эффективные проекты, соответствующие ожиданиям обоих сторон;
- соблюдение сроков исполнения проекта на коротких промежутках (спринтах).
Таким образом творится внутренняя разработка проектов в Magneex. Если вам хочется узнать о магии больше, обязательно свяжитесь с нами через форму ниже.