Около недели назад мы провели вебинар по соответствующей теме, нас просили поделиться презентацией и мы решили не просто ей поделиться, а написать полноценную статью со слайдами. Запись вебинара уже выложили в нашем канале на Youtube — подписки и лайки как обычно приветствуются. А еще приглашаем вам подписаться на наше телеграм канал zabbix_ru, где мы публикуем много полезной информации по этой популярной системе мониторинга.

Под катом рассказываем во всех подробностях.

Пару раз на предыдущих местах работы я попадал на проект, где не было документации. Все знания о проекте были у разных коллег, а некоторые части систем вообще были «чёрными ящиками».

Что делать, когда попал в проект без документации? Ответ простой — уходить!

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

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

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

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

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

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

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

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.

Плюс, регресс — штука дорогая, ведь в это время команда (особенно QA) не занимается созданием новой ценности для заказчика и пользователя, а перелопачивает старую.

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

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

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

Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.

Зачем проводить ретроспективы с командой? 

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

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

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

Привет! Я Лена, ИТ-лидер 1С в Moex. Хочу поделиться историей, как я внедрила ретро в своей команде, не знакомой с ней и какие инструменты для этого я использовала.

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

Продолжаю делиться личным опытом в планировании. Без воды, лирики и рерайтов. В статье перечислю инструменты которые прошли проверку временем и самое главное — ленью. Я отсеял всё лишнее и оставил только то, что действительно полезно и эффективно.

Расскажу, как работать с планированием на ежедневной основе — по сути, на какие кнопки я нажимаю (поговорим про софт), как провожу утро (та самая практика — книга «Магия утра», но в моей собственной интерпретации) и как я лично использую известные фреймворки:

— Getting Things Done, как основа процесса;

— Матрица Эйзенхауэра, как способ приоритизации;

— Метод «Съесть лягушку», как вспомогательный инструмент к Матрице Эйзенхауэра, потому что я всё‑таки ленивый и не всегда сам себе честно отвечаю, что действительно надо сделать в первую очередь.

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

Опуская множество НО, в целом, философия Agile (а никак иначе язык сказать не поворачивается) показала довольно неплохие результаты с точки зрения организации команд в других, околоайтишных направлениях.

И возник вопрос, возможно ли этот подход положить на понятный, последовательный и очевидный проект в области Охраны труда. Казалось бы, зачем? А затем, что помимо понятной и очевидной части есть совершенно непредсказуемая и многогранная - работа с Заказчиком, пользователями и экспертами.

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

Большинство предприятий среднего и крупного бизнеса, когда сталкивается с необходимостью смены системы учета (по причине перехода на новую конфигурацию 1С из-за устаревания текущей или перехода на 1С с другой учетной системы), встают перед выбором между двумя программными продуктами: 1С:ERP Управление предприятием 2.5 и 1С:Управление холдингом 3.2.

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

Сегодня вышел подробный отчёт о состоянии DevOps в России. В исследовании этого года приняло участие рекордное количество респондентов — больше 4100 линейных специалистов и руководителей. В статье мы расскажем, что узнали про инфраструктуру российских компаний: какие ОС чаще используют на серверах, где хранят логи, какие системы контроля версий предпочитают и как меняется картина от года к году.

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

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

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

Привет! Меня зовут Дмитрий. Я архитектор решений в крупной российской компании, более 15 лет проектирую, пишу код и руковожу командами. Сотрудничаю с Практикумом как ревьюер курса по Java и как автор курса «Архитектура программного обеспечения» в Яндекс Практикуме.

Предположим, вы решили развлечься дизайном систем (System design), пусть даже и не добровольно, на собеседовании. Если компания поленилась поделиться рабочим контекстом, то задача может быть в формате «запроектируй Твиттер». Более кандидатоориентированная компания N может попросить «спроектируй поиск на сервисе N».

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

Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса.  

Несколько дисклеймеров:  

Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат. 

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

Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org. 

Исходная ситуация 

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

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

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

Как был организован процесс? 

У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы.  Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.  

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