POR DENTRO DO SCRUM: MONITORAMENTO DO PROGRESSO NO SCRUM

Quando trabalhamos em projetos críticos, as partes interessadas costumam perguntar aos membros da equipe como vão as coisas. Isso é bom. As pessoas estão se dedicando ao resultado do projeto. Pode ser uma distração para a equipe, pois alguns membros têm uma perspectiva completa da situação, e outros não. 

O Scrum aborda esses desafios publicando radiadores de informações. Isso abrange tudo que publicamos em paredes ou sites de equipe e que ajude todos a entender o que está sendo feito e o andamento. 

As formas variam muito, conforme a necessidade do ambiente e do projeto. Já vi equipes publicarem as normas para a equipe, a visão do projeto, a definição de “concluído”, os roteiros e o planejamento de lançamentos. No mínimo, as equipes publicam o quadro de tarefas e o gráfico de burndown. 

Então, vamos detalhar isso. O formato do quadro de tarefas varia, mas alguns componentes são essenciais. Ele mostra as histórias prometidas na iteração, as tarefas atuais e a situação delas e as tarefas já concluídas. Este é um exemplo simples de um quadro de tarefas.

Ele mostra claramente as histórias prometidas e as tarefas relacionadas, mas vai além, mostrando quais tarefas foram iniciadas e quais já foram concluídas. 

Essa ferramenta simples e prática informa a todos no que a equipe está trabalhando. Esse quadro se torna a essência da execução da iteração. A equipe se reúne ao redor dele para acompanhar o que está acontecendo na iteração e se ajudar, caso alguém tenha dificuldades. 

Outra ferramenta primordial para apresentar informações sobre o andamento é o gráfico de burndown da iteração. Ele é usado pela equipe para avaliar seu sucesso ao executar a iteração. Embora o quadro de tarefas informe a conclusão das atividades, ele não compara isso com a situação da equipe na iteração. O gráfico de burndown faz isso. Aqui vai um exemplo.

O gráfico informa exatamente onde estamos na iteração dia após dia e quanto trabalho nos comprometemos a fazer em toda a iteração ou horas. O ideal é que o detalhamento seja feito de forma linear. A linha “real” informa exatamente como estamos indo em comparação com o ideal. É uma ferramenta muito poderosa que mostra o andamento da equipe a todos os interessados. Fácil de criar, usar e entender. 

Essas são as principais características dos grandes radiadores de informações. São úteis para a equipe, e os interessados vão gostar de entender a situação com clareza.

Em nossa próxima postagem, falaremos sobre Scrum diário ou reunião diária em pé

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

POR DENTRO DO SCRUM: PLANEJAMENTO DAS ITERAÇÕES NO SCRUM

Conforme a equipe se prepara para uma iteração, torna-se necessária uma colaboração mais detalhada, e é exatamente isso o que fazemos na reunião de planejamento da iteração. A participação plena é fundamental. Precisaremos de todos os membros da equipe de desenvolvimento, do ScrumMaster e do Product Owner. Essas responsabilidades não podem ser delegadas. 

Usando a lista de pendências priorizada, o PO apresenta as histórias de maior valor para a equipe na sequência. A equipe precisa estar à vontade para fazer perguntas. O objetivo é que todos tenham plena compreensão do objetivo da história e de seus CA específicos. Na reunião, também é útil publicar a definição de “concluído” da equipe para todas as histórias. 

Como a definição de “concluído” da equipe se aplica a tudo, ter essa informação à mão ajuda a garantir que todas as tarefas sejam identificadas. No planejamento das iterações, fazer perguntas é primordial. No final do planejamento, a equipe vai se comprometer a terminar todo o trabalho. Problemas de entendimento devem ser evitados, e essa é a ocasião certa para esclarecer as histórias. 

Depois que todos entenderem os detalhes das histórias, a equipe anota as tarefas necessárias para concluir cada uma. Vamos ao exemplo do aplicativo para pedir refeições. Na história “criar identificação do usuário”, a tarefa seria “gravar identificação do novo usuário no banco de dados” e levaria cerca de meia hora. Vamos ver como atribuir as histórias. Cada tarefa deve ficar clara e ser estimada usando o tempo. Nas iterações, utilizamos pontos para identificar as histórias a incluir em cada iteração. Nas tarefas, usamos o tempo para preencher a capacidade — as horas que cada membro da equipe pode dedicar. Sabendo o número de horas de todo o trabalho planejado na iteração, precisamos verificar se a equipe tem capacidade para realizá-lo. Como orientação geral, em um dia de trabalho de oito horas, as pessoas geralmente têm apenas seis horas de tempo produtivo. As outras duas horas costumam ser gastas com telefonemas, interrupções, e-mails, etc. Estamos tentando evitar o comprometimento excessivo. Portanto, a comparação entre horas necessárias e horas disponíveis é uma boa etapa de confirmação. Por fim, agora que as histórias foram claramente explicadas e as tarefas em cada uma delas foram definidas, é hora de se comprometer com o trabalho. 

