Фреймворки масштабирования Agile Асхат Уразбаев, ScrumTrek / GameTrek, CEE-SECR 2017

Процесс разработки относительно небольшого проекта (командой до 9 человек) более менее понятен. В большинстве случаев это Scrum или Kanban c некоторыми вариациями и упрощениями.

С большими проектами и командами, объединяющими сотни человек все сложно. Если вся эта команда работает над одним продуктом или набором связанных продуктов, то неизбежны пересечения по коду и требованиям. Возникающие зависимости могут очень сильно замедлить разработку. Для команды это выглядит как череда постоянных прерываний со стороны других команд или менеджеров. “Классический” Agile в такой структуре может сильно ухудшить ситуацию.

Есть несколько доминирующих на рынке фреймворков масштабирования Agile на большую организацию: Scaled Agile Framework, Large Scale Scrum, Nexus, @Spotify, Nexus. Вокруг них последнее время разгорелись нешуточные холивары.

У нас в ScrumTrek в последние годы появился практический опыт работы и в докладе я поделюсь практическими рекомендациями по теме масштабирования. Будем разбираться, в чем на самом деле между ними разница и какой фреймворк вам подходит.

Transcript

1. Фреймворки масштабирования Agile Асхат Уразбаев ScrumTrek
2. Асхат Уразбаев • ScrumTrek • Основатель и генеральный директор • Agile Coach • В прошлом • Программист, менеджер, архитектор процессов
3. Аджайл
4. Front End Back End Testers Architect OPS 6 ppl 8 ppl 4 ppl Boss До-о-олго!
5. Boss Feature Team 1 Feature Team 2 Feature Team 3 Architect Отстойно! Я больше не могу контролировать ВСЕ!
6. Зависимости
7. Misalignment
8. Boss Feature Team 1 Feature Team 2 Feature Team 3 Architect
10. Чье кунгфу сильнее? Nexus @Spotify Large Scale Scrum (LeSS) Scaled Agile Framework (SAFe)
11. Lean Kanban — экосистема взаимозависимых сервисов • Система взамозависимых сервисов • Эволюционное развитие • Вообще говоря, НЕ Agile • Не будем рассматривать Продажи Маркетинг Производство Производство Клиентский сервис Транспорт СДЕЛАТЬ ПЛАН В РАБОТЕ ГОТОВО 2 2 http://leankanban.com/kanbans-service-delivery-principles/
12. Культура Практики Структура
13. Framework. Simple, not easy Nexus
14. Философия Nexus • Наследник Scrum • Правила — простые в понимании, трудные во внедрении • Минимально необходимый набор практик, артефактов, мероприятий Nexus
15. Философия @Spotify • Не фреймворк • Вдохновляет примером • Правила нужны для старта • Культура есть стратегию на завтрак
16. http://agilerussia.ru/practices/spotifyscaling/ @Spotify
17. SAFe http://www.scaledagileframework.com
19. Философия SAFe • Интегрированный набор работающих практик • Не знаете как — посмотрите у нас! • Есть ответы на все вопросы • От автора RUP Dean Leffingwell
20. LeSS
21. Large Scale Scrum • Don’t Scale – Descale! • Структура важнее • Минимальный набор работающих правил
22. Descaling Metrics UX guidelines Requirements UI Design Code Delivery
23. Что общего у всех подходов • Agile Teams и число Миллера (7±2) • Tribes и число Данбара (150) • Синхронизированные спринты • Интегрированный продукт каждый спринт
24. #L100 • Sli.do • #L100
25. Структура команд • Типичная компания • < 80 человек • Как будет устроена структура организации в разных подходах? Design Web Backend iOS Android Testing
26. Nexus Nexus guide не содержит упоминаний о том, как должна быть устроена структура команд
27. http://agilerussia.ru/practices/spotifyscaling/ Spotify • Сквозные команды, несущие ценность • Ответственность за части приложений
28. Agile Release Train в SAFe Feature teams: ►Выше скорость ►Минимум зависимостей ►T-skills Компонентные команды: ► Высокое переиспользование, технологическая специализация, критически важные NFR ► Создание компонента как потенциально заменяемой части системы с ясными интерфейсами Feature Component Feature Team Feature Team Feature Team Component
29. Cтруктура в LeSS • Идеальное состояние: • Ответственность команду за ценность/решение проблемы в любой части продукта
30. Что означает гибкость • Компания-цветочек – Фокус на планомерный рост метрик – Работа от гипотез • Проектная организация – Потребности изменчивы – Закрепление команд снижает гибкость • Крупный продукт – Динамика определяет потребность в гибкости
31. Alignment and Dependencies • Как синхронизируется работа множества команд?
32. В LeSS кросскомандная координация организуется самими командами • Just Talk! • Коммуникация через код • Межкомандные встречи • Менторы компонентов • Скауты • Межкомандный груминг • ОДИН Product Owner на все команды
33. SAFe: Program Increment Planning
34. PI Planning 8:00- 9:00 9:00- 10:30 13:00- 16:00 17:00- 18:00 10:30- 11:30 16:00- 17:00 11:30- 13:00 8:00- 9:00 9:00- 11:00 11:00- 13:00 14:00- 14:15 13:00- 14:00 После соглашения 14:15- ???
40. Program Board
41. ART Sync координирует прогресс • Прозрачность прогресса и препятствий • Проводит RTE • Участники: Scrum-мастеры, другие выбранные члены команды, при необходимости эксперты предметной области (SMEs) • Еженедельно или чаще, 30-60 мин. • Время ограничено, по завершению “meet-after” Scrum-of-Scrums PO Sync  Прозрачность прогресса, изменений рамок и приоритетов  Проводит RTE или PM  Участники: PMs, POs, другие заинтересованные лица и эксперты предметной области по необходимости  Еженедельно или чаще, 30-60 мин.  Время ограничено, по завершению “meet-after” ART Sync
42. Что еще? Цели на PI 1 Бизнес-ценность › Структурное местоположение и 7 проверка местоположения › Создать и показать прототип 8 концепции контекстных изображений › Реализовать отрицательную 8 триангуляцию по: тегам, компаниям и людям › Ускорить индексацию на 50% 10 › В индексе на 1.2 млрд. больше 10 веб-страниц › Получение и создание URL 7 Дополнительные цели для PI 1 › Нечеткий поиск по полному имени 7 › Улучшение качества тегирования до релевантности в 80% 4 PI Objectives Risk Roaming Голосование
43. Hardware/Firmware/Software company?
44. LeSS Huge
46. Сихронизация нескольких ART в SAFe • s PI Planning
47. Enterprise • Новая проблема – новая система с новым стеком • Нет автотестов • Адски-трудный рефакторинг • Нет Continuous Integration • Нет контроля версий!!! Front End Back End
48. Больше ада! • Нет интеграционных сред • Vendor lock • “Исчезновение” разработчиков • Неравномерность загрузки из-за проектного финансирования • «Водопадные» команды • OPS
49. Проблемы с составом команд • Нет выделенных разработчиков • Несбалансированная команда: – Мало разработчиков, нет тестировщиков и втрое больше аналитиков • Внешние проблемы: доступ, среды и т.д.
50. Сопротивление миддл-менеджмента
51. Развилка Перебюрократизированная организация Строим на месте Новая структура • Недобюрократизированная организация
52. Фокус для крупной компании • Структура никогда не будет готова • PI как способ таймбоксить поставку • Интеграция раз в спринт как способ повысить прозрачность • Подключение команд от PI к PI
53. Какой подход вам кажется разумнее для вашей ситуации? • http://Sli.do • #L100
54. СПАСИБО!