Йуухуу! Выложили видео моего доклада про Agile антипаттерны с конференции Agile Rock Conference. Веселого вам просмотра! ;) https://www.youtube.com/watch?v=XTsf7quT2nM

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

По ретроспективам все достаточно просто и я всем рекомендую вот этот пакет книжек: https://leanpub.com/b/agileretrospectives.

По практическому применению Канбан уже сложнее. С одной стороны, нужно проникнуться философией Lean и организации потока, а с другой, нужны примеры применения на практике в IT. Вот что бы я рекомендовал для начала:

1. «Цель» и «Цель 2» для поднятия мотивации. Формат производственного романа легко читается и захватывает.
2. В продолжение можно добавить ещё «Проект Феникс» в том же жанре.
3. Дальше можно почитать книжек из серии «The Toyota Way» и «Lean Thinking».
4. После этого можно уже переходить в IT. Начать стоит с классики «Implementing Lean Software Development», хотя я слышал мнения об устаревании идей в книге.
5. Дальше что-то простенькое и веселое про применение Kanban как «Kanban and Scrum: Making the Most of Both» и «Lean from trenches».
6. Потом среднего уровня «Kanban: Successful Evolutionary Change for Your Technology Business» и «Real-World Kanban: Do Less, Accomplish More with Lean Thinking».
7. Ну а тут пути расходятся для углубляющихся в практики или адаптирующих Kanban на конкретные типы компаний/проектов/команд.

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

По остальным вопросам вроде все понятно. ;)

Для тех, кто решился уже мигрировать свой код на Java 11 с 8-ки, есть хорошая отправная точка в виде обзорной статьи с ссылками на детальные описания по каждому из шагов миграции. Мы планируем переход уже в начале 2019. https://blog.codefx.org/java/java-11-migration-guide/

ВАУ! Мартин Фаулер выпустил второе издание легендарной книги про рефакторинг. В обзоре пишет, что за эти годы пересмотрел своё отношение практически ко всем практикам и собрал кучу новых. Не терпится прочитать, эта книга 100% стоит потраченного времени. https://martinfowler.com/articles/refactoring-2nd-ed.html#gone-to-the-printers

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

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

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

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

Я уже публиковал видео кейноут докладов с конференции Agile Rock Conference, которые меня зацепили содержанием и подачей. Организаторы уже опубликовали остальные видео и я после просмотра выбрал ещё несколько для вас.

Наступают выходные и можно будет найти часик-другой на самообразование.

Первой рекомендацией стал доклад Артёма Быковца про Agile трансформацию вне IT. Очень много жизненных историй и моментов на реальном опыте. Единственная ложка дёгтя в непонятном желании везде притягивать Scrum. https://youtu.be/C_lcC7QjV-A

Второй рекомендацией идёт доклад Анны Обуховой про выгорание команд и конкретных людей, а также способах борьбы с этим выгоранием. Много коучинговых подходов и психологии. https://youtu.be/_lZ-5Nzl6KU

Ну а последним на сегодня будет доклад Натальи Трениной про людей, которые ищут оправдания чтобы не меняться и что с этим делать. Доклад наполнен юмором, но при этом соблюдается баланс полезняшек. https://youtu.be/L7EE0TYBK9Q

Напоследок совет от Тони: многие доклады весьма комфортно смотреть на скорости 1.3-1.5 совершенно без потерь в усвоении материала. Этот совет поможет сэкономить кучу времени.

Удачного просмотра!

Недавно на одной встрече зашла речь о том, что такое Spike и чем отличается от Proof of Concept или, в простонародье, PoC. Это совершенно разные по целям и фокусу активности, поэтому стоит провести небольшой ликбез.

PoC нужен для того, чтобы проверить определенную идею на состоятельность или попробовать рабочую гипотезу на практике. Целью является минимально возможная реализация, которая способна продемонстрировать идею и дать возможность оценить ее актуальность. Чаще всего PoC применяется со стороны бизнеса, чтобы не тратить время на полноценную реализацию идей, которые ещё не опробованы и в которых нет уверенности.

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

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

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

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

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

Сегодня коротенький пост на пожаловаться и посмеяться. Я уже писал, что мы ищем себе в команду опытного Java разработчика. Так вот, подключили мы к этому делу несколько рекрутерских компаний и за неделю упало из 6 кандидатов 4 с ожиданиями по зарплате $8K. Вы не ослышались и зрение вас не подводит: это именно 8 ТЫСЯЧ ДОЛЛАРОВ США в ожиданиях зарплаты Java разработчика!

Что же должен делать Java разработчик за такие деньги? Мы сегодня нашли единственный логически объяснимый вариант и я поделюсь им с вами. Первый день после найма, полчаса после получения ноутбука и ароматного кофе в компании новых коллег:

- Коллеги, а есть ли у вас список текущих проблем в продукте на стороне бэкенда?
- Да, есть, мы его ведём в техническом бэклоге...
- Мне нужно два часа и чтобы никто не мешал!

2 часа спустя:

- Все, я закрыл последнюю задачу из технического бэклога. Все тесты зеленые, билд собран, энв обновлён!
- О_о! Но у нас не было тестов!
- Дайте мне ещё один час...

Вот как-то так. Другого варианта в голову не приходит. Удачных вам наймов!

Только что подсмотрел новость в DevOps канале о том, что AWS Lambda теперь может выполняться до 15 минут вместо 5 минут. О чем это говорит? Serverless наступает по всем фронтам и предлагает все больше возможностей сделать что-то в виде функций из коробки. Это тренд уровня облаков, в которые я помню лет 10 назад мало кто верил в таком масштабе, а сегодня это стандарт де-факто. Интересное будущее нас ожидает. :) https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/

