Наша команда Scrum состоит из обычных ролей Scrum. У нас нет дизайнера UI / UX, и разработчики работают с UI / UX с владельцем продукта. Здесь кроется проблема. Каждый раз, когда мы собираемся создать резерв, и мы не определяем точный дизайн UI / UX до начала спринта, мы заканчиваем тем, что тратим слишком много времени во время спринта, пытаясь завершить дизайн UI / UX.

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

Во-первых, взгляните на этот приятный разговор , который дал Флориан Хаас в FROSCON (GER). Речь идет о практической невозможности делать разборки вообще.

Хорошие новости : Поскольку хватка это невозможно осуществить, вы можете делать все , что вы хотите.

Плохая новость : Не называйте эту схватку.

Это освобождает вас от вопроса: «Правильно ли я занимаюсь ссорами?» (Ответ: нет, не так ), и вы можете перейти к практическим вопросам жизни, в этом вопросе.

У нас нет дизайнера UI / UX, и разработчики работают с UI / UX с владельцем продукта

Это не редкая ситуация. Но AFAIR scrum против специализации: каждый должен иметь одинаковый набор навыков и работать взаимозаменяемо.

Каждый раз, когда мы собираемся создать резерв, и мы не определяем точный дизайн UI / UX до начала весны, мы заканчиваем тем, что тратим слишком много времени во время спринта, пытаясь завершить разработку UI / UX.

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

Затем наступил этап QA, и снова началось обсуждение.

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

Но затем цикл начался снова, пока ПО не было удовлетворено.

А потом пришел заказчик ...

Из этой истории войны вы видите, что этот (особый) процесс адски неэффективен.

В конечном итоге у нас сработало бросание разборок за борт.

Но это не решение вашего вопроса;)

Считаете ли вы, что все возможные подробности о функции должны быть предоставлены разработчикам до начала спринта или это должно быть задачей в рамках функций?

Решение этой дилеммы будет заключаться в тесной обратной связи между а) самим клиентом и ПО , так что критерии будут сформулированы достаточно жестко. б) Тесная обратная связь между scrum-командой и ПО, чтобы свести к минимуму вероятность выезда с дороги.

Я бы нарушил некоторые (более) правила схватки, чтобы определить один backlogitem: «рабочий манекен». Что может быть быстро рассмотрено ПО и клиента минимизируют developertime потратили на простой элемент.

ТЛ; др

Каким должен быть вклад команды Scrum?

Достаточно информации, чтобы соответствовать техническим требованиям в кратчайшие сроки.

Не по теме:

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

Канонический ответ: «делай, что работает для тебя».

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

Отдельные лица и взаимодействия над процессами и инструментами.
Работа с программным обеспечением над исчерпывающей документацией.
Сотрудничество с клиентами по согласованию контрактов.
Реагирование на изменения в соответствии с планом ( Agile манифест ).

Вопрос не в том, что ваша команда должна начать с истории, а в том, какой вклад ваша команда позволяет решить конкретной бизнес-потребности.

По моему личному опыту, это зависит от бизнес-цели. Некоторые истории уже идут с исследованиями UI / UX и полным дизайном, и это нормально. Некоторые истории поставлены со смутными требованиями, потому что бизнесу просто нужно решить проблему. Это тоже нормально.

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

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

Что сработало для нас:

1. Кто-то работает с владельцем продукта, чтобы создать макеты экранов, которые будут разработаны. Они проверяются в ходе обычного процесса доработки истории, прежде чем история затягивается в спринт, что дает всем шанс провести честное обсуждение.
2. Не пытайтесь доработать дизайн до написания кода, просто получите его и поговорите о том, что нужно изменить. Затраты на внесение изменений становятся более ясными, что помогает владельцу продукта / клиенту решить, стоит ли оно того.
3. Доверие между владельцем продукта / клиентами и разработчиками. В конце концов все пытаются доставить вещи клиенту. Полиция не имеет права жаловаться на команду, которая не доставляет все со спринта. Разработчики не могут быть намеренно препятствующими, потому что они беспокоятся о том, чтобы не доставлять.
4. Практика. Мы только лучше оценили размеры историй и смогли определить возможные проблемы.

Tl; DR: не полностью определять UX перед кодированием. Подождите, пока пользователи увидят его и поиграют с ним.

Считаете ли вы, что все возможные подробности о функции должны быть предоставлены разработчикам до начала спринта или это должно быть задачей в рамках функций?

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

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

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

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

Если вы скрам, любой может стать дизайнером UI / UX.

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

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

Единственный завершенный UI / UX на мертвом программном обеспечении.

Из вашего комментария:

«Это должно быть одобрено владельцем вашего продукта». Именно здесь возникает проблема. На процесс утверждения уходит огромное количество времени, и в итоге мы тратим дни, а не несколько часов, которые изначально были оценены. - Рашид

Устранить все, что без необходимости замедляет вас.

У тебя есть идея. Сообщите владельцу продукта. Они должны сидеть рядом с вами.

Они ненавидят это? Двигаться дальше. Любить это? Сделай это. Не понимаешь это? Показать их.

Короткие частые незапланированные встречи. Говорить. Doodle на доске или бумаге. Макет в программе рисования с использованием снимков экрана. Быстро сообщайте, одобряйте, внедряйте и просматривайте идеи.

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

Не трать одну секунду, чтобы сделать это красиво. Просто доберись до сути. Держите ваши идеи маленькими и постепенными, и вы можете сделать это, прежде чем кто-либо даже попросит оценить.

По моему опыту:

• Слишком малый предварительный анализ приводит к неэффективному, начальному развитию
• Слишком много предварительных анализов вызывает паралич анализа (Спринт никогда не запускается)

Что мы делаем:

• Определить некоторые критерии " Готов к развитию "
• Для UX-историй это может быть «у нас есть каркас, который хорошо понимает команда»

Во время планирования спринта:

• Любые истории, которые не готовы к разработке, выбрасываются (они будут слишком разрушительными для команды и вернутся для дополнительного анализа)
• Любые пограничные истории объявляются «Высокими рисками» и проводятся в самом начале спринта.
• Хорошо понятые истории оцениваются и принимаются в спринт

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

Любая задача в вашей схватке должна иметь оценку общего объема работ и поддающийся проверке результат.

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

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

Теперь, когда задача выполнена, ваш менеджер по продукту может сказать, что ему не нравится результат. Ничего страшного. В схватке было задание, вы сделали это, и это ваша работа. Он может поставить другую задачу в следующей схватке. Может быть, с немного большей направленностью, какой пользовательский интерфейс он на самом деле хотел бы. Это его работа. Постановка задач, дающих полезные результаты. Иногда это тяжело, и работа делается, что оказывается бесполезным. Вот почему они называют это «гибким»; Выполняются задачи, которые оказываются бесполезными, и тогда вы переходите в лучшую сторону.

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

Я не уверен, что вы следуете гибким принципам, но вот как это следует делать.

мы не определяем точный дизайн UI / UX до начала спринта

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

мы заканчиваем тем, что тратим слишком много времени во время спринта, пытаясь завершить дизайн UI / UX.

Работайте над тем, чтобы определить, когда все сделано. У меня есть ощущение, что кто-то продолжает делать многократную оценку UI / UX. Слишком много людей имеют мнения о UX / UI, и клиенту ничего не подкрепляет их предположения.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

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

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