Publicado em

O essencial da retrospectiva !!!

A retrospectiva é o cerimônia que encerra a sprint, importante evento do Scrum , sua principal função é dar a oportunidade para que o time exercite a transparência, inspeção e adaptação.

Existem muitas formas de fazer uma retrospectiva, porém algumas ações são essenciais e determinam se a cerimônia está ajudando a entregar o que se propõe, o principal ativo do Scrum, a melhoria continúa.

Muitas vezes as retrospectivas são realizadas, e algumas disfunções precisam ser corrigidas, as pessoas do time não dividem sua opinião sobre o que aconteceu na última sprint, as questões discutidas não são registradas, não existe um acompanhamento ou controle nas retrospectivas subsequentes se alguma melhoria em relação as sprints anteriores foi alcançada.

A Retrospectiva talvez seja a cerimônia mais importante do Scrum, o time deve utiliza-la para evoluir e se tornar mais eficiente, algumas ações simples podem garantir isso.

Existem alguns softwares que podem ajudar as pessoas a se expressarem, temos algumas ferramentas a disposição como o https://app.mural.co/ por exemplo, o pessoal pode colocar o que achou bom ou ruim na restrospectiva ajudando o Scrum Master a obter as informações que são necessárias para que o time evolua como um grupo.

As saídas de uma restrospectiva devem seguir minimamente a lista abaixo:

  • O que fizemos de bom
  • O que não foi tão bem
  • Lista das ações com responsável

A lista com as ações endereçam a questão da melhoria contínua, essa lista deve ser revisitada pelo time a cada restrospectiva e juntos devem determinar se as ações deram resultado e quais novas ações devem compor a lista, sem isso não há como o time evoluir na sua forma de trabalho de maneira estruturada.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Já ouviu falar de “Planning Onion” !?

Planning onion representa os níveis de planejamento que podemos considerar durante a execução do projeto para nos organizar conforme o nível de detalhamento de cada fase, veja a seguir uma sugestão dos níveis que geram informações que dão sustentação ao nível subsequente.

Cada camada tem ações executadas seguindo seu nível de detalhamento, as ações de cada nível ocorrem em paralelo, conforme vamos seguindo o nível de planejamento fica mais específico.


O planejamento em vários níveis ou planning onion tem o conceito da realização de planejamento que retroalimenta todos os níveis conforme o projeto evolui e as ações vão acontencendo.
  • Visão do produto: são as razões do produto existir e que devem nortear todas as ações do projeto, fornece informações para o Roadmap do produto;
  • Roadmap do produto: coordena o desenvolvimento do produto estabelecendo as datas, fornece direcionamento para determinar as Releases;
  • Planejamento de Releases: determina quando o resultado de um conjunto de sprints e quais assuntos serão publicados considerando o Roadmap do produto, fornece informações para o detalhamento das Sprints.
  • Planejamento das Sprints: revela as tarefas de desenvolvimento referente a um determinado grupo de histórias que endereçarão parte do planejamento da release que está em desenvolvimento.
  • Planejamento Diário: Mostra o status do trabalho e identifica as tarefas remanecentes para que o objetivo da Sprint seja alcançada.

O planejamento em vários níveis ou planning onion tem o conceito da realização de planejamento que retroalimenta todos os níveis conforme o projeto evolui e as ações vão acontencendo.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Você sabe que é ScrumBut !?

O Scrum é um framework que oferece um conjunto de recursos para que possamos desenvolver software de uma forma mais organizada (papéis, regras, timebox e etc).

Quem nunca viu situações aonde se declara a utilização do Scrum “mas” (ScrumBut), frequentemente ouvimos aquelas famigeradas declarações:

  • Nós usamos Scrum “mas” não não fazemos daily todos os dias;
  • Nós usamos Scrum “mas” fazemos os testes fora da Sprint;
  • Nós usamos Scrum “mas” terminamos a sprint, só falta testar;
  • Nós usamos Scrum “mas” mudamos sempre o escopo da sprint durante sua execução;
  • Nós usamos Scrum “mas” não fazemos Review, é muito chato;
  • Nós usamos Scrum “mas” achamos a Retrospectiva uma perda de tempo;
