Юрий Соболев. Проблемы и решения Scrum на практике

Решения и проблемы
SCRUM на практике

Юрий Соболев (CTO + PO)
10 лет занимаюсь управлением техотдела

Юрий Соболев (CTO + PO)
Менеджмент? Не, не знаю

Сергей Царев (DCTO + PO)
Челмедведосвин,
I’m super cereal!

Медиатех - разработка и сопровождение
1. 120 сотрудников (2016 - 70, 2015 - 30). Отдел разработки - 29.
2. Отделы: разработка, административно-аналитический, продажи,
маркетинг, конвертация, анализа качества, финансовый
3. Полный цикл: от разработки ПО до поддержки в ведении проекта
4. Опыт создания WEB-проектов с 2006-го года.

Адстерра - биржа интернет рекламы
● 9 различных форматов рекламы
● Помогаем рекламодателям найти нужный тип трафика
● Помогаем владельцам сайтов получать максимальную прибыль с
рекламы
● Около 180 млн показов рекламы в сутки
● 100+ серверов в 7 датацентрах по всему миру
● Большой стек технологий, который постоянно расширяется.

● Июль - Октябрь 2013 – рождение проекта. MVP Adsterra ( 2.5 человека
за 3 месяца)
● Июнь - Декабрь 2014 – переход полностью на свое ПО. (6 человек за 6
месяцев)
● Февраль 2015 - Первые проблемы роста, первобытный Scrum

Первобытный SCRUM
● Нас все еще мало
● Но задач, почему-то, все больше
● Нужно все это как-то планировать и контролировать
● Илья сказал: “Нам нужен Scrum!”

Первобытный SCRUM. Результаты
Задача Результат
Приоритезация
-
Планирование
+/-
Коммуникация
+
Ответственность
+

Нас становится все больше...
● Чето опять не успели в спринт кучу тасков...может ну его нафиг, мы итак
много работаем, к чему эти формальности.
● И вообще народу все больше, занимаются разными вещами, все эти
скрам борды только путают.
● Блин, мы превращаемся в большую компанию, нам нужно планирование,
диаграмма Ганта и прочие прикольные штуки...

месяцев)
● Февраль 2015 - Первые проблемы роста, ломаем Scrum
● Лето 2015 - WaterFuc**ngFall?? (10 человек)

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

«Waterfall». Результаты
+/-
+/-
-
+

«Waterfall». Проблемы
● Один за всех и все на одного
● Я разработчик: как написали - так я и сделал
● Во всем виноваты тестировщики!

месяцев)
● Лето 2015 - WaterFuc**ngFall??(10 человек)
● Весна 2016 - Самоорганизация?(25 человек)

«Free for All»
Основные потребности:
● Децентрализовать контроль
● Свести к минимуму накладки при переходе из этапа в этап
Что сделали:
● Стали собирать команды под проект из спецов всех компетенций
● Команды выбирают ответственного и сами за всем следят
● Мы с Сережей пьем пиво и радуемся жизни (планируем...)

«Free for All». Результаты
+/-
-
+
-

«Free for All». Проблемы.
● Ответственные как-то не выбирались…
● С одной стороны команда под проект, с другой стороны задачи
подотдела по вертикали
● Попытка масштабирования привела к небольшому хаосу...

месяцев)
● Весна 2016 - Самоорганизация? (25 человек)
● Август 2016 - в России месяц тяжелый…

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

Август. Все сломалось...Надо что-то делать
Сережа:
“Юра, а давай сформируем постоянные команды по продуктам, там будут
конкретные ответственные и мы сможем пить пиво!”
Юра:
“Мне кажется, я где-то это уже видел...”

За полгода до этого Юра купил книгу и убрал в
шкаф...

● Июль - Октябрь 2013 - рождение проекта. MVP Adsterra 1.0 - 2.5
человека за 3 месяца
● Июнь - Декабрь 2014 - переход полностью на свое ПО. Adsterra 2.0 - 6
человек
● Весна 2016 - Самоорганизация? (25 человек)
● Август 2016 - в России месяц тяжелый…
● Октябрь 2016 - Scrum к нам приходит (31 человек)

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

Узнаем, как это называется в скраме
Что было хорошо Как это называется в скраме ???
Разбор задач группой Planning
Короткая итерация разработки Sprint
Все знают кто и чем занимается Backlog
Объективная приоритезация Grooming + Demo
Коммуникация подотделов Scrum Team
Коммуникация с заказчиками Daily Standup
Периодический «разбор полетов» Retrospective

Кто за все это отвечает?
Что было хорошо Как это называется в
скраме
Кто отвечает
Разбор задач группой Planning Scrum Master + Team
Короткая итерация разработки Sprint —
Все знают кто и чем занимается Backlog Product Owner
Объективная приоритезация Grooming + Demo Product Owner
Коммуникация подотделов Scrum Team Scrum Master + Team
Коммуникация с заказчиками Daily Standup Scrum Master + Team
Периодический «разбор полетов» Retrospective Scrum Master + Team

Что может быть проще?
Зачем звать кого-то для внедрения?

Сережа: “Юра, если мы сейчас обосремся, народ уже ни одно нововведение
не примет”
Юра: “Нам нужны авторитеты...”

