Mais pensamentos sobre Agile UX
Continuando no tema de Agile UX, estive pensando bastante sobre a forma de trabalhar quando usamos técnicas ágeis comparando com o ambiente tradicional (waterfall), em paralelo conversei com algumas pessoas (UX guys) para saber o que eles acham, e minhas impressões seguem abaixo.
Adicionando um pouco de contexto, o foco deste post é conversar sobre duas formas de trabalhar em ambientes que envolvam UX no desenvolvimento de projetos Web:
Quando pensamos com mais calma sobre estas comparações, acho que a conclusão fica meio óbvia, principalmente se o objetivo é ter a melhor qualidade possível como “saída” do nosso trabalho. Explicando: ao desenvolvermos um projeto novo o que é mais fácil? Fazer pequenas partes muito bem, com foco total e com o decorrer do tempo ir desenvolvendo as outras partes enquanto se ve o software funcionando, OU fazer um grande projeto com milhões de partes de uma só vez, para depois de um tempo razoável entregar todas as telas e suas variações para a próxima área responsável? É importante lembrar que em times ágeis o que é definido como entrega é software funcionando e não um monte de telas, especificações, casos de uso ou documentações.
Fazendo um paralelo com o nosso dia a dia (pelo menos eu sou assim), quando tentamos fazer muitas coisas ao mesmo tempo, geralmente não fazemos nada com profundidade e no final acaba tudo ficando “meia boca”. Ao ir desenvolvendo novas funcionalidades ou melhorias a cada 15 dias (citando um exemplo da duração de um Sprint aqui no Yahoo!), podemos pensar bem a respeito do funcionamento de cada item e, mais importante, temos a chance de envolver todos no time nas decisões: desenvolvedores, designers, Produto, QA, etc. Com isso eu sinceramente acredito que a qualidade geral do produto e das decisões tomadas aumentam exponencialmente e ficam cada vez mais consistentes com o tempo.
Sempre que vi um projeto sendo feito da forma tradicional, existia um batalhão de Designers que faziam “milhões” de telas, para que todas as variações possíveis fossem mapeadas antes de serem entregues para a equipe de desenvolvimento, muitas vezes chamavamos estas pessoas de “replicadores de telas”. É óbvio que quando se faz um trabalho em massa, como se fosse uma fábrica, nem tudo terá a melhor solução e alguns parafusos deverão ser apertados mais tarde, algumas partes vão precisar de alguns remendos para encaixarem e com certeza várias das telas criadas nunca serão implementadas representando total perda de tempo e dinheiro. O mesmo acontece com as fábricas de software, elas fazem com que os desenvolvedores trabalhem em paralelo como se cada um fosse uma máquina (os famosos Code monkeys). Os designers “Replicadores de telas”, nada mais são do que uma versão da fábrica de software aplicada ao UX.
Estes são conceitos bem básicos sobre desenvolvimento ágil e que podem ser melhor visualizados através das duas figuras abaixo:
Figura 1: Sprints com entregas constantes
Na Figura 1, temos o modelo ágil onde ao final de cada Sprint sempre haverá uma entrega de software funcionando, ou seja, com entrega de valor para o cliente, valor perceptível e paupável, pois estes poderão ver seu produto funcionando e se tornando real de forma evolutiva. Uma situação interessante é que se o orçamento acabar no Sprint 3, pelo menos o produto terá 3 Sprints completos de funcionalidades entregues e funcionando em produção.
Figura 2: Metodologia Waterfall
Na Figura 2, temos o método tradicional, onde vemos que o produto só vai funcionar ao final de quase todas as etapas, o que pode levar a tomadas de decisão preciptadas. Aplicando a mesma situação, se o orçamento acabar na fase 2 (Arq. da Informação e Design) o que podemos entregar para o cliente é uma série de documentos e PSDs, nada de software funcionando.
9 Comments
Antonio Carlos Silveira on January 14th, 2009
Luiz, essa história do pato foi excelente hahaha LOL.
abs,
Antonio
Luiz Aguiar on January 14th, 2009
Blz Antonio?!
Uma dúvida dentro desse mesmo contexto, como vcs trabalham com os wireframes ai Yahoo!? Entram no mesmo ciclo do scrum, correto?
Muito bom novamente o post.
[]s
Antonio Carlos Silveira on January 14th, 2009
Olá Luiz,
nao trabalhamos com wireframes diretamente, temos os conceitos de estrutura e arquitetura mas isso é feito quase que diretamente no código pelo UED do time. Não investimos muito tempo em arquivos e documentações e colocamos o máximo de esforço no produto em si, diretamente com código. Assim podemos ver como serão as animações e como os dados e informações irão fluir na interface.
Adolfo Sousa on January 15th, 2009
Na palestra do Rails Summit, o Obie Fernandez falou que eles têm uma modalidade de desenvolver projetos lá na Hashrocket chamada “3-2-1 Launch”, ou seja, eles se comprometem a entregar o produto em 3 dias. Nestes casos, ele contou que eles precisam de todas as telas do sistema já definidas e “prontas” antes de começar o desenvolvimento. Em todos os outros casos eles optam pelo design iterativo e incremental.
Antonio Carlos Silveira on January 15th, 2009
@Adolfo
Interessante este approach, mas pelo que entendi da sua explicação, eles tem 3 dias para fazer o desenvolvimento (código)
Mas e quanto tempo levam para ter todas as telas prontas?
Na verdade o tempo total do Projeto vai desde o momento em que ocorreu o sinal verde para executar a idéia até a aplicação estar em produção.
karinedrumond on June 23rd, 2009
Bacana…
Dúvida: e neste seu contexto, vocês tem algo como o “ciclo zero”? Onde teoricamente sao definidas estrategias do produto, quem sao os usuários, necessidades, etc? Pelo que li sobre a sua experiência voce conta sobre o ciclo 1 em diante.
Ja li em outros artigos sobre Ux em ambiente agil (como este do D. Norman: http://www.uigarden.net/english/why-doing-user-observations-first-is-wrong), que nesta etapa entrariam pesquisas com usuários, identificacao de ideias, necessidades, etc, mas este ciclo é antes do sinal verde, como vc mencionou acima. Como você vê a participaçao de designers nesse ciclo zero no agil?
E mais uma outra dúvida: me parece que o UED é responsável pelo desenho (desenho visual e de arquitetura) e impletacoes da interface, mas a equipe aplica tecnicas de validaçao com usuarios, como testes rapidos de usabilide, etc? Como fica a questão do feedback do usuário?
Ainda tenho muitas dúvidas em como integrar o processo de design centrado no usuário ao processo agil, de uma maneira efetiva (mantendo os principios ageis) sem perder tecnicas importantes para Ux, como testes com usuários, pesquisa estratégica, etc.
Abs!
UxAgile. Em busca da integração perfeita « Designing for Humans on July 22nd, 2009
[...] 22, 2009 · Deixe um comentário Neste artigo aqui, (recomendo ler o post dele antes para entender o meu) o Antônio Carlos fez uma série de [...]
Marcelo Eduardo on July 23rd, 2009
Opa Antonio,
(nem sei se vc se lembra de mim na época da globo.com, trabalhava com o Márcio e cia) 
De qualquer forma, respondi no site da Karine acima, e coloco aqui tb um pouco dos desafios que temos passados por aqui no instituto Nokia:
Após os treinamentos, e primeiras tentativas do scrum, obviamente o time queria seguir da melhor forma, integrado trabalhando junto etc. Tentamos e falhou. Falhou pelo fato dos 15 dias serem complicados para o time de design prover o que o time de desenvolvimento precisava naquele dado sprint.
Um ponto importante a ser colocado aqui é a plataforma alvo. Quando nossos projetos começam aqui, a gente perde uma coisa que tinha na época da internet: é mouse e teclado (tudo bem hj tem mobile phone) mas mesmo assim: perde todo o previous knowledge, etc, e acaba tendo um trabalho que PRECISA de um detalhamento maior.
O fato é : como vc colocou, se um time tenta “prever” tudo, e fica “replicando” tela vc vai ter um trabalho meia bomba sim. O que fizemos pra contornar isso?
a) Concept: antes do projeto ganhar sinal verde, utilizamos entre 1 ou 3 semanas como uma exploração pesada do produto, pegando um Product backlog BEM alto nível e dissecando ele em histórias estratégicas para o produto e para.. o time de design. Com essas histórias em mãos, criamos uma sequência de sessões não incrementais por feature, mas por pacote onde a gente tenta sim ir + fundo, mas pra previnir que um conceito de interface esteja errado quando a gente chegar lá no sprint 12, e for criar uma sub aplicação X que pede um menu diferente.
Mas qual a diferença afinal? é que apesar de tentarmos prever, aqui não é pra definir a UI em si, e deixar pronto antes do dev team começar, mas sim encontrar os corner-cases principais da aplicação antes do dev team chegar lá e jogar o pepino pra gente no meio do sprint.
Com isso, continuamos “ágeis” no aspecto de ter sim, design em cada sprint trabalhando junto com desenvolvimento, e conforme o desenvolvimento vai desbravando as features, o design vai melhorando, refinando sprint por sprint mas com a segurança básica que nenhum imprevisto gigantes (que poderia requesitar um redesign completo) aconteça.
Pq isso/ pq muitas vezes nós não possuímos sequer o hardware que será usado, então perdemos a referência “o usuário tem teclado e mouse e estar em um browser de internet ou applicativo flash). Acabamos as vezes criando tb a interface de usuário (hardware) e lidando com desafios no meio do projetos, quando o nosso projeto é na verdade todo o “shell” de usuário do sistema operacional que vai no aparelho.
Finalizando:
Nos criamos de forma iterativa na fase de conceito, tentando fazer “todo o produto” (na verdade uma amostragem considerável) pelo menos 2 ou 3 vezes. Na terceira vez, temos protótipos em flash / slides / etc da UI e já sabemos onde atacar pros primeiros 2 ou 3 sprints.
Durante os sprints, além do trabalho dia a dia do lado, aquela ajuda pra nada sair errado e ser corrigido só no outro sprint, o time tb já prever os problemas pro sprint que vem, e criar qualquer outro “mockup” que o dev precise (eg: as vezes temos UI com muitas animações transições, menus dinamicos para X items que precisa ser dissecado em todas as possibilidades ).
Nosso alvo (design) é evitar ao máximo retrabalho do time de desenvolvimento por erro de design, e tb manter o time de desenvolvimento totalmente “aware” dos desafios nos próximos sprints, pra que a arquitetura seja + precisa possível.
No meio disso tudo, sem perturbar o time de dev, ainda fazemos as pesquisas (parceiros, universidades, empresas especializadas) – testes (lab interno) – e o que + for necessário para uma UX esperada no final.
A gente anda discutindo bastante o assunto e acho que vou escrever de forma mais detalhada nosso processo no meu blog pra adicionar a discussão!
grande abraço!
Marcelo
Subscribe to My RSS Feed
Luiz Faias Jr on January 14th, 2009
Fala Antônio,
Quando você disse “…quando tentamos fazer muitas coisas ao mesmo tempo, geralmente não fazemos nada com profundidade…”
Me lembrei da história do pato do Comandante Rolim Amaro (TAM): “A grande invenção polivalente de Deus foi o pato. Ele anda, nada e voa. E faz tudo isso mal.”
Ótimo post. Parabéns.