MasterTags:
1 sprint a frente é mini waterfall
Postado por
Everton J. Carpes
em
01/02/2010 02:21
Blog: MyWay
Karmômetro (?)
bom e polêmico
Cada vez mais em times Agile (principalmente Scrum), tem se seguido a pratica de um ou mais times que tem como foco trabalho “front end” serem alocados no que vem sendo chamado de “um sprint a frente” (“one sprint ahead”). A principal argumentação é manter uma integridade maior da experiencia de usuário que ó pode ser alcançada dando-se aos designers tempo de antever o que esta no backlog e tomar decisões a respeito, preparando o campo para quem for desenvolver as features em questao.
Exemplos fortes desta opinião podem ser observados em vários dos casos apontados no artigo Agile Usability: Best Practices for User Experience on Agile Development Projects da Nielsen Norman Group.
Particularmente considero a principal argumentação desta pratica uma falacia, claramente vinculável com o pensamento tipico dos times waterfall. A justificativa é exatamente a mesma, uma determinada função responsável por parte do trabalho criativo considera que para manter um conceito único e apropriado de seu trabalho, é necessário que se pense (pouco ou muito) antes de executar. A pratica vem sendo engolida justamente porque como é “apenas” um sprint, o impacto parece minimizado, mas na verdade o impacto é absolutamente o mesmo: um time começa a determinar como as coisas serão, com base em teorias soltas que refletem muito pouco das capacidades da empresa em responder ao que se espera, alem disso, esta pratica vai em detrimento da propriedade geral sobre o projeto, inibindo os membros dos demais times a fazer qualquer critica que pode ser pertinente, pois a pratica dá ao primeiro time uma propriedade maior sobre as escolhas.
Esta pratica acaba por coibir a melhor participação dos demais membros do time e é evidente que certas decisões tomadas pelo time de designers tendem a fugir da realidade e da capacidade dos desenvolvedores.
Dudu Pontes (que é Product Owner na Globo.com), aponta ainda a possibilidade sempre presente do projeto ser congelado ou concluído, ou mesmo ocorrer uma mudança drástica nas prioridades e conseqüentemente no backlog, o que invalidaria ou inutilizaria o trabalho previamente realizado pelos membros do time de UX.
Um time agile precisa estar preparado para responder a mudanças no ambiente… Concorrentes lançam produtos novos, o interesse do cliente diminui ou os objetivos dos Stakeholders precisam ser alterados. Qualquer mudança deste tipo tende a alterar os rumos seguidos pelo time e um time agile abraça este tipo de mudança. No caso de times onde praticas de trabalho de “planejamento” acontecendo em paralelo ao trabalho de desenvolvimento, o trabalho feito “a frente” é perdido em qualquer mudança de rumos.
A argumentação de que um time precisa de trabalho de planejamento de UX de antemão ao trabalho de desenvolvimento é uma prova forte da má compreensão da proposta agile e dos valores a serem considerados. Empresas que consideram esta pratica normal, provavelmente não acreditam realmente na premissa de que é mais importante software rodando e interações entre indivíduos sobre qualquer processo.
Desenvolvedores que defendem waterfall alegam exatamente a mesma coisa, que precisam de planejamento “up front” para manter uma arquitetura apropriada. Este tipo de argumento é uma falacia, nada garante que o tempo gasto vá gerar uma arquitetura mais solida e a experiencia tem mostrado que é exatamente o oposto, o que é gerado é um sistema com varias features inúteis e que não responde a expectativa do publico/cliente. O fato de que o trabalho em questão esta “apenas” um sprint a frente é apenas um detalhe, poderíamos dizer que neste caso não é bem um waterfaal e talvez seja um mini-waterfall (com quase nenhuma vantagem que o watterfall poderia trazer e com vários problemas novos).
Times comprometidos em entender os problemas do cliente e a realidade do mercado, se envolvem com o processo e ajudam a construir uma visão clara do projeto. Para facilitar este tipo de situação, alguns times abraçam praticas como Metáforas da XP, de forma a ter alguma abstração que permita verificar desvios no projeto geral, mas mesmo sem este tipo de pratica, a maioria consegue obter bons resultados dependendo exclusivamente do que se pretende e da transparência e sinceridade dos envolvidos. Em um time ágil que esta realmente comprometido, as demandas de UX são incorporadas como praticas do dia a dia e critérios de aceitação, manter o nível esperado para a UX torna-se parte da avaliação de qualidade do time.
Qualquer esforço de deslocar membros dos times para trabalhos paralelos é altamente nocivo. Pouco interessa se os envolvidos são desenvolvedores, designers, gerentes ou o que for, todos precisam estar envolvidos diretamente com o que se pretende entregar. As decisões, sejam elas de origem gerencial ou criativa, devem ser tomadas junto com os envolvidos de forma que todos possam entender os efeitos e intervir com observações que possam ser pertinentes. Qualquer coisa diferente disso ainda é o mesmo que sempre tivemos, projetos sendo administrados por profissionais que acham que tem a capacidade de prever o futuro, que supõe que seu trabalho é mais importante que o dos demais e que normalmente conhecem muito pouco do dia a dia da criação e desenvolvimento agindo sempre por traz de praticas e processos que lhes defendem da responsabilidade que lhes deveria ser legada.
Se você gostou,
seja um GEEK!
Comentários
Postar um novo comentário
voltar ao início
Karmômetro (?)
polêmicoBastante pertinente o seu post. Pode parecer estranho, mas a bola de cristal ainda é um instrumento bastante utilizado hoje em dia. Também se percebe a não adequação de certos “setores” ao conceito de equipe, buscando qualificadoes que os diferencie entre os demais.
Postado por Alessandro Martins em 01/02/2010 10:32
Karmômetro (?)
lixo totalgosto de fazer amigos novos todos dias namorar ler apreder coisas novas
Postado por amplo em 01/02/2010 14:07
Karmômetro (?)
tende a neutroEverton
Esse seu texto me deixou algumas dúvidas
Você diz que no texto que a motivação pro “spring a frente” seria que: “um time precisa de trabalho de planejamento de UX de antemão ao trabalho de desenvolvimento”
Eu sinceramente acredito nisso porém esse (como você mesmo disse) não é motivo pra ter uma equipe trabalhando numa backlog à frente… É sim um sintoma de que o time INTEIRO tem problemas para realizar as atividades de avaliação de interação com o usuário como atividades do cotidiano.
Porém vale salientar que algumas atividades de UX são realmente “waterfall style”
Ex:
A Criação de “Personas” não pode ser postergada tem que ser uma das atividades iniciais do sistema inteiro ou pelo menos de cada novo modulo implementado em que aparecerem novos perfis de usuário.
Eu sei que soa estranho mas é verdade, pra contornar esse problema é que existe a prototipação descartável: Técnica que é extremamente eficiente e altamente sensível a mudanças nos requisitos que na minha opinião são a razão de termos springs e pequenas entregas (adptar-se rapidamente à mudanças)
1)
Você fala em “time de UX”. Como é possível querer que as atividades de UX “incorporadas como praticas do dia a dia” se você delega apenas a uma equipe todas as questões de interação com o usuário?
2) “decisões… de designers tendem a fugir da realidade e da capacidade dos desenvolvedores”
Será que essas decisões não estão “fugindo a realidade” porque exigem alterações no sistema que poderiam ter sido evitadas caso os desenvolvidores tivessem em mente a necessidade dos usuários finais?? (a comunicação continua com os clientes não é uma característica forte do desenvolvimento ágil?)
Nós desenvolvedores temos que parar de ver interação como trabalho de designer (trabalho de designer é ARTE!!!) temos que usar os designers e engenheiros de interação como líderes técnicos que permeiem nossas decisões técnicas usando o conhecimento deles a favor do usário.
Enquanto essa guerra desenvolvimento x interação continuar quem mais perderá será o usuário final.
Postado por Eduardo em 19/09/2010 15:38
Karmômetro (?)
tende a ruim@Eduardo
creio que eu tenha causado confusao, pois muito do que tu apontou nao eh minha opniao, vou aqui tentar responder a alguns pontos:
“um sintoma de que o time INTEIRO tem problemas para realizar as atividades
de avaliação de interação com o usuário como atividades do cotidiano”
Concordo plenamente contigo, acredito q uma vez incorporadas praticas e valores de UX a todos os membros estas dificuldades desaparecem.
“algumas atividades de UX são realmente “waterfall style” "
O mesmo pode ser argumentado quando se fala de atividades de desenvolvimento. Times que realmente se esforcam a atuar em um projeto incremental conseguem abandonar este tipo de pratica substituindo as mesmas por praticas alternativas. O grande exemplo disso eh a questao de desenho e arquitetura de sistema, que eh substituido com grande valor pela pratica de metaforas no uso da XP por exemplo!
“Criação de “Personas” não pode ser postergada tem que ser uma das atividades iniciais do sistema inteiro”
Aqui temos uma confusao visivel: o objetivo do meu post nao eh questionar a necessidade de praticas previas ao trabalho como um todo, estas daih sao praticas que cabem muito bem em Discoverys sobre o produto e se for preciso em trabalhos previos como o tipico “Sprint Zero”.
Minha critica eh especificamente sobre times trabalhando a frente dos demais.
“Você fala em “time de UX””
Time UX nao se refere a um time de pessoas que trabalham como uma equipe somente atuando em UX, eh uma denominacao que eu dei a todos os profissionais de uma empresa que atuem com atividades relacionadas, independente de pertencerem a equipes mistas.
Eu NAO acredito em times isolados de UX de forma alguma! A denominacao foi usada para referenciar o que eh realidade em muitas empresas, onde apesar das equipes relacionadas com produtos e multidisciplinares, ainda existe um tratamento/organizacao horizontal de profissionais especificamente atuando com atividades de design.
“alterações no sistema que poderiam ter sido evitadas caso os desenvolvidores tivessem em mente a necessidade dos usuários finais”
Em parte sim! Porem acredito tambem que isso ocorra menos em ambientes onde desenvolvedores e designers trabalhem completamente juntos, em equipes onde os designers nao atuem apenas desenhando telas ou prototipos, mas tambem atuem junto dos demais, desenvolvendo algumas das solucoes que propoe, decidindo junto com o time nas horas de planning, etc.
Jah tive ohtimas experiencias nesse sentido e vejo claramente q em equipes onde designers e developers atuam mais proximos, compartilhando os mesmos ambientes praticas e preocupacoes a coisa flui bem melhor e problemas como os apontados raramente emergem.
“temos que usar os designers e engenheiros de interação como líderes técnicos que permeiem nossas decisões técnicas”
Discordo em parte de voce. Designers sao membros dos times, devem atuar junto de cada desenvolvedor e sem nenhuma diferenca em relacao aos mesmos, mas sinceramente tornar-los lideres eh perder grande parte do que obtivemos.
Praticas como planning games nos habilitam a permitir a todos no time, sejam designers, clientes ou o que for, a atuar definindo os rumos para onde cada atividade deve ser direcionada. Isso jah acontece se voce usa este tipo de pratica, nao ha nenhuma necessidade de ter uma forca de maior lideranca.
Eh claro que o designer acaba por responder nao apenas por si, mas tambem pelo usuario e caso o usuario nao tenha outro representante, cada papel especifico de usuario deve ter sua representacao ocupada pelo designer nos jogos de planejamento e isso leva a um aumento da responssabilidade de poder atribuidos aos designers de um time, o que eu acho natural e muito saudavel.
“Enquanto essa guerra desenvolvimento x interação continuar”
Nao deve haver guerra nenhuma, os times precisam passar por uma fusao, onde developers aprendam a entender os elementos e fundamentos que compoe a atividade de designer, e os designers passem a compreender qual o impacto e tamanho das decisoes que ele toma.
Designers isolados em “ilhas”, rabiscando na frente de um editor de photos aquilo que eles querem ver na aplicacao, definitivamente nao eh um caminho. Tu apontou o uso de prototipagem fraca… Acho uma pratica excelente que diminui muito a perda de tempo na conceituacao de determinados projeto, mas por si esta pratica apenas inibe que discucoes improprias sejam levadas a cabo. Designers que atuam diretamente tambem diretamente sobre elementos reais como marcacao e estilo, conseguem em geral desenvolver uma capacidade bem maior de avaliar com clareza qual o impacto de cada decisao e mensurar melhor o que deve ou nao ser feito em cada momento de um projeto.
Para varios dos melhores designers que eu conheco, a melhor ferramenta de prototipagem que eles usam eh o firebug!
Certamente concordo que todos os lados precisam aprender muito e que em um mundo ideal, as atividades de cada membro de uma equipe vao se tornando as mesmas, o que se mantem eh apenas a capacidade de critica a cada aspecto e valor.
Postado por Everton J. Carpes em 21/09/2010 18:17
Karmômetro (?)
tende a neutroEu realmente tinha ficado confuso… esse feedback rápido é ótimo!!
Tirei muitas das minhas dúvidas…
Parabéns pelo post!
Postado por Eduardo em 21/09/2010 19:18