Categoria: Agile/Scrum/TDD

TDD – Os Mandamentos

Olá Pessoal, 

O post de hoje separei alguns “mandamentos” que eu considero importante termos em mente quando estamos programando guiado por testes. Cada um dos pontos que veremos abaixo fui aprendendo com base na experiência que venho adquirindo usando a técnica de TDD, dai separei aquelas que repetiu com bastante frequência e que era bom ter sempre termos em mente quando estamos sendo influênciados por Test-Driven-Development.

lets Go…

Um detalhe importante ponto que preciso ressaltar é que os mandamentos eles são de certo modo abstrato, ao ler, ficaremos sem saber o motivo de cada um, mas só conseguimos ver  a real existência quando  estiver programando, ai vai você vai lembrar: “hmm, isso aqui é o que tinha no mandamento X”.

Os Mandamentos de TDD que você precisa saber

A seguir temos alguns mandamentos que todo Agilista precisa saber quando estiver trabalhando com TDD. A criação destes mandamentos teve como base o princípios  da técnica  e outros são de minha autoria que identifiquei durante as minhas experiências nos projetos que tenho  usado TDD.

  1. Coragem: administrar o medo durante a programação;
  2. Adicione um teste antes de qualquer coisa;
  3. Faça uma coisa de cada vez;
  4. Faça o mínimo de trabalho possível para compilar;
  5. Falha é progresso;
  6. Eliminar as duplicações antes de ir para o próximo teste;
  7. TDD não é dar passos pequenos, e sim saber dar os passos pequenos;
  8. Quando receber uma barra vermelha inesperada, dê marcha ré;
  9. Rode os testes a cada nova implementação, só para garantir o que é obvio para você, também é obvio para o computador;
  10. Quando um defeito passar, aprenderemos uma lição de como o teste deveria ter sido escrito e seguiremos em frente;
  11. quanto mais pressão sofrer busque adicionar mais testes de requisitos na lista TO-DO;
  12. Esqueça as refatorações enquanto o sinal não ficar verde;
  13. De tempos em tempos nosso raciocínio falhará, é normal, não estamos lutando pela perfeição;
  14. Não é pecado fazer um teste funcionar através da duplicação, lembre do ciclo TDD;
  15. Não vá para cama até a duplicação tenha sumido;
  16. Documente o que é significativo, não o projeto;
  17. Escreva testes que exatamente gostaria de ter;
  18. Não interromper o que estamos fazendo;
  19. Está se sentindo inseguro, troque a marcha;
  20. Não escrever novos testes quando temos uma barra vermelha;
Eu falei desses mandamentos no TDC 2012, caso queira ver no modo apresentação só acessar: 
abraços, vou ficando por aqui.
see ya!!!!

IcreScrum tools para Team Agile

opa! Pessoal,

O post de hoje é para quem teve dificuldade de rodar o IceScrum localmente em ambiente Linux. Ahh, você sabe o que é iceScrum? Se não sabe, fique tranquilo que irei explicar.

Lets go…

IceScrum

Bom, venho há algum tempo buscando ferramentas open-source eficiente para usar nos meus projetos Agile, tentei de cara ScrumWorks, porém a limitação deles para nro de usuário e feature para a versão free foram pontos que fizeram eu buscar uma nova ferramenta mais completa(claro, sem deixar de ser open-source). Daí, fui apresentado ao IceScrum através do Google, e vou lá fazer uns nos testes, e não é que a ferramenta foi aprovada? Pois, eh bem completa com relação à outras que fingem ser free, mas só com meia-duzia de feature, no máximo. A seguir falo um pouco sobre IcreScrum:

  •  100% plataforma web;
  • leve e rápido;
  • roda tranquilão no Chrome;
  • Bons conceitos de usabilidade ;
  • boa organização;
  • baixa curva de aprendizagem;
  • instalação (execução na verdade) rápida e fácil;
  • diversos tipos de chart;
  •  controle das atividades por horas ou pontos;
  • no dashboard temos todas as informações que precisamos;
  • podemos usar post it para user stories (achei bem legal);

O que sentir falta?

  • definir deadline  ou horas para uma task;(pelo menos achei, onde fechar uma task, ou definir quando ela deve ser concluída)
  • add uma task à um Sprint deveria ser mais fácil de encontrar e adicionar.

Ainda estou testando a ferramenta para conhecer melhor, mas já adotei para um projeto e quero ver  se ela vai atender aos principios de um projeto Agile. No link a seguir temos os screensshots da ferramenta:

http://www.icescrum.org/screenshots/

