Как Scrum Мастеру системно разобраться с бардаком в Jira на уровне компании

Отмечу, что мы смотрим с точки зрения управления трансформации всей компании, и данная проблематика может быть не очень существенна для каждой команды в отдельности.

Возможная проблематика:

  • Облако меток в Jira не поддается никакой логике — Например метка DevOps в куче существует в вариантах (DevOps, DEVOPS, Dev-Ops, Dev_Ops, DevOps с пробелом, DevOps со *) и не понятно по какому принципу ее надо ставить на Элемент бэклога.
  • Связи между элементами бэклога дублируют друг друга, как в части названий связей (Например — “Зависит от” и ”Dependent on”), могут быть дублированы с Epic Link и т. д.
  • Названия проектов и пространств имеют разную логику и зачастую не понятно что скрывается под проектом Dev. Проекты невозможно как то быстро сгруппировать.
  • Не понятна полнота ведения бэклога группой проектов и можно ли доверять оценкам в Story Point?
  • Создано много типов элементов бэклога(Задача, Task, Задание),и они используются кардинально различающимся способом от команды к команде.
  • Не понятно, на сколько можно доверять Метрикам потока (flow metrics) и Дашбордам построенным по данным из Jira.

Команд 100+ и масштабы проблематики толко растут.

Простой ответ — ввести новую роль / человека, который будет “следить за порядком” но только как чтобы нечего не испортить и не затормозить трансформацию.

Кстати, ситуация с Jira является хорошим маркером для SM / RTE / Agile коучей, консультантов по изменениям, что с подобными проблемами могут сталкиваются и пользователи продуктов и сервисов создаваемые компанией. И лучше подойти к решению системно через Data Governance.

Ключевые элементы Agile трансформации

Ключевые элементы Agile трансформации

Без данных трудно быть DDDM. Полное название этого подхода — Data Driven Decision Making (DDDM), то есть информационно обоснованные решения (или data driven decisions). Он стал альтернативой подходу HiPPO (Highest Paid Person’s Opinion) — принятию решений на основе мнения руководства. Проблема этого подхода в том, что руководитель или менеджер не могут быть объективными и компетентными во всех вопросах и знать все особенности и нюансы. И что не маловажно иметь достаточно времени для отслеживания всех изменений на Рынке, в широком смысле слова.

Что такое Data Governance

Фактическим мировым отраслевым стандартном в области управления данными является DAMA-MDBOK.

Существуют и другие модели зрелости работы с данными:

  • Data Management Maturity (DMM), является частью CMMI
  • DCAM: The Data Management Capability Assessment Model

Но альтернативы мало помогут решить нашу, вполне конкретную проблему с Jira, они создавались для другого.

Также существуют фреймворки и базы знаний концентрирующиеся на том как работать уже с собранными данными:

Термины

Data Governance — концепция управления данными, является частью корпоративных политик управления. Существует несколько фреймворков управления данными

DAMA International — независимая от вендоров глобальная ассоциация технических и бизнес-профессионалов, управляемая Советом директоров. Основана в 1980г в США за 21 год до Agile Манифеста.

DAMA-DMBOK 2-е издание

DAMA-DMBOK. Свод знаний по управлению данными — всеобъемлющий справочник созданный DAMA, расшифровывается как DAMA — Data Managment Body of Knowledge. Труд монументальный, больше 830с. Главы написаны разными авторами, этим книга похожа на PMBOK от PMI и SRE от Google.

DMBOK Издание 1 — 2009г.

DMBOK Издание 2— 2017г, в 2020 переведена на русский язык.

CDMP — Certified Data Management Professionals, сертификационные экзамены DAMA.

CDO — Chief Data Officer, Директор по данным — это один из высших руководителей компании, отвечающий за использование и управление данными в организации.

Базовые принципы DAMA

  • Данные должны приносить новые ценности и новые продукты для компании.
  • Данные — Ценный актив, который требует управления.
  • Управление данными — отдельная корпоративная функция возглавляемая CDO.
  • Управление данными не является частью ИТ, и сильно тяготеет к Бизнесу.

Организационная схема DAMA — Роли и Комитеты

Слайд Юрия Клочко из Управление данными. DAMA-DMBOK/реальность

