Сейчас даже тяжело поверить, что еще лет 5 назад мы жили без контейнеров и Docker. Сейчас их используют разработчики для своих нужд повсеместно. В том числе и для автоматизации тестирования. Selenoid изначально сильно упростил управление браузерами и тестовой инфраструктурой для тестирования с помощью WebDriver. Теперь ребята пошли дальше и сделали следующий шаг в упрощении масштабирования, развертывания и поддержки контейнерной тестовой инфраструктуры - Moon или "Selenoid на K8S стероидах". И пока даже бесплатно лицензии дарят на полгода. https://medium.com/@aandryashin/selenium-back-to-the-moon-6ea73f1657cc

Я обещал анонсировать время от времени конференции, в которых я принимаю участие как докладчик, организатор или участник. И вот, совершенно неожиданно для себя, я впервые иду на IT Weekend Ukraine. Конференция пройдёт 8 сентября в Киеве и соберёт смешанную тусовку на темы AI, ML, Serverless, VR/AR и т.д. Почему я не посещал данное мероприятие раньше? Потому что я не очень доверяю конференциям, которые организуют крупные компании, да и тематика далека от сферы моих интересов. Но в этом году меня подкупили персональным приглашением и было очень невежливо отказать. :) Так что увидимся на IT Weekend Ukraine! https://itweekend.events/event/it-weekend-ukraine-2018/

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

Со временем я убедился, что это не очень хороший вариант. Гораздо лучше работает вариант с итерациями, начинающимся в середине недели. И вот список причин:

- в середине недели люди реже берут day off или устраивают сокращённый день (особенно летом), поэтому с большей вероятностью в полном составе команда будет на важных активностях по итерации (планирование, демо, ретро);
- планирование в понедельник утром после выходных обычно начинается поздно и люди входят в рабочий ритм неспешно, в середине недели такая проблема наблюдается куда реже;
- после завершения итерации, в идеале, стоит задеплоить последнюю версию системы на живые окружения, а в пятницу это делать крайне не рекомендуется;
- ретроспектива в пятницу вечером по умолчанию не настроена на конструктив;
- работа без явной передышки между итерациями больше настраивает на ритм continuous delivery с последующей возможностью перехода на потоковые подходы к разработке;
- в случае форс-мажора люди сильно не любят оставаться вечером в пятницу в офисе, потому что это ломает их планы на вечерний досуг и выходные;
- удобно назначить груминги на «середину» итерации, потому что она попадает на середину рабочей недели;
- меньше проявляется «синдром студента».

Очень рекомендую попробовать такой подход!

Так как это мой персональный канал, то я надеюсь, что не будет сильно наглым запостить объявление о наборе людей ко мне в команду. :)

Итак, к себе в команду на масштабный healthcare проект активно ищу таланты:

- Senior Java Developer на микросервисную архитектуру, Spring Boot, Docker-ы и это вот все.
- QA Automation Lead чтобы автоматизация тестирования процветала еще больше и по всем направлениям.
- System Analyst для сложного системного анализа, внешних интеграций и поддержания консистентности функциональности платформы.
- Business Analyst, который магически превращает пачку документации в User Stories и умеет находить общий язык с командой заказчиков.

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

Йуху! Нас уже 1000 в этом канале! Первый шаг в амбициозном плане собрать 10К подписчиков к 2024 году сделан. :) Но вы можете помочь ускориться, поделившись ссылочкой на канал с коллегами и знакомыми.

А еще сегодня вроде как празднуется День Программиста. Поздравляю всех причастных! Желаю надежных коммитов, быстрых ревью, классных продуктов, интересных проектов, приятных заказчиков, новых технологий побольше, ну и конечно же всегда соблюдать work/life баланс. С праздником!

Я уверен, что у многих из вас есть крутые идеи из мира медиа, но обычно у вас не хватало смелости, времени или единомышленников, чтобы воплотить их в жизнь.

13-14 октября у вас будет замечательный шанс реализовать свои идеи и посоревноваться с другими командами за призовой фонд в размере $5000. Наши друзья из Megogo организуют в UNIT.City крутой хакатон Megogo Media Hackathon 2018, на котором любой сможет попробовать превратить эфемерную идею в реальный проект.

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

Участники могут выбрать одно из 5 направлений:
▪ Big Screen Solutions — все для больших экранов;
▪ Data Driven Media — Big Data и Machine Learning;
▪ Future & Innovation — инновации в медиа;
▪ Interactive Content & Services — интерактивный контент и все, что с этим связано;
▪ Mobile Media — решения для самой популярной медийной платформы.

Участие бесплатное. Все подробности о хакатоне, регистрация и правила участия можно найти на сайте: https://hackathon.media/.

Если бы давали выбор, кому из мира IT можно было бы смачно врезать по лицу, то я бы выбрал UX дизайнера и главного по качеству по JIRA. Это самый ужасный в плане качества и UX инструмент для разработки в 2018 году. Просто на уровне дна!

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

- нельзя для берндаун чарта использовать фильтр, чтобы можно было отдельно глянуть на прогресс по бэкенду и фронтенду в итерации;
- в JQL не работает поиск по тексту с [], эскейп не спасает, поэтому фильтр типа [FE] в названии таски сделать нельзя;
- нельзя сделать запрос на полное совпадение названия ишью;
- нельзя убрать неиспользуемый статус с ишью воркфлоу;
- не работает поиск summary ~ BE, причём именно BE, все остальные сочетания работают...

