Пока вы работаете, ваш коллега уже сжёг 210 миллиардов токенов за неделю. Это 33 Википедии. Он не написал ни строчки в продакшн — но возглавил корпоративный лидерборд и получил звание «Token Legend».

Токенмаксинг (tokenmaxxing) — это практика, при которой сотрудники компаний соревнуются за максимальное потребление токенов, превращая сам факт использования ИИ-инструментов в показатель производительности.

Рассмотрим откуда пошел термин, почему люди соревнуются и причем тут Performance Review в FAANG.

Рассуждаем на тему того, что AI-агенты радикально скукожили привычный нам цикл разработки.

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

В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

В посте рассмотрим модель эффективной команды под названием "Учпочмак".

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

Обсудим, как диагностировать проблемы на каждой вершине "треугольника", какие таргеты поставить, а также почему несогласованность целей на масштабе нескольких команд - это главная проблема, с которой нужно бороться.

Первое крупное контролируемое исследование влияния ИИ-ассистентов на поддерживаемость кода: код, написанный с GitHub Copilot и Cursor, не стал сложнее в эволюции для других разработчиков. В двухфазном эксперименте с 151 участником (95% — практикующие специалисты) одни разработчики создавали фичи с ИИ и без, а другие — развивали чужой код, не зная его происхождения.

Результат: нет значимых различий по времени, качеству кода (CodeHealth) или покрытию тестами. При этом в первой фазе ИИ дал типичное ускорение на 31–56%. Авторы предупреждают о двух невидимых рисках — раздувании кода и когнитивном долге — которые краткосрочные метрики не захватывают.

TL;DR План «заменим разработчиков ИИ» провалился. Вот цифры

• 95% корпоративных GenAI-пилотов не дали ни доллара ROI. 

• 45% AI-кода содержит уязвимости из OWASP Top 10. 

• Набор джунов упал на 50%, а техдолг вырос в разы.

Вместо обещанной «революции» получили slop layer - код, который работает, но никто не понимает как. Senior'ы тратят 11 часов в неделю на проверку AI-галлюцинаций и работают медленнее, чем без ассистентов.

По мотивам интересного видео разобрал данные MIT, Stanford, Veracode и CodeRabbit -> что пошло не так и что с этим делать компаниям и разработчикам.

Общий объем планируемых инвестиций в ИИ-инфраструктуру к 2030 году достигнет $2.75 трлн, при этом частный капитал ($2.22 трлн) намного превосходит государственные вложения ($530 млрд). Каждая страна выбирает уникальный вектор развития, отражающий национальные приоритеты и геополитическое позиционирование.

В статье посмотрим на запланированные и уже исполненные инвестиции в ИИ-инфру по основным странам (и сравним с РФ).

Из-за экспортных ограничений США, китайские производители AI-чипов переманивают бывших сотрудников Nvidia и активно развивают свое железо.

В обзоре рассмотрим на самые перспективные стартапы в области разработки ИИ-железа (Cambricon, Baidu, Huawei, Moore Threads, Enflame, MetaX), разберем самые известные чипы этих компаний, сравним их с чипами от Nvidia и AMD.

Как использовать метрику потока Throughput и реалистично прогнозировать на основе симуляции Монте-Карло. Разберем динамику Throughput (пропускной способности) за значимые периоды времени, насколько она вариативна, посмотрим на кластеризацию по типам работы).

Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).

За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.

Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.

Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года. 

Последние 10 лет я плотно работаю со стартапами, и рынок буквально кричит: "хватит выбрасывать на рынок тонны нового функционала, займитесь уже тем, что у вас получается хорошо”. 

В рамках этого сотрудничества мы создали простую табличку, чтобы проанализировать как чувствуют себя новые фичи и как много мы в них инвестировали. В интернете очень много комплексных ROI-моделей, но простота этой таблицы в том, что ее данных достаточно чтобы начать двигаться в продуктовом направлении.

В работе с Incident Management-фреймворком мы в инжиниринге преследовали две основные цели: довести uptime до 99,99% (в API / SDK), и всегда знать о проблеме раньше пользователей.

В наши первые дни у нас не было всеобъемлющей системы оповещения и мониторинга. А если и была, то с кучей false-positive алертов и буквально одним-двумя графами в Kibana. Поэтому начать мы решили с создания команды Network Operations Center (NOC) - как стратегического базиса для работы с предотвращением и управлением инцидентами. Мы не только достигли показателя времени безотказной работы в 99,98%, но и увеличили нашу проактивность в выявлении инцидентов заранее: с 60% до впечатляющих 95% и выше. А все благодаря не только активному участию в улучшении платформы со стороны инженерки, но еще и благодаря метрикам First Time to Respond, Time to Acknowledge, Time to Assemble, Proactive Engineering Detection Rate, Number of Critical False Positives. В этом посте я расскажу про каждую из них, какие бывают антипаттерны, как измерять и как улучшать.

