7 desperdícios em desenvolvimento de Software - Detalhamento (parte #3 - final)

No artigo anterior, vimos os 3 desperdícios no desenvolvimento de software: trabalho parcialmente feito, características extras e reaprendizado

Neste artigo vamos ver os últimos 2 desperdícios, completando assim a lista dos 7 desperdícios mais comuns em desenvolvimento de software e que finalizam a lista citada nos posts anteriores

Desperdício #6: comutação de tarefas Significado: Membros da equipe que se deslocam de uma tarefa para outra sem concluir a primeira tarefa corretamente.

Possível razões:

  1. Interrupções contínua de tarefas
  2. Falta de análise ao nível do solo das tarefas necessárias para as histórias
  3. Uma equipe compartilhada trabalhando em mais de um projeto de cada vez
  4. Falta de coordenação adequada entre o proprietário do produto e a equipe de desenvolvimento

Como você pode eliminá-lo?

  1. As interrupções podem ser devido a muitas razões, incluindo a falta de informações completas sobre a tarefa, dependências relacionadas ao hardware, etc. Verifique se as tarefas são detalhadas o suficiente na reunião de planejamento do release e identifique todas as dependências externas na frente. Criá-los como impedimentos e deixar o time trabalhar com eles.
  2. Certifique-se de gastar tempo suficiente quando você está dividindo as histórias em tarefas durante a sua reunião de planejamento Sprint. Você precisa identificar todas as tarefas possíveis, e identificar a ordem dessas tarefas, de modo que você pode trabalhar em uma história até que seja completamente feito sem qualquer comutação de tarefa.
  3. Idealmente, as equipes de desenvolvimento devem ser equipes dedicados. Se você tem equipes compartilhadas, então, naturalmente, que leva à mudança de tarefa. Busque implementar uma fila única de trabalho, que possa tratar demandas de desenvolvimento e sustentação do mesmo produto.
  4. Se o dono do produto não fornecer a prioridade das histórias durante o planejamento de Sprint, isso pode levar a malabarismos entre as histórias durante o Sprint. Isso, por sua vez, leva à mudança de tarefa. Então tente ter as histórias priorizadas pelo proprietário do produto. Para este o valorcusto, e _risco_são os fatores-chave, como mencionado acima.

Desperdício #7: defeitos Significado: Funcionalidade errônea que produz saída errada.

Possível razões:

  1. Falta de compreensão sobre a história
  2. A história não satisfaz o princípio do investimento
  3. Falta de práticas de engenharia, como TDD, refatoração
  4. Falta aceitação critérios
  5. Falta de conjuntos de habilidades técnicas para os membros da equipe
  6. Tarde envolvimento de testadores
  7. Desatenção para a automação teste

Como você pode eliminá-lo?

  1. Não salte no desenvolvimento da história até que você tenha uma compreensão completa da história. Consulte o décimo princípio ágil–simplicidade, ou maximizando a quantidade de trabalho não realizada. Sempre que mais complexidade estiver envolvida, então vá com a abordagem “especificação por exemplo”.
  2. O proprietário do produto tem de garantir que a história segue o princípio do investimento. Se não, tente dividi-lo em histórias mais granulares.
  3. Seja rigoroso sobre como fazer testes de desenvolvimento orientado, emparelhar programação e refatoração parte do seu plano de desenvolvimento. Estes são poderoso Engenharia práticas.
  4. O proprietário do produto deve anexar os critérios de teste de aceitação a cada história que é priorizada para um Sprint. Isso ajudará o desenvolvedor a entender a história com mais detalhes do ponto de vista da implementação.
  5. Certifique-se de que você tem habilidades corretas na equipe e também tem padrões de codificação adequados e diretrizes no lugar na frente.
  6. É sempre bom ter os testadores envolvidos direito do estágio de planejamento Sprint. Ele irá ajudá-los a se envolver na maior cobertura de teste possível, o que reduz os defeitos.
  7. Certifique-se de ter um conjunto de testes automatizados criados a partir do primeiro release. Para qualquer projeto, um certo número de casos de teste (testes de sanidade) terá que executar mais de uma vez, de modo que, automatizando-os, vai economizar tempo bem como reduzir defeitos.

Finalizamos aqui a nossa série sobre desperdícios em desenvolvimento de software.

Quer saber como evitar estes desperdícios? Venha participar do Workshop Lean-Kanban Fundamentals

Até mais!