Retrospectiva 2010

Já faz um tempo que não escrevo aqui, mas esse post vai explicar um pouco o por que disso.

O ano de 2010 foi um ano de muitas surpresas, emoções, realizações e acima de tudo mudanças. No começo do ano eu morava em Belém, trabalhava em um banco para a Cobra Tecnologia, onde era coordenador de um time de desenvolvimento, ministrava aulas na pós-graduação do CESUPA e ainda tinha as atividades com as comunidades locais (em especial o Tá Safo e Beljug), reuniões dos grupos, organização de eventos e palestras ministradas na região...vida muito agitada, vivia ligado em 220 sempre!!!

Posso dizer que eu estava em um momento bastante confortável, podia me considerar uma pessoa realizada em muitos aspectos, tinha um relacionamento estável, empregos estáveis, muitos amigos por perto e morava com a minha família... não queria mais nada! Mentira queria sim, mas não sabia ainda o que viria pela frente.

E ai começaram as mudanças, a primeira de todas foi o noivado... isso mesmo, eu decidi casar!!! Essa já seria uma grande mudança na vida de qualquer pessoa, na minha não foi diferente, mas isso era só o começo.

Em junho eu participei do evento Agile Brazil, conheci algumas pessoas novas incluindo os futuros colegas de trabalho... é isso mesmo, eu fui chamado para fazer parte do time da Ci&T, aceitei a proposta e hoje é a empresa que eu trabalho como líder técnico.

Mas mudar de emprego era só um detalhe, a Ci&T que eu iria trabalhar fica em Campinas, então eu e minha noiva largamos nossos empregos, nos mudamos para Campinas e fomos morar juntos.

Então em agosto desse ano eu vim morar em Campinas para trabalhar na Ci&T e junto com minha noiva alugamos um apartamento e trouxemos nossas trouxas.

Não conhecíamos a cidade e nem tínhamos muitos amigos por aqui também. Foi sem dúvida uma grande mudança em nossas vidas e um desafio novo que estamos superando juntos todos os dias.

Do meio do ano para cá eu mudei completamente de vida, uma vida nova, cheia de novos desafios, emoções e surpresas.

O ano terminou e com certeza foi um ano marcante e inesquecível...daqui pra frente eu não sei o que vai acontecer, mas espero que eu continue me surpreendendo com as novas experiências que virão... É foi um ano maravilhoso sem dúvidas. 

Um Feliz Ano Novo para todos, muita paz e saúde, que o resto é por nossa conta.

Que venha 2011!!!!

PS: "Aprende que não importa onde já chegou, mas para onde está indo... mas, se você não sabe para onde está indo, qualquer caminho serve" (Willian Shakespeare)

Abraço,

#horadodesapego com a galera do Tá Safo!

Publiquei a pouco o relato do Tá Safo em Ação com a #horadodesapego que ocorreu em julho com meus amigos Caike (@caike) e Mateus (@mateuslinhares) compartilhando suas experiências!

Confiram o post no blog do Tá Safo!!!

Abraço,

Praticar o Desapego em TI é Importante!

Eu estava lendo alguns tweets na semana passada e vi a @pamelagatinho anunciando a doação de alguns livros que ela tinha (veja aqui), onde no tweet ela colocava a hashtag #horadodesapego, isso ficou na minha cabeça e comecei a observar outras coisas na qual somos apegados, mais especificamente na área de TI.

Essa semana eu fiquei observando o quanto as pessoas são apegadas ao trabalho realizado na área de tecnologia também. Vamos imaginar a cena - O fulaninho desenvolve uma solução que é utilizada por algum tempo e essa é contestada por outra pessoa que sugere uma nova solução (imagine um novato contestando), o fulaninho demonstra uma enorme resistência e defende com unhas e dentes aquela solução, mesmo estando convencido de que a outra é melhor. Já viu isso alguma vez?

Ai aparecem aquelas frases: "Já pensamos nisso antes, não da certo". Quando não: "Na verdade a solução não é tão simples assim". Ai vem o acomodado e preocupado em perder o controle: "Vai dar muito trabalho mudar tudo é melhor deixar assim". Mas a melhor de todas é: "Ta funcionando então deixa, por que time que ta ganhando não se mexe".

A falta de renovação e preocupação em se melhorar sempre e buscar agir antes mesmo que algo vire um problema maior é que eu acredito ser um dos grandes problemas das empresas de tecnologia que se encontram em um estado de enrijecimento.

Na verdade eu acredito que esse é um dos sintomas mais evidentes do apego! Quando os problemas aparecem, ou novidades aparecem e provacam mudanças, e a busca por proteção, ao em vez de solução, começa a surgir. Esse é um sinal de que o apego ao processo, apego a rotina, apego a solução, já se instaura em seu ambiente.

Nessa semana refletindo um pouco percebi que nós na área de TI precisamos praticar mais a arte do desapego, pois se apegar a soluções, processos e rotinas diárias não é uma boa ideia, ainda mais se tratando dessa área extremamente dinâmica, onde mudanças e quebras de paradigmas são simplesmente naturais.

