O Instituto ensina algoritmos, estruturas de dados, OOP. Em um bom caso, eles podem falar sobre padrões de design ou programação multithread. Mas não ouvi como avaliar corretamente os custos de mão-de-obra.

Enquanto isso, todo programador precisa dessa habilidade todos os dias. Sempre há mais trabalho do que pode ser feito. A avaliação ajuda a priorizar corretamente e a abandonar completamente algumas tarefas. Sem mencionar questões domésticas como orçamento e planejamento. Estimativas incorretas, pelo contrário, criam um monte de problemas: subestimados - situações de conflito, processamento e falhas nos orçamentos, superestimadas - cancelamento de projetos ou procura de outros artistas.

Para ser justo, deve-se notar que a desvalorização é muito mais comum no desenvolvimento. Porque Alguém acha que os programadores são muito otimistas por natureza. Acrescentarei mais uma razão para isso: ser um bom programador e um bom avaliador não é a mesma coisa. Para se tornar um bom programador, um desejo não é suficiente. Precisa de conhecimento e prática. Por que a avaliação seria diferente?

No artigo, falarei sobre como minha atitude em avaliar tarefas mudou e como os projetos em nossa empresa estão sendo avaliados. E vou começar com como você não precisa avaliar. Se você já sabe como "não", vá diretamente para a segunda parte do artigo .

Padrões Anti-Avaliação

A maioria das avaliações em projetos é feita no início de seu ciclo de vida. E isso não nos incomoda até entendermos que as estimativas foram obtidas mais cedo do que os requisitos foram determinados e, consequentemente, mais cedo do que a tarefa em si foi estudada. Consequentemente, uma avaliação geralmente não é feita no prazo. Esse processo é chamado corretamente de não avaliação, mas adivinhação ou previsão, porque cada ponto nos requisitos é um jogo de adivinhação. Quanto essa incerteza afeta os resultados finais da avaliação e sua qualidade?

Um pouco, mas desagradável

Suponha que você esteja desenvolvendo um sistema de entrada de pedidos, mas ainda não foi capaz de desenvolver requisitos para inserir números de telefone. Entre as incertezas que podem afetar a avaliação do programa, podemos destacar imediatamente o seguinte:

O cliente precisa que o número de telefone digitado seja verificado quanto à validade?
Se o cliente precisar de um sistema de verificação de número de telefone, qual versão ele prefere - barato ou caro?
Se você implementar uma versão barata da verificação de números de telefone, o cliente desejará mudar para a cara mais tarde?
É possível usar um sistema pronto para verificar números de telefone ou, devido a algumas restrições de design, você precisa desenvolver o seu próprio?
Como o sistema de verificação será projetado?
Quanto tempo leva para programar um sistema de verificação de número de telefone?

E essas são apenas algumas perguntas da lista que surgem na cabeça de um gerente de projeto experiente ... Como pode ser visto até mesmo neste exemplo, diferenças em potencial na definição, design e implementação das mesmas oportunidades podem acumular e aumentar o tempo de implementação em centenas ou mais vezes. E se as combinarmos em centenas e milhares de funções de um grande projeto, obtemos enorme incerteza na avaliação do próprio projeto.

Outro excelente exemplo de “inchaço” parece ser um requisito básico, lido no artigo “ Como estão as duas semanas ?! ”

Cone da Incerteza

O desenvolvimento de software - e muitos outros projetos - consiste em milhares de soluções. Os pesquisadores descobriram que as estimativas do projeto em diferentes estágios são inerentes aos níveis projetados de incerteza. O cone de incerteza mostra que as estimativas se tornam mais precisas à medida que o projeto avança. Observe que, no estágio do conceito inicial (onde as estimativas são frequentemente feitas e as obrigações são feitas), o erro pode ser de 400% (quatrocentos por cento, Karl!). É ideal assumir compromissos após a conclusão do projeto detalhado.

Mítico homem-mês

Ainda existem executivos que acreditam que, se a funcionalidade for rigidamente fixa, uma redução no tempo poderá ser alcançada a qualquer momento, adicionando-se uma equipe que faria mais trabalho em menos tempo. O erro desse raciocínio está na própria unidade de medida usada na avaliação e no planejamento: homem-mês. O custo é realmente medido como o produto do número de funcionários e do número de meses gastos. Mas o resultado não é alcançado. Portanto, o uso de homens-mês como unidade de medida do volume de trabalho é um equívoco perigoso. Todos os pesquisadores concordaram que a redução do período nominal aumenta a quantidade total de trabalho. Se o prazo nominal para um grupo de 7 pessoas for 12 meses, um simples aumento de pessoal para 12 pessoas não reduzirá o período para 7 meses.