Muitas vezes vemos a pseudo utilização do Scrum, é uma jornada que muitas vezes fazem parte de um processo de aprendizagem, continue em movimento com objetivos estabelecidos rumo a sua meta.

Dá pra continuar essa lista até amanhã, muitas vezes vemos grupos “adaptando” o Scrum para “facilitar” sua utilização quando na verdade estão dificultando já que o Scrum colabora para revelar os problemas de forma que possamos identificar e agir inspecionando e adaptando, porém para tanto, precisamos exercer a transparência.

Quando se faz uso deste expediente do ScrumBut, estamos na verdade ocultando as disfunções existentes no processo o que torna as coisas bem mais complicadas, enfrente seus medos e diga não ao ScrumBut.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Arquitetura de software e agilidade combinam !!!

Eu penso que é muito importante antes de iniciarmos o desenvolvimento de qualquer sistema, que se elabore um desenho de solução, não importa o tamanho do sistema a ser construído. O que tenho visto nos últimos anos são times que simplesmente abdicam deste importante artefato ou ao contrário, tentam prever todos os detalhes de forma prematura, acredito que o custo das duas abordagens é alto.

Precisamos encontrar um meio termo, o manifesto agíl diz “responder a mudanças ao longo de um plano” deve haver um plano inicial e conforme as necessidades vão surgindo, ajustamos o plano. Precisamos criar um desenho de solução arquitetural inicial para servir como ponto de partida, um direcionamento para o time, isso pode nos livrar de muitos problemas futuros.

Muitas vezes arquitetura e a agilidade são considerados fatores conflitantes, entretanto quando ambas são tocadas corretamente a colaboração entre as duas se torna natural.

Precisamos tentar garantir que as decisões importantes tenham sido tomadas, dependendo do tipo de arquitetura selecionada, algumas decisões podem ser mais importantes que outras, em um cenário de baixo acoplamento a escolha da linguagem de programação não é tão crítica por exemplo.

Um bom desenho de solução colabora com a agilidade pois nos permite executar mudanças de forma mais flexível, quem nunca enfrentou a situação da impossibilidade de realizar mudanças específicas em um sistema sem quebrar outras coisas que não tem haver com o que foi alterado ?! Claro que é mais simples falar do que fazer, entretanto não podemos deixar de fazer o melhor que pudermos dado o cenário para cada situação.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Surgimento de novos requisitos na Sprint Review, como tratar !?

A Sprint Review acontece ao final de cada Sprint encerrando o evento, essa reunião tem o intento promover principalmente:
 Demonstração do incremento produzido.
 Obter aprovação do Dono do Produto.

A meta da Sprint precisa se alcançada, devem ser demonstrados na reunião apenas os itens que foram executados, ou seja que alcançaram a definição de pronto, todo o trabalho não terminado deve voltar ao backlog para replanejamento.

A Sprint Review é cerimônia que deve ter observada seus objetivos, novos insights devem aparecer durante a reunião, porém se organize e não se perca.

O próprio time deve fazer a demonstração e deve se organizar para a tarefa respondendo todas as dúvidas que surgirem na reunião, os dois valores do Scrum que são determinantes nesta reunião são a Inspeção e Adaptação.

Durante a reunião novas ideias e requisitos irão aparecer e isso deve ser considerado com positividade, podem ser discutidas considerando porém o objetivo da cerimônia, as ações de melhoria identificadas devem ser endereçadas nas próximas sprints, o momento de detalhamento destas ações é posterior a review, mantenha o foco no objetivo da reunião.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Definição de Preparado, use com bom senso !!!

