Criação + Scrum: mais uma visão sobre UX e desenvolvimento ágil

Entre o artigo anterior e este, foram seis meses onde fiz um curso para CSM, certifiquei-me, troquei de emprego e comecei trabalhar com outros projetos que integram equipes que usam metodologias de experiência do usuário e as que usam as metodologias de desenvolvimento ágil. Gostaria de compartilhar algumas destas novas experiências.

Durante o curso, surgiu o conceito de haver um time separado para ajudar o product owner a definir o backlog. Em um PO team podem estar contempladas várias competências que não estão relacionadas a desenvolvimento tecnológico, inclusive as de UX, como arquitetos de informação, designers de interfaces e até mesmo desenvolvedores front-end. Tudo depende de qual seja a definição de pronto (ou definition of readyDoR) para o dev team começar suas histórias: layouts ou código HTML.

Nada impede que este time associado ao product owner seja uma célula própria e que siga os ritos Scrum como tal.

Um cenário

Em um projeto em que estou envolvida agora, a empresa que o implementou optou por não ser obrigatório encerrar uma história ao final de um sprint. Aceitar que uma história pode precisar de mais um sprint para ser concluída significa tempo para que as tarefas que gerem dependências podem ser feitas sem sobrecarregar alguns dos membros do time, como o front-end e o QA, sem que seja encarado como uma falha do processo (e do time). A estrutura básica de uma história de desenvolvimento simples pode ter os seguintes conjuntos de tarefas:

  • Criar cenários de testes
  • Desenvolver código server-side
  • Desenvolver código HTML/CSS/JS
  • Desenvolver código server-side (dependente do código HTML/CSS/JS)
  • Testar (dependente de todas as tarefas anteriores)

É importante enfatizar o conceito de minimizar a dependência entre tarefas para não cair nos mesmos problemas de um modelo em cascata. A estrutura de um time e os processos envolvidos devem facilitar o paralelismo entre as tarefas de uma história para que idealmente se consiga iniciar e concluir uma história em um sprint. As dependências são problemas do mundo real que ficam mais explícito com a variedade de competências que uma história pode requerir. Por exemplo, para realizar testes funcionar é necessário que o desenvolvedor já tenha feito sua parte de acordo com o que foi planejado.

(De novo, o que exponho aqui são formas que alguns times do mundo real acharam para solucionar problemas. Tenho certeza que outros times por aí podem ter encontrado outras soluções bem mais fiéis ao framework.)

Neste cenário, o DoR inclui layouts e arquitetura que foram desenvolvidas pelo PO team ou por outra célula. Vemos aqui, de novo, que as histórias do designer não são as mesmas que as do programador. Muitas vezes, a visão de como o sistema deve funcionar não está completa até a aprovação do layout das telas.

Por outro lado, histórias podem ser criadas apenas para incorporar outras tarefas de UX, como testes de usabilidade. Estas histórias podem estar relacionadas a datas de releases, por exemplo.

Mais informações sobre Scrum podem ser encontradas no Agile Atlas.

Este artigo é uma continuação do texto “Criação + Scrum: como encaixar UX nas metodologias ágeis“, de 11/11/2012.

Por | Tags: , | Alterado em 07/05/13 às 14:05

Comentários

Sem comentários. Seja o primeiro.

Faça um comentário

*