Publicado em

Não faça sprint de QA !!!

Algumas vezes nos deparamos com situações aonde se opta rodar uma sprint separadamente para execução dos testes de QA, essa abordagem deve ser evitada pois gera diversas disfunções causando impactos negativos.

Nesse cenário a definição de pronto não estaria sendo completamente seguida ou seria nula, pois na prática não teria utilidade já que ao final de uma sprint, o trabalho executado não estaria validado.

Não crie dificuldades para o seu time, se organize e faça os testes dentro da Sprint.

Durante os testes, os ajustes e bugs encontrados serão tratados em um momento diferente do ideal o que impactará a produtividade do time seja qual for o procedimento adotado a partir deste ponto.

Haverá dificuldades para o planejamento de releases além da geração de débitos técnicos diminuindo certamente a transparência, faça os testes de QA dentro da sprint, vai ser bem mais legal.

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

Publicado em

O ágil não é bala de prata !!!

Muitas vezes vemos o começo de iniciativas nas empresas aonde a utilização do ágil é encarado como a solução de todos os problemas, porém quando se pergunta quais são os principais desvios que se espera mitigar com essa iniciativa, a resposta na maioria das vezes é um longo silêncio.

Isso é um problema significativo, usar algum tipo de metodologia ou framework simplesmente porque “todo mundo está usando” não é exatamente recomendável, escolhas feitas com esse critério costumam não vingar porque pois neste cenário nunca poderemos chegar a conclusão de que estamos envoluindo, já que não sabemos aonde queremos ir.

Os objetivos precisam ser claros e entendidos por todos os envolvidos.

Posto isso, nada que está disponível no mercado poderá resolver o problema (já que não temos objetivos claros), e depois de muita confusão e disfunções, alguém vai dizer que o ágil não funcionou.

Antes de implementar qualquer solução em uma empresa, analise os problemas atuais e os priorize, verifique os níveis de maturidade nas principais questões, monte os cenários e ai sim busque as opções e as possíveis formas de resolução estabelecendo metas.

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

Publicado em

Faça a daily, todo o dia !!

A Daily é uma evento descrito do Scrum Guide que tem o time-box de 15 minutos, ela por definição otimiza a colaboração dos times através da inspeção e adaptação do que será feito nas proxímas 24 horas, por vezes em algumas situações podemos enfrentar resistência para praticarmos esse rito, precisamos concientizar as pessoas dos ganhos da correta utilização desta cerimônia.

Este evento endereça um dos principais problemas nos projetos, a falta de comunicação, muitas vezes as pessoas estão uma do lado da outra e estão passando por situações que não deveriam acontecer caso a comunicação estivesse adequada de forma que todos do time saibam e entendam o trabalho em andamento.

A comunicação durante a daily deve ser clara, todos precisam ter o entendimento do que está sendo tratado.

Existem ganhos significativos na realização da daily, seguem alguns deles:

  • O time poderá dividir o entendimento do que é mais importante no trabalho nas próximas 24 horas na busca do que é prioritário para que a meta da sprint seja alcançada;
  • Informar possíveis impedimentos ao Scrum master
  • Durante a daily membros do time podem trazer problemas que podem ser resolvidos rapidamente pelo time simplesmente compartilhando informações;
  • Todos terão visão do trabalho que está sendo executado em que ponto estão;

Com esses passos simples, podemos identificar problemas o mais cedo possível de forma a diminuir o impacto das questões identificadas durante a Sprint trazendo benefícios a todos os envolvidos.

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

Publicado em

A importância do time box.

O time box tem o objetivo de limitar uma quantidade de tempo para a resolução de uma atividade, existe um time box para todos os eventos do Scrum por exemplo.

O time box de certa forma promove a auto organização já que o planejamento de cada sprint será feito considerando o tempo determinado promovendo a oportunidade do time trabalhar em grupo encontrando soluções que caibam no tempo estabelecido em cada cenário.

O time box colabora que todos estejam focados na mesma questão ao mesmo tempo, isso facilita a coesão do time na busca pela meta da sprint. As pessoas que estão mais proxímas do problema serão encorajadas a criar a melhor solução possível dentro da período estabelecido para sua finalização dado o contexto situacional vigente.

O time box é um recurso do ágil muitas vezes negligenciado, entretanto temos muitos benefícios na sua correta utilização.

