Щелчок тумблера, и теперь мы не программисты, но разработчики продукта :)
Шутка. Нет волшебного переключателя, которым можно было бы щёлкнуть, чтобы все сразу заработали по-новому. Кто-то уже несколько лет делал работу на всех слоях, а кто-то не начнёт и в новой должности.
Фактически уже несколько лет мы двигались в Scrum и LESS. Теперь и на формальном уровне. Никаких больше узко специализированных должностей. Нет больше фронтендеров, мобильников, бэкендеров, дбд, тестировщиков. Есть разработчики продукта с Т-shape или Ш-shape экспертизой. Не всем это подходит, но вариантов нет. Больше не получится тыкать пальцем "это вон у бэкендеров апи кривое". Придётся всей командой проектировать контракт апи.
Придётся брать на себя больше ответственности.
Никого не увольняют, но подозреваю что не всем подойдёт новая реальность, и кто-то уйдет искать привычное болото в менее прогрессивные конторы.

​Продуктовый. Разработчик.

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

IT с точки зрения программиста, который не ограничивает свою зону ответственности кодированием. И имеет от этого некоторые явные и не очень профиты.

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

Этот канал - про взгляд изнутри на образ мышления, роли, процессы, события и артефакты продуктовой разработки.

Продукт vs Проект

Попробую объяснить, что такое продукт, через сравнение с проектом.

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

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

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

Scrum - это ответ! А какой был ваш вопрос?🙃

Очень часто слышу от людей из разных контор, что вот мол у них Scrum.
А потом от них же слышу “этот _ваш_ скрам не работает”. Потом оказывается, что они просто отсчитывают итерации по две недели. А еще у них четко разделены функции: вот спринт бэкендеров, вот спринт фронтендеров, вот спринт разработчиков баз данных. И планирование спринтов у них раздельное. И каждая функциональная команда является “внешней” для другой функциональной команды. И когда фронтендерам нужно какое-то API, они заводят задачу бэкендерам. Вот такой “этот ваш скрам” точно не работает.

А у нас работает. Но не совсем скрам. Мы руководствуемся теорией ограничений и понимаем что тру-скрам трудно достижим. Это обусловлено в первую очередь нашими ограничениями: большой продукт, большая популяция айтишников, большая база легаси кода и легаси процессов, смежные IT подразделения, работающие с процессами локальных очередей. Мы работаем по фреймворку, который скромно называем Scrum-based LeSS-like.
Основных идей три:
📌- уменьшать количество бэклогов
📌- собрать все нужные компетенции в одной команде
📌- уменьшать внешние зависимости

Роли

В этом нашем Scrum-Based LeSS-Like мы выделяем 5 ролей, хотя скрам подразумевает всего 3.

Chief Product Owner - Имеет верхнеуровневое видение вектора развития продукта в целом. Взаимодействует с продуктовыми командами, передает это видение.

Area Product Owner - отвечает за определенную зону продукта. Приоритезирует задачи в бэклоге зоны, чтобы максимизировать ценность своей зоны продукта; Плотно работает с командами в своей зоне;

Product developer - создает качественный регулярный инкремент в продукт. Обычно работают со своим APO;

Product IT Manager - помогает разработчикам продукта поддерживать вектор развития инженерных практик и процессов разработки. И индивидуального развития самих разработчиков;

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

Запись в трудовой

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

​​Ок. Теперь ты продуктовый разработчик. Что дальше?

В серии из 4 постов расскажу о цикле разработки с точки зрения изнутри.

Часть 1 - проработка бэклога.

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

Это не исчерпывающий список, я покажу наш Definition of Ready for sprint (DoR) позже.

Часть 2 - планирование спринта

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

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

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

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

Часть 3 - работа в спринте

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

Каждое утро команда собирается, чтобы ответить на один вопрос: "всё ли идёт по плану?" Даже при идеальном планировании может случиться влёт. В таком случае нужно либо срезать часть работы, либо использовать резервное время. Если его заложили, конечно. Сидеть вечерами - точно не путь к успеху. Это путь к выгоранию. Лучше как можно раньше увидеть отклонение от плана и договориться с владельцем продукта о срезании каких-то критериев приемки.

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

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

