xpinjection

@xpinjection_channel Нравится 1
Это ваш канал? Подтвердите владение для дополнительных возможностей

Авторский канал @xpinjection - опытный Java Tech Lead, Delivery Manager и консультант с 15+ лет опыта в IT.
Я пишу о Java, распределённых системах, Agile, процессах разработки, инженерных практиках, QA, конференциях, инфраструктуре и многом другом...
Гео и язык канала
Украина, Русский
Категория
Технологии


Гео канала
Украина
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
16.07.2018 11:51
реклама
TGAlertsBot
Мониторинг упоминаний ключевых слов в каналах и чатах.
SearcheeBot
Ваш гид в мире Telegram-каналов
Telegram Analytics
Подписывайся, чтобы быть в курсе новостей TGStat.
3 973
подписчиков
~3.3k
охват 1 публикации
~885
дневной охват
~2
постов / нед.
82%
ERR %
0.62
индекс цитирования
Репосты и упоминания канала
5 упоминаний канала
1 упоминаний публикаций
12 репостов
2%
Hell of Testing by ZX
Hell of Testing by ZX
2%
Менеджер от боженьки
2%
Hell of Testing by ZX
DevPassion
Scrum Master Notes
Архитектура ИС
Nemchinskiy On Business
ДевОпс Инженер
Automate It All!
Чернозём и Звёзды
Новые каналы
QAStudy.online
Интересное в IT
Каналы, которые цитирует @xpinjection_channel
Последние публикации
Удалённые
С упоминаниями
Репосты
xpinjection 22 Jun, 21:11
Маленький пост «от кэпа» в период карантина и бесконечной череды онлайн встреч, наполненный болью. Очевидные советы, но при этом единицы им следуют... :(

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

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

2. Удосужьтесь написать в приглашении о цели встречи и предполагаемой структуре. Очень желательно упомянуть тех людей, от которых вы ожидаете вовлечённости и как вы видите их роль во встрече. Это сильно помогает проводить сфокусированные встречи и улучшать уровень подготовки.

3. Используйте онлайн инструменты для фасилитации встреч. Люди гораздо лучше воспринимают информацию визуально чем на слух. При этом, у вас остаётся отличный артефакт для продолжения работы и участников, желающих быстро получить представление о результатах встречи. Как минимум, это может быть mind map. Желательно использовать подготовленные шаблоны под конкретные типы встреч.

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

Эффективных вам встреч!

#митинги #эффективность
👍 84
😱 1
😴 4
Читать полностью
xpinjection 18 Jun, 10:01
В предыдущем посте я обещал поделиться видео своего доклада про capacity-based планирование с февральской конференции Agile Magic 2020. Оно действительно уже доступно, ссылку можно найти ниже. Надеюсь в карантинном онлайн мире видео докладов вам ещё не наскучили и вы открыты к новым знаниям и опыту. :)

#Agile #планирование
👍 36
😱 1
😴
xpinjection 16 Jun, 10:01
Продолжим тему оценок и сегодня обсудим как бороться с проблемами, о которых я писал прошлый раз. Я не буду писать очевидные вещи о том, что оценки должны быть командными и максимально исключать якоринг с помощью таких техник как planning poker. Это само собой разумеется и является обязательным базисом.

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

Поэтому, данные критерии нужно максимально исключить из оценок. Задача должна быть полностью понятна исполнителям и не иметь видимых значимых рисков. Если в процессе обсуждения выяснилось, что непонимание либо подобные риски присутствуют, то необходимо уточнить, что нужно сделать для их устранения. Зачастую, помогают технические спайки или прототипы. Реже помогает более детализированный технический дизайн. Лучше проверять задачи ещё на уровне проведения PBR (aka груминг), но лучше поздно чем никогда.

Вторым важным моментом я бы назвал гранулярность задач. Мы увидели, что слишком мелкие или слишком крупные задачи приносят проблемы. Поэтому Капитан Очевидность подсказывает нам держаться среднего размера. Что это значит? На моем опыте, лучше всего работают задачи размером от 4 часов до 2 дней. Речь конечно об идеальных часах/днях в capacity-based планировании (ссылку на видео моего доклада на эту тему скоро опубликую). Если задача получилась мельче, то лучше не обьединить с соседней. Если крупнее, то декомпозировать. При таком размере задач также лучше ощущается прогресс команды в рамках спринта и растёт приятное ощущение от законченности работы.

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

