Кто делает UX на Scrum-проекте?

ХОРОШО. Допустим, вы работаете над проектом Scrum из учебника. У вас есть мастер схватки, сотрудничающий с владельцем продукта. Следующий спринт UI-тяжелый - к тому времени ваших кодеры начинают строить экраны, вы действительно хотите иметь некоторое представление , что они будут выглядеть.

Кто делает каркас и когда? Владелец продукта? Кто-нибудь поддерживает владельца продукта? Скрам мастер? Если у вас есть эксперт по UX, работают ли они вместе с кодировщиками после начала спринта, или они предоставляют каркасы и макеты заранее, которые лежат рядом с вашими историческими картами и ограничениями, чтобы направлять и информировать работу, которую делают разработчики?

Видите ли, я уверен, что нам нужна помощь UX, но я действительно не уверен, где ее применить ...

РЕДАКТИРОВАТЬ: Позвольте мне перефразировать вопрос.

Как вы обеспечиваете согласованное, высококачественное взаимодействие с пользователем в гибком проекте?

Дизайнер взаимодействия

UX! = UI Вам нужен опытный дизайнер взаимодействия, чтобы обеспечить хороший пользовательский опыт, вопреки распространенному мнению, что это не программист. Для всех вас, программистов, которые думают, что они могут делать UX (включая меня), позвольте мне сказать это. Чтобы научиться интерактивному дизайну, нужно как минимум столько же времени, сколько и для программирования. Сколько времени вы потратили на создание чистого интерактивного дизайна?

На начальном этапе разработчики взаимодействия должны:

1. Извлечение фактических целей решения от владельца продукта
2. Определите персон, которые будут использовать решение.
3. Напишите сценарии, рассказывающие о том, как будет использоваться решение.
4. Скомпилируйте проектный документ, который оставляет мало места для двусмысленности с точки зрения UX

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

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

Как всегда, я настоятельно рекомендую книги Алана Куперса на эту тему («О лице» и «Заключенные управляют убежищем»)

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

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

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

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

Редактировать:

Я провел дополнительное исследование, потому что знал, что где-то читал об этом, и, наконец, я нашел его в книге «Успешный Agile: разработка программного обеспечения с использованием Scrum» Майка Кона . Майк обсуждает именно роль дизайнера UX в команде. Его первоначальное описание аналогично моему, и он рассматривает его как естественный сдвиг, когда компания меняет метод разработки с водопада на Scrum, но позже он делает вывод, что это не рекомендуется. Причина в том, что если дизайнеры UX не являются частью команды, они могут думать о себе как о отдельной команде, и им не нужно делиться обязательствами команды разработчиков.

Несмотря на это, ответ @ Adam Byrtek выглядит верным. Сделайте UX парень частью команды и позвольте ему сотрудничать с разработчиками над уже реализованными пользовательскими историями. Парню из UX не понадобится все время, поэтому он также будет сотрудничать с владельцем продукта или клиентом, чтобы подготовить макеты и каркасы для начала одного или двух спринтов.

Я подписан на рассылку предупреждений Якоба Нильсена (в основном из-за его критики по поводу назойливых практик веб-дизайна), и я вспоминаю, что недавно прочитал несколько статей по этой теме (хотя у меня едва ли есть хоть какое-то понимание всего процесса гибкой разработки), возможно, они будут любого использования для вас:

• Agile User Experience Projects
• Agile Development Projects и удобство использования

Для "учебника Scrum":

Во-первых, Scrum Masters не сотрудничают с Владельцами Продуктов - ну, ни в коем случае, кроме этого, вся команда, включая SM и PO, сотрудничает для построения системы.

Во-вторых, команды Scrum должны быть однородными с кросс-функциональными членами команды. Таким образом, у вас не будет "UX Guy".

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

Кто делает UX на проекте водопада? Кто занимается разработкой мэйнфреймов для проекта XP?

Методология проекта не имеет значения. Каждый технологический проект требует определенных специализированных ролей. Иногда проект может обойтись без полностью лицензированного и связанного «проектировщика взаимодействия» (что бы это ни значило). Иногда вам нужен кто-то специализированный. Но то же самое можно сказать и о любой другой роли.

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

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

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

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

На практике я склоняюсь к тому, что разработчикам UI / UX требуется разумное время для решения вопросов, которые должны быть согласованы во всем решении. Мне нравится думать об этом как о программной архитектуре. Конкретный дизайн компонентов часто может быть выполнен спринтом до реализации, но я склонен находить, что, как только дизайнеры начинают работать, они могут значительно ускорить реализацию. Более поздние спринты, как правило, являются хорошими местами для реализации / изучения внешнего вида, а также для получения обратной связи по удобству использования, когда решение начинает обретать форму. Результаты этих более поздних упражнений возвращаются к планированию следующего спринта.