Agile/Scrum/TDD – Página: 8

Scrum:Convencendo o Cliente adotar Scrum em 5min

Olá Pessoal,

A partir de hoje estarei dando inicio a série de posts sobre Scrum focando em ajudar quem está dando os seus primeiros no mundo Agile e pretende usar o Scrum framework. Um detalhe que os posts serão curtos e focado no assunto. E neste primeiro, já podemos vê isso em prática.

lets go….

Como convencer o cliente adotar Scrum em 5 min?

Talvez seja fácil convencer um cliente adotar Scrum se você tivesse uma meeting de 1 hora com aqueles slides bonitos e efeitos de impressionar. Mas, nem sempre vivemos no mundo ideal e precisamos adaptar e atender às mudanças. Então como responderíamos a pergunta acima? O segredo é não entrar nos detalhes técnicos, e às vezes nos profissionais da área técnica tendem a ir para o que é mais confortável para nós explicar, mas não considera que o cliente normalmente não é o cara de TI e que para ele pouco importa os detalhes, o mais importante para o cliente é saber o quanto isso agrega valor para o negócio dele e porque deveria adotar. E para isso, devemos deixar o pensamento técnico de lado e traduzir para linguagem humana e compreensível por um stakeholder e atingindo nosso objetivo que é convencer o cliente adotar Scrum . Sabe aquela história que você pode dizer a mesma coisa, porém de formas diferente? É isso que fazemos aqui.

E como responder a pergunta acima sem entrar nos detalhes do framework?

Simples. Respondendo assim:

Scrum é um framework Agile que permite entregar um valor de negócio mais elevado num período de tempo mais curto. (ao falar isso automaticamente o cliente pensará em ROI)
Scrum permite entregar rapidamente software funcionando e de qualidade a cada duas à quatro semanas (ele pensaria, “hmm tenho feedback constante”)
Você (cliente) que define as prioridades. O time se auto-organiza e determina a melhor forma de entregar as funcionalidades de maior priorização
No final de cada Sprint o time apresenta para você (cliente) as funcionalidades funcionando.
Então Scrum é: transparência, inspeção e adaptação.

E assim destaquei 5 importantes pontos que você pode usar e certamente fará seu cliente pensar um pouco mais sobre o Scrum e daí quem sabe ele marca uma próxima reunião mais longa para discutir adoção e possivelmente virar mais um cliente?!

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

Abraços, see ya !

Entendendo Certified Scrum Master CSM

olá Pessoal,

O post de hoje vou falar de um assunto que já é polêmico “Certificação” e quando vamos para o mundo Agile a certificação CSM é mais polêmica ainda que as certificações tradicionais, uma vez que não há uma prova tradicional(tipo aquela da Oracle para OCJP com mais de 60 questões). Sendo assim, vou compartilhar com vocês minha experiência que tive na semana passada, “tirando essa certificação”.

Lets go.

Starting

Acompanho sempre as discussões e opiniões adversas sobre as certificações da ScrumAlliance, nunca opinei, pq não conhecia o suficiente para opinar e não queria comenter o erro de sair falando sem entender(como já fiz no passado em outros cases e em algumas vezes tive que avaliar o que falei e aprender com alguns erros) o Por que?!. Eu sempre tive uma pergunta comigo: pq eles faziam a certificação deles diferente do que estamos acostumados em modelos do tipo OCJP, por exemplo?E isso nunca saiu da minha cabeça. como não tinha resposta, deixei a pergunta no modo stand by, pois eu saberia que ainda ia encontrar a resposta.
Ela veio quando eu parei de pensar: “como eu vou usar essa certificação para uma promoção ou proximo emprego” e começei a pensar: “com a certificação eu passo a ter um cartão de visita com clientes incertos e que preciso vender meu serviço para eles”. E fui fazer a certificação para tirar essa dúvida na prática e buscar as respostas nos minimos detalhe.
E daí começei a entender o motivo que elas existiam e pq eram feita daquela forma, sem falar quem criou as certificações os co-fundadores, se pegarmos o cv deles, a maioria é consultor independente e certamente eles nao pensaram em certificacao para agradar o pessoal do RH. E o que poucos sabem, mas a resposta é: Pq as certificações vieram primeira a ScrumAlliance? Simples, os co-fundadores precisam vender o framework para um cliente(talvez os primeiros), mas este cliente, disse tá preciso de algo mais “sólido” que certifique meu projeto ou pessoas, nao posso comprar, so pq vc ta falando e como vou identificar outros consultores? Eu preciso comprar alguma coisa à nível de mercado.
Pois, eh tb nao sabia, descobrir isso no curso com os dos caras que participou no desenvolvimento da certificação da CSM Michel GoldenBerg, ele trabalhava junto com o Mike Cohn nos projetos Agile (bem no inicio da “revolução agile”).

