Edson – Página: 4 – Edson Conceição

junho 29, 2020junho 30, 2020

Conhece Comunicação Não Violenta (CNV) !?

A CNV ou Comunicação Não Violenta, é um conjunto de técnicas para melhorar relacionamentos sejam eles pessoais ou profissionais, na dinâmica da busca de soluções muitas vezes enfrentamos obstáculos como mal entendidos gerados pela forma que estamos acostumados a olhar o outro.

Temos a tendência de identificar apenas o que há de errado com as outras pessoas e não conseguimos comunicar muitas vezes nossas necessidades ou analisar as possíveis necessidades dos outros.

Utilize a CNV e se comunique com mais eficiência resolvendo os conflitos de forma construtiva além de fortalecer o time.

Para melhorar a nossa comunicação precisamos reconhecer nossos sentimentos e explicar exatamente o que estamos precisando, isso aumenta muito a chance de que haja sucesso na comunicação, pois a outra parte terá a chance de entender exatamente como a questão está impactando, veja a diferenças nas duas sentenças abaixo:

Ele é muito irresponsável agindo dessa forma e isso me deixa muito irritado !!
Sinto-me muito irritado com essa situação porque nossos clientes ficam prejudicados e insatisfeitos com o nosso serviço e no próximo mês é o período para renegociação de nossos contratos.

Veja que na segunda sentença a chance de uma construção mais efetiva é bem maior, ao invés de simplesmente culpar o outro pelo que estamos sentindo, reconheça suas expectativas, necessidades e desejos e comunique isso para que todos possam estar contextualizados.

Ao invés de simplesmente apontar o que há de errado com as outras pessoas, converse sobre o que você precisa , a probabilidade de se chegar a uma solução que atende a todos aumenta enormemente.

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

junho 25, 2020junho 25, 2020

Obtenção de Métricas Avançadas

No último post falamos de busca de informações que podem ajudar a ter um direcionamento no ínicio do trabalho e fazer as correções necessárias para que se garanta a integridade das informações prestadas, com essa base, podemos extrair métricas que vão ajuda-lo a dar um direcionamento aos times no médio e longo prazo.

Cycle Time: o tempo médio de quando os itens começam a ser executados até a entrega dentro processo estabelecido.

Lead Time: o tempo médio de finalização dos itens desde a hora em que o item aparece no backlog até a entrega em ambiente produtivo, percorre todo o processo de desenvolvimento, de ponta a ponta.

Throughput: é o número de itens executados dentro do fluxo de desenvolvimento em um determinado período.

WIP: Número máximo de itens que devem estar em progresso, isso ajuda na organização do time, para que se evite que se coloque mais itens em andamento do que o time consegue tratar, já que cada pessoa consegue andar com uma tarefa por vez.

Com a utilização de métricas vários aspectos de um time podem ser analisados e melhorados conforme a necessidade e priorização, porém é necessário ter uma base sólida e íntegra para que se possa ver.

Com a utilização destas métricas é possível controlar e calcular o tempo total de uma tarefa, gerando informação para que se possa tomar iniciativas de melhoria, diminuir o tempo em que as coisas ficam paradas e ajustar estimativas.

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

junho 25, 2020junho 25, 2020

Obtenção de Métricas Básicas

Uma das primeiras coisas a fazer quando um Scrum Master assume o “mandato” é verificar como as informações relacionadas as métricas são coletadas, o ideal é que se utilize um software para armazenar essas informações do time, como o Jira ou o TFS por exemplo.

Comece verificando a integridade das informações geradas pelo time, identifique os gaps de manejo e oriente o time para que as informações sejam fornecidas corretamente, isso também vale caso não exista um software aonde as demandas são controladas, é mais difícil mas possível.

Ajude o time a dispor as informações de forma que se possa obter algumas das seguintes métricas de forma sustentável:

Velocidade (Velocity)
Pontos de história completados por sprint
Burndown
Burnup
Release Burndown
Quantidade de defeitos
Quantidade de builds
Quantidade de histórias publicadas em produção
Frequência de releases
Quantidade de histórias aceitas
Quantidade de histórias não aceitas

Garantindo que essas informações estejam realmente íntegras, será fácil analisar e identificar as oportunidades de melhoria para realização de um planejamento, a coleta e a manutenção das informações é essencial para que se tenha certeza que as ações estejam sendo realizada no ponto certo, fique de olho.

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

junho 23, 2020

Já ouviu falar em 5W2H !?

Uma das missões do Product Owner é obter e traduzir para o time de desenvolvimento as necessidades da área de negócio e/ou os clientes a serem atendidos pelo seu produto, existem várias formas, você já ouvir falar de 5W2H !?

É um acrônimo em inglês que representam as perguntas que podem ser respondidas em um levantamento de informações/requisitos, é uma ferramenta que pode ser utilizada em qualquer área profissional, é bem conhecida em gerenciamento de produtos.

Who ? (Quem ?)
What ? (O quê ?)
Where ? (Aonde ?)
When ? (Quando ?)
Why ? (Por que ?)
How ? (Como ?)
How Much ? (Quanto ?)

Uma ferramenta que pode ser utilizada em qualquer área profissional, é bem conhecida em gerenciamento de produtos.

É um recurso muito interessante quando falamos em levantamento de requisitos, vários aspectos de uma questão podem ser capturados com a utilização deste expediente.

São perguntas abertas que exigem respostas mais elaboradas e geram uma oportunidade para se obter informações preciosas, muito se fala sobre os usuários não saberem o que querem, mas eles não podem esconder suas necessidades com esse tipo de abordagem, seja gentil.

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

junho 21, 2020

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

junho 18, 2020

Scrum Master é um cargo de gestão !?

O cargo de Scrum Master certamente é um cargo de gestão, porém não tem as atribuições de um gerente tradicional que tipicamente tem ascendência funcional sobre o time.

O Scrum Master gerencia utilizando o processo Scrum e não tem poder funcional sobre o time ou suas atribuições, dentro da companhia, o Scrum Master é responsável por entender o cenário e facilitar que as pessoas possam atuar da forma mais eficiente possível utilizando o framework.

A posição de Scrum Master é de gestão, porém sobre um prisma diferente.

A sua principal missão é influenciar para que o framework seja entendido e adotado da melhor forma possível conforme o nível de maturidade do grupo, gerando ações de melhoria, estabelecendo metas e criando indicadores de forma que todos tenham visão aonde estão e quanto falta pra chegar lá.

Trocando em miúdos é como se você estivesse cuidando dos filhos de outras pessoas, precisa manter a ordem e cuidar, mas não pode brigar, seja paciente e ajude-os.

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

junho 17, 2020junho 18, 2020

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.

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

junho 16, 2020

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

junho 15, 2020junho 15, 2020

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

junho 14, 2020

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