0: И мы продолжаем привет. Кто только подключился к нам в прошлом докладе Константин поделился с нами опытом, наблюдениями. Как может команда компания подойти к тому, чтобы внедрять инструменты в свою разработку?

1: И мы упоминали, что вообще довольно важно понимать, да, какие у вас вообще процессы разработки и, главное, уметь измерять нужные вещи. То, что нам действительно важно. Поэтому с нами сегодня человек, который умеет измерить в разработ,

2: Примерно все рассказать, почему мы это Мерим, что должно мерить. И, надеюсь, мы сегодня поспрашиваем и узнаем о том, как ишечка поменяет наше представление о метриках и о том, что в них важно. Аня, привет, микро.

3: Микрофон твой. Привет всем привет. Да, как уже было сказано ранее, сегодня поговорим про метрики, поскольку я аналитик, для меня это не пустой звук. И если уж мы заговорили про меня, кто я такая?

4: Меня зовут Аня Громова, я руководитель продуктовой аналитики в управлении базовых технологий в банке. И я занимаюсь тем, что, во первых, провожу аналитику внутренних платформ. Это де платформы, платформы обсервабилити и так далее. Занимаюсь аналитикой делси.

5: Если вас эта аббревиатура смутила или показалась неизвестной не переживайте, мы ещё про неё поговорим и, конечно же, занимаюсь аналитикой я инструментов, которые внедряются в процесс разработки.

6: Зачем вообще мы здесь собрались и что вообще нас интересует? Во первых, мы хотим понять, как метрики помогают оценить те самые dlc процессы. Диэлси это совой деливери лайфсайкл или можно перевести, если на русский

7: Жизненный цикл поставки кода на прод и конечно же, с учётом того, что ai все сильнее и сильнее внедряется у нас в процесс разработки по хочется понять, как он влияет и на процессы поставки кода на прод 2.

8: Аспект это то, что существующие фреймворки метрик, они на самом деле устаревают. Во первых, потому что у нас меняются процессы разработки, а во вторых, потому что спойлер, эй тоже меняет разработку, но об этом по порядку. Какой у нас вообще с вами план?

9: Капкан, что будем обсуждать и по какому пути пройдёмся во первых мы я расскажу как мы в тбанке построили свой фреймворк метрик для сиэлси. Во вторых расскажу как этот фреймворк помогает оценивать влияние.

10: Ai на процессы поставки кода на прод. Расскажу примеры влияния эйай на метрики и конечно же, поговорим то, о чем уже упоминалось прогнозы на будущее что же мы на самом деле будем измерять в далёком, а может быть, на самом деле не в

11: Таком далёком будущем, как я уже сказала, мы к своему фреймворку метрик пришли на самом деле не сразу. Это эволюционный процесс. И для того, чтобы построить свой фреймворк ме.

12: Поставок кода на прод мы обратили сначала своё внимание, естественно, к существующим фреймворкам. И 1, который приходит на ум, который, наверное, самый известный в индустрии, это дора, вообще дора.

13: Исследовательский проект, он расшифровывается как девопс ресерч diceman, и существует он уже очень много лет более 10, и он сформировал 5 основных метрик. На самом деле до 24 года их было 4, но вот

14: После 24 года стало 5. Вы их можете увидеть на слайде. Глобально они делятся на 2 части рпут. Это пропускная способность, это по сути то как быстро вы катите изменения на прод.

15: Ну, здесь не нужно, не нужно быть большим знатоком английского, чтобы не понять, что это означает стабильность. То есть, по сути, насколько надёжны ваши поставки кода на прод, это такая получается, балансирующая 2 балансирующие составляющие катить.

16: Быстро и в то же время качественно давайте я расскажу вам про эти 5 metric для начала хотя бы потому, что они потом будут у нас с вами достаточно часто фигурировать и для нас будет очень важно на самом деле их закрепить, потому что они такие достаточно фундаментальны.

17: Во первых, это ли time for changes? Это, по сути, время, которое требуется от коммита до поставки кода на прод деплоймент фриен это частота наших деплоев. 3 метрика. Вот она как раз немножечко была.

18: Изменена после 24 года. Она как раз разделилась на 2. Вот 1 из них это file deployment рекавери тайм это по сути время, которое требуется на восстановление после сбоя релизного. Че это у нас?

19: Релизов, которые вызвали инциденты, то есть во время которых были какие-то сбои, ну и right, это, по сути, доля незапланированных работ по исправлению ошибок. Вот, измеряя эти 5 метричек, дора позволяет

20: Оценить то, насколько быстро и насколько качественно вы катите свои изменения на прод и доставляете свои новые фичи и новые релизы до конечного пользователя. Вообще, как я люблю, мне нравится эта метафора, что