Acredito que conseguir a resposta pq já tive experência de estar dos dois lados da moeda, um como profissional CLT e outros como profissional independente e para cada uma experiência eu tinha que pensar diferente, agradar o cliente como CLT é bem diferente de como agradar o cliente sendo um profissional independente.

Como funciona?

Ser CSM não é muito difícil, basta fazer um curso por um CST e no final responder média de 36 questões enviado pela ScrumAlliance. E assim você é um Certified Scrum Master.

E as questões?

Essas questões são para avaliar o CST, se a turma tiver um percentual muito baixo, à ScrumAlliance, vai chamar o CST para uma conversa, pois houve um problema no treinamento por parte dele.Isso é muito díficil, a maioria dos CST são experientes e passar o conhecimento não é um problema, uma vez que um CST já foi um ScrumMaster um dia e possivelmente na longa jornada dele, teve que passar conhecimento para um grupo, sendo assim ministrar o treinamento, não é algo do outro mundo. Nenhum CST que ter uma média ruim, pelo contrário ele vai se esforçar o máximo para que seus alunos tirem a maior nota possível.O objetivo das questões é para o aluno saber se ele entendeu o mínimo possível de Scrum, isso acaba sendo uma auto-avaliação para o próprio conteúdo, uma vez que as questões é direcionando a tudo que foi visto no curso e com algumas pegadinhas como de lei em qualqer exame.

E pra que serve essa certificação?

Apesar de ser criticada por alguns profissionais de TI, mas há algo importante que é preciso analisar antes de criticar. São eles:

se você já tem um bom nome no mercado onde você é o valor da sua empresa em si. Não vai precisa de certificação nenhuma. Exemplo? Pessoas como Eike Batista, Steve Jobs esses caras por exemplo podem abrir uma empresa amanhã e ela já começa com um valor X somente porque eles são os dirigentes e seus clientes não querem saber se a empresa dele tem profissionais certificado YHY. Pois, a confiança é depositada tneles e quem deposita à confiança conhece o perfil de cada um desses caras e sabe o nível de qualidade e não precisa de nenhum órgão para testar isso, pois eles por si só são os órgãos.
Agora em outro contexto onde está a maioria dos pobre mortais. Aquele profissional que não tem esse valor todo no mercado(como jobs e batista por exemplo) e de alguma forma precisa vender um produto para o cliente, o qual vai precisar que algum órgão mais abrangente que tem respeito no mercado diga: “esse cara tem os conhecimentos mínimos, nos o certificamos”(até você atingir o sucesso com seus clientes e sua empresa tornar referência, mas precisar desse tipo de titulo). E ai você precisa vender o seu certificado, para ganhar alguns tipos de clientes. E pra isso existe certificações, para aproximar novos clientes incertos do seu serviço. Isso é a realidade do mercado, seja aqui no Brasil ou lá fora, claro com algumas particularidades de cada país, mas é muito similar.

Em resumo se amanhã você pretende atuar como um consultor Agile, ter as certificações pode ajudar naqueles seus primeiros clientes incertos, caso você não tenho um mercado já consolidado com seu nome impresso. E nesse momento sentirá falta da certificação para jogar na mesa do StakeHolder, será seu cartão de visita.

A diferença

Isso aqui é o ponto diferente das demais certificações tradicionais.Ser um CSM não é ScrumMaster por que(meio louco isso)? Simples. Você não compra liderança, motivação de equipe,práticas de negociação etc. Você desenvolve essas habilidades e são os pontos chaves para atuar como um ScrumMaster, pouco importa se você é o cara de Java, .NET, Ruby, mas se não sabe lidar com equipe, remover as barreiras, ter um bom relacionamento, você tá perdido. Agora vem, a sensação de outras certificações como Java, algumas do PMI, que ao terminar você olha, pow estudei isso, aquilo, agora eu sei exatamente como fazer X. Já sei usar generics e entendi threads ou aprendi como calcular custo do projeto com menos erros, depois da prova PMI xxx.