Сережа: “Юра, если мы сейчас обосремся, народ уже ни одно нововведение
не примет”
Юра: “Нам нужны авторитеты...”
Приглашать тренеров и консультантов надо прежде всего для придания
большего авторитета нововведениям. И уже во вторую очередь - для
обучения.

Разбиться на скрам команды - делов та...
● Изначально команды сформировались на основе групп людей, которые
итак чаще всего работали вместе.
● Плюс команда тех, кто занимался всем подряд:)
● Хотели обойтись малой кровью
● Частично произошла миграция постепенно между командами

Разбиться на скрам команды - делов та...
● Изначально команды сформировались на основе групп людей, которые
итак чаще всего работали вместе.
● Плюс команда тех, кто занимался всем подряд:)
● Хотели обойтись малой кровью
● Частично произошла миграция постепенно между командами
● Но в целом - до сих пор постоянно всплывает вопрос про
переформирование команд:(

Команда AdsFormat+
На старте Сейчас
● 2 Front-End
● 1 QA
● 2 FrontEnd
● 1 QA
● 1 Backend
● 0.5 DB developer
Пытаются потихоньку выходить за рамки
1 компетенции на человека.

Команда DBModules
● 1 разработчик модулей (Back-End)
● 3 DB Developers
● 1 QA
● 2 Data Science
● 7 Developers
Но на самом деле, конечно, не совсем.

Команда Application
● 3 Front-End
● 2 Back-End
● 1 QA
● 1 DB developer
● 3 Front-End
● 2 Back-End
● 1 QA
● 1 DB developer

FullStack VS T-Shaped VS Single
● Как вы думаете, с какой командой больше всего проблем с
прозрачностью и планированием?

FullStack VS T-Shaped VS Single
● Как вы думаете, с какой командой больше всего проблем с
прозрачностью и планированием?
● Но все совсем не так однозначно: мы люди, а не машины.

Большие команды VS маленькие
Большие(Application+DBModules) Маленькие (Adsformat+)
● Устойчивость к отсутствию
сотрудников
● Больше возможностей обмена
знаниями
● Мгновенные коммуникации
● Минимум конфликтов

Армия VS Семья
Стиль общения во многом зависит от размера команды, но не на 100
процентов. Главное, чтобы устраивало команду.
Строгая организация Неформальное общение
● Повышают дисциплину
● Помогают организовывать рабочее
время
● Наработанные практики помогают
решать проблемы
● Высокая личная ответственность
● Минимум конфликтов

Активные VS Пассивные
Капитан очевидность: Лучше, когда команда состоит из активных людей,
которые уважают друг друга(лучше быть здоровым и богатым...)
Активные Пассивные
● Продвигают идеи
● Думают над улучшением команды
● Спорят(в хорошем смысле)
● Не создают конфликтов
● Не задавливают других участников

Активные VS Пассивные
Капитан очевидность: Лучше, когда команда состоит из активных людей,
которые уважают друг друга(лучше быть здоровым и богатым...)
Такое вообще бывает?
Активные Пассивные
● Продвигают идеи
● Думают над улучшением команды
● Спорят(в хорошем смысле)
● Не создают конфликтов
● Не задавливают других участников

Человеческий фактор
● Некоторые сотрудники не нашли своего места в командах
● Не все хотят заниматься чем-то, кроме “разработки”
● Необходимость отвлекаться от своей специализации нравится не всем
● Перемены для многих - это шок
● “Уравниловка” в командах нравится не всем

Скорость VS Качество
● SCRUM говорит много про скорость
● Но мало конкретного про качество
● На старте - это, возможно, и не плохо
● Но со временем создает все больше проблем

Скорость VS Качество
● SCRUM говорит много про скорость
● Но мало конкретного про качество
● На старте - это, возможно, и не плохо
● Но со временем создает все больше проблем
● SCRUM не учит Разрабатывать, это просто метод организации
процесса

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

● Кто должен это продвигать?

● Кто должен это продвигать?
● Ретроспективам надо учиться

Тех Отдел - лишь часть компании
● Приходится менять взаимодействие с другими отделами
● У вас должна быть для этого власть
● Старые подходы в других отделах тормозят многие процессы внутри
отдела
● Но нельзя просто взять и поменять всю компанию(особенно, когда не
знаешь как)
● Но постепенно пример техотдела распространяет практики по всей
компании
● И надо понимать свою ответственность за это

Выводы
Что мы приобрели:
● Мы делаем нужные вещи в короткий срок
● Мы можем расти дальше, не усложняя структуру
● Заказчики знают, чем мы занимаемся
● Разработчики все больше понимают, чем они занимаются
● В разработке все меньше узких горлышек

Выводы
А что нас еще беспокоит:
● Состав команд и специализация ее членов
● Не налажен полный процесс поставки ценности от заказа до результата
● Технические проблемы с контролем качества

Юрий Соболев. Проблемы и решения Scrum на практике

More Related Content

What's hot (16)

Similar to Юрий Соболев. Проблемы и решения Scrum на практике (20)

More from ScrumTrek (20)

Юрий Соболев. Проблемы и решения Scrum на практике