21: Дора, это про конвейер. Насколько быстр и надёжен ваш конвейер, но пару лет назад мы ещё обратили своё внимание на ещё 1 фреймворк. Он уже сформирован в 21 году в майкрософте.

22: Space на самом деле это, как я называю, производительность с человеческим лицом. Почему она создатели этого фреймворка предложили рассмотреть 5 аспектов разработки.

23: И каждое из этих направлений, собственно говоря, 1 буква это и есть 1 из буковок в слове спейс, то есть space это на самом деле ещё и аббревиатура ко всем этим 5 направлениям 1 то, что связано с satisfaction, это удовлетворён.

24: Разработчиков процессами. То есть вообще, насколько им все ок, насколько они там не выгорают, насколько им комфортно работать и так далее. Перфоманс это те метрики, которые очень сильно перекли

25: С метриками доры, мы их уже с вами только что обсудили. Активность это то, что касается количества коммитов, строчек, кода и так далее. Коммуникации это взаимодействие внутри команды и в том,

26: Числе, как устроены процессы синхронизации между людьми в командах или в смежных командах. Ну и состояние потока это про то, какая когнитивная нагрузка оказывается.

27: Возлагается на разработчика и насколько ему вообще комфортно переключать фокус между разными задачами и не возникает ли у него вообще вот этого межфокусного какого-то разно

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

29: Историю с потоком в спейсе, потому что, собственно, понятно, измеряет нагрузку на разработчика. Насколько сильно у него происходит расфокус фидбэк лупс. Это у нас цикл обратной связи.

30: Обычно он измеряется через процессы ci cd, процесс тестирования и так далее, и flow state, состояние вообще потока, но здесь есть 2 важных момента. Во первых, вот.

31: Ни спейс, ни дивэкс не дают конкретных метрик по тому, как измерять эти направления, они предлагают, условно говоря, оценить тот или иной аспект работы.

32: Разработчика или тот или иной аспект процессов разработки, но не говорит, какие вообще выбирать метрики, как их считать, каким образом вы будете считать когнитивную нагрузку или как вы будете определять удовлетворённость пользователя, не

33: Понятно, но мы в любом случае обратили внимание своё на эти 2 фреймворка, потому что они позволяют оценить. Вот я вам говорила, что дора это оценка конвейера, а дивес и space это, по сути, оценка людей, которые

34: Работают за этим конвейером, и если мы будем совмещать, кажется, что у нас есть шанс попробовать оценить многогранно все эти аспекты работы и процессов, и разработчиков.

35: Но для, но для начала мы ещё решили попробовать как, собственно говоря попробовать оценить вот эти все направления для спейса мы выработали набор метрик. Вот для каждого направления, которое спейс предлагает оценивать, удовлетворён

36: Производительность, активность коммуникации, состояние потока и так далее. Мы сформировали свои метрики для удовлетворённости. Понятно. Это, по сути, уровень удовлетворённости, вовлечения, выгорания. Если бы

37: Посмотрим с вами на перформанс. Я уже говорила, что очень сильно перекликаются с метриками доры и вы их здесь можете найти. Это вот как раз time for chains, ченж, фейлор и так далее. Активность это больше про количество коммитов, строчек, кода, количество открытых эмэро.

38: Это количество влитых мэров к количеству открытых и так далее. Коммуникации. Это, собственно, про то, как устроена работа внутри команды. Какое, Коли, как удовлетворены ли

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

40: Мы ещё с вами поговорим. Это очень важная история. И вообще, насколько долго приходится ждать нам в очереди нашего ревью? Я наверняка уверена, что сейчас у вас зародилась мысль, что, ну хорошо, строчки то кода с комитами мы посчитаем, но вот эти вот

41: Странные вещи про уровень выгорания или уровень удовлетворённости это то, как вы можете посчитать, не переживайте, чуть позже я обязательно расскажу вам, как и это можно посчитать, а для devexus тоже подобрали.

42: Метрики, я вам говорила про состояние потока, это как раз вот про фокус тайм, то есть какое время позволяет разработчик, в течение какого времени разработчик может заниматься над своей задачей? Это как раз по сути,

43: Proxy, метрика это время, которое уходит на написание кода, это количество встреч, которое уходит у разработчика, потому что мало ли вдруг он все весь день проводит на встречах. Когда же ему, бедному, писать вообще код, время не и доля не

44: Запланированной, например, работы, которая влетает посередине спринта и так далее. Если мы с вами говорим про цикл обратной связи, то здесь, конечно же, это все, что связано с ревью таймом, это все, что связано с работой пайплайнов, да, как, да, мы смотрим, как отра,

