Skip to Content.
Sympa Menu

aifia-pt - Re: [AI] Arquitetos ágeis =)

aifia-pt AT lists.ibiblio.org

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

List archive

Chronological Thread  
  • From: "Karine Drumond" <karinedrumond AT gmail.com>
  • To: aifia-pt AT lists.ibiblio.org
  • Subject: Re: [AI] Arquitetos ágeis =)
  • Date: Mon, 20 Oct 2008 10:51:57 -0200



Sobre prototipos e rascunhos em papel: o segundo eh 100% benefico num
ambiente agile, jah o primeiro, sinceramente, eh perda de tempo. O que
voce gasta preparando um prototipo para testar/apresentar aos usuarios
eh 50% ou mais do que voce gastaria para desenvolver a versao inicial
da funcionalidade.

Mesmo em testes de usabilidade e pesquisa com usuários é possível adaptar, e ser ágil > não esperando que o protótipo esteje "impecável" é possível testar em papel , até com rascunhos, o importante é entregar na mão do usuário o mais cedo possível. A vantagem é que é tão rapido, (testar em papel) e já da para prever tanta coisa (principalmente interface para web) que pode ser feito antes mesmo de desenvolver a versão inicial da funcionalidade. O importante nesse caso é preocupar menos em gerar relatórios e mais em implementar os resultados descobertos. Mas concordo que se o desenvolvimento é ágil , já da para fazer a versão e já entregar na mão de um usuário... O problema é quando o desenvolvimento não é ágil e gasta-se muito tempo com código e só vai validar com usuário lá no final do processo.

Na verdade o ponto crítico é "O que construir" é o "Identificar as funcionalidade realmente úteis". "Qual é a real necessidade dos usuários"... O que se controi de coisas inúteis, centrados em necessidades fantasiadas ou centradas na tecnologia x, sem levar em consideração qual a real necessidade... Perde-se muito a essencia no meio do caminho...




Oi Ana,

realmente você tocou no ponto chave. Acho que essa é realmente a questão. Os
métodos ágeis só funcionam em ambientes, organizados e projetados para isso.
A forma como as empresas estão organizadas e estruturadas pode ser um
entrave. Mas será que mesmo assim dá para "importar" alguns bons conceitos
ágeis?

Talvez começando de forma simples, integrando os pequenos grupos que estão
na mesma sala, ou na mesma cidade. Por ex, envolvendo designers e
desenvolvedores nas idéias e soluções dos arquitetos e vice-versa? Ou
comunicando as descobertas dos testes com usuários aos desenvolvedores e
designer gráficos em reuniões rápidas... Ou rascunhando e prototipando
juntos... Não sei, mas tem que haver algum jeito.. hehe

Olhem esse artigo sobre métodos ágeis em Ux:
http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html




> Oi pessoal,
> Meus dois centavos :)
> Achei legal o ponto da Karine sobre o excesso de documentação que acaba por
> tornar o processo de AI mais demorado.
> Infelizmente, em algumas empresas, a documentação detalhada é o único jeito
> de fazer com que as definições da AI não se percam durante a construção da
> interface / aplicação. Já aconteceu comigo dezenas de vezes: sempre que
> deixo de lado as especificações mais detalhadas (principalmente por causa
> dos prazos), as funcionalidades acabam não funcionando como eu tinha
> idealizado.
> O problema, a meu ver, é a forma como os projetos são vistos pelas
> empresas.
> Quando estou fazendo wireframes de uma interface, o designer gráfico já
> está
> desenhando as telas de um projeto que fiz semana passada, e o desenvolvedor
> HTML já está em outro projeto. Esse esquema "em cascata" dificulta a
> comunicação entre os membros da equipe.
> Infelizmente, os processos ágeis, que possivelmente resolveriam estes
> problemas, são difíceis de serem aplicados em todas as situações. Eu, por
> exemplo, faço parte de uma equipe que está distribuída em duas cidades. É
> praticamente impossível que a comunicação entre os membros da equipe seja
> tão fluída como em  organizações onde todos estão na mesma sala, pelo menos
> na minha opinião. O que vocês acham?
>
> Grande abraço a todos :)
>
>
--
Karine Drumond
Latitude14 | pesquisa + design centrado no usuário
www.latitude14.com.br
(31) 3542-9991
(31) 9132-8406
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.ibiblio.org/pipermail/aifia-pt/attachments/20081017/da21de81/attachment-0001.htm

