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

Забавна формулировка, но в то же время я считаю, что это реально очень эффективный формат. Минимум теории, неформальная атмосфера, код, реальные проблемы, флипчарт для визуализации идей, продуктивная дискуссия... Пользы куда больше чем от семинаров. :)

Недавно на внутреннем Agile клубе подняли важную тему применения Definition of Done (критериев готовности). В индустрии это как подростковый секс - все о нем говорят, но ни у кого толком ничего не работает. Я на своём веку повидал немало списков, гордо озаглавленных Definition of Done. Рекордный из них насчитывал более 50 пунктов, собранных по всем закуткам интернета. Но парадокс заключается в том, что единицы команд делают формальную проверку указанных критериев и не принимают работу, если какой-то из них нарушен.

Я считаю, ситуацию можно сильно улучшить, модифицировав структуру списка и добавив каждому из критериев дополнительную информацию:

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

2. Как можно проверить соответствие данному критерию в конце итерации? Некоторые критерии необходимо проверять вручную, для других отлично работают автоматизированные метрики и код. Данный вопрос необходим, чтобы не было добавлено абстрактных критериев, которые никто по факту не проверяет и пользы от которых нет вовсе.

3. Кто может подтвердить выполнение критерия? Для некоторых критериев это может сделать только PO, для других отлично сработает роль QA инженера или техлида. Все сильно зависит от структуры команды и конкретного критерия. Ответ на этот вопрос нужен, чтобы определить ответственного за каждый критерий и тем самым ещё больше снизить количество «бесхозных» абстракций.

Проще всего начать улучшение своего Definition of Done с командной встречи, где команда сможет рассмотреть текущие критерии и попробовать ответить на указанные вопросы. Если ответа нет, то лучше критерий отложить и поработать над ним отдельно. Возможно, команда просто не готова по своему уровню зрелости или он ей не подходит по контексту.

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

Пришло время поделиться видео и слайдами своего доклада «Wasteful waste of why everything is so slow in development», который месяц назад занял первое место на конференции Selenium Camp 2019. В этом докладе я изложил своё видение концепции waste-кругов и их пагубного влияния на разработку. Вживую улучшенную версию этого доклада презентую на JEEConf 2019, а пока можно глянуть в записи и поразмыслить о извечной теме продуктивности разработки. :) https://www.youtube.com/watch?v=8vLrFH8mg2U https://www.slideshare.net/alimenkou/wastful-waste-or-why-everything-is-so-slow-in-development

Сегодня я приготовил для вас краткий отзыв об очередной прочитанной книге. Это небольшой по объёму, но очень крутой сборник практических советов по работе с требованиями в Agile окружении под названием «50 quick ideas to improve your User Stories».

Так получилось, что эту книгу я прочитал 2 раза: первый раз в далеком 2014 году сразу после ее издания, а второй раз через 5 лет. Первый раз мне она показалась слишком надуманной и очевидной, ведь я работал большей частью в небольших продуктовых командах с сильным продуктовым майндсетом. За эти 5 лет я много консультировал и окунался временами в жесткий энтерпрайз мир с его неэффективностью и искусственной сложностью. И вот там я по-настоящему оценил советы из данной книги, даже решил освежить воспоминания, прочитав ее ещё раз.

Книга очень хорошо структурирована и покрывает основные сложности работы с продуктовым бэклогом, начиная от формата User Story и выбора направления развития продукта, и заканчивая подходами к дроблению требований и продуктовым экспериментам вместе с командой разработки. Все по делу и основано на реалистичных примерах. Каждый совет из 50-ти оформлен на 3-4 страничках, поэтому не станет скучным чтивом. Такой подход также даёт возможность в любой момент остановиться и продолжить чтение позже.

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

Категорически рекомендую к прочтению. Это, пожалуй, одна из лучших книг по работе с требованиями в Agile мире. https://www.amazon.com/Fifty-Quick-Ideas-Improve-Stories-ebook/dp/B00OGT2U7M

AWS сервис S3 пополнился ещё одним типом хранилища для долгосрочных архивов с возможностью восстановления в течение 12 часов. Боль многих продуктов, хранящих данные много лет ради удовлетворения требований регуляторов, решена более чем полностью за сущие копейки. Ну и градация сервиса S3 отлично работает для распределения классов хранения данных в продукте любого домена. Огонь просто! https://aws.amazon.com/ru/s3/storage-classes/

Написал детальный обзор программы конференции JEEConf 2019. Самое время присоединиться к нам 26-27 апреля и подпитаться свежими идеями! https://xpinjection.com/articles/jeeconf-2019-program-for-java-developers/

Очень забавно, но именно IT специалисты могут много полезного почерпнуть из выборов в Украине. В этом канале мы не будем затрагивать политические баталии и топить за одного из кандидатов. Скорее рассмотрим несколько ошибок в предвыборной компании и проведем параллели с миром IT.