45: Рабатывают процессы ci cd ну и, конечно же, опять-таки мы уже с вами говорили дора красной нитью проходит у нас через все фреймворки, здесь мы видим или time фо, и диплом, и так далее для когнитивной нагрузки здесь.

46: Это вопросы метрички онбординга, это важная история. Почему? Потому что если у вас время на анбординг очень высокое, есть вероятность того, что ваш продукт или проект, в который погружается разработчик, причём не обязательно, если он только только пришёл в компа,

47: Вполне возможно, что он пришёл из другого продукта или проекта, то есть ротировался внутри компании, и если это время достаточно высоко, то это может свидетельствать о том, что здесь есть проблемки. Мы об этом примере тоже с вами поговорим.

48: Социальный граф это взаимодействие с командой. И здесь у нас тоже было много интересных исследований относительно того, как влияние, взаимодействие внутри команды влияет уже на процесс разработки и в том числе уровень

49: Сложности кода и количество вообще разных Тулов и инструментов, с которыми работает разработчик, потому что если он достаточно велико и он все время вынужден переключаться между большим количеством разного инструментария, это может приводить

50: К тому, что у него будет происходить постоянный расфокус.

51: Как вы заметили, что я уже повторилась, да, что дора у нас красной нитью проходит везде и как самостоятельные метрики, и как часть метрик дивэкс, и как часть метрик спейса, и все 3 фреймворка друг другу не противоречат.

52: Они дополняют друг друга, позволяя сделать более полную картинку. Как я уже сказала, мы можем оценить и конвейер, и людей за этим конвейером, тем самым понять, какой у нас проблемные, какое у нас проблемное место.

53: В процессах, переварив все эти фреймворки и поработав с набором этих метрик, мы сформировали своё дерево метрик. Мы его представили на февральской конференции, поэтому здесь вы можете там сбоку видет

54: Плашечку, то sen конф на самом деле, наверное, если говорить более честно, это даже не столько дерево, сколько сеть, но тем не менее, давайте про неё тоже расскажу, потому что она достаточно большая и занимательная. Вот верхняя часть это наша

55: Замечательная тора, все те самые замечательные 5 метрик и то, как их можно разложить путём создания прокси метрик, прокси метрик, да, то есть те метрики, которые опосредованно объясняют ту или иную метрику,

56: Вы можете опосредованно понимать, что если вот эта прокси метрика растёт или падает, она будет влиять на верхнее, стоящую снизу растёт дивэкс растёт, в смысле произрастает. И вы здесь видите, что часть метрик пересекается. И это окей, потому что

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

58: Замечательные метрички, которые уровень выгорания, уровень удовлетворённости, как вот это посчитать и как сюда их вписать, что мы для этого сделали раз в полгода мы проводим большой опрос по всем it сотрудникам в рамках

59: Которых, в рамках которого спрашиваем людей, насколько вы удовлетворены процессами разработки, насколько вы удовлетворены процессами кодревью? Насколько вы удовлетворены процессами внутри команды? Какой у вас

60: Чувствуете ли вы выгорание и так далее, и тому подобное. Он очень большой, там большое количество вопросов. И как раз это нам позволяет закрывать вот те части спейса, которые связаны с удовлетворённостью и с коммуникациями сразу.

61: Скажу, на самом деле, вот те метрики опросные, которые мы проводим раз в полгода, и метрики, которые мы собираем согласно вот этому графу, который вы видите на слайде, они не противоречат друг другу, если

62: Мы видим, что люди в опросе жалуются на процессы код ревью, то мы стопроцентно с вами увидим, что ревью тайм достаточно высок.

63: Если люди жалуются на то, что-то, что им не нравятся какие-то процессы, мы, например, можем видеть, что количество встреч, доля встреч достаточно высокая, да, там так, митинг, тайм рейд, это вот этот вот

64: Таким образом мы можем отслеживать проблемные места и пытаться их исправлять, фиксить и находить какую либо какие-либо решения. Давайте

65: Я вам приведу несколько примеров, чтобы было понятно о чем идёт речь и как вообще можно эти метрики использовать для оценки процессов с dlc давайте разберём, я не могу сказать, что простую, но чуть более.

66: Мне кажется, чуть более простую для понимания метрику летаем, фо ченджес. Это, напомню, время от коммита до появления кода на проде, и её можно разложить на 2 составные части. Это все, что связано.

67: С анбордингом и все, что связано там с процессами, которые проходят уже при написании кода процессы сиайси и так далее. Анбординг это, понятно, время до 1 коммита мэра диплоя. И, как я уже говорила, это не обязательно. Можно