------------------------------

Message: 3
Date: Fri, 17 Oct 2008 14:25:22 -0400
From: Ricardo Grzeca <grzeca AT hotmail.com>
Subject: Re: [AI] Arquitetos ágeis =)
To: Arquitetura da Informação (em Português)
       <aifia-pt AT lists.ibiblio.org>
Message-ID: <BAY112-DAV14F92098129F8C1E037D6C7320 AT phx.gbl>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Minha experiencia com trabalho a distancia sempre foi positiva.
Jah trabalhei de Porto Alegre para Chicago, Sao Paulo para Porto
Alegre, Dubai, NY, Seattle, Mexico, Madrid e atualmente trabalho de NY
para NY e Madrid.
Tudo eh uma questao de como o gerente do projeto aborda a comunicacao.
Sempre tentamos estabelecer uma reuniao diaria onde todos apresentam o
q fizeram no dia anterior e no minimo 3 atividades que serao
concluidas no dia atual.

Quanto a documentacao excessiva, essa eh uma caracteristica de varias
consultorias onde se cobra por Kilo de relatorio e nao pela qualidade
do que se estah entregando :) e esse eh um dos pontos cruciais de
agile: qualidade do produto em detrimento de excesso de documentacao
( que nao vai ser lida por ninguem no fim das contas e soh serve pro
shamestorming)

Sobre prototipos e rascunhos em papel: o segundo eh 100% benefico num
ambiente agile, jah o primeiro, sinceramente, eh perda de tempo. O que
voce gasta preparando um prototipo para testar/apresentar aos usuarios
eh 50% ou mais do que voce gastaria para desenvolver a versao inicial
da funcionalidade.

Uma questao que ainda nao foi abordada eh a de que nem todos os
projetos serao beneficiados por agile e nem todas as empresas estao
preparadas para cobrar por agile.
Nao eh apenas uma metodologia de desenvolvimento, agile tem impacto no
modelo de negocios.
A maioria das consultorias e agencias trabalha por empreitada,
fechando um valor para produzir uma determinada solucao para uma certa
demanda/problema e acaba nao sabendo como cobrar por um projeto que
utilize agile ou como vender a metodologia sem apresentar um orcamento
fixo. Eh muito facil voce perder o rumo em um projeto agile com budget
limitado se voce nao souber o que estah fazendo.
Jah uma empresa com um nucleo de P&D ou focada em inovacao, um portal
como a globo.com, ou uma fabrica de software se beneficiariam
imensamente da metodologia assim como seus clientes/stakeholders.

R



> 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.

Márcia, apenas alinhando sobre o SCRUM, o GP tradicional se assemelha
mais ao ScruMaster, responsável por resolver os impedimentos e cuidar
para que o time execute as tarefas durante o sprint. O product owner
seria o "cliente",  e é literalmente o dono do produto.

O tópico está interessantíssimo.... e resumindo: quanto mais iteração
com usuário, melhor o resultado final!
Sempre reforço aqui no trabalho que "metodologia ágil" não prega
ausência de documentação, e sim documentação SUFICIENTE.... em certos
momentos, kilos de documentação serão necessários ;-), em outros, até
o wireframe pode ser descartado.

[]s




--
Marcelo Linhares
Pessoal -> marcelolinhares.com
Procurando vagas em TI ? http://www.vagasem.info






--
Karine Drumond
Latitude14 | pesquisa + design centrado no usuário
www.latitude14.com.br
(31) 3542-9991
(31) 9132-8406



Archive powered by MHonArc 2.6.24.

Top of Page