Что такое Scrum?

Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.

Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.

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

А теперь представьте, что вы создаёте цифровой продукт в роли PO, CPO или CTO. Тогда вы столкнетесь не только с несогласованным дизайном, но также с неуправляемым бэклогом (план против реальности), задержками выпуска версий и постоянными переделками функционала после выхода в продакшн.

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

Около года назад мы в команде всерьез задумались о пересмотре сроков среднесрочного планирования. И всему виной наш любимый производственный календарь РФ. Но начнем издалека.

Традиционно мы привыкли встречаться раз в три месяца, квартал, ставить цели, возвращаться через квартал подводить итоги, ставить новые цели и так до бесконечности (хочется верить).

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

Чтобы достичь этой цели, мы решили сделать необычное (конечно, нет) – сделать ставку на масштабирование команды, улучшение процессов планирования и разработки. Самое главное: выпустить версию 2.0. Это должна была быть написанная с нуля новая онлайн-доска, которая возьмёт всё самое лучшее от предыдущих двух лет существования продукта (версии 1.0), но для новой целевой аудитории - бизнеса. В том числе с возможностью поставки в контур заказчика. Спойлер: мы это сделали.

При этом надо было помнить, что компания является стартапом и не может позволить себе раздуть ФОТ, погрязнуть в кризисе роста и потерять общую эффективность, которая складывается из результатов каждого члена команды.

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

Все предыдущие года, мы ставили себе цели на периоды по три месяца: с января по март, с апреля по июнь, с июля по... Ну вы поняли. И нас все устраивало, но был важный нюанс. Все это время мы работали супер небольшой командой, часть из которой была представлена аутстафом и жила вообще не по трудовому календарю РФ. Что уж говорить про фаундеров, которые всеми силами выбирались из долины смерти, иногда забывая про сон.

Л - Добрый день, дорогие зрители, сегодня мы продолжаем нашу серию репортажей «Стартаперы Кварцевой Лощины». С вами снова я, независимый журналист, Лайер Бала-Больё, и сегодня наш гость - талантливый селфмейд, добившийся всего сам, 19-летний сын известного миллиардера, стартапер Жу̒лико Бары̒гги младший.

Жулико уже выпустил два сверхполезных и сверхнужных приложения, это всем известный SriiPee для заказа пиццы прямо с унитаза и HeyGey – апп для поиска скоплений бородатых мужчин в клетчатых рубашках, любящих фруктовые коктейли и самокаты. Последнее приложение даже автоматически предустанавливается в каждый новый грушефон.

Жулико, вы только что были спикером на проходящем в Сан-Дьябло Блаблатоне и упомянули такую интересную вещь, как ШвабрОпс - можете рассказать нашим зрителям, что это такое и с чем его едят.

Ж – Привет, Лайер, привет всем. Да, на Блаблатоне я рассказывал про ШвабрОпс – это новое перспективное направление в IT. Дело было так. Я маялс…т.е. интенсивно работал в офисе и обратил внимание, что какой-то очкастый толстый задрот ходит туда-сюда из кабинета в кабинет. Я спросил секретаршу – кто это такой? Она ответила – это наш ДевОпс.

Л – Ага.

Ж – А я, если честно, даже не знаю, кто это такой. Но мне тут же в голову пришла идея. А что, если он возьмет в руки швабру и будет протирать пол, пока ходит туда-сюда.

Л – Угу.

Ж – Ну и все, собственно. Я подумал-подумал и решил – а зачем нам уборщица?! Пусть этот дев…как его там…в общем – пусть он еще и пол протирает параллельно. Это же какая экономия получается!  

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

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

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Не знаю, как в других странах, а у нас любят увлекаться идеей использовать какой-то, довольно узкий, инструмент, как панацею.

Получилось забить гвоздь молотком – получилось. Давайте попробуем с помощью молотка почистить фарфоровую посуду от налета. Ну очевидно же!

Не избежал этой участи и пресловутый Agile. Так называемые гибкие методологии разработки. Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности, в обучении – всюду, куда фантазии хватит его вставить.

А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Всем привет, меня зовут Андрей Гирин, и я agile-коуч в РТЛабс. Десять лет назад я был руководителем проекта с небольшой командой, а сейчас помогаю строить команды другим.

Недавно я был с воркшопом, посвящённым star map, на профессиональной конференции для тимлидов Saint TeamLead Conf, о чём моя коллега Екатерина не так давно писала в посте.

Эта небольшая статья о том, как и почему эта идея вообще появилась.

Привет! Меня зовут Ксения, я руководитель продуктов в SM Lab. Хочу поделиться нашим опытом изменения воркфлоу работы с бизнесом — здесь и допиливание ряда процессов, и улучшение согласования между отделами, и доработка отчетов, да и вообще, много полезного.

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

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

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

Всем привет! Я Евгений Степченко, деливери-менеджер в Тинькофф. Расскажу про подход к анализу и улучшению процессов, который называется STATIK, System Thinking Approach To Introducing Kanban — применение системного мышления при анализе и проектировании канбан-систем. Поговорим о том, как устроен этот подход и как он помогает запускать эволюционные изменения.

Статья будет полезна тем, кто вовлечен в управление процессами и изменениями на основе канбан-метода. Если вы плохо знакомы с методом, советую сначала изучить официальное руководство. В конце статьи я поделюсь другими полезными ссылками по теме.

Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье. 

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

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

Результаты

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

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

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

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

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

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

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

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

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

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

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

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

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

Меня зовут Тимур Исхаков, я технический директор в Ak Bars Digital. Мы отвечаем за развитие ИТ Ак Барс Банка. 

В 2016 году, когда наша компания стартовала, мы сразу «пошли» в цифровизацию и аджайл. Начали со Scrum, которым уже тогда никого было не удивить: кросс-функциональные команды, Product Owners, пользовательские истории — выращивали продуктовую разработку. 

С 2018 года мы стали работать по SAFe: стримы, каналы, бизнес-юниты — вот это вот всё. И как результат — в 2021 году Ак Барс Банк занял 4 место в рейтинге самых инновационных банков России, а мобильное приложение Ак Барс Онлайн 3 года подряд входит в ТОП-3 лучших мобильных банков по версии Markswebb. 

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