A definição de preparado (Definition of Ready) é um acordo entre o product owner e o time de desenvolvimento que serve para orientar quando uma história está pronta para ser executada em uma Sprint.

A boa prática orienta que o Product Owner tenha um “estoque” de histórias preparadas equivalente a 3 sprints conforme a velocidade medida historicamente do time, assim quando houver algum imprevisto que evite a elaboração e o refinamento de novas histórias, não se corre o risco do time ficar parado.

Entretanto precisamos tratar com cuidado esse tema, pois o que se vê em algumas situações é o time utilizar a definição de pronto como escudo, afirmando que algo não pode ser iniciado devido a falta de alguma condição determinada na DoR, isso afeta a colaboração entre o time de desenvolvimento e o product owner.

O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva, não deixe que .
O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva.

É necessário que se use o bom senso, uma definição de preparado pode ser estabelecida como um contrato e servir como uma referência. Porém não quer dizer que se alguma demanda não alcançar todas as características determinadas nesta lista, não se deva trabalhar na demanda.

Se o time tiver o entendimento sobre o que precisa ser feito com as informações disponíveis para execução, devemos seguir. Aproveite os benefícios da utilização da definição de preparado (DoR), mas não deixe que isso se torne uma parede entre o time e o PO.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Product Owner novo na área, o que fazer ?!

O ideal é que o Product Owner conheça do negócio do lugar aonde ele vai atuar, mas caso seja novo na área que vai atender, não é o fim do mundo, fique frio(a) e siga o procedimento.

O primeiro passo é começar a construir um relacionamento com os stakeholders, se reúna com as pessoas que possam falar sobre o tema que você vai precisar tratar, procure capturar com a maior precisão possível as expectativas do negócio.

Analise o mercado e esteja ciente das tendências, identifique os principais competidores, sendo eles diretos, indiretos, potenciais ou substitutos, conforme as características como qualidade dos times, marca, base de usuários e etc.

Comverse com as pessoas, e busque as informações disponíveis, assim será bem mais fácil, perguntar não ofende!!

Analise o backlog atual caso exista, conheça o time de desenvolvimento converse com eles, fornecerão informações valiosas para que você consiga montar sua visão sobre o cenário do qual está integrando. Trabalhando em conjunto com os stakeholders e o time de desenvolvimento o processo deve ser acelerado, boa sorte.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Você sabe o que é Value Stream ?!

O value stream representa o caminho por onde as ideias trafegam até que a mágica aconteça, a entrega, o value stream é o mapeamento de fluxo de valor, uma técnica Lean para análise de processos e como sabemos existem muitos desafios e oportunidades de melhoria nesse interim, precisamos eliminar as atividades que não adicionam valor, essa é uma ótima técnica pois vai ajuda-lo a isolar, comunicar e quantificar de forma eliminar o desperdício otimizando o tempo de entrega.

O objetivo é mapear seu processo e analisar cada ponto em busca de alguma não conformidade ou oportunidades de melhoria, veja abaixo o desenho de fluxo exemplificando as fases do desenvolvimento utilizado por uma squad.

Tipicamente na transição entre as fases temos oportunidades que podem ajudar significativamente a dimunição do lead time e cycle time.

Então para iniciar este tipo de trabalho é muito importante que se conheça e se entenda as fases por onde uma demanda trafega em seu ambiente, para identificar os problemas e promover as melhorias é essencial que se conheça a dinâmica de como as coisas acontecem.

Considerando o fluxo da imagem acima, podemos verificar em uma situação hipotética que temos um gargalo no code review e então ao analisar a questão mais de perto se descobre que temos uma pessoa responsável por isso e que está sobrecarregada, uma das soluções possíveis seria por exemplo que todos o desenvolvedores do time fizessem o Code Review no código do colega, isso reduziria o tempo em que as demandas ficariam paradas nesse passo, a ideia é eliminar ou amenizar os gargalos.

