Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье. 

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

Привет! Меня зовут Даша Семенова, я руководитель проектов в AGIMA. Уже пять лет настраиваю процессы у одного большого заказчика. Это еком, ребята продают свою продукцию, а многие из вас ее покупают. А если не покупаете, то точно слышали. В общем, бренд известный и важный для нас.

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

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

Несколько лет назад сочетание слов Delivery и Manager редко встречались вместе. Сегодня же количество таких вакансий исчисляется сотнями, и многие компании внедряют у себя такую роль.

Что это? Очередная дань моде? Или вполне четкая трансформация IT-менеджмента? Нужно ли относиться серьезно к этой роли, или через пару лет она также быстро исчезнет, как и появилась?

За ответами на все эти вопросы прошу под кат.

Кого обычно ставят тимлидом? По каким правилам и критериям происходит выбор? Как стать именно таким кандидатом, которого назначат на эту позицию?

Это и многое другое в статье. Прошу под кат.

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

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

Статья будет интересна тем, кто анализирует бизнес-процессы и создаёт их с нуля.

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

Синонимами кнопочного мышления я считаю «экранное мышление» или преждевременную концептуализацию. Я раскрою мышление кнопками на десятке примеров из практики. А здесь для начала история, которая наверняка случалась с каждым. Представьте к вам приходят и рассказывают о падении конверсии на сайте. А вы ему сразу: «Давайте кнопку покупки сделаем побольше и поярче!». Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Вот в таких случаях я говорю о кнопочном мышлении.

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

В комментариях к моему туториалу, рассказывающему о парсинге логов с помощью Fluent-bit, было приведено две альтернативы: Filebeat и Vector. Этот туториал рассказывает как организовать сбор и парсинг лог-сообщений при помощи Filebeat.

Цель туториала: Организовать сбор и парсинг лог-сообщений с помощью Filebeat.

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

Кому данная тема интересна, прошу под кат:)

Привет, я - Эдгар, backend-разработчик личного кабинета МегаФон, поделюсь решением проблемы log shipping-процесса в централизованное хранилище Elasticsearch, которое мы нашли вместе с командой. 

Привет! Это вторая часть статьи, в которой мы будем разбирать практическое применение платформы Graylog.

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

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

Всем привет! В этой статье мы хотим поделиться нашим опытом использования полезной платформы Graylog, которая ежедневно помогает собирать, надежно хранить и анализировать логи с десятков серверов, окутанных заботой нашей поддержки :)

Это первая часть статьи, в которой мы расскажем почему выбор пал на Graylog, как его установить и произвести базовую настройку.

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

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

Когда мы только берём задачу в работу, она попадает в Tech Design, затем задача перемещается в Development — основной этап разработки. После того, как разработка фичи окончена, задача отправляется на Review, где мы проверяем написанный разработчиком код. Затем два этапа тестирования, и, соответственно, две колонки — QA (Quality Assurance) и UAT (User Acceptance Testing). Финальная колонка — Ready to Release, то есть, фича, попавшая в неё, уже готова к выпуску в прод.

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

Вступление