Olá Habr! Meu nome é Artyom e sou líder de equipe na Skyeng. Minha equipe de desenvolvimento tem um cliente, ele é gerente de produto, é apenas Vanya. Vanya acredita que nosso esquema de pontuação não é perfeito. Por exemplo, uma nota de 2 dias não lhe dá nada. Ele verá sua tarefa à venda em uma semana ou 10 dias ou mais. Ou menos.
Isso acontece não porque estamos com falha nas tarefas, mas porque com a estimativa tradicional, na realidade, só estimamos o tempo que um desenvolvedor leva para escrever código. Mas também há testes e revisão de código. Ok, vamos colocar tudo isso na avaliação. Mas ainda:
- temos uma fila antes do desenvolvimento e teste,
- há melhorias, não estamos sem pecado,
- tarefas urgentes voam
- quando uma implementação afeta vários serviços, esperamos análises de equipes relacionadas.
Como aprender a responder à pergunta "Quando?" , se a previsibilidade está fora de questão?
Como questionamos a estimativa
Nossa equipe, como muitos na empresa, tem uma reunião muito útil - uma revisão técnica (ou, em resumo, uma revisão técnica ). Requer uma quantidade decente de tempo e esforço, mas aumenta a previsibilidade: agendamos uma solução técnica para o problema com antecedência e, ao mesmo tempo, avaliamos.
Como sempre somos remotos, tudo acontece no JIRA: existe um quadro no qual as etapas do trabalho são visualizadas. O cartão sai do status "Revisão técnica" e passa para "Pronto para desenvolvimento" depois de descrevermos e avaliarmos tudo. É neste momento que nos comprometemos a concluir o trabalho.
"Pronto para desenvolvimento" tem um limite WIP - não pode haver mais do que 8 tarefas ao mesmo tempo. Existe a regra oposta: assim que as tarefas na coluna se tornam menos, iniciamos uma nova revisão técnica.
Fato: gastamos uma quantidade significativa de tempo avaliando. Uma revisão técnica geralmente ocorre duas vezes por semana; pode levar de 1,5 a 3 horas para concluir 4 tarefas com um estudo e avaliação detalhados. Mas! Ainda podemos dedicar um tempo para descobrir por que a estimativa foi excedida.
Ao mesmo tempo, nem a avaliação nem o debriefing agregam valor ao nosso produto. Em vez disso, estamos perdendo tempo com eles. E dinheiro. Durante muito tempo, duvidei da necessidade desses procedimentos e, a certa altura, amadureci para uma conversa séria com o produto. E nós dois reconhecemos o problema.
"A camisa está seca e completamente ..." não XS
Decidido: vamos experimentar abordagens de avaliação. Sugeri colar com o tamanho da camiseta - os tamanhos das camisetas são usados como uma unidade de medida nesta técnica. Você precisa encontrar a menor tarefa que precisa executar e confundi-la com o XS. Depois disso, as tarefas restantes são avaliadas com base em "quanto maior elas são XS" - e, dependendo disso, recebem o tamanho S, M, L ou XL.
Subornou a oportunidade de avaliar "a olho". A idéia era simples: acumulamos estatísticas sobre o quanto o desenvolvimento cumpre uma tarefa de uma dimensão ou outra, calcula a média e pode prever o tempo.
Um erro em um dia ou dois será perdoado pelo cliente - o que significa que não haverá mais perguntas. E na revisão de tecnologia, você não precisará perder tempo com votação interativa e secreta. Está tudo bem!
Trabalhamos dessa maneira há vários meses, coletando estatísticas. E apenas Ivan olha de soslaio para nós.
Descobriu-se que XS, como S, fazemos em 1 dia e depois em 10. E em L, gastamos 5 ou até 15 dias. Porque, de fato, trabalhamos primeiro, alguns na segunda e outros na quinta - e tarefas da mesma dimensão passam momentos diferentes em estados de espera. Opa, aqui está a média.
Em suma, a dispersão aqui não é de alguns dias - e para Vani pouco mudou. Reconhecemos o experimento como malsucedido, mas, no entanto, a ideia de que as tarefas podem ser categorizadas de alguma forma está na minha cabeça. E comecei a pensar mais nessa direção.
“Todo mundo adora bolos. Puff! " Burro de Shrek
E eu amo. Além disso, o aniversário de uma criança é uma ótima ocasião! Vou ao meu site favorito e começo a escolher:
- você pode ser assim, mas não pode,
- você pode decorar, mas você não pode decorar,
- É possível 2 kg e 5 kg.
Não revelarei minhas preferências de gosto, mas escolhi um bolo. E eles o trouxeram para a data marcada. A seguir, será apresentada a filosofia do bolo timlid excessivo.
Claro, eu não sou Newton, e o bolo não é uma maçã, mas a inspiração veio.
Eu poderia escolher entre muitas opções, mas, o que quer que escolha, a data de entrega não mudou. Eu precisava de um bolo em uma semana. E eles estavam prontos para fornecer este serviço para mim. E o tamanho do bolo, o peso e todos os tipos de sinos e assobios não afetaram muito o resultado final - mais precisamente, nesse caso, não afetou nada. Não é sobre o tamanho, como se costuma dizer. E em quê? No preço.
Por exemplo, os caras tinham um pedido expresso: por uma taxa adicional, teriam me trazido o mesmo bolo chique em apenas alguns dias, e não em 5. Meu pedido, como o mais valioso em comparação com os outros, teria saído da linha. Basicamente, a padaria possui dois SLAs: um para pedidos regulares e outro para VIP. Há algo em que pensar.
A ideia do SLA foi acionada porque eu li sobre isso no Guia Kanban
Do ponto de vista do método Kanban, tudo é um serviço. E, apesar de não fornecermos bolos e nosso produto não poder ser tocado ou consumido, o desenvolvimento também é um serviço. E também tratamos as tarefas de maneira diferente.
Lembre-se do nosso quadro: O
serviço consiste em várias etapas (desenvolvimento, revisão de código, teste), e a coluna "Pronto para o desenvolvimento" é o nosso ponto de confirmação para o cliente.
Fazemos algumas coisas em nosso ritmo usual, mas quando tarefas de gravação chegam, abandonamos tudo. Resta entender qual o SLA que temos - e será possível concluir um acordo com a Vanya.
Como avaliar o SLA da sua equipe: construindo um diagrama espectral (é simples)
Para entender quais classes de serviço temos e quais SLAs eles têm, Kanban sugere a construção do seguinte cronograma:
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
Encerramos as tarefas nos últimos meses e obtivemos o seguinte:
Encerramos 3 tarefas por dia, 6 - em duas, acima de tudo - em 5, e em algum lugar brigamos por mais de duas semanas ...
Bem, agora é hora de analisar. Quais são essas tarefas? Por que eles acabaram aqui? Por que estamos fazendo em um determinado LT mais do que outros que estão lá? Você pode descobrir clientes e artistas, bem como estudar comentários sobre a tarefa.
Aqui está o que conseguimos descobrir. Este é o nosso trabalho regular .
A propagação é bastante grande, mas pode ser analisada.
Em geral, a maior parte das tarefas foi distribuída no intervalo de 7 a 14 dias, e um casal voou para muito longe - nessa parte, havia várias tarefas (nem todas) do PR para outros serviços. As tarefas concluídas em 3 a 4 dias provavelmente são uma exceção do que uma regra.
, , , 75% 10 .
E com 90% de probabilidade, levará 14 dias. Bem, se o desenvolvimento afetar outros serviços da empresa, demorará um pouco mais para esperar - precisamos de uma revisão de código de outra equipe e depois de outro lançamento.
Vamos mais longe. Nomeamos esta classe como "Importante" .
Por alguma razão, essas tarefas são executadas mais cedo que outras: há mais valor ou um preço de atraso mais alto.
E aqui também podemos expressar o SLA: com uma probabilidade de 75%, a tarefa será vendida em 5 dias, com uma probabilidade de 90% em 7. Vamos continuar?
As próprias tarefas pelas quais desistimos de tudo e vimos, vimos, vimos são bloqueadores .
Em 100% dos casos, essas são pequenas melhorias que não levamos em consideração ao implementar o recurso principal ou bugs que afetam a funcionalidade vital do produto.
Apesar de termos conseguido resolver todas essas situações em dois dias, ainda anunciaremos o 90º percentil. Em primeiro lugar, você não deve prometer 100% - nunca a ninguém :) Em segundo lugar, você precisa criar variabilidade: lembre-se do caso com trabalho regular, quando várias tarefas desapareceram em mais de 20 dias, porque a dependência de outras equipes apareceu.
Feito! Podemos coordenar com o Vanya SLA para todas as classes de serviço:
escolhemos exatamente 90% em termos de tempo - essa é, de fato, a tolerância do cliente à não conformidade. Ou seja, se 1 em cada 10 tarefas não se encaixar no SLA, estamos prontos para perdoá-lo.
Se seu cliente não é tão gentil, é melhor expressar o percentil 95, por exemplo.
Em vez de uma conclusão
- E o que impede Vanya de ganhar apenas tarefas importantes ou bloqueadores?
- Limites WIP horizontais.
Concordamos em limitar o número de tarefas na classe de serviço: você não pode executar mais de dois bloqueadores, não pode executar mais de duas tarefas importantes. Você pode ter outros números - isso é uma questão de acordo com o cliente. Você não pode colocar esses limites no JIRA sem plug-ins, portanto, é definitivamente necessário um acordo verbal. Ferramentas, mas sem interação com pessoas de qualquer lugar.
Obrigado por sua atenção e planejamento bem-sucedido!