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!!

Scrum: Lidando com estimativa e escopo com o cliente


Olá Pessoal,

Firme e forte na série Scrum. Hoje vamos ver como lidar com estimativa e escopo com o cliente, quem aqui não teve aquela solicitação do cliente: “será que não dar para diminuir um pouco a estimativa?”. Mas, nem sempre dá, porém o cliente sempre insiste. Então como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? Veremos a seguir.

Lets GO…

 Lidando com estimativa e escopo com o cliente situação comum e esperada

 Quem nunca passou pela situação a seguir? Não necessariamente com cliente apenas, mas com gerente de projetos, arquitetos etc. Se tua estimativa está alta na visão deles, é capaz, de presenciar um infarto rs ;).

Note: Estimar não é uma tarefa fácil, envolve vários fatores o quanto o time conhece as tecnologias, o produto, a experiência profissional, e os mais recentes chegados na equipe terão dificuldade em estimar inicialmente, pelos fatores citados anteriormente sendo assim o ScrumMaster deve auxiliar os novatos dando um coach na estimativa.

“O cliente diz, eu sei que você tem uma equipe técnica qualificada, com os melhores profissionais, será que não dá para diminuir um pouco a estimativa?”

Nesse caso o cliente está usando a qualidade interna, (aquilo que ele não ver) como fator para reduzirmos à estimativa, mas ele não quer diminuir o escopo. Claro que não permitiremos isso, sacrificar à qualidade interna na maioria das vezes (para não dizer sempre) é péssima idéia, lembre-se disso: “uma vez que se permita que uma base de código se deteriore, é muito difícil recuperar a qualidade mais tarde”. Não conte com refactoring, pois fazê-lo depois de tudo há um custo e nem sempre o cliente vai querer pagar por isso. Mas, como responder ao cliente a pergunta acima?

Uma das formas de responder é tentar convencê-lo de reduzir o escopo para algo mais especifico e remover aquela parte avançada, que normalmente vai virar uma nova estória que pode entrar no próximo Sprint. Um exemplo:

Se o cliente quer que todas as mensagens iterativas com o usuário sejam exibidas, por que não implementar as mais importantes e aquelas com menos importância deixar para um futuro, ou seja, aquelas que não causam impacto no entendimento ou funcionalidade da aplicação, podem ficar para os próximos Sprints. Outra situação é que ele quer um WebService para aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo e com base no escopo atual do WebService. A missão agora é convencer o cliente diminuir o escopo caso ele queira ver algo de WebService pelo menos iniciado no Sprint corrente.

Sei que não é uma tarefa fácil convencer o cliente disso, mas se ele está envolvido com o time e Scrum, ele sabe dos problemas que pode ter se tentar ir além da capacidade de entrega da equipe, é por isso que o PO não dita o que deve entrar no Sprint. É a equipe que vai pegando os itens até chegar no limite. Então qual a solução? Negociação e validar o escopo com o PO, essa é a forma mais adequada para não afetar a qualidade interna do produto, alguém uma vez disse em algum lugar que a qualidade não é negociável.

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

Abraços, see ya!!

Scrum: Fim do planejamento do Sprint


Olá Pessoal,

Hoje vamos lidar com o fim do planejamento do Sprint(Sprint Planning), estamos chegando ao final da reunião e ainda não definimos muita coisa, talvez a equipe perdeu o foco por algum momento e o ScrumMaster não trouxe a equipe para o objetivo principal o quanto antes  e agora temos um problema, como resolver? Aposto que alguns não podem gostar da resolução, mas eu tomei já esse remédio amargo quando alguém tomou a decisão que veremos a seguir.

Let GO…

Fim do planejamento do Sprint

Se chegar ao final do planejamento do Sprint e está faltando muita coisa a ser definido o que fazer?

Opções:

  1. Remarcar para o dia seguinte por algumas horas
  2. Esticar mais um pouco o planejamento do dia atual?

A opção 1 poderia ser boa e a primeira a ser pensada. Porém, um dia a mais de reunião pode ser ruim, pois a equipe já está ansiosa para começar e não agüenta mais horas de reuniões. Então uma esticadinha? Você acha que resolveria todos os problemas com algumas horinhas a mais e todos já querendo ir embora? A melhor escolha e pode ser radical é começar o Sprint do jeito que está, é isso mesmo vai começar do jeito que conseguimos chegar até o final da reunião, pois a equipe precisa aprender com uma lição que todos vão receber ao término do Sprint.

Será um Sprint sofrido, mas na próxima todos saberão da importância do planejamento do Sprint. Acredite isso funciona!

