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