Saiba por que a estimativa de software está mais importante do que nunca

Em um mundo que ainda está se desvencilhando da tradicional metodologia cascata em direção ao desenvolvimento de metodologias ágeis, seria compreensível assumir que não há necessidade de estimativas de projeto de software. Muitos praticantes da metodologia ágil sentem que não existe valor em estimativas, desde que estejam prontos para trabalhar com pequenos incrementos, sprints e aprimoramento de seus backlogs.

Embora essa premissa possa estar equivocada.

Em uma recente entrevista, os fundadores do Scrum, Ken Schwaber e Jeff Sutherland, foram questionados sobre o movimento #NoEstimate. Schwaber acredita que um termo mais apropriado seria #NoMeaningfulCommitments ("sem comprometimento significativos"). E sente que as pessoas normalmente confundem estimativa com comprometimento e, de fato, a estimativa deveria ser utilizada para produzir comprometimento. Sutherland mencionou que em uma pesquisa recente da Rally (atual CA), perguntou a 70.000 membros de equipes Scrum sobre as técnicas de estimativa que utilizavam, para em seguida relacionarem as técnicas com a velocidade das entregas. Então, perceberam que aqueles que evitavam estimar produziram entregas mais lentas, enquanto os resultados mais rápidos foram entregues por aqueles que empregaram o escopo baseado em estimativas.

As informações encontradas indicam que as estimativas podem ser muito mais importante hoje do que jamais foram, mesmo para praticantes do ágil. Muitos projetos de desenvolvimento estão se tornando maiores e mais complexos, desafiando as equipes a conhecer e a determinar prazos de entrega realistas. Enquanto isso, executivos-sênior exigem estimativas de custo precisas para ajudá-los a definir o orçamento anual e determinar se os projetos são viáveis e se estão alinhados com a estratégia de negócio. Tudo isso é real, independente da metodologia de software que está sendo utilizada.

Ao invés de abandonar a estimativa de software, as empresas deveriam focar em estimar melhor. A prática da abordagem top-down, uma estimativa de nível macro, e que foca exclusivamente em algumas métricas centrais, pode auxiliar gerentes a ter mais controle de seus projetos, além de criar cenários de desenvolvimento mais realistas. Isso resultará em projetos que vão de encontro às expectativas dos gerentes e são entregues no prazo e dentro do custo.

Entretanto, antes de observar os detalhes das melhores práticas, seria útil entender por que as equipes continuam brigando sobre estimativa de software. Como se vê, há vários motivos pelos quais os gerentes de projeto têm dificuldades com o processo.

Eles tentam exceder o otimismo.

Os gerentes de projetos e desenvolvedores de software tendem a ter visões claras do projeto em que estão trabalhando. Parece ser uma tendência natural superestimar sua habilidade de criar, entregar e fazer projetos corretamente logo na primeira vez. Assume-se que tudo sairá perfeito e não haverá impedimentos no caminho.

Infelizmente, os obstáculos inevitavelmente irão aparecer. Haverão interrupções, mudanças não antecipadas no cronograma e outras condições imprevisíveis que impactam o desenvolvimento.

E então, os gerentes cometem dois erros.

O primeiro é quando falham em balancear dados históricos a partir de projetos parecidos, particularmente relacionado a equipe, o que pode ser útil ao estimar o tamanho e o tempo do projeto com maior precisão. Nossa pesquisa mostra que quando os gerentes confiam apenas na metodologia de desenvolvimento, em vez de entender e otimizar os recursos disponíveis, os projetos acabam com um excesso de pessoas, acima do orçamento e com defeitos mais significativos. O estudo de 15 anos da QSM sobre desempenho ágil mostrou consistentemente que um bom plano, e não a metodologia de desenvolvimento, é a chave para o sucesso no desenvolvimento de software. Além disso, os dados históricos tem uma função integral no planejamento efetivo e nas estimativas. A razão pela qual criamos e continuamos atualizando nossa base de dados de projetos de software é fornecer informações históricas de alta qualidade e tendências para que nossos clientes tomem decisões de forma mais consciente no processo de desenvolvimento de software, independente da metodologia que estejam utilizando.

Segundo, os gerentes tendem a confundir estimativa com comprometimento, objetivo de valor ou metas. Um objetivo de valor é algo que alguém gostaria que acontecesse. Por outro lado, uma estimativa é baseada em análise quantitativa sobre quando é mais provável que aconteça. Essas duas coisas nunca deveriam ser confundidas, ao invés disso, objetivos e estimativas deveriam ser avaliados independentemente para observar se irão se alinhar. Isso ajuda a equipe a manter o otimismo em níveis mais realistas. As estimativas deveriam ser sempre utilizadas como uma prévia antes de se comprometer com custos e cronograma.