Então quem for fazer certificação Agile CSM esqueça qualquer uma dessa sensação, pelo contrário você sai de lá com mais dúvidas, confusão mental. No inicio achei meio estranho, porém passar um ou dois dias achei que isso um ponto excelente e chave, pois fiquei motivado em ir buscar resolver aquelas confusões que estavam na mente, tirar aquela barreira e para isso tinha que estudar mais, aumentar o faturamento da amazon.com etc, mandar e-mails para os mais experientes (até para o Mike Cohn eu enviei). Algo que nas certificações tradicionais não acontece, após ter passado, temos a falsa segurança que dominamos o assunto e nem abrimos mais o livro de estudo e dai começamos outra jornada na carreira e com um certo tempo começa o esquecimento caso não use com frequência o conteúdo que viu na certificação.

O treinamento

São dois dias de treinamento, onde é abordado os pontos core de Scrum, desde conceitos: teóricos, práticos e cases. Há muita discussão e aprendizado nesses dois dias. Não é um curso comum, o aprendizado é grande e muito valioso. Sabe por que? Vou responder a seguir.

A sacada da ScrumAlliance

É fácil criticar quando não conhecemos, mas a ScrumAlliance fez algo que achei interessante. Para ser um CST não é para qualquer um. Ou seja, só quem teve e tem vivência pratica Agile pode ser um CST. E isso garante que o conteúdo do curso será com um profissional que tem conhecimento e experiência de fato com projetos Agile. E isso enriquece todo o curso de uma forma que é difícil descrever. Muitos criticam que na maioria(há exceções) das faculdades temos professores “doutores/p.h.d” porém que nunca tiveram experiência profissional e que o curso só fica no meio acadêmico e ao chegar no mercado o aluno ver que a coisa é bem diferente, do que ele viu em sala de aula, já que ele não foi preparado para o mercado na sua formação. No treinamento da ScrumAlliance isso não temo como acontecer, pelo requisito de se tornar um CST.

Ao sair do curso

Bem, ao sair do curso não dar para ter a síndrome do estudante, de achar que “eu sou o ScrumMaster”. Talvez, os menos experientes possam sair com essa sindrome. A certificação não prova que você tem todo skill de ScrumMaster expert. Porém, é esperado que o aluno tenha o conhecimento suficiente para rodar uma Scrum, porém isso não quer dizer que ele vai conseguir rodar bem ou a melhor Scrum do mundo. No curso você percebe se é aquilo que de fato que deseja para você. O framework Scrum deixa transparente o papel e o que um SM vai viver no dia-dia sem maquiagem.

Compensa?

Essa é uma pergunta que muitos fazem. Bom, responderia dizendo que sim. É um bom curso, com aprendizado diferenciado, como falei baseado em experiência e case, e não só formado por conteúdo teórico. É como o meu CST(Michel Goldenberg) falou : “se fosse teórico e explicar o que já tem no wikipedia, ninguém precisava estar aqui, pois tem tudo isso de graça”.

Valor do investimento

R$ 1950.00 (só à vista)

É isso que você vai ter que investir. Não posso dizer que é um valor do tipo “trocado”. A única coisa que invisto sem estar muito preocupado é no conhecimento, então nunca vejo um investimento em conhecimento como perdido. Mesmo se um dia fizer um curso que for ruim(já fiz r não foram poucos), eu vou conseguir aprender algo com ele, do lado negativo sempre dá pra tirar algo de positivo para o seu aprendizado, mesmo que não seja no conteúdo do curso.

O mercado

Como o mercado vê essa certificação?

Da mesma forma que ver as demais, talvez essa aqui ainda pior, porque um dos problemas ainda existe em quem analisa é saber interpretar e conhecer como é o curso e como ele qualifica o aluno e parar de olhar para um “pedaço de papel”.

Conclusão

Foi um curso muito produtivo, conheci pessoas diferentes, o Michael é de fato um cara muito experiente e com uma boa didática. Ele fez o que pouco fazem, ensina o porque das coisas. Como eu não sou muito preso a esses papeis de parede, faria o curso mesmo sem certificado, não estou muito preocupado com ele, exceto se eu precisasse vender para um cliente que gosta de ver esses titulos in english de preferência. A minha conclusão é que as certificações da ScrumAlliance elas foram pensandas mais para quem quer atuar independente, ou seja, não ser funcionário, uma vez que o a forma que é aplicada, não deixa o pessoal do RH feliz para o que eles precisam como criterio de avaliação.

Bom vou ficando por aqui espero ter esclarecido sobre a certificação CSM. : )

