Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

CEE-SECR
October 20, 2017

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

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

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

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

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

CEE-SECR

October 20, 2017
Tweet

More Decks by CEE-SECR

Other Decks in Technology

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
  9. None
  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

  18. None
  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- ???
  35. None
  36. None
  37. None
  38. None
  39. None
  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

  45. None
  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. СПАСИБО!