O Scrum leva a etapa de compromisso muito a sério. Perguntamos a cada pessoa da equipe se ela se compromete com as histórias da iteração, e ela deve responder “sim” ou “não” e por quê. Se alguém não puder se comprometer, o PO e a equipe precisam trabalhar juntos para mudar a forma da iteração até que todos possam se comprometer. O planejamento das iterações é um esforço colaborativo importante no Scrum. Repita essa reunião no início de cada iteração. Você vai ficar cada vez melhor.

Em nossa próxima postagem, vamos falar sobre o Monitoramento do progresso no Scrum

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

POR DENTRO DO SCRUM: CRIAÇÃO DO ROTEIRO E PLANEJAMENTO DE LANÇAMENTOS

Depois de todo trabalho preparando os temas, recursos e lista de pendências e identificando a duração das iterações, é hora de estimar quando as tarefas serão realizadas. O Scrum também tem ferramentas para isso. Usamos dois mecanismos diferentes: o roteiro e o planejamento de lançamentos. O roteiro é bastante geral e visa à aplicação dos temas ao longo do tempo. Assim, todos terão uma noção geral de qual será o foco num determinado período. Usando o exemplo da criação de um aplicativo móvel para pedir refeições, identificamos os temas perfil, pedido, pagamento e entrega. Agora precisamos decidir a melhor sequência para trabalhar nesses temas. 

Embora o pagamento talvez seja o mais importante para os nossos parceiros de negócios, do ponto de vista das dependências, provavelmente faz mais sentido priorizar o perfil e o pedido. Como tudo no Scrum, essa é uma diretriz, não uma regra, mas seguindo essa ideia, veja como seria o roteiro. Como podemos ver, esses temas não estão necessariamente ordenados pelo valor. Depois disso, podemos organizar as histórias conforme os cronogramas de temas que elaboramos. É assim que criamos o planejamento de lançamentos, que é a próxima camada de detalhes. É um plano geral que visa ligar o roteiro às iterações. Ele permite visualizar como faremos as entregas. 

No Scrum, precisamos concluir histórias totalmente funcionais ao final de cada iteração. Porém, não somos obrigados a divulgá-las às partes interessadas no fim de cada iteração. Ou seja, podemos concluir todo o trabalho de duas ou três iterações e divulgar os resultados juntos. Vamos usar os pontos de história para ajudar a equipe a decidir o que consegue fazer em cada iteração. 

Depois de trabalhar junta por um tempo, a equipe alcançará uma velocidade estável. Isso significa que todos saberão quantos pontos de história conseguem completar em cada iteração. Até que a velocidade se estabilize, faremos estimativas do número de pontos a concluir em cada iteração. Por exemplo: suponha que a equipe tenha acabado de começar e considere que, em grupo, consiga lidar com 10 pontos a cada iteração de 2 semanas. Pretendemos fazer o lançamento após 3 iterações, ou seja, 30 pontos por lançamento.

Vamos analisar o roteiro e as histórias que organizamos ao longo do tempo com base nos temas. Só precisamos selecionar as histórias de maior prioridade por tamanho, para encaixá-las em cada iteração. Deve ser algo assim: 

Veja que não estou planejando por ordem de prioridade. Neste nível de detalhe, trata-se de maximizar o número de pontos por iteração. Então, se a próxima história de maior prioridade, a história C, de oito pontos, for grande demais para a primeira iteração, descemos na lista até encontrarmos uma que se encaixe — a história D, de cinco pontos. Lembre-se de que o roteiro é uma estimativa de quando a equipe vai concluir essas histórias. Ele deve ser atualizado no fim de cada iteração. A equipe segue aprendendo e escrevendo novas histórias durante a iteração, então o roteiro deve ser um documento vivo. É apenas um guia, mas nos ajuda a manter o foco para que o projeto atinja os objetivos.

Em nossa próxima postagem, vamos falar sobre Planejamento das iterações no Scrum

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

TPM: O OEE (OVERALL EQUIPMENT EFFECTIVENESS)

