Сейчас стало модно заводить каналы в Телеграмм и писать туда свои мысли, новости, анонсы. Тут я буду писать про Java, Agile, процессы разработки, инженерные практики, архитектуру, DevOps, QA, автоматизацию и другие темы из мира разработки. Мысли мои собственные и никак не связаны с моими работодателями. Ну или почти не связаны. ;)

Разработчики все время ноют, что их тесты выполняются долго и результаты теряют актуальность. В результате, не получается запускать их на каждое изменение и ситуация ещё усугубляется. А я в таких случаях каждый раз вспоминаю этот доклад с XP Days Ukraine далекого 2012 года как чуваки оптимизировали свои сборки до упора и им все казалось медленно. С тех пор появилось ещё 100500 способов и инструментов для ускорения тестов, но большинству просто лень сесть и начать что-то делать. ;) https://xpdays.com.ua/archive/xp-days-ukraine-2012/materials/build/

Вот вам в качестве примера статья от Влада «Хибернейтовича» на тему ускорения DB тестов. https://vladmihalcea.com/how-to-run-database-integration-tests-20-times-faster/

В самом конце мая проходила конференция Spring I/O 2018, собравшая практически весь состав ключевых контрибьюторов Spring экосистемы. Я, к сожалению, поехать не смог, но уже с удовольствием смотрю опубликованные видео. https://www.youtube.com/playlist?list=PLe6FX2SlkJdRCNFdhWgpRmJybXafo-Uqk

Я часто вспоминаю свой первый день в ЕПАМ, когда мне нужно было настроить рабочий календарь в аутлуке. В тот момент я не мог понять зачем он нужен, до этого я больше 10 лет работал без подобного инструмента. Но очень быстро стало понятно для чего в большой компании этот адский инструмент - чтобы люди из разных уголков могли втягивать тебя в бесконечные митинги и им это было сделать просто.

Скоро мой календарь наполнился до такой степени, что в течение дня не было даже перерыва «на пописять». Митинг, за ним митинг, за которым ещё митинг и после него митинг. Ещё через какое-то время я начал подстраиваться под правила игры:

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

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

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

Зато теперь реже можно будет поиграть в conference call bingo. :)

Скоро начнётся горячий конференционный IT сезон. Поэтому самое время строить планы, выбирать мероприятия и покупать билеты. Я буду время от времени делать анонсы тех конференций, которые я собираюсь посетить с докладом или как участник.

Сегодня мы поговорим о сентябрьских QA Fest (http://qafest.com) и Agile Rocks (http://www.agilerockconference.com). Обе конференции пройдут 21-22 сентября. Первая из них уже несколько лет собирает тестировщиков и всех небезразличных к обеспечению качества в Киеве.

QA Fest значительно вырос и в прошлом году число участников приблизилось к 1000. Я каждый год там выступаю и этот не станет исключением. Последние два года мой доклад становился лучшим по итогам голосования участников. Как тут не выступать? ;) В этом году я будут рассказывать про то, как готовить тестовые данные. Доклад на эту тему был на Selenium Camp 2018, я его немного доработаю согласно полученной обратной связи.

Agile Rocks - совершенно новая конференция, которая пришла на смену «сдувшейся» AgileEE. Я обычно скептически отношусь к чисто Agile конференциям, но тут вроде должно быть интересно. Собирается много достаточно крутых спикеров. Я решил поделиться своими наблюдениями за последние 10 лет внедрения Agile в компаниях Украины: какие практики не работают, какие анти-паттерны и ловушки поджидают команды, что больше всего болит и почему. Надеюсь, доклад породит много интересных дискуссий. :)

Один из самых полезных инструментов в продуктовой разработке для уменьшения количества бесполезной работы и сокращения митингов - это Definition of Ready (DoR). Требования очень часто бывают не готовы к разработке вовремя по причине распыления усилий ответственных за их подготовку. Обычно за требования к продукту отвечает Product Owner или его замена, в более редких случаях бизнес аналитики. Без конкретных критериев готовности требований на планировании у команды остаются открытые вопросы, возникают недопонимания, отсутствует понимание бизнес-целей и бизнес-процессов. И это очень сильно влияет на качество и результаты работы команды. Поэтому возьмите на заметку, если ещё не используете. https://m.habr.com/post/417101/

Я считаю формат ретроспективы с тремя колонками «что было хорошо», «что было плохо» и «что можно улучшить» самым ужасным форматом. Практически везде, где я его встречал, ретроспектива делалась для галочки. Доска фотографировалась и все расходились с чувством выполненного долга.