Сегодня речь пойдет о таком важном аспекте работы с заказчиком как управление ожиданиями (customer expecations management). Очень часто я сталкиваюсь с проблемой в командах и компаниях, когда вроде хотели как лучше и вложили немало усилий, но результат вызвал только критику и проблемы. В результате происходит глубокое разочарование как со стороны команды так и со стороны заказчика.

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

- команда разработки решает продумать и реализовать крутой UI/UX в энтерпрайз системе (ведь современная же система), кидает на это много усилий, а в итоге заказчик разочарован, потому что ему было на порядок важнее получить больше функциональности хотя бы в базовом варианте и конечные пользователи не готовы к таким улучшениям;
- команда разработки принимает решение в первую очередь реализовать самый сложный и рискованный сценарий в системе и продемонстрировать его как ценный MVP с минимальным UI, а в итоге разгорается скандал с кучей эскалаций со стороны заказчика;
- команда разработки реализует ту функциональность, которая понятна им на текущий момент и показывает хороший прогресс по скорости работы, но наступает важная для заказчика дата и он интересуется только наличием ключевых сценариев, отбрасывая все остальное как неважное.

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

Казалось бы, при чем тут выборы? А вот при чем! Ты можешь сделать со своей точки зрения (да и с объективной точки зрения тоже) очень многое для страны, больше чем смог кто-то другой до тебя. Но если при этом ты не обращал внимания на конкретные ожидания своих избирателей и их формулировки, то все это может остаться незамеченным и неоцененным. А в результате они будут считать тебя плохим и не станут за тебя голосовать...

Кто бывал на моих технических тренингах или докладах, знает о моей приверженности к DBUnit для тестов на уровне БД. Но так как DBUnit очень стар и имеет не сильно современный API, то я предпочитаю пользоваться удобными современными обертками. Много лет это был Unitils, который служил верой и правдой пока его не перестали поддерживать. На смену ему пришёл database-rider, который я использую постоянно.

И вот оказалось, что в моем любимом database-rider нет поддержки MS SQL Server. Оно и понятно почему, ведь в этой БД все сделано «не как у людей» и есть куча исключений из общепринятых в мире RDBMS подходов. Что делают в мире open source, если чего-то не хватает? Конечно, ноют! Ну или создают ишью и слёзно просят добавить побыстрее поддержку?

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

Итак, встречаем свежую версию database-rider с поддержкой MS SQL Server! Ну а я доволен, что наконец сложились звезды начать контрибьютить в open source. https://github.com/database-rider/database-rider/releases/tag/1.5.3

Появилась новость, которая стоит того, чтобы ее распространить как можно шире: взломали Docker Hub. В итоге, «утекли» данные почти 200 тысяч пользователей (логины, пароли, токены). Особенно стоит беспокоиться тем, кто хранил какие-то токены или данные доступа в докер-образах!

Инструкции по дальнейшим действиям:
https://news.ycombinator.com/item?id=19763413

Оригинальное письмо:
https://cdn.changelog.com/uploads/news_items/AJOA/large.png?v=63723566056

Уже прошла неделя с конференции JEEConf 2019 и мы поэтапно публикуем записи докладов. Ведь знания в современном IT так быстро устаревают, что нет смысла задерживать публикацию. На текущем этапе видео все ещё доступно только по ссылке. Удачного просмотра, набирайтесь знаний! https://www.youtube.com/playlist?list=PLYj3Bx1JM6Y7nQ6WW9uPJDvr1e_mryjZu

В этом году я снова оставил количество выступлений на конференциях минимальным и выбрал только те из них, которые действительно не хотел пропускать. В весеннем сезоне обе из них в Минске. DelEx 2019 прошёл в феврале, а Voxxed Days Minsk 2019 запланирован на 24-25 мая. Я очень рад, что после многих неудачных попыток в Беларуси начали развиваться классные конференции для разработчиков. Программа получилась достойной и Минск соберёт команду крутых докладчиков международного уровня.

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

https://voxxeddays.com/minsk/

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

А что же тогда происходило под зонтиком DevOps все эти годы? Во-первых, сильно развился инструментарий, который ооочень упрощает процедуру поставки сервисов на продакшен окружение через все промежуточные этапы.

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

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

В-четвертых, вся инфраструктура разработки (CI/CD, хранилища артефактов, метрики, логи, трейсы и т.д.) все больше уходит к инфраструктурным инженерам и все меньше разработчиков лезут в эту область или делают что-то сами.

Именно поэтому на большинстве DevOps конференций мы слышим доклады на темы как круто применили тул X для такой-то задачи, как здорово развернули окружения в AWS и решили проблемы, как построили масштабируемый CI/CD для большой компании, как красиво организовали мониторинг для всей инфраструктуры. И мало докладов про то, как ежедневная совместная работа разработчиков, инфраструктурных инженеров и других членов команды помогла команде стать быстрее и делать работу качественнее.

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

К сожалению, пока так, но надежда не покидает...

Я не знаю, смотрели ли вы на альтернативные платформы для разработки микросервисов на Java, но недавно RedHat родил ещё одну с прицелом на скорость, экономию памяти и места, то есть оптимизированную под запуск в контейнерах - Quarkus. Демки смотряться очень интересно, модный GraalVM под капотом, запуск за доли секунды и упаковка только полезного из всех зависимостей.

