Наша команда scrum складається із звичних ролей scrum. У нас немає дизайнера UI / UX, і розробники працюють з UI / UX з власником продукту. Тут криється проблема. Щоразу, коли ми збираємося створити відставання, і не визначаємо точний дизайн UI / UX до початку спринту, ми закінчуємо витрачати занадто багато часу під час спринту, намагаючись допрацювати дизайн UI / UX.

Це точно стосується аналізу та архітектури функцій. Як ви вважаєте, що будь-яку можливу деталь щодо функції слід надати розробникам перед початком спринту чи це має бути завдання в межах функцій? Ми пережили це, і це призводить до деяких невизначених особливостей, які не мають жодних критеріїв.

По-перше: подивіться на цю приємну розмову , Флоріан Хаас виступив у FROSCON (GER). Йдеться про практичну неможливість взагалі робити скрам.

Хороші новини : Оскільки хватка це неможливо здійснити, ви можете робити все , що ви хочете.

Погана новина : Не називайте цю сутичку.

Це звільняє вас від запитання: «Чи правильно я роблю сутичку?» (Відповідь: « Ні, ви цього не робите» ), і ви можете перейти до практичних питань життя.

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

Це нечаста ситуація. Але AFAIR scrum проти спеціалізації: кожен повинен мати однаковий набір навичок і може працювати взаємозамінно.

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

Так, я зараз ця ситуація занадто гарна. Я працював у команді, де нам доводилося мати справу з дуже широкими відсталими написами на кшталт «Як користувач, я хочу бачити інформацію x», і це було все. Потім предмет приземлився на дошці спринту. Один дев взяв це. Вирішили це. Після його впровадження відбувся перший експертний огляд, де розпочалася дискусія про те, як повинен виглядати інтерфейс користувача.

Потім прийшов QA-Phase і обговорення почалося все заново.

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

Але потім цикл почався все заново, поки ПО не був задоволений.

А потім прийшов замовник ...

З цієї історії війни ви бачите, що цей (особливий вид) процес є пекельно неефективним.

Зрештою, для нас спрацювало це перекидання бруду над дошкою.

Але це не рішення вашого питання;)

Як ви вважаєте, що будь-яку можливу деталь щодо функції слід надати розробникам перед початком спринту чи це має бути завдання в межах функцій?

Вирішення цієї дилеми передбачає чіткі зворотні зв'язки між а) самим замовником та постачальником послуг , щоб критерії були сформульовані відносно чітко. b) Щільний зворотний зв'язок між командою scrum та PO, щоб мінімізувати шанс виїхати з дороги.

Я б порушив декілька (більше) правил scrum, щоб визначити один відсталий текст: "робочу манекен". Що може бути швидко розглянуто ПО і клієнта мінімізують developertime витратили на простий елемент.

тл; д-р

Яким повинен бути внесок команди scrum?

Достатньо інформації для задоволення специфікацій за якомога менше часу.

Не по темі:

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

Канонічна відповідь - «роби те, що працює для тебе».

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

Індивіди та взаємодія над процесами та інструментами
Робоче програмне забезпечення над всеосяжною документацією
Співпраця з клієнтом над переговорами контракту
Відповідь на зміни внаслідок виконання плану ( Agile manifest )

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

На мій особистий досвід, це залежить від бізнес-мети. Деякі історії вже одержані з дослідженнями UI / UX та повним дизайном, і це нормально. Деякі історії випливають із невиразними вимогами, оскільки бізнесу просто потрібна вирішена проблема. Це теж нормально.

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

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

Що для нас спрацювало:

1. Хтось працює з власником продукту, щоб створити макети екранів, які потрібно розробити. Їх переглядають під час звичайного процесу доопрацювання історії, перш ніж історія потрапить у спринт, що дає кожному можливість чесно обговорити.
2. Не намагайтеся доопрацювати дизайн перед кодуванням, просто дістаньте його, а потім поговоріть про те, що потрібно змінити. Витрати на внесення змін потім зрозуміліші, що допомагає власнику продукту / замовнику вирішити, чи варто цього робити.
3. Довіра між власником продукту / покупцями та розробниками. Зрештою, всі намагаються доставити речі замовнику. PO не може стогнати над командою, не доставляючи все зі спринту. Чорти не можуть бути навмисно перешкоджаючими, тому що вони переживають, щоб не доставити їх.
4. Практика. Ми щойно покращили оцінку розмірів історії та зможемо виявити ймовірні проблеми.

