Вечером зашел на Хабр, отсортировал статьи по лучшим за сутки, вверху списка наткнулся на статью «Как убить разработку в три шага и на четвертый навсегда похоронить».
Хтонический ужас нависал над хабром, не заминусованный. Я судорожно вышел из ридонли. Мне хочется кричать, но я бью по клавишам, пишу, что рвется наружу, на этот лист.
Автор статьи – irintus (имя изменено), в подробностях рассказала зачем и как она убила процесс разработки, куда и какие зонды вставила, но забыла написать, чего этим добивалась. Давайте я это исправлю.
Почему единые метрики качества — это важно для денег
Если на вопрос поставленный так:
Без единого подхода к метрикам соотнести команды между собой очень сложно
У вас же есть CI/CD, значит и метрики есть.
Вы отвечаете так:
Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
Не завидую вам, ребята
То вы - манагер. А если вы манагер, значит, софт вас не интересует, вас интересуют отчеты. Только зачем нужны отчеты?
В дальнейшем по тексту мне начало казаться, что работников будут финансово стимулировать. А отрицательное финансовое стимулирование, как известно, тоже стимулирование.
Доктор Джордан Питерсон однажды обозначил различие между злом и трагедией. Ото зла трагедию отличает факт того, что она случается сама. Мы не можем обвинять град в том, что он побил нам помидоры. Побитые градом помидоры это - трагедия, а вот если ваши помидоры побил сосед, то это уже зло.
Но как будут собираться метрики?
Шаг 1: находим все, что дорого
Как и любой другой манагер, Irintus первым делом начала смотреть на то, что уже работает. Ведь зачем приходить в компанию с набором готовых, рабочих практик, когда можно уничтожить существующие?
Чтобы не изобретать велосипед, мы решили начать с исследования того, что уже сейчас есть в командах. Наши первые вопросы были такие: «Собирается ли в вашей команде статистика по дефектам с прода? Если да, то в каком виде?»
Да, это называется CI/CD
Практика разбора дефектов была у многих команд, но носила стихийный характер. Есть проблема — разбираем, нет проблемы — значит, все хорошо. Так мы поняли, что статистику дефектов, ее анализ, постановку целей по улучшению и SLA мало кто делал.
CI/CD и тестирование на продакшене это стихийный процесс. Стопроцентное покрытие кода – стихийный процесс. Изящная автоматизация процесса разработки через пайплайн это – стихийный процесс. Вдумайтесь в безумие этой фразы.
Доказательства отсутствия проблем через тестирование больше недостаточно. Даешь SLA! Что такое SLA? Это KPI. Не достал до KPI – не поел.
Потом мы проанализировали ответы на вопрос: «Как вы отличаете дефекты теста от дефектов прода?» — и обнаружили первую проблему.
* Дефекты прода — дефекты, найденные на прод-среде после завершения тестирования и выката на продакшен.
* Дефекты теста — дефекты, найденные на любой из тестовых сред
Юнит тесты, интеграционные тесты и тесты на продакшене, все слиплось… пелена на глазах… трудно дышать…
Устраивать Jira-фашизм и заставлять всю компанию перейти к одному-единственному подходу нам не хотелось. Поэтому стали копать дальше. Более глубокий анализ показал, что из всех подходов есть абсолютное большинство, и мы смогли выделить четыре варианта разделения дефектов теста и прода.
Удобство, интеграция с IDE, CI/CD. Незнакомо… непонятно... Сжечь, уничтожить, заменить.
Шаг 2: искажаем, заменяем, уничтожаем
Irintus, манагеры, пожар, ураган или наводнение, это феномены, в них нет ни жалости, ни корысти. Не нужно винить огонь в том, что он поглощает топливо, их приход - трагедия. Но коптящий огонь инквизиции заговорил. И рассказал, что сделал, как уничтожил, подробно, цинично, по пунктам. Вот вам, краткий дайджест:
1. Заставить молчать
Пт. Количество заведенных и закрытых дефектов & пт. Соотношение дефектов и задач
«График закрытых дефектов должен быть приближен к графику заведенных. Обратное говорит о том, что команда не успевает исправлять все заведенные дефекты.»
Гит заменяется на джиру, больше нельзя заводить TODO, и обсуждения, нельзя писать RFC, иначе графики не совпадут. Теперь только баг репорты.
Конечно, чтобы подстроиться под KPI, люди кое-чо придумают, но пусть Irintus узнает об этом сама.
2. Запретить вопросы
Пт. Количество отмененных дефектов по месяцам для теста и прода
«график показывает, сколько дефектов заводится впустую, то есть неэффективно потраченное время команды.»
Новичок задает вопросы? Так делать нельзя, график вверх – плохо. Разработчики, новенькие и техническая поддержка не должны общаться напрямую, это поднимает линию вверх, а вверх это плохо.
Это очень эффективная мера по подавлению инициативы, у компании не будет будущего, если новички не будут вовлечены в процесс.
3. Запретить тестирование
Пт. Состав релизов
«Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.»
Большое количество ишшуев во время тестирования скорее говорит, об эффективной разработке софта и о том, что люди вовлечены в этот процесс.
Если нам необходимо подавить активную разработку, то почему бы и нет, инициатива хорошая.
4. Запретить релизы
Пт. Коэффициент ошибок, пропущенных на прод
«показывает качество тестирования, проработки требований и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на прод.»
Напоминает на внедрение плохих врачебных практик в США. Лечение там опирается на строгие критерии от FDA.
Бывает, врач знает, что вот это лекарство, если дать его прямо сейчас, спасет человеку жизнь, но врач пациенту его не даст, потому что он нарушит гайдлайны FDA.
«Пойду домой, приму решение, может быть риск того и стоит, утро вечера мудренее». Подумал доктор. На следующий день пациент умер, проблема решена, совесть чиста, виновен FDA, Rinse and repeat.
С этой же ситуацией сталкиваются все «агиле коучи», команда тестирования не пропускает релиз потому, что получит по башке из-за «дефектов на проде», а команда разработки больше не может деплоить в прод, потому что команда тестирования не пропускает релиз.
Это закономерно породит цикл обвинений как на знаменитой диаграмме «заказчик-вендор-интегратор», а также разорвет фидбек с клиентами. Отличный результат!
5. Разрушить пайплайн
Пт. Распределение дефектов по приоритетам для теста и прода
«показывает, как соотносятся между собой количество дефектов с разными приоритетами для прода и тестовых сред.»
Вся сила CI/CD в том, что, работая в команде мы хотим поддерживать всего один бранч, main, и вместе весело пушить туда все что только можно. Все постоянно фетчат все изменения и всегда в курсе последних изменений, это удобно.
Сделал тесты, написал код. Проверил, все ли работает, прогнал тесты – запушил.
На сервере сборки началось тестирование – все хорошо, все прошло, все тесты зеленые -можно в релиз.
Это очень мощный инструмент, ускоряющий разработку и облегчающий жизнь всем.
Однако, если мы хотим это разрушить, то давайте заведем в джире отдельный стак ишшуев для дев и для прод. Отличная идея!
Такой подход неявно предполагает, что прод и дев это два разных пайпа или бранча, которые отдельно поддерживаются. Двойной оверхед при разработке.
Шаг 3: активные меры по подавлению разработки
Оставлять разработчиков наедине нельзя, иначе все обретет рациональные формы и станут звучать рациональные вопросы.
- А зачем нам джира, когда есть VCS? Зачем заводить ишшуй, когда человек, который обнаружил баг, может сделать пул реквест?
- Если есть рабочий CI/CD пайплайн, почему бы не взять его за основную метрику?
Чтобы подавить это, нужна активная бюрократия и красивый дашборд, в котором бюрократы смогут рассматривать цветные графики и пытаться их анализировать., проводить митапы и консультировать всех по поводу того, что они придумали.
Шаг 4: похороны
Похороны процесса разработки сопровождались такими церемониями как «встречи-презентации» и «получение консультаций». В тинькове они, кстати, обрели ритуалистический характер. Успение разработки теперь отмечается у них постоянно.
В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65.
Такой процесс я называю «End to end похороны», когда ни работники, ни начальство не понимает, зачем нужны метрики и чем одна от другой отличается.
Саботаж?
В своем обзоре я выделил только интересные участки. В целом, тут пробы негде ставить почитайте сами. Задачи, которые были достигнуты, походу, были поставлены так:
Установление токсичной атмосферы, где сотрудники компании будут ожидать «ножа в джиру»
Как можно чаще вытаскивать людей из интегрированных сред для разработки
Заставить умалчивать проблемы
Отбить новичкам желание задавать вопросы
Задерживать новые релизы
Поощрять code bloat, заставить писать mockery вместо тестов
Демонтировать CI/CD пайплайн
Уменьшить социализацию внутри команды
Но это еще не все, у них в планах:
1. «Построение еще одного дашборда качества для руководителей, с помощью которого будет возможно быстро проанализировать и сравнить несколько команд в рамках одного департамента.»
Т.е. Посеять раздор и нездоровую конкуренцию между командами
2. «Прислушиваемся к хотелкам команд и развиваем текущие дашборды: делаем новые графики, улучшаем визуализацию ранее созданных графиков, добавляем фильтры и новые возможности для удобства использования.»
Т.е. поощрять итальянские забастовки и подрывную деятельность между командами
Заключение | Imprisonment
Учитывая весь контекст и основываясь на данных из статьи и новостных источников, делаю вывод – это саботаж и попытка устранения конкурента с помощью найма вот таких кадров.
Вдогонку лишь скажу, что как же хорошо, irintus, что я работаю не с вами.
Вперед, сначала банк, потом страхование. Так победите!