Melhoria contínua com Kanban em uma equipe de desenvolvimento do TST
•
2 gostaram•669 visualizações
Este documento descreve a jornada de uma equipe de desenvolvimento do TST para melhorar seu processo usando Kanban. Inicialmente, a equipe tinha problemas com tamanho do time, alto trabalho em progresso e estoque de defeitos. Experimentos como dividir o time, limitar WIP e mostrar métricas reduziram esses problemas e melhoraram métricas como entregas e lead time. A equipe continua evoluindo seu processo com foco em priorização e previsibilidade.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (17)
Semelhante a Melhoria contínua com Kanban em uma equipe de desenvolvimento do TST
Semelhante a Melhoria contínua com Kanban em uma equipe de desenvolvimento do TST (20)
Último
Último (8)
Melhoria contínua com Kanban em uma equipe de desenvolvimento do TST
- 1. Melhoria Contínua com Kanban em uma Equipe de desenvolvimento do TST Rodrigo Cardoso Vieira rodrigo.vieira@tst.jus.br
- 2. Ambiente TST Caracterização do ambiente do TST.
- 3. 2014 A equipe de desenvolvimento de sistemas jurídicos do TST em Janeiro de 2014 tinha 12 desenvolvedores (analistas e programadores) e chegou em maio com 13. Com horários de trabalho variados fica difícil encontrar todos ao mesmo tempo e realizar os ritos previstos nos métodos ágeis.
- 4. 2014 Desde 2014, esta equipe de sistemas jurídicos já trabalhava com um quadro Kanban, com replicação na ferramenta Jira.
- 5. Técnicas As práticas e técnicas ágeis utilizadas em 2014 eram integração contínua e reuniões de retrospectiva. As reuniões diárias eram feitas esporadicamente. Pair programming e TDD não eram praticados de forma consistente por toda a equipe.
- 6. Tipos de demandas Manutenções Pequenas Melhorias Correção de defeitos ~30 Sistemas Projetos Sistemas Novos Evoluções Tarefas Auditorias Relatórios avançados Esta equipe de desenvolvimento é responsável por Manutenções, Projetos e Tarefas.
- 7. Cursos 2012 Hoje A equipe vem realizando cursos sobre desenvolvimento ágil desde 2012, o que cria um ambiente mais propício para a mudança de mindset necessária.
- 9. Evolução do Processo Kanban é evolutivo. A implantação do método é gradual e evolutiva. A estratégia é observar o sistema, mapear o fluxo de trabalho e melhorá-lo continuamente. Não existe um estágio final de implantação do método. O time está sempre evoluindo e se adaptando ao ambiente.
- 10. Mapeamento Visual Kanban se baseia no mapeamento e gerenciamento visual do trabalho. Cada post-it representa um item de trabalho.
- 11. Limitar Work in Progress Kanban limita o trabalho em progresso para entregar mais rápido cada item. Menos trabalho em progresso, menor o tempo de ciclo (Lead Time).
- 12. Ciclos de Feedback De quais feedback loops vou falar? Kanban utiliza ciclos de feedback para evoluir e adaptar o processo de desenvolvimento. TDD, reuniões diárias, reuniões de demonstração do produto e reuniões de retrospectiva determinam ciclos de feedback que permitem a melhoria contínua do processo.
- 13. Resultados Apresentação dos resultados na comparação de janeiro a maio de 2015 em relação ao mesmo período de 2014.
- 14. Número de itens em produção 141 ~71% jan-mai Neste período, houve um aumento de 71% na taxa de entrega (demandas em produção).
- 15. Aumento da equipe 2014 2015 ~30% Parte desse aumento pode ser explicado pelo aumento da equipe no período. Mesmo assim, o saldo fica em cerca de 40% mais entrega do que em 2014.
- 16. Distribuição dos itens ~5% Histórias Além disso, houve proporcionalmente mais entrega de valor. 5% a mais de histórias.
- 17. Lead Time Houve impacto também na redução do Lead Time. O Lead Time é o tempo entre uma demanda começar a ser desenvolvida até ela entrar em produção. Em 2015 vemos que as linhas tendem a convergir para 30 dias.
- 18. Evoluções no Processo Quais alteração foram feitas no processo neste período?
- 19. Time Grande Problema 1 O primeiro problema era o um único time grande.
- 20. Problema P1 P2 P3 M Coordenação Previsibilidade para projetos Um única equipe de 13 pessoas podia trabalhar em qualquer projeto em andamento ou em manutenção. Gerando dificuldade de coordenação (era difícil encontrar todos nas reuniões). Afetando também a previsibilidade dos projetos pois o desenvolvedor podia escolher em qual projeto trabalhar. Então um projeto poderia estar andando mais rápido, mas poderia diminuir a velocidade a qualquer momento.
- 21. Experimento P1 P2 P3 M Reuniões diárias Retrospectivas Maior foco em cada problema O time único foi dividido em times menores. Cada time passou a ter um foco no trabalho.
- 22. Muito Trabalho em Progresso (WIP) Problema 2
- 23. Problema Cada post-it representa um item de trabalho. Claramente temos muito coisa sendo executada ao mesmo tempo para o tamanho da equipe.
- 24. WIP alto Problema Mais defeitos Mais tempo corrigindo defeitos Multitarefa Lead Time alto Ciclo de Feedback longo
- 25. WIP Limitado Situação Time não respeitava o limite Cultura? Não havia incentivos? Já está bagunçado mesmo !
- 26. 1. Retirar os limites de WIP Experimento 2. Não priorizar nada do backlog 3. Esperar o WIP baixar 4. Reintroduzir os limites de WIP A estratégia utilizada.
- 27. Experimento Vemos os WIP menor aqui e a volta dos limites nos post-ir azul escuro.
- 29. Alto Estoque de Defeitos Problema 3
- 30. Problema Março de 2015 200 Defeitos? Itens velhos? ? Mais de 200 defeitos em estoque. Dúvidas: quais eram defeitos? Existem itens velhos? O que está neste estoque?
- 31. Experimento Inclusão de um gráfico para mostrar o estoque de defeitos.
- 32. Experimento 200 75 25 dias úteis Estoque de defeitos Detalhe do gráfico que foi colocado ao lado do quadro kanban. Deixando a informação à vista e não escondida em algum sistema.
- 33. Experimento 25 Estoque de defeitos Gráfico transferido para planilha.
- 34. Experimento Estoque de defeitos reduzido e mantido baixo Estratégia: Criamos um feedback loop que não existia.
- 35. Falta de critério para priorização na manutenção Problema 4
- 36. Demandas chegam diariamente Problema Mais antigas perdem prioridade Falta de coesão entre as priorizadas Defeito chegou Prioriza
- 37. Experimento Priorizar Semanalmente Sistema Puxado O que é mais importante agora? Ordem de priorização != chegada
- 38. Experimento Demandas não envelhecem no quadro Formação de time Implantação mais simples 1 semana
- 39. O que temos pela frente?
- 40. Problemas a vista Rodízio de devs entre os times não está permitindo o desenvolvimento dos times. Melhorar a previsibilidade dos projetos. Melhorar a priorização dos projetos. TDD? Continuous Delivery?
- 41. Finalizando... Melhorar a gestão tem um alto poder de alavancagem no processo de desenvolvimento de software. Barry Boehm - Software Engineering Economics David Anderson: Lessons in Agile Management Kanban nos possibilitou ver as oportunidades de melhoria e atuar nelas.
- 42. Obrigado!
Notas do Editor
- Caracterização do ambiente do TST de onde saiu este trabalho.
- A equipe de desenvolvimento de sistemas jurídicos do TST em Janeiro de 2014 tinha 12 desenvolvedores (analistas e programadores) e chegou em maio com 13. Com horários de trabalho variados fica difícil encontrar todos ao mesmo tempo e realizar os ritos previstos nos métodos ágeis.
- Desde 2014, esta equipe de sistemas jurídicos já trabalhava com um quadro Kanban, com replicação na ferramenta Jira.
- As práticas e técnicas ágeis utilizadas em 2014 eram integração contínua e reuniões de retrospectiva. As reuniões diárias eram feitas esporadicamente. Pair programming e TDD não eram praticados de forma consistente por toda a equipe.
- Esta equipe de desenvolvimento é responsável por Manutenções, Projetos e Tarefas.
- A equipe vem realizando cursos sobre desenvolvimento ágil desde 2012, o que cria um ambiente mais propício para a mudança de mindset necessária.
- Principais características de Kanban.
- Kanban é evolutivo. A implantação do método é gradual e evolutiva. A estratégia é observar o sistema, mapear o fluxo de trabalho e melhorá-lo continuamente. Não existe um estágio final de implantação do método. O time está sempre evoluindo e se adaptando ao ambiente.
- Kanban se baseia no mapeamento e gerenciamento visual do trabalho. Cada post-it representa um item de trabalho.
- Kanban limita o trabalho em progresso para entregar mais rápido cada item. Menos trabalho em progresso, menor o tempo de ciclo (Lead Time).
- Kanban utiliza ciclos de feedback para evoluir e adaptar o processo de desenvolvimento. TDD, reuniões diárias, reuniões de demonstração do produto e reuniões de retrospectiva determinam ciclos de feedback que permitem a melhoria contínua do processo.
- Apresentação dos resultados na comparação de janeiro a maio de 2015 em relação ao mesmo período de 2014.
- Neste período, houve um aumento de 71% na taxa de entrega (demandas em produção).
- Parte desse aumento pode ser explicado pelo aumento da equipe no período. Mesmo assim, o saldo fica em cerca de 40% mais entrega do que em 2014.
- Além disso, houve proporcionalmente mais entrega de valor. 5% a mais de histórias.
- Houve impacto também na redução do Lead Time. O Lead Time é o tempo entre uma demanda começar a ser desenvolvida até ela entrar em produção. Em 2015 vemos que as linhas tendem a convergir para 30 dias.
- Quais alteração foram feitas no processo neste período?
- O primeiro problema era o um único time grande.
- Um única equipe de 13 pessoas podia trabalhar em qualquer projeto em andamento ou em manutenção. Gerando dificuldade de coordenação (era difícil encontrar todos nas reuniões). Afetando também a previsibilidade dos projetos pois o desenvolvedor podia escolher em qual projeto trabalhar. Então um projeto poderia estar andando mais rápido, mas poderia diminuir a velocidade a qualquer momento.
- O time único foi dividido em times menores. Cada time passou a ter um foco no trabalho.
- Cada post-it representa um item de trabalho. Claramente temos muito coisa sendo executada ao mesmo tempo para o tamanho da equipe.
- A estratégia utilizada.
- Vemos os WIP menor aqui e a volta dos limites nos post-ir azul escuro.
- Mais de 200 defeitos em estoque. Dúvidas: quais eram defeitos? Existem itens velhos? O que está neste estoque?
- Inclusão de um gráfico para mostrar o estoque de defeitos.
- Detalhe do gráfico que foi colocado ao lado do quadro kanban. Deixando a informação à vista e não escondida em algum sistema.
- Gráfico transferido para planilha.