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: A importância do Product Owner no planejamento do Sprint

Olá Pessoal,

Mais um post da semana seguindo o ritual da serie Agile/Scrum ;). Hoje vamos ver a importância do Product Owner no planejamento do Sprint. A pergunta é: O quanto é importante a presença desse camarada? Vamos descobrir.

Lets GO…

Product Owner no planejamento do Sprint

Sem o product owner na reunião de planejamento não há Sprint. O PO é a chave para o inicio de qualquer Sprint, Há três pilares importantes: escopo, estimativa e importância. O escopo e importância são do PO, mas a estimativa fica com a equipe. Como a reunião começa com os itens mais importantes, se a estimativa for diferente do que o PO pensou isso pode fazer ele re-pensar no nível de importância, o mesmo pode acontecer com a equipe, se o escopo mudou a  equipe deve re-pensar nas estimativas novamente. E assim cada parte envolvida responde as mudanças e se adapta a elas.

Se o PO não puder aparecer este pode nomear um intermediário, com os poderes de exercer o papel de PO, mas se não houver o PO o lançamento do Sprint é adiado até a disponibilidade dele. Quando falei, de uma pessoa representar e ter poderes de PO como intermediário, isso não é só ter a pessoa como alguém presente na reunião de planejamento e sim com permissões de mudar níveis de importância das estórias, escopo etc. E uma vez definido o intermediário, o Product Owner oficial não poderá alterar tudo que foi feito pelo seu intermediário após já ter dado inicio ao Sprint (claro que há exceções se as mudanças forem com base nas regras de negócio, mas o fato da mudança não pode ser com base porque o Product owner enviou um intermediário). Mas, se o PO Oficial resolve mudar tudo, então voltarmos à ter um novo planejamento do zero e jogamos fora tudo que foi feito e acabamos desperdiçando tempo, porém de quem foi a responsabilidade?!. Atenção deve ser tomada aqui, pois há product owner que pode enviar um intermediário somente para iniciar de imediato o Sprint, pois ele já sabe que sem um representante nada inicia, mas depois vai querer mudar tudo e como sabemos isso vai ferrar o Sprint e ninguém quer isso. Deixe transparente, que se mudar tudo, haverá um re-planejamento.

Há dois tipos de qualidade em projeto Agile que são extremamente importantes:

  1. Qualidade externa: aquela que o usuário tem acesso, como a interface, o design.
  2. Qualidade interna: aquela que é da equipe, ou seja, como a equipe faz aquilo. Algo que tem um profundo efeito de manutenabilidade do sistema, como refactoring, cobertura de testes etc.

Claro que um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, mas um com baixa qualidade interna raramente terá uma qualidade externa alta, não dá para construir algo bom, se a base está podre. Então à qualidade interna, simplesmente não é negociável.

E assim finalizo mais um post da série Agile/Scrum, no próximo veremos como lidar com estimativa e escopo com o cliente, esse aqui sempre gera discussões nas reuniões.

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

Scrum: Preparando para planejar o Sprint

Olá Pessoal,

Mais um post curto da série Agile/Scrum que tem como objetivo de apresentar no formato baby-step um pouco de Scrum para quem está chegando no mundo Agile. E hoje vou falar de como se preparar para planejar o Sprint (Sprint Planning). Como tudo na vida, é necessário planejamento para conseguirmos atingir os objetivos e com Scrum não  é diferente.

Lets GO…

Preparando para planejar o Sprint

Antes de tudo devemos garantir que o product backlog esteja organizado (com as prioridades já definidas pelo product owner(PO)) e fechado (já com os devidos requisitos)antes da reunião de planejamento do Sprint. Em outras palavras o PO já deve ter a pilha de item que ele deseja para release, priorizado pelo nível deimportância. Se o PO não sabe como escrever as estórias o ScrumMaster deve escrever ou ensinar ao PO como escrever. Alguns times ágeis decidem convocar toda equipe para essa fase enquanto outros times deixam como opcional e prefere que o PO e SM conversem e traga os trabalhos para a reunião de planejamento.Enfim, fica à criterio da equipe.

Aqui alguns pontos que devemos considerar quando estamos nos preparando para planejar o Sprint:

  • Saber o nível de importância do que temos no product backlog, pois os pontos só são usados para classificar o item com mais importância e não o quão importante. Se criar um web service via soap tem 25 pontos e criar página de login tem 50 pontos, isso não quer dizer que criar página de login tem a importância duas vezes maior que criar um web service via soap. Se o valor fosse 26 ao invés de 25, o significado seria o mesmo, desde que fosse maior.
  • O product owner precisa saber o motivo pelo qual um item está na lista de backlog;

Então o que precisa estar claro sempre é:

  • Outras pessoas podem adicionar estórias ao product backlog, mas não podem definir o nível de importância, só o product owner;
  • Os prazos é uma tarefa exclusiva que só a equipe pode definir;
  • O Sprint backlog não é fechado, de acordo com o ritmo do time, caso sobre tempo o PO pode adicionar mais um item ou se a equipe perceber que não vai dar para entregar tudo, pode remover um item do backlog.
  • A duração do Sprint é fixa, ou seja, não é aconselhável ter Sprint com tamanhos diferentes, onde a Sprint 1 teve 2 semanas e a Sprint 2 teve 3 semanas, isso não deve existir, pois atrapalha quando vamos tirar uma radiografia de como estamos indo. Sem falar que, para calcular as próximas Sprints fica mais difícil, já que usamos as ultimas Sprints como referência para saber a velocidade da equipe para próxima.

Por hoje é só isso, pessoal. No próximo post veremos o que acontece no dia da reunião de planejamento e a importância do Product Owner nesta reunião.

Abraços, see ya!!