В этом году первой прочитанной книгой стала "Камасутра для оратора" Радислава Гандапаса. И я подготовил для вас краткий отзыв о ней.

Книга, на мой взгляд, будет полезна только для начинающих выступать публично, хотя даже опытные могут найти пару-тройку полезных советов. Первая часть книги - это 10 глав по разным частям подготовки или проведения выступления, а потом вторая часть в виде 100+ вопросов и ответов. Вторая часть заметно хуже первой и как будто бы существует только чтобы добить книгу до определенного объема.

Основные плюсы кроются в раскрытии психологии выступления и многочисленных точечных советах для докладчика как во время подготовки доклада, так и во время выступления. Это реально полезно понимать и знать.

Из минусов по содержанию я бы отметил почти полное отсутствие рекомендаций по подготовке визуального ряда (слайдов, презентации, картинок), несколько устаревший контент про микрофон и сцену, а также отсутствие современных подходов как story telling. И вообще, многие вещи не пересмотрены на современный лад.

Но САМЫМ ГЛАВНЫМ МИНУСОМ я бы обозначил зашкаливающий уровень сексизма: вся книжка прямо полыхает сексистскими сравнениями, шуточками ниже пояса и намеками на гигантское эго автора. Обычно я к такой теме отношусь нормально, но тут аж перебор.

В целом, первую часть рекомендую к прочтению и выписыванию чеклиста для себя, если мириться с перечисленными минусами. Как никак, автор является российским Тони Роббинсоном в мире публичных выступлений. :)

Натолкнулся в одном из каналов на очень крутую штуку - периодическая таблица DevOps инструментов. Понятное дело, что это не все инструменты на рынке и не по всем возможным направлениям. Но очень хорошо помогает систематизировать видение и понять, а не появилось ли чего нового интересного, что стоит покопать глубже и учитывать для своих задач.

Еще рекомендую почитать комментарии, потому что много людей пополняют таблицу пропущенными в ней инструментами. В общем, крутая находка!

https://xebialabs.com/periodic-table-of-devops-tools

Сегодня мы открыли регистрацию на конференцию JEEConf и первыми об этом узнаете вы, подписчики канала. Если вы работаете с Java, то у вас есть отличная возможность пополнить багаж знаний, найти новые интересные идеи и отлично потрусить в рамках Java-сообщества. Все это 26-27 апреля, а пока у вас есть шанс купить билет по минимальной цене. Их как обычно всего 100 и разлетаются за 1-2 дня! https://jeeconf.com/registration/

Дочитываю ещё одну классную книжку под названием Microservice Patterns. Это просто кладезь знаний и опыта в области микросервисной архитектуры. Все примеры реалистичны, а разбираемые проблемы - как раз то, о чем не говорят в докладах и не пишут в книжках, когда агитируют за микросервисы. Правда книга имеет достаточно большой порог входа. Например, концепции типа распределённых транзакций, DDD или CQRS предполагаются давно знакомыми читателю. Но в этом и плюс книги, потому что «воды» минимум. В общем, всем настоятельно рекомендую.

По книге также есть сайт с описанием основных шаблонов. https://microservices.io/patterns/microservices.html

У меня для вас ещё один анонс. Мы опубликовали программу конференции Selenium Camp 2019. В этом году явно прослеживается фокус на следующие темы:

- инфраструктура тестирования с применением современных инструментов контейнеризации;
- мобильное тестирование;
- свежие инструменты на рынке как Cypress;
- затягивание всех артефактов тестирования поближе к коду.

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

Если вы ещё не купили билет или сомневались, то самое время принимать решение. Увидимся 22-23 февраля!

https://seleniumcamp.com/program/

Бытует мнение, что каждая ретроспектива должна заканчиваться четко сформулированными и взятыми в работу action items для команды. Именно поэтому 80% команд используют формат ретро "The bad, the good and action items". На мой взгляд, куда важнее бывает решить вопрос одинакового понимания командой какого-то вопроса, процесса или проблемы. Даже если в результате не будет четкого плана действий, может начаться натуральный процесс улучшений в разных областях за счет прозрачности и убирания барьеров непонимания.

Приведу пример такого рода ретроспективы. Она делится на 2 части: разминка и основная часть. Каждая может в некоторых случаях занять полноценную ретроспективу, тогда нужно использовать более короткие варианты разминки. Итак, на разминке команде предлагается выполнить следующее упражнение:

