Por quê? Algumas tarefas não podem esperar até a próxima semana? É tão importante terminar absolutamente tudo antes do fim de semana? Não, não é tão importante. E tudo isso se deve ao fato de que "executar tarefas é ruim".
Scrum não é mais uma metodologia de desenvolvimento ágil
Cheguei à conclusão de que há muita ênfase no processo de trabalho no Scrum. Ou, pelo menos, as pessoas prestam muita atenção a isso, o que é expresso da seguinte maneira:
- Não há problema em terminar a história do usuário no último dia do sprint. Mas terminar o trabalho na próxima segunda-feira já é uma "transferência de tarefas".
- - ( , ), , , , , .
- , , , . , , , ( , ).
Como resultado, verificou-se que o Scrum não nos ajudou mais a alcançar a meta. Esse método de gerenciamento de projetos agora estava nos limitando.
Com tudo isso, posso observar que os membros da minha equipe começaram a se sentir descontentes com o que estava acontecendo. Isso afetou a qualidade do que criamos. Os programadores estavam mais preocupados em cumprir os prazos do que em alcançar o nível de qualidade desejado.
Nesse ponto, começamos a procurar outras maneiras de organizar o trabalho, procurando outra estrutura ágil que melhor se ajustasse à maneira como trabalhamos.
Então nós encontramos Kanban (Kanban).
O que é Kanban?
O Kanban é um método de gerenciamento de produção que se originou na Toyota na década de 1950. Na época, a Toyota usava um quadro com três colunas: Planejado, Em andamento, Concluído. Essa estrutura permitiu à Toyota alocar recursos com mais eficiência em situações em que surgiram gargalos em algum lugar ao longo da linha de produção.
Então, quando ficou claro que o uso do Kanban poderia aumentar a velocidade do desenvolvimento de software, o Kanban foi transferido para a arena da tecnologia.
Comparação das estruturas Scrum e Kanban
Nos últimos anos, Scrum e Kanban têm lutado para se tornar a principal estrutura ágil. Apesar do fato de o Scrum estar em primeiro lugar , o Kanban está gradualmente se espalhando cada vez mais. E se você compará-los?
Se tomarmos o Scrum como base e compará-lo com o Kanban, obtemos o seguinte:
- , ().
- .
- «». , .
- , , .
- () -.
Uma comparação mais detalhada entre Scrum e Kanban pode ser encontrada aqui .
O Kanban oferece à equipe de desenvolvimento um nível bastante alto de flexibilidade. As histórias de usuários, em comparação com o Scrum, são executadas de maneira mais livre. Mas liberdade é responsabilidade. Embora o Kanban não exija que os desenvolvedores se comprometam a se comprometer a cada duas semanas, esse método de gerenciar o desenvolvimento tem seus próprios controles. Essas são, por exemplo, métricas como tempo de ciclo e taxa de transferência do sistema.
É tudo sobre métricas
É impossível avaliar a eficácia (ou ineficiência) do trabalho sem métricas especializadas. Vamos dar uma olhada nas métricas usadas no Scrum e no Kanban.
▍Métricas de scrum
Ao aplicar o scrum, as seguintes métricas e gráficos são usados:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
É improvável que essas métricas o ajudem a melhorar seu fluxo de trabalho.
"Velocidade" não mede a taxa na qual os subsistemas de produtos acabados são liberados. Essa métrica mede apenas o número de etapas de trabalho concluídas que são relevantes para uma história de usuário. Se uma história demorar mais do que o planejado para ser concluído, essa métrica não terá sentido.
“A proporção do comprometimento do desenvolvedor com o volume de tarefas concluídas” não deve ser considerada uma métrica. Essa "métrica" compara o compromisso com os resultados. Escusado será dizer que isso pode levar as pessoas a fechar e reabrir tarefas apenas para realizá-las.
O diagrama de burnout é algo que eu pessoalmente nunca prestei muita atenção. Isso se deve principalmente ao fato de esses gráficos frequentemente parecerem com o abaixo.
Diagrama de Burnout
Por que isso acontece? Digamos que você comece com um quadro em branco e comece a trabalhar em paralelo, por exemplo, com três histórias de usuários. É provável que essas histórias sejam trabalhadas na mesma velocidade, e é por isso que você pode ver movimentos poderosos para baixo no diagrama de burnout. Além disso, se houver apenas um testador na equipe que deve testar os resultados do trabalho em todas as tarefas, ele será o gargalo da equipe.
Métricas Kanban
Acredito que as métricas são as forças mais importantes do Kanban. O Kanban tem muitas métricas diferentes para ajudar você a entender melhor o que está acontecendo com sua equipe. Por exemplo:
- Rendimento da equipe O número de histórias de usuários que foram concluídas em um determinado período.
- Tempo de ciclo O número de dias necessários para concluir o trabalho do histórico desde o início do trabalho. Métricas como intervalos de confiança são usadas aqui. O mais comum é 85% de confiança.
- Diagrama de fluxo cumulativo Esse diagrama permite visualizar o processo de solução de problemas com base nas histórias do usuário. Este diagrama deve se parecer com o mostrado abaixo.
Fluxograma Cumulativo
Existe um plugin para o Jira que permite tirar proveito de todas essas métricas. Isso é ActionableAgile for Jira - Agile Metrics . Ajuda a explorar métricas relevantes para o desempenho da equipe usando a mesma plataforma usada para gerenciar o trabalho.
Adaptação Kanban
O uso do Kanban "puro" não fornece algumas das operações necessárias ao usar o scrum. Mas esse método de gerenciamento de projetos é flexível o suficiente para permitir, se essas ações parecerem úteis, serem adicionadas ao fluxo de trabalho.
Retrospectivas são um dos tipos mais importantes de reuniões. É nessas reuniões que os membros da equipe podem falar sobre o que alcançaram, o que não correu muito bem e o que pode ser melhorado. Uma retrospectiva é um evento calmo, onde você pode falar sobre seus problemas e parabenizar aqueles que fizeram um excelente trabalho pelo sucesso.
Embora os flashbacks não sejam necessários no Kanban (eles são realizados no final de cada Sprint no Scrum), nós os achamos valiosos e não queremos ignorá-los. De fato, começamos a fazê-lo semanalmente, e não a cada duas semanas como costumávamos. Isso nos permitiu reagir mais rapidamente à ocorrência de qualquer problema. Também usamos essas reuniões para analisar as métricas da equipe e verificar os fluxos de trabalho em busca de problemas e gargalos.
Salvamos mais um elemento dos nossos tempos do Scrum, o que é opcional ao usar o kanban. Trata-se de estimar o tempo necessário para trabalhar em uma história de usuário. Isso é feito no decorrer do esclarecimento das tarefas que aparecem na história. O Scrum usa essas estimativas para entender melhor o que caberá no sprint. Você pode pensar que, como não há sprints no Kanban, a avaliação da história é desnecessária. Mas na verdade não é.
Estimar o tempo necessário para concluir uma história do usuário ajuda a garantir que todos os membros da equipe tenham o mesmo entendimento do escopo das tarefas que precisam ser concluídas durante o trabalho na história. Se alguém der à história uma nota 8 e alguém 3, é óbvio que precisamos continuar discutindo esse assunto. Alguém pode, ao avaliar o momento, levar em consideração alguns problemas que outros desconhecem. No entendimento de alguém, o escopo do trabalho da história do usuário deve incluir algo que outros não consideram como tal.
De fato, tudo isso empurra os membros da equipe para discussões.
Quando algo assim acontece, torna-se óbvio que nem todos têm uma compreensão clara de quanto trabalho precisa ser feito em uma determinada história do usuário.
Outro cenário comum se parece com o seguinte: toda a equipe atribui à laboriosidade da história uma classificação bastante alta (geralmente tudo que tem mais de 8 pontos). Isso fala de incerteza. Isso significa que estamos falando de muito trabalho ou resolvendo problemas muito difíceis, o que torna os membros da equipe desagradáveis. Nesse caso, é melhor dividir a história do usuário em várias histórias menores e definir os objetivos do trabalho com mais clareza.
Resultado
O Scrum permanecerá para sempre em nossos corações como a primeira metodologia ágil generalizada. Mas, à medida que as empresas avançam em direção a esquemas de implantação contínua, o uso de sprints com tempo limitado não faz mais sentido.
Sempre haverá projetos especiais nos quais o Scrum pode ter um bom desempenho. No entanto, dado que as empresas estão cada vez mais usando metodologias ágeis, o Kanban vai gradualmente se destacando, substituindo Scrum.
O que melhor combina com você? Scrum ou Kanban?