Abracos, see ya next post!!

TDD:O seu primeiro TDD em Java

olá Pessoal,

Mais um post da śerie Agiile.Hoje veremos como escrever o seu primeiro TDD em Java (não é “o meu…”, pq este já fiz rs ), na semana passada eu dei um overview dos principios de TDD, nessa vamos praticar da maneira mais simples de ser. No próximo post, mostrarei como faço TDD hoje, após de algumas “aulas” com o Kent Beck e o dia-dia fui aprimorando.Mas, não poderia de fazer um post para quem está no 0x0 do primeiro tempo :). (não sei pq,mas eu adorei a imagem que temos no inicio do post, passo horas olhando pra ela hehe)

lets go…

O foco

O foco aqui é poder compartilhar com vocês de modo prático como foi que aprendi TDD. Pois, ainda há muitos programadores que não conseguem entender o uso, ou usar no dia-dia(claro que há exceções onde TDD não se aplica ,porém quando aplicamos este já comprovou que os resultados são indiscutíveis).

O Exemplo

Antes de tudo vou buscar ser bem direto ao foco do post e todo o conceito TDD será deixando de lado blz? Qualquer dúvida da uma passada no primeiro post ou no velho Google.

O nosso exemplo é o algo muito comum e escolhi ele, porque eu lembro como se fosse hoje, que foi a partir dele que o mundo Agile marcou minha vida profissional, pois foi onde conseguir a dar meus primeiros passos ao desenvovimento guiado por testes.Sendo assim,resolvi usá-lo aqui no post. (não é nada chique, desde da faculdade, o que mais vemos é algo como RG, CPF, Locadora ,Estoque etc). Porém, o objetivo aqui não é saber se você sabe validar um RG,CPF,CNPJ, Locadora etc. E sim se consegue desenvolver usando TDD.

Não esquecer

TDD não é apenas criar unit tests e sim ter testes inteligentes, ou seja, automatizados o suficiente para gritar quando alguém quebrar alguma regra. Outro detalhe não é pq são unit tests que você escreve de qualquer forma, é code então os principios são os mesmos utilizados no código funcional(não sei porque tem gente que separa isso, até hoje não entendi o motivo), na verdade quem desenvolve utilizando TDD tem um carinho enorme com seus testes, pois sabemos da importância deles durante o desenvolvimento e na manutenção. Já vi perguntas do tipo:

– pq não coloca tudo em um teste só? (será que precisa responder o motivo?)

– o que é um bom teste? (essa foi uma boa pergunta)

Primeiro que não há receita de bolo, mas um bom teste ele sempre tem um perfil parecido, grita de forma eficiente, ou seja, não grita por qualquer coisa que mudou, só grita quando algo que ele testa de fato mudou. Qual a diferença? Muita, há testes criados que tem varias responsabilidades e isso já passa ser um problema maior. Daí algo mudou e ele falha, mas a falha daria um novo teste especifico, mas o desenvolvedor que só escreve teste por escrever ou pq é mandatório no projeto, e importante que o teste esteja lá como métrica.

Enfim, Um bom teste deve ser especifico e rápido, assim vc pode executá-lo várias vezes.Isso é algo primário que precisamos ter em mente ao construir nossos testes.

Praticando

No exemplo a seguir temos uma aplicação que faz a “validação” de um nro de uma carteira de identidade. Este é um start-up para você ficar brincando após brincando após a leitura, mas terá que ser persistente e ir mais adiante para olhar o que tem após omuro. Se não fizer foi ai onde quase todos desistiram.

Primeiro passo

Escrevemos a classe de teste e já fizemos o teste para os possíveis RG inválido/válido.

public class RGTest extends TestCase {

private RG validarg = new RG();

publicvoid testIsValidaRG(){

assertFalse(“retorna FALSE – inválido RG”, validarg.isValidaRG(“128641011”));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(null));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(“”));

assertTrue(“retorna TRUE – RG válido”, validarg.isValidaRG(“128640-28”));

}

Se for executado vai falhar porque não temos a classe principal “RG” que precisamos implementar. A falha anterior é de compilação, caso você execute.

public class RG {

publicboolean isValidaRG(String rg){

return false;

}

Segundo Passo

Agora precisamos testar e ver se vai falhar, pela teoria deve falhar.

O motivo da falha é que o método isValidaRG(String rg) sempre retorna false, então, nosso teste não está funcionando 100%. Pois, precisamos ter um nro de RG válido.

Terceiro passo

Fazer o teste funcionar, precisamos resolver o problema de ter um RG válido, para isso precisamos alterar o método da classe principal.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}

