Criação + Scrum: como encaixar UX nas metodologias ágeis

Andei conversando nos últimos dias com designers, arquitetos de informação e gestores que já estão trabalhando com metodologias ágeis. Notei que há muitas dúvidas de como a criação pode alinhar com desenvolvimento na prática. Vamos rever aqui alguns métodos de posicionamento das tarefas de UX dentro do modo de produção.

Obs.1: Não sou especialista em Scrum. Sou apenas mais uma parte desta engrenagem que luta diariamente para encaixar todas as etapas de crição de interfaces nas metodologias ágeis de desenvolvimento, com todas as dificuldades do dia-a-dia.

Obs.2: Esta não é uma regra e sim um estudo de caso. Cada empresa, assim como cada time, deve encontrar a melhor forma de adaptação à metodologia. Agências que possuem uma célula que lida com diversos clientes ou uma de dedicação exclusiva a um cliente devem se planejar de modo bem diferente.

Resumindo um pouco da terminologia que usamos na célula em que trabalho somente para referência:

  • Célula: grupo de pessoas com competências diversas responsáveis por entregar as funcionalidades de um produto.
  • Sprint: período de tempo para realização de uma entrega completa. Trabalhamos aqui com dez dias úteis.
  • Planning: reunião do time com o PO para tirar dúvidas sobre as regras de negócios. É realizada no primeiro dia do sprint.
  • Review: apresentação do trabalho realizado durante o sprint.

Nos casos estudados, contamos com os seguintes papéis e competências:

  • Product owner (PO): traz as regras de negócio, representando os interesses de clientes e usuários.
  • Scrum master: responsável por manter o ritmo da equipe, resolvendo impedimentos e atuando como mediador entre o time e outras áreas.
  • arquiteto de informação e designer de interação: elaboram as interfaces, estabelecendo a navegação entre telas ou funcionalidades.
  • front-end: responsável pelos métodos de codificação em HTML/CSS e da definição das tecnologias de interação (frameworks e plugins em JS).
  • desenvolvedor: integra o sistema o código HTML sugerido, realiza alterações no sistema e testes funcionais.

Lembro que há situações onde um profissional pode execer duas ou mais competências. Um designer de interação também pode fazer as vezes de um arquiteto de informação, assim como um front-end pode trabalhar programar em linguagens server-side.

Em teoria, teríamos que idealizar, planejar, criar e desenvolver uma funcionalidade em dez dias. Isto certamente funciona bem para a criação de uma nova microinteração ou a evolução de uma funcionalidade onde as tarefas relacionadas às diversas competências podem ser realizadas paralelamente. Vamos analisar história de uma manutenção evolutiva e suas possíveis complicações:

História: Como usuário quero participar de uma enquete com foto.
Contexto:
O time desenvolveu anteriormente uma funcionalidade de enquete em formato texto que precisa de evolução para atender uma nova necessidade do cliente.

1° cenário: um sprint
Sprint 1: O PO explica a nova necessidade e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas, enquanto os desenvolvedores alteram a funcionalidade. Após aprovação de layouts, o front-end corta em HTML/CSS e adiciona interação em JavaScript. O desenvolvedor integra o HTML ao código, publica em um ambiente de teste e todos validam.

Neste cenário, já encontramos alguns pontos de conflito. O time sente-se mais confortável em trabalhar com telas aprovadas pelo cliente/usuário. Nem sempre dentro do período de um sprint isto é viável. Consideramos que o review é o momento para a aprovação da entrega. Por que não aprovar também layouts, wireframes, fluxos de interação e relatórios de usabilidade?

2° cenário: dois sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, os layouts são submetidos para aprovação e a navegação sugerida é demonstrada.
Sprint 2: O front-end transforma o layout em HTML/CSS e adiciona interação com JavaScript. Ele também testa o modelo de navegação sugerido. O desenvolvedor integra o código HTML ao sistema e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam. Na review, a publicação de uma enquete com foto é demonstrada.

Parece que há perda de tempo neste cenário, mas isso não ocorre na prática. É possível tratar de mais histórias em paralelo. Na prática, é como se arquitetos de informação e designers estivessem em uma célula diferente que anda um sprint à frente.

(Na célula em que trabalho agora, trabalhamos boa parte das histórias em dois sprints. A diferença é que front-end faz sua entrega no primeiro sprint.)

Podem surgir outras complicações. Interações podem ficar mais complexas e demandar mais tempo de desenvolvimento exclusivo do front-end. Torna-se necessário aqui um sprint exclusivo para a montagem do layout em HTML, CSS e JavaScript.

3° cenário: três sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, são apresentadas as telas para atender à nova demanda.
Sprint 2: O front-end transforma o layout em em HTML/CSS e adiciona interação em JavaScript. Na review, são apresentados os protótipos funcionais.
Sprint 3: O desenvolvedor integra o HTML ao código e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam.  Na review, o sistema é apresentado completo.

Além disso, profissionais externos à célula, como analistas de usabilidade ou a equipe de infra-estrutura, podem demandar cortes durante o desenvolvimento para realização de testes. Os sprints mais cortados, quase que por competência, facilitam a integração com outras equipes. Nem sempre a interação leva apenas um sprint o que pode prejudicar o planejamento do time. No caso de testes de usabilidade, por exemplo, há fatores externos como seleção de usuários e agenda de laboratório. Tudo isso deve ser analisado história a história considerando os prazos negociados com clientes e usuários.

O terceiro cenário é o mais próximo do que considero bom hoje. É claro que demandaria um pré-planejamento de três sprints e nem sempre isso é possível.

Para fazer tudo isso funcionar, temos usado também o Kanban (que podemos ver em mais detalhes em outro artigo).

O importante antes de estabelecer uma forma de trabalhar é fazer as perguntas certas sobre o tempo e o nível de envolvimento entre todos os interessados. Além disso, nada impede que variáveis deste modelo podem ser usados como regra em todas as histórias, em histórias de um determinado sprint ou caso a caso. O melhor momento para esta definição é quando a demanda chega ao time que pode ser durante o planning ou em uma reunião anterior de priorização.

Como você e sua equipe trabalham? Tem alguma dúvida? Sugestão? Comente aqui!

Outras reflexões:

  • A formulação da estratégia de experiência do usuário pode ser incompatível com o processo do desenvolvimento ágil. Deve-se concluir toda a pesquisa e desenvolvimento de UX em um Sprint 0 antes de começar o desenvolvimento.
    Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?, por Paul Bryan (UX Matters).
  • Por outro lado, o time de UX deve sentir-se confortável para parar o desenvolvimento e reavaliar conceitos mais amplos. No artigo Fitting Big-Picture UX Into Agile Development (Smashing Magazine), Damon Dimmick introduz o conceito de design spikes.
Tags: , , , , , ,