OEE é o principal indicador de efetividade global de equipamentos e linhas de produção, sendo largamente utilizado nas indústrias de manufatura.  A sigla OEE é uma abreviação do termo Overall Equipment Effectiveness.

O OEE foi introduzido por Seiichi Nakajima, um dos pais da TPM (Total Productive Maintenance / Total Performance Mangement - consulte nosso artigo CONHECENDO O TPM - ALINHANDO CONCEITOS), como sendo uma medida essencial para avaliar a performance de um equipamento,  sendo usado como um dos principais componentes da metodologia TPM.

Com o crescimento da manufatura enxuta (lean manufacturing) o OEE passou a ter um amplo uso pelas empresas que abraçaram esta filosofia de produção, tornando-se popular e sendo utilizado até por empresas que ainda não adotaram a produção enxuta.

Uma das razões que contribuíram para a larga utilização do OEE, é pelo fato de nos mostrar, de forma simples e direta, o quão efetivamente um equipamento foi utilizado, ou seja, quantos itens bons foram produzidos, comparado com a sua capacidade de produzir itens bons.

Exemplo:

Peças boas produzidas no turno: 3000 peças

Peças boas que o equipamento tem capacidade de produzir no turno: 5000 peças

OEE = 3000 / 5000 * 100% = 60%

No exemplo acima, o OEE de 60% indica que o equipamento produziu 60% dos itens bons que o equipamento tem capacidade para produzir no período, e que a perda foi de 40%, ou seja,  2000 itens deixaram de ser produzidos ou foram produzidos com defeito.

O OEE mostra quanto tempo o equipamento produziu comparado com o tempo disponível para produção.  Do de produção, quão rápido ele produziu.  E dos itens produzidos quantos estavam conforme as especificações.   E assim o OEE não só quanto houve de perda, mas também onde estão as perdas, facilitando a atividade de quem atua na produção e precisa adotar ações para atingir as metas estabelecidas.

Gestores têm condições de analisar todas as oportunidades de melhoria, escolhendo aquelas que proporcionam um retorno maior ou as que, apesar de apresentarem um retorno menor, podem ser alcançadas rapidamente à um custo pequeno, como por exemplo, a aplicação de um treinamento voltado para a equipe de produção.

Outro fator importante referente a adoção do OEE na gestão da performance industrial, deve-se ao fato de que o uso de indicadores de desempenho financeiro não refletem a realidade da produção, conduzindo os gestores, em algumas situações, a tomarem decisões equivocadas.

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

SUSTENTABILIDADE: COMO MEDIR MINHA PEGADA DE CARBONO

Nesta etapa, a grande dúvida é sobre como agir para fazer parte da solução desse problema, certo? Bom, existem algumas calculadoras disponíveis para medir a sua pegada de carbono e/ou ecológica, conforme a seguir:

United Nations - Carbon Offset Platform (em inglês).

Global Footprint Network - Footprint Calculator (em inglês).

Iniciativa Verde - Calculadora de CO2 (em português).

Como reduzir a minha pegada de carbono?

Seguem abaixo algumas dicas para alcançarmos essa redução:

1. Diminua o consumo de plásticos ou opte por objetos reutilizáveis;

2. Troque aparelhos que gastam muita energia por outros mais econômicos;

3. Consuma mais produtos locais e/ou crie uma horta urbana;

4. Plante árvores;

5. Conscientize pessoas sobre o tema e ajude elas a darem o primeiro passo;

6. Apoie projetos socioambientais;

7. Seja um exemplo prático no dia a dia para quem está perto de você

E assim concluímos nossa série de postagens sobre as Pegadas de Carbono. Esperamos que tenham gostado, entendido e aprendido a importância de buscarmos sempre rotinas e condutas sustentáveis. Tanto o planeta quanto a sociedade agradecem!

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

POR DENTRO DO SCRUM: PONTOS DE HISTÓRIA E ESTIMATIVAS NO SCRUM

Todos os dias usamos dois tipos de estimativa: real e relativa. Usamos a estimativa real ao ler um mapa. Para ir de A a B, são 15 quilômetros. É muito específico. Já a estimativa relativa consiste em comparar duas coisas para ter uma ideia geral de algo, como “uma girafa é duas vezes mais alta que uma zebra” ou “um bolo tem a mesma largura de uma torta”. 

Na Gestão Ágil e no Scrum, utilizamos os dois tipos de estimativa. Usamos a estimativa relativa para ter uma noção da quantidade de trabalho, comparando histórias de usuários umas às outras. Ela nos dá uma ideia da dimensão de algo. As próprias histórias são indicações aproximadas de como o usuário deseja interagir com o produto. Por ser um relato aproximado da necessidade, não podemos ser muito específicos quanto à sua dimensão. Além disso, como é apenas uma previsão inicial, as partes interessadas não devem achar que sabemos exatamente o que é necessário para concluir o trabalho. 