Crie métricas que possam ajuda-lo conforme o cenário e fique de olho no Lead Time e o Cycle Time, a cada intervenção avalie se houve o efeito desejado nas medições.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Processo de homologação, como é que é ? (Parte 3/3)

Depois de preparar o ambiente aonde acontecerá a homologação é necessário verificar conforme o cenário qual será a estratégia de execução, dependendo do tamanho dos sistemas mais de uma área de negócio precisará dar o sinal verde, precisamos organizar isso através da elaboração de um plano.

Um plano de homologação precisa ser elaborado desde o início do projeto aonde todas as pessoas necessárias precisam ter ciência que nesse momento serão acionadas. Um erro muito comum é que haja essa comunicação na reta final do projeto e dessa forma fica mais difícil que todos consigam se planejar para estarem a disposição no momento necessário, causando atrasos.

Quando falamos dessas necessidades, não estamos falando apenas da área de negócio, mas de pessoas e recursos de todas áreas que precisam contribuir de alguma forma para que a homologação possa ocorrer (criação de banco de dados, questões de hardware, configuração de ambientes, migração de dados, dentre outros), incluindo pessoas que estão envolvidos na execução do próprio projeto, o planejamento da homologação deve ser iniciado juntamente com o próprio projeto, isso é fundamental e deve evoluir conforme o projeto avança.

Existem muitas formas de executar, porém as decisões precisam ser tomadas conforme o cenário e as restrições colocadas. Tipicamente o que acontece, com o objetivo de ganhar tempo, é a montagem de algumas frentes que executarão a homologação em paralelo, porém para fazer isso precisamos conhecer quais são as dependências e como será a divisão para que o sistema possa ser validado.

Por isso a necessidade de criar o plano desde o início do projeto, para que haja tempo hábil de se conhecer quais recursos serão necessários para cada assunto, deixar tudo isso para o final é a fórmula para a bagunça.

Veja o exemplo do caminho a percorrer para validar o funcionamento de cadastro de produto em um site de e-commerce:

  1. Cadastro de Produto
  2. Geração do Pedido de Venda
  3. Recebimento de Mercadoria
  4. Incremento do Estoque
  5. Precificação do Item
  6. Produção do SKU (Colocar informações e imagens para aparecer no site)
  7. Ativação
  8. Disponibilização de cálculo de Frete
  9. Fechamento de Compra
  10. Envio para ERP
  11. Faturamento
  12. Geração de Nota Fiscal

Bastante coisa não é, agora imagine planejar como irá testar tudo isso apenas no final do projeto, veja que a cada passo dependendo do que precisa ser homologado vai ter uma abordagem diferente, por exemplo, como o teste é do cadastro de produto, não preciso neste momento validar se o cálculo do frete está correto, só precisamos que o recurso esteja disponível de forma que o teste possa ser executado até o final com as variações necessárias para validação.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Velocity x Débito Técnico

É comum times que priorizam a velocity (soma dos pontos entregues ao final de uma sprint) não considerando qualidade e a completude dos itens no afã de entregar tudo que foi planejado.

Quando isso acontece, a velocidade atribuída ao time não é real, pois no caminho os débitos técnicos surgem se acumulam gerando um backlog informal que em algum momento precisará se resolvido, afetando exatamente a velocidade do time já que a capacidade de entrega será diminuída, com o passar do tempo.

Tipicamente ao implementar as histórias subsequentes existirá a necessidade de fazer trabalho adicional relacionado aos débitos técnicos existentes conforme a evolução dos trabalhos.

Na maioria dos casos a falta de transparência no time scrum permite que o débito técnico seja criado e mantido durante o projeto.

Ou seja a velocidade “oficial” passa a não ser real pois devido aos problemas que deverão ser tratados durante as sprints, em algum momento o planejamento não poderá ser mais cumprido, e se chegará a conclusão que itens entregues no passado não estavam realmente prontos, é melhor controlar o passo agora para não tropeçar depois, mantenha a transparência.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!