Rodando o IceScrum Localmente ambiente Linux

  1. faça o download da ferramenta na versão bundle: http://www.icescrum.org/en/download-en/
  2. descompacte o arquivo
  3. abra  o terminal e navegue até a pasta bundle que foi descompactada
  4. digite: sudo chmod u+x *.sh  na raiz da pasta bundle
  5. Agora vá na server/bin e faça o mesmo
  6. Em seguida retorne para raiz, ou seja, pasta bundle
  7. e execute: sudo ./start.sh
  8. Algumas mensagens  de config são printada, é o esperado;
  9. abra o browser, por default o icrescrum roda: http://localhost:8080/icescrum
  10. Para entrar, faça um pequeno registro, que também já cria o usuario admin
  11. Pronto, done! Agora é só criar os projetos e  enjoy

 Note: Detalhe importante, para rodar o IceScrum é requerido ter o TomCat 6  ou later instalado, para este post usei o Tomcat 7.

Vou ficando por aqui, espero que tenham gostado do post.

see ya! Guys

abraços,

Pré-Lançamento: Livro TDD na Prática

Olá pessoal,

É com muita felicidade que escrevo este post. Realmente só quem é “pai” sabe o que eu estou sentido. Como vocês já podem imaginar está vindo ai mais um filho para se juntar aos seus irmãos “Guia do exame SCJP” e “Guia Prático JEE”. É ele o “TDD na Prática”. O livro está previsto para ser publicado até o final de junho/2012. Ainda não recebi a versão final do livro, mas assim que receber estarei disponibilizando alguns capítulos. A seguir faço uma pequena apresentação sobre o meu filhão.

lets go…

Sumario Tdd na Prática

Sobre o livro

O livro vem com um objetivo simples: “Descomplicar o que parece ser complicado”, em outras palavras O objetivo é ensinar como praticar TDD usando a linguagem de programação Java. Para muitos iniciantes em TDD, no primeiro momento parece que estamos fazendo tudo errado e que escrever os testes antes do código funcional não é nada legal. E que para superar os primeiros obstáculos, só o conhecimento técnico não é suficiente. Quando comecei com TDD passei por vários obstáculos e um deles foi encontrar livros práticos, ou seja, aqueles que eu pudesse colocar a mão na massa de verdade, ter problemas para resolver usando a técnica, etc. Os disponíveis eram bastante teórico, deixando a parte prática sobre minha responsabilidade que, como iniciante, era difícil saber por onde começar. Esses livros foram importantes para entendimento e formação da minha base teórica sobre o assunto, mas eu percebi que uma coisa era eu ter lido e outra era praticar e me ver com o Eclipse aberto e sem saber o que fazer de verdade, ou pior, me perguntar: ‘como resolver um problema usando TDD e não cair na tentação de escrever os testes por último?’. Quem não tem cão caça com gato. Tive que criar meu próprio caminho prático, onde comecei a desenvolver novas aplicações usando a técnica (venci pela persistência), em seguida surgiu  a oportunidade de ir para um projeto novo na empresa que trabalhava e lá tive o espaço para desenvolver usando TDD por quase 2 anos, e nesse meio surgiu a ideia desse livro: “por que não criar um livro prático sobre TDD com base na minha experiência?”. E foi assim que comecei a escrever o livro no final de 2010, tendo como referência o Kent Beck.  

O que você vai encontrar no livro:

  • Desenvolver aplicações Java usando a técnica de TDD;
  • Exercícios Práticos;
  • O uso de objetos mocks com Mockito;
  • Praticar algumas técnicas de Refactoring ;
  • Entender os valores do mundo Agile;
  • Por que TDD?
  • Junit;

E como sempre, dei preferência em usar uma linguagem informal e fazendo o uso bastante da primeira pessoa. O motivo é que durante seus estudos quero que tenha a sensação de estar batendo um papo comigo ao invés de estar lendo algo mais formal.

Meu desafio

Quando eu decidi escrever esse projeto foi porque me sentir desafiado (assim como os outros já publicados). É isso mesmo. Ao olhar o que tinha em mãos (anotações) mais a experiência e sofrimento com o “mundo TDD” e decepções que passei eu disse: “preciso escrever um livro sobre o assunto”. Daí reparei que escrever um livro com um assunto abstrato não seria uma tarefa fácil, uma vez que TDD, refactoring são técnicas que não se aplicam somente à linguagem Java. E daí eu comecei a entender melhor o livro do Kent Beck (TDD by example) e Martin Fowler (o de Refactoring) o quanto eles são “chatos” e sem sabor para quem é bem iniciante. E eu disse: “preciso fazer algo que empolgue o iniciante, ou seja, algo com sabor, mas que eu não venha perder o eixo principal da técnica”. E daí passei dias pensando, escrevendo, apagando, anotando, dormindo sem respostas e fui vendo como vencer esse desafio de ensinar TDD sem ferir os conceitos da técnica. Isso era o que me tirava o sossego todos os dias e não sei se consegui atingir. Acredito que sim, mas só terei a certeza quando você me escrever dizendo o que achou J. (aguardem até o lançamento…)