Em grandes grupos, os custos de coordenação e gerenciamento aumentam e o número de caminhos de comunicação aumenta. Se todas as partes da tarefa devem ser coordenadas separadamente entre si, o custo da comunicação aumenta quadraticamente e o “poder” da equipe cresce linearmente. Três trabalhadores exigem três vezes mais comunicação pareada que dois, quatro por seis.

imagem

A equipe do projeto está tentando lidar com a garupa // Ivan Aivazovsky, 1850

Se 8 pessoas podem escrever um programa em 10 meses, 80 pessoas podem escrever o mesmo programa em um mês? A ineficiência de prazos extremamente rigorosos se torna especialmente evidente em casos extremos - como 1.600 pessoas que precisam escrever um programa em um dia. Leia mais sobre isso no livro de mesmo nome de Frederick Brooks .

Padrões de avaliação

Então, com os problemas, tudo está claro. O que pode ser feito?

Decomposição

Em vez de avaliar uma tarefa grande, é melhor dividi-la em muitas pequenas, avaliá-las e obter a nota final como a soma das notas iniciais. Assim, matamos imediatamente até quatro pássaros com uma pedra:

Entendemos melhor o escopo do trabalho. Para decompor uma tarefa, você precisa ler os requisitos. Lugares inexplicáveis emergirão imediatamente. O risco de interpretar erroneamente os requisitos é reduzido.
Durante a análise de uma análise mais detalhada dos requisitos, o processo de pensamento de sistematização do conhecimento é iniciado automaticamente. Isso reduz o risco de esquecer parte do trabalho, como refatoração, automação de testes ou o esforço extra de planejar e implantar
O resultado da decomposição pode ser usado para gerenciamento de projetos, desde que para os dois processos uma ferramenta tenha sido usada (esse problema será discutido em mais detalhes posteriormente no texto).
Se medirmos o erro médio da estimativa de cada problema obtido durante a decomposição e comparar esse erro com o erro da estimativa total, verifica-se que o erro total é menor que a média. Em outras palavras, essa avaliação é mais precisa (mais próxima dos custos reais do trabalho). À primeira vista, essa afirmação é contra-intuitiva. Como a avaliação final pode ser mais precisa se cometermos um erro na avaliação de cada problema decomposto? Considere um exemplo. Para criar um novo formulário, você precisa: a) escrever o código no back-end, b) criar o layout e escrever o código no front-end, c) testar e fazer o layout. A tarefa A foi avaliada às 5 horas, as tarefas B e C às 3 horas cada. A pontuação total foi de 11 horas. Na realidade, o back-end foi feito em 2 horas, o formulário levou 4 e o teste e a correção de erros levou outros 5. A carga de trabalho total foi de 11 horas. Ideal para ser avaliado. Além disso, o erro na avaliação da tarefa A é de 3 horas, a tarefa B é de 1 hora e C é de 2 horas. O erro médio é de 3 horas. O fato é que os erros de subestimar e superestimar as estimativas se anulam. As 3 horas economizadas no back-end compensavam o atraso de 1 e 2 horas nos estágios de front-end e teste. O trabalho real é uma variável aleatória que depende de muitos fatores. Se você ficar doente, será difícil se concentrar e, em vez de três horas, poderá levar seis. Ou surgirá algum erro inesperado que precisará ser pesquisado e corrigido o dia todo. Ou, inversamente, pode acontecer que, em vez de escrever seu próprio componente, você possa usar um componente existente etc. Desvios positivos e negativos serão cancelados. Assim, o erro total diminuirá.

Recursos e tarefas

No coração da decomposição que temos é o Feature. Um recurso é uma unidade de entrega de funcionalidade que pode ser colocada em produção independentemente de outros. Às vezes, esse nível é chamado História do Usuário, mas chegamos à conclusão de que a História do Usuário nem sempre é adequada para a definição de tarefas, por isso decidimos usar uma formulação mais geral.