Eles falham em re-estimar quando as coisas mudam.

Como mencionei, inevitavelmente, alguma coisa vai acontecer e mudar os rumos do esforço de desenvolvimento. Por exemplo, uma equipe pode achar que precisa ajustar os requisitos e o escopo do projeto na metade do ciclo de desenvolvimento. Essas mudanças provavelmente impactarão o cronograma, além de poder impactar em fatores como o número de membros necessários para trabalhar no projeto, orçamento, entre outros. Em alguns casos, os gerentes precisam estar preparados para re-estimar e ter maior precisão sobre o status do projeto.

Infelizmente, muitas pessoas não fazem isso e continuam com suas estimativas originais. Quando falham em suas estimativas o projeto atrasa, segue acima do orçamento, etc. E culpa-se o processo de estimativa de software, entretanto, não foi o processo que falhou; foi o simples fato de que a equipe manteve-se focado em sua estimativa original.

Os gerentes de projetos precisam lembrar que as estimativas não são escritas em pedras, e que podem e devem ser ajustadas de acordo com as mudanças que acontecem durante o processo de desenvolvimento. Isso é algo que os praticantes de ágil aprenderam há muito tempo atrás e é a razão pela qual constroem o potencial para mudanças dentro de suas metodologias de desenvolvimento.

Eles produzem pontos de estimativa ao invés de intervalos.

Quando estão estimando, os gerentes tendem a aplicar pontos de estimativa ou valores únicos em seus projetos. "Nosso projeto será entregue em 1º de Maio de 2018", anunciam sem deixar espaço para discussões.

Mas estimativas são inerentes à incerteza. Elas são orientadas pelo que não sabemos, como o tamanho, escopo e produtividade, por exemplo. Quando estimamos, estamos realmente tentando desenvolver uma linha do tempo e nos esforçando para segui-la. As equipes que promovem uma data em particular estão mais propensas a falhar.

Ao invés de produzir pontos de estimativa, os gerentes de projetos deveriam desenvolver intervalos de estimativas. Por exemplo: "O projeto possivelmente não será entregue antes de 15 de Abril, mas não será entregue depois de 1 de Maio" ou "Nosso projeto não custará menos que R$ 1 milhão, mas não custará mais que R$ 3 milhões". Isso dá algum espaço a equipe para respirar, sem pressioná-los a se comprometerem com o que podem não cumprir, além de dar uma boa perspectiva do que é esperado.

Considerando o modelo de predição de furacões, os meteorologistas nunca usam uma linha estreita para prever o trajeto, mas apresentam isso como um cone de incertezas que cresce com o tempo. Embora o modelo não seja exato, é bom o suficiente para determinar quais os centros populacionais que deveriam considerar a evacuação. Essa ideia é exatamente a mesma na modelagem e predição dos resultados de projetos de software. Assim como os meteorologistas usam o cone de incertezas para explicar possíveis mudanças de curso dos furacões, os gerentes de projetos podem usar os intervalos de estimativa para gerar um buffer de risco razoável, enquanto permanecem hábeis a dar expectativas realistas para a gerência.

As melhores práticas que podem ajudar a prosperar a estimativa de software.

Agora que examinamos os erros que estão sendo cometidos, vamos ver de perto como os desenvolvedores de software podem ressuscitar seu processo de estimativa de software para entregar valores excepcionais em sua organização.

Realizar um "top-down", uma abordagem de nível macro

A gestão tradicional de projetos envolve a alocação de pessoas e um número de horas para se trabalhar em uma tarefa específica (estimadas no início do projeto). Isso normalmente acontece antes das equipes conhecerem os requisitos específicos da tarefa de cada um ou antes de estimar o esforço e duração total para todo o sistema. A abordagem do "bottom-up" para estimar projetos de software normalmente resulta em uma adivinhação imprecisa e replanejamento, custando às organizações mais tempo e dinheiro.

