Создание стартап-вебприложений с помощью Scrum: пошаговое руководство, вдохновлённое проектом Ratifire

«Scrum?! Scrum?! Что это за странное слово?» Это было в моей голове, как только я начал знакомиться с этим понятием. Понимание управления проектом было, но именно то, что вы используете конкретные элементы и принципы Scrum —нет, поэтому мы решили исправить это и написать статью, которая поможет начинающему погрузиться в этот мир и не заблудиться в проекте, особенно в первой работе. Итак, начнём.

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

Scrum — это довольно популярный фреймворк/схема (Планируй, Делай, Проверяй и Действуй) для управления проектами, которая повышают эффективность команды. Она широко используется в области разработки программного обеспечения. Она предлагает интерактивный итеративный подход к созданию продуктов, который позволяет командам быть более гибкими и адаптироваться к переменным требованиям.

О компонентах Scrum поговорим во втором разделе, а сейчас сосредоточимся на вопросе «Каковы преимущества Scrum в startup проектах и не только?»:

• гибкость: Scrum позволяет быстро адаптироваться к изменениям рынка и требованиям клиентов;
• скорость: регулярныеспринты обеспечивают быстрое получение результатов и вывод продукта на рынок;
• фокус на ценности: Scrum помогает командам сосредоточиться на создании наиболее ценных функций для пользователей. Все участники видят и чувствуют свое влияние на процесс и разработку продукта.

Но Scrum — не единственное, что нужно понять. Существуют также понятия Agile, Kanban и т. д. Поэтому держите краткое описание этих терминологий, которые будете постоянно слышать при разработке программного обеспечения.

• Agile — это зонтиковый термин (an umbrella term — англ., охватывает связанные научные направления, которые имеют общий объект исследования), который сочетает в себе методы, которые подчёркивают гибкость и сотрудничество. Основное различие между Scrum & Agile заключается в том, что Agile — это общая концепция, а Scrum— это конкретный фреймворк с чётко определёнными правилами. Если это очень просто объяснить, то Agile — это рецепт приготовления пищи, а Scrum — это рецепт для конкретного торта.
• Kanban — это концепция управления проектом из семейства Agile. Он фокусируется на постоянном потоке работы, визуализации задач и их безприрывном улучшении. Это более гибкий принцип, который позволяет легко адаптироваться к изменениям. Другими словами, Kanban — это постоянный поток и гибкость, а Scrum — это итерации и структура.

ПОШАГОВОЕ РУКОВОДСТВО ПО СОЗДАНИЮ ВЕБ-ПРИЛОЖЕНИЯ RATIFIRE С ПОМОЩЬЮ SCRUM

Чтобы глубже раскрыть тему Scrum, рассмотрим практический пример. Я работаю как Front-End Developer на проекте Skillzzy — платформой, которая помогает разработчикам готовиться к техническим собеседованиям посредством поддержки опытных специалистов и сообщества.

Наш проект охватывает весь спектр Scrum-практик: от формирования команд до проведения ретроспектив. Ввиду формата статьи мы не будем рассматривать все нюансы, а сосредоточимся на основных идеях.

Команды и роли в команде, их ответственности и взаимодействие

Skillzzy имеет хорошо структурированную команду, распредёленную по технологическим стекам: front-end, back-end, QA, design и DevOps. Каждая из этих команд имеет свои Team & Tech Leads и Product Owner, что обеспечивает чеёткое распределение ответственности и эффективное управление.

Основные роли в Scrum

Product Owner:

• Определение ценности и видения продукта.
• Формирует и управляет Product Backlog (беклогом продукта) — списком всех функциональностей, которые необходимо реализовать в продукте.
• Принимает решение о приоритетности реализации функционала и устанавливает сроки их выполнения.

Team & Tech Leads:

• Элиминируют препятствия, мешающие команде эффективно работать.
• Фасилитируют все Scrum-церемонии (планирование спринта, ежедневные митинги, ретроспективы).
• Помогают команде развиваться и усовершенствоваться.

Development Team:

• Выполненяет всю работу по созданию продукта.
• Самоорганизующаяся и самоуправляемая.
• Определяет, как лучше выполнить задание спринта.
• Несёт ответственность за создание инкремента (работающей версии продукта) в конце каждого спринта.

Каждая команда состоит из 6 (max 9) team members. И данный аспект очень важен для Scrum, потому что это оптимальное число для эффективной работы и коммуникации. В противном случае увеличение команд от +9 приводит к понижению производительности до 45%.

Артефакты в Scrum: фундамент успешного проекта

