UX-дизайнери працюють на один спринт вперед

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

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

Отже, чи бачите ви якісь недоліки в нашому підході? Здається, це працює для нас, але це дещо суперечить принципам Scrum.

Однак у Scrum вам належать лише історії користувачів, які надають користувачеві цінність.

Значення не вимірюється лише у рядках коду, що можна відвантажити.

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

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

Основними недоліками є такі:

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 зловживають, а користувачі неправильно позначають. Scrum - це не універсальний інструмент, це засіб для досягнення мети.

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

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

Ось чому це відчуває вас неправильно, вам насправді не потрібні або користі від scrum ні в якому разі, тому що ви перебуваєте в групі послуг, і ваша робота випливає з людей, які вже не зробили спритний / scrum частин.

Нічого насправді поганого, просто інший процес, ніж те, що вам сказали.