Как масштабировать Scrum — пара слов о фреймворке гибкой разработки ПО Nexus
В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
/ фото Sebastian Sikora CC
Кто и зачем создал Nexus
В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.
Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.
Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.
Чтобы исправить ситуацию и помочь масштабировать методологию, в 2015 году Кен Швабер представил фреймворк Nexus. Nexus помогает избежать частых проблем совместной разработки: сложностей при использовании одной и той же кодовой базы и нестыковок при интеграции наработок разных команд.
В Nexus использованы итеративный и инкрементальный подходы к масштабированию процессов разработки ПО. Каждая команда работает в рамках своего спринта, а потом их результаты объединяются. За счет этого разработку продукта легче координировать.
Компоненты Nexus
Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.
Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).
Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.
В Nexus, чтобы помочь с масштабированием методологии, появилась роль Nexus Integration Team (NIT). Это целая команда, в которую входят Product Owner, Scrum Master и представители скрам-команд. Их задача — оценить потенциальные проблемы командной разработки и предотвратить их. Важно отметить, что члены NIT не занимаются непосредственно программированием, а дают рекомендации по применению Scrum- и Nexus-принципов всем остальным участникам.
В целом внедрение NIT помогло улучшить координацию между командами за счет грамотного распределения задач. Однако участники ИТ-сообщества говорят, что новая роль также поспособствовала созданию своеобразного «бутылочного горлышка» — когда члены NIT решают организационные вопросы, команда разработки простаивает в ожидании инструкций.
Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).
В журнале пожеланий проекта перечислены общие требования к функциональности — так называемые пользовательские истории, отсортированные в порядке убывания важности. Они помогают получить представление о том, как должен выглядеть конечный продукт.
Журнал пожеланий спринта — список функций для реализации, выбранных владельцем продукта. На основе этого списка разработчики отслеживают задачи, которые нужно завершить до конца одного спринта.
В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.
События. Все члены команды ходят на собрания, которые иногда называют общим термином «события». «Свиньи» проводят их ежедневно, а «куры» — в начале и конце проекта или спринта. Собрания нужны, чтобы обсудить ход разработки, прикинуть планы, выявить узкие места.
Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:
- Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
- Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
- Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
- Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.
На странице официального гайда по Nexus можно найти схему взаимодействия и последовательности всех этих событий.
Когда стоит использовать Nexus
В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.
Тогда компания пригласила эксперта по Scrum, и он предложил перенести рабочую схему Scrum на многокомандный уровень — внедрить Nexus. Сейчас по Nexus-методологии работают уже шесть команд, которые стабильно выпускают новые релизы ПО каждые две недели.
В крупных компаниях. Например, у ИТ-отдела компании Terminales Portuarios Peruanos (TPP), занимающейся морскими грузоперевозками в одном из портов столицы Перу, на выпуск новой версии профильного ПО уходило целых девять месяцев. Чтобы исправить ситуацию, компания пробовала методологии Waterfall, RUP и принципы традиционного управления проектами. Однако все они не дали значительных улучшений, и в каких-то случаях даже сделали хуже.
Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.
Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.
Отметим, что хотя Nexus и помогает скоординировать работу множества команд разработки при работе над крупным проектом и ускорить выход релизов (как в случае с TPP), он все же не способен решить проблемы, связанные с внутренним устройством организации. К примеру, фреймворк не окажет заметного эффекта, если в командах будет не хватать специалистов для решения всех задач.
Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.
P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:
P.S. Несколько публикаций из нашего Telegram-канала:
