Come gestire la progettazione dell'interfaccia utente e il relativo supporto delle funzioni nello sviluppo Agile?

In un processo di sviluppo Agile di solito l'attenzione principale è sulle storie degli utenti, ma a volte un singolo requisito può comprendere più storie degli utenti.

Ad esempio, il client può richiedere una pagina di ricerca per tutti gli utenti in un forum e ci sono diverse azioni che possono verificarsi su ciascun utente come vietare l'utente, eliminare l'utente, reimpostare la password, ecc.

È possibile dividere questa funzione in almeno 4 storie utente:

1. Cerca utenti
2. Divieto utente
3. Elimina utente
4. Resetta la password

In che modo il progettista dell'interfaccia utente implementerebbe tale interfaccia utente? Dovrebbe lavorare sulla prima user story e quindi iniziare ad incrementare più funzionalità nell'interfaccia utente? Tuttavia, penso che l'interfaccia utente finale sarà incasinata!

Se decide di lavorare sull'intera funzione (ricerca + azioni), cosa succede se le azioni fossero di bassa priorità e sarebbero state implementate diverse iterazioni dopo che la funzionalità di ricerca era stata eseguita?

Prendilo iterativamente. Stai lavorando direttamente con gli utenti, giusto? Quindi non dovrebbe mai essere davvero un casino.

Prima fai la pagina di ricerca. Tu e gli utenti dovreste tenere a mente che vorranno essere in grado di fare azioni sui risultati. Piace agli utenti? OK, hai la tua ricerca.

Ora aggiungi la "Cambia password" (o qualunque cosa sia la prossima priorità). Oops, dobbiamo cambiare un po 'la pagina di ricerca - beh, il cambiamento è spesso parte del gioco. Piace agli utenti come i risultati? Buona.

Ora aggiungi l'elemento successivo e il prossimo ...

L'approccio agile dice che hai sempre un feedback immediato, quindi dovresti essere bravo.

Detto questo, non esiste un vero motivo per cui potresti non essere in grado di attaccare 2 di queste storie nella stessa iterazione (aggiungendo l'utente di eliminazione E l'utente di ban). La chiave è lavorare sempre con il cliente per assicurarsi che sia giusto.

Spesso (sempre?) Finirai con gli utenti che pensano a qualcos'altro che vogliono fare da quella schermata di ricerca dopo che il tuo "design" originale è stato realizzato e implementato. Quindi, ci si ritroverà modificandolo ad un certo punto comunque. Basta avvicinarsi al tutto con quell'aspettativa e dovresti essere bravo.

Mi sento di dirlo molto. Agile non significa che devi mettere i paraocchi per ignorare il futuro e progettarti in un angolo. Agile riguarda il modo in cui offri funzionalità e ha ben poco a che fare con il modo in cui progetti la funzionalità.

In altre parole, va bene guardare nel futuro quanto vuoi quando crei il tuo design, purché non rinvii la consegna di funzionalità a breve termine.

Ciò che significa nel tuo esempio specifico è che vai avanti e progetti l'interfaccia utente in modo che sia facile aggiungere azioni in seguito. Tuttavia, se lavorare per ottenere la progettazione delle azioni corretta ritarderebbe la consegna della ricerca utente di base mediante un'iterazione, è meglio fare prima una progettazione senza azioni, supponendo che una ricerca senza azioni abbia valore per il cliente.

La domanda da porsi è "Questo lavoro di progettazione sta ritardando la mia prima consegna?" Il più delle volte, la risposta sarà no. Devi comunque fare un disegno, tutto ciò che cambi sono alcuni criteri di disegno.

La prima user story può essere il design dell'intera interfaccia: non devono progettarne solo un pezzo. È il design nel suo insieme che aggiunge valore al business.

Detto questo, vedo almeno due caratteristiche distinte qui: la capacità di cercare utenti e la capacità di eseguire una funzione su uno o più utenti. Il progettista potrebbe affrontare ciascuno di quelli in modo perspicace se ciò ha più senso.

Ricorda: l'obiettivo è fornire software di qualità, non seguire ciecamente una metodologia. Chiediti se spezzare il disegno in pezzi aiuta o ostacola questo obiettivo. Non ci sono mischie, solo clienti felici o insoddisfatti.

Ho avuto l'opportunità di fare uno stage in una fabbrica di programmazione Agile / Extreme. Stavano usando le carte narrative per guidare il processo di sviluppo iterativo. Ogni story-card ha guidato un'implementazione o un cambiamento. La chiave era l'interazione dell'utente. Come si può progettare con successo un'interfaccia pensata per un utente senza interagire con un utente del software?

Uno scenario possibile è iniziare con l'interazione dell'utente per decidere cosa desidera prima l'utente. Quindi, in modo iterativo, progettare l'interfaccia utente in base al feedback crescente, alla priorità dell'utente e a ciò che l'utente deve avere.

Le storie degli utenti sono lì per guidare il modo in cui l'utente interagirebbe, a quale livello e in che modo. Ma sono solo approssimazioni fino all'interazione con l'utente. Se ci sono una moltitudine di utenti che desiderano tutti qualcosa di specifico, allora potrebbe essere un piccolo sondaggio di persone al fine di definire alcune linee di base per l'interfaccia utente.