Um membro é responsável por um recurso. Alguém pode ajudá-lo com a implementação, mas uma pessoa passa para o teste. A tarefa também está sendo devolvida a ele para revisão. Dependendo da organização da equipe, este pode ser um líder de equipe ou diretamente um desenvolvedor.

Infelizmente, às vezes há grandes recursos. Levará muito tempo para trabalhar sozinho nesse volume. E por muito tempo você terá que testar e implementar o processo de aceitação. Depois, alteramos o tipo de tarefa para Epic. Epic é apenas um recurso muito grosso. Não começamos nada além de um épico. I.e. épicos podem ser grandes, enormes ou gigantescos. De qualquer forma, o épico é enviado em partes (recursos) para a aceitação.

Para avaliar com mais precisão, os recursos são decompostos em subtarefas separadas (Tarefa). Por exemplo, um recurso pode ser o desenvolvimento de uma nova interface CRUD. A estrutura das tarefas pode ser assim: "exibir uma tabela com dados", "agilizar a filtragem e a pesquisa", "desenvolver um novo componente", "adicionar novas tabelas ao banco de dados". A estrutura das tarefas geralmente não é de todo interessante para os negócios, mas é extremamente importante para o desenvolvedor.

Avaliação em grupos, planejamento de pôquer

Os programadores estão otimistas demais com a quantidade de trabalho. De acordo com várias fontes, a desvalorização geralmente varia na faixa de 20 a 30%. No entanto, em grupos, o erro é reduzido. Isso se deve a uma melhor análise devido a diferentes pontos de vista e avaliação do temperamento.
A prática mais comum com a crescente popularidade do Agile é a prática do " planejamento de pôquer ", mas dois problemas estão associados à avaliação em grupo:

Pressão social
Custos de tempo

Pressão social

Em quase todos os grupos, a experiência e a eficácia pessoal dos participantes variam. Se a equipe tem uma equipe / tecnologia forte - o líder / programador líder, outros membros podem se sentir desconfortáveis e subestimar deliberadamente as notas: “Bem, como Vasya pode fazer isso, mas eu sou pior? Eu também posso fazer isso! As razões podem ser diferentes: o desejo de parecer melhor do que realmente é, a concorrência ou apenas o conformismo. O resultado é um: uma avaliação em grupo perde todas as suas vantagens e se torna individual. Timlid dá notas, e o resto simplesmente concorda com ele.

Por muito tempo, pressiono a equipe a fim de obter classificações mais consistentes com minhas expectativas. Isso invariavelmente levou a uma diminuição na qualidade e uma quebra nos termos. Como resultado, mudei de atitude e agora minha classificação geralmente é a maior. Durante a discussão, aponto possíveis problemas que vêm à mente: “aqui a refatoração não faria mal, aqui a estrutura de nosso banco de dados está mudando, seria necessário fazer um teste de regressão”.

Existem várias recomendações principais:

A maioria das classificações está subestimada. Não pode escolher entre duas classificações? Pegue o que é maior.
Não tem certeza da avaliação - jogue fora o cartão "?" ou uma ótima classificação. Talvez quase nunca carregue.
Sempre compare plano e fato. Se você sabe que não se encaixa duas vezes, faça uma estimativa duas vezes maior do que pensa. Começou a exagerar? Multiplique em sua mente por um ano e meio. Após algumas iterações, a qualidade de suas notas deve melhorar significativamente.

Custos de tempo

Você conhece a frase "Deseja trabalhar?" Reúna uma reunião! Não apenas um programador tenta prever o futuro em vez de escrever código. Agora o grupo todo faz isso. Além disso, elaborar uma decisão em um grupo é um processo muito mais longo do que tomar decisões individuais. Assim, a avaliação em grupo é um processo extremamente caro. Vale a pena olhar para esses custos do outro lado. Primeiro, no processo de avaliação, o grupo é forçado a discutir os requisitos. Isso significa que você precisa lê-los. Já não é ruim. Em segundo lugar, vamos comparar esses custos com aqueles que a empresa incorre devido à subestimação do projeto.

