Несмотря на то, что прошло уже почти 10 лет, как я написал (в соавторстве) книгу, читаю лекции, преподаю и провожу тренинги на эту тему, мне все еще задают много вопросов. В основном продакт-менеджеры, исполнительные руководители и технические менеджеры спрашивают меня о том, как интегрировать UX и дизайн в процесс SCRUM-разработки. Это сложная задача, с который продолжает сталкиваться большинство организаций, главным образом потому, что причина, по которой SCRUM был принят, заключалась в том, чтобы вместо более продуманной, ориентированной на клиента работы, быстрее и больше кодить.
Я работал с командами, которые справились с этой задачей. Этот опыт зафиксирован в моих публикациях, книгах и уроках. Недавно я имел удовольствие работать с соавтором моей книги Джошем Сейденом и несколькими умными, прогрессивными членами общин Agile и Scrum. Вместе мы работаем над созданием фреймворка, который шаг за шагом разъясняет, как интегрируются UX-дизайн и SCRUM. Одно упражнение, которое каждый из нас проделал индивидуально, состояло в том, чтобы наложить UX и дизайн на вершину хорошо обоснованной модели SCRUM. Схема ниже — моя попытка выполнить это упражнение.
Когда вы посмотрите ее, учтите следующие оговорки:
- Это далеко не полный перечень дизайнерской деятельности. Не хватит статьи, чтобы расписать все. 🙂
- Я использую слово «Дизайн» (часто с заглавной «Д»), в качестве обобщающего термина для всех видов деятельности, которую обычно выполняют или в которой участвуют дизайнеры всех видов
- Меня не особенно интересуют бездонные глубины определений «Дизайн», «UX» и др. Мы оставим этот вопрос для другой статьи.
Я пронумеровал каждую группу UX-операций. Ниже приведены краткие описания и мои обоснования для каждой группы.
- Бэклог продукта содержит фрагменты более широкого видения, над которыми не будут работать в текущем спринте. Здесь присутствуют элементы высокого уровня, концепция и многие предположения. Чтобы сообщить о бэклоге продукта, такие действия, как «Дизайн-спринты», «Исследования» (качественные, всех типов) и написание гипотез, помогают добавить этим элементам, как реальность, так и ориентированный на клиента фокус.
- Планирование спринтов — это ежедневная задача для команды. Ответы на такие вопросы, как: «Как это будет выглядеть?», «Каким будет процесс перехода с экрана на экран?», «Какие исключения нам нужно учесть?», можно получить с помощью таких инструментов проектирования, как Collaborative Sketching (aka «Дизайнерские студии», «charettes»
и т. д. ) и других видов мозгового штурма, которые особенно нравятся UX-дизайнерам. - Тактическая Дизайн-работа (заглавная «Д», чтобы служить в качестве обещающего термина для различных аспектов продуктового дизайна) должна войти в тактический бэклог — бэклог спринта, а затем выполняться в первую очередь дизайнерами, но в сотрудничестве с остальными членами SCRUM-команды. Ключевым моментом является приоритизация этой работы таким образом, чтобы все члены команды могли работать параллельно.
- Для интеграции UX дизайна в SCRUM-разработку команде критически необходим дизайнер на полную ставку. Он — единственный способ обеспечить параллельное сотрудничество с разработчиками и продакт-менеджерами (тактика из пункта # 3).
- Обзор спринта — это возможность всем вместе взглянуть на результат командной работы, проделанной во время спринта. Это также возможность просмотреть, что мы узнали во время спринта (итоги). Такие виды деятельности, как обзоры дизайна, обсуждения и дискуссии по синтезу исследований и количественному анализу помогают нам сфокусировать следующий раунд разработки на приоритетах бэклога продукта и спринта.
Крайне важно отметить, что все это невозможно без специального дизайнера, прикрепленного к SCRUM-команде. Именно его присутствие гарантирует, что соответствующие виды деятельности предлагаются, расставляются по приоритетам и выполняются. Если работа над дизайном передается стороннему дизайнеру вне команды (независимо от того, является ли этот дизайнер корпоративным или нет), то команда снова работает в стиле «Big Design Up Front», который также известен, как каскадная модель — все это сокращает сотрудничество, общее понимание и доверие между членами команды.
Что вы думаете? Что я упустил или забыл? Что бы вы сделали это по-другому?
Я бы хотел узнать ваше мнение.
Нет комментариев