- разделиться на группы по специализации (BE, FE, Infra, QA, BA, UX и т.д.), если она есть;
- каждая группа вытягивает из шляпы бумажку с названием другой группы;
- за 5-7 минут каждая группа должна расписать свое представление рабочего дня представителя вытянутой группы, основные проблемы в его работе и кто может ему помочь потенциально;
- после этого за 3-5 минут представитель каждой группы рассказывает о получившихся результатах, а остальные могут задавать уточняющие вопросы и "набрасывать на вентилятор".

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

Далее следует основная часть, в которой фасилитатор просит помочь ему на доске нарисовать в деталях весь процесс разработки от идеи в голове заказчика (PO, CEO, клиента и т.д.) до деплоя работающей функциональности на реальные боевые окружения. При этом, должно соблюдаться одно важное правило: никто не может описывать свою собственную активность в этом процессе. То есть, если у вас есть бизнес-аналитики, работающие с требованиями, то их работу описывают другие члены команды. При этом фасилитатор может набрасывать интересных уточняющих вопросов или просто "на вентилятор". Если процесс простой и команда в курсе его деталей, то можно легко уложиться в оставшиеся 40 минут. Иначе можно уверенно потратить до 2 часов.

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

Настоятельно рекомендую попробовать. Удачных вам ретроспектив!

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

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

- ведущий покупает разноцветные конфеты m&m’s (красный, зелёный, желтый, синий);
- все конфеты в равной пропорции высыпаются в банку с непрозрачными стенками;
- члены команды поочередно вслепую тянут конфету;
- в зависимости от цвета они должны вспомнить негативный факт, нейтральный факт, позитивный факт или похвалить кого-то из команды;
- особенность в том, что добровольно можно подняться на уровень выше (например, вместо негативного факта похвалить кого-то);
- конфета съедается.

Данный формат разминки легко укладывается в 10-20 минут. Его основная цель в том, чтобы научиться смотреть на ситуацию с разных сторон, благодарить друг друга за помощь и проделанную работу, а также понять общее настроение команды.

Дальше следует основная часть в формате, в который я долгое время не верил и считал слишком детским. Вся команда разбивается на группы по 3-4 человека и получает задание нарисовать картину текущей реальности. На нем нужно визуализировать как можно ярче что тянет команду вниз, что помогает ей развиваться и добиваться целей, какие есть препятствия на ее пути, какие цели и задачи перед ней стоят. Как пример приводится корабль с островом, тучами, айсбергом, якорями и т.д. Но тема рисунка может быть изменена командой.

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

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

Готовьте свои какашки... Огонь! ;)

Вчера внезапно прочитал еще одну книгу под названием "Слушать нельзя указывать: Альтернатива жесткому менеджменту" Эдгара Шейна. Нашел ее случайно на полке библиотечки в компании, название показалось забавным и я решил прочитать описание. Книга оказалась не о менеджменте вообще, а об искусстве задавать вопросы, слушать собеседника и налаживать доверительные отношения в социальной группе.

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

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

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

Давненько мы не проводили публичных воркшопов и тренингов. Перед глядящей конференцией Selenium Camp 2019 решили организовать сразу 3. Итак, чему можно научиться в феврале?

Строить масштабируемую инфраструктуру для браузерного тестирования с Иваном Крутовым. Ваня является одним из разработчиков Selenoid и занимается тестовой инфраструктурой в Яндексе, обеспечивая быстрый и эффективный запуск десятков тысяч тестов.

Мир инструментов для тестирования не стоит на месте. Не так давно начал набирать популярность Cypress - продукт для браузерного тестирования на JavaScript. К нам приедет его VP of Engineering и просто талантливый разработчик Глеб Бахмутов. Его воркшоп - отличная возможность не только попробовать инструмент на практике, но и узнать все нюансы использования на практике из первоисточника.

Ну и наконец, подкастер и один из лидеров QA сообщества Украины Сергей Пирогов проведёт воркшоп по организации успешной автоматизации тестирования в Java мире. Тут будет и API и UI и контракты между микросервисами. В общем, приходите и сами все увидите!

Места ещё есть, присоединяйтесь!

https://seleniumcamp.com/program/

Вот уже второй год я участвую в конференции DelEx, посвящённой автоматизации тестирования и DevOps направлению. Так совпало, что в это же время мы активно работаем над подготовкой программы нашей конференции Selenium Camp. Я общаюсь с людьми, которые не ходят по конференциям и слышу от них мнение, что ничего нового не появляется и все инструменты и подходы уже описаны.

