Começou assim ...
Em nosso Sprint Planing, nosso 'PÔ' Rodrigo Pestana nos apresentou um email de um amigo dele na Europa informando que lá muitas empresas estão fugindo do Java e dando exclusividade para projetar sistemas usando PHP, Phyton, entre outros. E isto principalmente devido ao vasto e diferenciado número de frameworks existentes; e consequentemente os prováveis problemas que isto poderia estar causando no processo de arquitetura de softwares.
De fato, se fossemos contar a quantidade de frameworks disponíveis, que tem uso para funcionalidades semelhantes; poderiamos ficar muito confusos. Outro dia mesmo, entrei em um tópico em um JavaUserGroup brasileiro, e o resumo da história é que eu fiquei uns 3 dias em depressão por causa de tantas tecnologias que iam surgindo em comentários dos usuários. Cada um citava em média 5 tecnologias. O total de tecnologias únicas no tópico já deve estar passando de 70.
Então. Teria razão, o amigo do nosso P*** Orêia ?
No meu ponto de vista não. O número excessivo de frameworks, no meu pensamento, só nos traz benefícios. É o que estávamos conversando eu e Franzão outro dia (voltando do único restaurante que os 3º's tem 'beneficio' maior). Uma grande parte de frameworks já tem espaço no mercado e são tomados como padrão na hora de tocar um projeto em Java. Por exemplo: Struts, Spring, Hibernate, JUnit. Quem nunca ouviu falar deles ? Com eles temos tudo que precisamos para adotar o MVC no sistema. E realmente são eles que são utilizados na maioria das vezes.
Ok, não seria contraditório dizer que vários frameworks é bom, mas que poucos são tomados como padrão ? Hummm ... não ! Sabe porque ? Tudo no mundo evolui, e pra mim as pessoas que trabalham com Java podem esperar algum framework ter AQUELE destaque significativo nas comunidades pra aí sim pensar em ler algo à respeito dele. Poucos são os aventureiros que tem tempo de usar um framework, no qual ele tem pouco conhecimento, e que pouca gente usa. O que isso geraria ? Suponhamos que um dia ele precise tirar um dúvida (daquelas bem besta) sobre esse framework. Iria encontrar pouco conteúdo. Diferente dos que optam por usar os frameworks que já são praticamente API's disseminadas por 'desbravadores de frameworks' ou que por um
motivo ou outro tem bastante adeptos e conteúdo disponibilizado pra consulta.
Finalizando com tudo o que me veio na cabeça sobre frameworks, queria mostrar mais duas coisas que ví esta semana, que fizeram minha cabeça agir no estilo 'tranca,solta' (by CQC) auheaueahuae
1:
A notícia que a SUN e o Google tem dado apoio ao Phyton. fontes: GUJ e InfoQ
Na página inicial do setor de "developers" da SUN, note que dois principais itens de página são sobre o JRuby e sobre a então novidade: "Want some Phyton in you Java?".
Puts ! Essas notícias foram um p*** de um TRANCA na minha cabeça ! Eu todo feliz, acabei de comprar meu voucher pra fazer a certificação SCJP e me vem uma destas. Que tristeza né ... pensei ...
2:
Não demorou muito, e veio o ... SOLTA ...
kakakakaka Olha aqui europeus otários! O Java destruindo em performance! Que se fo** que a gente tem que escrever o dobro de linhas de códigos ... pois a gente SABE fazer isso!
Abraços !
Desejo muito sucesso pro pessoal que conhecí na CTBC. Sem exceção alguma, aquela fila inteira (dum lado e doutro) lá da 236; os chefes e pessoal da plataforma do C.A.
PS: Eu vou embora mas eu deixo vocês me chamarem pro churrasco grátis que nosso P.O. tá nos devendo hein !
Namastê
All Rights Reserved by EU MESS !
sexta-feira, 18 de julho de 2008
quarta-feira, 2 de julho de 2008
Pair Programming/Code Review
"Duas cabeças pensam melhor do que uma."
Acho que essa frase, cujo autor eu desconheço, reflete a essência da programação em par (pair programming). Não vamos chover no molhado aqui explicando o conceito que é melhor descrito aqui, aqui ou aqui.
Os prós da programação em par (código com melhor qualidade, em parte devido a maior atenção do programador quando sob o efeito de outro par de olhos, aprendizado e troca de experiência, etc, etc) puderam ser sentidas com a pequena experiência que alguns desenvolvedores tiveram ao adotarem esta prática em algumas tarefas.
Agora a pergunta que não quer calar é se estamos fazendo programação em par de forma sistemática. Bom a resposta é não. "Mas como ? Você acabou de dizer que programação em par é uma ótima técnica. É bom ou não ?". Deixe explicar.
Primeiro em "um ambinte Scrum" a democracia é fundamental. Sem este preceito as pessoas não se envolvem não sentem-se estimuladas a agir e por melhor que seja uma idéa a probabilidade de ela fracassar por causa deste "fator humano" é grande.
Como não "votamos" o uso da programação em par (devido ao tempo de apresentar a ideia seus preceitos básicos etc etc) os próprios integrantes do time se encarregaram eles mesmos de utilizarem esta técnica quando acharam conveniente. Mesmo sem saber que o que estavam fazendo era pair programming.
Respondendo a pergunta a programação em par é usada quando o time acha necessário e os motivos são: aprendizado(um programador tem um skill que pode auxiliar outro na realização da tarefa), qualidade do código (dois desenvolvedores tem tarefas semelhantes logo resolveram executar as duas tarefas juntos).
Mas mesmo com essa liberdade no uso ou não da programação em par tentamos sempre fazer uso da revisão do código(ok ok, isso não foi votado mas espero não ver nenhuma rebelião por causa disto ... o que é isso lá fora tochas, uma fogueira ???) e não exite um revisor fixo (tá bom eu confesso as vezes eu reviso). A revisão não tem o intuito de desqualificar o código sendo revisado. A intenção é que revisor e o autor do código entrem em consenso sobre o melhor caminho para boas práticas de codificação e código de qualidade. Ambos aprendem e todos ganham. Bom essa é a intenção quem pode falar se estamos conseguindo este objetivo é o time (não vou pressionar ninguém a falar algo positivo sobre este artigo mas sabem aquelas férias na Disney de que falei ? Pois é, o primeiro que falar que o que escrevi é metira pode dar adeus as férias).
"Conhece-te a ti mesmo".
P.S: Como esse artigo tá muito sério resolvi citar Sócrates. :-D
Acho que essa frase, cujo autor eu desconheço, reflete a essência da programação em par (pair programming). Não vamos chover no molhado aqui explicando o conceito que é melhor descrito aqui, aqui ou aqui.
Os prós da programação em par (código com melhor qualidade, em parte devido a maior atenção do programador quando sob o efeito de outro par de olhos, aprendizado e troca de experiência, etc, etc) puderam ser sentidas com a pequena experiência que alguns desenvolvedores tiveram ao adotarem esta prática em algumas tarefas.
Agora a pergunta que não quer calar é se estamos fazendo programação em par de forma sistemática. Bom a resposta é não. "Mas como ? Você acabou de dizer que programação em par é uma ótima técnica. É bom ou não ?". Deixe explicar.
Primeiro em "um ambinte Scrum" a democracia é fundamental. Sem este preceito as pessoas não se envolvem não sentem-se estimuladas a agir e por melhor que seja uma idéa a probabilidade de ela fracassar por causa deste "fator humano" é grande.
Como não "votamos" o uso da programação em par (devido ao tempo de apresentar a ideia seus preceitos básicos etc etc) os próprios integrantes do time se encarregaram eles mesmos de utilizarem esta técnica quando acharam conveniente. Mesmo sem saber que o que estavam fazendo era pair programming.
Respondendo a pergunta a programação em par é usada quando o time acha necessário e os motivos são: aprendizado(um programador tem um skill que pode auxiliar outro na realização da tarefa), qualidade do código (dois desenvolvedores tem tarefas semelhantes logo resolveram executar as duas tarefas juntos).
Mas mesmo com essa liberdade no uso ou não da programação em par tentamos sempre fazer uso da revisão do código(ok ok, isso não foi votado mas espero não ver nenhuma rebelião por causa disto ... o que é isso lá fora tochas, uma fogueira ???) e não exite um revisor fixo (tá bom eu confesso as vezes eu reviso). A revisão não tem o intuito de desqualificar o código sendo revisado. A intenção é que revisor e o autor do código entrem em consenso sobre o melhor caminho para boas práticas de codificação e código de qualidade. Ambos aprendem e todos ganham. Bom essa é a intenção quem pode falar se estamos conseguindo este objetivo é o time (não vou pressionar ninguém a falar algo positivo sobre este artigo mas sabem aquelas férias na Disney de que falei ? Pois é, o primeiro que falar que o que escrevi é metira pode dar adeus as férias).
"Conhece-te a ti mesmo".
P.S: Como esse artigo tá muito sério resolvi citar Sócrates. :-D
quarta-feira, 25 de junho de 2008
Papéis
O Scrum prega poucos papéis no desenvolvimento de software. Basicamente o PO (vulgo "Puta Oreia"), Scrum Master (vulgo "Office Boy") e o Time (vulgo "Faz Tudo").
Em projetos ditos "tradicionais" temos um certa hieraquia como Arquiteto, lider de projeto e outros. O Time no Scrum não tem nenhuma divisão hierarquica então como pode o mesmo tomar decisões sobre aspectos arquiteturais, frameworks a serem utilizados, etc. ?
Tivemos essa experiência recentemente e a solução foi a boa e velha democracia. Sim nós votamos. Apresentamos os candidatos (no caso 2 frameworks MVC) com os prós e contras utilizando a experiência de cada um do time e fizemos a votação.
O que temos desta experiência é que o time fica ciente de porque determinada solução foi adotado e o que pode ser feito no futuro se a solução escolhido não for de agrado de todos.
Concluimos que adotaríamos o framework XPTO mas que iríamos pesquisar mais afundo o framework LXWZ aproveitando os Lab Days. Por falar em Lab Days este é um assunto pra outro artigo.
Peace!!!
Em projetos ditos "tradicionais" temos um certa hieraquia como Arquiteto, lider de projeto e outros. O Time no Scrum não tem nenhuma divisão hierarquica então como pode o mesmo tomar decisões sobre aspectos arquiteturais, frameworks a serem utilizados, etc. ?
Tivemos essa experiência recentemente e a solução foi a boa e velha democracia. Sim nós votamos. Apresentamos os candidatos (no caso 2 frameworks MVC) com os prós e contras utilizando a experiência de cada um do time e fizemos a votação.
O que temos desta experiência é que o time fica ciente de porque determinada solução foi adotado e o que pode ser feito no futuro se a solução escolhido não for de agrado de todos.
Concluimos que adotaríamos o framework XPTO mas que iríamos pesquisar mais afundo o framework LXWZ aproveitando os Lab Days. Por falar em Lab Days este é um assunto pra outro artigo.
Peace!!!
segunda-feira, 23 de junho de 2008
Pensamento do dia
Galera,
aí vai um pensamento de Charles Bukowski, achei que se
enquadra bem na situação atual do nosso time ;)
"A diferença entre um louco e um profissional é que
um profissional faz o máximo que
pode de acordo com o que se propôs a
fazer, ao passo que um louco faz
excepcionalmente bem o que não
consegue deixar de fazer.”
by Charles Bukowski
aí vai um pensamento de Charles Bukowski, achei que se
enquadra bem na situação atual do nosso time ;)
"A diferença entre um louco e um profissional é que
um profissional faz o máximo que
pode de acordo com o que se propôs a
fazer, ao passo que um louco faz
excepcionalmente bem o que não
consegue deixar de fazer.”
by Charles Bukowski
sexta-feira, 20 de junho de 2008
Vivendo e aprendendo ...
Uma coisa interessante das metodologias agéis (Scrum, XP, outros) é a maneira pela qual elas enfatizam e geram um comprometimento dos envolvidos (desenvolvedores, stakeholders, etc, etc).
Não que os membros do nosso time não tenham tido comprometimento em outros projetos que não usavam o Scrum. Todos eles são pessoas altamente competentes, talentosas e tenho total confiaça neles. (Muito bem time, todos vocês receberam o número da minha conta bancária efetuem o deposito até o dia 30/06 ou eu modifico este artigo ;-D)
Mas quando damos ao time a liberdade de estimar e de levar ou não adiante um ítem do backlog (mesmo que a contragosto do PO) parece que existe um "efeito placebo" que motiva o pessoal.
Veja o exemplo de um caso real abaixo (o nome das personagens foram trocados por motivos obvios):
Papai Smurf(Scrum Master): Para fazer esta tarefa vamos usar o framework WS XPTO. Vc precisa configurar 213134532411414 aquivos xml mas é simples e já fizemos isso antes
Gustaff: Hummm ... o que você acha de pesquisarmos um framework mais simples ?
Papai Smurf(Scrum Master): Acho legal ... poderíamos usar em outro projeto ... mas e o tempo ?
Gustaff: Pode deixar ... eu estudo e acho que posso fazer isso de maneira mais simples ...
Papai Smurf(Scrum Master): Ok ...
Trabalhando com projetos "tradicionais" casos acima não são tão freqüêntes como os que observei em tão pouco tempo de Scrum.
"O tempo é bom conselheiro".
Não que os membros do nosso time não tenham tido comprometimento em outros projetos que não usavam o Scrum. Todos eles são pessoas altamente competentes, talentosas e tenho total confiaça neles. (Muito bem time, todos vocês receberam o número da minha conta bancária efetuem o deposito até o dia 30/06 ou eu modifico este artigo ;-D)
Mas quando damos ao time a liberdade de estimar e de levar ou não adiante um ítem do backlog (mesmo que a contragosto do PO) parece que existe um "efeito placebo" que motiva o pessoal.
Veja o exemplo de um caso real abaixo (o nome das personagens foram trocados por motivos obvios):
Papai Smurf(Scrum Master): Para fazer esta tarefa vamos usar o framework WS XPTO. Vc precisa configurar 213134532411414 aquivos xml mas é simples e já fizemos isso antes
Gustaff: Hummm ... o que você acha de pesquisarmos um framework mais simples ?
Papai Smurf(Scrum Master): Acho legal ... poderíamos usar em outro projeto ... mas e o tempo ?
Gustaff: Pode deixar ... eu estudo e acho que posso fazer isso de maneira mais simples ...
Papai Smurf(Scrum Master): Ok ...
Trabalhando com projetos "tradicionais" casos acima não são tão freqüêntes como os que observei em tão pouco tempo de Scrum.
"O tempo é bom conselheiro".
Divisão de Tarefas
P.S.: Tinha gente que tava tão empolgada com a divisão de tarefas que queria levar o quadro da CTBC pra casa. Pode ? Imagina o constrangimento um monte de marmanjo carregando um quadro da sala de reunião pro elevador e o segurança pedindo pra galera voltar. Corto minha cabeça mas não digo que a idéia foi do Marcello (putz escapou !!!...)
3, 2, 1 ... GO!!! (Início do Jogo)
Eu achava que 2 (dois) dias era muito tempo para a reunião de Sprint Planning. Após nossa primeira reunião mudei de idéia. Não devemos nos esquecer que a apresentação dos projetos e o Planning Poker é um processo que exige muito esforço para tornar o conhecimento da equipe mais homogêneo. É nesta hora que todos se conscientizam do que deve realmente ser feito.
O segundo dia para a divisão das tarefas também foi utilizado para familiarizar outros componentes do time com o ambiente de desenvolvimento do projeto e alguns apectos arquiteturais e padrões de código. O que julguei um tempo muito útil. É claro que com a padronização dos projetos no CTI este tempo não será necessário.
Quero destacar o desempenho do nosso PO (vulgo "Puta Oreia" :-D ) que se mostrou muito preparado na reunião de Sprint Planning respondendo com propriedade a todas as perguntas do time.
"Foi dada a partida!!!" :-)
O segundo dia para a divisão das tarefas também foi utilizado para familiarizar outros componentes do time com o ambiente de desenvolvimento do projeto e alguns apectos arquiteturais e padrões de código. O que julguei um tempo muito útil. É claro que com a padronização dos projetos no CTI este tempo não será necessário.
Quero destacar o desempenho do nosso PO (vulgo "Puta Oreia" :-D ) que se mostrou muito preparado na reunião de Sprint Planning respondendo com propriedade a todas as perguntas do time.
"Foi dada a partida!!!" :-)
Assinar:
Comentários (Atom)