В Scrum артефакты — это не просто модные термины. Это конкретные инструменты, которые помогают команде держать курс, понимать, где мы есть, что делаем и зачем.

Вот три ключевых артефакта, с которыми мы ежедневно работаем в Skillzzy:

1. Product Backlog — сердце продукта:

• Это список всего, что продукт может и должен производить. Мечты и планы, ещё не ставшие кодом.
• Борда, помогающая визуализировать задачи. У нас используется GitHub Boards. Також можна зустріти Jira, Trello, Asana, JetBrains, etc. Выбирать есть из чего, всё зависит от того, какой бюджет команды и какая функциональность борды нужна — суть не в инструменте, а в принципе: все задачи видят все.
• Задания сортируются по приоритетам и статусам:

Backlog → Bugs → ToDo → In Progress → Blocked → On Review → Ready for Testing → Done

Это не просто список задач — это «живая» борда, работающая вместе с командой. Каждый видит, на каком этапе любая задача, и может быстро вмешаться, если что-то горит.

2. Sprint Backlog — наша «порция пиццы»

• Это определённый процент Product Backlog. Скажем Product Backlog — это пицца, а Sprint Backlog — это её один кусочек.
• Простыми словами это пул задач, которые команда определила на конкретный спринт и старается закрыть. Именно так, это определ'нного рода agreement команды и менеджера, не навязанное мнение сверху, а decision команды.

Это набор задач, которые команда сознательно выбирает на следующий спринт. Никто не навязывает сверху — это общее решение.

Конечно, при условии, что каждый член команды погружён в процесс. Если мы как разработчики не можем закрыть конкретную задачу за спринт, то смотрим на причины «Почему так случилось?». Возможно задача большая для спринта в общем и стоит её разбить на подзадачи или есть какие-то блокеры, которые стоит решить.

3. Increment (Инкремент)

• Это работающая версия продукта, создаваемая в конце каждого спринта.
• Инкремент демонстрирует прогресс команды и является результатом выполнения задач по Sprint Backlog.
• Проект должен быть готов к демонстрации: стабильным, протестированным, реальным.
• Если инкремента нет — спринт нельзя считать завершенным. Просто «писать код» — это не Scrum.

СПРИНТЫ: ПЛАНИРОВАНИЕ, ЕЖЕДНЕВНЫЕ ВСТРЕЧИ, ДЕМОНСТРАЦИЯ РЕЗУЛЬТАТОВ

Спринт — это довольно короткий итеративный промежуток времени (обычно от 1 до 4 недель), если сравнить с общим временем реализации продукта/программного обеспечения, за которое команда работает над реализацией определённого набора функциональных возможностей продукта.

На проекте Skillzzy он особенно важен, потому что:

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

Ключевые этапы спринта:

Планирование спринтов у нас — это всегда увлекательный процесс, требующий от всей команды погружения в детали. Один из ключевых моментов — оценка сложности задач. Для этого мы используем Scrum Poker, хоть и в онлайн-формате.

Как это работает?

1. Выбор задач: в начале спринта мы выбираем задачи из беклога, которые планируем выполнить.
2. Оценка по шкале Фибоначчи: каждый член команды оценивает сложность задания с помощью чисел Фибоначчи (1, 2, 3, 5, 8, 13). Это помогает нам быстро сориентироваться и понять, насколько задача сложна.
3. Обсуждение разногласий: если оценки сильно расходятся, мы подробно обсуждаем задачи. Каждый объясняет свою точку зрения, учитывая технические аспекты, зависимость от других задач, а также внешние факторы (например, изменения в дизайне).
4. Повторная оценка: после обсуждения мы повторно оцениваем задачи. Как правило, после обмена мнениями оценки сближаются.
5. Принятие решения: задача включается в спринт с согласованной оценкой.

Почему мы не используем человеко-часы?

Использование абстрактных единиц (сторипоинтов, размеров футболок) позволяет нам:

• сохранить фокус на сложности: мы оцениваем не время, а объём работы и её сложность;
• избежать давления: отказ от часов позволяет разработчикам сосредоточиться на творческом решении задач, а не на часах;
• стимулировать командную работу: обсуждение оценок способствует лучшему пониманию задач и укрепляет команду.

ПРИМЕР ИЗ ЖИЗНИ

Оценивая задачи на создание нового шаблона, мы получили разные оценки: от 1 до 13. После обсуждения выяснилось, что разработчики, давшие низкую оценку, уже имели схожий опыт, а давший высокую учёл необходимость согласования с дизайнерами. В результате мы приняли компромиссную оценку, учитывающую как техническую сложность, так и необходимость дополнительной коммуникации.

