Включение UX-задач в бэклог при подходе Agile
Перевод статьи Рэйчел Краузе.
Краткое содержание: есть три модели формирования бэклога, которые позволяют командам уделять внимание работе с качеством пользовательского опыта. Каждая модель имеет свои достоинства и недостатки.
Определение: бэклог — это список задач, упорядоченный по их приоритетности. В него входит разработка нового функционала и обновление уже существующего, исправление ошибок, и другие активности, например работа с UX-долгом. Выполнение задач из списка требуется для успешного завершения проекта.
Нет жестких правил о составлении бэклога при Agile-подходе — каждая команда может структурировать свой бэклог по-своему. Это скорее плюс: у каждой команды свой подход к работе, поэтому навязывать всем командам один способ было бы непрактично. Но из-за гибкости подхода и отсутствия жестких правил, исследования пользовательского опыта иногда остаются за бортом процесса.
Бэклог при аджайл-подходе.
В большинстве команд, работающих по Agile, при разработке функционала ведут документацию в формате user stories. Для каждой user story указывается:
- критерий приемки (требования к готовому функционалу)
- оценка сложности работ, которые потребуются для реализации соответствующего функционала.
Затем user stories расставляют в порядке приоритетности — в зависимости от нужд стейкхолдеров, бизнеса и команды.
Приоритизация — важный шаг для любой команды, работающей по Agile. В ходе нее решается, какие user stories будут “закрыты” в текущем спринте. User stories, связанные с качеством пользовательского опыта, могут получать меньший приоритет, чем те, которые связаны с разработкой функционала. Это зависит от того, насколько стейкхолдеры убеждены в ценности UX.
Структура бэклога
Команды, работающие по Agile, часто сталкиваются с дилеммой: стоит ли им использовать один-единственный бэклог, в который входят в т.ч. UX-работы, или заводить для них отдельный бэклог?
Оба метода могут быть успешны — в зависимости от того, как они применяются. В основе лежит понимание того, как работает команда и как много влияния на бэклог у стейкхолдеров.
Давайте изучим достоинства и недостатки разных моделей формирования бэклога.
1) Общий бэклог: пункты по UX и разработке вместе
Общий бэклог содержит в себе все активности по продукту, включая разработку, UX-работы и контроль качества.
В приведенном выше примере бэклога, спринт состоит из 4 пунктов, каждый из которых оценен в story points. Пункт, выделенный синим, Прототип: улучшения по фильтрации, — это особая UX-работа, связанная со сборкой и тестированием прототипа.
В общем бэклоге UX-работы приоретизируются и оцениваются по тому же принципу, что и все остальные. Выделять UX-работы можно по тэгам, особому наименованию (например, добавляя префикс UX-) или используя специальные возможности ПО для управления проектами (например, ставя метки или категории).
Достоинства
Этот метод делает UX-работы явными для команды и стейкхолдеров.
Каждый может заглянуть в бэклог и посмотреть, какие есть UX-работы. Особая разметка в ПО для управления проектами позволяет легко фильтровать UX-работы.
Пункты бэклога с UX-работами чаще большие и глобальные, чем маленькие и конкретные.
Это полезно для дизайнеров, которые хотят мысленно охватить весь поток работ или взаимодействий пользователя, а не только их отдельные части. Обычно user stories в бэклоге очень конкретны и предполагаются к реализации за один спринт. Однако при этом часто приходится держать UX-работы в уме (на более высоком уровне) — ради уверенности в том, что:
- интерфейс получается единообразным
- дизайн интерфейса допускает более широкий взгляд на него.
Таким образом, введение в бэклог отдельных UX-пунктов не ограничивает общий объем UX-работ.
Недостатки
Стейкхолдеры могут снижать приоритет UX-пунктов — чтобы повысить приоритет работ по разработке нового функционала.
Особенно если они не видят в UX-исследованиях ценности. Если ваши стейкхолдеры на постоянной основе занижают приоритет работ, связанных с улучшением пользовательского опыта, в ваших же интересах будет опробовать одну из двух других моделей бэклога, описанных ниже в статье.
Усложняется отслеживание очередности работ.
UX-работы могут повлиять на другие пункты бэклога. Это значит, что придется заранее решать, что должно быть сделано в первую очередь. Борьба с этим недостатком упрощается, если вы используете тэги или категории в ПО для управления проектами. Однако, нужно уделять особое внимание очередности, чтобы избегать полноценной разработки функционала до того, как будут выполнены относящиеся к нему UX-работы.
2) Общий бэклог с делением пунктов на задачи для разных членов команды
Второй метод организации бэклога основан на разбиении каждого пункта на отдельные задачи для членов команды с разными компетенциями (например, на UX-задачи и задачи по разработке).
Приоритет
В этом примере, пункт бэклога Улучшения по фильтрации подразделяется на 4 задачи — некоторые для UX, некоторые для разработчиков и QA. Этот пункт бэклога считается выполненным, когда выполнены все задачи.
В этой модели бэклога, UX-задачи добавляются в любой пункт бэклога, где требуется соответствующая работа. Такими задачами могут быть исследования, дизайн и юзабилити-тесты.
Достоинства
Этот метод работает лучше всего, когда дизайн и разработка какого-то функционала могут быть выполнены за один спринт.
Обычно такое возможно в ситуации, когда команда работает в хорошо знакомой области и с небольшими либо очень узкими дизайн-проблемами. Так как все члены команды выполняют работают одновременно, нужны гарантии того, что UX-задачи не тормозят процесс для остальной команды.
Легкодоступный чеклист задач для выполнения каждого пункта бэклога.
Каждый член команды может иметь задачу в каком-либо пункте бэклога. Таким образом, отслеживать очередность разных работ проще, чем при общем бэклоге. Также упрощается отслеживание того, что сделано, и что предстоит сделать.
Недостатки
Команда должна быть опытной в оценке сложности работ.
Так как разные члены команды могут работать над одним пунктом бэклога, оценивание работ может стать более запутанным. Некоторые команды предпочитают использовать т.н. покер планирования или последовательность Фибоначчи для оценки задач по разработке и аналогии с размерами футболок для UX-задач.
Есть вероятность, что вы будете переносить пункты бэклога из спринта в спринт — в зависимости от прогресса по отдельным задачам в этом пункте.
К примеру, если работа с результатами фидбека от пользователей — это UX-задача, которая не будет выполнена до конца спринта, то связанная с ней задача по разработке функционала переносится в следующий спринт, как и весь пункт бэклога.
3) Несколько бэклогов
Последняя модель предполагает ведение разных бэклогов, каждый для своего набора компетенций. Например, разные бэклоги для работ по UX и по разработке. В основном, эта модель рекомендуется, только если вы уже попробовали две предыдущие, т.к. ведение нескольких бэклогов требует дополнительной дисциплины и коммуникации. Этот метод также подходит для обособленных UX-команд или команд, в составе которых есть члены с разными компетенциями в UX.
В этом примере, продуктовый бэклог и UX-бэклог разделены. UX-бэклог состоит из работ, основанных на пунктах продуктового бэклога. В этом случае по-прежнему остается основной бэклог с пунктами по новому функционалу, фидбэку пользователей, багам и пр. Отдельный UX-бэклог включает все UX-активности. От вас и вашего product owner будет зависеть своевременная работа над правильными задачами. В некоторых случаях, чтобы направить разработку в верное русло, UX-специалистам стоит проработать что-то до того, как к этому приступят другие члены команды. Так, если в основном бэклоге есть пункт Оповещения о возможных клиентах, нужно удостовериться, что до начала разработки соответствующего функционала будет выполнена задача Дизайн-спринт: оповещения о возможных клиентах из UX-бэклога.
Достоинства
UX-специалисты полностью отвечают за свой бэклог.
UX-команда сама принимает решения о том, что и когда должно быть сделано, и может спланировать свою работу над предстоящими пунктами бэклога. Также, исходя из того, что работа UX-специалистов опережает разработку, меньше вероятность, что они будут задерживать разработку.
Отдельный UX-бэклог можно масштабировать с учетом разных компетенций в UX-команде и разных команд разработки.
Если в компании большая UX-команда из людей с разными компетенциями, каждый ее член может работать над задачами в зоне своих компетенций. Кроме этого, если над одним продуктом работают несколько команд разработки (например, разные команды для iOS-, Android- и веб-версий), то сведение всех UX-работ в одном бэклоге помогает поддерживать согласованность команд.
Недостатки
Сложно рассчитывать общую скорость работы команд
Так как UX-команда работает с отдельным бэклогом, ее скорость не совпадает со скоростью команды разработки. (Некоторые команды не считают время, затраченное на UX-работы, частью времени, потраченного командой, тогда этот пункт не является минусом).
Риск чрезмерного опережения разработки
При планировании пунктов продуктового бэклога заранее, рекомендуется сфокусировать большинство усилий на пунктах в текущем и следующем спринте. Если UX-команда, опережая разработку, работает над чем-либо кроме первичных исследований, есть большой риск потерять результаты этой работы, если соответствующие пункты продуктового бэклога будут понижены в приоритете.
Заключение
Структура бэклога может меняться от команды к команде и от проекта к проекту. Плюс бэклогов в том, что вы можете и должны проявлять гибкость. Не бойтесь смешивать и сочетать разные методы, пока не найдете то, что сработает для вашей команды.