Global Agile Summit 2025
#GlobalAgileSummit 2025 початок
Панель Lizard Optimization на #GlobalAgileSummit цікава завдяки реальним прикладам з роботи.
Цікаво, що вже до багато чого з цього дійшов чи дійшли практично вже також.
Почалося з ідентифікації, що єбагом, а що фічею.
Один з прикладів, що скарга була від користувачки, що не може використовувати застосунок на холодильнику. Спочатку було не розуміння чого користувач хоче. А потім вияснилось, що у користувачки новий холодильник з великим екраном і Андроїдом, вона хотіла спостерігати за зустрічами на холодильнику поки готує їжу для дітей, бо це зручніше, ніж дивитися на ноутбуці на столі, що щнаходився далі.
Коли оптимізували UI застосунку для холодильників, то це зробило застосунок зручнішим для багатьох інших категорій користувачів і кількість користувачів помітно виросла після того.
Доволі тригеряча особисто для мене панель 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, бо гравець не припиняє в них грати, а постійно щось нове отримує.
Сама компанія розробник не працювала за Scrumm і кілька років тому був великий провал, коли спробували перейти на нього, тому застосувати в розробці доповнення не було можливо.
Цікаво було почути як був організований процес чисто в 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 така JIRA.
В Atlassian це покращили тим, що доручили більше тестувати розробникам, якщо розробники тестують самі та їх задача не зависає на етапі QA, то це підвищує. задоволення оозробників. Лишається питання, що розробник не може все передбачити, особливо якщо сам код писав, але коли QA не вистачає, то краще так, ніж перевантажений QA, у котрого рескрсів та уваги не вистачає.
Від себе додам, що у мене в команді техпідтримки вже давно почали тестувати виправлення один одного, хоча потім це QA передаємо та буває зависає на ньому, але цікава ідея це зробити частиною процесу. Хоча не кожному сподобавється тестувати чужий кож, а в своєму коді вже погляд замилений.
Цікавий приклад був, з котрим напевно кожен стикався, що треба кларифікувати кінцеву мету задачі. Наприклад, менеджер попросив вигрузку даних в таблицю, потім виявилось, що їх треба саме в CSV, а потім виявилось що це треба для передачі в CRM, коли у CRM є API та можна одразу зробити передачу данних через API.
Також цікава ідея, що коли перезентують новий функціонал, то розробник записує демо сам та робить запис доступним для всіх, замість того щоб робити зустріч зі всіма, а потім уже в Loom кожен глядач може лишить коменти і створити обговорення.
Ось цей момент мені дуже сподобався, бо я аналітик, глибоко повільно аналізую все, а від мене вимагають миттєво реагувати на демо та ставити питання та постійно критикують мене, що я поганий менеджер, бо не ставлю питання на демо. Буде тепер що запропонувати на критику.
Загалом треба дивитись що важливо для компаніі та заміряти це, слідкувати за метриками, зазвичай, це 4-6 метрик.
Далі вже сказали те, до чого ми прийшли, що у нас є: що треба щотижня перевіряти метрики та обговорювати їх, розуміти причини зміни показників. Нормально, що щось просідає, коли є відповідні причини.
У Atlassian є одна спільна метрика для всіх команд - це як багато часу команда витрачає на розвиток бізнесу, його зміну, та скільки на підтримку. У них мета 55% нове та 35% підтримка, а 10% уже на задоволення розробників. В період коли треба було підвищити задоволення розробників, то останніє мало ціль 20%
Зрозуміло, що різні команди різні та мають різні приорітети, у мене он команда підтримки та отже левову частку витрачаємо на підтримку.
Також в Atlassian проводиться опитування розробниква щомісяця, щоб виправити речі та покращити роботу команди, на початку опитування були щомісяця, тепер кожні два мвсяця. Самі результати опитуваня доступні публічйно. З опитуванням також цікава ідея - треба буде вивчити все це на сайті Atlassian.