Причём часть из этого является регрессией с определенной версии, часть запрашивается сообществом уже лет 5 и собрало кучу голосов.

Про UX вообще отдельная история. Половина действий в настройке не то чтобы ненатуральна, а вообще контринтуитивна.

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

Не так давно я писал, что люблю время от времени ходить на собеседования. И вот я столкнулся с таким собеседованиям, о каких я до этого только читал и не мог представить, что такая дичь ещё существует где-то на просторах нашего IT. Чтобы было веселее, я опишу происходившее в виде «вредных советов».

Итак, сначала для рекрутера:

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

Теперь для собеседующих:

- как CTO, только вы можете знать единственное верное определение микросервиса, поэтому добейтесь от кандидата его озвучивания;
- у вас был негативный опыт с Go и вы считаете на нем можно писать только hello world, убеждайте кандидата что это единственный правильный ответ и не принимайте возражений;
- отметьте явно, что кандидат неверно понимает термин digital transformation, потому что в других компаниях его делают неправильно;
- даже если вы выдумали для себя новый тип NoSQL баз данных (tree storage), явно продемонстрируйте неудовольствие от того, что кандидат его не назвал;
- если вы закончили свою часть вопросов, то смело открывайте ноутбук и погружайтесь в свои дела;
- про опыт кандидата не задавайте вопросов вовсе, зачем вам эта ненужная информация;
- на середине вопроса коллеги оторвитесь от ноутбука и сообщите, что у вас уже следующая встреча началась и вам пора бежать;
- ну и поддержите рекрутера в желании не утруждать себя обратной связью!

Следуйте стабильно всем этим советам и вас даже могут номинировать на обзор в свежем номере «прекрасного IT». ;)

Вот наглядный пример как не сидеть и ныть, что тесты занимают много времени, а взять и сделать реальную оптимизацию для одного из повторяющихся шагов - авторизации: https://medium.com/@rosolko/boost-you-autotests-with-fast-authorization-b3eee52ecc19.

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

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

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

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

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

MVP подход и TDD мировоззрение рулят! Когда прежде чем взяться за дорогое решение ты делаешь MVP и тесты по всем ключевым аспектам, то теоретическое решение адаптируется под реалии максимально дёшево и эффективно.

Ну и наконец, no blaming культура позволят сэкономить просто уйму времени и нервов. :)

Сегодня и завтра буду параллельно участвовать сразу в двух конференциях: QA Fest и Agile Rocks. На Agile Rocks у меня будет бомбический, поджигающий пуканы коучей и тренеров, доклад про антипаттерны Agile, от которых до сих пор сильно страдают компании в Украине. А на QA Fest я расскажу как грамотно управлять тестовыми данными, чтобы автотесты были надежными, быстрыми и стабильными. Приходите!

А вот вам свежих слайдиков с первого доклада про Agile антипаттерны. Хорошего настроения! https://www.slideshare.net/alimenkou/agile-antipatterns-review-after-10-years-of-practice

Сегодня самым ярким впечатлением дня на конференции Agile Rocks для меня стал доклад одного из старых евангелистов Agile, который стоял у основ развития гибких методологий в СНГ. После многих лет коучинга, тренингов, консультаций и прочих активностей для других бизнесов он решил основать свою продуктовую компанию в UK. И основной вызов в том, что когда это твой продукт, твои деньги, твои риски, то собственные советы из прошлого перестают работать или ты просто перестаёшь их слышать в своей голове.

Это очень интересный момент, потому что в докладе были все анти-паттерны:

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

Лично мои выводы в стиле Тони Роббинса:

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

Доклад сумбурный, но полезный выводами.

А вот слайды доклада про управление тестовыми данными с #qafest. Тони теперь преследует меня в каждом докладе. :) https://www.slideshare.net/alimenkou/bro-manage-test-data-like-a-pro-qa-fest-2018/

А если кому-то не спится и хочется глянуть бодрящих и увлекательных Agile историй, то могу поделиться парочкой видеозаписей докладов, которые понравились мне на конференции Agile Rocks. Великолепные кейноуты: есть чему поучиться и много личных выводов!

https://www.facebook.com/agilerockconf/videos/1704147163045846/

https://www.facebook.com/agilerockconf/videos/1862055803909597/

Осталось чуть больше 2 недель до закрытия приема докладов на XP Days Ukraine 2018. Если вам есть чем поделиться на тему архитектуры, DevOps или инженерных практик, то торопитесь подать заявку на доклад! https://xpdays.com.ua/speakers/

Вчера выступал на онлайн Java конференции с темой про гексагональную архитектуру. Уже готовлю вторую версию с реалистичными примерами из мира Domain-Driven Design. А пока слайды презентации:  https://www.slideshare.net/alimenkou/hexagonal-architecture-with-spring-boot-116495140

Вчера зарелизилась Java 11, которая является первым LTS релизом со времен 8-ки. Фичей, которые кардинально меняют жизнь обычного Java разработчика там нет, но все же важных обновлений и исправлений достаточно много. Возможно люди начнут массово мигрировать на эту версию, чтобы захватить все приятные плюшки из 9-ки и 10-ки, ведь по статистике до сих пор большинство все еще пользуется Java 8. https://habr.com/company/jugru/blog/424543/