(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

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!

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.

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.

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

abs,

Antonio

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.