Состав и особенности • Заказная разработка: автоматизация пополнения магазинов крупного ритейлера • 10 человек: аналитики, разработчики, тестировщики • Сформировалась из двух разных групп • Новый руководитель проекта Команда
системы несколько раз переносится на короткий срок (от одного дня до недели) Непонимание между участниками, ведущее к конфликтам Нет четких критериев готовности системы
на короткий срок (от дня до недели) • Заказчик хочет тестировать систему в неожиданные моменты Решение • Единый приоритизированный список задач от заказчика • Введение релизного цикла: длительность итерации — 2,5 недели, частота поставок — неделя • Неделя — компромисс между нашими возможностями и сроками сдвигов внедрения Частота поставки версии
с техдолгом: сначала под него выделили каждый 4–5-й релиз, затем — до 20 % каждого релиза Взаимодействие с заказчиком Проблемы • Неотлаженная и непостоянная коммуникация с заказчиком • Большой объем техдолга из-за быстро меняющихся требований
Не закреплены границы ролей • Отсутствие правил ведения задач в таск-трекере Решение • Договоренности о правилах работы: закрепили границы ролей, установили правила ведения задач в таск-трекере • Переход на Jira Договоренности в команде
разработка • Переход к разработке только после согласования аналитики Проблемы • Рассинхронизация работ аналитиков и разработчиков • Необходимость постоянно переделывать функционал Планирование
портал с документацией Работа с документацией Проблемы • Неструктурированная и неактуальная документация в wiki • Сложности в поиске нужной документации
руководителя команды — на внутренних процессах, фокус руководителя проекта — на внешних взаимодействиях и обязательствах Проблемы • За команду отвечал руководитель проекта, который курировал еще несколько проектов • У команды не было тимлида Организационная структура
◦ Взяли разработчика, который хотел развиваться во фронтенд-разработке ◦ Расширили обязанности одного из членов команды Проблемы • Нехватка сотрудников с нужными компетенциями из-за ухода ведущих специалистов • Невозможность быстро ввести в проект новых специалистов с рынка Состав команды
команда, налажены коммуникации Разработчики не уточняют задачи Есть понятный процесс, как внутри, так и с заказчиком Тестирование работает, как «черный ящик» Тестирование стало более прозрачным
• Чек-листы • Метрики Когда • Слияние нескольких команд или реорганизация команды • Появление новых участников в команде • Внешние изменения (организационные изменения в компании, новый формат работы с заказчиком) Когда и как пересматривать процессы?
с ролями и функциями • Договоренности о правилах работы • Общее пространство команды ◦ Чат, групповой почтовый адрес ◦ Страница команды • Состав и роли • Ссылки на самое важное • Статусы в командах: общий регулярный статус, короткие ситуативные • Таск-трекер ◦ Общая доска и доски по специализациям • Расписание работ/релизов
любой инициативный участник Ищите поддержку как внутри команды, так и за ее пределами Проговаривайте свои планы, объясняйте смысл нововведений Не рассчитывайте на быстрые результаты