68: Применять только для процессов, когда человек только только пришёл в компанию, это можно в том числе использовать и в кейсах, когда у вас человек ротировался внутри компании и стал работать в другом проекте или продукте.

69: Tems это все, что касается, понятно, время до коммита, до Мержа, до билда, до диплоя и все, что связано с процессами сиайсиди. И здесь, заметьте, не только время длительность пайплайнов, сиайсиди, но и уровень падающих.

70: Планов. Почему? Потому что мы уже знаем достоверно корреляцию, что чем больше у вас падает пайплайнов, тем дольше, собственно, они будут у вас крутиться, они у вас будут увеличивать время, а это время будет влиять на й. То есть тем до

71: Дальше у вас будет идти код до ваших Конечных пользователей. Тайм ту мерч тоже, как видите, раскладывается на несколько прокси прокси метрик. Да, это и время ревью, и время реворка, и в размер эмера. Почему? Потому что ещё раз, потом

72: Чуть позже приведу пример, как это все влияет. Давайте рассмотрим примеры, как вы можете использовать эти метрики и какие выводы вы можете из них делать. Здесь 3 примера. Сейчас расскажу. 1. Пред

73: Представляем, что у нас ли time вырос с and do ка дней, не знаю, был 1 день, стал 5, что мы можем сделать и вообще, как можем проверить идём в веточку онбординг таймс, и если мы видим, что у нас значительное количество вре,

74: Время до 1 мэра, то с высокой вероятностью у нас есть.

75: Гипотеза о том, что у нас может быть причина либо в плохой документации и разработчику, чтобы разобраться в новом проекте или продукте в новом, для него требуется большое количество времени, прежде чем вообще он сможет запушить какой-то свой 1 mr, а может быть, там.

76: Проблемы с доступами. То есть такая специфика продукта или проекта, что чтобы получить весь необходимый набор доступов, у человека уходит такое количество времени, что это увеличивает время до 1 мра, а это, соответственно, влияет там уже в

77: Налетай. Особенно, конечно, это важно. Если у нас с вами проект в какой-то активной стадии, а не просто в на этапе рано. 2 пример, допустим, мы видим, что литам у нас вырос на какое-то количество процентов.

78: Хотя вроде бы смотрим, не увеличилось количество коммитов, они все те же. Тоже самое смотрим, идём в веточку пайплайн и начинаем проверять там метрички. Допустим, видим, что увеличилось. Тестинг таймс, скорее всего.

79: Может быть, что причина, в чем мы добавили медленные энту тесты, они у нас стали увеличивать тестинг таймс. Это, соответственно, стало увеличивать пайплайн таймс, а это ли time? Это благодаря этому мы можем уже совершать какие-то дальнейшие

80: Процессы по оптимизации, ускорению или ещё чему-то, чтобы исправлять этот вопрос 3 пример мы видим, что у нас ли time высокий, хотя вроде бы ci cd в норме, и вот как раз пайплайн duration time нормальный.

81: Зато видим, что у нас очень высокий ревью тайм. Начинаем смотреть. Вырастает большой, вырастает Эмер сайз, то есть мерч тайм сайсс. Ну или там размер реквеста. Можно, в принципе, смотреть даже медиану.

82: А почему? Потому что мы знаем, что чем больше мэр, тем дольше процесс ревью. В принципе, оно бьётся на уровне здравого смысла, потому что человеку, который будет ревьюить ваш мэр, чем он будет больше, этот мэр.

83: Тем больше времени понадобится ревьювер, чтобы разобраться во всех хитросплетениях и вообще понять, насколько бьётся, не бьётся логика и так далее.

84: Сейчас вы меня спросите. На самом деле, не только вы, это достаточно частый вопрос, который я слышу о том, что, а что делать. А, да, прежде тем, что делать. Ещё маленький нюанс, расскажу про телеметрию, и почему это залог успеха. Вот.

85: Когда мы говорили с вами об этом графе с метриками

86: Sweet time вот с этим все плюс минус понятно он в принципе в большинстве своём скорее всего вы его соберёте при помощи данных из гитлаба да, потому что это все что касается комитов это все что касается

87: Мэров и так далее. Но если мы с вами посмотрим на метрику, вот, связанную с recovery time, там, скорее всего, вам понадобится оценивать уже системы обсервабилити системы работы с инцидентами, там же надо будет смотреть релизы.

88: Другими словами, уже появится большое количество систем. А если мы с вами возьмём дивэкс и вспомним там замечательные метрички фокус тайм, то здесь у нас появится вопрос, а какое количество инструментов вообще затраги?

