Agile UX: Projetando a User Experience no Mundo Ágil – Parte 2

  •  
  •  
  •  
  •  

E aí, pessoal!

Hoje vou dar continuidade sobre esse assunto que já iniciei aqui. Nesse post irei falar especificamente como apliquei o Agile UX no time que trabalhei em 2015 e que foi tema da minha palestra no Regional Scrum Gathering 2015.

Antes de começar, irei falar um pouco sobre o time. Formado por 2 desenvolvedores, 1 designer / scrum master e  1 product owner (PO). Utilizou-se como método ágil o ScrumBan (Scrum e Kanban), trazendo bons aprendizados até conseguir migrar totalmente para o Kanban e nossas sprints tinham duração de 10 diasDestaco que o time já estava bem entrosado e já conhecia seu ritmo. Outro fator que foi tranquilo e favorável para esse experimento dar certo, é que trabalhávamos em um projeto interno, ou seja, tínhamos acesso direto ao cliente e ao usuário final, facilitando muito a comunicação.

COMO FUNCIONOU?

Agile UX by Diogo Riker

Agile UX by Diogo Riker

PASSO

numero-1

Na reunião de planejamento, após definir o sprint backlog, o time definia a pontuação baseada em esforço, utilizando o planning poker, e planejava as atividades do item de maior prioridade da lista. As atividades das outras estórias eram definidas no decorrer da sprint após o término do item anterior.

É muito mais produtivo ter 3 reuniões de planejamento de 1h de duração no decorrer de uma sprint do que 1 reunião de 3h, pois evita desperdícios e diminui a chance de replanejamento no próximo ciclo.
PASSO

numero-2

Após a definição das atividades do item 1 do sprint backlog, o PO passava a ideia geral do item 2 e explicava qual o objetivo que aquela user story deveria alcançar a nível de negócio. Baseado nisso, o time realizava um brainstorming para possíveis soluções, selecionava a mais interessante e menos complexa e, ao final, esboçava no quadro branco a ideia de um protótipo de baixa fidelidade a ser validado com o cliente (ou usuário final) pelo designer, ou seja, eu :).

Time participando da criação do protótipo

Time participando da criação do protótipo

É muito importante a participação de todos nessa atividade, pois isso facilita muito o entendimento das funcionalidades e regras de negócios para o time, resultando em vários benefícios.
PASSO

numero-3

Com a ideia criada colaborativamente, eu começava a trabalhar no protótipo (de baixa fidelidade) da funcionalidade, ou parte dela que seria desenvolvida, destacando o fluxo de navegação, a interação e alguns outros fatores (como os princípios de Nielsen), a fim de validar com o cliente ou usuário final enquanto o time de desenvolvimento trabalhava no item 1.

Nem sempre é possível realizar um teste de usabilidade completo, mas tento fazer o mínimo possível e viável durante a fase de validação.
PASSO

numero-4

Após a validação, eu ia trabalhar na versão final do protótipo do item 2, deixando-o pronto para os desenvolvedores.

Quando havia alguma mudança no protótipo após a validação, buscava alinhar as expectativas dessa mudança com os desenvolvedores para todos estarem cientes da versão final.
PASSO

numero-5

Após o término da criação do protótipo, eu voltava a trabalhar exclusivamente no item 1, junto com os desenvolvedores, para trabalhar na User Interface (UI) e codificação do front-end (HTML e CSS) do mesmo.

PASSO

numero-6

Quando entregávamos o item 1 para o cliente, o time marcava outra reunião de planejamento, agora do item 2, planejando suas atividades e estimando o esforço e, começava todo o procedimento de brainstorming, filtragem e prototipação agora do item 3 do nosso sprint backlog, conforme a imagem a seguir.

Agile UX by Diogo Riker

Agile UX by Diogo Riker