Надеюсь, эти советы помогут вам с командными оценками!

#оценки #планирование
👍 71
😱 2
😴 7
Читать полностью
xpinjection 10 Jun, 21:50
На опыте работы с множеством разнообразных команд разработки, я заметил, как люди попадают в 3 типичные ловушки оценок. В результате, страдает общая скорость разработки и накапливается недовольство со стороны бизнеса.

Первая ловушка весьма очевидна и заключается в увеличении погрешности с увеличением оценки. Если задача кажется большой, сложной, непонятной или рискованной, то все эти показатели легко закладываются в оценку. И растёт разбежка между оптимистичной и пессимистичной оценкой. Как результат, мы можем видеть оценки 30-45 и они кажутся разумными с точки зрения относительной погрешности, но абсолютная погрешность очень большая. При этом, очень тяжело придти к единому командному мнению, поэтому многие команды просто берут пессимистичную оценку для надежности.

Вторая ловушка полностью противоположная. То есть, каждая задача разбивается на несколько маленьких, полностью понятных и простых подзадач, которые потом оцениваются. Такие задачи часто получают оценки 1-2 часа за счёт уровня гранулярности оценок. В результате, мы видим маленькую абсолютную разбежку всего в 1 час и не замечаем огромную относительную погрешность в 50%. Если просуммировать все оценки, то можно «потерять» до 50% всей скорости команды.

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

Что же делать? Об этом поговорим в следующем посте. :)

#оценки #планирование
😱 61
😢 21
😴 9
Читать полностью
xpinjection 9 Jun, 16:15
Сегодня в ленте проскочила новость на тему одного из моих постов на прошлой неделе. AI в разработке с каждым днем все ближе!
😱 20
😢 4
👌 11
xpinjection 4 Jun, 13:39
Недавно я писал про постоянно растущий спрос на IT специалистов и к каким негативным последствиям это приводит. В ответ я получил много вопросов на тему, что с этим можно сделать. Я считаю, что есть 2 радикально действенных пути решения проблемы.

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

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

Описанный подход уже давно не мечты, а вполне реализуемая задача. За последний год было показано уже несколько прототипов от разных компаний. Да, пока они мало что могут. Да, пока решения ещё сырые. Но когда-то ровно такая же ситуация была в создании AI для игры в шахматы или Go...

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

Вместо этого предлагается сосредоточить куда большие усилия на продуктовом дизайне. И речь не о UI/UX дизайне, а о полном спектре уровней продуктового дизайна. В реализацию нужно запускать только то, в чем бизнес уверен и что точно принесёт задуманную ценность. Практика показывает, что такой подход позволяет сэкономить 50-90% усилий разработки и значительно ускорить получение конечной ценности. А это, в свою очередь существенно упрощает технические решения и радикально уменьшает потребность в таком большом количестве разработчиков.

Есть ещё много способов незначительно изменить ситуацию, но для кардинальных изменений я вижу только описанные два подхода.
😱 13
👍🏻 55
😴 29
Читать полностью
xpinjection 29 May, 13:46
Мы проводим технологические конференции в Украине уже 10 лет, JEEConf 2020 должна была стать юбилейной. Мы тщательно готовили программу и работали над реализацией новых идей, но весь мир изменился довольно быстро и существенно повлиял на все публичные мероприятия.

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

Мы не можем и не хотим рисковать здоровьем наших докладчиков, участников и всех, кто помогает нам организовывать наши мероприятия. Поэтому мы приняли нелегкое решение отменить конференцию JEEConf в 2020 году. Этот год стал очень непростым для многих, и для нас в том числе, но мы надеемся, что переждем это время и все станет на свои места. И мы обязательно встретимся с вами в следующем году на JEEConf 2021!

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