89: Разработчик, как он часто между ними переключается, а вот количество, чтобы померить долю времени, сколько он проводит на встречах, тогда, значит, нам нужно использовать оценку внутренних корпоративных систем и так далее.

90: И тому подобное. То есть вы видите, что количество источников растёт, поэтому нам понадобится с вами собирать, во первых, из разных источников метрички, а во вторых, нам нужно будет продумывать концепт, как связывать эти разные сущности, если для

91: Там мы с вами оперируем коммитами полуёкта, да, то для всех остальных придётся уже формировать какие-то другие сущности и находить связи. 2 аспект телеметрии это регулярность. Да, мы можем с вами разово как-то так собраться.

92: И ударно все посчитать, но мы ваш в данном случае тогда получим просто snapshot, мы получим, по сути срез, какие были метрички на этот момент времени, но это нам не позволит понять их динамику. А для чего это важно, вдруг вы собрали, не знаю.

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

94: Увидите их сезонность, бизнес смысл собираем не все подряд. Собираем только то, что нужно для подсчёта метрик. Это очень хорошо. Вам поможет не пытаться логировать все на свете и отливать логи со всех всех источников.

95: Которое надо и не надо теперь про вопрос, о котором я говорила и который мне часто задают, о том, что а если у меня вообще пока ничего нет, как мне вообще, с чего мне начать оценку этого злосчастного с дилси и

96: С чего вообще начать мой вам совет? Следующий. 1. Попробуйте оценить по метрикам доры, потому что эти метрики уже существуют. И в принципе уже понятно, как их считать. Здесь нет какого-то грандиозного рокет сайнса.

97: 2, это описывать процессы в 1 очередь, а не людей, то есть документировать, что происходит в процессах от начала задачки до диплоя и, наконец, светофор здоровья, да, вы можете точно также собирать опрос. Никто не я.

98: Вам не предлагаю на 1 этапе брать опрос аналогично нашему, в котором, не знаю, несколько Десятков вопросов и так далее. Вы можете вполне себе проводить какой-то маленький из буквально пары тройки вопросов по пятибалльной

99: Шкале, чтобы понимать общий уровень состояния разработчиков.

100: Давайте перейдём к следующему этапу. Вот мы с вами поговорили про то, какие сейчас существуют фреймворки, какой мы в банке сформировали фреймворк для подсчёта метрик. И, конечно же, у вас возникает вопрос, а как все это

101: Изменится. И как все это поменяется, если мы сюда добавим эйай.

102: Прежде чем к этому вопросу перейти, давайте я вам немножко расскажу, как обстоят дела у нас с этим инструментом. В тбанке. У нас в банке есть эя ассистент, он встроен в разные инструменты, вы можете их видеть на слайде.

103: Это и понятно идее это инструменты разработки для аналитиков это aka юпитер, ноутбучик или цеппелины, но внутри у нас мы называем их хеликоптер это и обсервабилити платформы, это поисковая.

104: Система это код ревью и многое другое адопшен нашего ассистента, какой в де это 50%, но опять-таки в зависимости от чего мерить, то есть что писать в знаменателе, если брать всех it сотруднико.

105: Это 50%. Если брать от активных в гитлабе, это 75% у инструментов аналитики, он выше. Ну и вообще, в целом, на всех, всех поверхностях. Если брать всех, всех, это 57%. Если мы будем говорить про

106: Ассистент разработчика вде, а я буду в большей степени на него фокусироваться. Он существует в формате подсказок чата, подсказки, чата, агентский режим.

107: И здесь я тоже небольшой совет, потому что тоже периодически спрашивают, а как мне начать мерить влияние эйя на разработку? Если вообще пока ничего нет, непонятно, че делать. 1, какие мои вам советы? Во первых, начните считать.

108: Минимум адопшен ну потому что если вашим инструментом пользуются полтора человека, то маловероятно, что вы вообще увидите какой-то эффект 2, попробуйте собирать хотя бы минимальный набор метрик из dlc, количественных и качественных, каких мы с вами проговорили пару слай.

109: Назад, да, напомню, это дора. Ну а в качестве качественных вы можете, в принципе, сделать какой-то маленький опрос на пару вопросов и, конечно же, артефакты использования. Эйай, приведу пример, вы можете посмотреть Мау своего

110: Тула мало, да, это какая аудитория в месяц, и он может вам показаться невероятно высоким, и вы порадуетесь. Но если вы посмотрите, как часто люди пользуются и что они там делают,

111: Вас может расстроить, поэтому нужно смотреть не только сколько людей пользуется инструментом, но и как-то есть это такой какой-то минимальный гигиенический набор, который вы можете попробовать посчитать, чтобы начать оценку. Эйя, давайте теперь разберём как же ai.

