Представьте себе ситуацию, когда вы работаете над крупным проектом, но на каждом шагу сталкиваетесь с зависимостями от других команд: общие аппаратные и программные ресурсы, библиотеки, инструменты тестирования, архитектурные слои, когда фронтенд ждет бэкенд, а бэкенд - базы данных, интеграции между компонентами, последовательные этапы процесса разработки и поставки, сотрудники с уникальной экспертизой, и многое другое.
Всё это усложняет работу, снижает эффективность команд и задерживает выпуск продукта.
Что же с этим делать?
Обсудим, как эффективно справляться с этими зависимостями с помощью планирования и трекинга, изменения архитектуры, использования досок зависимостей, кросс-командных ревью кода, декомпозиции на инкременты, регулярных синхронизаций типа PIP, POSync и демонстраций, и других приёмов. Важная часть – обучение сотрудников для повышения кросс-функциональности; мы рассмотрим примеры, когда наши специалисты командируются на задачи других команд и наоборот, и как это помогает решать проблемы быстрее.
Узнаете, как грамотно справляться с зависимостями, чтобы ваш проект двигался быстрее и эффективнее, без лишних задержек и проблем.
Всё это усложняет работу, снижает эффективность команд и задерживает выпуск продукта.
Что же с этим делать?
Обсудим, как эффективно справляться с этими зависимостями с помощью планирования и трекинга, изменения архитектуры, использования досок зависимостей, кросс-командных ревью кода, декомпозиции на инкременты, регулярных синхронизаций типа PIP, POSync и демонстраций, и других приёмов. Важная часть – обучение сотрудников для повышения кросс-функциональности; мы рассмотрим примеры, когда наши специалисты командируются на задачи других команд и наоборот, и как это помогает решать проблемы быстрее.
Узнаете, как грамотно справляться с зависимостями, чтобы ваш проект двигался быстрее и эффективнее, без лишних задержек и проблем.
Предполагаемая аудитория
Тим-лиды, ИТ-лиды, пиэмы, релиз-менеджеры, деливери-менеджеры.
Виды зависимостей по источнику возникновения
- Части общей цели
- Hardware: сервер, среда, площадка, VM
- Software: библиотеки, инструменты тестирования, CI/CD pipeline, лицензии
- Части общего инкремента и интеграция
- Архитектурно слои: Front, Back, DB
- Архитектурно компоненты: API, micro-services, общие сервисы типа аутентификации
- Shared codebase
- Ожидание документации: спеки, планы, архитектура
- Части общего процесса SwD: разработка, тестирование, поставка (deliverable handoffs)
- Ожидание решения, согласования
- Maintenance windows and shared services like Support team
- Расписание релизов
- Потребность в экспертизе: предметная область и техническая
Группы подходов, с помощью которых работаем с зависимостями
- Архитектура
- Оргструктура
- Процесс SwD с этапами, чеклистами, согласующими
- Роли, права, доступы к ИС, документам, репозиториям
- Цели и ответственность за них
- Компетенции сотрудников
- Координация, встречи, тулы
- Личные отношения
Способы работы с зависимостями "УСПТ"
Для многих действий ниже необходимо проанализировать существующие документы из списка выше:
- Архитектура, интеграции
- Оргструктура
- Процесс SwD с этапами, чеклистами, согласующими
- Роли, права, доступы к ИС, документам, репозиториям
Далее все способы работы с зависимостями я разложу по 4 секторам.
Устранить
Устранить заранее, в корне. Pro-active: знаем, убираем заранее
- Изменить ответственность + независимая ответственность
- Научить или нанять + права доступа: Командировка нашего на наши задачи, Командировка их к нам, Командировка нашего на их задачи, Cross-team code review
- Изменить оргструктуру (кросс-ф.)
- Изменить архитектуру
- Убрать naming должностей ради T-shape (привет Scrum) и нанимаем таких в будущем
- Делегирование decision making
- AT, CI/CD
Смягчить
Смягчить, сгладить, облегчить: планируй, мониторь. Active: знаем, но не убираем, а подготовились
Буферное время
- Изменить ответственность + шире или уровнем выше
- Научить или нанять – без прав доступа
- Risk register запланировать и трекать: Dependency board (Gantt chart), синхронизации до, во время, после
- Декомпозировать, часть добиться от смежников, часть сделать самим
- Интеграции вперёд
- Открытая документация и история изменений
Буферное время
Предвидеть
Предвидеть. Pro-active: не знаем, но поискали, чтобы подготовиться
- Обогатить Stakeholder matrix + plan "дружить"
Тушить
Тушить: реагировать. Re-active: не знали или знали, но случилось
- Декомпозировать и часть вообще не делать
- Попросить смежников взять в бэклог
- Попросить команду 3 освободить нам слот в бэклоге команды 2
- Поделиться $
- Зайти через начальника