return true;}

Agora estamos validando, os nossos assertXXX da classe teste.

O Bug

O código abaixo passa no teste, observe que não há nenhuma regra validando letras, e sabemos não existe RG com letras. Precisamos criar um teste para isso. E resolver o bug

assertTrue(validarg.isValidaRG(“abcdefgh-ij”));

Quarto passo

criamos um método na classe RGTeste para testar se de fato nossa aplicação NÃO aceita letras, mas pelo resultado abaixo, vimos que aceita, uma vez que o método retorna TRUE, já que não há nada que proíba as letras na classe principal.

//criando um novo método para testar letras

publicvoid testIsValidaRGLetras(){

assertFalse(“retorna FALSE – inválido letras RG”, validarg.isValidaRG(“ABCDEFGH-IJ”));

assertFalse(“retorna FALSE – Inválido letras RG”, validarg.isValidaRG(“G3X8Xopa-22”));}

Quinto passo

Precisamos agora alterar isso no código principal, para testar que letras não podem passar pelo metodo.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}//fim do if

for (int i = 0; i < rg.length(); i++) {

if(i!=8){

char posicao = rg.charAt(i);

//senao for umdigitoretorne false

if(!Character.isDigit(posicao)){

return false;

}}

}return true;

}

Ambos testes passaram, assim sabemos que a validação de RG está correta, até agora. Porém, o que devemos observar que nessa mecânica, fomos escrevendo o nosso código com base nos resultados dos unit tests primeiro e não fazer o inverso. É obvio que falta muito trabalho ainda até termos um RG realmente válido e inválido, mas lembre-se que o básico de TDD é querer fazer a barra verde chegar o quanto antes com o menor esforço possível, é um tal de baby-step. É comum, queremos implementar logo a parte complexa do código, querendo fazer as validações possíveis etc. Mas, é ai que o terreno está propicio para nascer os bugs mais terríveis de nossa vida e só saberemos quando o cliente abrir. Encontrar bugs em modelo como waterfall não é uma tarefa fácil, não é a toa que o custo de manutenção nesse modelo é alto. Lembre-se que devemos desenvolver algo que qualquer outro desenvolvedor possa entender no menor tempo possível, e TDD possibilita isso, eu particularmente, quando pego um código feito com TDD olho primeiros os testes. Os testes sãos os guias que precisamos. :).

Meu case

No exemplo do post vimos como usar TDD, quando iniciei meus estudos nunca parece vantagem (acho que você deve está com esse sentimento também), olhando apenas a execução e o resultado. Mas, confesso que só conseguir ver a essência de TDD em partes diferente do projeto, uma quando precisamos alterar algo, e manter os testes passando, ou quando recebia novos requisitos e tinha que implementar e criar mais testes, ai vi agilidade em pratica e ficando viciado, sem falar que todo time fica feliz, pelo tempo gasto na manutenção, TDD de fato dar contribuição dele na manutenção de software. Fora que com o tempo vamos vendo o quanto TDD ajuda na construção do nosso design. Daí passamos a ter um tal de design incremental.

Espero que tenham gostado do post, vou ficando por aqui, até o próximo post.

Abracos, see ya!!

TDD:Os principios de TDD para iniciantes

TDD

olá Pessoal,

Esse post está preparado desde de 2010, porém vinha postergando, por falta de tempo para organizá-lo. Mas felizmente chegou o dia. O objetivo que estarei compartilhando a minha experiência que venho tendo com TDD há pouco mais de um ano e confesso que cada vez que preciso fazer um novo código eu vejo que mais preciso aprender a criar meus unit tests. É inacreditável como TDD é algo bem dinâmico, a ação sempre é a mesma de escrever os testes primeiro, mas cada teste sempre traz um desafio. E isso é um estimulante dos fortes. Eu adoro isso. Sem falar que com TDD nos força a se envolver mais e mais na área de negócios, pois quanto mais entendemos mais fácil fica escrever os testes. vou apresentar alguns princípios básicos sobre TDD para quem está querendo fazer sua primeria app Java com TDD e em outro post, vamos colocar mão na massa.

