В начале 2011го года компания Skype купила небольшой стартап под названием Qik. На тот момент в компании Skype был официальный процесс на базе SCRUM. Вышло так, что после перехода на этот процесс, команда Qik сильно потеряла в скорости поставки. В своём докладе я расскажу, что именно произошло, и как следование правилам Scrum мешало команде быстро и качественно разрабатывать свой продукт.

1. Как убить поставку
Скрамом
Алексей Ильичев,
ScrumTrek

2. • С 2004 года в
разработке ПО
• Разработчик
• PM
• ScrumMaster
• AgileCoach
• Life Coach

4. Рабочая Группа
Кто будет
делать эту
фичу?
Product Owner
Team Leads
Developers

5. Преимущества
Маленькое время цикла (Time to Market)
Никакой бюрократии
Чувство ответственности
Близко к пользователям

7. Disclaimer
Я отвечал за внедрение Scrum в
российском подразделении. Моё
понимание ситуации может быть
неполным.

8. Release Vehicle (RV)
Часть системы, которую можно независимо
зарелизить.
Команда
Product Manager и Product Engineering Manager
Бэклог
Sсrum

9. Configuration Mac Client

10. Сервисная архитектура

11. Планирование
Апрель Май Июнь
iOS client
MacClient
NS
ConM
CLIB
AMS

12. Отчёты по RV (RV reports)
Была ли итерация успешной
Был ли релиз успешным
Если нет, то почему?
Регулярные совещания на уровне
директоров

14. Тут есть
зависимость
Мы можем взять
это в спринт
через неделю
6 недель
Баг!
10 недель

16. Диаграмма RV
ABE
AMS
Web
iOS
QLIB
Android

17. Ожидание
Добавление ценности
CycleEfficiency = ValueAddedTime / TotalTime
30%

18. Типичная фича

21. Первый подход: feature teams
Весь технологический
стек представлен в
одной команде
Команда делает фичу
от начала до конца
Компонентные команды
остаются, чтобы не
упало качество

22. Причины провала
Слишком много специализаций
Специалисты не будут друг друга понимать
Очень низкая взаимозаменяемость
Не получится балансировать нагрузку

24. Закон Литтла
• Время ожидания =
размер очереди /
скорость
обслуживания
• 200 человек / 20
человек в час = 10
часов
• CycleTime = WIP /
Completeon Rate

25. Незавершенная работа (WIP)
Удлиняет цикл, согласно закону Литтла
Понижает эффективность:
Переключения контекстов
Забывание и устаревание информации
Повышение затрат на багфикс

27. ABE
AMS
Web
iOS
QLIB
Android
Команда перегружена!

28. Как обнаружить узкое место
Много дефектов
Большая очередь, долгое время ожидания
Самая «занятая» команда, вечный цейтнот
Все остальные стараются уменьшить
зависимость

29. Теория ограничений
Обнаружить
Максимально использовать
Подчинить работу ограничению
Расширять

30. Вариации в потоке задач
Релиз
Команда 1
Команда 2
Команда 3

31. Межкомандный Skill Chart
Java
C++
Обработка видео
Высокие нагрузки
Android iOS Backend Галерея
+
+
+
+
+
+
+
+

32. ABE
AMS
Web
iOS
QLIB
Android
Много проблем на стыке!

33. Интеграционная команда
Второй подход к созданию кросс-
компонентных команд
Участок, где больше всего «пинг-понга»
Уменьшение «ложной нагрузки»

34. Вытягивание календарём

35. Мета-команда
Те же принципы, что и в скрам-команде
Общая цель, групповая ответственность
Самоорганизация, регулярные встречи
лидеров
«Владение» процессом
Ежемесячные релизы

36. Заключение
Оптимизируйте поток ценности, а не
отдельные участки
Контролируйте WIP
Поставьте общую цель и поощряйте
командную работу
Фиксируйте дату, управляйте скоупом

37. Спасибо за внимание!
Алексей Ильичев
Agile Coach, ScrumTrek
alexey@scrumtrek.ru
Skype: alexey.ilyichev