Tl; DR: Не коментуйте повністю UX перед кодуванням. Зачекайте, поки користувачі побачать це, і пограйте з ним.

Як ви вважаєте, що будь-яку можливу деталь щодо функції слід надати розробникам перед початком спринту чи це має бути завдання в межах функцій?

Простіше кажучи, якщо власник продукту не в змозі поставити дизайн ui / ux до спринту, розробка ui / ux має бути історією , а не завданням.

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

Вам не потрібно писати інтерфейс користувача, просто прийміть функціональний запит (історію) і зарахуйте його, знаючи, що вам потрібно думати про інтерфейс користувача. Якщо клієнт уточнить, інтерфейс користувача задає проблеми.

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

Якщо ви скучаєте, будь-хто може бути дизайнером UI / UX.

UI / UX не повинен бути думкою. Це має бути результатом. Це має бути схвалено власником вашого продукту. Він повинен з’являтися, навіть якщо тільки в якості gif, при доставці.

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

Єдиний доопрацьований UI / UX знаходиться на мертвому програмному забезпеченні.

З вашого коментаря:

"Це має бути схвалено власником вашого продукту." Саме тут і виникає проблема. На цей процес затвердження витрачається величезна кількість часу, і ми закінчуємо витрачені дні замість кількох годин, що спочатку було оцінено. - Рашид

Усуньте все, що непотрібно сповільнює вас.

У вас є ідея. Повідомте власника продукту. Вони повинні сидіти поруч з вами.

Вони ненавидять це? Рухайся. Любите? Зроби це. Не розумієте? Покажіть їх.

Короткі часті позапланові зустрічі. Розмова. Doodle на дошці або папері. Макети в програмі фарби за допомогою знімків екрана. Швидке спілкування, затвердження, реалізація та перегляд ідей.

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

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

З мого досвіду:

• Занадто мало переднього аналізу викликає неефективний розвиток зупинки та запуску
• Занадто багато переднього аналізу викликає параліч аналізу (спринт ніколи не починається)

Що ми робимо:

• Визначте кілька критеріїв " Готовий до розвитку "
• Для UX історій це може бути "у нас є каркас, який добре розуміється командою"

Під час планування спринту:

• Будь-які історії, які не готові до розвитку, викидаються (вони були б занадто руйнівними для команди та повертаються для більшого аналізу)
• Будь-які прикордонні Історії оголошуються "Високим ризиком" і здійснюються на початку Спринту
• Добре зрозумілі Історії оцінюються і допускаються до спринту

Ця система дозволяє нам присвячувати велику частину кожного спринту для виконання, тобто ми працюємо набагато ефективніше.

Будь-яке завдання у вашій програмі повинно мати оцінку загальної роботи та перевірений результат.

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

Тепер я поклав завдання на ваш scrum "спроектувати інтерфейс користувача для функції X". Це можна оцінити, а результат перевірити. Це нормальне завдання в scrum. Коли завдання виконано, ви це зробили.

Тепер, коли завдання виконано, менеджер продукту може сказати, що результат йому не подобається. Все добре. У scrum було завдання, ви це зробили, і це ваше завдання. Він може поставити ще одне завдання в наступний скрам. Можливо, з трохи більше напряму, який саме користувальницький інтерфейс він би хотів. Це його робота. Постановка завдань, які дають корисні результати. Іноді важко, і робиться робота, яка виявляється марною. Ось чому вони називають це "спритний"; виконуються завдання, які виявляються марними, а потім ви переходите на кращий напрямок.

Крім того, 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. Хтось втручається в вимоги під час спринту. Поверніться до вирішення того, що хоче клієнт, визначте, скільки часу знадобиться, і працюйте з ними, щоб визначити пріоритет. Якщо вони думають, що пройде занадто багато часу, запитайте їх, чого позбутися.

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