Quem pode ler?

O publico alvo são estudantes da tecnologia Java que querem aprender usar TDD desde o principio e tem simpatia com o mundo Agile.Se você ainda está dando os primeiros passos com Java e gosta de ser desafiado, este livro é para você. Indiretamente o livro acaba revisando alguns conceitos básicos do Java nada fora do normal, porém agora o desafio é você fazer as coisas mais simples escrevendo seu teste primeiro. Como eu já passei por isso, sei o quanto difícil é escrever os testes primeiro antes do código funcional e quando eu falo mais simples, não necessariamente é mais fácil.  Se você está bem no inicio do Java, ainda dando “Hello World”, eu diria que o livro não vai ajudar muito nos seus estudos com Java, talvez atrapalhe. A minha sugestão é: aprenda primeiro os fundamentos da linguagem e Orientação à Objetos e depois retorne à todo vapor para ler o livro. Enquanto isso coloque na prateleira e não compre o exemplar.

Pensei em escrever este livro quando, ao iniciar meus estudos com Java, não encontrei um material do qual pudesse desde “pequeno” ir sendo educado com boas práticas, e fui aprendendo no dia-dia, além dos sofrimentos que tive até adquirir uma nova cultura. Se você é aquele iniciante que está a fim de colocar em prática toda essência do Java e ao mesmo tempo ir entendendo o que só ouve falar de TDD, Refactoring, JUnit, este livro é para você.

Eu particularmente diria que este é um tipo de livro que gostaria de ler depois de ter lido Head First Java da Kathy Sierra.

Agradecimentos

Fazer essa parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como essa: amigos, colegas de trabalho, familiares, “amigo virtual” etc. E lembrar todos não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que perdoem.

Não poderia esquecer o meu colega de trabalho Gustavo Knuppe, apesar dele não saber que estava escrevendo este livro, foi responsável em muitas mudanças que fiz na forma de abordar o assunto de TDD.Principalmente em um artigo sobre TDD, o qual Knuppe foi o revisor, e nesse processo, sugiram várias e boas sugestões no artigo produzido e aproveitei para utilizar neste projeto. Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença e grande. Obrigado meu amigo!

Outra pessoa é meu amigo Edson Gonçalves, sempre digo que se me tornei um escritor é porque fui “batizado” por esse grande escritor e amigo, o qual já temos um laço de amizade verdadeira por mais de quatro anos. Dedicar este livro para um grande amigo como você é o mínimo que posso fazer. Nos momentos mais difíceis você sempre estava ali comigo me dando força. Abraços e tudo de bom para você meu grande amigo.

Formatos

  • Será vendido no formato impresso e e-book.

Enfim, pessoal essa foi a pequena apresentação do meu próximo livro. Espero que vocês gostem e curtam. Quem quiser divulgar nas comunidades eu não me importo 🙂

Abraços, qualquer dúvida só mandar.

See ya!!!

Overview TDD by example

olá Pessoal,

O objetivo deste post é dar um overview do livro TDD By Example, eu li o livro no inicio do ano, mas só agora conseguir liberar o post.Certamente se você quer entender algo de TDD já deve ter colocado o mesmo na sua lista. Nesse post vou dá um overview com meu ponto de visto  sobre o livro. Se houver alguma critica com certeza ela será construtiva. 🙂

Lets go…

Overview

O livro na parte I atende o que esperamos sobre TDD e o que já vimos na internet, porém o Kent Beck aborda de uma forma bem longe de qualquer linguagem de programação é abstração mesmo(e isso é bom), se você está iniciando com TDD, e se sente muito inseguro em saber qual o próximo unit tests criar, então terá dificuldades em seguir adiante em muita parte do livro, porque há questões entre linhas que só com uma boa dose de pratica que conseguimos identificar porque já fizemos. E a todo momento o Kent Beck tenta provar que TDD não é apenas escrever unit tests primeiro e sim uma forma de ti guiar para saber que está desenvolvendo algo correto conforme esperado, quando surgir um defeito, saberá fix, no menor tempo e maneira rápida e que ter tests é uma consequência. É como funciona um alarme. Se você põe um alarme na sua casa, ele não vai disparar do nada. Um alarme devidamente configurado, foi programado para disparar quando alguma regra de segurança fosse quebrada (uma porta que abriu que não deveria). E o alarme ti dar um feedback no menor tempo possível, o mesmo com os units tests, se eles quebraram é porque algo mudou em algum lugar que fez um de seus tests não ter o resultado esperado. Tirei essa conclusão durante abordagem do Beck.