1. Разработка. Получив свою задачку, каждый член команды погружается в работу. Мы ведь понимаем, что успех проекта зависит от каждого. Если возникают сомнения в правильном решении, всегда можно провести дополнительное исследование или обратиться за помощью к опытным коллегам. Открытая коммуникация — наш ключ к успеху. Поэтому любые проблемы или задержки обсуждаются сразу, во время ежедневных митингов или в общем чате.
2. Ежедневные митинги. Это наши короткие, но эффективные встречи, где мы обмениваемся информацией о прогрессе работы. Каждый участник коротко рассказывает, что удалось сделать, над чем работает сейчас и есть ли какие-то препятствия. Такой формат позволяет быстро реагировать на изменения и поддерживать общий темп работы. В общей сложности должно длиться 15 мин. Если есть конкретные топики для обсуждения, выносится как отдельный call.
3. Демонстрация: в Skillzzy мы проводим еженедельные демонстрации, отходя от классического Scrum. Это позволяет нам получать быструю обратную связь и оперативно адаптировать разработку под изменяющиеся потребности стартапа.
4. Ретроспектива: после каждого спринта мы проводим ретроспективу, чтобы глубоко погрузиться в результаты нашей работы. Вместе с Tech & Team Lead-ами мы анализируем, что помогло нам добиться успеха, а над чем ещё предстоит работать. Это не просто подведение итогов, а скорее общая рефлексия, помогающая нам развиваться как команде фронтов.

ТИПИЧНЫЕ ПРОБЛЕМЫ ПРИ ПРИМЕНЕНИИ SCRUM

Как команда Front-end разработчиков в Skillzzy, мы столкнулись с несколькими типичными проблемами при внедрении Scrum:

• Несоблюдение принципов Scrum. Особенно это касалось молодых специалистов, ранее не работавших по этой методологии. Творческий характер разработчиков также влиял на соблюдение жёстких правил, таких как ежедневные митинги.
• Проблемы с коммуникацией. Сложности возникали при взаимодействии с другими командами, например, дизайнерами. Каждая команда стремилась отстаивать свою точку зрения, что усложняло процесс принятия решений.
• Изменение требований. Как и во многих других проектах, мы сталкивались с ситуацией, когда product owner мог предложить другое решение уже во время спринта.

Как мы разрешили эти проблемы:

• Накопление опыта: со временем команда приобрела опыт работы с Scrum, что позволяет лучше понять его принципы и преимущества.
• Менторство: опытный Tech&Team Lead помог команде освоить Scrum и соблюдать установленные правила.
• Ужесточение коммуникации: мы четко определили ответственных за принятие технических решений и наладили эффективную коммуникацию между командами.
• Адаптация к изменениям: мы научились быстро адаптироваться к изменениям требований, включая их в следующий спринт.

РЕЗУЛЬТАТЫ, КОТОРЫЕ БЫЛИ ДОСТИЖЕНЫ НА ПРОЕКТЕ SKILLZZY

1. Рост продуктивности. Проект стартовал в январе 2024 года. До июня 2024 года были частичные применения Scrum, я бы сказала неудачные и на момент этого времени были разработаны не целые две страницы со многими багами. С июля 2024 года с применением Scrum продуктивность front команды выросла и increment на данных период составляет 5 страниц https://skillzzy.com, рефакторинг модалок + чат на WebSocket + полноценный landing https://ratifire.org/. Сравнивая с чего мы стартовали, то по моим скупым оценкам продуктивность выросла до 500%.
2. Презентация платформы Skillzzy на Web Summit 2024 в Лиссабоне. Продукт был представлен большой IT-community. В результате которого мы получили много положительных отзывов и главное — feedback для улучшения платформы и внедрения инновационных решений.
3. Будущая коллаборация с современными и передовыми украинскими IT School такими как Hillel. Сейчас проходят переговоры по условиям сотрудничества.
4. Подача заявки на Премия DOU 2024. Ищем проекты, инициативы, людей, которые влияют на украинское IT-сообщество.

Scrum стал нашим компасом в мире разработки. Это не просто инструмент, это философия. Она научила нас, что успех — это не конечная точка, а постоянный процесс усовершенствования. Каждый спринт — это новый шаг к улучшению и чему-то новому. Мы с нетерпением ждём, чего ещё можем добиться. В некотой мере Scrum помогает поймать счастье в ежедневной суматохе задач, оглянуться и ответить на вопрос «Что сделал? Куда я двигаюсь и что буду делать? Есть ли какие блокеры?». Попробуй и ты!