7 desperdícios em desenvolvimento de Software - Detalhamento (parte #1)
Continuando o post anterior, vamos avaliar aqui 3 grandes desperdícios que encontramos em desenvolvimento de software.
Desperdício #1: trabalho parcialmente feito Significado: Isso geralmente significa que o trabalho (história) que não é completamente feito como por sua definição de Done, e, portanto, você não pode demonstra-lo ou você não pode liberá-lo. Isso pode incluir código que não é refatorado, código que não é testado, unidade/integração que não foi testada, código que não está devidamente documentado, código que não é implantável, etc.
Possível razões:
- Priorizando uma história sem ter informações completas sobre essa história do proprietário do produto
- Complexidade técnica que não foi analisada adequadamente durante o planejamento de Sprint
- Aguarde o tempo entre as tarefas que são identificadas para completar a história
- Dependências inadequadas para esta história com base em outras histórias
- Removendo uma história existente que está a meio caminho feito e recebendo uma nova história para o Sprint
- Incompleta/inadequada tarefas identificação
Como você pode eliminá-lo?
- Tente ter uma discussão detalhada com o proprietário do produto para entender a funcionalidade da história, e para entender o valor que ele adiciona ao produto. Em seguida, execute faça a priorização para um compromisso de entrega dentro da sua cadência já estabelecida. Isso exige uma grande coordenação e colaboração entre a equipe e o proprietário do produto.
- Tente avaliar a complexidade técnica da história com base em sua funcionalidade. Se necessário, vá para um pico técnico antes de chegar à estimativa. Isto irá, pelo menos, ajudá-lo a avaliar o quão complexo é para que você pode pegá-lo diretamente ou pedir ao proprietário do produto para dividi-lo-ou ir com alguma outra abordagem de implementação técnica.
- Tente fazer tarefas em paralelo, tanto quanto possível. Esta deve ser a maneira ágil verdadeira e não uma espécie de mini waterfall. Quando você está com algum bloqueio em alguma etapa do processo ou atividade, procure ajuda o mais rápido possível. Desenvolva as equipes Cross-funcionais que podem endereçar este ponto eficazmente, porque qualquer um pode pegar toda a tarefa pelo menos em alguma extensão.
- Gerencie sua reserva de produto de forma que as dependências entre várias histórias sejam claramente identificadas antes que as histórias sejam recolhidas para um momento de entrega definido. Mais uma vez, isso precisa de muita coordenação e colaboração entre a equipe e o dono do produto. Às vezes o dono do produto pode não ter compreendido as dependências técnicas, assim que em tais cenários a equipe deve ajudar o dono do produto. Exemplo: informar o Login ser priorizado antes de fazer o cadastro do usuário.
- Quando você tem histórias alinhadas (comprometidas) para um compromisso de entrega, não tente manipulá-los durante o período de execução. Ele irá adicionar retrabalho desnecessário e levará a uma perda de velocidade.
- Quando você decompõe a história em tarefas em sua reunião de planejamento do release, tente gastar uma boa quantidade de tempo e envolver todos os membros da equipe. Isso irá ajudá-lo a chegar a _todos_as tarefas necessárias para concluir a história. Se você não fizer isso, você terá uma lista insuficiente de tarefas, mas, na realidade, você terá que executar todas as tarefas para completar uma história. Assim, as tarefas que não são identificadas no seu planejamento do release pode levar a um esforço adicional que não está prevista, por isso pode finalmente empurrar a sua história para um estado “incompleto”.
Desperdício #2: Características extras Significado: Fornecendo mais do que o que está sendo pedido. Lembre-se do princípio de Pareto (80 por cento dos usuários utilizam apenas 20 por cento das características do produto).
Possível razões:
- Falta de compreensão do produto Visão
- Quem está no seu produto “público-alvo”?
- Gold Plating pela equipe de desenvolvimento
- Errado priorização de produto características
Como você pode eliminá-lo?
- O atraso do produto é o bebê do proprietário do produto, que deve mapeá-lo para a visão do produto. Ele ou ela também é responsável pelo ROI do produto. Assim, o proprietário do produto é responsável por gerenciar o atraso do produto de acordo com a visão do produto. Ele deve priorizar o histórias como por o valor.
- Cada produto terá seu próprio público-alvo, os usuários primários do produto. O proprietário do produto tem de certificar-se de identificar o público-alvo, e só então começar a criar o atraso do produto. Se necessário, use personas para identificar os recursos com base no público-alvo.
- Gold Plating geralmente vem da equipe de desenvolvimento, e às vezes pode ser não intencional. Ao priorizar as histórias para um release, o proprietário do produto e a equipe de desenvolvimento têm que chegar a um acordo comum sobre as histórias para esse release, e eles devem ficar com essa lista.
- Desde o planejamento de lançamento, os recursos do produto têm de ser cuidadosamente priorizados. As principais variáveis para priorizar essas histórias são valor, custo e risco.
Desperdício #3: Reaprendizado Significado: Não usando o conhecimento que está disponível dentro dos membros da equipe, tentando reinventar a roda.
Possível razões:
- Falta de um bom processo de compartilhamento de conhecimento dentro da equipe
- Falta de Necessário documentação
- Radiação de informação em falta de osmotic communication
- Distribuídos equipes
Como você pode eliminá-lo?
- A equipe deve compartilhar conhecimento continuamente durante o período de execução do trabalho. Os melhores lugares para compartilhamento de conhecimento são a reunião diária e o quadro kanban. Todos os membros da equipe devem participar de todas as reuniões da equipe. Este vai melhorar conhecimento partilha.
- O mito geral sobre Agile é: “Agile é anti-documentação.” Isso não é verdade. A equipe deve preparar toda a documentação necessária, mas deve sempre ser “Just in time”.
- Tente manter todas as informações importantes exibidas em um espaço de equipe para que todos tenham acesso igual. A osmotic communication desempenha um papel vital na partilha de distribuição de conhecimento. Certifique-se de documentar o “conhecimento tácito” que será repetidamente exigido. Você pode ferramentas de uso como como SharePoint, wiki, etc.
- A Co-Location é a melhor abordagem para a execução de projetos ágeis. Se isso não for possível, devido a quaisquer razões práticas, use ferramentas como videoconferência para que o compartilhamento de conhecimento seja mais fácil.
Quer saber como evitar estes desperdícios? Venha participar do Workshop Lean-Kanban Fundamentals
Até logo!