Outra novidade que a partir de hoje, estarei dando inicio à série de post Agile com base em experiências e estudos que venho adquirindo nessa longa jornada que terei com Agile. E espero através do blog ir compartilhando isso com vocês, uma vez que que venho advogando Agile no desenvolvimento de Software ultimamente.Além deste ser é um dos objetivos na minha carreira. Além, disso quero poder ajudar os iniciantes que tem dúvidas sobre o mundo Agile, sem falar na quantidade de siglas que no inicio é um pouco confuso para os iniciantes: TDD, Scrum, XP, DDD etc.Eu tive dificuldades, barreiras (não é que agora não tenho mais, porém são outras rs, aprendizado é base de Agile)e tentar ensinar alguma coisa para quem está precisando só de um empurrãozinho para vim fazer parte do Agile Team é algo que sempre gostei de fazer aqui no blog e não será diferente com Agile.

Espero que gostem . 🙂

Lets go…

Outros Post:

Agile

Starting…

No TDD você desenvolve os testes do software antes mesmo de desenvolver o software(eu chamo de code core). Para cada “peça” da aplicação que é construída uma série de testes são escritos ANTES do desenvolvimento para garantir que a aplicação funciona como deveria funcionar.

Na pratica, quando você termina os testes, terminou o desenvolvimento principal e está seguro que aquela classe faz o que se espera.

A crença do iniciante

Todo mundo que inicia com TDD, nos primeiros passos fala:

“meu deus, que coisa mais chata e ainda dar mais trabalho, pra que diabos eu vou criar uma nova classe com metodos, se eu poderia fazer um método único( main) com todos os possíveis erros e ver no console o resultado com System.out.println!?”

Bem, eu devo confessar que pensei assim também, pois tive resistência ao uso TDD logo quando fui apresentado ao sr. TDD Master. Um dos pontos era esse:a impressão que dar mais trabalho escrevendo os métodos testes(unit tests).Isso era algo que eu não conseguia entender.

O ponto 2 era pensar nos testes e que eles fossem especificos para cada situação, era outro ponto difícil, pois não conseguia pensar que tipo de case criar, uma vez que não tinha o código core pronto.

Superação

Com persistência e coragem fui superando o “novo ambiente”, é normal termos resistência ao que é novo, e o que motivou foi o seguinte ponto: “o mercado usa, os caras mais punks(Martin Fowler, Kent Beck, Guilherme Silveira, Paulo Silveira, Rodrigo Yoshima etc) defendem o uso, e põe em pratica, e porque eu não devo usar?Eu estou errado ou o mundo está errado? Será que eles também não tiveram os mesmos problemas?”. E daí fui em frente e virei um TDD-Viciado, não consigo mais fazer uma aplicação por mais simples que seja sem TDD, é muito bom ver o sinal de “Vermelho” e “Verde”, um dizendo que preciso fix algo e outro dizendo que o meu fix foi aprovado. E o mais divertido quando uma regra de negócio muda, quebram algum teste e aí eu sei: “mudaram o código, que regra mudou?”.

Antes de TDD

Antes de TDD, eu achava que tinha entregue um programa como foi solicitado, mas não durava muito tempo lá vinha a pilha de bugs pelo pessoal de QA, e a maioria era em algo que não implementei, ou que achei que estaria funcionando corretamente, mas na verdade não estava. Um exemplo, prático que lembro no projeto do ano passado é que o usuário esperava a partir de ação receber o CPF e acreditei que o método retornaria de fato este valor para ele, mas na verdade vinha um null e quando fui ver em algum lugar lá esqueci de passar o valor de um atributo do objeto para o método responsável.A moral aqui que para saber, tive que debugar, e isso consome tempo.

Com TDD isso ainda pode acontecer, a diferença é que o objetivo é diminuir esse risco, de quando entregarmos algo com TDD estamos seguro que estamos entregando a coisa certa com o risco menor. O problema na minha época pré-TDD é que o tempo de manutenção não era tão curto como esperado, pois eu não sabia onde estava o erro e tinha que usar o debug do eclipse até encontrar. Li em algum lugar que o “debug” deveria ser removido do Eclipse para alguns projetos. Só não lembro quem falou isso agora. hehe.

Os princípios fundamentais que devemos ter ao adotar TDD :

– escrever TESTE da implementação ANTES de escrever code core;

– escrever apenas código suficiente para o TESTE possa se contentar com isso(controle sua anciedade);

– escrever TESTE pequenos, testando a menor quantidade possível de código de cada vez;

– escrever TESTE rápidos(não é programar rápido e sim tests que rodem rápido, em milisegundos).

O ciclo de vida TDD(veja a imagem no inicio do post)

