Занятие 1

В первом вебинаре мы рассмотрим один из самых популярных на сегодня фреймворков для масштабирования в Agile — SAFe (Scaled Agile Framework). В частности — его самую простую конфигурацию Essential SAFe.

Поговорим о:

  • мировой статистике: какой фреймворк для масштабирования сейчас самый популярный;
  • 7 ключевых компетенциях SAFe, без которых ничего не выйдет;

Scaled Agile Framework (SAFe) на уровне Предприятия даёт хорошо описанный набор практик управления Бизнесом, базирующихся на принципах Agile, Lean и DevOps. При этом на уровне кросс функциональным команд позволяя сохранить высокую степень гибкости и помогая поставлять ценный для Бизнеса инкремент вовремя.

Проблематика

Иллюстрация из Телеграм канала Enterprise Agile Russia.

Вопросы на которые уже есть ответ

SAFe помогает предприятиям ответить на следующие типы вопросов:

  • Как…

Набор из коротких видео для быстрого погружения в Scaled Agile Framework SAFe®

Общие видео, стоит смотреть всем

Обзор SAFe® 5.0 за 5 минут
Навигация по Общей Картине SAFe®
Доска Программы в SAFe®
Introduction to PI Planning: A Quick Overview

Для представителей бизнеса

Как безопасно шагнуть в SAFe®?

Для технических специалистов

Что такое DevOps?

И как правильно формулировать базовые Элементы Бэклога (PBI).

При подготовке к полевому PI Planning у команд часто бывают вопросы при разделении Бэклога на Истории и Задачи. Баги вызывают меньшие затруднения, но определённые разночтения всё-таки встречаются, что затрудняет процесс планирования. Также много вопросов возникает при формулировании самих элементов(PBI).

Итак, давайте разбираться.

История, Задача и Баг не одно и тоже.

В 3х рассматриваемых сущностях общее то, что они…

  • Оптимизация Системы важнее оптимизации отдельной команды или человека.
  • Единые правила для всех членов поезда включая менеджмент.
    Пример – Каждый сам заносит свои задачи в Jira.
  • Человеческий труд не должен пропадать.
  • Принятие решений на основе данных.
  • Экономический взгляд на приоритезацию задач
  • Нетерпимость к Лжи.
  • Если что-то может быть автоматизировано – значит это должно быть автоматизировано.
  • Санкций за Мнение быть не может.
  • Ключевые решения (архитектурные и т.п.) должны документироваться. Проблематика, контекст, варианты, причины выбора.
  • Фич в работе без критериев приёмки (AC) и гипотезе о выгоде быть не может.
  • Компетенции должны оставаться в компании
    Пример — Каждый крупный сбой должен быть задокументирован в формате Postmortem по Google SRE Book.
  • Команды идущие впереди должны иметь бенефиты.
  • Вариативность в требованиях должна оставаться на столько долго на сколько это возможно(Set-Based Design, SBD)
Git — распределённая система управления версиями.

Основные плюсы при использовании Git в одиночку

  1. Уверенность отсутствии глупых ошибок, затёрся мастер файл, уладились пара строк кода и т.п.
  2. Децентрализованный репозитарий, т.е сохранность данных.
  3. Ветки, возможность работы с несколькими версиями кода
  4. Прозрачность процесса разработки для руководства
  5. Быстрый онбординг в команду, если потребуется
  6. Возможность быстро откатываться на стабильный коммит
  7. Возможность быстро визуализировать различия между версиями кода

Сопутствующие плюшки, часто вытекающие из реализации Git

  1. Возможность использовать пайплайны и автоматизацию (CI/CD)
  2. Использование разных автоматических сценариев тестирования, независимых от рабочего места Dev,а
  3. Возможность прикреплять ID коммита к Истории или Таску, для точной индикации решения вопроса.
  4. Возможность строить отчёты по рефакторингу кода и динамике других показателей.

Книга о тайм менеджменте и стиле жизни.

Смелая книга про управление временем работой и жизнью.

Авторы по своему продлили 4 вектора Agile манифеста, получилось весело, ну и немного субъективно.

Эпатаж некоторых заявлений немного мешал моему восприятию, но как ещё достучаться до трудоголика со стажем, если не через провокацию, которая заставляет…

Правила:

  • PI Цель должна быть достижима командой за PI.
  • Фича должна быть принципиально исполнима поездом (ART) за PI .
  • История или Задача должна быть принципиально исполнима командой за Итерацию
  • Фича в текущем PI должна быть декомпозирована на Истории и\ или Задачи.
Story and Feature

Реализация в Jira

Удобные практики

  • Фича — примерно 1–2 итерации для Команды или Поезда

На данный момент реальность такова что большинство PI Planning будут осуществляться в удалённом формате и длиться 3 дня. Команды трудно собрать в 1 месте из-за их распределенности по миру и COVID ограничений.

  • Лучше всего определять мощность — по историческим данным, с учётом всех отпусков и обучений.
  • Можно вычислить пропускной способности команды до появления исторических данных.
  • При необходимости выделите процентное соотношение пропускной ёмкости для незапланированных действий, таких как обслуживание и поддержка.
  • Последняя итерация используется для Инноваций и планирования (ИП). У вас должна быть…

Условия и Применение

  • Нет исторических данных по сгоранию Story Points за спринт и Бэклог ещё не оценён
  • Новая Agile команда
  • Необходимо быстро оценить мощность команды(Team Capacity) перед PI Planning, при приземлении SAFe.
Новая Agile команда

Алгоритм:

  1. Выбираем размер Ирерации – например 2 недели. И фиксируем даты начал и концов каждой Итерации в PI.
  2. Для каждого разработчика и…

Михаил Соколов

PDM & Scrum Master from Nizhny Novgorod https://t.me/agile4dev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store