Arquitetura da Informação (em Português)

[Marcia Lunardi <lunardi AT pobox.com>]

Adotar metodologias de desenvolvimento ágil exige a quebra de uma série de paradigmas e nesse contexto o AI tem que se reinventar. Simplesmente porque as etapas que antes eram desenvolvidas de forma seriada têm que ser feitas junto com o desenvolvimento. Esse assunto tem muito a ser discutido. Inclusive uma questão seria como nós AIs poderíamos contribuir mais nesse tipo de ambiente.

 

Estamos trabalhando com SCRUM há poucos meses e o AI, talvez por ser a minoria, em uma série de times é o profissional que tem tido maior dificuldade de se integrar.

 

Muitas vezes documentos tradicionais são substituídos por sketches feitos em um quadro. Funcionam muito bem e são fáceis de ser alterados e visualizados por todos. No entanto, algumas versões simplesmente ficam ser registro documental o que não tem se mostrado um problema.

 

No SCRUM o GP é chamado de Project Owner, e cada equipe tem um PO exclusivo. É ele que aprova as entregas e deve estar bastante presente.

 

Quanto aos testes temos nos deparado com situação similar a narrada pelo Ricardo.

 

Estarei apresentando um artigo no EBAI e o co-autor desse artigo, José Muanis, trabalha na Globo.com como Scrum Master de um time já há um certo tempo. Ele tem uma experiência prática enorme e pode contribuir bastante com a visão de um desenvolvedor sobre os designers e os AI.

 

Me comprometo a consolidar os principais aspectos abordados sobre esse assunto no congresso para compartilhar com vocês. Esse é um tópico bastante rico!

 

Abs,

 

Márcia Lunardi, M.Sc.
Arquiteta de Informação e Designer

+55 21 3545-0113

marcialunardi AT yahoo.com.br

 

 

--- Em qui, 16/10/08, Ricardo Grzeca <grzeca AT hotmail.com> escreveu:

De: Ricardo Grzeca <grzeca AT hotmail.com>
Assunto: Re: [AI] Arquitetos ágeis =)
Para: "Arquitetura da Informação (em Português)" <aifia-pt AT lists.ibiblio.org>
Data: Quinta-feira, 16 de Outubro de 2008, 13:29

Excelente topico!

Em projetos que utilizam metodologias agile existem dois momentos  
distintos em que AI/UX acontecem:
Durante a etapa inicial do projeto, em que se estah planejando os  
recursos a serem desenvolvidos.
Nessa etapa a dinamica e documentacao gerada sao bastante similares a  
dos projetos convencionais.
- content assessment
- user profiles
- use case scenarios
- interaction flows
- wireframes
- etc.
Jah durante o desenvolvimento do projeto tem se demonstrado, na minha  
experiencia (~2 anos trabalhando com agile), uma boa pratica:
- semana 1
    - planejar o recurso
    - documentar
	- atualizar wireframes
	- produzir novos fluxos
- semana 2
    - producao/desenvolvimento
Com isso o designer tem tempo de planejar o funcionamento do proximo  
recurso enquanto o time de desenvolvimento/criacao/producao estah  
envolvido na producao do recurso anterior.

E importante destacar que agile demanda uma participacao efetiva do  
gerente de projeto. Em metodologias tradicionais vemos o GP como  
alguem que atualiza o cronograma e eventualmente negocia com o gerente  
da equipe (desenv ou criacao) os prazos, gerencia a ansiedade do  
cliente e nao mto mais que isso. Esse GP tambem costuma trabalhar com  
6 ou 7 projetos ao mesmo tempo.
Num ambiente agile ele precisa estar muito mais envolvido, definindo  
os recursos a serem desenvolvidos, e acompanhando de perto a producao  
dos assets necessarios, de outra forma a agenda de releases ficara  
comprometida.

Sobre adaptar os metodos ou nao, a maior diferenca entre trabalhar num  
ambiente convencional e num ambiente agile eh o dialogo constante.  
Simplesmente nao eh viavel que voce fique 3 dias produzindo um  
wireframe/site map/flow e o apresente, aprove e envie para as outras  
equipes. E necessaria uma negociacao constante, diaria, entre os  
envolvidos.
Eu costumo organizar minha semana da seguinte forma:
Segunda - planejamento geral dos recursos - reuniao com o GP para  
discutir as ideias surgidas
Terca e Quarta - documentacao - reuniao para discutir os documentos  
com o GP - normalmente uma troca de emails e uma conversa no jabber  
sao suficientes
Quinta
	- revisao do trabalho realizado durante a semana
	- revisao do que foi produzido pelas outras equipes - uma especie de QA
Sexta - dia de release
	- mais testes
	- debrief - apresentacao para as outras equipes, dos recursos a serem  
desenvolvidos na proxima semana
	- brief - planejamento dos proximos recursos com o gerente de projeto/ 
produto
	- cerveja

E os testes com usuarios, como ficam?
Sinceramente, num ambiente agile nao faz muito sentido voce planejar e  
executar testes por varios motivos
- todo o processo demora muito tempo
- as funcionalidades adicionadas aos releases sao sempre pequenas
- voce consegue coletar feedback dos usuarios reais, em situacoes  
reais atraves de:
	- formulario - sim, as pessoas compartilham suas opinioes
	- analise de logs - feitas em conjunto com o gerente de produto/projeto
	- ferramentas para analisar zonas de calor da pagina

meus $0.50

R


. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial 
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt 
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt

---

Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.