«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
3. О проекте
Облачная платформа электронной коммерции
Быстрое развертывание сайтов Интернет-торговли
Три года. Три версии платформы
Продакшен + активная разработка
Запуск продуктов и наращивание функционала
8. Как это было
1 версия
2 человека
Стартап. Прощупали почву
2 версия
10 человек
Техлид – архитектор – менеджер
Объем работы рос, процессов не было
Намечалась 3 версия
9. Проблемы на входе
• Не было налаженных процессов
• Хаотический режим поступления
задач (Do or Die, FFF)
• Ковбойские условия труда
• Непонятные срочные противоречивые требования
• Огромные переработки, у команды накопился стресс
• Ритм продолжал расти, люди начали уходить с проекта
Так продолжать нельзя…
10. Как это было
1 версия
2-3 человека
Стартап. Выстрелило.
2 версия
10 человек. Тех лид – архитектор – менеджер.
Объем работы рос, процессов не было
3 версия
16 человек
Абсолютно все созрели к смене стиля работы!
11. Особенности проекта
• Владелец продукта и продуктовая команда – на другом
континенте
• Разница во времени - 9 часов
• Особенности заказчика
• Целевая аудитория – США и Канада
• Хаотичность индустрии Direct TV
• Необходимость быстро реагировать на изменения
13. SCRUMBUT
• Слишком большая команда
• Реагировать на изменения раз в
спринт - медленно
• Активная разработка + запуск
продуктов
14. Первые шаги
Плюсы:
• Сдвинулись с мертвой точки
• Команда в курсе происходящего
• Хоть какое-то планирование лучше, чем никакого
Daily-митинги
Выяснение требований
Недельные спринты
15. Планирование и оценка задач
Покер планирование
Проблемы:
Большая команда
Можно проиграть зарплату
16. Первые шаги
Плюсы:
• Сдвинулись с мертвой точки
• Команда в курсе происходящего
• Хоть какое-то планирование лучше, чем никакого
Daily-митинги
Выяснение требований
Недельные спринты
Минусы:
• Только поиграли в покер – уже релиз
• Хаотичные релизы продолжались
17. Двухнедельные спринты?
Оптимальный горизонт планирования
Хватит времени на любую задачу
И тестирование!
Две недели в этой индустрии – очень много
Продукты запускаются несколько раз в неделю
Не решает проблему хаотичных релизов
«Некогда объяснять, нужен билд на продукцию»
Не подходит
ДА ЭТО ЖЕ КЛАССИКА SCRUM!
18. Двухнедельные спринты?
Да, плюс расписание релизов!
• Покер-планирование в начале спринта
• Расстановка приоритетов по релизам
• Приоритеты можно менять, кроме ближайшего
релиза
19. Выяснение требований
• Отдельный проект
• Идея - тикет
• Обсуждение – менеджер, архитектор, PO
• Выясненное требование – тикет в беклог
Плюс ежедневные митинги менеджера с PO
20. Команды поддержки
• Отдельный проект
Возможность создать тикет по е-мейлу
• Люди из команды
разработки
• Посменно
• Добровольно
• Ответственность за качество
• Знание платформы
Почему все те же ребята?
22. Before After
Стабильные процессы
Команда поддержки
User stories
Сплоченность
Интересная работа
На проект хотят прийти
Пальма позеленела
Хаос
Fix ASAP
Сделай то, непонятно что
Стресс
Адский труд
Проект хотелось бросить
Пальма завяла
И все это за 5,45 долларов месяцев!