1.criar o teste

2.executar todos os possíveis testes e ver aplicação falhar(barra vermelha no junit);

3.escrever aplicação a ser testada;

4.executar os testes para ver se todos passarão;

5.Refatorar – refactoring;

6.executar os testes novamente e garantir que eles continuem passando(principio de refactoring)

Pq adotar?

necessidade de manter compatibilidade retroativa;
baixa cobertura de testes unitários;
design pouco testável

Tipos de Testes

Teste unitarios

testam apenas um componente do sistema.

Ferramentas: Junit, Jmock
Fundamental para prática do TDD

Testes de Integração

testam integração entre componentes que envolve dois ou mais. Ex.: classes + SGBD

Ferramentas: Junit, DBUnit

Teste de Aceitação:testam uma funcionalidade ou caso de uso e envolve vários componentes do sistema.

Ferramentas: Junit, Selenium

Pode ser usado em TDD

Consequências

testes podem ser feito na IDE
Não há necessidade de fazer um deploy da aplicação para execução dos testes ;
bugs são encontrados com mais facilidade e corrigidos com maior velocidade;
bugs comprovados por testes unitarios (barra vermelha na tela);
código mais estável, pois estimula um melhor design;
facilita a técnica de refactoring;
evitar o “overdesign”, ou seja, só escrever código suficiente para o teste passar ;

Pontos de Reflexão

Há pessoas que são contra ao uso de TDD, Agile etc. Dizem que isso é coisa de “pensadores” e que não existe “bala de prata”. Mas, eu não sei de onde vem o “bala de prata” e fico as vezes assustado como essas pessoas não sabem fazer interpretação. Não há lugar nenhum escrito que TDD, Scrum, XP são bala de prata. Porém, essas pessoas deduzem isso. Hoje particularmente não discuto mais sobre o assunto com essas pessoas, simplesmente ignoro a discussão (e não à pessoa 🙂 ).

Mas, por que faço isso?

Antes, eu até tentava discutir (normal entre profissionais de TI) e mostrar que não é isso que os Agilistas tem em mente, mas era difícil e tentar mudar as pessoas é algo praticamente impossível. E um dos princípios que incorporei como Agilista foi “aprendizado” e tive que aprender, que não podemos mudar as pessoas.Depois disso vivo mais feliz, com menos discussões que não terão resultado no final.

Outro problema os bugs

Quem desenvolve com TDD sabemos que é possível desenvolver com zero bugs ou algo próximo de zero, e quando é encontrado o custo de manutenção é relativamente baixo com relação ao que já conhecemos no dia-dia. Porém, você vai encontrar alguém dizendo por ai: “Bugs fazem parte do desenvolvimento de sistemas, todo sistema tem bugs”. De novo, não estamos dizendo que um sistema não tem bug, o problema maior não é ter, e sim como resolver, daí eu pergunto quanto custa fixar um bug?

E qual o nível desse bug ou bugs?

Você já precisou parar um Sprint por causa de bugs?(a resposta para o Sim, vem logo adiante)

Então você tem um problema sério na qualidade de como o seu produto foi desenvolvido. Se você tem uma pilha de bug, que impacta o desenvolvimento, então a coisa é muito séria concorda? Pois, bloqueou todo o ciclo do produto.

Conclusões

colabora para o aumento da qualidade dos sistemas;
software cresce de forma ordenada e com qualidade design ;
software se adapta com mais facilidade à mudanças ;
Ninguém falou que Agile é a bala de prata;

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

abracos see ya!

TDD:Minha primeira Experiência TDD

olá Pessoal,

No post de hoje é compartilhar com vocês minha primeira experiência com TDD de forma mais corporativa onde tinha que entregar algo de fato(e sair dos tests made in house).Para quem acompanha o blog, meu twitter sabe que venho estudando e se envolvendo cada dia com o mundo Agile. Como toda primeira experiência nunca sabemos como será o resultado,uma vez que não nada de background para aquele contexto. Talvez podemos falhar ou ter um sucesso do tipo “aceito”. E para sabermos disso precisamos apenas de coragem(não esqueça dessa palavra quando tiver trabalhando com TDD) e deixar o medo de errar de lado. Foi assim, que começei meus “baby-steps” com TDD. O que aprendi de cara foi: “uma coisa é usar TDD em seus projetos pessoais at home, e outro quando vamos para complexidade que temos no mundo de um negócio real, são experiências muito distante, porém se não tivesse feito aquela experiência caseira, o impacto seria maior”.