Apesar de ser um ferramenta importante não seja radical, não há problema por exemplo se em uma daily exceder o tempo, caso a conversa esteja sendo pertinente e for importante para o time, permita, sempre use o bom senso.

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

Publicado em

Scrum Master com time novo, o que fazer !?

Dependendo do cenário, este evento pode acontecer com mais ou menos frequência, o fato é que como Scrum Master de um time recém formado, uma de suas atrubuições é ajudar o time a começar o trabalho da melhor forma e no menor tempo possível.

Solicite que as pessoas do time se apresentem falando brevemente sobre suas carreiras e habilidades, seja o primeiro a fazer isso e não seja muito formal, crie um ambiente para que as pessoas se sintam a vontade nesse momento, vale até contar alguma piada que caiba no contexto, seja gentil.

O Scrum Master deve facilitar o início dos trabalhos do time aproximando o Product Owner e o Time de Desenvolvimento.

Peça ao Dono do Produto para apresentar o projeto, explicar quais são as dores, metas/objetivos, cenário e claro responder as dúvidas do time.

Com essas informações peça para o time Time de Desenvolvimento comece a discutir como eles imaginam que poderiam trabalhar em conjunto no contexto colocado com as informações disponíveis até o momento para iniciar os trabalhos de transformar Backlog do Produto em software, isso deve ajudar como ponta pé inicial.

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

Publicado em

Tratando requisitos não funcionais no ágil

Além dos requisitos funcionais que traduzem as funcionalidades previstas para uma aplicação, muitas vezes é necessário observar outras necessidades/características que estão inerentes ao que precisa ser desenvolvido, são os requisitos não funcionais que ensejam necessidades como segurança, performance, usabilidade dentre outras.

No contexto de agilidade, temos algumas formas de tratar os requisitos funcionais que quando não tratados o mais cedo possível costumam causar toda sorte de contra tempos, é muito mais difícil fazer um sistema performar mais rápido depois de que ele está desenvolvido do que fazer um planejamento de como essa questão será tratada previamente.

Requisitos não funcionais devem ser tratados o mais cedo possível conforme as necessidades emergem durante o projeto.

Tipicamente podemos tratar essa questão incluindo itens que endereçam as questões relacionadas aos requisitos não funcionais no Backlog do Produto e atribuindo a definição de pronto as atividades necessárias para nos ajudar a identificar como se fará a implementação considerando esses requisitos.

Podemos por exemplo determinar testes de carga estabelecendo uma métrica para a aprovação fazendo parte da definição de pronto, isso irá ajudar o time a se planejar para que os requisitos não funcionais sejam levados em conta desde o início do trabalho.

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

Publicado em

Utilização de técnicas de aprendizagem na TI.

Também atuo como professor, dou aulas há mais de 15 anos e nos treinamentos que ministro dentro das minhas possibilidades do conforme a instituição que estou atendendo, crio uma linha de raciocínio me baseando no que vejo nas empresas por onde passei e o que cada perfil (SM, PO, Dev Team) tipicamente enfrenta, faço isso fazendo uso de uma técnica utilizada na aprendizagem baseada em projetos na área de educação que é a problematização, colocando cenários aonde em grupo as pessoas possam discutir e trabalhar em conjunto para chegar a uma solução com acompanhamento e mediação adequeadas. Em treinamentos InCompany sempre que possível gosto de considerar as DIMENSÕES DE CONTEÚDO (aprendi isso em uma pós de docência):

Implementação de algum processo em relação ao conteúdo ministrado pode ser monitorado e avaliado em três aspectos:

Dimensão Conceitual: Operacionalizar a internalização dos conceitos passados em aula, demanda compreensão e estabelecimento de relações o que aumenta a complexidade de avaliação. (O que saber)

Dimensão Procedimental: Se resume a saber o que fazer, está ligada a operacionalização dos conceitos obtidos propriamente dita. (Saber fazer)

Dimensão Atitudinal: O comportamento individual que é formado por valores e crenças de cada pessoa e seu relacionamento com o contexto do qual está inserida, por meio de observação, sugestões podem ser formuladas com o objetivo de maximizar o aprendizado do conteúdo. (Como fazer).

A abordagem tende a dar mais resultados quando existe um acompanhamento dos egressos após o treinamento, em loco o que certamente exige um esforço e investimento adicionais.

Dimensões de conteúdo caem como uma luva quando falamos em cenários de implantação do Scrum nas empresas, a técnica é perfeitamente aplicável. 

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