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

На скриптовых языках удобно разрабатывать… И на этом удобство заканчивается. Вне машины разработчика начинаются проблемы. Особенно если вы пишете какой-то прикладной тулинг — cli-утилиты, вспомогательные приложения в вашем SDK и прочее. Вы даже не можете рассчитывать на то, что у пользователя будет pip, чтобы он смог поставить все ваши зависимости, вам все нужно организовать самостоятельно.

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

Если вам покажется, что в чем-то я ошибаюсь, добро пожаловать в комментарии. Буду рад услышать любые альтернативные точки зрения. Кроме, как я уже отметил в заголовке, рекомендации переписать все на Go/Rust/You name it :) Этот холивар мы уже проходили.

Разработка фронтенд-части любого веб-приложения представляет собой неимоверное количество задач и решений, которые влияют на функциональность и внешний вид продукта. Когда речь идет о создании платформы для такой критической сферы, как торговля на фондовом рынке, задача становится еще сложнее. Своим опытом использования нейросети в разработке такого приложения с нами поделится Павел Янонис, старший разработчик в ICBC Standard Bank.

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

Привет, Хабр! Я Саша Шутай, руководитель направления PHP в AGIMA. Хочу обсудить важные для тимлидов вопросы: как управлять бэклогом и правильно распределять время, нормально ли отвлекаться во время работы, как овертаймить, не выгорать и успевать жить. Статья в первую очередь будет полезна начинающим тимлидам. Ну а матерые руководители команд найдут в ней советы по оптимизации работы.

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

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

Всем привет! На связи мы, Мария и Яна из самой драйвовой IT-команды «БАРС Груп». В этой статье расскажем, как создавали инструмент эффективного взаимодействия в IT-команде — базу знаний постановок задач, которые реализует проектная команда. По порядку разберем, почему мы решили создать шаблон, как разрабатывали и как доводили до ума после внедрения и, конечно, о результатах.

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

На канбан-досках могут быть различные виды задач, в зависимости от конкретного проекта, типа бизнеса или потребностей команды. В этой статье разберём основы ведения учета задач на Канбан-доске, необходимые колонки, виды и типы задач, в том числе Epic, userstory, task.

Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.

Привет, Хабр!

Меня зовут Александр, я занимаюсь релиз менеджментом в ИТ-компании TAGES. Эта работа требует быстрой поставки бизнес-ценности в условиях меняющегося мира. Однако непрерывность регулярных деплоев невозможна без четкого плана. А правильный план, в свою очередь, требует точной оценки трудозатрат.

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

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

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

Привет, хабровчане! Это команда разработки «МосТрансПроекта». Возможно, вы уже читали статью про наш сервис оценки транспортной доступности новостроек «Узнай про ЖК». Если еще нет — велком. Сервис работает уже год и совсем недавно мы запустили ряд обновлений. Расскажем, зачем они были нужны и что это дало пользователям.

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

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

Привет! Меня зовут Александр Омельяненко, я работаю тимлидом Flutter-команды в AGIMA. Расскажу, как и почему на одном из наших проектов мы внедрили компонентный подход к разработке и какие плоды нам это дало. В статье покажу основные плюсы и минусы нашего решения. А еще затрону прикладные моменты: на какие позиции мы поделили участников команды, какие обязанности им поручили и как документировали работу.

Привет, Хабр! Меня зовут Михаил Фандуберин, я Product Owner, отвечающий за авторизацию и онбординг в KION. В прошлом августе я написал статью о повышении конверсии регистраций на примере страницы входа онлайн-кинотеатра KION. Сегодня расскажу о другом проекте — работе со стартовым экраном приложения для улучшения пользовательского опыта и оптимального перераспределения метрики смотрения. Подробности — под катом.

Привет, Хабр!

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

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

Если это Senior Full Stack разработчик с опытом администрирования Linux, то установка и настройка конфигов Nginx, PHP-fpm, MariaDB для него не будут проблемой (а может и с Docker даже знаком?). 

Разработчик Middle уровня (особенно без опыта с backend) возможно пользуется одним из готовых решений под Windows/MacOS.

Junior верстальщик, в свою очередь, раньше не запускал приложение работающее на PHP на своем компьютере вообще, и вот-вот попробует в первый раз.

Было такое? У меня было. Случалось даже поздним вечером помогать новичку с установкой или решением проблемы, возникшей в ходе установки.

А потом, еще через некоторое время, из-за разных конфигов или окружения возникали и новые проблемы из разряда “на моем компьютере же все работает”, которые в том числе могут появиться из-за разных настроек готовых сборок.

Самая популярная в мире CMS (система управления контентом) это WordPress. Почти половина (43%) веб-сайтов в мире управляется с помощью нее, и доля растет ().
Бразильский стартап Deco.cx хочет бросить вызов такому грозному сопернику. В начале года они привлекли раунд в 2,2 млн.$

Деньги планировали потратить на добавление ИИ в свой сервис, и судя по всему уже добавили.

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

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

Меня зовут Евгений Макархин. Я архитектор VK Teams. В этой статье я расскажу, как мессенджер VK Teams прошел путь от внутреннего решения до супераппа и как менялась его архитектура.