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.
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
Archive powered by MHonArc 2.6.24.