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

Twitter, I love you

Por que amamos Twitter e não Pownce, Jaiku ou mesmo Plurk? Como nos tornamos tão dependentes do relacionamento com certas ferramentas que, quando necessário, é doloroso migrar para outro serviço?

Twitter is over capacity

Os usuários do Twitter têm sofrido nas últimas semanas com constantes quedas no serviço, limitação no uso dos clientes de terceiros e notificações por mensagem instantânea. Mesmo assim há resistência em utilizar outros serviços. Qual seria o problema?

A primeira resposta seria a lista de amigos. No entanto, é virtualmente possível refazer boa parte dele em uma tarde em qualquer outro site que não dependam de convite, como o Jaiku. Basta enviar um email notificando seus contatos mais próximos. Se o conteúdo do seu microblogging for interessante para seus contatos, o sucesso da migração está garantido. Este não deveria ser o principal obstáculo e pude comprovar isso nas últimas semanas com a enxurrada de convites.

Vários fatores influenciam diretamente o sucesso do Twitter: sua simplicidade, sua interoperabilidade, sua popularidade. Graças a estes dois últimos, vários programas clientes de terceiros foram desenvolvidos pela comunidade, como extensões para Firefox, programas para diversos sistemas operacionais, clientes para celular, sites de mashups. Praticamente qualquer necessidade de experiência de usuário para a publicação e acompanhamento da rede Twitter está suprida. Quem já se acostumou aos seus modos favoritos de leitura, terá dificuldade nestes outros sites, ainda não tão populares.

Something is technically wrong

O grande fator de rejeição do Jaiku, por exemplo, é sua falta de simplicidade e clareza. O serviço optou por oferecer diversos recursos, o que tornou a interface bastante poluída e com poucas opções de personalização. Imagino que integrar todos estes recursos a um programa cliente também seja custoso demais para uma base de usuários não tão extensa.

A crise existencial dos serviços de microblogging é um caso incrível para o dia-a-dia do profissional Web. Temos que manter o foco na simplicidade da interface e objetividade na realização da tarefa. Qualquer firula, principalmente nos primeiros meses de um site, é um risco para a fidelização de usuários.

Ainda hoje, o usuário precisa se sentir conquistado e amado pelo site que participa. E ele não sonha com flores e bombons: o usuário deseja que serviço esteja disponível quando ele precisar. Se o serviço é bom, mas tem suas falhas, o usuário perdoa. Mas cuidado para não fazê-lo se sentir a mulher do malandro. Um dia, ele segue o seu rumo.

Referências e outras opiniões:

UPDATE:

Nos últimos dias, tenho usado o serviço do Ping.fm para publicar microposts para o Twitter, Jaiku, Pownce e Plurk simultaneamente. Foi um achado para a manutenção da base de amigos e para a produvidade no trabalho. Ainda mais com a versão móvel. É uma grande vantagem para o microblogueiro autista que “apenas fala para a parede”. Falta uma ferramenta que integre melhor as respostas que fazem do Twitter, por exemplo, mais uma rede social do que uma plataforma de publicação na Web.

Tags: , , ,

Planejando interfaces Web acessíveis

Update no endereço… Avenida Presidente Wilson 164 – 12º andar

A Synapsis DI está com uma parceria bem legal de desenvolvimento com a 288 Design. Eles estão começando agora com algumas atividades e eu sugeri para eles alguns temas legais para fazer algumas palestras curtinhas, recheadas de exemplos práticos. Eu vou dar a primeira delas sobre acessibilidade:

288 atividades: Planejando interfaces Web acessíveis
A acessibilidade numa interface Web começa antes da fase codificação. Ela toma forma no briefing com o cliente. É ali que se define o público-alvo e que tipo de interação será exercida. Planejar interfaces acessíveis desde a fase zero do projeto é o melhor caminho para a experiência do usuário, seja ele qual for.

Data e hora:
Terça-feira, 9 de outubro de 2007, das 9 às 12 horas

Local: Avenida Presidente Wilson, 164 – 12o. andar – Centro – Rio de Janeiro

Mais informações

Tags: , ,