E a pratica?

Não tem nada de pratico não, esqueça algo que possa fazer passo-passo, é abstração mesmo, ele põe os códigos lá e vai mostrando o que fazer. Bem, este também é o proposito do livro de mostrar o uso de TDD e não ser uma receita de bolo, porque não há receita de bolo, mas sentir que se o leitor é bem iniciante com TDD, pode vai ficar frustado. Eu diria que o publico alvo, seria um leitor que já fez alguns TDDs com aqueles software house que fazemos nas madrugadas de isonia, ou quem já usa na empresa e quer aprimorar.

As demais parte do livro é bem teoria, é abordado padrões de projeto (um breve overview), depois vai para refactoring, fala do uso de TDD, mas achei a leitura dele cansativa, o Kent Beck precisa escrever melhor na minha opnião, falo em termo de didático, sinto que na leitura fica algo “meio explicado” e que precisamos fazer associações para entender o que ele quis dizer. E não adianta dizer que bons programadores não escreve bem, a Kathy Sierra e seu time da serie “use à cabeça” provam isso para o mundo. E há outros autores por ai que sabe escrever bem, a questão é pensar mais como leitor do que autor/desenvolvedor. E isso não é uma tarefa fácil. Já consigo imaginar o sofrimento do Kent.

Custo x beneficios

O livro não é tão caro, com o dolar mais barato agora deve custar menos de 70,00 reais. Eu acho um livro válido se você já tem uma pratica de TDD e que ver alguma coisa, mas acho que há livros melhores e esperava mais do livro do Kent.

Os capitulos

Esses aqui são bem curtos, somente na parte bem teorica no final do livro que é tem caps longos, mas na de TDD na parte I, são bem pequenos mesmo de ter 3-4 páginas e achei isso legal, porque ele vai na ideia de baby-steps, explica só um trecho e explica de forma especifica.

O aprendizado

Bem, após a leitura conseguir consolidar mais um pouco de teoria de TDD, abrir mais minha mente de forma pratica que TDD guia você mais para o design e os units tests são consequência, a cobertura de code também. Fora, a organização e policiamento quando estiver no campo de batalha de TDD, não dar passos longos, saber quando preciso dar um passo atras e recomeçar, confiança no que entrego, garantir que atende aos requisitos e com alguma coisa próximo a zero de defects caso aconteça. TDD e refactoring estão mais próximos que qualquer coisa no mundo, querer usar TDD sem técnicas de refactoring é quase impossível, pois o próprio processo começa a gritar no menor tempo possível dizendo : “aqui precisa de refactoring”. Enfim, achei que foi um bom conhecimento adquirido.

Concluindo

O sentimento após a leitura é que “valeu” ter lido deu pra pegar detalhes, mas isso porque já tinha praticado e lido outros materiais antes, se tivesse lido como meu primeiro material, a frutação seria grande e teria jogado o livro de lado.

Bom fica aqui meu overview, e você o que achou do livro? Comente, please!!

Abracos, vou ficando por aqui.. see ya!! guys!

Scrum:Definindo as estórias para o Sprint Backlog


olá Pessoal,

Demorei um pouco, pois os ultimos dias tem sido corrido, mas está aqui mais um post da série Scrum, hoje vou apresentar como é que a equipe define quais estórias estarão no Sprint Backlog do Sprint que inicia amanhã. Vimos em um dos post anteriores que o PO é um cara importante no planejamento do Sprint. Então chegou a hora de discutir de como tirar as coisas que estão no Product Backlog e trazer para nossa “mesa”. Antes de começar o post queria compartilhar com vocês um vídeo muito interessante desenvolvido pela FIAP. Não é fazer propaganda da instituição, pelo contrário o vídeo foi feito com objetivo informativo sobre o mercado de TI. Vejam:


Lets go

Como a equipe define as estórias que vão para um Sprint?

