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

Ранее мы уже обозначили, что Nexus состоит из интеграционной команды. То есть, это один большой коллектив, который разделен на небольшие группы в зависимости от их квалификации. В среднем в Nexus состоит от 3 до 9 команд, которые работают по принципам Scrum методологии. Они постоянно взаимодействуют между собой, чтобы достичь общей цели проекта.

Интеграционная команда Nexus

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

Интеграционная команда Nexus состоит из:

• Владельца продукта;

• Скрам–мастера;

• Одного или нескольких участников команды интеграции Nexus.

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

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

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

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

Бэклога продукта.

На этапе, когда идет работа над бэклогом продукта, интеграционная команда помогает всем командам Nexus понять свои задачи и зону ответственности в рамках проекта.

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

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

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

Владелец продукта в интеграционной команде Nexus

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

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

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

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

Скрам–мастер в интеграционной команде Nexus

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

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

Благодаря его присутствию удается выстраивать грамотные рабочие процессы в соответствии с гибкими принципами Scrum. Что необходимо для улучшения качества продукта и оптимизации рабочих процессов.

Участники интеграционной команды Nexus

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

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

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

Эти роли не подразумевают вертикальной иерархии с жесткими правилами взаимодействия. Абсолютно все участники Nexus имеют право высказывать свое мнение и влиять на ход разработки.

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

Nexus имеет несколько составляющих, таких как:

• Роли.

В основе процесса управления находится интеграционная команда (Nexus Integration Team). Она осуществляет координацию и коучинг в вопросах применения Nexus и Scrum. Благодаря им удается достичь более высоких и предсказуемых результатов. В состав этой команды входят: владелец продукта (Product Owner), Скрам–мастер (Scrum Master) и прочие участники разработки.

• Артефакты.

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

• События.

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

Подробнее о каждом из составляющих Nexus, мы расскажем в следующих разделах.

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

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

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

Далее подробнее рассмотрим основные этапы рабочего процесса Nexus.

Уточнение Бэклога продукта.

Бэклог продукта является основой для разработки. Он содержит задачи, которые требуется выполнить, чтобы достичь целей. Также он определяет требования к продукту, каким его ожидает увидеть заказчик и конечный потребитель. Именно на него опирается команда, когда планирует спринты. Созданием бэклога занимается владелец продукта, который является представителем интересов заказчика. Он же определяет последовательность выполнения задач и их сроки.

Планирование спринта.

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

Кроме того, в рамках этой встречи происходит распределение ролей, обязанностей и зоны ответственности. Это зависит от специфического набора навыков и знаний, которыми обладает специалист. Например, проверку функционала продукта доверят тестировщику, потому что он имеет необходимый опыт и инструменты.

Разработка.

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

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

Ежедневный скрам.

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

Обзор спринта.

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

Ретроспектива спринта.

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

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

Далее мы рассмотрим, какие роли существуют в рамках Nexus.

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

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

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

Рабочий стол Nexus – инструмент для визуализации прогресса работы команд в рамках Nexus. Благодаря ему участники проекта могут иметь представление об общей видимости проекта в настоящий момент. Он способствует выстраиванию коммуникации между командами, а также позволяет находить и решать проблемы продукта или процесса разработки.

Метрики Nexus – количественные и качественные показатели, которые отражают уровень эффективности работы команд в рамках Nexus. Благодаря им можно измерить скорость работы над задачами или покрыть продукт тестами, чтобы выявить скрытые дефекты.

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

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

Ниже рассмотрим основные события Nexus и определим их продолжительность.

Уточнение Бэклога

Данный вид события можно отнести к одному из самых важных, так как по сути это первая встреча, на которой закладывается будущая основа проекта.

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

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

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

Планирование спринта Nexus

Ещё одним не менее важным событием является планирование спринта, так как благодаря ему команда может определить его продолжительность и какое количество задач будет решено за этот промежуток времени.

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

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

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

Если команда смогла верно расставить приоритеты, определить продолжительность и количество задач, то сам спринт будет более продуктивным и эффективным. Кроме того, это позволит соблюсти сроки проекта.

Ежедневный скрам Nexus

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

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

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

Обзор спринта Nexus

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

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

Ретроспектива спринта Nexus

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

Ретроспективу можно поделить на три части:

1. Первая часть – определение общих проблем проекта, которые требуют решения.

2. Вторая часть – каждая Scrum–команда проводит собственную

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

3. Третья часть – повторная встреча представителей Scrum–команд для обсуждения решений проблем.

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