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

prendilo iterativamente. Stai lavorando direttamente con gli utenti, giusto? Quindi non dovrebbe mai essere un disastro.

Per prima cosa fai la pagina di ricerca. Tu e gli utenti dovresti tenere presente che vorranno essere in grado di fare azioni sui risultati. Piace agli utenti? OK, hai la tua ricerca.

Ora aggiungi "Cambia password" (o qualunque cosa sia successiva in priorità). Oops, abbiamo bisogno di cambiare leggermente la pagina di ricerca, beh, il cambiamento è spesso parte del gioco. Piace agli utenti i risultati? Buona.

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

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

Detto questo, non c'è una vera ragione per cui potresti non essere in grado di attaccare 2 di queste storie nella stessa iterazione (aggiungendo l'utente delete E l'utente 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 "progetto" originale è stato fatto e implementato. Quindi, finirai per modificarlo ad un certo punto comunque. Avvicinati al tutto con quell'aspettativa e dovresti essere bravo.

Mi sento come se lo dicessi molto. Agile non significa che devi mettere i paraocchi per ignorare il futuro e progettare te stesso in un angolo. Agile parla di come offri funzionalità e ha ben poco a che fare con la tua progettazione .

In altre parole, è bene guardare il futuro nel modo desiderato quando crei il tuo design, purché non rinvii la fornitura di funzionalità a breve termine.

Ciò significa nel tuo esempio specifico che vai avanti e progetta l'interfaccia utente in modo tale che sia facile aggiungere azioni in un secondo momento. Tuttavia, se lavorare per ottenere il giusto design delle azioni ritarderebbe la consegna della ricerca utente di base per iterazione, è meglio fare prima un progetto senza azioni, supponendo che una ricerca senza azioni abbia un 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 quello che stai cambiando sono alcuni criteri di progettazione.

La prima user story può essere il design dell'intera interfaccia: non è necessario progettarne solo una parte. È il design nel suo insieme che aggiunge valore al business.

Detto questo, vedo almeno due caratteristiche distinte: la capacità di cercare utenti e la possibilità di eseguire una funzione su uno o più utenti. Il progettista potrebbe affrontare ognuno di questi argomenti se questo ha più senso.

Ricorda: l'obiettivo è fornire software di qualità, non seguire ciecamente alcuni metodi. Chiediti se rompere il design in pezzi aiuta o ostacola tale obiettivo. Non ci sono poliziotti di mischia, solo clienti felici o insoddisfatti.

Ho avuto l'opportunità di fare un tirocinio presso una fabbrica di programmazione Agile / Extreme. Stavano usando le story-card 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 l'utente desidera prima. Quindi, iterativamente, progetta l'interfaccia utente in base all'aumento del feedback, della priorità dell'utente e di 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 desidererebbero tutti qualcosa di specifico, allora una piccola indagine sulle persone potrebbe essere utile per definire alcune linee di base per l'interfaccia utente.