Essa é uma pergunta clássica. Eu já ouvir alguns comentários que talvez o PO ou SM deveria fazer isso. Eu acho que se Scrum fosse um framework que funcionasse com base em quem tem o nível mais alto(para não dizer função) é quem define as coisas, talvez faria sentido. Mas, como não é assim, o conceito de time, equipe, pessoas etc, é de fato mais importante que os papeis apenas. Enfim, apesar do PO ter escrito toda história e em alguns casos ser o responsável pelo investimento no projeto, com Scrum isso não dar o direito de dizer: “a estória já está escrita, priorizada e o escopo é aquele. Se não entendeu algum ponto, por favor, deixe me saber, mas não vou mudar o escopo, porque eu quero assim”. Não é bem por ai. A questão é quem tem a bola da vez aqui é o time, ou seja, todos estão envolvidos e não apenas o PO. Não é porque ele é dono do produto que tudo vai acontecer como ele deseja sem questionamentos. Se temos um problema como esse é sinal que seu cliente não entendeu como Scrum funciona e ai é um outro problema que precisa ser tratado antes de pensar quando vai acontecer a reunião de planejamento.Eu diria que até antes do cliente apresentar o produto, ele já deveria saber o porque vai rodar Scrum e saber que as coisas funciona em um trabalho de equipe e cada um tem suas responsabilidade e limitações. Se isso não está claro para o seu cliente, não inicie nada, do contrário terá problemas e discussões que talvez não compense. Agora vamos ignorar o cenário anterior, trouxe apenas fazer uma citação do mundo real :). Então, Camilo como escolher a estória que vai para o Sprint Backlog?

Por sentimento ou instinto. É isso mesmo não há mágica nem ferramenta que vai ti dizer: “pega a história X, e sim a equipe que vai contribuir para isso”. Normalmente o ScrumMaster pergunta para equipe se a estória que está no top da lista(aquela que tem mais importância para o PO) dar para entregar naquela Sprint. Aquelas que ficarem com dúvidas e incertezas da entrega fica de fora (com o aval e negociação com PO) do Sprint.

A seguir temos um exemplo, pratico de um Product Backlog:

Imagem do livro Scrum and XP from the Trenches

Note: Claro, que vamos seguir sempre a ordem de importância definidas pelo PO e não pegar as estórias aleatórias.

Vamos supor que o PO não gostou porque a história D está fora, já que a velocidade da equipe só permite entregar até a C. O que fazer?

Primeiro: O PO não pode obrigar à equipe pegar(de novo, para você não esquecer). Então ele tem duas opções:

  1. é alterar o escopo, possivelmente quebrando e o time re-estimar e ver se é possível.

  2. ele mudaria a ordem de prioridade levando a estória para acima do C, daí o team é obrigado a pegar. Porém, a estória C ficaria de fora. Mas, o framework Scrum não diz que temos que pegar a estória com maior prioridade?

Sim. Pegamos a estória que está no topo da pilha do product backlog, mas ao olhar ela identificamos que é grande demais e não cabe dentro do Sprint de duas semanas, ou seja, é pouco tempo para muita coisa(escopo grande) em uma única estória. Lembre-se, as estórias deve ser do tipo INVEST.

  • – Independente: a estória não pode ficar bloqueada durante a implementação, ela precisa ter vida por si só;
  • – Negociável:uma estória precisa ter um escopo que pode ser alterado sem perder toda a essência do que se pretende e algumas coisas podem ser postergadas para um dos próximos Sprint tranquilamente.
  • – Valioso: deve agregar valor ao produto, ter um valor de importância dentro do produto
  • – Estimável: se não conseguimos estimar com base no que está escrito para estória, é porque temos alguma problema no que ela se propõe atingir. Então precisamos ver com o PO o que ele está querendo dizer;
  • – Small: não precisa ter todas as funcionalidade em única estória, sendo assim pode ser pequena para que fique dentro do Sprint.

  • Testável: toda estória precisa ter uma forma de validar se ela foi implementada corretamente. Então os critérios de aceitação devem existir, para que podemos nos certificar que fizemos algo de acordo com o esperado.

Então era isso pessoal que eu tinha para apresentar para vocês quando estiverem pegando as estórias do Product Backlog e trazendo para o Sprint Backlog. Não se esqueçam que a responsabilidade de analisar e estimar uma estória é da equipe.
O que foi escrito pelo PO para estória é o que ele desejaria(nem sempre querer é poder) de ver pronto, mas nem sempre é possível, pois há vários fatores que contribuem para isso tais como: velocidade da equipe, nível técnico, interrupções etc. Não é uma tarefa fácil, mas com uma boa comunicação entre a equipe e o PO, sempre terminamos no contexto ideal.

Vou ficando por aqui espero que tenham gostado.

Abraços, see ya!!