Vamos ver o que rolou…

lets go…

Cenário

Surgiu uma nova feature no projeto e teremos que implementar, e daí cai isso na minha mesa(sempre acontece isso no desenvolvimento de software certo?). O escopo, design, desenvolvimento etc. Tudo isso é responsabilidade do engenheiro/desenvolvedor/analista/arquitetos etc encontrar uma solução para a tal feature. Alguem precisa dela done no prazo X , dentro dos criterios de aceitação YXZ.

Minha Experiência

Normalmente um produto tem muitas features, no inicio gera uma pergunta: “Por onde começar?” “qual a melhor feature implementar por agora?” Selecionei a mais simples. Antes eu poderia ir logo na mais que aparentava difícil, mas com TDD eu precisava fazer de forma mais simples possível, desde que saisse do vermelho para verde. Daí começei a criar os units tests para uma determinada classe, pensando nos problemas, principalmente aqueles esperados, as exceções que deveriam acontecer quando o contexto fosse ZX. E foi assim que começei, da maneira mais simples e “boba”, a medida que ia adicionando novas features e o código mudando, os tests mais simples failure e isso era bom, porque sabia que uma nova feature que foi implementada, fez meu código quebrar e eu fiquei sabendo disso o quanto antes e agora devo fixar para poder ir adiante. Então esses feedbacks rapidos foram cruciais, pois não esperei até o deploy acontecer e o pessoal de QA abrir um bug 🙂

Para saber o que precisava ser feito, fiz um BillBoard, com as tasks(to-do), o que está sendo feito(in progress), e o que foi feito – Done (faltou uma coluna com blocker). Assim podemos manter o foco e saber de fato do que estamos fazendo e ajuda até dar um bom status nas scrums com o team.

O resultado

Resultado veio além do esperado, no inicio gastei bastante tempo com o units tests e seguindo os conceitos da metodologia, porém ganhei mais velocidade lá na frente e principalmente na semana final, pois tinhamos code clear(TDD ajudou identificar onde deveria refatorar), units tests fazendo boa cobertura e testes rápidos.

A moral da história que ganhei 2 dias free, pois conseguir entregar antes do deadline, com um bom tempo sobrando para fazer qualquer coisa, e o melhor de tudo a segurança que os criterios de aceitação daquela feature estava sendo alcançada com o menor esforço possível(não foi necessário dar aquelas esticadas de 2-3 hrs após o expediente). Então feature accepted, good cobertura de code e code clear. Tudo provocado por algo chamado TDD. Observem que nada disso foi planejado, era apenas entregar a feature, mas por consequência do destino, TDD trouxe vários outros beneficios de forma indireta ao desenvolvimento.

TDD não é a solução para todos os problemas que temos no desenvolvimento de software, não passa de uma metodologia que depende como está sendo aplicada ao projeto, e o mais importante pessoas etc. Se as pessoas envolvidas não estão nem ai, e não acreditam já entramos perdendo no jogo.

Eu faço uma associação bem abstrata para quem não entende TDD com aquelas metodologias que aprendemos na faculdade de como fazer o seu TCC, sabemos que só a metodologia não vai fazer o seu TCC, você vai precisar entender do assunto que deseja escrever, e começar a usar a metodologia para ti guiar como terminar aquilo da melhor forma possível e saber quando acabou ou quanto falta para acabar. E o melhor se vai dar tempo de entregar dentro do prazo (basta olhar o seu burn down chart do TCC rs).

Um livro que eu deveria ter lido, antes de ir para minha primeira experiência profissional com TDD era o do Kent Beck, mas não tive tempo, pois foi um challenge que surgiu em questão de poucos dias e daí tive que usar os materiais que já tinha em mãos e li bastante artigos, post da galera mais expert: Guilherme Silveira, Philip Calçado, Rodrigo Yoshima, Guilherme Chapiewski há alguns post e palestras legais no InfoQ. E o que não deu pra ver ler, teve que ser visto na pratica com erros e acertos.

Vou ficando por aqui, e espero que tenham gostado do post, não deixe de compartilhar como foi sua primeira experiência com TDD, ficaria feliz em ler outros cases. O objetivo do post, é mostrar para aqueles que estão na dúvida do uso de TDD, para saber de fato se funciona, tem que colocar mão na massa, o máximo que você vai descobrir no final é que TDD não atendeu aquele contexto que você tentou validar.

Abracos, see ya!!