Quem faz o UX em um projeto scrum?

ESTÁ BEM. Digamos que você esteja trabalhando em um projeto de scrum de livro didático. Você tem um scrum master colaborando com o proprietário do produto. O próximo sprint é pesado na interface do usuário - quando seus codificadores começam a criar telas, você realmente quer ter uma ideia de como eles serão.

Quem faz a wireframing e quando? O proprietário do produto? Alguém apoiando o proprietário do produto? O scrum master? Se você tem um especialista em UX, eles trabalham com os codificadores após o início do sprint ou fornecem wireframes e mock-ups antecipadamente que ficam ao lado de seus story cards e restrições para orientar e informar o trabalho que os desenvolvedores estão fazendo?

Tenho certeza de que precisamos de alguma ajuda de UX, veja, mas não tenho certeza de onde aplicá-la ...

EDIT: Deixe-me reformular a pergunta.

Como você fornece uma experiência consistente e de alta qualidade ao usuário em um projeto ágil?

O designer de interação

UX! = UI Você precisa de um designer de interação experiente para oferecer uma boa experiência ao usuário, ao contrário da crença popular de que não é um programador. Para todos vocês programadores que pensam que podem fazer UX (isso inclui eu), deixe-me dizer isso. Ser bom em design de interação requer pelo menos tanto tempo quanto ser bom em programação. Quanto tempo você passou criando puro design de interação?

Na fase inicial, é responsabilidade dos designers de interação:

1. Extrair os objetivos reais da solução do proprietário do produto
2. Defina as personas que usarão a solução.
3. Escreva cenários com histórias sobre como a solução será usada.
4. Compile um documento de design que deixe pouco espaço para ambiguidade do ponto de vista do UX

Durante o projeto, é tarefa dos designers de interação garantir que essas diretrizes sejam seguidas e resolver quaisquer problemas adicionais que possam surgir (e serão).

Muitos programadores se opõem a essa abordagem, tenho certeza, já que todos acham que são a exceção que pode criar interfaces "maravilhosas", provavelmente você não é. Por outro lado, uma boa relação designer-programador de interação geralmente é muito boa para o programador, assim como eles não precisam lutar contra uma "especificação estúpida". Infelizmente, é difícil encontrar bons designers de interação na minha experiência, mas eles estão lá fora.

Como sempre, recomendo profundamente os livros de Alan Coopers sobre o assunto ("About Face" e "The Inmates are running the asylum")

Sugiro organizar o trabalho do cara do UX da mesma maneira que o resto da equipe. Ele deve ser considerado um membro igual da equipe, participar de standups e se comunicar de perto com os programadores.

Idealmente, os modelos devem ser feitos com pelo menos um sprint de antecedência, mas para recursos menores, pode fazer sentido considerar a criação de modelos como uma subtarefa de uma história planejada para a iteração atual.

Como sempre com o ágil, use o bom senso, experimente diferentes abordagens e siga a que funciona bem para sua situação específica.

Na minha opinião, este é um caso especial que deve ser tratado de maneira especial. Definitivamente, o Scrum Master não participará disso - esse não é o seu papel. A equipe geralmente é um grupo de desenvolvedores e a maioria deles não tem experiência com o UX e será uma perda de tempo forçá-los a isso. Você contratará um especialista em UX e o especialista não fará parte da equipe - a equipe deve ser multifuncional e o especialista em UX provavelmente não será um desenvolvedor. Além disso, o especialista em UX não estará no projeto durante toda a sua duração. O especialista em UX trabalhará com o proprietário do produto um sprint à frente para preparar mock-ups e wireframes para as próximas histórias de usuário, para que a equipe saiba o que terá que ser feito no próximo sprint - os mock-ups estarão disponíveis durante a reunião de planejamento.

Editar:

Fiz algumas pesquisas adicionais porque sabia que li sobre isso em algum lugar e finalmente o encontrei em Sucedendo com o Agile: Desenvolvimento de Software Usando Scrum por Mike Cohn . Mike discute exatamente o papel do designer de UX na equipe. Sua descrição inicial é semelhante à minha e ele considera sua mudança natural quando a empresa muda o método de desenvolvimento de cascata para Scrum, mas depois conclui que não é recomendado. O motivo é que, se os designers de UX não fazem parte da equipe, eles podem pensar em si mesmos como a equipe separada e não precisam compartilhar o compromisso da equipe de desenvolvimento.