Поэтому я решил подбить ТОП-6 интересных направлений в автоматизации тестирования, которые активно развиваются и стоят вашего внимания:

1. Impact analysis. Это достаточно старая идея, которая заключается в интеллектуальном подходе к выбору тестов для запуска, чтобы они быстрее давали результат и не теряли в покрытии. Подходы есть разные: основанные на рисках и приоритетах, базирующиеся на обратном графе покрытия кода, трассировке от тестов и т.д. Чем больше тестов пишется и чем чаще они запускаются, тем больше преимуществ может принести данный подход.

2. Scalable and reliable test infrastructure. Проблема актуальна практически для каждой команды. Не хочется ждать длинных запусков тестов и иметь нестабильности из-за инфраструктуры. Большой прорыв в этой области был достигнут благодаря контейнеризации и новые решения продолжают появляться, решая все больше проблем. Kubernetes, OpenShift и другие платформы позволяют строить гибкие и эффективные решения.

3. Smart reporting. Когда-то было нормальным просто показывать отчёт о том, сколько тестов прошло и с каким статусом. Сейчас этого явно недостаточно. Разрабатываются решения и подходы для сбора и агрегации логов, скриншотов, трассировки запросов, видео, состояния приложения и других показателей в единый отчёт. Такой отчет даёт полную информацию о контексте проблемы для ее быстрого анализа и принятия решения.

4. Self-healing tests. Очень перспективное направление, потому что очень много людей страдает от хрупкости UI тестов. Идея подхода лежит в том, чтобы автоматически исправлять локаторы и другие элементы хрупкости на базе анализа изменений верстки или изображений. Развиваются новые инструменты и сервисы, работающие не только на простых алгоритмах, но и задействующие ML и AI.

5. Test data management. Старое направление, которое заиграло новыми красками с появлением новых инструментов и подходов. Сюда входят практики генерации тестовых данных, безопасные преобразования живых данных в тестовые, версионирование слепков данных, использование immutable контейнеров с данными, управление данными непосредственно из теста. Очень интересная и обширная тема.

6. Everything as a code. В этом направлении я отмечу 2 очень свежих идеи test cases as a code и QA service mesh. Первая предполагает хранение полностью всей информации о тестах, включая ручные проверки и связывание с требованиями, в коде. Такой подход открывает много возможностей по автоматической генерации тестовых прогонов, сложной отчётности, работе с ветками, практикам ревью и т.д. Вторая идея предполагает вынесение в отдельный процесс всех функций, которые нужны автотестам. Этот процесс может быть запущен рядом с каждым сервисом системы и позволяет легко получить доступ к файловой системе, обмену сообщениями, внутреннему API и т.д. Таким образом, сами сервисы остаются чистыми, повышается гибкость и безопасность.

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

Вот слайды с моего доклада про использование чеклистов при DevOps трансформации и адаптации практик под новую культуру. По сравнению с прошлой редакцией добавил ссылочек на публичные чеклисты, с помощью которых можно провести разносторонний аудит в своей команде/проекте/компании. https://www.slideshare.net/mobile/alimenkou/devops-checklist-or-how-to-understand-where-is-your-team-in-devops-landscape-131209120

Уважаемые Java-господа, синьоры и синьорины, технические лиды и инженерные менеджеры, напоминаю вам, что у нас вовсю идёт подача докладов на конференцию JEEConf 2019. Мы всегда делали большой фокус на докладчиков из локального сообщества и верим в то, что самые интересные темы исходят из практического опыта, которого в Украине очень много.

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

- помощь опытного программного комитета в подготовке доклада;
- плотную работу с тренером по публичным выступлениям;
- доступ к накопленным за 8 лет советам и рекомендациям докладчикам;
- комфортную атмосферу на протяжение подготовки.

Присоединяйтесь к нашей команде докладчиков JEEConf 2019 и о вашем опыте узнают тысячи Java разработчиков!

https://jeeconf.com/speakers/

Я знаю достаточно много людей, которые видят и знают только 2 модели принятия решения: авторитарная и демократичная большинством голосов. На самом деле моделей гораздо больше и разные подходят лучше или хуже под определённый контекст. Вот тут описаны базовые варианты для старта погружения в эту тему: https://thedecider.app/?fbclid=IwAR3ksbsy5WQu97IefzStzVGgkwVl-Y-igR_b_Sz_bATC_8sRN6fRhIvd9XU

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

