Olá. Deixe-me contar a você sobre minha experiência na avaliação de produtos de software. Há 15 anos faço isso sem interrupções e gostaria de compartilhar minha experiência e a evolução de minhas visões sobre avaliação. Tenho certeza de que será útil. Vamos começar com o estabelecimento de metas. Por que medir? Quem precisa disso?
A resposta é realmente muito simples - as pessoas querem certeza, em particular a resposta à pergunta "quando ela estará pronta?" Quando posso sair de férias, quando as vendas começam, quando fazer uma tarefa relacionada. Por outro lado - você nunca sabe o que as pessoas querem, por que devido ao desejo de outras pessoas de perderem seu tempo com essa atividade?
Mas, afinal, todos nós gostaríamos de receber um salário, e o salário não aparece do nada, a empresa tira do produto, em um caso separado - dos investimentos. E para que essa receita seja, precisamos atingir uma meta de negócios. E as pessoas que formulam metas de negócios gostam muito de todos os tipos de fórmulas financeiras - ROI, LTV e outros EBITDA. E essas fórmulas constantemente apresentam prazos. Sem eles, o crocodilo não é apanhado, o coco não cresce.
Há também uma segunda razão, um pouco menos importante: se as estimativas para os recursos forem claras, isso afetará sua prioridade, tarefas mais simples tendem a receber prioridade mais alta. Como na abordagem ágil convencional, o backlog é regularmente abalado, as informações de entrada sobre as classificações de tarefas ajudam a tornar o processo de repriorização mais eficiente.
Como consequência: muito provavelmente, você ainda terá que avaliar. Humilhe-se .
Agora vamos falar sobre como fazer isso, para não amaldiçoar tudo e todos no processo. Como as pessoas que não sabem avaliar o material de TI costumam se classificar? Como isso:
- Avaliamos todo o trabalho em dias pessoais.
- Adicione 10% apenas no caso.
- Divida pelo número de desenvolvedores.
- Adicionamos o número de dias resultante à data atual e obtemos a data final.
- Isso é tudo.
Por causa disso, flashbacks vietnamitas da foto do título ainda estão piscando diante dos meus olhos: muitos dos meus nervos estavam perdidos nesta guerra. E vai morrer por você se começar a avaliar dessa forma. O problema é que esse é exatamente o tipo de avaliação que se espera de você:
“Não brinque com seus pontos de história, mostre sua mão.”
Quais problemas serão enfrentados durante a avaliação
Vamos começar com uma situação ideal:
- Temos uma tarefa atômica (simples, indivisível).
- Não tem dependências de outras tarefas, não há necessidade de coordenar nada.
- Existe uma pessoa 100% dedicada à tarefa que sabe fazer.
Mesmo neste caso, surge a questão "Quem fará a avaliação?" Nesse momento, a implacável máquina de controle é acionada. Primeiro, o gerente pensa: se o desenvolvedor vai fazer isso, o que o impedirá de especificar altos custos de mão de obra para brincar? -> Portanto, o gerente avalia ele mesmo a tarefa. -> No entanto, o gerente não entende o assunto profundamente o suficiente e não vê (ou não quer ver) as armadilhas. -> A estimativa acaba sendo irremediavelmente subestimada. -> A equipe não cumpre o prazo. -> Morte e decadência.
A situação descrita acima é um problema clássico da cultura corporativa de desconfiança de seus funcionários. No entanto, a maioria dos desenvolvedores tem uma motivação intrínseca para resolver problemas interessantes, para eles é muito mais atraente do que bancar o idiota do computador, então não há motivo para desconfiança generalizada. Em geral, uma empresa deve ser construída com base na presunção de confiança em seus funcionários, e não distorcer os processos normais de negócios para parecerem ovelhas negras.
Uma cultura de desconfiança é muito comum em conjunto com uma cultura corporativa de medo: mesmo que um desenvolvedor esteja avaliando uma tarefa, o que acontece em sua cabeça durante a avaliação? Ele responde à pergunta: "Como minha empresa reage à discrepância entre as datas planejadas e reais?" Se o desenvolvedor for repreendido pelos prazos não cumpridos, ele os superestimará. Se as avaliações posteriores do desenvolvedor forem interrompidas para as tarefas feitas com antecedência, ele não entregará as tarefas com antecedência.
O mais novo exemplo de uma cultura de medo é o lançamento de Cyberpunk 2077. O jogo foi lançado com uma qualidade nojenta em consoles da geração anterior. O CEO da empresa disse em um comunicado que "ao que parece, muitos dos problemas que você encontrou no jogo não foram encontrados durante os testes." O que, claro, é uma mentira total. Os problemas eram visíveis a olho nu, os testadores fisicamente não podiam perder isso. Esta é uma situação típica em uma cultura de medo: os problemas são abafados. Assim, as informações ao longo do caminho até o último andar da administração foram de “jogo não jogável em consoles básicos” para “vamos lançar”.
Se este não for o seu caso, você pode avaliar melhor. Se você não tem sorte com a cultura da empresa, não leia mais, porque você precisa fazer avaliações não para fins de precisão, mas para minimizar chutes das autoridades, e essa é uma tarefa completamente diferente.
E então você deu uma estimativa, por exemplo - 1 semana. Este é apenas seu palpite, nada mais. A avaliação determina a data de conclusão planejada de uma tarefa, mas não pode determinar quando ela realmente será concluída. Onde exatamente o tempo real de conclusão da tarefa estará é descrito por uma distribuição normal. Por enquanto, vamos apenas lembrar disso como um axioma, no final haverá uma reviravolta na história.
Tudo se complica ainda mais pelo fato de que algumas tarefas não são fundamentalmente divididas em partes e também acontece que não podem ser paralelizadas. Existem também tarefas interdependentes, você precisa mergulhar no contexto das tarefas. Além disso, ao desenvolver, a equipe precisa se comunicar para sincronizar suas atividades.
Também não sabemos ver o futuro. Como resultado, surgem constantemente tarefas que não previmos e não podíamos prever. O que poderia ser?
- Desejos do cliente ou proprietário do produto.
- Problemas repentinos, para os quais algo precisa ser melhorado.
- Legal inesperado.
- E toneladas de coisas.
O mais imprevisível é o problema da velocidade diferente dos desenvolvedores.
Para desenvolvedores reais do mesmo nível e com o mesmo salário, a produtividade pode diferir em uma ordem de magnitude:
- Alguém cortará e depurará o código por uma semana e alguém danificará a biblioteca aberta em meio dia.
- Alguém vai fumar Stack Overflow, e alguém já resolveu esses problemas e vai começar a se beneficiar imediatamente.
Como resultado, nosso gaussiano se transforma em algo assim (a estimativa parece a mesma quando a tarefa não é suficientemente dimensionada):
Em geral, tudo é complicado, não estamos cavando trincheiras aqui. Como você pode tirar uma boa nota nessas condições?
Critérios de boa nota:
- Alta velocidade de avaliação - a avaliação em si não traz nenhum valor para o negócio, por isso é lógico fazer o mais rápido possível para não se distrair do desenvolvimento.
- A avaliação é responsabilidade de toda a equipe, e há um bom princípio do “você avalia, você faz” que protege a equipe de marcas de teto.
- Não se esqueça de todos os componentes da saída de um recurso em produção - análises, desenvolvimento, testes de unidade, autotestes, testes de integração, devops. Tudo isso deve ser avaliado.
Como você pode ver, não escrevi nada sobre precisão. Durante os 15 anos em que fiz estimativas, não aprendi a fazê-las com precisão, então sejamos mais modestos e tentemos estimar pelo menos aproximadamente. Todo o processo de avaliação é assim:
- Colocar tarefas no backlog do produto.
- Avaliamos as histórias de maior prioridade no backlog usando qualquer método (há muitos métodos, falarei sobre eles a seguir).
- Começamos a trabalhar (por exemplo, no Scrum - por sprints).
- Após vários sprints, medimos quantos pontos de história obtemos em média a cada iteração. Esta é a nossa velocidade - velocidade média de desenvolvimento da equipe.
- . burndown chart. , .
Mas o mundo não é perfeito, então corrigimos quantos novos recursos (também estimados em pontos da história) nosso Product Owner gera a cada sprint. A linha vermelha mostrará o crescimento da carteira, agora a intersecção das linhas vermelha e azul é a data desejada.
Se o Product Owner for muito criativo, então pode até ser assim:
E agora nos lembramos que a avaliação obedece às leis da distribuição normal, mas a reviravolta na história - tais gaussianas somam-se perfeitamente. Portanto, é o que resulta (isso é chamado de gráfico burndown encantado):
Parece que o sonho de um jovem matemático se tornou realidade: de um monte de caos, obtivemos um belo gráfico e podemos transmitir com um olhar inteligente que “ com 50% de probabilidade terminaremos no sprint 14, com 80% de probabilidade no dia 17, de 95% - no dia 19 ".
Existem várias armadilhas em todo esse processo.
Em primeiro lugar, direi imediatamente sobre o elefante na sala: o backlog é grande, há muitas tarefas sobre as quais nada se sabe, exceto a descrição no formato da história do usuário, então a estimativa será muito aproximada em qualquer caso. Já mostrei acima como uma estimativa aproximada se parece na linguagem da matemática.
Em segundo lugar, o problema "os desenvolvedores trabalham com produtividade diferente" não é resolvido de forma alguma em princípio... Isso significa que obtemos um aumento muito plano na probabilidade, o que não ajuda muito na tomada de decisões de gestão: “com 50% de probabilidade terminaremos no 14º sprint, com 80% de probabilidade - no 27º, com 95% - na 39ª ”- então, na linguagem da matemática, soa como“ um dedo para o céu ”.
Portanto, eu pessoalmente maximizo a métrica de "taxa de avaliação" e agora contarei os métodos que tentei.
Método de planejamento de pôquer
Essa é uma das técnicas de avaliação mais populares, provavelmente por ser a mais antiga.
- Os participantes do processo usam cartões especialmente numerados com números de Fibonacci.
- O Dono do Produto faz um breve anúncio da próxima história e responde às perguntas da equipe.
- Depois de receber as informações, os participantes do “poker” escolhem uma carta com uma avaliação adequada, na sua opinião, e não a mostram a ninguém.
- Em seguida, todos são revelados juntos, e os participantes com as pontuações mais baixa e mais alta fazem pequenos comentários explicando sua escolha de pontuação.
- Como resultado do processo de discussão, a equipe chega a uma única decisão e então passa para a próxima história.
Durante uma sessão de uma hora dessa forma, você pode avaliar de 4 a 8 histórias. Este é o maior problema com este método - é longo, as pessoas ficam entediadas e distraídas. Não foi à toa que usei a frase "todos são revelados juntos".
O método de "ordem de construção"
Esta é a abordagem que estamos usando atualmente no trabalho. O objetivo é avaliar as tarefas em relação umas às outras. É assim que uma sequência de tarefas classificadas por dificuldade é construída. Para este método, você deve primeiro acumular um conjunto de tarefas avaliadas e colocá-las na escala.
- Quando é hora de avaliar, cada membro da equipe se reveza fazendo seu movimento (como em um jogo de tabuleiro). Os movimentos podem ser os seguintes: coloque a tarefa na escala, mova a tarefa ao longo da escala, discuta a história com os colegas, pule sua jogada.
- Como resultado, as tarefas estão em constante movimento no quadro, sua avaliação em relação às outras é refinada até que seja obtido um estado que satisfaça toda a equipe.
- Quando todos os participantes perderem sua vez, você estará pronto.
Esta é uma técnica rápida. Com sua ajuda, você pode estimar 15-20 histórias por hora, o que normalmente é o suficiente.
Método grande / pequeno / obscuro
Já usei várias vezes, mas não criou raízes.
- Três zonas estão marcadas no tabuleiro: "tarefa grande", "tarefa pequena" e "informação insuficiente".
- , «/». « » = « ».
- .
O método tem uma grande vantagem - é super rápido. Assim, você pode processar 50 histórias de usuário por hora.
Aqui, há um problema em traduzir essas estimativas em pontos da história, mas quando a velocidade da equipe já é conhecida, então entendemos quantos pontos da história uma pessoa vai mastigar por sprint em Jira e avaliamos pequenas tarefas em torno dessa métrica.
Quanto ao resto das tarefas. Enviei tarefas da área de "informações insuficientes" para a analítica e tarefas da "tarefa grande" - para a decomposição, para que pudessem ser reavaliadas na próxima sessão.
Como resultado, em nosso produto simplesmente traçamos um roteiro com recursos que achamos que teremos tempo para escrever em um futuro próximo. Se não tivermos tempo - bem, isso acontece. E usamos estimativas apenas para as tarefas imediatas, que normalizamos, e mesmo assim, nem sempre.
Talvez eu esteja empenhado em lançar minha incompetência no campo da avaliação em termos pseudocientíficos, mas para mim pessoalmente, o processo em si parece um tanto estúpido, como um estranho culto à carga que tocamos para fingir que somos o mesmo estáveis e indústria previsível, como alguma outra indústria realmente estável e previsível. Eu adoraria ler sobre sua experiência nesta área, talvez esteja faltando alguma coisa.