Como lidar com o design da interface do usuário e o respectivo suporte a recursos no desenvolvimento Agile?

Em um processo de desenvolvimento ágil, geralmente o foco principal está nas histórias de usuários, mas às vezes um único requisito pode abranger várias histórias de usuários.

Por exemplo, o cliente pode solicitar uma página de pesquisa para todos os usuários em um fórum e existem várias ações que podem ocorrer em cada usuário, como banir usuário, excluir usuário, redefinir senha, etc.

Podemos dividir esse recurso em pelo menos quatro histórias de usuários:

1. Procurar usuários
2. Banir usuário
3. Deletar usuário
4. Redefinir senha

Como o designer da interface do usuário implementaria essa interface? Ele / ela deve trabalhar na primeira história do usuário e começar a incrementar mais recursos na interface do usuário? No entanto, acho que a interface do usuário final será confusa!

Se ele decidir trabalhar em todo o recurso (pesquisa + ações), e se as ações forem de baixa prioridade e forem implementadas várias iterações após a conclusão da funcionalidade de pesquisa?

Tome iterativamente. Você está trabalhando diretamente com os usuários, certo? Portanto, nunca deve ser realmente uma bagunça.

Primeiro, faça a página de pesquisa. Você e os usuários devem ter em mente que desejam executar ações nos resultados. Os usuários gostam? OK, você conseguiu sua pesquisa.

Agora adicione o "Change Password" (ou o que for o próximo em prioridade). Opa, precisamos mudar um pouco a página de pesquisa - bem, a mudança geralmente faz parte do jogo. Os usuários gostam dos resultados? Boa.

Agora adicione o próximo item e o próximo ...

A abordagem ágil diz que você sempre recebe feedback imediatamente, portanto deve ser bom.

Dito isso, não há motivo real para que você não consiga atacar duas dessas histórias na mesma iteração (adicionando excluir usuário e banir usuário). A chave é estar sempre trabalhando com o cliente para garantir que esteja certo.

Você sempre (sempre?) Acaba com os usuários pensando em outra coisa que eles querem fazer nessa tela de pesquisa depois que seu "design" original é feito e implementado. Então, você acabará modificando-o em algum momento de qualquer maneira. Basta abordar a coisa toda com essa expectativa e você deve ser bom.

Eu sinto que digo muito isso. Agile não significa que você precise colocar antolhos para ignorar o futuro e se projetar em um canto. O Agile é sobre como você fornece funcionalidade e tem muito pouco a ver com o design da funcionalidade.

Em outras palavras, não há problema em olhar o mais longe possível no futuro ao criar seu design, desde que não adie a entrega de funcionalidades a curto prazo.

O que isso significa no seu exemplo específico é que você prossiga e projete a interface do usuário de forma que seja fácil adicionar ações posteriormente. No entanto, se o trabalho de acertar o design das ações atrasar a entrega da pesquisa básica do usuário por uma iteração, é melhor fazer um design sem ações primeiro, assumindo que uma pesquisa sem nenhuma ação tenha valor para o cliente.

A pergunta a ser feita é: "Esse trabalho de design está atrasando minha primeira entrega?" Na maioria das vezes, a resposta será não. Você precisa fazer um design de qualquer maneira, tudo o que está mudando são alguns critérios de design.

A primeira história do usuário pode ser o design de toda a interface - eles não precisam criar apenas uma parte dela. É o design como um todo que agrega valor ao negócio.

Dito isto, vejo pelo menos dois recursos distintos aqui: a capacidade de procurar usuários e a capacidade de executar uma função em um ou mais usuários. O designer pode lidar com cada um deles com carinho, se isso fizer mais sentido.

Lembre-se: o objetivo é fornecer software de qualidade, não é seguir cegamente alguma metodologia. Pergunte a si mesmo se dividir o design em pedaços ajuda ou atrapalha esse objetivo. Não há polícia de scrum, apenas clientes felizes ou insatisfeitos.

Tive a oportunidade de estagiar em uma fábrica de programação Agile / Extreme. Eles estavam usando cartões de histórias para conduzir o processo de desenvolvimento iterativo. Cada ficha de história levou a uma implementação ou mudança. A chave foi a interação do usuário. Como alguém pode projetar com sucesso uma interface destinada a um usuário sem interagir com um usuário do software?

Um cenário possível é começar com a interação do usuário para decidir o que o usuário deseja primeiro. Em seguida, iterativamente, projete a interface do usuário com base no aumento do feedback, na prioridade do usuário e no que o usuário deve ter.

As histórias de usuário estão lá para orientar como o usuário interagia, em que nível e de que maneira. Mas são apenas aproximações até interagir com o usuário. Se houver uma infinidade de usuários que desejariam algo específico, uma pequena pesquisa de pessoas poderá definir alguma linha de base para a interface do usuário.