Мы очень просим вас с пониманием отнестись к ситуации и готовы предложить несколько вариантов на выбор для участников конференции. Итак, есть несколько способов использования вашего билета на JEEConf 2020:

- «заморозить» билет и воспользоваться им для посещения другой нашей конференции (Selenium Camp или XP Days Ukraine) без доплат, как только снимут ограничения;

- перенести билет на конференцию JEEConf 2021;

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

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

Как это сделать? Просто напишите нам на электронный адрес, какой из способов вам удобен и мы в ближайшее время ответим вам.

Спасибо и до встречи!

#конференции #Java
😱 5
😢 27
👌 64
Читать полностью
xpinjection 28 May, 22:10
Новое слово в микросервисной архитектуре! 2 больших микросервиса (бэкенд и фронтенд), задеплоенные на одной ноде minikube. Оверинжениринг убьёт этот мир! А мы ещё обвиняли криптомайнеров в напрасной трате электроэнергии...

#fun #архитектура #микросервисы
😂 99
😳 3
😔 4
xpinjection 26 May, 15:17
Обычно, с любой технологией у людей есть либо чисто теоретический опыт (читал/посмотрел как ловко кто-то делал демо на конференции) либо практический (когда начали происходить непонятные вещи и пришлось пробежаться по технологическим граблям). Вот простой пример, что нужно знать для надежного деплоймента своих систем в Kubernetes, если у вас не кластер сына маминой подруги с 2-3x запасом по объёму доступных ресурсов.

#инфраструктура #kubernetes
😱 7
👍🏻 17
😟 1
Читать полностью
xpinjection 19 May, 10:01
На сайте LeSS неожиданно есть архитектурно-технический раздел. В нем не предлагается ничего революционного, просто собраны здравые идеи и тренды последних 5-10 лет в IT:

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

В конце раздела есть неплохая библиография. Я все книги оттуда кроме двух прочитал сам и советую к прочтению другим (разве что кроме UML и шаблонов проектирования, потому что ооочень скучно написаны).

#architecture #agile
Читать полностью
xpinjection 18 May, 12:51
В конце прошлой неделе случилось важное событие для Java разработчиков - вышла новая долгожданная версия Spring Boot 2.3.0. Что хорошего в новой версии?

- Поддержка Java 14.
- Обновление ключевых зависимостей, включая последний релиз Spring Data семейства.
- Поддержка построения более эффективных Docker образов из коробки (меньше плагинов теперь нужно).
- Использование /config/*/ на файловой системе для вычитки конфигураций (убирает кучу костылей в Kubernetes деплоях).
- Реализация graceful shutdown, что очень важно в мире контейнеризации.
- Liveness и readiness пробы из коробки, что прекрасно для использования Kubernetes.
- Добавлен еще одна слайс-аннотация для тестирования веб-сервисов WebServiceClientTest.
- Улучшения actuator для еще большего удобства observability.

Много настроек изменилось, поэтому рекомендуется использовать spring-boot-properties-migrator для миграции. Он поможет мигрировать некоторые настройки на лету, а также покажет какие потенциальные проблемы есть.

#java #spring_boot
🎉 88
😱 1
😴 6
Читать полностью
xpinjection 18 May, 12:51
В конце прошлой неделе случилось важное событие для Java разработчиков - вышла новая долгожданная версия Spring Boot 2.3.0. Что хорошего в новой версии?

- Поддержка Java 14.
- Обновление ключевых зависимостей, включая последний релиз Spring Data семейства.
- Поддержка построения более эффективных Docker образов из коробки (меньше плагинов теперь нужно).
- Использование /config/*/application.properties на файловой системе для вычитки конфигураций (убирает кучу костылей в Kubernetes деплоях).
- Реализация graceful shutdown, что очень важно в мире контейнеризации.
- Liveness и readiness пробы из коробки, что прекрасно для использования Kubernetes.
- Добавлен еще одна слайс-аннотация для тестирования веб-сервисов WebServiceClientTest.
- Улучшения actuator для еще большего удобства observability.

Много настроек изменилось, поэтому рекомендуется использовать spring-boot-properties-migrator для миграции. Он поможет мигрировать некоторые настройки на лету, а также покажет какие потенциальные проблемы есть.