Рамочная структура DAMA-DMBOK — Колесо DAMA

Рамочная структура управления данными DAMA-DMBOK2 (колесо DAMA)

Помимо областей знаний, DAMA-DMBOK включает следующие

  • Этика обращения с данными
  • Оценка зрелости управления данными
  • Управление данными и управление организационными изменениями

Где легко приземлить Data Governance по DAMA-DMBOK, а где будет сложнее.

— Легче:

  • Международные корпорации
  • Финансовые институты (отсюда выросла DAMA)
  • Государственные структуры
  • Энергетический сектор (не в последнюю очередь за счет ассоциаций OSDU и PPDM)

— Сложнее:

  • Agile компании
  • Производства

Важно отметить что мы смотрим в рамках этой статьи только на Big Business. Средний и малый бизнес лучше рассматривать отдельно, в рамках другой статьи.

В РФ существует Национальная система управления данными (НСУД), в нормативных документах которой описаны требования по управлению государственными данными. Модель работы ускользающе отличима от Dama.

Первый шаг к DG в Agile компании

В лоб DAMA-MDMBOK трудно применить к Agile компании и при Agile трансформации. DAMA требует создавать комитеты, регламенты и еще много того, что не вписывается в Agile картину мира.

Что может сделать SM \ RTE c Jira

Можно системно подойти к организации работы с данными — применяя DAMA-DMBOK как справочник практик. Его можно успешно использовать для разрешения разногласий, особенно на первом этапе.

Принять, что в случае с Jira можно начать с 3х практик/областей:

  • Разработка бизнес-глоссария (Business Glossaries)
  • Master data management (MDM), еще это называется Управление Нормативно-справочной информацией (НСИ)
  • Управление Качеством данных (Data quality)

Установить роли:

  • Распорядители данных (Data Stewards) осуществляют надзор (oversight) за отдельными областями (domain) данных предприятия в процессе выполнения всех связанных с этими областями бизнес-функций.
  • Владелец данных (Data Owner) — это распорядитель бизнес-данных, который обладает подтвержденными полномочиями на утверждение решений, касающихся его области данных.

На время наиболее активной фазы трансформации владельцем Домена с Jira может быть Лидер по изменениям. Важно определить заранее условия передачи полномочий в Трайбы/ART’s, которые в итоге являются владельцами бизнес-процессов, рождающих данные.

Основная задача Владелец данных — прочертить границы ответственности для Распорядителей данных и ИТ службы.

Роль распорядителя данных может быть взята кем ни будь из Scrum Master’ов.

Распорядитель данных на своем уровне может создавать:

Бизнес-глоссарий — это не просто перечень терминов с определениями. Каждый термин должен быть связан с другими полезными метаданными: синонимами, метриками, данными о происхождении, бизнес-правилами, информацией о распорядителе данных, отвечающем за термин, и т. д.

Инструмент — Confluence.

НСИ (MDM) — это ведение контента мастер и референс данных, таких как справочник типов проблем, статусов и понятий, валют, стран, товаров, продуктовых направлений и т.п. в зависимости от организации. В рамках формализации справочников данные о них попадают в т.ч. и в бизнес-глоссарий как описание этих самых справочников.

Инструмент — Внутренние примитивы Jira + Confluence.

Управление Качеством данных (Data quality) — проверка данных введенных в Jira т.е. Бэклог всех команд на полноту, согласованность и актуальность.

Инструмент — Confluence + JQL запросы позволяющие выявлять ошибки.

Следующие шаги сильно будут зависеть от организации, но можно предположить несколько Кейсов:

  • Развитие Распорядителя данных в PO продукта, подразумевающего монетизацию.
  • Если вы собрали данные, и они не используются — нужно попробовать их продать.

--

--

--

RTE & DevOps from Nizhny Novgorod https://michael.sokolov.im

Love podcasts or audiobooks? Learn on the go with our new app.

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
Михаил Соколов

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

RTE & DevOps from Nizhny Novgorod https://michael.sokolov.im

More from Medium

A Brief History of the Scaled Agile Framework

Enterprise Agile Framework Implementation

Sometimes The Truth Hurts

When to aim for Agility instead of Agile?

agile software development, agile team, agile software developers, agile company, business agility, agile vs agility, Dreamix