Каков приоритет стартапа? Убедительная подача? Уникальный дизайн приложения и UX? Чистый код? Своевременный ответ на отзывы пользователей?

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

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

Что такое Scrum? Зачем это использовать? Где и как Scrum помогает стартапам обеспечивать согласованный рабочий процесс между стартапом и его внешней командой разработчиков? И где не работает Scrum? Читай ниже.

Что такое Scrum?

Scrum - это основа для разработки продукта, объединенная схожими подходами под так называемым Agile зонтиком.

Scrum фокусируется на итеративном подходе к четко определенной цели. Цикл разработки программного обеспечения на основе Scrum делится на спринты (от одной недели до одного месяца, обычно две недели). В конце каждого Sprint команда разработчиков отправляет сборку (компонент или часть рабочего функционала), поэтому каждый участник проекта сразу видит результат работы команды. Это помогает заинтересованным лицам оставаться мотивированными в долгосрочной перспективе.

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

Зачем использовать Scrum в проекте?

Scrum - это способ думать о том, как доставить релевантные вещи пользователю в разумные сроки, это прибыльная стратегия в двух сценариях:

1. для разработки при запуске, когда владелец продукта знает необходимые функции для разработки MVP (Minimum Viable Product) и быстро вносит изменения в программное обеспечение, как только группа получает отзывы пользователей;
2. для команды разработчиков, чтобы обеспечить максимальную ценность для бизнеса, быстро реагируя на любые существенные обновления в проекте.

1. Адаптируемость

В отличие от структуры Waterfall, где требования не подлежат пересмотру, Agile считает своевременный ответ на изменение более важным, чем строгое соблюдение первоначального плана. Вместо того, чтобы придерживаться плана и реализации незапрошенных функций, Scrum гарантирует, что команда разработчиков быстрее удовлетворяет реальные потребности рынка - что крайне важно для выживания стартапа.

2. Связь

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

3. Нет микроуправления

Scrum поощряет понимание проекта каждым членом команды. Все разделяют ответственность за конечный результат. Хотя команда является самоорганизующимся подразделением, роль Scrum-мастера заключается в обеспечении равномерного распределения рисков и зависимостей по всей команде. Но Scrum-мастер не является прямым руководителем и никого не подталкивает к тому, чтобы сделать какой-либо выбор: члены команды принимают решение и несут ответственность за свои решения.

4. Автоматизация процессов

Одна из целей Scrum - максимально эффективно использовать рабочее время. Чтобы соответствовать запланированным масштабам, разработчики должны сосредоточиться на важных задачах. И, поскольку дьявол кроется в деталях, они также должны иметь дело с небольшими, но необходимыми деталями. Единственный способ справиться с этим - автоматизировать каждую рутину. Это устраняет трудоемкие рутинные задачи и увеличивает время разработки.

Scrum также вписывается в конвейер CI/CD и культуру DevOps, помогая распределять обязанности и предотвращать дублирование.

5. Улучшенный контроль

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

Благодаря постоянному обмену знаниями, Scrum гарантирует, что отсутствие члена команды (временное или постоянное) не разрушит установленные процессы.

Когда Scrum не работает

Тем не менее, как и в любой среде, Scrum имеет ограничения. Широкий спектр действий на разных уровнях может привести к провалу.

1. Отрасли с высокими рисками и/или высокими требованиями

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

В этом случае waterfall является разумной альтернативой.

2. Отсутствие связи

Scrum работает для команд, где все открыто обсуждают любые проблемы, с которыми они сталкиваются в проекте. Суть успеха Scrum - открытое общение и быстрое решение проблем.

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

3. Недостаточно гибкости

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

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

4. Стремление к совершенству

В «Мире Scrum» стремление к постоянному совершенствованию не позволяет команде создавать ценность и удовлетворять главный приоритет для потенциального успеха стартапа: стремительно вывести MVP на рынок.

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

Для этих востребованных функций существуют сеансы чистки и рефакторинга, когда команда тратит время на улучшение исходного кода.

5. Нет работы с отзывами пользователей

Игнорирование обратной связи с пользователем после запуска MVP вполне может быть смертельным звеном успеха для стартапа. Ни один стартап не может игнорировать то, что конечные пользователи думают о их программном обеспечении и все же быть успешным. Они должны собирать отзывы пользователей и собирать важную информацию как основу для улучшений.

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