Хто виконує UX на проект scrum?

ДОБРЕ. Скажімо, ви працюєте над проектом scrum textbook. У вас є майстер scrum, який співпрацює з власником продукту. Наступний спринт UI-важкий - на той час ваших кодери починають будувати екрани, ви дійсно хочете мати деякий уявлення , що вони будуть виглядати.

Хто займається проводкою та коли? Власник продукту? Хтось підтримує власника продукту? Майстер скраму? Якщо у вас є експерт з UX, чи працюють вони поряд із кодерами після того, як спринт розпочався, чи вони постачають каркаси та макети вперед, які сидять поруч з вашими картками історії та обмеженнями, щоб керувати та інформувати про роботу розробників?

Я впевнений, що нам потрібна допомога щодо UX, але я не знаю, де її застосувати ...

EDIT: Дозвольте перефразувати питання.

Як ви забезпечуєте послідовну, якісну роботу користувачів на спритному проекті?

Дизайнер взаємодії

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

На початковій фазі дизайнери взаємодії відповідальні за:

1. Вилучення фактичних цілей рішення у власника продукту
2. Визначте персони, які будуть використовувати рішення.
3. Напишіть сценарії, які є розповідями про те, як рішення буде використано.
4. Складіть проектний документ, який залишає мало місця для неоднозначності з точки зору UX

Під час проекту завдання дизайнерів на взаємодію - переконатись у дотриманні цих керівних принципів та вирішенні будь-яких додаткових питань, які виникнуть (і вони будуть).

Багато програмістів будуть проти цього підходу, я впевнений, оскільки всі відчувають, що вони є винятком, який може створити "чудові" інтерфейси, ви, мабуть, не так. З іншого боку, хороші стосунки дизайнера та програміста часто дуже приємні для програміста, тому що їм не доведеться боротися з "дурною специфікацією". На жаль, хорошого дизайнера взаємодії важко знайти в моєму досвіді, але вони там.

Як завжди, я настійно рекомендую книги Алана Купера на цю тему ("Про обличчя" та "Ув'язнені мають притулок")

Я пропоную організувати роботу хлопця UX так само, як і решти команди. Він повинен вважатися рівноправним членом команди, брати участь у складі стендів і тісно спілкуватися з програмістами.

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

Як завжди з спритними, використовуйте здоровий глузд, експериментуйте з різними підходами та дотримуйтесь того, який добре підходить для вашої конкретної ситуації.

На мою думку, це якимось особливий випадок, з яким треба поводитися особливим чином. Майстер Scrum точно не братиме участі в цьому - це зовсім не його роль. Команда, як правило, є групою розробників, і більшість з них не має досвіду роботи з UX, і витрачати їх час буде витрачати їх на це. Ви наймете експерта з UX, і експерт не буде частиною команди - команда повинна бути функціональною, і експерт UX, ймовірно, не буде розробником. Також експерт UX не буде працювати над проектом впродовж усього його дії. Експерт UX буде працювати з власником продукту на один спринт вперед, щоб підготувати макети та провідні рамки для оновлення історій користувача, щоб команда знала, що потрібно зробити в наступному спринті - макети будуть доступні під час зустрічі планування.

Редагувати:

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

Незважаючи на це, відповідь @Adam Byrtek виглядає правильною. Зробіть хлопця UX частиною команди та дозвольте йому співпрацювати з розробниками над поточно реалізованими історіями користувачів. Це не займе весь час хлопця UX, тому він також буде співпрацювати з власником продукту або замовником, щоб підготувати макети та проводки для вдосконалення одного або двох спринтів.

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

• Проекти Agile User Experience
• Гнучкі проекти розвитку та зручність використання

Для "підручника Scrum":

По-перше, Scrum Masters не співпрацюють із власниками продуктів - ну не в іншому сенсі, крім того, що вся команда, включаючи SM та PO, співпрацює для створення системи.

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

Крім того, ви, ймовірно, не створили б UX Sprint перед функціональним кодом. Особливості поставляються повністю в межах одного спринту. Якщо UX, пов’язаний з функцією, занадто складний, щоб доставити разом з функціональним кодом в одному Sprint, то ви вирізаєте всю функцію до того, що можна зробити, включаючи елементи UX, в одному спринті.

Хто займається UX за проектом водоспаду? Хто займається розробкою мейнфреймів для проекту XP?

Методика проекту не має значення. Кожен технологічний проект вимагає певних спеціалізованих ролей. Іноді проект може піти без повністю ліцензованого та підключеного «дизайнера взаємодії» (що б це не означало). Іноді вам потрібен хтось, хто спеціалізується. Але те саме можна сказати і для кожної іншої ролі.

Отже, до вашого другого питання про те, як ви користуєтеся високоякісною роботою користувачів за допомогою agile. Ми впоралися з цим в останньому проекті scrum, з яким я брав участь, залучаючи бізнес-аналітика та клієнта рано і часто. Також у нас був розробник, який мав особливо хороший погляд на UX. Він, як правило, робив незначні зміни у користувальницьких інтерфейсах, над якими розробники працювали після того, як вони здійснили доручення.

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

Якщо під UX ви маєте на увазі дизайнера користувальницького інтерфейсу, вони є лише іншою роллю або ресурсом для команди. Дизайн інтерфейсу користувача, як і будь-який дизайн, вирізає проект. Існує розумна кількість архітектурних / дизайнерських робіт, які слід виконувати попереду, і є кількість, яку можна виконати, коли ви йдете далі.

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

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