Продуктовая разработка: инструкция к применению от Red Collar, часть вторая

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

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

И нам важно корректно оценить, какие функциональности являются первостепенными, а какие — дополнительными. И в этом нам поможет Agile.

О том, что такое Agile, написано много и доходчиво. Добавим от себя, что Agile — это не столько методология, сколько философия, в рамках которой с помощью разных инструментов реализуется гибкий подход. Для нас главный инструмент — это Scrum, который как раз и является методологией.

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

Но обо всем по порядку.

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

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

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

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

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

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

Если этап приема работ выпадает, то, собственно, и рушится сама суть подхода.

Также злую шутку с Agile может совершить та самая гибкость, которая является плюсом.

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

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

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

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

Если визуализировать процессы — или правильнее сказать церемонии — в рамках Scrum, то получится эдакий «бублик», состоящий из нескольких слоев.

Внешний слой — это общий цикл работы над цифровым продуктом, внутри которого в параллели идут два потока.

Первый поток — это продуктовый бэклог, спринтовый бэклог и инкремент или демо.

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

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

Инкремент — это как раз та самая фича, которую мы успешно разработали в рамках спринта.

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

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

Второй поток — это процессные рутинные церемонии: планирование спринта, дэйлики, спринт-ревью и ретро.

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

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

Ревью (Sprint Review или Demo) – встреча в конце спринта, на которой команда представляет заинтересованным лицам промежуточный результат работы, чтобы получить обратную связь.

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

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

По сути результат каждого спринта — это готовая работающая фича.

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

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

Задачами, которые мы распределили по спринтам, делимся с командой: дизайнерами, разработчиками и QA-инженерами. Все участники команды начинают работу в параллели.

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

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

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

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

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

Как вы уже догадались, мы ценим Agile за гибкость и прозрачность процессов внутри команды. Также расходование ресурсов должно быть прозрачным и понятным клиенту, поэтому мы работаем по системе «Time&Materials».

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

Итак, спланировав работу по Agile, настроив работу команды по Scrum и отчитавшись о работе по Time&Materials» мы довели проект до логического завершения — его релиза. Но на этом наша работа не заканчивается, достаточно часто в рамках продуктовой разработки мы вместе с заказчиком продолжаем сотрудничество: поддерживаем готовый цифровой продукт, чтобы он был в актуальном состоянии и соответствовал всем задачам и запросам.

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

Stay tuned!