Что делать, если ваша компания нуждается в серьезном масштабировании, а количество сотрудников, понимающих принцип методологии Scrum, недостаточно.
Тем более, необходимо учитывать не только нюансы расширения самой инфраструктуры, но и полностью соответствовать идее управления проектами разработки программного обеспечения, чтобы не прерывать рабочие процессы и не снизить их эффективность после окончания перестройки. Итак, что же нужно делать?
Планирование
Предположим, что ваша компания нуждается в разработке абсолютно нового сервиса для обслуживания клиентов. Для этого нужно создать несколько Scrum-команд, которые будут работать параллельно, двигаясь к одной цели. В данном случае, лучше, чтобы они были независимы друг от друга.
Расставьте приоритеты
Scrum методология управления проектами подразумевает, что вы должны учитывать все нюансы во время принятия каждого решения, влияющего на процесс работы. Помните, что эффективный инструмент для определенной задачи может быть полезным, но в другой плоскости он окажется совершенно ненужным.
Дублируйте эффективные функциональные решения
С точки зрения проектного управление scrum, если у вас есть эффективный инструмент, например, для проведения платежа для одного из способов, не нужно придумывать новый для другого. То есть, если алгоритм для оплаты с кредитки быстр и надежен, то используйте его и для транзакций с интернет-магазина. Зачем усложнять работу и инфраструктуру?
Передавайте сопровождающую документацию лишь частично
Когда несколько команд работает над отдельными проектами, то каждая из них будет вести собственную документацию сопровождения как фронта, так и всех микросервисов. Очень важно разделять эти две части, чтобы не вызвать путаницу во время непосредственного сопровождения продукта. Это можно сделать путем размещения документация фронта в confluence, а самих микросервисов – в git.
Проследите за идентичностью дизайна
При наличии нескольких команд, очень трудно уследить за тем, чтобы дизайнеры могли скооперировано соблюдать одинаковые требования к дизайну продукта. Периодически проводите сверки, чтобы в конце разработки не обнаружить, что весь код готов и отлажен, а дизайн всех частей абсолютно разный.
Снижайте риски
Проектное управление scrum и масштабирование может быть осуществлено несколькими способами. Каким именно воспользоваться, решать вам. Но прежде, оцените все риски. Ознакомьтесь с LeSS, создайте единый бэклог и спринт для коллективов, а также проводите запланированные беседы с руководителями команд, чтобы не сбиться с курса.
Спринт
Создайте для всех команд спринт, по которому они смогут выровняться в работе. Это поможет четко соблюдать сроки и одновременно оценивать качество. Данный метод очень эффективен при правильном применении. Стоит лишь поставить задачу и все команды реализуют ее одинаково и в один срок.
Сквозная приоритезация спринта
Создание единого бэклога также необходимо. Он должен пересматриваться в установленные сроки, чтобы вовремя определить наиболее важные элементы, на которые стоит установить высокий приоритет или наоборот.
Однако стоит заметить, что при наличии нескольких команд, стоит дать им возможность вести собственную историю работы продукта, чтобы позже иметь представление о ее эффективности как отдельно от общего сервиса, так и в объединении с продуктами других команд.
Команды должны сами анализировать свою работу на предмет расставления приоритетов. Но общие сборы помогут не сбиваться с курса и снизить риски за счет спринтов.
Разработка
Scrum методология управления проектами очень гибка, поэтому удобна для применения в любых командах. Однако, не забывайте про необходимость наличия кроссфункциональных специалистов. Например, если у вас в команде будет лишь один разработчик, понимающий JS, то некому будет осуществить контроль его работы для оценки качества.
Все команды должны быть независимыми в самом процессе разработки, но обязаны соблюдать идентичные требования к качеству. Разработчикам, дизайнерам, аналитикам и прочим необходимо кооперироваться, чтобы оценить друг друга, проследить за качеством и искать оптимальные решения вместе.
Анализ спринтов
Каждая команда должна иметь возможность увидеть плоды своего труда. Для этого и нужны общие собрания во время спринта. Спринт – это не только инструмент для контроля и установки сроков, но и шанс оглянуться и проанализировать проделанную работу.
Также можно использовать ретроспективный подход к анализу эффективности. За счет него тоже можно достичь весомых результатов. Более того, это повышает конкуренцию между командами и стимулирует их не ударить в грязь лицом перед коллегами.
Также стоит привлекать и обычных пользователей на подобные встречи, чтобы они могли оценить удобство продукта со своей стороны. Это очень удобный способ налаживания обратной связи.
Вывод
Итак, реализовать масштабирование вполне возможно. Главное, не забывать про методики управления проектами разработки программного обеспечения. И конечно же, соблюдайте баланс между регулярными совещаниями и самим процессом разработки. Это сложно, но реализуемо. Удачи!
Эффективно объединить усилия нескольких команд при работе над большим проектом, не отступая от методологии Scrum, сможет опытный DevOps руководитель с более чем 10-и летним стажем. Обращайтесь +38 (067) 523-77-57
About The Author
Виктор