Global Agile Summit 2025
#GlobalAgileSummit 2025: начало
Панель «Lizard Optimization» на #GlobalAgileSummit интересна благодаря реальным примерам из практики.
Интересно, что ко многим из этих выводов мы уже пришли или практически пришли.
Началось с определения того, что является «ебагом», а что — «фичей».
Один из примеров: жалоба поступила от пользовательницы, которая не могла использовать приложение на холодильнике. Сначала было непонятно, чего именно хочет пользователь. А потом выяснилось, что у пользовательницы новый холодильник с большим экраном и Android, она хотела следить за встречами на холодильнике, пока готовит еду для детей, потому что это удобнее, чем смотреть на ноутбуке на столе, который находился дальше.
Когда мы оптимизировали пользовательский интерфейс приложения для холодильников, это сделало приложение более удобным для многих других категорий пользователей, и количество пользователей после этого заметно выросло.
Лично для меня довольно вдохновляющей оказалась панель «Breaking Bad: Creating Powerhouse Organisations Through Better Behavioral Habits» на #GlobalAgileSummit. Поскольку в начале описано много токсичных ситуаций и поведения, с которыми я регулярно сталкиваюсь на работе. Работодатель оплачивает мне курсы и прочее, заинтересован в моем росте, но наибольшее влияние я могу оказывать на команду, которой руковожу. Сам же непосредственный топ-менеджер совершает много токсичных действий и своим поведением влияет на меня. Попробую применить услышанные здесь аргументы — что микроменеджмент демотивирует и снижает продуктивность, а этот топ-менеджер постоянно требует от меня микроменеджмента, потому что он сам занимается микроменеджментом.
Интересно, что к концу дня на #GlobalAgileSummit у меня уже не осталось сил писать впечатления и заметки о презентациях. Очень сильно выматывает и лишает ресурсов пребывание среди людей, я даже почти не пытался общаться. Не стоит думать о общении на таких мероприятиях — ресурсов на это точно нет.
И так много ресурсов уходит на то, чтобы проработать и понять презентации — это у меня хотя бы получается, хотя можно и эффективнее. Смотрю, некоторые используют маппы ума для конспектирования, надо изучить это.
Было немало шуток в духе того, что Agile называют чаще мёртвым, чем Маск обещает самоуправляемые автомобили)
Кроме того, говорилось о том, что благодаря ИИ разработчики теперь не будут привязаны к командам и смогут легко менять команды и места работы, как это делают, например, хирурги. Поскольку ИИ разгрузит ментальную составляющую погружения в контекст, ИИ будет предоставлять контекст и обстановку, а разработчик будет лишь делать то, что от него требуется, не тратя сотни часов на погружение в проект и притирку к команде.
Современный ИИ — это инструмент, его можно использовать как во благо, так и для чего-то нечеловеческого, как, например, Amazon использует ИИ для наказания сотрудников, хотя, судя по всему, клиентов тоже наказывают.
Лично мне сейчас вспомнилась популярная история об Amazon, что один ИИ ошибочно предоставляет возврат средств, а другой ИИ навсегда банит клиента за получение неправомерного возврата.
Также была озвучена идея, что Amazon может использовать ИИ для печати разных версий книг в зависимости от истории покупок, ведь сейчас книги не хранятся на складах, а печатаются по мере поступления заказов.
Например, включать абзац о Маске для тех, кто заказывал нацистский флаг, и убирать его для тех, кто заказывал радужный.
В общем, сейчас ИИ уже заменил новичков в юриспруденции, копирайтинге, дизайне, разработке.
Проблема в том, что старшие опытные сотрудники перенимают знания о новинках у новичков, ведь именно новички знают и интересуются новым, а с ИИ это исчезает.
Кроме того, нужно иметь достаточную квалификацию, чтобы проверять результаты работы ИИ, а когда используешь ИИ, твои навыки постоянно снижаются, и со временем ты уже не знаешь, дал ли ИИ верный результат. Теоретически необходимо регулярно проходить сертификацию, подтверждающую, что ты можешь проверять работу ИИ.
В будущем нас ждут сети ИИ, агенты ИИ и люди, работающие друг с другом, но для этого нужно решить вопросы памяти, безопасности и протокола.
Вижу, есть скептицизм: получится ли из всего этого что-то стоящее, успеют ли?)
Было интересно услышать об Agile Clinics, не слышал о таком.
Также хорошая идея с доской для экспериментов, эксперименты я люблю, можно применить) Эксперименты короткие, безопасные, дешёвые.
Также все лидеры перемен нуждаются в ком-то, с кем можно поговорить. Здесь интересно: нужно ли говорить с тем, кто тебя поддерживает, или с тем, кто бросает вызов твоим взглядам, ставит их под сомнение и противоречит тебе?
Вообще, нужно ли быть гибкими и ставить людей в центр, если Agile умирает, а побеждают Трамп и российские принципы, где вообще никто не считается с людьми, а люди — это просто ресурс, с которым не считаются.
В общем, попробую выделить для себя важные шаги для стабильной трансформации себя:
1. Делать каждую неделю что-то впервые
2. Работать с людьми, у которых можно учиться новому
3. Помнить, что это путешествие, ультрамарафон, а не спринт, не забег.
Ну и банальное: нужно расставить приоритеты в своей жизни, найти баланс между работой и личной жизнью, уделять внимание тому, что доставляет удовольствие и заряжает именно тебя.
Оказалась довольно интересная презентация «Building a Successful Agile Team in a Waterfall Company and How to Scale It» на #GlobalAgileSummit
Интересный рассказ о том, как разрабатывали и добавляли симулятор свиданий в лутер-шутер Warframe.
По сути, онлайн-игры работают по принципам Agile, потому что игрок не перестает в них играть, а постоянно получает что-то новое.
Сама компания-разработчик не работала по методу Scrum, и несколько лет назад произошёл крупный провал, когда они попытались перейти на него, поэтому применить этот подход при разработке дополнения не удалось.
Было интересно услышать, как был организован процесс исключительно в Slack без встреч — вообще не было встреч, хотя работа велась удаленно из разных уголков мира.
Для разработки функционала свиданий был открыт канал в Slack, где фиксировались итоги обсуждений, а затем в конце недели откреплялись после написания итогового отчета.
Главное — ставить людей выше процессов и полностью доверять команде, чтобы она самоорганизовывалась.
Нужно находить индивидуальный подход к подчинённым. Раскрывать застенчивых, чтобы они выражали своё видение и затем эффективно работали в соответствии с ним.
Также учитывать в Slack, что кто-то отвечает в рабочее время, а кто-то посреди ночи в выходной день отреагирует на сообщение, и именно таким людям и нужно отправлять отложенные сообщения. Я сам об этом забываю, потому что пытаюсь найти баланс и решать, отвечать ли на сообщения сразу или в рабочее время, а некоторые же всегда отвечают и действуют независимо от времени.
Кроме того, хороший менеджер всегда наблюдает и в курсе всего, но не вмешивается, а ждет, когда его спросят.
Например, женщины были против подсветки правильного варианта ответа в диалоге после его выбора, а мужчины настаивали на том, чтобы была реакция, когда выбран правильный вариант в диалоге на свидании.
Здесь уже пришлось обратиться к менеджеру: хотя она и женщина, но приняла верное решение для бизнеса, ведь 80% игроков в Warframe — мужчины.
Это пример опасности самоорганизующихся команд, когда в 1 из 10 случаев такая команда принимает неверное решение.
Нашёл время и силы, чтобы записать мысли и заметки о последних беседах #GlobalAgileSummit 2025.
Презентация «Can the Elephant Arrive on Time?» была не насыщенной и подробно сосредоточивалась лишь на одном вопросе с различными примерами.
В недавно созданной команде технической поддержки стартапа мы прошли через эти ошибки, хотя у меня теперь другая проблема, о которой в конце поста.
Основной пример в презентации — дорога, забитая автомобилями. Если на дороге нет свободного места, то скорость потока снижается до нуля, хотя в теории все могут ехать.
То же самое с своевременным выполнением задач. Если не оставлять в плане промежутков для незапланированных задач, то все задачи будут выполнены не вовремя.
А вот панельная дискуссия от Atlassian под названием «Developer Joy: How Great Teams get S%*t done» на #GlobalAgileSummit была насыщенной и с кучей тем за то же время, что и предыдущая бизнес-панель, что ещё более заметно на контрасте.
Началось всё с вопроса, кто пользуется JIRA: большинство в зале пользовались, а когда спросили, кому нравится JIRA, поднялось несколько рук. Докладчик заметил, что нужно поговорить с ними, наверное, чтобы исправить то, за что JIRA им нравится)
В наше время разработчику приходится пользоваться множеством различных сервисов, что создает большую ментальную нагрузку, чего не было 10–20 лет назад. Если рассмотреть, как достигали производительности во времена промышленной революции, то стоит заметить, что производительность разработчика — это не производительность чернорабочего на фабрике. Разработчики любят творить.
Первое из важных наблюдений заключалось в том, что должна существовать культура ревью кода. Раньше в команде Confluence в среднем 3 дня уходило на ревью кода. Ситуация улучшилась благодаря тому, что в начале рабочего дня руководитель команды напоминал ответственным о необходимости провести ревью кода, а затем эту функцию взял на себя бот, который автоматически отправлял напоминание в начале рабочего дня, если ревью находилось в очереди. В результате средняя продолжительность ревью сократилась до 1,2 суток.
От себя лично добавлю, что сам люблю делать такие напоминания. Но меня смущает, что менеджер к этому относится отрицательно, считая, что я должен тратить свою энергию на то, чтобы сам помнить 100500 вещей, которые мне нужно делать, а не создавать ботов, рассылающих напоминания. Странный подход, на мой взгляд.
Также в идеале команды должны быть автономными, в каждой команде разработчиков должен быть свой QA, но на практике в Atlassian на 30 разработчиков приходится 1 QA. После этого я понял, что у меня на работе не всё так плохо, и почему JIRA такая, какая она есть.
В Atlassian это улучшили тем, что поручили больше тестировать разработчикам: если разработчики тестируют сами и их задача не застревает на этапе QA, то это повышает удовлетворенность разработчиков. Остаётся вопрос: разработчик не может всё предусмотреть, особенно если сам писал код, но когда QA не хватает, то лучше так, чем перегруженный QA, у которого не хватает ресурсов и внимания.
От себя добавлю, что у меня в команде технической поддержки уже давно начали тестировать исправления друг друга, хотя потом это передаем в QA и бывает, что застревает на нём, но интересная идея — сделать это частью процесса. Хотя не каждому понравится тестировать чужой код, а на свой код взгляд уже притупился.
Был интересный пример, с которым наверняка каждый сталкивался: нужно уточнить конечную цель задачи. Например, менеджер попросил выгрузить данные в таблицу, потом выяснилось, что их нужно именно в формате CSV, а потом оказалось, что это нужно для передачи в CRM, хотя у CRM есть API и можно сразу осуществить передачу данных через API.
Также интересная идея: когда презентуют новый функционал, разработчик сам записывает демо и делает запись доступной для всех, вместо того чтобы устраивать встречу со всеми, а потом уже в Loom каждый зритель может оставить комментарий и создать обсуждение.
Вот этот момент мне очень понравился, потому что я аналитик, глубоко и медленно анализирую всё, а от меня требуют мгновенно реагировать на демо и задавать вопросы, и постоянно критикуют меня за то, что я плохой менеджер, потому что не задаю вопросов во время демо. Теперь будет что предложить в ответ на критику.
В общем, нужно смотреть, что важно для компании, и измерить это, следить за метриками — обычно это 4–6 метрик.
Далее уже сказали то, к чему мы пришли, что у нас есть: что нужно еженедельно проверять метрики и обсуждать их, понимать причины изменения показателей. Нормально, что что-то проседает, когда есть соответствующие причины.
В Atlassian есть одна общая метрика для всех команд — это то, сколько времени команда тратит на развитие бизнеса, его изменение, и сколько — на поддержку. У них цель — 55% на развитие и 35% на поддержку, а 10% — на удовлетворение потребностей разработчиков. В период, когда нужно было повысить удовлетворенность разработчиков, для последнего была поставлена цель в 20%.
Понятно, что разные команды разные и имеют разные приоритеты; у меня, например, команда поддержки, и, следовательно, львиную долю времени мы тратим на поддержку.
Также в Atlassian ежемесячно проводится опрос разработчиков, чтобы исправить недочеты и улучшить работу команды; вначале опросы проводились ежемесячно, теперь — каждые два месяца. Сами результаты опроса доступны публично. С опросом также связана интересная идея — нужно будет изучить всё это на сайте Atlassian.
