UX дизайнеры работают на один Sprint вперед

У наших UX-дизайнеров в Sprint X обычно есть история, которую разработчики будут реализовывать в Sprint X + 1 (UX-разработчики и разработчики / тестеры работают в одной команде). Я думаю, что это имеет смысл, потому что, если у вас нет макетов экрана и четких спецификаций, вы не сможете оценить работу во время планирования спринта.

Однако в Scrum вы должны иметь только те пользовательские истории, которые представляют ценность для пользователя. В нашем случае истории UX-дизайна не дают такой ценности (они больше похожи на работу по отставанию). Также обычно тренеры Scrum не рекомендуют иметь полные спецификации перед началом Sprint, рекомендация, которую я нахожу трудной для понимания.

Итак, вы видите какие-либо недостатки в нашем подходе? Кажется, это работает для нас, но это несколько противоречит принципам Scrum.

Однако в Scrum вы должны иметь только те пользовательские истории, которые представляют ценность для пользователя.

Значение не измеряется только в строках отправляемого кода.

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

Не зацикливайтесь на догме о схватке. Скрам призван сделать вас более эффективным. Если создание UX-истории одним спринтом до того, как вы внедрите UI, поможет вам предоставить лучшее программное обеспечение, сделайте это.

Основными недостатками являются следующие:

1. Вы работаете с конвейерами: если ваши дизайнеры опаздывают, ваши разработчики остаются без работы; если ваши разработчики опаздывают, ваш дизайнер в конечном итоге будет работать более чем за одну итерацию заранее. Это не стабильная ситуация - она ​​не устойчивая .

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

3. Ваши дизайнеры UX принимают решения заранее, не привлекая разработчиков. Вы упускаете полезные идеи и увеличиваете риск того, что дизайны будут неверными или нереальными. Это довольно распространенное явление, потому что дизайн UX не является «абстрактным» упражнением - оно должно быть разработано исходя из характеристик приложения (включая то, что целесообразно / желательно сделать или нет технически)

4. Исключение или ослабление возможностей ваших разработчиков не является устойчивым способом запуска проекта.

5. Дизайнеры не приносят пользы: это означает, что трудно, если не невозможно, правильно расставить приоритеты в своей работе. Как правило, работа разработчика расставляется по приоритетам с учетом различных проблем, ценности, выполнимости в следующем спринте, количества усилий. Много историй времени обсуждаются и изменяются для того, чтобы сделать их «подходящими» или из-за полезного обсуждения: если что-то из этого изменяет пользовательский интерфейс (и вы можете предположить, что это происходит, если это не просто детали реализации), что вы делаете с историей? Вы не можете играть в это больше.

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

Мне это нравится по двум причинам:

1. это похоже на работу для вас; трудно с успехом спорить!
2. команда UX берет историю и начинает разговор рано - и разговоры являются своего рода историей

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

Команда UX не производит потенциально выпускаемый продукт, а команда Scrum не способна создавать вертикальные фрагменты функциональности, поскольку они не обладают всеми необходимыми навыками. Это дисфункции.

Sklivvz написал отличный пост о проблемах, которые могут привести к вышеуказанным нарушениям. Таким образом, я не думаю, что вы практикуете Scrum.

Но в этом нет абсолютно ничего плохого. Если вы обнаружили способ работы, который приносит ценность для всех вас, и вы все довольны этим, продолжайте делать это. Мой единственный совет - часто проверять и адаптировать.

Тем не менее, обратите внимание, что если ваша цель - поставлять программное обеспечение с использованием Scrum, вам необходимо устранить выявленные неисправности.

Здесь есть две проблемы: одна о дизайне, ориентированном на пользователя, а другая о выравнивании спринта.

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

«Пользователи будут иметь более легкий доступ к активности учетной записи на одной странице, а не разделены на несколько страниц»

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

Второе : выравнивание спринта. UX разрабатывает функции в спринте X, которые разработчики реализуют весной X + 1. На практике это происходит во многих магазинах, и иногда это может быть больше похоже на реализацию в спринте X + 2 или X + 3. С трудолюбивым и опытным коллективом эта установка может работать. Это становится сложной задачей, если у вас есть новая команда или новые участники, которые не знакомы с наборами навыков, предпочтениями, привычками, стилями работы и тенденциями других членов команды. Если вы работали вместе менее 6 месяцев, это может стать проблемой.

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

Одна из возможных проблем, которую я вижу, состоит в том, что в Scrum область спринта N + 1 обычно определяется непосредственно перед его запуском. Итак, как вы можете сделать UX для спринта N + 1 историй в спринте N, прежде чем вы узнаете, какие истории будут в области. Если вы решите исправить область спринта N + 1 в начале спринта N, вы потеряете некоторую гибкость.

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

На мой взгляд, они представляют большую ценность для своего пользователя. Дело в том, что их пользователь не является конечным пользователем компании, их пользователь - команда разработчиков, которая будет реализовывать эту функцию в спринте X + 1.

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

Я думаю, что ваша группа неправильно пометила, кто ваши пользователи, и что они планируют не ту аудиторию.

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

Вот почему это кажется вам неправильным: на самом деле вы не нуждаетесь в scrum и не получаете никакой выгоды от него, потому что вы находитесь в сервисной группе, и ваша работа передается от UX-людей, которые уже выполнили части agile / scrum.

Ничего особо плохого там нет, просто идет другой процесс, чем то, что вам сказали.