Мне кажется, что Quarkus может идеально подойти для развивающегося мира Serverless, ведь реализация лямбд на Java оставляет желать лучшего с точки зрения скорости и потребления ресурсов. Будем следить за развитием событий!

https://quarkus.io

Если кто-то искал что посмотреть из технологических докладов на выходных, то ловите видео с прошедшей недавно конференции DevOps Days Kyiv 2019. Не все доклады были огонь, по пару-тройку интересных каждый для себя точно найдёт.

https://m.youtube.com/playlist?list=PL_O8YSX8ckffzeV9mIBUQniaKFxGnPdYh

Я забыл поделиться с вами ещё одной важной информацией. Лучше поздно чем никогда. С конференции Voxxed Days Minsk 2019 ведется прямая трансляция со всех залов. Ниже ссылочки.

Зал 1: https://m.youtube.com/watch?v=4_ndWRD1RSM

Зал 2: https://m.youtube.com/watch?v=ewzmSZH47Qk

Зал 3: https://m.youtube.com/watch?v=UvL1-s_1MUw

Зал 4: https://m.youtube.com/watch?v=AIBp54H0Y0Y

Через 2 часа в главном зале я буду выступать с закрывающим кейноутом.

У меня для вас есть новости. Похоже, со второй половины августа я снова буду доступен для долгосрочного hands-on консалтинга на ~70% загрузки в связи с завершением этапа работ с предыдущим клиентом.

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

Также, мы предоставляем следующие виды услуг:

- архитектурные, технологические и процессные аудиты;
- организация и поддержка трансформаций в компании:
  * переход к Continuous Delivery;
  * построение эффективного процесса разработки;
  * внедрение полноценных QA процессов;
  * миграция к микросервисной архитектуре;
  * построение DevOps культуры;
  * внедрение Agile подходов.
- разнообразные технологические тренинги:
  * по Java разработке (Spring Boot, Java 8-12, Hibernate/JPA);
  * архитектурным темам (микросервисы, распределенные системы, high load/availability);
  * QA процессам и практикам тестирования;
  * инженерным практикам (TDD, Code Review, автоматизация тестирования, CI/CD;
  * Agile подходам (Scrum, Kanban, масштабирование разработки);
  * современным менеджерским практикам.
- консультации для принятия эффективных решений;
- выступления для сотрудников с целью мотивации, распространения новых идей и вовлечения в процессы развития компании.

Обращайтесь, будем рады сотрудничеству!

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

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

В результате страдают все:

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

Есть большое паразитное направление, которое сильно развивает предвзятость. Это политика. Практически 100% людей видят политические события через призму СМИ или других каналов информации, действуют в основном эмоционально и быстро втягиваются в отстаивание своей точки зрения, манипулируя малым числом фактов. Дальше все происходит под копирку - они формируют социальный круг, который разделяет их мнение, фильтруют подтверждающие свое мнение "факты" и с усердием борются за каждую возможность доказать свою правоту.

А потом предвзятость как паразит начинает распространяться на другие области жизни и работы. В результате получаются "эксперты во всех вопросах" и ярые "отстаиватели истины". Будьте осторожны, эта гадость затягивает незаметно... :)

Меньше месяца назад прошла масштабная конференция KubeCon в Барселоне. Для всех, кто не смог присутствовать лично, но интересуется вопросами инфраструктуры, я бы рекомендовал почитать отчёты и конечно же выбрать себе видео докладов для детального изучения.

Основные тренды можно уловить из вот этого отчета одного из участников: https://medium.com/@armab/notes-on-kubecon-cloudnativecon-eu-barcelona-19-ec7b3d4213d4, а также краткого обзора на Facebook от Владимира Цапа: https://m.facebook.com/volodymyr.tsap/posts/2462105400519964.

Уже давно доступны видеозаписи всех докладов (342 видео, между прочим): https://www.youtube.com/playlist?list=PLj6h78yzYM2PpmMAnvpvsnR4c27wJePh3. Я уже отобрал штук 15 для просмотра, чего и вам советую! :)

Наступили очередные выходные и у многих появится время для самообразования. Поэтому самое время поделиться видеозаписями докладов с конференции Spring I/O 2019. В этом году популярные темы включают безопасность, инфраструктурную интеграцию со Spring Cloud, реактивщина. Хорошего просмотра!

https://www.youtube.com/playlist?list=PLe6FX2SlkJdTlXfwer8JB-WGm-TEyIB2k

Много разработчиков мучается с постоянным устареванием зависимостей в своих приложениях или сервисах. Чем больше библиотек и фреймворков ты подключил, тем тяжелее становится этот процесс. На днях я встретил в одном из каналов ссылку на очень интересный инструмент: https://dependabot.com/. Бот пробегается периодически по вашим зависимостям и в случае нахождения обновлений сам делает pull request в GitHub. Отличный пример автоматизации рутинной задачи, недаром в мае этого года GitHub его прикупил и сделал бесплатным для своих пользователей.