112: Влияет на процессы разработки и поставки кода на прод.

113: И для начала вообще хочется попробовать, раз уж мы с вами начали разбирать примеры из dlc, связанные с ли time, давайте попробуем и уж тогда рассмотреть, как ияй помогает ускорить ли time и медтайм.

114: Пример номер раз помните в том в примерах на слайдах назад, несколько слайдов назад я рассказывала о примере, когда у нас увеличился ли time, потому что увеличился, увеличилось кодревью, а оно увеличилось за счёт.

115: Того, что был там большой мэр.

116: И до ai у нас может было как могла быть какая ситуация, что висит наш пулреквест? Он висит йен часов. Во первых, он висит в ожидании ревью. Кто ж его вообще наконец начнёт смотреть дальше? Ревьювер будет тратить какое-то количество времени на то, чтобы

117: Оценить, посмотреть и так далее. И более того, может там отправить на доработку автору пулреквеста. Другими словами, у нас будет с вами 2, 3 итерации, но с учётом внедрения эйай, у нас эта ситуация

118: Меняется. Во первых, вам не нужно ждать, когда кто-то из людей, кто-то из членов вашей команды наконец доберётся до вашего пулреквеста. Во вторых, я ревью. Не требуется такое количество

119: Времени, как человек, чтобы пробежаться по всей логике реквеста. Ну и в третьих, зачастую он может исправить многие вещи и, по сути, свести это все к 1 итерации у нас, как я уже сказала,

120: Внедрено в процессы кодревью. Я ассистент тоже в том числе. То есть, другими словами, там у нас сокращается за счёт того, что я берет на себя рутину, стиль опечатки, баги и сокращает время на вот это вот

121: Бесконечные повторы, а мы это с вами помним, ещё влияет с точки зрения dx на фидбэк лупс на цикл обратной связи, пример номер 2 дибагинг понятно, что

122: До использования эая нужно там, не знаю, прочитать логи, погуглить похожую проблему. Возможно даже потратить какое-то количество времени вплоть до несколько многих часов, чтобы понять, в чем корневая причина и

123: И уйдёт несколько операций, там правка диплой снова падает, снова что-то исправляем и так далее. После яя, после внедрения я ассистента в процесс разработки. Понятно, что у нас меньшее количество времени уходит на анализ Логов и кода.

124: Понимание корневой проблемы и вообще опять-таки сокращаем до 1 итерации.

125: 3 пример это генерация юнит Тестов.

126: Здесь я, наверное, скажу такой момент. Во первых, все, что связано с тестированием, это отдельная большая веточка на нашем графе, и она на самом деле очень хорошо помогает оценивать, в том числе и, например, чендж фейла рейт. То есть убедиться, чт

127: У нас доля релизов, которые вызывают, вызвали инциденты, не растёт, а во вторых, есть такое интересное исследование антропка о том, что яй позволил взять на себя ту рутину, на которую люди раньше

128: Могли, до которой у них не могли. Раньше не могли дойти руки. Что это значит? Юниттесты не всегда входят в число интересных занятий разработчика, поэтому зачастую

129: Раньше разработчики нехотя особо писали эти тесты и могли даже забывать покрывать этими тестами код.

130: Однако эя эту проблему решает. Он позволяет генерировать все нужные юниттесты. Более того, за счёт того, что мы создаём эти юниттесты, мы увеличиваем долю успешных пайплайнов сиасиди. А помните, я вам ранее

131: Показывала, что помимо длительности пайплайнов в процессах сиайсиди важна и доля успешных, потому что это взаимосвязанные вещи. Мы точно знаем, чем больше пайплайнов падает, тем дольше

132: Вас, они будут бежать. Ну и понятно, что если раньше люди писали вручную, и это уходило достаточно долго, я это все может генерировать за секунды. То есть мы сокращаем, читаем за счёт того, что убираем ручное написание, но

133: А самое главное ещё увеличиваем покрытие тестами.

134: Яй влияет на медтайм или time, но если мы на самом деле с вами не будем перестраивать процессы, то есть риск просто перенести это узкое бутылочное горлышко дальше по цепочке эту мысль в своё время высказывал.

135: Мой коллега Александр Поломонов, поэтому я его на самом деле здесь процитировала. Давайте приведу пример, что это вообще значит?

136: Вот смотрите, ранее у нас там пункт 1, написание кода, и у нас узкое место было, что скорость написания, что нужно время, пока этот код напишешь и так далее, и тому подобное. Окей, внедрили. Эйай, начали писать быстрее.