Ter um objetivo para o Sprint é requerido, melhor ter um do que não ter, pois todos vão saber o porquê estão ali, e este objetivo deve ser em termos de negócio e não técnico (tome cuidado com isso), assim qualquer um de fora da equipe, possa entender. Caso tenha dificuldades em escrever o objetivo do Sprint, basta responder a pergunta:

  • “Por que não saímos de férias ao invés de fazer esse Sprint?”
  • “Quem se importa com esse Sprint?”
  • “por que estou aqui?’

São perguntas que devem ter sido respondida até o final do Planejamento do Sprint. Enfim,  final de planejamento de Sprint é final, busque maximizar o uso bem do tempo que tem e evite que a equipe venha perder o foco do que precisa ser feito. Mas, sabemos que isso é o que queríamos no mundo ideal, e nem sempre vivemos no mundo ideal. De qualquer forma teremos que lidar com situações desejáveis e as indesejáveis no dia-dia.

Vou ficando por aqui, até o próximo post da série. Espero que estejam aprendendo um pouco de Scrum.:)

Abraços, guys!

Scrum:Reunião de Planejamento Sprint

Olá Pessoal,

Vamos para mais um post da nossa série Agile/Scrum. Hoje veremos o que acontece na reunião de planejamento, umas das reuniões mais importantes de um projeto Agile com Scrum.

Lets GO…

Note: somente para ter certeza que você sabe o que é um Sprint, abaixo coloquei a diferença entre Sprint e product backlog , é comum para quem está chegando agora, fazer confusão entre um e outro.

Sprint: quando falamos reunião para o Sprint ou o famoso Sprint Planning, estamos dizendo: “bem vamos planejar o nosso trabalho, para não ficarmos coçando”.

Product Backlog(PB): Aqui não é um planejamento oficial, mas é feito normalmente pelo PO e o ScrumMaster, depende mais do PO, pois é ele que vai montar o PB.

Reunião de Planejamento

Chegou o dia da reunião de planejamento, onde é um momento bastante crítico e o mais importante, pois é dai que vai sair todo o trabalho para a Sprint que inicia amanhã e também saberemos o que será feito e quando devemos entregar. O resultado do encontro de planejamento do Sprint deve ter:

  • Um objetivo do Sprint (o que pretendemos entregar?);
  • Os membros da equipe (quem vai trabalhar conosco? Quantos profissionais eu tenho? Todos full time?)
  • Um backlog para o Sprint (uma lista de estórias do Sprint que vem do product backlog)
  • Data de apresentação do Sprint (a demo do que está sendo entregue)
  • Data e local das reuniões diárias (daily scrum, recomendado sempre manter o mesmo local e horário)

É nessa reunião que o time faz as estimativas com os itens priorizados pelo PO. Então o time pega o primeiro item que está no product backlog e analisa, se tiver pergunta para o PO, o que ele quis dizer com o ponto X na story, a hora é essa.

Como saber quantos pontos uma story vai receber na estimativa?

Pontos = Nro pessoas * dias

Ex.: 2 * 5 = 10 pontos.

Então estou dizendo que se eu tiver duas pessoas trabalhando na primeira estória do product backlog por 5 dias, isso custará 10 pontos. O importante é não estimar em horas, e sim em dias, o motivo é que sabemos que não trabalhamos 8hr com 100% de foco, paramos para ver o nosso e-mail pessoal, tomar um café, visitar as redes sociais etc. A pergunta que deve ser feita nesse caso é: “Zezinho, se você pegar essa história em quantos dias você entrega?” Zezinho responde: “pelo que entendi, dá para fazer em 4 dias”. Então temos o total de pontos igual 4 (pois, Camilo vai trabalhar sozinho naquela estória).

Algumas equipes usam fibonacci para estimativa da estória(estimate story). Eu gosto dessa forma, assim eu consigo estimar comparando com outras stories. Usar a idéia de planning poker é boa, assim buscamos garantir que cada um fez as estimativas sem sofrer influência da estimativa de outros colegas.

Planning Poker

É uma técnica utilizada em times Ágeis com o objetivo de evitar opiniões por senso comum nas estimativas. Mas se as equipes estão longe geograficamente? Dai os membros remotos enviam suas estimativas via chat privado para o ScrumMaster.

Como funciona?

*se puder compre o baralho Agile, do contrário use os dedos. ; )

A pessoa que apresentar o menor número deve explicar porque é fácil e o que apresentar o maior número deve explicar o porquê é difícil. A jogada só termina quando o time entra em um consenso.

Por hoje está bom, nos próximos post falarei da importância do PO no planejamento do Sprint e o que fazer quando chegar no fim do planejamento do Sprint.

Espero que tenham gostado do post.

Abraços, 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.

  1. Ferramentas: Junit, Jmock
  2. 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!