Implementando o "top-down", uma abordagem de estimativa macro, podem-se obter resultados muito mais efetivos. A estimativa top-down leva todo o projeto em consideração, desde o início, empregando modelos históricos e empíricos mais precisos para estimativas de tamanho, custo, esforço e outros fatores. Os gerentes podem usar cenários "E se…" para considerar diversos desafios que podem ocorrer ao longo do desenvolvimento. Por exemplo, "E se estivermos acima do orçamento?" ou ainda "E se tivermos que fazer algum retrabalho?". Os ajustes necessários poderão ser feitos antes do início do trabalho, economizando tempo e dinheiro conforme ocorre.

Foco nas cinco métricas centrais.

Os gerentes de projetos não precisam capturar diversas métricas para garantir o sucesso de seus processos de estimativa; ao simplesmente focar nas cinco métricas centrais: duração, esforço, tamanho, produtividade e confiabilidade, poderão entregar estimativas mais confiáveis e precisas.

Meu pai, Larry Putnam, apresentou esta teoria anteriormente em seu livro "Five Core Metrics: The Intelligence Behind Successful Software Management". No livro, meu pai aponta que simplificar o processo de estimar e ajustá-lo às áreas que realmente importam pode ajudar os gerentes a avaliar melhor os fatores de risco, antecipar e responder a mudanças, e replanejar seus projetos com sucesso quando necessário, tratando o equívoco comum de que a estimativa de projetos de software é algo difícil e complicado. Como já mostrado pelo meu pai, certamente não é o caso.

Medidas de tamanho e escopo.

Das cinco métricas centrais, o dimensionamento do projeto, que considera a quantidade de funcionalidades em uma determinada versão de software, tende a ser o que mais traz dores de cabeça. Normalmente, as equipes acham extraordinariamente difícil quantificar o tamanho de seus projetos, sobretudo se envolverem esforços de larga escala para o desenvolvimento. Frequentemente, as equipes vão precisar utilizar métodos diferentes de dimensionamento, de acordo como projeto se encontra no ciclo e as informações disponíveis.

Além disso, dimensionar é extremamente importante. Sem isso, as partes interessadas não estarão habilitadas para determinar em quanto tempo o projeto de software será finalizado, quanto custará, quantas pessoas serão necessárias para completá-lo e o quão produtiva a equipe será ou a quantidade de defeitos que esperam encontrar durante os testes. Ignorar o tamanho conduz a estimativas ruins.

Embora seja ótimo conseguir contar exatamente cada unidade de trabalho, nem sempre isso é possível. Nesses casos, a equipe seria melhor servida com valores aproximados para as estimativas; poderiam ser classificadas basicamente como pequena, média e grande ou com alguma variação desses termos. Também poderiam ser empregados medidas de alto nível como "requisitos de negócio" ou "quantidade de user stories ou épicos" para estimar o tamanho.

As ferramentas de estimativa podem ser utilizadas para complementar os quadros iniciais de referência e esclarecer qualquer incerteza que possa existir. Depois de aplicar algumas estimativas iniciais, os gerentes podem ter uma ideia boa e confiável sobre o tamanho de seus projetos. Assim, as estimativas podem ser comparadas às tendências da indústria para verificar os custos globais e cronograma do projeto.

Então, a estimativa não está morta, pois permanece essencial.

A estimativa de software não precisa ser difícil, onerosa ou ineficiente. Pelo contrário; feita corretamente, a estimativa pode ser absolutamente essencial para o desenvolvimento e a entrega de projetos no momento certo. Pode ajudar as equipes a entender melhor sobre quanto tempo, esforço e dinheiro precisarão para entregar a solução de valor para suas organizações. Aos gerentes de projeto, Isso também pode fornecer informações demandadas por stakeholders sobre como seus investimentos estão sendo gerenciados. Em resumo, a estimativa de software está longe de morrer, ou seja, está muito viva. Com um pouco de atenção, as organizações podem usá-la em toda a sua extensão para entregar intuições valiosas para projetos de todas as metodologias e tamanhos.

Sobre o autor

Lawrence H. Putnam Jr. é co-CEO da QSM, liderando melhorias de processo de software e estimativa de sistemas de desenvolvimento. Sua principal área de responsabilidade é orientar a direção estratégica da produção de negócios da QSM. Isso inclui reuniões de revisão dos objetivos, direção da produção estratégica, serviços de atendimento ao cliente e pesquisas. Tem mais de 25 anos de experiência em medição, estimativa e controle de projetos de software. Está na QSM desde 1987, tendo trabalhado em todos os aspectos do negócio, incluindo desenvolvimento dos negócios, serviços de atendimento ao cliente, serviços profissionais e, atualmente, gestão executivo.