Apesar disso, a resposta de @Adam Byrtek parece a correta. Faça do UX o cara da equipe e permita que ele coopere com os desenvolvedores nas histórias de usuários atualmente implementadas. Não vai demorar todo o tempo do cara do UX, então ele também cooperará com o proprietário ou o cliente do produto para preparar modelos e estruturas de arame para iniciar um ou dois sprints.

Eu assinei a caixa de alerta de Jakob Nielsen (principalmente por causa de suas críticas às práticas irritantes de design da web) e lembro-me de que li recentemente alguns artigos sobre o assunto (embora eu mal tenha uma compreensão mínima de todo o processo de desenvolvimento ágil), talvez eles sejam de qualquer uso para você:

• Projetos de experiência do usuário ágil
• Projetos de desenvolvimento ágil e usabilidade

Para "livro didático Scrum":

Primeiro, o Scrum Masters não colabora com os Product Owners - bem, em nenhum sentido além do que toda a equipe, incluindo o SM e o PO, colabora para construir o sistema.

Em segundo lugar, as equipes Scrum devem ser homogêneas com os membros multifuncionais da equipe. Então você não teria um "UX Guy".

Além disso, você provavelmente não criaria o UX a Sprint antes do código funcional. Os recursos são entregues completamente em um único Sprint. Se o UX associado a um recurso for muito complexo para ser entregue juntamente com o código funcional em um único Sprint, você reduzirá todo o recurso a algo que pode ser feito, incluindo os elementos UX, em um único Sprint.

Quem faz UX em um projeto em cascata? Quem desenvolve o mainframe em um projeto XP?

A metodologia do projeto não importa. Todo projeto de tecnologia requer certas funções especializadas. Às vezes, um projeto pode sair sem um "designer de interação" totalmente licenciado e vinculado (o que isso significa). Às vezes você precisa de alguém especializado. Mas o mesmo poderia ser dito para todos os outros papéis.

Então, na sua segunda pergunta, sobre como você oferece uma experiência de usuário de alta qualidade usando o Agile. Nós o gerenciamos no último projeto de scrum com o qual participei, envolvendo o analista de negócios e o cliente com antecedência e frequência. Além disso, tínhamos um desenvolvedor com um interesse particularmente bom pelo UX. Ele tendia a fazer pequenos ajustes nas UIs nas quais os desenvolvedores estavam trabalhando depois de realizarem os commits.

Não entregamos UX perfeito no final de cada sprint. As demos geralmente expunham um problema ou dois da perspectiva do UX. Mas nós os corrigimos para o próximo sprint (se valesse a pena para o cliente) e, quando lançamos a produção, tínhamos um UX muito sólido.

Se por UX, você quer dizer designer de interface do usuário, eles são apenas outra função ou recurso para a equipe. O design da interface do usuário, como qualquer design, detalha um projeto. Há uma quantidade razoável de trabalho de arquitetura / design que deve ser feito antecipadamente e há uma quantidade que pode ser feita conforme você avança.

Deve-se observar que as tarefas de design da interface do usuário geralmente não se encaixam no mesmo escopo de um sprint de desenvolvimento. Ao projetar um componente de interface do usuário, o design pode levar vários sprints para implementar.

Na prática, costumo achar que os designers de UI / UX precisam de um prazo razoável para lidar com aspectos que devem ser consistentes em toda a solução. Eu gosto de pensar nisso como arquitetura de software. Muitas vezes, o design de componentes específicos pode ser executado rapidamente antes da implementação, mas costumo constatar que, uma vez que os designers estejam em andamento, eles podem acelerar muito a implementação. Os sprints posteriores tendem a ser bons lugares para implementar / explorar a aparência e a sensação, além de obter feedback de usabilidade à medida que a solução começa a tomar forma. Os resultados desses exercícios posteriores são realimentados no planejamento do próximo sprint.