Como vocês podem perceber, apenas um protótipo final criado colaborativamente e validado com o usuário, é o suficiente para os desenvolvedores não ficarem impedidos de trabalharem, pois todos participaram do processo de criação.

Escrevendo esse post, parece que tudo foi muito fácil, QUEM ME DERA. mas não foi! Esse método gerou bastante desconforto para o time inicialmente, pois a afinidade entre seus membros era frágil e a cultura ágil não fazia parte do cotidiano de todos os integrantes. Entretanto, quando esses fatores começaram a se alinhar, a equipe aperfeiçoou-se de tal forma que as entregas passaram a ter mais valor para o cliente, pois o processo de geração e validação da solução apresentada trouxe mais segurança na utilização do Agile UX no decorrer do projeto, trazendo a responsabilidade para todos os membros do time, pois todos participaram.

Portanto, pude perceber que a participação do usuário no decorrer de uma sprint foi algo muito enriquecedor, pois o alinhamento das expectativas dele com o time de scrum impediu possíveis decepções que ele poderia ter. Outro ponto bem interessante, foi que a participação de todos na criação das ideias, reduziu o risco de ter uma wiki extensa (caso entrasse alguma pessoa nova no time), pois todos saberiam explicar o objetivo do sistema e das funcionalidades.

Outro ponto que destaco é que a utilização do Design Thinking e do Lean UX foram muito enriquecedores, pois além de tudo, a redução de desperdício foi considerável: tivemos menos retrabalho e focamos os esforços em apenas uma funcionalidade por vez, evitando começar o desenvolvimento de diversas ao mesmo tempo e não entregando nada de valor para o cliente. Como diz a máxima do kanban: Pare de começar e comece a terminar! ;).

Mas Diogo, e se um desenvolvedor não tiver mais nada para fazer naquela funcionalidade, ele não pode começar outra? Eu diria que é melhor não e vou citar alguns fatores: a chance de retrabalho é alta, a prioridade pode mudar ou o ciclo pode ser cancelado, transformando o trabalho dessa pessoa em vão. Acho mais interessante focar no que esta mais próximo de terminar do que começar outra do zero. Nesse caso, percebo uma excelente oportunidade para essa pessoa adquirir um novo conhecimento trabalhando em algo que não é de sua área ou em melhorias no time.

Essa foi a minha experiência com esse método incrível. Atualmente estou trabalhando em outro time no qual tenho que adequar esse processo para essa nova realidade, ficando claro que esse método, assim como o Scrum, é flexível e adaptável. Tem sido muito interessante, mas isso é um assunto para outro post.

Grande abraço.

Showing 3 comments
  • Luciana Buchaul
    Responder

    Oi Diogo, estou adorando seus posts…. Sou da área de Compras de Tecnologia e atualmente a empresa no qual trabalho esta partindo para contratação de desenvolvimento de SW utilizando a metodologia Ágil. Tenho 2 perguntas para voce :
    (i) Voce tem algum post ou orientação de como o pessoal de Compras deve montar a planilha comercial, quais são os pontos de atenção etc ?
    (ii) Voce indica algum curso para “não tecnólogos” que possa ajudar a enteder melhor a metodologia ?
    Desde já agradeço sua atenção e fico no aguardo do seu retorno.
    abs, Luciana Buchaúl

    • Diogo Riker
      Responder

      Olá Luciana!!!

      Fico muito feliz que esteja gostando dos posts!! 🙂

      Infelizmente, acho que não sou a melhor pessoa para responder a sua pergunta. Antes de fazer qualquer orientação, preciso entender o seu contexto, pois é uma área que não tenho ideia pra onde vai. Mas te convido a participar da comunidade de agilidade no slack. Lá tem várias pessoas que possam te ajudar melhor a pensar numa metodologia.

      Com relação a segunda pergunta, qual metodologia você está falando? 🙂

  • A.S.
    Responder

    Olá,
    Quais métodos de avaliação de UX vocês usavam?

Leave a Comment