Управление разработкой *

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

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

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

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

Всем привет! Меня зовут Антон Баранов, я тимлид разработки в компании "Синимекс", недавно я завершил работу над двумя микросервисными проектами в сфере финтех, а до этого был техлидом и разработчиком на проектах, связанных с БЭК-офисами и витринами данных. Сейчас я актуализирую свой чек-лист и хочу поделиться с вами размышлениями о том, почему старт проекта — это одновременно и самое захватывающее, и самое рискованное время для тимлида.

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

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

Есть один чудесный советский фильм — «Приключения Электроника». В нём злой персонаж с криком «Где же у него кнопка?!» ищет у мальчика-робота скрытый рычаг, который заставит робота вести себя так, как нужно злодею. Многие руководители и тим лиды, напоминают мне этого персонажа, считая, что человек устроен просто - у него есть "волшебный пендель" или "волшебная кнопка", нажав на которую можно сделать так, чтобы он (сотрудник) наконец начал поступать правильно. И я, грешен, тоже искал эти «кнопки». Но моя практика упрямо показывает: у людей нет таких кнопок.

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

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

Но если вы когда-либо задавались вопросом: «Почему этот человек снова и снова поступает именно так, как поступает?» — возможно, эти паттерны помогут вам увидеть то, что скрыто за словами.

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

Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.

Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что он «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.

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

Большинство enterprise-приложений работают с БД в том или ином виде. Чаще всего в качестве БД выступает реляционная DBMS, например, PostgreSQL или Oracle. Относительно часто для доступа к данным используют Hibernate. Ранее он предлагал только одну спецификацию — JPA (Java Persistence API), она же Jakarta. Но теперь Hibernate реализует ещё и Jakarta Data.

Jakarta Data — это новая спецификация под зонтиком проекта Jakarta EE (как и JPA), которая упрощает интеграцию данных в корпоративных Java-приложениях. Обе эти спецификации разрабатывает Eclipse Foundation, и в частности Gavin King, создатель Hibernate.

Большинство разработчиков привыкли работать с Hibernate именно через Spring Data JPA. Изначально, когда только обсуждали спецификацию Jakarta Data, Spring Data (не обязательно JPA) была одним из тех проектов, который, в перспективе, мог бы реализовать спецификацию Jakarta Data. Но этого не произошло, и, несмотря на то, что изначально команда Spring Data была вовлечена в процесс создания спецификации, они отказались от идеи реализовывать Jakarta Data, и та стала развиваться самостоятельно. Сегодня Jakarta Data применяют в Hibernate, Open Liberty и ряде более мелких решений. Как же так вышло?

Меня зовут Михаил Поливаха, я практикующий инженер и активный коммитер Spring Data. В этой статье я расскажу об особенностях Jakarta Data, как она появилась и чем отличается от конкурентных решений. Я также расскажу, что помешало команде Spring Data реализовать Jakarta Data, и что же нас ждёт дальше.

За год команда разработки Kaiten выросла в 3 раза, и привычные процессы перестали работать: доска переполнилась, потерялась прозрачность, а чтобы узнать, на каком этапе работа, приходится проваливаться в каждую карточку. 

Вместе с Юрой Юрковым, Delivery Manager Kaiten, расскажем, как мы прошли путь трансформации, какие решения сработали и как не потерять управление в момент масштабирования. Если вы в похожей ситуации — читайте статью и используйте наш опыт, чтобы быстрее навести порядок.

В современной разработке все чаще предъявляются высокие требования к качеству кода и неукоснительному следованию стандартам качества кода в командах. Обеспечение качества кода, а также решение многих других задач, связанных с разработкой и поддержанием «чистого» кода, берёт на себя популярный инструмент анализа — SonarQube.

Меня зовут Николай, я 1С-разработчик в SimbirSoft и в этой статье хочу подробно рассказать о процессе установки и настройки SonarQube в ОС Linux.

Забудьте о скучных теориях! Мы отправимся в мир расчетов и оценок. Приготовьтесь к практическому путешествию в мир Bus Factor!

Расскажем, как посчитать эту метрику и сделать это легко. Покажем, как применять набор индикаторов.

Публикуем интервью директора КЕДР Solutions Егора Гуторова с основателем компании «АТБ Электроника» Романом Дементьевым. Говорили о том, как развивается российская электронная промышленность. Обсуждали такие темы как история компании «АТБ Электроника», изменения рынка после 2014 и 2022 годов, рост роли импортозамещения и локализации производства электроники, поддержка государства и развитие собственных продуктов, вопросы кадров.

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

Тема безопасной разработки программного обеспечения интересует всё большее количество разработчиков и руководителей. Дополнительным стимулом стал вышедший в конце 2024 года обновлённый ГОСТ Р 56939, в котором описано 25 процессов (мер) для построения безопасной разработки. Это хороший список, но что он означает на практике, например, для Java-разработчиков? Поговорим о сути некоторых процессов и инструментарии.

Статья является переработкой совместного вебинара компаний ООО "ПВС" и АО "АКСИОМ". Текстовый вариант содержит дополнительные ссылки, а некоторые моменты рассмотрены более подробно. Полную запись вебинара доступна здесь: "Безопасность приложений: инструменты и практики для Java-разработчиков".

Статья построена так же, как и вебинар: первую часть подготовил Андрей Карпов, затем слово передаётся Алексею Захарову (@AlexZ0).

Когда специалист становится тимлидом, на него обрушивается лавина новых задач. Например, налаживать взаимодействие внутри команды, собирать качественную обратную связь, улучшать процессы, а иногда и пересобирать команду. Как справляться с этим, описано во множестве источников, но практические кейсы дают больше понимания, доходчивее будет только собственный опыт. Мы спросили у тимлидов Lamoda Tech, с какими вызовами они справлялись (или нет) в своей практике — внутри и за пределами компании.

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

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

Привет, Habr! Меня зовут Михаил Тетерин, я разработчик в Lenta tech, и сегодня расскажу, как мы упростили и ускорили процесс code review с помощью собственного инструмента — «ревью-рулетки». Это решение появилось из повседневной боли, когда merge requests зависают, разработчики неохотно разбирают задачи на ревью, а в чатах идет бесконечное «посмотри мой MR, пожалуйста».

Меня зовут Юля Гапуненко, я аккаунт-директор студии НАДО, которая помогала принимать Сибирский Диджитал-тур в Омске. Ниже делюсь своими впечатлениями от Тура.

Рассказ о том, чем параллельная разработка отличается от последовательной, и об опыте её внедрения в компании SM Lab.

В разработке появился новый тренд: вайбкодинг. Работает так: берёте Cursor или Windsurf, заставляете его писать код за вас, смотрите на выдачу и несёте её в прод. Всё, success. Так думает 90% вайбкодеров.

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

Привет, Хабр! Меня зовут Саша Мищенко, я тимлид платформенной команды в Профи.ру. Сегодня хочу поговорить о легаси и о том, почему мы не переписываем код просто из-за того, что он старый.