137: Столкну упёрлись в следующее узкое место ревью, что ai нагенерировал код, а теперь нужно человеку это все проверить, там например вашему сеньору в команде узкое место окей внедрили ai дальше.

138: Пошли. Следующее бутылочное горлышко сиайсиди. У нас, например, мощность и надёжность сиай пайплайнов, потому что, не знаю, у нас там флаки, тесты, которые то падают, то не падают. Непонятно, что они увеличивают время. Окей, там, возможно,

139: Могли что-то поправить, но дальше, например, упёрлись в узкое место, связанное с диплоем, потому что, не знаю, у нас какая-то пропускная способность тестового окружения не позволяет нам все это быстрее ускорить. Вот этот слайд призван как раз

140: Иллюстрировать мысль о том, что ai это, по крайней мере, пока что не всегда серебряная пуля, если у вас есть проблемы вот в этих этапах процессов разработки, вы просто можете

141: Сдвигать и упрётесь, условно говоря, там не на 1, 2 этапе, а там, не знаю, на 3, 4.

142: Давайте приведу ещё конкретные цифры про то, что получилось у нас. Мердж тайм или time, да, на всякий пожарный здесь написано, что это за метрички. Во первых, мы у себя увидели снижение медианного мерч.

143: На 12% и сокращение ли time на 30%. У амбассадоров яя. Здесь есть несколько аспектов, да, некоторый дисклеймер, что снижение медианного времени это там, понятно, без учёта особенностей репозитория там и

144: Который в нём находится. То есть пока здесь за скобками оставляем аспект сложности, связанности и так далее. И что я подсвечиваю, намеренно ли time снизился у амбассадоров? Я, да, там, а не у всех.

145: На свете это важный аспект. С другой стороны, мы же здесь с вами все и собираемся, чтобы вдохновиться хорошими примерами из разряда получилось у них. Почему бы не получиться? И у нас про генерацию юниттестов. Во первых, мы увидели, что за последнее

146: Полгода увеличилась доля пользователей, которые генерируют юниттесты. И я намеренно говорю, что это не просто какая-то фича. Да, это реальный пользовательский сценарий, и доля запросов по тому, чтобы сгенерировать юнитесты через эйя ассистента выдаёт

147: Тоже выросло. И если вы меня спросите и что, я напомню вам, что, во первых, по исследованиям юнитест, относительно всего кода репозитория находится в соотношении 1 к 2, а значит, мы точно ускоряем мердж тайм, и я вам приводила ранее

148: Примеры, как это может срабатывать. Во вторых, увеличиваем покрытие тестами.

149: И последний маленькая составная часть порассуждать, подумать как ai при массовой генерации кода вообще у нас изменит процесс разработки опять.

150: Приведу примеры уже в тех метриках, которые мы с вами обсуждали код ревью в старом мире da мир, где были только люди, у нас было 2 вещи мы говорили про ревью тайм, то есть сколько времени уходит на ревью и время 1 реакции.

151: Это чтоб понять, мало ли вдруг у вас там всего 1 ревьювер, и он вынужден ревьювить 10 человек в команде, только этим и занимается везде. Но в новой. Но новая метрика для нашего нового мира это мир. Эйай плюс человек, человек просто уже

152: Не будет успевать ревьювить все эти огромные объёмы кода от ai и будет, скорее всего, переключаться на проверку только каких-то опасных участков и возможно здесь у нас будет с вами другая метрика, например.

153: Плотность человеческих комментариев на 1000 строк. 2 вариант. 2 аспект. Помните, я уже неоднократно говорила вам про размер пулреквеста, потому что чем он больше, тем люди дольше будут ревьювить и так далее.

154: Но если у нас с вами внедрён эйай в процессы кодревью, ему все равно на объём мэра, и тогда у нас с вами появится вообще другая метрика, нам не будет. С вас нам не будет уже интересен размер, мэр.

155: Нам будет интересно время, которое, например, от инцидента до автоматически сгенерировано обратного мра сколько ушло, и для нас это будет важно, а не то, какой мрр был по размеру.

156: Следующий аспект читаемость кода в нашем человеческом мире очень важна такая вещь, как цикломатическая сложность. Почему? Потому что, ну, мы люди с нашей вот такой вот

157: Несовершенной оперативной памятью мы не все можем, не все можем охватить, не все можем оценить. И нам очень важны, чтобы были там человекочитаемые имена, функции, переменные и так далее. Потому что нам важно этот код читать, вникать. У нас командная разработка, мы должны

158: Уметь подхватывать код, который написали другие люди, другие участники команды и так далее. Но для эая нет проблемы читаемости кода.

