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.

Por | Tags: , , , , , , | Alterado em 11/11/12 às 12:11

Comentários

  1. Robson Waterkemper disse:

    Olá. Muito interessante o seu artigo. Já trabalho com UX e Métodos Ágeis desde 2009 e sempre muito legal ver a visão de outras pessoas com o mesmo perfil que eu.

    No entanto, tenho algumas experiências diferentes. A primeira dela é que o Feedback do Cliente, ou P.O. não precisa ser feito necessariamente em uma Review. Podemos pegar esse feedback a qualquer momento. Assim, uma história pode ser completa sim em um único Sprint, mesmo passando por todos as etapas de aprovação (Wireframes, Layout, Protótipo e Funcionalidade).

    Inclusive, incluímos uma tarefa de QA (Quality Assurance) de Negócio no final de cada história para que o P.O. a veja pronta de verdade antes da Review final. Isso evita rejeição de histórias no final do Sprint. Só há rejeição por falta de tempo ou de escopo totalmente entendido errado, e não por não tem ter entendido algum detalhe que era crucial mas facilmente consertado.

    Pensar a UX como um todo no começo, um Sprint 0, na realidade é um valor bem concreto que pode ser escrito como uma história: “Ter uma experiência consistente (como Usuário)”. ou “Acessar o site com boa usabilidade (como Usuário)”. Assim como outros valores mais abstratos podem ser histórias concretas: “Acessar o site com uma identidade visual coerenten (como Usuário)”, “Ter uma solução de tecnologia consistente (como Empresa)”.

    A questão do time de UI estar sempre um pouco à frente é comum, mas também é uma armadilha. Nos métodos ágeis, é um do conceitos, o projeto dar guinadas radicais no caminho para onde se está indo. Se o time de UI está adiantado, ele pode estar gastando horas em histórias que de uma hora para outra se tornem não prioritárias. O ideal é manter todo mundo junto, fazendo pequenas entregas. Um outro fator importante é a interação de quem faz UI e quem desenvolve o back-end. Todos no mesmo time, cria troca entre os perfis de profissionais, agregando qualidade ao produto como um todo. Hoje cada vez mais temos que viver menos o Spec (Especificação) e mais o Sketch (Rascunho).

    • Robson, por partes 🙂
      Feedbacks e aprovações durante o sprint são ótimas e acho que é o ideal também. Mas há situações onde é difícil conseguir um retorno rápido. Formalizar um encontro para aprovações sempre me ajudou antes mesmo do Scrum. Meu sonho de consumo agora é ter o PO dentro da sala novamente.
      Este QA com o PO antes do review é um outro sonho! 😀
      Sobre as guinadas durante o projeto, dê uma olhada no artigo da Smashing Magazine linkado logo acima. Curti bem o conceito de design spikes ou um freio de mão no projeto para que todos (designers e desenvolvedores) possam procurar novos caminhos para o produto. E acho que este é justamente o grande ponto de conflito do Scrum com o UX: quando é necessário reformular tudo por causa de uma mudança de estratégia, tendências ou tecnologias.
      Obrigada! Bjs,

  2. Olá, estou ressuscitando o post, espero que vc leia, Simone 🙂
    Bem, minha equipe trabalha no seu primeiro cenário, porém, o PO participa de todo o sprint, aprovando cada tarefa e participando das reuniões diárias. Ou seja, o designer tem a aprovação das telas e interações no prazo de no máximo um dia após a conclusão da tarefa.
    Isso é ótimo, pois a equipe sente confiança na implementação. Claro que não elimina os problemas e a possibilidade de design spikes, mas já é algo.
    O conflito é não termos espaço para as metodologias de UX dentro das histórias. Temos liberdade para usa-las, mas os entregáveis são sempre direcionados para o usuario (representado pela figura do PO), ou seja, personas, pesquisas, wireframes, etc, não são considerados entregáveis.
    Também não temos participação do designer no planejamento do escopo, isso dificulta a equipe estimar os pontos de cada história.
    Ainda não encontrei um modo de incluir o UX no scrum sem causar muita resistencia na cultura empresarial e na administração dos projetos.

Faça um comentário

*