Разработчик и колпак

1 week ago 1

*«You Only Live Twice», (1967)*


Развитие микроэлектроники, ИТ технологий и широкого спектра программных продуктов открыло новые возможности по контролю всего. Датчики, камеры, цифровые следы… Магнитофон в чемодане уже неактуален.


Разработчики пишут, а компании внедряют различные системы для мониторинга эффективности работы сотрудников. Казалось бы, в зоне опасности банковские операционисты, кассиры, сотрудники колл-центров и т.д, а разработчики на коне.
По факту оказывается, что разработчики могут находиться под куда более жестким контролем.
Как же так???


Все предыдущие публикации.


Поскольку это хорошо монетизируется, эту тему весьма активно продвигает множество компаний, начиная от ITSM консалтеров и завершая гитлабом. Называется эта тема VSM, расшифровывается как Value Stream Management (есть и чуть другие трактовки, например, M — Metric, но это надо отдельно сопоставлять).


Просто для примера, запрашиваем у поисковика Value Stream Management и получаем сразу широкий спектр:



Много слов, много картинок, готовность сразу принять кэш. Неизбежность грядет…
Все пропало, все пропало, Матрица наступает.



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


Если нельзя избежать, то можно возглавить и обратить это движение во взаимную пользу. При этом совершенно необязательно за VSM платить бешеные суммы, можно собрать такую штуку на DS стеке, причем функционал будет гораздо мощнее.


Для начала пробежимся тезисно по входным данным. Альфа и Омега.


#1. Разработчики работают во множестве систем. Это и почта и порталы и траблтикет система и репозиторий и много чего другого. Казалось бы, что это является проблемой.
Однако, это совсем не так, скорее, наоборот. При поставленном процессе труд разработчика может быть прецизионно оценен по цифровым следам, поскольку все регламентировано и метки должны быть осмысленными и значимыми.


#2. Метрик может быть много разных, но глобально их можно разделить на два основных класса:


  • количественные описания артефактов;
  • временные характеристики блоков процесса.
    Т.е. кто что делает и как долго с этим возится.

Очевидно, что все решения начинают свое движение от системы ведения задач. Назовем условно «Jira». Из Jira можно достать много всякой информации о задачах, подзадачах, их тегах, статусах, временах и пр… Простая статистика по атомарным атрибутам может дать массу различных срезов, чем и пользуются коммерческие решения. Много графиков и цифр — есть ощущение управляемости.


Вполне понятно, почему ITSM консультанты идут в эту тему.


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



Однако, это все плоско и скучно.


Отступим на шаг в сторону. Что мы видим? Видим же мы совокупность различных конечных автоматов (state machine), реализованных в различных информационных системах. Во всех системах есть набор записей, осуществляемых под учетной записью разработчика (или робота), содержащего, как минимум, три основных поля:


timestamp, user_id, event_id

Идеальная площадка для применения технологии Process Mining. Причем на задачу надо смотреть сразу шире, собирать сразу все. Процессная стыковка данных из различных систем для DS инструментов не является каким-то сложным вопросом. Методологически — да, надо понимать где как матчить события и идентификаторы, как расщеплять или дополнять события, как делать синтетические вставки, как нормализовать справочники по шкале времени и т.д… Но технологически это все решается без проблем.


Реконструкция транзакций дает честные ответы на все вопросы и метрики, про которые рассказывают консультанты. Все эти Lead Time/Cycle Time/Setup Time/… могут быть посчитаны для определенных путей и транзакций, можно построить распределения и увидеть многомодальность, посчитать различные стат. метрики. Картографирование процесса, сверка со стандартом и т.п. осуществляется машиной, а не человеком.


Напомню, как это все выглядит в исходном виде («лапша» или «сортировочная станция») и после применения мат. алгоритмов.
«сортировочная станция»
«Сортировочная станция»

«Чистый процесс»


Для демонстрации пример рабочего места такого аналитика, DAG, статистика, фильтры, выборки, трейсы. Все, что полагается...


DAG и сводка
DAG и сводка


Детализация и «ползунки» настройки
Детализация и «ползунки» настройки


Трейсы
Трейсы


Табличные представления
Табличные представления



Серьезной интересной связкой является Jira + Git. т.е. когда мы строим процессы по событиям из двух систем сразу. Тут и постановка задач и продвижение по задаче, тут и работа с готовыми артефактами. Репорт в таймтрекер и коммит в гит — совсем разные вещи.


После чуть более глубокого погружения становится очевидным, что к словам консультантов, анализирующих только Jira (а таких в тематике VSM большинство), можно относиться только как говорил Барон Мюнхаузен: «Нет, я говорю сущую правду и берусь ровно через час доставить вам из богдыханского погреба бутылку такого вина, в сравнении с которым ваше вино – жалкая кислятина.»


Именно связка Jira + Git, при должном выстраивании процесса разработки, позволяет построить всю цепочку от «педалить код» до получения реальной ценности в виде фичи, модуля или продукта. В гите остается крайне важный блок, отвечающий за принятие проведенных доработок в конечный продукт.


Маршрут merge-request — merge-to-dev — merge-to-release долог и болезнен.


  • Не исключены возвраты на доработку или отказы от проведенных доработок.
  • Появляются интересные метрики, связанные с фальшстартом (коммиты по задаче пошли до ее перевода в работу) или же двойным учетом (коммиты шли после формального завершения задачи).
  • Временные характеристики могут быть пересчитаны с учетом принятия доработок в релизный код.
  • Можно состыковать открытые дефекты с исходной задаче. Быстро не всегда значит качественно!
  • Лапша из задачек и подзадачек может быть собрана в единый трейс в рамках процесса.
  • При наличии CI/CD можно расширить аналитику и на этап «Deploy», много интересного вскроется.

Для примера — плотность вероятности для времен начала и окончания задач (из тех, что раньше стартовали или позже завершились)… Видна явная бимодальнось — надо детально разбираться с элементами каждого класса отдельно.



Отклонения, связанные с «ранним началом» и «поздним завершением» дочерних задач, имеют существенно более важное значение для процесса по сравнению с Git Commits самой Story


Опыт применения технологии Process Mining позволяет однозначно утверждать — халявщикам и халтурщикам скрыться невозможно. Хороший аналитик (да, как для анализа рентгенограмм, для анализа наблюдаемых картинок надо немного тренироваться) вскроет любую фродовую схему и достанет из любого уголка. Добавление же четвертого измерения (время) позволяет сравнивать разработчика самого с самим и смотреть на его динамику. При негативном тренде самое время подключаться HR специалистам и разбираться с проблемами в коллективе.


Но ведь в создании качественных и конкурентоспособных программных продуктов заинтересованы и сами разработчики. И тут VSM в большую помощь самим же разработчикам. И технология Process Mining для целей VSM.



Тему Process Mining немного затрагивал ранее:



Для более детального погружения в тематику process mining даю отсылку к отправной точке, труду Wil M. P. van der Aalst «Process Mining: Data Science in Action». Лекции, статьи, книги и т.д. можно далее искать самостоятельно, если тема заинтересует.


Заглядывайте в группу, задавайте вопросы. Иногда там даже ответы бывают.


Предыдущая публикация — «Дата саентист и циклы-циклы-циклы…».

Read Entire Article
Litres

Бесплатные объявления Пермского края