Меня зовут Иванов Алексей. Я DS и скрам-мастер в центре ML-экспертизы разработчика HRtech-решений TalentTech. Мы занимаемся обучением моделей для проектов компании.
Ровно год назад наша команда самоорганизовалась и начала применять подход SCRUM (будем дальше — скрам.) Я расскажу о наших внутренних процессах: что произошло, что происходит и, возможно, будет происходить с нами в ближайшем будущем.
Привет, Хабр! В Dodo Engineering мы любим ставить амбициозные цели и проводить эксперименты. В этой статье я хочу рассказать, как небольшая фича-команда за три месяца сделала и запустила новую программу лояльности в Додо Пицце.
Хотите взглянуть на проект целиком глазами бэкенд-разработчика? Тогда заваривайте чай, мы начинаем путешествие в страну спринтов, хотфиксов, миграций и блестящих додокоинов!
В статье пойдёт речь об опыте построения процессов CI/CD в Национальном расчетном депозитарии (НРД) в разработке под ЦФТ-Банк. В качестве введения рекомендую ознакомиться с предысторией того, как мы перевели разработку ЦФТ-Банк на CFT Platform IDE. Новая статья — её логическое продолжение и ориентирована на разработчиков, знакомых с основными возможностями CFT Platform IDE.
«Играющий тренер» – термин, пришедший в IT из мира спорта. Он подразумевает, что руководитель одновременно занимается как управленческими задачами (планирование, контроль), так и решает вполне рядовые (пишет код, настраивает сервера и т.д.). Считается, что совмещать эти роли нельзя, но в жизни, как и в палитре, есть куча оттенков между «можно» и «нельзя». Под катом будет мой жизненный опыт в роли этого самого играющего тренера, я расскажу о плюсах и минусах, а также попробую подвести некий итог своего опыта в этой роли.
Татьяна Гребенюкова, продакт-оунер курса Слёрм «SRE: внедряем DevOps от Google», собирает интересные кейсы внедрения SRE в российских компаниях. Некоторые истории мы используем для развития курса, а другими рады поделиться со всеми.
Сергей Бухаров, SRE из Dodo Engineering, рассказал историю внедрения SRE в компании, какие практики из книжек оказались неприменимы и из чего состоят будни SRE-команды.
Привет!
Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов разработчиков в QIWI.
Если предпочитаете формат видео — держите.
А вот и текст.
У меня есть любимая притча. Мужик пилит дерево. Другой к нему подходит и спрашивает:
— Как дела? Давно пилишь?
— Три дня уже.
— Что-то долго. Может, тебе стоит пилу заточить?
— Не, некогда точить, нужно дерево пилить.
И в IT такое бывает часто. Работаешь над какой-нибудь рутинной задачей и думаешь, что вот наверняка есть какой-то инструмент, который может автоматизировать эту работу. Но сроки горят, и мы говорим себе: «Не в этот раз». И оставляем на потом. А когда работа завершается, мы быстро забываем про эту боль.
Я, например, до сих пор использую старый SQL Developer для работы с базой данных, хотя все коллеги давно перешли на DataGrip. И они периодически подталкивают меня, а мне все лень. Кто-то пользуется Git-ом и никак не соберется с силами, чтобы изучить его поглубже, добавить в свой багаж более глубокие команды. А кто-то использует IDE и не изучает горячие клавиши или плагины, которые могут помочь в работе.
Меня зовут Артём Сусеков, я менеджер разработки в Miro. Расскажу, как мы пришли к справедливой оплате и прозрачному обсуждению эффективности сотрудников команд продуктовой разработки.
Статья будет полезна, если вы задаётесь вопросами:
•Как оценить вклад каждого сотрудника в результаты компании?
•Как сформировать понятные ожидания?
•Как оценить грейд сотрудника и понять, что ему нужно сделать, чтобы вырасти в компании?
•Как проводить оценку сотрудника, не перегружая этим процессом всех остальных?
•Как сделать процесс оценки прозрачным?
Принципы разработки программного обеспечения необходимо знать каждому инженеру, который хочет писать чистый код. Следование этим принципам позволяет вам и другим разработчикам понять проект.
Кроме того, обслуживание или изменение проекта в будущем станет легким. Таким образом, вы в конечном итоге сэкономите деньги, время и ресурсы. Если вы хотите, чтобы проект развивался более плавно, то рекомендуется жить по этим законам.
Мы хотим помочь вам внедрить чистый код. Давайте рассмотрим наиболее распространенные принципы разработки программного обеспечения.
Если ваш проект с автотестами растет, то рано или поздно ставится вопрос о том, как централизованно управляться с этими тестами. Как найти время на поддержку тестовой документации? Как ее структурировать? Где хранить отчеты? Как избавиться от нестабильных тестов и быстро выявить ответственных за них? В Wrike мы смогли ответить на все эти вопросы и автоматизировать процессы, которые они затрагивают. В статье расскажем, как нам это удалось.
Эта статья является переводом материала «Tackling Complexity in CQRS».
Шаблон CQRS может творить чудеса: он может максимизировать масштабируемость, производительность, безопасность и даже «превзойти» теорему CAP. Тем не менее, например, в своей статье о CQRS Мартин Фаулер утверждает, что шаблон следует применять умеренно и даже осторожно:
«...для большинства систем CQRS добавляет риски»;
«...вы должны быть очень осторожны при использовании CQRS»;
«Итак, хотя CQRS - это шаблон, который хорошо иметь в наборе инструментов, имейте в виду, что его сложно применять правильно, и вы можете легко пропустить важные части, если неправильно использовать его.»
С моей точки зрения, сложность, вызванная CQRS, в значительной степени случайна, и поэтому ее можно избежать. Чтобы проиллюстрировать свою точку зрения, я хочу обсудить цель CQRS, а затем проанализировать 3 распространенных источника случайной сложности в системах, использующие CQRS.
На написание этой статьи меня подтолкнула мысль о том, что все малочисленные конструкторские бюро (1...4 конструктора), с которыми я имел дело или в которых работал, имеют крайне низкую эффективность. Сами же сотрудники таких микро КБ как правило живут "с бревном в глазу".
SCRUM закрепился и в стартапах, и в IT-гигантах, но что на счёт скрама в крупной госкомпании? Попытаемся дать ответ на примере одной из команд разработки Россельхозбанка, а в конце статьи поделимся чек-листом в помощь начинающему скрам-мастеру.
Привет, Хабр!
На связи команда YouTrack из JetBrains. Как вы знаете, YouTrack подстраивается под работу практически любой команды с помощью рабочих процессов (workflows). Рабочие процессы позволяют автоматизировать многие рутинные действия, однако до недавнего времени это требовало навыков программирования. Мы добавили в новую версию YouTrack конструктор рабочих процессов, позволяющий командам любого (не)технического уровня создавать рабочие процессы без единой строки кода.
Об этом и о других нововведениях расскажу ниже, добро пожаловать в пост!
Использование инструментов для повышения и контроля качества кода может стать важным фактором успеха при реализации сложных программных проектов. Например, к таким инструментам относятся статические анализаторы. На данный момент они доступны в большом количестве: от бесплатных с открытым исходным кодом до кросс-функциональных коммерческих решений. С одной стороны – есть из чего выбирать, с другой – поиск подходящего вашей команде инструмента может стать настоящей исследовательской работой.
Возможно, вы сталкивались с классической историей: поговорили с заказчиком о задаче, всем всё понятно. Начали работать — и началось: "А я думал, это и так ясно" или "Я ожидал, что ты это опишешь точнее".
Начинается круговорот вопросов, переделок, а главное — неоправданных ожиданий и недовольств.
Как с этим бороться?
Мы привыкли, что на докладах рассказывают про Agile, но в реальном мире осталось много мест, где используется каскадная модель разработки.
Поговорим о том, какие инструменты и практики из гибких методологий можно использовать в таких случаях, какая от этого польза для проекта, а также как найти баланс между постоянными экспериментами и необходимостью четко фиксировать требования и ТЗ заранее.
Сегодня поговорим о тестировании у нас в Alente, а конкретно — о том, как трансформировалась роль тестировщика в проектах.
Пару лет назад мы работали как большинство студий: привлекали тестировщика только на этапе тестирования. Но сейчас он принимает деятельное участие в работе уже на этапе сбора требований к сайту. Почему так получилось и как это помогает улучшить продукт? Читайте — и вы всё узнаете.
Как было раньше?
Проекты приходили на тестировку перед запуском. И мы получали набор стандартных проблем данного этапа: непроработанные изначальные требования приводили к переделкам на этапе тестирования. При этом отметим, что непроработанные требования — это не только недостаточное описание работы функций, но и возникающие противоречия в их трактовке. Мы все люди, и бывают ситуации, когда команда разработки, начиная от проект-менеджера и дальше по цепочке верстальщик — программист — тестировщик, трактует требования по-своему. А в итоге получается проект-«франкенштейн».
Причиной чаще всего были ошибки коммуникации, потому что не все требования фиксировались текстом или выражались в виде прототипов и макетов. Что-то оставалось в переписках, в обсуждениях и даже просто в головах, терялось в потоке задач и выпадало из процесса.
Другой проблемой становились изменения требований по ходу разработки. Отсутствие чёткого механизма фиксации изменений приводило к ситуациям, когда что-то делалось по договорённости, а потом не было никакой возможности выяснить, кто, с кем и о чём конкретно договаривался. В случае кадровых ротаций в команде это приводило к очень серьёзным проблемам.
Привет. Меня зовут Андрей Костылев. Я работаю в IT более 15 лет. За это время вырос из рядового программиста в тимлида и CEO проектов. Сейчас наш основной стартап — система автоматизации X24:ERP, которая помогает довести производственные процессы до совершенства.
Сегодня хочу поделиться правилами, которые помогли мне построить карьеру. Уверен, они пригодятся всем, кто хочет добиться успеха в любой сфере.