Мы уже активно публикуем отобранные доклады в программу XP Days Ukraine 2018. В этом году в топовых темах будут:

- Serverless;
- Cloud-native и практики использования платформ оркестрации контейнеров;
- инженерные практики (куда же без них);
- работа с большими data streams;
- современные архитектурные подходы и практики;
- DevOps культура и популярные инструменты для ее поддержки.

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

Половина билетов уже продана, но еще осталось чуток по цене ранней регистрации. Присоединяйтесь!

https://xpdays.com.ua/program/

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

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

Я специально выбрал более общее слово контекст, потому что для разных команд, проектов, компаний и продуктов он может означать разное. Где-то речь о культуре и ценностях, где-то контекст подразумевает определенные правила и их восприятие кандидатом, а где-то наличие определённого уровня зрелости.

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

Есть примеры не такие очевидные. Говнокодят ребята очередной стартап и фокус у них сугубо на скорость выпуска новых фичей. А тут приходит кандидат с чувством прекрасного, 100% покрытием кода и всеми архитектурными заморочками... Он явно выпадает из контекста и способен в некоторых случаях чуть ли не полностью остановить разработку. Или, например, на проект ищется 17-й гребец второго отсека на 4-м ряду, а приходит кандидат с продуктовым майндсетом и привыкший работать по короткому циклу идея-mvp-измерения-адаптация. Явно этот контекст не для него, хоть по техническим навыкам он может идеально подходить.

Так вот, за 14 лет в индустрии я чётко усвоил урок: нанимаемый человек должен обязательно попадать в контекст. Никаких компромиссов! Либо да либо нет. Нарушение этого правила не только запускает принцип разбитых окон, но способно чуть ли не остановить разработку на корню, развалить существующую культуру и убить мотивацию всей команды. Ни разу решение «ну в этот раз прокатит» не оправдывало себя даже в среднесрочной перспективе, не говоря уже про долгосрочную. Да, можно набрать 150 человек, которые работаю по скорости как 15, но это уже совсем другие цели и ценности. ;)

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

1. Сформулировать чётко свой текущий контекст для найма новых людей.
2. Согласовать его с командой, чтобы не было поломанных ожиданий и субъективных суждений.
3. Продумать вопросы, которые вы зададите на собеседовании или прескрине для проверки попадания в ваш контекст.
4. Придумать скрытые проверки в других частях собеседования, которые позволят понять не притворяется ли кандидат с целью получить работу у вас.
5. Поклясться на библии или любой толстой книге, орошённой пивом и пиццей, что вы не возьмёте кандидата, который не подходит по контексту.

Готово! Действуйте и удачного вам найма. Продолжение следует...

Ну и немножко позитива для изучающих IT алфавит. :)

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

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

Давайте перейдём к примерам. Я попытаюсь упомянуть контексты, которые я встречал чаще всего:

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

2. Вторым по распространённости является контекст наличия лидерских качеств. Компания ищет лидера, который сможет сплотить людей вокруг идеи и повести их за собой. Модели лидерства бывают разные и компания должна сформировать четкое понимание какого типа лидера они хотели бы нанять. Говорят, что лидерские качества можно развить, но как ни крути это очень непросто и работает не всегда. Явно не для найма с рынка.

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

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

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

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

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

Поэтому в качестве одного из общественных проектов я откликнулся на приглашение Олега Докуки стать одним из ревьюверов их с Игорем Лозинским книги "Reactive Programming in Spring 5". Я конечно не представлял сколько отнимает времени ревью книги. Оказалось очень много, ведь приходится читать и перечитывать очень внимательно каждую главу минимум 2 раза, а их в книге около 10.

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

До 24 октября действуют следующие промокоды на покупку:

RIJORT50 - 50% на eBook
ILXJIG15 - 15% на печатную копию

Заказать со скидкой можно тут: https://www.packtpub.com/application-development/hands-reactive-programming-spring-5

Хорошего чтения! А вот тут можно почитать подробнее про мое видение идеальной работы, если кому интересно: https://xpinjection.com/articles/do-you-know-your-dream-job/

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

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

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

2. Второй совет не такой очевидный. С утра первый час после пробуждения не используйте смартфон (разве что для критичных вещей) и ни в коем случае не заходите "почитать новости" в соцсети. Это позволит мозгу войти в рабочее состояние синхронно с нервной системой и не вызовет информационного перегруза на старте дня, когда мозг готов активно потреблять информацию после отдыха.

3. На митингах и других мероприятиях заставьте себя отучиться от привычки "что-то листать на смартфоне". Два параллельных канала информации очень сильно напрягают мозг, хотя вам это может быть и незаметно. Эта привычка еще вредна тем, что у многих перерастает в реальную зависимость "покрутить ленту" как только появилась свободная минута. Я перешел в режим только проверять важные коммуникационные каналы на митингах раз в 10-15 минут и работаю над избавлением от привычки дальше.

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

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

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

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

8. Используйте time management технику, которая лучше всего подходит для вашей деятельности. Если у вас предполагается погружение в задачу, то отлично подойдет техника Pomodoro. Если вы делаете много мелких задач в потоке, то посмотрите в сторону управления списками задач с разбивкой определенного размера. Обязательно делайте полноценные перерывы и переключайте внимание с отключением от информационных пото
ков. Прогуляйтесь, поболтайте с кем-то, поиграйте в теннис, позвоните родным. Что угодно, но не заменяйте один информационный поток другим. Это не отдых.

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

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

И снова подсмотрел интересную новость из соседнего канала: HashiCorp запустили обучающий проект по своим инструментам. Всем кто присматривался, но не знал с чего начать, на заметку. http://learn.hashicorp.com

Утреннего позитива! Эта картинка заряжает на продуктивный рабочий день. :)