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

Ordenando os seletores CSS

O artigo sobre organização do CSS era para ser dividido em duas partes. Desisti logo depois. Achei que estava indo longe demais na minha mania de código limpo. Mas a Smashing Magazine me provocou e tive que voltar atrás. Vamos listar alguns parâmetros para pôr uma ordem definitiva nos seletores CSS.

Tags: , , ,

CSS livre, leve e solto

Há várias formas de deixar seu CSS levinho, levinho. Algumas são automáticas, mas as melhores mesmo são aquelas que exigem apenas um pouco de disciplina e atenção na hora de evoluir com o código e a montagem.

Os melhores métodos para diminuir o tamanho dos arquivos passam por configurações no servidor. Compressão GZIP e configuração do “expires” estão entre os meus métodos favoritos. Mas nem sempre o desenvolvedor tem permissões para fazer isso ou solicitar. Aqui seguem algumas dicas de fazer otimização no CSS que não precisam de mais ninguém a não ser o próprio desenvolvedor de interfaces.

Diminuindo o número de requests

Alguns layouts exigem vários pedacinhos de botões, fundos, setas, efeitos. Cada uma das imagens recortada pode ser bem pequena, 1Kb apenas, mas para cada arquivo solicitado para o servidor há outro 1Kb referente à requisição do arquivo. Algumas sugestões para não sofrer na mão dos requests são:

  • Todos os ícones de uma mesma palheta num mesmo arquivo - icon-king.comProcurar imagens .gif ou .png que utilizem a mesma palheta de cores e condensá-las num mesmo arquivo. Se for usar como fundo, use posicionamento da imagem e um crop. Ninguém vai notar.
  • Imagem de referência para efeito de item no estado normal e ativo - everaldo.comSe houver menus com estado de inativo, ativo e hover, coloque todos os estados em um mesmo arquivo, posicionando um estado sobre o outro. Altere o posicionamento do fundo para cada estado.
  • Cada arquivo CSS é um request diferente, não importando se ele está sendo chamado no HTML ou importado dentro do CSS (@import). Economize arquivos! Use novos arquivos CSS apenas se absolutamente necessário. Para melhorar a organização, faça blocos de definições divididos por mídia (@media) e por tipo (tags, classes, IDs). É como usar o conceito de CSS frameworks, mas com menos arquivos.

Usando atalhos

Para cores:

Antes:

border-color: #FF0099;

Depois:

border-color: #F09;

Para espessuras:

Antes:

border-width: 1px 1px 1px 1px;
margin: 10px 0px 10px 0px;

Depois:

border-width: 1px;
margin: 10px 0;

Para fundos, fontes e listas:

Antes:

font-weight: bold;
font-style: italic;
font-variant:small-caps;
font-size: 1em;
line-height: 1.4em;
font-family: Verdana, Arial, Helvetica,sans-serif;

Depois:

font: bold italic small-caps 1em/1em verdana, sans-serif;

Usando alternativas

Algumas propriedades possuem alternativas. Escolha sempre a com menos caracteres. Por exemplo, troque font-weight:bold por font-weight:800, background-position:left top por background-position:0 0 e assim por diante.

Pontuando corretamente

Não é necessário encerrar cada bloco de seletores com ponto-e-vírgula:

a{
    color:#F09;
    text-decoration:underline
}

Vamos começar tudo de novo…

Mesmo que você não seja fã de CSS frameworks, use pelo menos um conjunto de parâmetros CSS para limpar todos as definições de estilo nativas do navegador. Causa um estranhamento no início, mas é bem mais rápido de implementar. Além disso, evita várias definições para limpar estilos espalhados pelo site e hacks para tentar igualar as definições de um browser para outro. Veja sobre reset.css mais no site do Eric Meyer.

Robôs para seu prazer

Para a publicação de uma inteface, é interessante usar alguma ferramenta de otimização como o Icey – CSS Compressor, Clean CSS e o CSS Tweak. Teste o site nestes e em outras ferramentas pois os resultados variam de projeto para projeto.

Lembre-se sempre de fazer um back-up dos seus arquivos antes de utilizar uma destas ferramentas. E teste, teste tudo novamente depois de passar os arquivos .css por estes filtros.

Há ferramentas para condensar arquivos de CSS e de JavaScript.

Referências:

Tags: , ,