#java #spring_boot
Читать полностью
xpinjection 17 May, 10:00
Большинство проблем в IT связано с двумя причинами:

1. Карго-культ. Мы слепо повторяем процессные ритуалы, применяем практики без глубокого понимания их смысла и должной мотивации, используем инструменты, которые «на хайпе» без подходящей для них задачи. Эта участь постигла Agile, DevOps, микросервисы и многие другие области.

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

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

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

#архитектура #микросервисы
😱 5
👍🏻 101
😟 4
Читать полностью
xpinjection 16 May, 11:42
​​Забавно, насколько любой подход зависит от подачи и аргументации. В релизе 1.5 популярного service mesh решения Istio практически все управляющие компоненты схлопнули в монолит. В релиз ноутах пишут, что стало проще, удобрее и быстрее. И это при том, что Istio как раз ориентирован на микросервисные системы...

#инфраструктура #kubernetes #istio
Читать полностью
xpinjection 12 May, 13:20
Начало 2020 года стало прямо таки технологическим прорывом за последние 5 лет для IT специалистов, которые предпочитают в работе компактные 13-дюймовые ноутбуки. Наконец производители стали предлагать опцию с 32GB RAM. И это прекрасно!

Apple начал продавать MacBook Pro 13 с возможностью выбора количества памяти на борту до 32GB в топовой комплектации. Также, из приятных плюшек, расширили размер SSD диска до 4TB (в максимальном размере опция обойдется $1200, но на мой взгляд 1TB для разработки уже с головой). И наконец закончилась эпопея с клавиатурой, поэтому MacBook Pro 13 для меня снова стал приоритетным вариантом при выборе. На последнем i7 c 32GB RAM и 512GB диска цена вопроса $2500.

Dell также обновил свой XPS 13, чтобы не отставать от конкурентов. Но максимальный размер SSD диска ограничен 2TB, из коробки идет 1TB. 4K Touch дисплей является опцией по умолчанию в топовой конфигурации, но практика использования показывает, что на таком размере Full HD также работает прекрасно (а это экономия $300). Дополнительно $60 уйдут на Windows Pro. В итоге, аппарат на последнем i7 с 32GB RAM и 1TB диском обойдется $2210 с 4K Touch дисплеем и $1910 с Full HD дисплеем.

Вполне сопоставимые варианты как по цене так и по комплектации. Вопрос больше предпочтений по операционке, бренду и прочим мелочам. Как по мне, это очень крутая новость и еще один широкий шаг в сторону от стационарных компов в разработке.
🎉 75
😱 3
😴 19
Читать полностью
xpinjection 8 May, 10:00
Маленькая радость для людей, которые работали с Kubernetes под виндой. Утилиты kubectx и kubens были переписаны на Go и теперь можно их скачать как бинарники. Я все равно предпочитаю поднимать полностью настроенный тулсет в Docker контейнере, но для многих эта новость немножко облегчит жизнь.
xpinjection 7 May, 14:39
Весенний конференционный сезон благодаря коронавирусу полностью провалился. Многие конференции перенеслись или отменились. Но некоторые организаторы решили провести мероприятия в легковесном онлайн формате.

На следующей неделе, 14-16 мая, именно в таком формате пройдет DevOps Days Kyiv from home. Это 3 дня докладов и сессии общения с докладчиками про DevOps культуру и связанные с ней технологии.

Благодаря онлайн формату, выступят топ-спикеры со всего мира:

‎•‎ Kris Nova – пионер Kubernetes and Chief Open Source Advocate в Sysdig.

‎•‎ Baruch Sadogursky – Developer Advocate в JFrog с 17 годами технического опыта.

‎•‎ Liz Fong-Jones – Principal Developer Advocate for SRE & Observability в honeycomb.io.

‎•‎ Niall Murphy – Director of Engineering for Azure Cloud Services в Microsoft.

‎•‎ Kelsey Hightower – Staff Developer Advocate в Google.

На третий у участников будет возможность поучаствовать в неформальном общении с Kelsey Hightower и задать вопросы легенде мирового DevOps сообщества.