Muitos anos atrás, em um dia de novembro, mudei de emprego para uma grande empresa. Imediatamente ficou claro para mim que o trabalho estava em pleno andamento. Metade da empresa trabalhou para liberar o produto antes do final do ano. Mas depois de uma semana, pareceu-me que até o final do ano eles não teriam tempo. A cada dia seguinte, as chances de sucesso desse empreendimento se tornavam cada vez mais ilusórias ... O projeto foi realmente entregue em dezembro, embora no ano seguinte. Aprendi sobre isso muito mais tarde, porque no verão os problemas começaram com o pagamento de salários aos funcionários e eu parei com cerca de metade dos funcionários. Você pode dizer "bem, é claro, os gerentes são tolos, você tinha que jogar pelo seguro". Eles se seguraram. Seis meses não houve problemas com o pagamento de salários. Manter um estoque de capital de giro por meio ano de financiamento não é uma tarefa fácil. Eu acho que se a avaliação fosse mais precisa, haveria outras decisões de gerenciamento no nível de gerência superior.

Se considerarmos o investimento na avaliação como um investimento na adoção de boas decisões de gerenciamento, elas deixarão de parecer tão caras. O tamanho do grupo é outra questão. Obviamente, não é necessário forçar toda a equipe a avaliar toda a quantidade de trabalho. É muito mais razoável dividir a tarefa em ~~módulos~~ , serviços, microsserviços e fornecer autonomia às equipes. E em um nível superior, use as estimativas obtidas por cada equipe para elaborar um plano de projeto. O que nos leva suavemente ao tópico do próximo parágrafo.

Layout de Dependência, Gráficos de Gantt

Se os programadores costumam fazer avaliações, então elaborar um plano de projeto é o monte de gerentes intermediários. Lembre-se de que escrevi que esses caras podem ser ajudados se uma ferramenta for usada para decomposição e gerenciamento de projetos. Avaliação e horário do calendário não são a mesma coisa. Por exemplo, para exibir uma tabela de dados simples, você precisaria de:

Tabela de banco de dados
Código de back-end
Código Frontend

A execução de tarefas nesta ordem é mais fácil do ponto de vista técnico. No entanto, na realidade, existem diferentes especializações. Um especialista em front-end pode estar programado para liberar mais cedo. Em vez de ficar ocioso, é mais lógico começar a desenvolver a interface do usuário substituindo a solicitação do servidor por dados simulados ou codificados. Então, quando a API estiver pronta, resta apenas substituir o código por uma chamada para um método real ... em teoria. Na prática, o nível máximo de paralelismo pode ser alcançado da seguinte maneira:

Primeiro, nos arrumamos rapidamente para concordar com a especificação da API
Em seguida, codifique os dados na parte traseira ou na frente, dependendo de quem estiver disponível.
Ao mesmo tempo, fazemos banco de dados, back-end e front-end. O banco de dados e o back-end bloqueiam-se parcialmente, mas na maioria das vezes essas competências são combinadas em uma pessoa e o trabalho realmente é seqüencial: primeiro um banco de dados, depois um back-end
Coletamos tudo e testamos
Corrigimos bugs e testamos novamente

É importante que as etapas 1, 4 e 5 sejam executadas o mais rápido possível para reduzir o número de bloqueios. Além das limitações tecnológicas e restrições à disponibilidade de especialistas da competência necessária, ainda existem prioridades de negócios! E isso significa que, após três semanas, uma demonstração foi agendada para um cliente importante e ele queria cuspir na primeira metade do seu plano de projeto. Ele quer ver o resultado final, que estará disponível o mais tardar dois meses depois. Bem, então você tem que preparar um plano separado para esta demonstração. Nós adicionamos ao plano os dados necessários do banco de dados, inserimos novos links para transições para a interface do usuário, etc. Também é desejável que, no final, fosse necessário descartar 20% do código, e não toda essa demonstração.

Cortar artisticamente esse plano não é uma tarefa fácil. Construir dependências simplifica bastante o processo. Antes de prosseguir para o módulo de relatório, você precisa criar um módulo de entrada de dados. Isso é lógico? Adicione uma dependência. Repita para todas as tarefas relacionadas. Acredite, muitas das dependências serão uma surpresa para você.