A estimativa relativa ajuda a enxergar que se trata apenas de uma estimativa, não de um compromisso. Porém, quando nos comprometemos com uma tarefa, precisamos saber muito bem o que é necessário para realizá-la. Assim, quando for hora de fazer o trabalho, precisamos especificar quanto tempo vai demorar, então passamos para a estimativa real. As equipes de Scrum usam o Planning Poker para fazer estimativas relativas de suas histórias. Os pontos de história são a unidade de medida que usamos para expressar o tamanho relativo. 

A estimativa deve ser simples e rápida. Não deveria levar dias ou horas para determinar quanto esforço vamos dedicar a algo. Talvez seja preciso prática, mas, depois que pegamos o jeito, fazemos isso rapidamente. 

Em nossa próxima postagem falaremos sobre criação do roteiro e planejamento de lançamentos

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!

TPM: INDICADORES DE MANUTENÇÃO - MTBF e MTTR

MTBF é a sigla para Mean Time Between Failures, que em português significa tempo médio entre falhas

MTTR é a sigla para Mean Time To Repair, que em português significa o tempo médio de reparo

O tempo médio entre falhas (MTBF) é a quantidade média de tempo que um dispositivo ou produto funciona antes de falhar. Esta unidade de medida leva em conta apenas o tempo operacional entre falhas e não os tempos de reparo, assumindo que, se houve falha, o item foi reparado e entrou em funcionamento novamente. Os valores de MTBF são frequentemente usados para projetar a probabilidade de uma única unidade falhar dentro de um certo período de tempo.

Um ponto bastante relevante do MTBF, é que aqueles que fazem análise desses tipos de estatísticas devem ter conhecimento se a medição se aplica a uma unidade que funcione até a ocorrência da falha, ou se um número significativo de unidades diferentes é executado por um curto período de tempo, no qual o MTBF representa a probabilidade de falha nesta fase mais reduzida de teste. O MTBF, por si só, nem sempre demonstra quanto tempo é o processo de teste para uma determinada unidade. Por exemplo, se mil dispositivos forem executados ao longo de várias horas cada e, 1% deles apresentarem mau funcionamento, essa condição produzirá resultados diferentes do que se uma unidade fosse testada até uma eventual falha da mesma.

Como Calcular Esse Indicador?

MTBF = (Tempo total disponível – Tempo perdido) / (Número de paradas)

MTTR  – Mean Time to Repair

O tempo médio de reparo (MTTR) mede capacidade de manutenção de um item reparável, informando o tempo médio necessário para reparar um item ou componente específico, retornando o mesmo ao status normal de trabalho. É uma medida básica da manutenção de equipamentos e peças. Inclui o tempo de notificação, o diagnóstico e o tempo gasto atuando no reparo real, incluindo outras atividades necessárias para que o equipamento possa ser usado novamente.

O tempo médio de reparo é a representação de quanto tempo leva para que o equipamento volte à condição de trabalho, levando em conta a notificação inicial da falha, o tempo necessário para encaminhar o equipamento aos reparos o, diagnóstico, tempo real de reparo, montagem, calibração, teste e depois retorná-lo de volta ao campo. Em resumo, contempla o tempo desde o momento em que um usuário envia o item para reparos até o usuário recuperar o item.

O MTTR é calculado pela divisão do tempo total necessário para reparo ou manutenção, pelo número total de reparos realizados em um período de tempo específico. Quanto menor o MTTR, maior a qualidade de um item ou equipamento específico. Por exemplo, um item que possui um MTTR de 24 horas é melhor que um com um MTTR de 7 dias se o tempo médio antes da falha (MTBF) for igual, já que isso significa que a disponibilidade operacional do equipamento é maior. Quando há uma falha no equipamento, há apenas um tempo de inatividade de 24 horas antes da retomada da operação, em oposição a inatividade de 7 dias.

Como calcular o MTTR?

Assim como o MTBF, o cálculo é simples.

MTTR = (Tempo total de reparo) / (quantidade de falhas)

Em nossa próxima postagem, falaremos sobre OEE

Siga nossas mídias clicando no link abaixo:

https://linktr.ee/sjconsultoria

Ou aponte seu celular para o QR CODE aqui:

Vem com a gente, porque aqui, nós pregamos o que acreditamos e praticamos o que pregamos! Até a próxima!