Por isso que eu sou a favor de praticarmos o desapego! Vamos buscar renovar sempre nosso dia a dia, com novas soluções e melhorias do que realizamos sempre, talvez assim lidar com as mudanças passe a ser realmente natural.

Abraço,

Desenvolvimento Orientado a Testes

No meu último post fiquei de postar sobre TDD com mais detalhes técnicos mostrando um exemplo prático do uso, mas ao ler o último post no blog do Tá Safo do Marcelo Andrade falando sobre TDD e ATDD, um artigo traduzido, vi que não precisaria mais postar aqui, confira.

Abraço.

Testando as Expectativas antes...

Estou estudando bastante sobre a atividade de testes ultimamente e sempre me encontro em um questionamento que acredito que seja comum entre as pessoas que praticam ou estudam essa prática...

Como provar ou avaliar que estou atendendo as expectativas do cliente?

Testar segundo nosso amigo Dicionário é: Pôr a prova, submeter a avaliação, submeter a teste ou experimentação. Refletindo sobre o contexto de software percebemos no dia-a-dia o quanto é difícil ter certeza que o software desenvolvido está de acordo com as expectativas do cliente.

Imaginem um restaurante que você vai pela primeira vez! O Restaurante novo requintado possui um cardápio com nomes esquisitos, molhos e massas com nomes nunca vistos antes e ai ficam as dúvidas: Como será esse prato? Que gosto vai ter essa mistura? Será que a quantidade é suficiente?... Nesse momento são criadas as expectativas, o cliente tem a necessidade (fome!!!) e viu as possíveis soluções dentro da realidade que ele se encontra (restaurante novo!!!), quando ele realiza seu pedido ele acredita que aquilo vai atender as suas necessidades, mas ele não tem certeza disso (notou alguma semelhança?).

O cozinheiro vai simplesmente pegar o pedido e fazer o que ele sempre faz, para atender aquele pedido. Apesar de diferente o contexto, o cozinheiro também está preocupado em atender as expectativas do cliente, mas mesmo ele fazendo o que está especificado no cardápio, ele não tem certeza que vai atender as expectativas do cliente (e agora notou a semelhança?).

Após o prato servido ao cliente inicia-se o processo de prova, ou experimentação (Teste). O cliente experimenta com o olhar (prato bonito!), com o cheiro (ta cheirando bem!) e finalmente com a degustação (eca...ta muito salgado!), e ai chegamos ao final do teste... o cliente sai insatisfeito e talvez nunca mais volte, ou na próxima vez ele da o feedback para o cozinheiro e ele refaz o prato (iterativo), com menos sal e então o cliente ficará mais satisfeito (agora tenho certeza que você notou a semelhança!).

Geralmente a atividade de teste é realizada ao final do processo de construção do software e isso gera um custo que poderia ser minimizado caso tivéssemos as expectativas do cliente mapeadas em teste para orientar o desenvolvimento (TDD – Test Driven Development), assim teríamos critérios melhores para dizer que o software desenvolvido está de acordo com as expectativas do cliente, mas mesmo assim ainda não podemos afirmar com toda a certeza que estamos atendendo 100%, por que temos que lembrar que o cliente ainda está descobrindo o que ele realmente necessita e por isso precisamos receber esse feedback constantemente para melhorar nossos critérios de aceite e melhorar o software desenvolvido. O objetivo no final é o mesmo que o do restaurante, cliente satisfeito!

A prática de TDD possui princípios simples e importantes que ajudam a desenvolver software de maneira iterativa, com design simplificado e evolutivo, código enxuto e organizado (refatoração constante).  E o que orienta tudo isso são os testes, ou seja, as expectativas mapeadas do cliente.

No TDD primeiramente procura-se mapear o que o cliente espera do software,  para depois construí-lo – simplesmente – atendendo aquela expectativa mapeada. Assim o software vai evoluindo junto com o esclarecimento das expectativas do cliente.

Os testes vão evoluindo e o software juntamente vai evoluindo também, sempre que a expectativa é atendida, analisa-se a solução e o código, para avaliar sua qualidade e verificar se pode ser melhorado (refactoring). Como temos a solução funcionando, caso algo seja feito incorretamente na refatoração, rapidamente será percebido durante a execução dos testes novamente (código blindado), além de perceber o teste ainda irá lhe indicar aonde ocorreu o erro, diminuindo o custo de depuração e correção, o ciclo é simples e bastante eficiente.

O processo é simples, mas não tão simples de realizar, pois exige muita disciplina da equipe. Mas acho que o mais importante durante o TDD é o exercício de construir coisas simples de pouco em pouco, acho que SIMPLICIDADE é a palavra em TDD.

Para não prolongar muito esse post, vou dividí-lo e no próximo colocarei um exemplo do desenvolvimento com TDD, sei que foi um post muito teórico, mas a idéia era passar a importância da automatização dos testes e mostrar a forma que é feito com TDD.

Abraço.