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: , , , , , ,

Maturando o HTML

Construir um bom código HTML garante um bom andamento de um projeto de desenvolvimento de interfaces. Muitos dos atributos e marcações que normalmente sentimos falta apenas na integração das camadas de apresentação e de comportamento podem ser antecipados em um código HTML maduro e eficiente, deixando apenas as particularidades de cada interface para ajustes pós-integração.

Tags: ,

Visie: Code Show

Code Show
17 de Agosto de 2007.
E duas semanas depois, alguns notas sobre o Code Show:

  • Ótima dica do Élcio para separar entregas de um grande aplicativo em pequenos módulos. O cliente vê que o projeto está andando, os projetos mais fáceis de gerenciar e o tesãozinho de trabalho cumprido quase que diariamente.
  • Que nervoso me deu com Diego espalhando aquele font-family no código todo! Lembrete para mim mesma: escrever algo sobre boas práticas para CSS, reset.css ou mesmo sobre CSS frameworks. Update: Escrevi! Uma outra visão sobre CSS Frameworks.
  • Outro ponto que me deixou tensa foi a estrutura da página. Quando começo a montar um conteúdo, coloco apenas as tags indispensáveis para a compreensão do conteúdo. Qualquer div ou span de estrutura só entra quando estou feliz com o conteúdo e começo a montar o CSS. Isto minimiza a ocorrência de tags desnecessárias, principalmente para quem está começando com o CSS design.
  • Não vi os meninos validarem o código HTML durante o processo. Não vi se o CODA já faz isso e eu perdi a deixa. Estou sempre validando para evitar erros de renderização bizarros e evitar o acúmulo de erros em todas as páginas. O mesmo serve para a verificação de acessibilidade e usabilidade. Assim que estou com o HTML montadinho em todo site navego para ver se faz algum sentido. Isso antes mesmo de ter um layout! Eu sei que era apenas um exercício, mas era o lugar para aprendermos um pouco das práticas uns dos outros.
  • Subversion é tudo nesta vida. Ainda vou ter um! *:D
  • Estava curiosa sobre o Python, mas foi só isso. Não me apaixonei.
  • Foi ótimo finalmente conhecer Elcio, Diego, Rafael e Jader, e conhecer o menino Victor, que levou a gente para almoçar, e todo mundo mais!
    Visie Code Show
  • Preciso de um destes aparelhinhos wi-fi. Me senti em 1986 com bloquinho de notas e lapiseira.
  • Ainda não vi a gravação do CodeShow! Tenho que fazer isso logo!!!
  • Não comi pizza, mas tomei um chopp preto ótimo no Prainha Paulista (que infame!).
  • Nunca vá de vestidinho para SP no inverno. Você vai congelar.

Uma resenha mais profunda no blog do Jader.

Tags: , , , ,