Як боротися з дизайном інтерфейсу користувача та відповідною підтримкою функцій у розробці Agile?

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

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

Ми можемо розділити цю функцію принаймні на 4 історії користувача:

1. Шукайте користувачів
2. Заборонити користувача
3. Видалити користувача
4. Скинути пароль

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

Якщо він вирішить попрацювати над цією функцією (пошук + дії), що робити, якщо дії, де мало пріоритетні, та будуть виконані кілька ітерацій після того, як функція пошуку була виконана?

Візьміть це ітеративно. Ви працюєте безпосередньо з користувачами, правда? Тож ніколи насправді не повинно бути безладу.

Спочатку зробіть сторінку пошуку. Ви та користувачі повинні пам’ятати, що вони захочуть робити дії щодо результатів. Користувачам це подобається? Гаразд, у вас є пошук.

Тепер додайте "Змінити пароль" (або що далі в пріоритеті). На жаль, нам потрібно трохи змінити сторінку пошуку - ну, зміни часто є частиною гри. Користувачам подобаються результати? Добре.

Тепер додайте наступний елемент, а наступний ...

Спритний підхід говорить, що у вас завжди є відгуки одразу, тому ви повинні бути хорошими.

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

Ви часто (завжди?) Стикаєтесь з тим, що користувачі думають про щось інше, що вони хочуть зробити на цьому екрані пошуку після того, як ваш оригінальний "дизайн" буде зроблено та здійснено. Отже, ви все одно в будь-який момент його модифікуєте . Просто підходьте до всієї справи з таким очікуванням, і ви повинні бути хорошими.

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

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

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

Питання, яке потрібно задати собі, таке: "Чи затримка цієї дизайнерської роботи моєї першої поставки?" Більшу частину часу відповідь буде "ні". Ви все одно повинні робити дизайн, все, що ви змінюєте, - це деякі критерії дизайну.

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

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

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

У мене була можливість стажуватися на заводі програмування Agile / Extreme. Вони використовували сюжетні картки для керування ітераційним процесом розвитку. Кожна історія-картка викликала реалізацію чи зміну. Ключовою була взаємодія користувача. Як можна успішно розробити інтерфейс, призначений для користувача, не взаємодіючи з користувачем програмного забезпечення?

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

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