Nas tarefas de automatização de processos de negócios, geralmente se obtém várias "cobras" longas de tarefas relacionadas com vários nós de bloqueio grandes. Na maioria das vezes, o plano inicial não é eficaz em termos de utilização de recursos e / ou muito longo em termos de calendário. A revisão da avaliação dos custos de mão-de-obra ocorrerá mais rapidamente - não é uma opção. A avaliação, portanto, é provavelmente otimista. Temos que voltar à decomposição, procurar correntes muito longas e adicionar “garfos” adicionais para aumentar o grau de paralelismo. Assim, devido a um aumento nos custos totais de mão-de-obra (mais pessoas estão trabalhando simultaneamente em um projeto), o período do calendário do projeto é reduzido. Lembre-se do "mítico homem-mês"? É improvável que um plano encolha mais de 30%. Para que o orçamento e o prazo sejam acordados, o plano pode ser revisado várias vezes. Existem vários truques para tornar o processo mais rápido e fácil.

Bloqueio de tarefas

A primeira razão para o bloqueio - dependências - já consideramos.Além disso, pode haver simplesmente requisitos incompreensíveis / imprecisos. É necessária uma ferramenta para bloquear tarefas e fazer perguntas. Com a especificação de requisitos, você pode desbloquear tarefas e ajustar a nota. A propósito, esse processo quase sempre ocorre durante o projeto, e não antes dele.

O caminho crítico, riscos à frente

. , ( ), , , , . , , , , , , . , .

Em resumo, se você mexer com a estrutura do banco de dados, terá que reescrever a parte de trás, não calcular a carga, talvez seja necessário alterar a tecnologia completamente. Escrevi em detalhes sobre os riscos do trabalho de design no artigo " Código de custo-benefício ". Quanto mais cedo os riscos no caminho crítico se materializarem, melhor. Afinal, ainda há tempo e algo pode ser feito. Melhor ainda se eles não se materializarem, mas sejamos realistas.

Portanto, você precisa começar com as tarefas mais confusas, complexas e desagradáveis, colocá-las em um status "bloqueado" e esclarecer, reavaliar e remover dependências sempre que possível.

Critérios de aceitação, casos de teste

Idioma natural: russo, inglês ou chinês - não importa - pode ser redundante e impreciso. Os casos de teste superam essas limitações. É também uma boa ferramenta de comunicação entre desenvolvedores, usuários comerciais e o departamento de qualidade.

Gerenciamento de projetos

Você quer fazer Deus rir? Conte a ele sobre seus planos. Mesmo que um milagre tenha acontecido e você tenha coletado e esclarecido todos os requisitos antes de começar o trabalho, você tem pessoas competentes o suficiente, o plano permite que você faça a maior parte do trabalho em paralelo, ainda não está imune a doenças dos funcionários, erros na avaliação e materialização de outros riscos. Portanto, é necessário atualizar regularmente o plano e compará-lo com o fato. E para isso, a contabilização do tempo de trabalho é importante.

Rastreamento de tempo, também conhecido como rastreamento de tempo

Tempo e presença há muito tempo são o padrão de fato no setor. É altamente desejável que seja produzido na mesma ferramenta que a avaliação. Isso permite que você acompanhe o desvio do tempo real gasto em relação ao estimado. É bom que essa ferramenta também seja usada pelo gerente de projetos. Todos os atrasos do caminho crítico serão imediatamente percebidos. Uma variante com ferramentas diferentes também é possível, mas exigirá custos de mão-de-obra significativamente maiores para a manutenção do processo, o que significa que haverá uma tentação de brincar. Já sabemos como isso termina. Nós usamos o YouTrack . Tudo o que escrevi no artigo está atualmente disponível imediatamente, embora exija alguns ajustes.

Conclusão

Avaliação é difícil
A decomposição permite encontrar lacunas nos requisitos e melhorar a qualidade da avaliação
As pontuações dos grupos são mais precisas que as individuais, use o pôquer
Bloqueadores, casos de teste e critérios formais de aceitação melhoram a comunicação, o que aumenta as chances de sucesso do projeto
Você precisa começar com as tarefas mais arriscadas no caminho crítico do projeto
A avaliação não é uma ação única, mas um processo inseparável do gerenciamento de projetos
Sem levar em consideração o tempo de trabalho, é impossível manter o status do projeto atualizado e ajustar suas estimativas

Deseja saber mais sobre a avaliação de projetos?

Leia o livro de Steve McConnell " Quanto custa um projeto de software " e outros artigos sobre este assunto em Habré:

Sobre avaliação e gerenciamento do desenvolvimento de produtos de software