Часть 4 - ревью спринта

В конце спринта происходит встреча всех команд продукта. Кто-то называет это событие Демо. Раньше у нас тоже было демо. Но в какой-то момент мы изменили формат встречи и теперь проводим ревью спринта.

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

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

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

​Как ретроспектива отражает этап становления команды

Цель ретроспективы - проинспектировать процесс и договориться об изменениях.
Мы ощутили на себе все этапы по Брюсу Такмену, и ретро спринта очень наглядно это показывало.

Forming. Сначала мы тупо молчали. Не понятно было, зачем собрались. Не понятно как (или страшно) давать обратную связь. Побухтели, вроде всё норм, разошлись. Никаких решений не приняли.

Storming. Это время киданием говняхами. Сложное время, но неизбежное. Зрелый и самодостаточный персонаж использует это время с пользой. На этом этапе на ретроспективе мы принимали эмоциональные "договоренности", которые сами потом не соблюдали. И это был еще один повод для кидания говняхами.

Norming. Научились давать ненасильственную обратную связь. Пошли первые рабочие решения на ретро. Их всё еще мало, но продуктивность команды уже вышла на уровень почти форминга.

Performing. Не смотря на конец спринта, чувствуется драйв. Есть что обсудить. Ретроспективы проходят динамично, конкретно и с четкими решениями. Обратная связь конструктивная.

​Три лайфхака к ретроспективе

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

1️⃣ Собирать темы во время спринта

Пример из нашего чатика:
#ретро не учли потенциальную нагрузку на сервис и забыли про нагрузочное тестирование. Добавить пункт DoR?

Во время спринта процессные боли или предложения мы паркуем с хэштегом #ретро.
Это позволяет нам не отвлекаться в спринте и иметь актуальные темы для обсуждения на ретроспективе.


2️⃣ Найти свой инструмент

В оффлайне проводили с доской и стикерами.
В условиях удалёнки встал вопрос инструмента: пробовали в гугло-таблицах и Miro. Потом наш PO где-то откопал инструмент https://easyretro.io/
Это простая общая доска со столбцами, куда каждый участник может накидать карточек, ставить лайки и комментировать. Есть шаблоны для разных форматов проведения ретро. Теперь пользуемся им.


3️⃣ Некоторые решения можно отложить

Если тема важная, но обсуждение буксует и сходу принять решение не получается, то есть выход: "Вася составит агенду и проведёт встречу по проблеме в следующем спринте".
Чем четче и понятнее предложение, - тем больше шанс что его примут. Такое предложение обречено на успех. Оно отвечает на вопросы:
- что?
- кто?
- когда?

​Discovery vs Delivery, ч.1

Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.

Процесс проработки бэклога не очень подробно описан в Scrum, но по идее он подразумевает вовлечение всей команды.
В отличие от проектной работы, в продуктовой разработке задачи попадают в бэклог совсем сырыми.
Перед тем, как думать о коде, нужно доуточнить и согласовать бизнесовую постановку, требования, ожидаемый эффект.
В эту работу не получается продуктивно вовлечь всю команду.
С другой стороны, разделение участников команды на Discovery и Delivery по сути делит команду пополам. Скрам явно не про это.

Ага! Этот ваш скрам не работает!

На помощь приходит Jeff Patton и его Dual-Track development. Он говорит, что Discovery и Delivery - это два направления работы одной команды.

Посмотрите на картинку.
Снизу - спринты Scrum, а сверху что?
- циклы вариативной длины
- непрерывная поставка задач, готовых к спринту

добавим к этому визуализацию процесса через столбцы на доске + лимиты work in progress...

Да это ж Kanban!

Выходит, что мы в этом своём Scrum-based LeSS-like добавляем еще "Kanban-discovered"?

Оригиналная статья Jeff Patton
Адаптация Авито и их опыт
Сравнение Scrum и Kanban от Atlassian