Зачем я это делал

Результаты

Кто отвечал на вопросы?

На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox. 

В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.

Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.

Привет! Меня зовут Юля и я занимаюсь развитием HR/ИТ-бренда в большой корпорации «Ростелеком». Да-да, «Ростелеком» – это не только про «услуги связи», мы – про цифровизацию, инновационные решения и даже квантовые технологии. А еще у нас есть ИТ-кластер, но сегодня не об этом.

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

Под катом расскажу, что работает у нас, чтобы команды хорошо функционировали, разберу методологию Agile, а в самом конце статьи анонсирую небольшой сюрприз:) Если интересно почитать о процессах в корпорации - добро пожаловать под кат!:)

Привет! Меня зовут Женя, я IT-менеджер в продукте QIWI Кошелек, над которым работают 5 фиче-команд (на начало написания статьи). В этом посте расскажу вам про наш опыт внедрения OKR («Цели и ключевые результаты», Objectives and Key Result») для непрерывного улучшения процессов разработки и развития инженерных практик. Как мы всё это делали, как теперь выглядят наши процесс и что нам дал OKR — под катом.

Привет, Хабр! Меня зовут Артур Темиров, я delivery‑менеджер в одном из продуктов X5 (о нём дальше в тексте). Над его созданием у нас трудятся 5 технических команд — в общей сложности это более 60 человек. В статье рассказываю о том, как визуализация является отправной точкой для эволюционного развития процессов, а также об ошибках, которые могут допускаться на этом пути.

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

Меня зовут Иван Кесель, я CPO в Домклик, лидер нескольких команд. Давайте поговорим про disrupt. Во-первых, разберёмся, что это за англицизм. Во-вторых, на примере из практики Домклика я покажу, как мы запускаем disrupt-решения. И в-третьих, дам вам десять подробных практических советов, которые нам помогают. 

Про приоритизацию багов, подходы и сложности, с которыми сталкивался. Как правило, все знают про severity и priority, но практически никто не говорит об urgency, вот про это и расскажу.

Дорогой читатель, в этом посте мы с тобой рассмотрим 6 аббревиатур и подумаем когда их применение уместно.

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

По крайней мере такое решение я, как scrum master и Agile coach определила внутри нашего коллектива, когда столкнулась с такими высказываниями во время обсуждений на ретроспективах и других встречах. Коллектив, на примере которого я предлагаю вам сегодня разобрать опыт ведения стратегической сессии, – gamedev паблишер, где работают продюсеры, маркетологи, аналитики, копирайтеры и другие специалисты.

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

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

Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.

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

А хотите, я расскажу вам сказку, про то, как одна компания решила перейти на agile working model, и в региональное представительство в России искало себе Agile‑мастера?

Этот пост в какой‑то мере вдохновлен обсуждениями про управление персоналом, которые почему‑то особенно мне близки и нравятся, хотя я никак не связан с HR службой. История будет без имен и лиц, почти не выдумана. Не в формате нытья, а наоборот, ради позитивного подхода к работе:)

Итак, есть великолепная инициатива штаб‑квартиры — что, мол, все региональные офисы независимо от объёма работы и уровня разработки должны у себя внедрить Аджайл, и сделать это за 9 месяцев, условно с января по октябрь. Да, скорее всего в других офисах и самой штаб‑квартире этот проект разрабатывали годами, но до российской дочки докопались только сейчас.

А может и раньше докопались, да только Тимлид ДепОпс (которому видимо и был поручен проект трансформации) откладывал все вопросы на «потом», а как этот потом наступил, понял, что его дико грузят вопросы безопасности и не менее бесят темы аджайла… свалил в общем.

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

BRD (Business Requirements Document) — это документ, который описывает бизнес-требования для проекта или продукта. BRD используется для установления и документирования функциональных и нефункциональных требований, целей и ожиданий заказчика. Вот некоторые шаги, которые помогут вам написать BRD:

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

Наладить работу с проектами не так просто. Для этого разработаны специальные методы. Один из них пришелся по душе большинству бизнесменов. Название его — Agile. Метод оценили пользователи, имеющих многогранный и постоянный поток заданий со сложными и часто меняющимися условиями. Что представляет собой Agile, какие этапы внедрения, какие имеет положительные и отрицательные стороны?

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

Для тех, кто знаком с другими методами эмпирического прогнозирования (например, методом «Вчерашней погоды» из Scrum) материал также может быть интересен.

Усилия монопродуктовых компаний сосредоточены вокруг одного продукта или сервиса. Однако не ждите, что команда мечты появится у вас уже завтра по щелчку пальцев. Для слаженной работы над продуктом важен грамотно подобранный состав участников, правильное распределение ролей в процессе разработки, а также четко продуманный набор компетенций для каждого. Каким образом организовать работу, если у вас 16 продуктовых команд и все они работают над созданием и развитием одного проекта?

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

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

Прогресс когда-то сместился от железа к софту, и всё самое передовое, то что называется “Research” в слове RnD оттянули на себя разработчики софта. Это видно по крайней мере по объему вакансий и зарплате разработчиков.

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

Привет, Хабр! На связи DevRel-команда inDrive. Мы прошли путь от стартапа из Якутии до компании с продуктом, которым пользуются в 47 странах мира. В процессе мы поняли важность culture fit — насколько хорошо вписывается разработчик в инженерную культуру компании. Мы представили её в виде пирамиды по аналогии с пирамидой Маслоу. 

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

Искусство и наука об оценки в IT:

 — Наука оценки хорошо развита и хорошо поддерживается программными инструментами.

— Искусство оценки преимущественно основано на эмпирических правилах и их еще нужно немного доработать.