На мой взгляд, этому есть три причины:

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

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

- Формат настраивает на поверхностный уровень разбора проблем. Что было плохо? Давайте так больше не делать! Тут помогает root cause analysis и групповая brainstorm работа.

Почему же данный формат так часто используется? Потому что он простой, не требует подготовки и позволяет провести ретро «для галочки». За свежими идеями своих ретроспектив советую обращаться в старинную книгу Agile Retrospectives или в более современные практические издания. Вот вам ссылкочка на всю пачку, не благодарите. :)

https://leanpub.com/b/agileretrospectives#bundle-page-agile-retrospective-kickstarter

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

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

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

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

https://ru.m.wikipedia.org/wiki/Гэмба

Шёл 2018 год... В Jenkins добавили поддержку пайплайнов с описанием в YAML. Совершенно бесполезная фича, а YAML для этой цели подходит как козе баян. Лучше бы за столько лет remote run запилили из IDE. А вы что думаете? Голосуем! https://jenkins.io/blog/2018/07/17/simple-pull-request-plugin/

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

- вводная часть минут на 10-15 на знакомство и разговор о предыдущем опыте, чтобы понять как человек общается и убедиться что он не имеет явных причин не вписаться в конкретную команду, компанию, культуру;
- минут 30-45 на предметные вопросы из основного направления вакансии, старт всегда с практического простого кейса с углублением для прощупывания уровня знаний и опыта;
- минут 15-30 на понимание уровня культуры разработки, следования инженерным практикам, самодисциплину, развитие и прочие важные факторы;
- в случае успеха и оставшихся сомнений, решение небольшой реалистичной задачи в паре с кандидатом (парное программирование, тестовая стратегия или улучшения процесса разработки), на что уходит 60-90 минут.

Собеседование может закончится на любом этапе, чтобы сэкономить время и мне и кандидату.

А вот вам ещё свежая статейка на тему плохих собеседований: https://m.habr.com/post/417431/#habracut

Для всех интересующихся автоматизацией тестирования и тематикой TestOps уже доступны видео с митапа в Минске. https://www.youtube.com/playlist?list=PLYinOsby80NlbBlgoCncOLQQl22KtCEDK

Как известно, в этом году вышло третье издание «маленькой библии» любого Java разработчика от Джоша Блоха. Речь о книге «Effective Java». А сегодня я наткнулся на презентацию Джоша на основе новинок в этом издании. Для визуалов будет полезно, но книгу все равно стоит прочитать. ;) http://www.infoq.com/presentations/effective-java-third-edition

Пока в Jenkins релизили в alpha «суперполезный» YAML, у TeamCity вышел очередной релиз с массой полезных фич. https://habr.com/post/416999/

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

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

Чтобы как-то улучшить ситуацию, мы решили провести новый семинар в формате Deep Dive на тему разработки тестовой стратегии. Первый пройдёт в субботу 28 июля, как обычно утром продолжительностью 4 часа. Мест не так и много, присоединяйтесь! https://xpinjection.com/trainings/deep-dive-testing-strategy/

Очередная новость из серии «как хорошо все начиналось в мире NoSQL»: MongoDB выпустили свежую версию с поддержкой ACID транзакций. С кучей ограничений, уверен что с множеством багов, но с большим стремлением стать чуток более похожими на RDBMS и тем самым лучше продаваться на рынке энтерпрайза. Случай не единичный: Cassandra из кожи вон лезет чтобы сделать свой CQL по фичам как можно более похожим на родной для большинства разработчиков SQL. Там же с каждой версией расширяется поддержка индексов, которые по умолчанию зло для такого типа хранилищ. В общем, прошло много лет и бабло уверенно побеждает NoSQL. :( https://www.infoq.com/news/2018/07/MongoDB-4.0-Released

Продолжает развиваться Jenkins X - свежее решение для CI/CD для тех, кто использует Kubernetes для своей инфраструктуры. Как по мне, направление очень правильное и когда допилится, то однозначно станет отличным решением для многих команд. Я даже знаю уже пару команд в Украине, активно внедряющих Jenkins X у себя. https://jenkins.io/blog/2018/07/19/jenkins-x-accelerate/

А вот человек сделал конспект нашего доклада по Hibernate с дополнениями из других источников. Хорошая выжимка получилась! https://m.habr.com/post/416851/#habracut

А вот вам напоследок сегодня перевод серии статей со сравнением RabbitMQ и Kafka. Хайп вокруг Kafka уже почти на пике, но RabbitMQ по-прежнему полезен для многих типов систем. https://habr.com/post/416629/