Design Ágil de UI como parte do Sprint

Ultimamente, tenho recebido com frequência a pergunta se UI Designers devem fazer parte do Scrum Team e se o trabalho deles deve ser incluído nos Sprints do Scrum. Como esse é um tema importante, vamos direto ao ponto.

Os dois objetivos de um Sprint ágil

Existem duas coisas que um time deve levar de cada Sprint:

• nova funcionalidade
• novo conhecimento

Todos sabemos que devemos desenvolver nova funcionalidade em cada Sprint. Afinal, esse é o objetivo de quase todos os projetos: oferecer novas possibilidades aos usuários.

Mas os times também precisam aprender algo novo e sair de cada Sprint mais inteligentes do que antes. Às vezes, um time aprende algo sobre uma tecnologia ou sobre como os usuários enxergam determinada funcionalidade. De vez em quando, um time talvez aprenda algo sobre si mesmo e sobre sua performance.

Ambos os objetivos são importantes.

O que UI Designers fazem durante o Sprint

Durante cada Sprint, os UI Designers também devem perseguir os dois objetivos mencionados acima: funcionalidade e conhecimento. Em um Sprint, um UI Designer ajuda o resto do time a transformar um design em código implementado e testado, enquanto já pensa no próximo recurso a ser desenvolvido (ou nos próximos dois). Isso significa que um Designer trabalha tanto no Sprint atual quanto olha para o que vem a seguir.

O resultado se parece com a figura a seguir. Nela fica claro que, embora escrever e testar código seja parte do Product Backlog, um User Interface Designer deve dedicar um tempo determinado (talvez até a maior parte do seu tempo) olhando para os próximos itens. Mesmo assim, continuam sendo um time trabalhando junto em um Sprint.

A primeira prioridade do Designer deve ser o trabalho do Sprint atual. Se um membro do time tem perguntas sobre o design de um Product Backlog Item que está sendo trabalhado, o Designer não continua focando no próximo Sprint, mas primeiro responde às perguntas sobre o trabalho do Sprint atual.

E quanto a outros papéis?

Pare um momento e pense sobre tudo o que você acabou de ler sobre UI Designers. Agora pense nisso em relação a Product Owners, analistas, designers de banco de dados, arquitetos e qualquer papel que tenha a ver com o que vem a seguir no projeto.

Nada muda, exceto talvez as proporções de tempo. Um Designer pode passar a maior parte do tempo aprendendo algo novo, mas também desenvolve um pouco de funcionalidade. Para outro papel, pode ser exatamente o contrário. No entanto, o tempo em um projeto ágil é sempre dividido entre desenvolver funcionalidade e ganhar conhecimento, independentemente do papel.

O UI Design não precisa ser perfeito logo de cara

Por ser permitido ao Designer olhar para frente, o time não pode exigir dele que finalize o design imediatamente. O Designer deve simplesmente adiantar o suficiente para que o Product Backlog Item possa ser finalizado pelo resto do time no próximo Sprint.

No final do Sprint, o time deve ter a sensação de que não teria conseguido finalizar o item se tivesse recebido um pouquinho menos de informações do Designer. Isso significa que alguns Product Backlog Items precisam ser examinados com muito cuidado (e isso mais de um Sprint antes), enquanto outros itens talvez não precisem de análise prévia.

Todos os itens que um Designer quiser examinar fora do Sprint atual devem ser escolhidos em uma conversa com o Product Owner. Assim, o Designer evita trabalhar em algo que o Product Owner pode considerar sem importância mais tarde.

Isso não leva a um design ruim?

Uma preocupação frequente é que isso poderia levar a um design ruim. Não seria melhor se o Designer pudesse pensar previamente sobre todo o sistema? No próximo artigo do blog, vou explicar por que essa abordagem não leva a um design ruim.