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

Машина кружит по заправочной станции на окраине Питера. Подъезжает к колонке, доливает пару литров, отъезжает в парковочный карман, стоит минуту — и всё повторяется снова.

Разомлевший на жаре (на улице июньские 34 градуса!) заправщик у соседней колонки лениво смотрит на происходящее. Кажется, его не удивляет, что два человека в салоне с ноутбуками постоянно что-то кричат третьему — и тот как будто делает всё по команде. Есть ещё один, четвёртый — он бегает и снимает это на телефон.

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

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

Описание построения процесса календарного и оперативного планирования в связке JIRA<->"локальный MSProject" на примере реализации в одном российском банке.

Привет, Хабр! Меня зовут Роман Блинов, я ведущий технический писатель в «Цифре» — в команде по развитию платформы ZIIoT. Этот пост будет о подходе Docs-as-code для документирования разработки ПО. Пишу с прицелом на тех читателей (то есть писателей), кто этот подход пока не пробовал и по факту имеет набор файлов в Confluence, файлы формата .docx и .pdf, на поддержку, обновление и оформление которых тратится порядка 70 % времени (а хотелось бы меньше), и 101 отговорку разработчиков, чтобы не участвовать в документировании.

Сначала расскажу, с какими проблемами сталкиваются писатели до перехода на Docs-as-code, затем опишу подход в общих чертах и в конце упомяну об основной трудности его внедрения по собственному опыту и опыту коллег.

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

Привет, Хабр. Меня зовут Макс. Я специализируюсь на реконструкции и развитии процессов. Сегодняшняя история про баги. Не баги вообще, а про вполне конкретную их категорию.

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

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

Всем привет! Меня зовут Александр Павленко, PHP-разработчик в NIX и спикер NIXMultiConf. В IT-сфере я наблюдаю такую тенденцию: чем масштабнее проект и чем быстрее растет разработка, тем чаще команде приходится менять, расширять логику приложения и улучшать функционал. В крупных проектах постоянный рефакторинг — неизбежный процесс. Иногда за ним скрываются проблемы, но их не стоит бояться. Подобные моменты — отличный шанс получить новые скиллы, прокачать свою экспертизу и получить доверие клиента.

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

Или как понять, когда остановиться

Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:

— Скажи, а зачем нам вообще нужны аналитики?

— И действительно, зачем? – подумал тогда я и написал заявление

Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении  системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.

Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.

Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема. 

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

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

В этой статье ребята из отдела Research and Development расскажут, как они планируют работу над проектами.

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

Одна из задач департамента заботы в Яндекс.Практикуме — организовывать и поддерживать среду внутри компании, оптимальную как для достижения бизнес-результатов, так и для реализации сотрудниками своего потенциала. 

Департамент заботы — внутреннее название, он выполняет две группы задач: operations и human, обеспечивая «заботу» о бизнес-процессах и командах — чтобы процветали и пользователи, и клиенты, и сама компания.

На чем основана работа департамента и как это выглядит на практике, поделилась руководитель Департамента заботы Адель Шадрина.

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

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

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

DELMIA Ortems работает на самых разных предприятиях. И одна из наиболее востребованных отраслей — машиностроение. Ведь именно здесь чаще всего реализуется одна из самых интересных возможностей APS-систем —двухуровневое планирование. В данной статье мы, команда CS Group, расскажем, зачем нужно делить план на две части и как их потом собрать воедино.

Современный подход к планированию производства представляет собой двухуровневую модель:

В преддверии запуска Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.

Периодечески на Хабре, Линкедине и других ресурсах вижу посты о смене профессии на что-то связанное с IT в довольно значительном, по меркам IT, возрасте — после 30 и более. Посты эти, в основном, про истории успеха, что может создать у некоторых людей иллюзию простоты подобной смены профессии. Дошло до того, что один мой знакомый инженер-строитель решил стать QA, ведь он «курсы закончил, да чего там сложного!». Хочу высказать свое мнение и заодно дать несколько советов, которые могут показаться полезными, тем, кто на это решится. Но это не точно. Все, что под катом — лютое ИМХО.

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

Для начала коротко о том, какие технологии легли в основу платформу. Про многие из них мы подробно рассказывали в отдельных статьях.

Привет, Хабр! Поговорим о Лабиринте разработки и о том, как побить рекорды по скорости создания приложений?

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

Мы попали в ловушку, из которой нет выхода? Эксперты КРОК в области DevOps нашли решение и готовы поделиться с вами. Встретимся 9 сентября на онлайн-мероприятии «DevOps-серфинг: инструменты управления потоком создания ценности от КРОК и HCL». 

Впервые представим комплексный инструмент для управления разработкой: решение Value Stream Management, интегрированное с DevOps платформой.

Покажем, как с его помощью наглядно представить каждый этап разработки, упростить взаимодействие функциональных команд и сократить Time to Market ИТ-продуктов в несколько раз.

Интересно? Регистрируйтесь по ссылке:

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

На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.