В последнее время я достаточно часто использую Trello, и, должен признаться, выглядит пока Трелло как наилучший инструмент для Ретроспектив и Фидбека по Демо. Так что в этом после попробуем пройтись по теме того, как Trello соотносится с другими аналогичными для этих задач инструментами.

Инструменты

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Привет всем, хотел рассказать о материалах при подготовке к сертификации PSM II от Scrum.org. Буду очень рад, если поделитесь своим опытом тоже :)

Sidenote: если вы апологет движения "сертификаты потеряли свою ценность" — я с вами соглашусь. И в отношении PSM I всё довольно просто — сертификация говорит что вы понимаете как работает фреймворк в общих чертах. В PSM II уже идёт работа с набранным в бою опытом применения скрама, потому она (сертификация) серьёзнее. Но ничего сверхъестественного в этом экзамене тоже нет. Кстати, сейчас в мире 6793 PSM II обладателей.

Подготовка к PSM II

Как писал Denis Salnikov, хорошо будет пройти Scrum.org open assesments перед сдачей несколько раз на 100%

• PSPO open — потому что там бывают вопросы, чтоб вы понимали как коучить PO и как идёт работа с ценностью. (кстати говоря, если вы дошли до PSM II, вы вполне можете сдать PSPO не мучаясь, что я и сделал).
• PSM — потому что это должно отскакивать на зубок. Ценности, роли, события, артефакты.
• PAL-E — чтобы через призму коучинга понимать менеджмент, и некоторые метрики, взрослость компании.
• PSK open — чтобы понимать основы работы с потоком.
• Nexus open — базовые основы пусть не самого популярного, но официального scrum.org решения для масштабирования.

Какие-то другие тесты надо проходить осторожно. В интернете довольно много подготовительных тестов: некоторые из них несколько PMBoK уклона, что норм для PMI-ACP, но другие прям адово извращают саму суть скрама, вводят какие-то новые роли, занимаются всяческим саботажем того, что вы практикуете к моменту подготовки к PSM II — берегите себя.

Коучинг, книжки, тренерство

Lyssa Adkins: Coaching Agile Teams — довольно лёгкая

Короткий отчет о том, как мы в Минске первый Atlassian User Group проводили.

После того, как увидел что в первой-пост-СНГ-технологической-столице не было официального Atlassian User Group'a, решили, с соратниками по Jira-энтузиазму из StiltSoft провести мероприятие, и, заодно, прощупать почву — есть ли страждущие узнать и поделиться опытом.

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

Atlassian Stride был запущен в ноябре 2017, как замена облачному HipChat. Де-факто, основной конкурент, это, конечно же, Slack. Я постараюсь сравнивать Stride со Slack, и Telegram со стороны текстовой переписки.

Плюсы

Встраивание в Экосистему Atlassian, контроль за пользователями

Самый большой плюс, это, безусловно, бесшовная интеграция в экосистему Atlassian. Есть у вас jira, confluence — и единый аккаунт у пользователя, где вы можете управлять доступом к разным кускам и возможностям этих двух приложений. А теперь у вас есть третье приложение — Stride, и управление пользователями чатика доступно из той же админки.

1. Трагедия в трех томах: как мы упрощали процессы в SkuVault, и как отражали и автоматизировали это в Atlassian Jira | Презентация
2. Цикл документооборота фич в Confluence
3. Q&A сессия с вопросами по доскам, интеграциям, тайм-трекингу в таск-трекере, и миллиону других вещей

1. стратегические митинги (планирование / ретроспектива)
2. ежедневную синхронизацию (в том числе daily standups)
3. прояснение рабочих вопросов

Учитывая что в Уфе зима приближается решительными марш-бросками, почему бы не поехать в конце октября на конференцию, куда-нибудь, где +20, и хоть немного, напоследок перед зимой, увидеть солнышко? Сказано-сделано: посмотрел конференции, сравнил докладчиков, посмотрел где еще есть early-bird access цены — и забронировал.

В этом году мы с коллегой разделились, и поехали на Agile Greece и Agile Turkey, дабы сравнить мероприятия, ну и рассказать что интересного было на каждой из них. Неоспоримы плюс Agile Turkey в этом году был открывающий доклад от Дейва Сноудена (создателя фреймворка cynefin, о которой вскользь писали на хабре). Обычно на подобных конференциях после докладов, спикеров облепляют заинтересованные, и свои вопросы задать и подискутировать не получается, что и было моим опасением, так как спросить надо было много.

Конференция и организация

Agile Turkey Summit проходит уже не первый год, в отеле Wyndham Grand Levent в Стамбуле (в активно строящемся небоскребно-деловом районе Maslak). Продолжается мероприятие всего 1 день (выпавший в этом году на 19 октября), хотя мастер-классы и воркшопы прошли еще 18-го числа. 4-й конференц-этаж отеля явно неспособен принять ~800 посетителей, что особенно очевидно, когда всех пытаются накормить.