159: Поэтому для нас, например, скорее всего, вообще перестанет, возможно, иметь значение цикломатическая сложность кода, зато, например, появится метрика, успешность автоматического рефакторинга или количество логических ошибок.

160: То есть это метрики, которые вот в серой части слайда, они, вполне возможно, просто со временем отомрут и появятся совсем другие. И это как раз моя мысль о том, что все фреймворки метрик

161: Это в некоторой степени живая вещь, потому что она позво, она меняется, потому что меняется разработка, в том числе при помощи

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

163: Процессы, то скорее всего у нас не будет адекватных инструментов для их улучшения, оптимизации. 2 без метрик. У нас нет системной оценки эффекта Ия. Если мы не знаем какой у нас был ли time до

164: Как мы поймём, ускорил он его или увеличил. Ну и, в третьих, то, что я вам показала уже до этого метрики не просто могут меняться, они будут меняться. И для нас это просто хороший повод, скорее всего, встретиться ещё раз.

165: И проговорить, как наши метрики поменялись и как поменялись процессы разработки. На этом у меня все. Спасибо большое за внимание.

166: Аня, спасибо огромное за знакомство с метриками дивного нового мира. И вот тут как раз, пока ты говорила про ботлнеки, что они могут смещаться, возник, пришёл вопрос, а вот

167: На там, на вашем опыте, не знаю, вот той, после внедрения, ай, как, как боттлнек смещался, да, отёки. Есть какие-то примеры, как они смещались, то есть, что было от до и куда я

168: Его сдвинул. Так, давайте я открою вот этот слайдик чудесный. Ну, во первых, точно мы можем сказать, что вот как раз первые 2 части. Э, яй, хорошо.

169: Мы заметили, оказал влияние. Я вам привела примеры, да, там про увеличение, сокращение медтайм, про генерацию Тестов, про ревью. Но вот здесь вот эти кусочки 3, 4, мы тоже в ряде продуктов, проектов также

170: Уже в них, собственно говоря, упёрлись. Вот, потому что если у вас есть проблемы с какие-то, с настройкой тестового окружения, если у вас есть проблемы, связанные с лимитами платформы или ещё с чем-то, то здесь

171: Пока вы эту часть не пофиксите, я вам здесь, это здесь не будет мощным помощником.

172: А может вообще были какие-то, не знаю, интересные инсайты, то есть изменения метрик хуже, лучше которых вы, может быть не ожидали даже.

173: У нас было опасение, что если будет большое количество сгенерированного кода, то до внедрения Ия ревью это будет увеличивать ревью тайм.

174: Ну, потому что код будет генерироваться в большом количестве. Вот, вот здесь вот этот кусочек, да, мы думали, что будет 2, но здесь, наверное,

175: У нас удачно сошлось, что рост ревью, рост доли сгенерированного кода совпал как раз с внедрением и ревью. Вот, н как раз да, было, было опасение, что

176: При росте доли сгенерированного кода ревьювер человеку будет тяжело это все отслеживать и понимать, где здесь, что нужно там пофиксить, исправить и так далее. Я слушателей призываю.

177: Ещё раз закидывайте вопросы в чатик, в тг. Вот, либо присоединяйтесь потом к дискуссии, пользуясь этим служебным положением. Вот если мы вообще говорим о метрике, да, внедрение ai про все эти вещи, а на-ка,

178: Каких размерах инженерной команды в целом. И не знаю, при каком уровне адопшена мне вообще имеет смысл задумываться о таких метриках, системе метрик или может просто там проще раздать всем.

179: Инструменты, как-то пытаться их пропагандировать и посмотреть, что будет. Я в таких случаях. Обычно говорю, что Дору в любом случае имеет смысл считать. Ну конечно, если вы

180: Не стартап, который существует только неделю. Вот то энивей считать метрики доры имеет смысл в любом случае, тем более, что это они достаточно носят базовый характер о том, что как

181: Быстро выкатываем изменения, насколько качественные они. То есть здесь кажется это в любом случае полезно и важно для команды. А вот дальше про ai имеет смысл. Просто если у вас нет этого на регулярной основе, то кое

182: Конечно, вам будет тяжело оценивать ияй в любом случае, почему, если вы не знали, как быстро вы катили до иая, как вы поймёте, что вы ускорились после, говоря про размер команды здесь?

183: Скорее не про размер. Опять-таки, вот говоря про Дору и про чистоту и надёжность, частоту выкатки и надёжность выкатки. Мне кажется, здесь эти вопросы для вас будут актуальны, независимо от того, у вас команда 10

184: Человек или 100 Аня, спасибо огромно.