Любую обратную связь нужно использовать как шанс что-то улучшить. И речь не только о командной работе и эффективности. На уровне членов команды работают те же принципы. Каждый из них воспринимает реальность через призму своего сознания и жизненного опыта. Мы склонны не замечать свои проблемы и ошибки, потому что так проще. Мы часто не видим пути развития, потому что не понимаем чего не хватает. Взгляд со стороны работает гораздо лучше.

В связи с этим, я очень позитивно отношусь к практике регулярного проведения так называемого «360 ревью». Это практика, согласно которой члены команды могут дать обратную связь на своих коллег. Благодаря разным взглядам со стороны от коллег получается более целостная картина (мы у себя в команде переименовали в «359 ревью», потому что полную картину получить невозможно в принципе) и из неё можно извлечь больше пользы. Каждый член команды может запросить обратную связь от конкретных людей или же высказывается каждый о каждом. Это уже зависит от структуры и размера команды.

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

- структурировать свои мысли по собственным достижениям и слабым сторонам;
- сравнить свою «реальность» с реальностью команды;
- продумать и построить план развития на следующий период;
- адаптировать своё поведение и практики под ожидания команды для более слаженной и комфортной работы;
- собрать основания для пересмотра вознаграждения;
- избежать недопониманий и конфликтов с коллегами на ранней стадии;
- выявить свои слабые стороны и придумать решение;
- понять, что человек не вписывается в команду и только мешает ей.

Практика прямо безумно полезная. Но большинством воспринимается с насмешкой от слишком частого применения ее «для галочки» или ради процессных манипуляций. Если вы не понимаете описанных выше целей или не разделяете их, то толку будет мало. При правильном применении, она помогает расти людям в команде индивидуально и одновременно повышать эффективность командного взаимодействия.

Да прибудет с вами сила обратной связи! :)

Наступила весна и осталось совсем немного времени до завершения "слепого" периода регистрации на конференцию JEEConf 2019. Несмотря на то, что заявки на доклады еще принимаются, мы решили опубликовать первую партию докладчиков конференции. Что же ожидает наших Java господ в этом году?

- почитателей Spring экосистемы порадуют своими докладами "человек-Spring" Женя Борисов и один из основных разработчиков Spring Boot Stéphane Nicoll;

- новостями из мира Cloud Native поделятся опытный архитектор Orkhan Gasimov и автор книги "Cloud Native Java" Kenny Bastani;

- разнообразные подходы и опыт применения Kafka будут представлены в выступлениях Ricardo Ferreira, Guido Schmutz и Ильи Селезнева;

- практическим опытом применения serverless подходов в Java разработке поделятся Krzysztof Pawlowski, Simon Tabor и Ivar Grimstad;

- новости мира reactive представят Игорь Лозинский и Олег Докука;

- в гости приедут создатели и основные контрибьюторы таких инструментов как Maven, TestContainers, ArchUnit...

Ну и конечно же, множество докладов будет посвящено различным аспектам Kubernetes и микросервисной архитектуры.

Текущий этап регистрации закроется на этой неделе, осталось только 30 билетов по ранней цене.

https://jeeconf.com/speakers/

Современный разработчик... ;)

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

В случае остановки на интерактивном варианте, ему предлагаются такие правила:

- Все вопросы будут разделены по темам и "категориям сложности", выраженные числами. Например, Hibernate за 300 или Spring Boot за 700. Кандидат может выбирать из оставшихся вариантов следующий вопрос. Это дает ему возможность выстроить стратегию собеседования под себя.

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

- На разные позиции можно заранее объявлять ожидаемый от кандидата уровень, выраженный в количестве набранных баллов. Например, на синьора ожидается 5000 баллов за полтора часа.

- Чтобы сделать собеседование еще более интерактивным, кандидату предоставляется на выбор 4 карточки с опциями (пропустить вопрос, звонок другу, заглянуть в stack overflow, отвечает сам интервьювер). Кандидат может выбрать из этих карточек себе 3 и применить каждую из них не более одного раза за собеседование.

Мне кажется, приоткрытого занавеса хватит, чтобы оценить идею. Я бы очень хотел поучаствовать в таком собеседовании в роли кандидата, а вы? Нет скучным собеседованиям! ;)

Вчера я выступал на митапе компании Андерсен, где топил за гексагональную архитектуру и как тестировать современные Spring Boot микросервисы. Обсуждали очень много практических аспектов на живых примерах. Ребята записали отличное видео, поэтому есть возможность потратить 3 часа на самообразование в указанных темах. https://www.youtube.com/watch?v=0vrhZbGYp4k