Em 1908, Henry Ford revolucionou a maneira de construir coisas com seu Modelo T. A linha de montagem reorganizou a produção para que mais carros fossem feitos simultaneamente, distribuindo as várias etapas da fabricação de um automóvel ao longo de uma esteira rolante. Os profissionais deveriam ser especialistas naquele pequeno ofício de apertar um parafuso dentro do processo inteiro.
Em 2006 me peguei usando um processo muito parecido com o de Ford para construir um website. O analista de produto fez um briefing, o arquiteto da informação estruturou os mapas de arquitetura, o designer de interface projetou os wireframes e depois os layouts, o pessoal do desenvolvimento client implementou um html, e os desenvolvedores inseriram a inteligência do sistema que fora prevista pela descrição funcional. Uma linha de montagem clássica.
Não bastasse o simples fato de usarmos um processo de cem anos atrás, ainda encontramos alguns problemas típicos dos tempos atuais: os profissionais envolvidos com o desenvolvimento de um site trazem os mais variados backgrounds e portanto falam línguas diferentes; a indústria da internet evolui e muda de direção em alta velocidade, o que faz com que o retrabalho seja uma constante. E, por fim, trabalhamos com algo menos tangível e com mais especificidades que um carro. Um software de online banking é totalmente diferente do site de um fotógrafo, por exemplo.
A rigidez do processo tolia a inovação. Os caras de criação entregavam um pacote fechado de idéias para os desenvolvedores. Havia pouca colaboração entre as áreas e nem todos tinham o mesmo sentido de paternidade do projeto. Tudo isso desaguava numa dinâmica patológica ao produto final, onde as funcionalidades eram concebidas muitas vezes prematuramente e aos desenvolvedores só restava tentar proteger os prazos e diminuir o escopo.
Processo colaborativo
Pesquisamos algumas metodologias menos rígidas e esbarramos no Extreme Programming (XP), um processo de desenvolvimento de software que prioriza a adaptabilidade em detrimento da previsibilidade. Em linhas gerais, o XP entende que mudanças são uma característica da indústria, não uma falha de projeto. Além da absorção das mudanças, outros conceitos importantes aprendidos foram: o mínimo de documentação e o máximo de comunicação entre os atores do processo; utilização das idéias mais simples, que aumentam em complexidade em releases evolutivos e trabalhar com feedbacks constantes do usuário e da equipe via protótipos, testes de usabilidade e iterações entre os participantes do projeto.
Testamos a nova metodologia (inspirada em XP, mas sem sua aplicação na íntegra) no novo projeto do núcleo de aplicativos da Globo.com, um site de mídia social baseado em fotos, que se chamaria 8P.
Sabíamos que o processo mais rígido, ao qual já estávamos habituados, nos daria maiores garantias em termos de prazo e infalibilidade do sistema, mas a diretoria estava disposta a arcar com os riscos em nome do aprendizado que favoreceria a inovação.
As funcionalidades seriam destrinchadas na sua menor unidade possível, e discutidas entre todos os envolvidos desde o primeiro momento aposentando os grandes pacotes de entregas, onde um recurso passava a bola para outro e lavava as mãos.
Documentação
A documentação seria feita quase integralmente numa ferramenta de wiki, onde arquiteto, analista de requisitos, desenvolvedor e designer construiam coletivamente cada funcionalidade do produto. A idéia podia vir de qualquer um dos envolvidos e a colaboração era tanta que, em nome dos prazos, muitas vezes tínhamos que trazer de volta um pouco do sentido de propriedade documental em cada uma das etapas. Era preciso evitar que alguém confundisse colaboração com democracia. Se cada decisão fosse discutida e votada estaríamos em loop até agora.
O caráter evolutivo do processo nos encorajou a tentar um novo formato de documentação. O arquiteto funcional passou a escrever uma espécie de pré-caso-de-uso, que seria complementado pelo arquiteto de sistemas. Antes, o primeiro escrevia uma especificação funcional que era re-escrita pelo segundo para chegar ao formato caso-de-uso. Isso tomava tempo e gerava documentação excessiva.
Pessoal integrado
A atitude dos recursos do projeto também mudou. O fato de todos trabalharem com proximidade física quebrou o gelo entre as equipes, facilitou a comunicação e eliminou o efeito ?eles e nós?. Os ?criativos? não tinham mais a pretensão de especificar o mundo em duas semanas e os desenvolvedores não se sentiam mais preteridos no processo.
A interface de excluir foto, por exemplo, foi projetada e prototipada algumas vezes antes de chegarmos a uma solução final, proposta pelo programador. O designer Thadeu Morgado, por sua vez, acampou algumas vezes na baia do desenvolvedor do mecanismo de personalização de página, flexibilizando sua idéia pelo que era mais factível. Também não era raro pedir feedback de funcionários da Globo.com que não tinham nada a ver com o projeto. Promovíamos testes de usabilidade relâmpago toda vez que tínhamos dúvida sobre o funcionamento de algum mecanismo.
As novidades do processo acabaram repercutindo no produto final, que conta com um blog onde a equipe de desenvolvimento adianta melhorias, conta detalhes e recebe feedback do usuário do 8P. Conseguimos mobilizar a comunidade para que ela contribua ativamente com o processo, reportando bugs e sugerindo melhorias. Outro aspecto facilmente notado é que o design do produto final é focado na maneira como o usuário se relaciona com o sistema, não num branding de afrescos visuais. A personalidade do produto vem dos mecanismos de interface.
No balanço final ficamos com um processo que precisa de muitos ajustes, mas indica um caminho na metodologia de como criar um software. Assim como o produto projetado, o método de desenvolvimento também deve ser vivo, com aperfeiçoamentos constantes. [Webinsider]
………………………………………….
Alguns links para você conhecer o 8P:
A homedo produto
Blog da equipe do projeto
O espaço de Gluz no 8P
Grupo Que filme é esse?
Grupo Obina Facts
.
16 respostas
Estou fazendo uma pesquisa sobre empresas que utilizam o método XP. Gostei do artigo me ajudou, mas gostaria de saber mais alguns detalhes. Quais as praticas do XP que utilizaram?
Obrigado
de 1974 a 1982 desenvolvi surf com motor e em 1982 em Ubatuba sp testei em alto mar,(esse é meu diploma)tenho projetos voltados ao futuro,carro que ainda não existem,os veiculos sofrerão poucas auterações ao longo deste tempo,poluem muito,pesados,muito ferro velho ambulante,o veiculo do futuro,mais conpacto,mais alto,mais leve,tudo se transforma conforme a necessidade do evento,pois o veiculo a função é de servir ao seu condutor,melhorar suspensão e outros,o peso pode chegar a metade do sepo atual,o veiculo sendo mais alto e compacto,esta na hora de mudar esta carroça.telefone 019 35338941
Parabéns pelo artigo. Porém, gostaria de passar maiores informações ao pessoal de tecnologia da empresa. Alguém indica um blog ou tutorial.
bjs, paty
Ferrou estou atás, bateu o desepero, trabalho a mais de 8 anos na rede e parece que não aprendi nada.
XP o que é isso?
Preciso correr!
Sei que é mais um método teorico, fazer o quê existem milhões deles…
Parabéns pelo projeto equipe 8P.
Vinícius, Danilo, Saulo e Fernando. Muito obrigado pelas colaborações! Isso é inteligência coletiva na veia!
Maurício, a idéia central é compartilhar a experiência de criar o 8P com uma metodologia que era nova para mim e para a minha empresa. Não poderia ter ?metodologias ágeis? como idéia central, por não ser um especialista no assunto e por nunca ter testado nenhuma delas de modo integral.
André, sou um admirador dos caras da 37 signals e leitor no Signal Vs. Noise. Gostei muito do livro ?Getting Real? e ele certamente influenciou meu pensamento sobre design e desenvolvimento de software.
Entretanto nós optamos por uma metodologia que usa conceitos adquiridos em várias fontes e na nossa própria experiência anterior na Globo.com. Não é muito fácil distingüir em cada uma desses conceitos o que dá certo e o que não dá porque o sucesso depende dos mais diversos fatores como tipo de aplicação, cultura da empresa, tolerância com atraso e erro, background da equipe e muitos outros. Metologia não deve ser encarada como receita de bolo.
Gostaria de saber se o livro Getting Real escrito pelo pessoal da 37signals também foi usado como referência no desenvolvimento desse projeto. Ele aborda vários dos conceitos comentados. Caso afirmativo você poderia comentar o que o livro mostra que realmente funciona e quais os maiores problemas encontrados.
Parabêns, o 8P é um excelente aplicativo.
[]s
André
Oi Marcelo! Show de bola o texto! Parabéns pela equipe por compartilhar esse tipo de informação.
Como alternativa ao XP, temos também o Agile (http://agilemanifesto.org/). Não há de se esquecer que esses processos normalmente são orientados ao cliente (principal stakeholder), e precisam ser adaptados para orientação prioritária ao usuário (no caso dos nossos projetos web). Abração, tudo de bom =)!
Olá Marcelo,
Muito bacana seu relato de uma experiência de utilização da XP em um projeto sistema para um portal Web. Isso demonstra a flexibilidade da metodologia além da possibilidade de integração de pessoas de áreas tão diferentes (designer, programador, analista de negócio, e vários outros) como é o caso do desenvolvimento Web.
Tenho utilizado as práticas do XP há 2 anos e realmente é bastante dificil mostrar os resultados no curto prazo, porém a diminuição REAL do re-trabalho que mostra os benefícios no longo prazo.
[]s e parabéns!
Saulo Arruda
http://sauloarruda.eti.br
Marcelo,
Parabéns pelo depoimento. Sou de São Paulo e também adepto dos métodos ágeis e, principalmente, de XP. É sempre bom ouvir que tem mais gente aproveitando as vantagens de um método ágil e trocando burocracia por comunicação, interação e adaptação.
Para quem tiver interesse em mais material sobre o tema, mantenho um blog:
http://www.dtsato.com
e sou membro da AgilCoop, que contém bastante material sobre XP (inclusive um podcast) no portal:
http://agilcoop.incubadora.fapesp.br
Mais uma vez parabéns!
Abs,
Danilo
Marcelo,
Um detalhe adicional que esqueci de mencionar. Você comentou sobre a linha de montagem do Henry Ford. XP é diferente exatamente porque não se baseia nos conceitos da Ford, mas sim em algo criado 50 anos depois, no Japão, chamado Just-in-Time.
Just-in-Time é o nome pelo qual é conhecido o Sistema de Produção da Toyota, caracterizado por qualidade imbatível e custos extremamente competitivos. Usando o Just-in-Time, a Toyota revolucionou a indústria automobilística e está se tornando rapidamente a maior montadora do mundo, além de ser consistentemente a mais lucrativa há muito tempo. Veja:
http://pt.wikipedia.org/wiki/Sistema_Toyota_de_Produção
Todas as práticas do XP são fortemente baseadas nos princípios do Just-in-Time. Por isso são tão produtivas e ajudam a desenvolver software com maior qualidade e velocidade. Por outro lado, da mesma forma que Just-in-Time causou controvérsia há algumas décadas, quando foi introduzida no ocidente, várias práticas do XP também são consideradas controversas por aqueles que estão habituados com metodologias tradicionais de desenvolvimento. Mais detalhes sobre essa questão podem ser obtidos no capítulo 4 do PDF abaixo:
http://www.improveit.com.br/xp/dissertacaoXP.pdf
Abraços,
Vinícius Teles
Marcelo,
Parabéns pelo depoimento e obrigado por compartilhar a experiência de vocês no desenvolvimento do site 8P. Fico feliz que a opção pelo XP tenha sido benéfica para o projeto.
Trabalho com XP desde 2002, executando projetos e ajudando organizações em todo o Brasil a utilizarem essa metodologia. Esse tem sido um trabalho gratificando e me alegra que outras equipes também estejam se beneficiando desse modelo de desenvolvimento.
Gostaria de agradecer ao Maurício pela indicação do meu livro. Para quem quer aprender XP, outra fonte de informações é o link abaixo:
http://www.improveit.com.br/xp
Lá existem várias informações que estão no meu livro de XP e outras que estão sendo atualizadas diariamente, à medida que escrevo um novo livro sobre o assunto. É um bom ponto de partida e, o que é melhor, não custa nada! 🙂
Outra dica é o Grupo XP Rio, fundado há quatro anos. Trata-se de um grupo de pessoas interessadas em Extreme Programming, que trocam informações na internet e se reúnem mensalmente para troca de experiências. É o maior e mais antigo grupo de XP do Brasil e um dos maiores do mundo. Conta com 600 participantes e as reuniões tratam não apenas de assuntos da metodologia, mas também de temas atuais, como o uso do Ruby on Rails, que foi tratado na reunião da última terça-feira, no centro do Rio (com o desenvolvimento de uma aplicação ao vivo). Para ingressar no grupo, basta acessar:
http://tech.groups.yahoo.com/group/xprio
Existe uma palestra gratuita sobre XP que é oferecida desde 2002 para organizações interessadas em aprender mais sobre a metodologia. Ela já foi ministrada inclusive na própria Globo.com. As informações podem ser obtidas em:
http://www.improveit.com.br/palestra
Extreme Programming, como se pode observar pelo depoimento do Marcelo, é uma forma de desenvolver software humana, social, produtiva e, acima de tudo, divertida!
Mais uma vez, parabéns Marcelo! E dê os parabéns também a todo o restante da equipe do site 8P.
Grande abraço,
Vinícius Teles
Para quem quiser começar em XP, há um excelente livro nacional sobre o assunto: http://www.improveit.com.br/livroxp
Pena que no artigo só há referências para o 8p, e não para o assunto central… metodologias ágeis. De qualquer forma, parabéns à equipe!
abs,
Filipe,
Existem livros sobre XP, e uma boa introdução sobre o assunto você encontra em
http://www.extremeprogramming.org .
Eric e Diogo,
Aqui no nosso núcleo nós optamos por uma metodologia que utiliza alguns princípios do XP, mas não todos. Entendemos que, pelas características da empresa, seria melhor assim. Sobre os custos, os pregadores do XP alegam que, por evitar retrabalhos, esse método acaba sendo menos custoso. Não posso afirmar isso, por não ter experiência de trabalho com o XP puro.
Onde posso encontrar algum material q fale mais sobre XP?
Como conhecer melhor essa metodologia?
Legal utilizarem uma metodologia baseada no XP. A maior dificuldade é a aceitação da empresa , pois aparentemente é uma metodologia mais custosa.
Mas a médio-longo prazo, se bem implementada, gera resultados excelentes.
Acho muito válida a idéia de compartilhar com a comunidade a forma de trabalho desse projeto.
É uma troca justa (quase inconsciente):
Conhecimento compartilhado x Simpatia pelo projeto 8P.
Boa sorte,
Diogo Lopes
Marcelo, muito boa a iniciativa de divulgar o método de trabalho dessa equipe. Melhor mesmo trabalhar com menos documentação e mais interação, pena que muitas empresas ainda não acordaram para isso e espero que fiquem atentas ao exemplo da Globo.com. Ainda mais interessante é que o wiki tornou o próprio aplicativo mais aberto a sugestões do usuário. Parabéns!