Я был на DevOps Days Kyiv в прошлом году и там был отличный нетворкинг. На следующей неделе тоже обязательно присоединюсь.

Регистрация БЕСПЛАТНАЯ, поэтому торопитесь занять себе место!
Читать полностью
xpinjection 5 May, 10:00
Многие айтишники не любят работать в больших энтерпрайз компаниях. Я недавно задумался, что же раздражает и утомляет именно меня в работе с такими компаниями. Ведь это же для каждого вполне конкретные факторы. Получился такой себе мини-рейтинг анти-паттернов:

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

2. На втором месте конечно же бесконечные митинги с неконтролируемым числом участников. У большинства сотрудников календарь на день забит так плотно, что не остаётся времени на перекус и туалет. Люди вскоре приспосабливаются, перекусывая во время митинга с выключенной камерой. Все менеджеры хотят быть в курсе всего. Вдруг что-то без них решат... Во второй половине дня мозг так перегружен информацией, что эффективность митингов резко снижается, что делает их ещё дольше и масштабнее. Тут вспоминается один из моих любимых мемов: «мы не закончим эту встречу, пока не поймём почему не делается работа». :)

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

Подобные анти-паттерны можно встретить во многих больших компаниях с классическим иерархическим управлением, чем бы они ни занимались и насколько успешными ни были. И, к сожалению, они очень устойчивы к любого рода попыткам изменений...
😂 64
😳 5
😔 118
Читать полностью
xpinjection 24 Apr, 10:00
​​Традиционно, в мире Agile проводятся только точечные тренинги на несколько дней с раздачей сертификатов и совсем мало проводится долгосрочного обучения. А уж чтобы еще и бесплатно... Поэтому делюсь с вами хорошей новостью с просторов интернета.

Во вторник, 28 апреля в 20:00 открывается "Вечерняя школа Слёрма по Аджайл: Как сберечь бизнес во время кризиса за счёт перехода на Аджайл".

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

Курс открытый, участие в нем БЕСПЛАТНОЕ.

Сам курс также построен гибко: планы будут меняться, ориентируясь на запросы и обратную связь участников, а также на изменение ситуации вокруг. Он рассчитан на 1,5 месяца: 2 вебинара в неделю, по вторникам и четвергам в 20:00.

Участников ждут:

— знания от практиков Agile;
— кейсы Agile-трансформации западных и российских компаний;
— рекомендации по организации удаленной работы;
— обсуждение ваших проблем с коллегами и спикерами;
— приёмы и навыки быстрых изменений в нестабильной среде.
Читать полностью
xpinjection 22 Apr, 11:35
Начинается сложный период и для рынка IT: закрываются проекты, замораживается найм, сокращаются зарплаты и людей даже отправляют в вынужденные отпуска. В первую очередь кризис ударил по стартапам и аутсорсингу. На этом фоне энтерпрайз пока чувствует себя более уверенно.

Мы для нескольких крупных клиентов запускаем или расширяем продуктовые команды. В связи с этим открыт ряд интересных вакансий:

1. Синьор Java разработчик с глубоким практическим опытом в Spring Boot, микросервисах, Kubernetes и Kafka. 2-3 таких нужно для усиления команды. Онсайт в Киев.

2. Инфраструктурный инженер с DevOps майндсетом, умеющий в Kubernetes на bare metal, observability и настоящий CI/CD. Работа в команде разработки с плотным сотрудничеством. Онсайт в Киев.

3. Техлид с серьезной банковской доменной экспертизой и знанием современного Java технологического стека. Нужно будет собирать команду и возглавлять разработку новых продуктов. Онсайт в Киев.

4. .NET разработчик с практическим опытом разработки микросервисов в Kubernetes, знанием Kafka и PostgreSQL, а также отличными инженерными практиками. Онсайт Днепр.

5. UI/UX дизайнер с опытом работы в энтерпрайзе, умеющий находить общий язык с командой разработки и дизайнить продукт по результатам работы с конечными пользователями. Современный технологический стек и интересный продукт, есть где развернуться. Онсайт Днепр.

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