BT

Início Artigos Entrevista sobre o livro “Software Estimation Without Guessing”

Entrevista sobre o livro “Software Estimation Without Guessing”

Favoritos

Pontos Principais

  • As estimativas podem e devem ser feitas para propósitos diferentes. Há uma grande diferença entre estimar o provável custo de um trabalho para decidir se vale a pena ser feito e estimar quanto trabalho pode ser realizado em um determinado período de tempo;
  • As pessoas usam estimativas de maneira inadequada e depois as culpam, ou pior, culpam quem as realizou, quando as coisas dão errado;
  • Uma erro comum é aplicar uma estimativa criada para certo fim, em algo que requer precisão ou foco diferente;
  • Grande parte do problema de estimar não está na estimativa em si, mas na comunicação (ou na ausência dela) entre os envolvidos. Se não soubermos como uma estimativa será usada, provavelmente ela estará errada para aquela determinada situação;
  • De maneira geral, a estimativa não é sobre um número e a exatidão ou a precisão deste, antes, é sobre aprender o suficiente para que possamos orientar o desenvolvimento de software para uma conclusão satisfatória.

George Dinwiddie escreveu o livro Software Estimation without Guessing: Effective Planning in an Imperfect World, que discute diferentes abordagens para a estimativa de produtos de software, as maneiras pelas quais podem dar errado e, quando podem ser bem ou mal utilizadas.

O livro pode ser adquirido aqui e os leitores do InfoQ podem baixar um capítulo de amostra aqui.

Dinwiddie falou ao InfoQ sobre o livro:

InfoQ: O que te motivou a escrever este livro?

George Dinwiddie: Comecei a pensar mais profundamente sobre as estimativas há uma década, quando notei o esforço que uma equipe colocava na estimativa de histórias e o pouco valor que estavam obtendo delas. Quanto mais precisamente tentavam fazer as estimativas, menor era o custo benefício.

A equipe teve sorte, pois ninguém reclamava devido as estimativas estarem erradas. O principal objetivo do livro é mostrar o quanto as pessoas negligenciam o assunto das estimativas. Muitas vezes maltratam outras pessoas, e se tem algo que odeio observar é pessoas sendo maltratadas.

As pessoas que solicitam estimativas geralmente não discutem o suficiente sobre as necessidades que devem ser atendidas e os responsáveis por dar as estimativas não entendem o que está sendo pedido e, portanto, fornecem estimativas que não são factíveis. As pessoas usam estimativas de maneira inadequada e posteriormente as culpam ou pior, culpam aqueles que as realizaram, quando as coisas dão errado. Ajustar as estimativas na esperança de evitar problemas, as tornam inúteis para o objetivo final.

É tentador evitar falar sobre este assunto. Por que isso dá dor de cabeça? Desenvolver um software leva o tempo necessário. Talvez isso seja verdade, se não mudarmos a forma como reagimos em relação ao desenvolvimento das atividades. Porém, desenvolver um software não é o objetivo final, outros objetivos e várias pessoas dependem do sistema que será criado.

O valor desse software, ou a capacidade que pode oferecer, varia ao longo do tempo. Às vezes, quanto mais rápido desenvolvermos, mais rapidamente agregaremos valor e elevaremos a vida útil do software. Às vezes, entregar o mais cedo possível não traz valor adicional, porém atrasar o sistema pode desvalorizá-lo totalmente. Compreender o contexto em uma visão maior, nos ajuda a entender a função do tempo específico em relação ao valor.

Ao analisar com profundidade o assunto, constatei que mesmo que possamos, criar um software sem nenhum tipo de estimativa não é uma maneira inteligente de administrar um negócio. Embora o Desenvolvimento Ágil de Software tente diminuir a distância entre "o negócio" e "desenvolvimento de software", essa diferença ainda existe. A dor em torno da estimativa é o sintoma dessa lacuna. Se não existisse, a equipe de desenvolvimento de software, no interesse de ter sucesso nos negócios, também estaria interessada em olhar para o futuro.

InfoQ: Para quem se destina o livro?

Dinwiddie: O livro é destinado a todos que necessitam de estimativas, que são responsáveis por fazer as estimativas e as pessoas que ficam presas neste ínterim. Todos têm necessidades que são inibidas devido a estimativas que usam padrões habituais aprendidos no dia a dia. E muitas vezes possuem dificuldades para entender e se comunicar com as pessoas de outros grupos.

Um dos objetivos deste livro é ajudar essas pessoas a entender o ponto de vista das demais. Grande parte do problema de estimar não está na estimativa em si, mas na comunicação, ou na falta dela, entre os interessados. Se não soubermos como a estimativa será usada, provavelmente será ineficaz para a situação em que será empregada. Se tememos que uma estimativa seja erroneamente utilizada para um fim diferente do qual foi proposto, provavelmente desenvolvemos uma estimativa que não atende a nenhuma das necessidades.

Até certo ponto, este livro tenta reduzir o gap entre os grupos de desenvolvimento de software, os de negócio e as estruturas de gerenciamento que pretendem fazer com que essas coisas funcionem como se fossem uma. Embora parte do livro se concentra nos problemas deste gap, grande parte dele pressupõe que todos querem que tudo funcione. O objetivo do livro é ajudá-los a fazer isso.

InfoQ: Estimativas para desenvolvimento de softwares são notórias por sempre estarem erradas, tanto que em muitas organizações há uma séria falta de confiança em quaisquer estimativas fornecidas por profissionais de software. Por que é tão difícil estimar neste setor e o que causou isso?

Dinwiddie: Como acabei de mencionar, uma fonte de erro é a estimativa criada para um uso, que é utilizada de maneira negligente para algo que requer precisão ou foco diferente. Vamos analisar um exemplo do cotidiano.

Suponhamos que gostaríamos de uma estimativa para determinar se o desenvolvimento de um novo produto pode ser viável, dada a capacidade da empresa em desenvolvê-lo. Essa estimativa não será apropriada para garantir uma data de lançamento. Se a equipe de desenvolvimento, com base em experiências passadas, pensar que a estimativa será utilizada como sendo um plano para julgá-los e para julgar o trabalho deles, irão estimar incluindo certas contingências que qualquer plano deve ter, mas isso desvia a estimativa. Se um gerente, com base na experiência passada, acha que a estimativa possui certo desvio, pode restringir tanto o plano quanto a estimativa que serão passadas para as pessoas interessadas. Em vez de uma estimativa, ficamos com um número bruto produzido por uma mistura de diferentes suposições, algumas totalmente opostas.

Então somos pegos de surpresa ao desenvolver softwares que podem ter diferenças fundamentais em relação a experiências passadas, com pessoas cujo conhecimento, habilidades e experiência de trabalho em equipe são desconhecidos. Há muita variabilidade no desenvolvimento de software e a maioria não é vista facilmente.

InfoQ: O livro fornece diversas abordagens para estimativas, por que existem tantas opções? Quais são algumas das abordagens e como diferem uma das outras?

Dinwiddie: Em um sentido, há apenas uma maneira de estimar, que é comparando o desconhecido ao conhecido. É claro que existem muitas maneiras de fazer essa comparação. Conceitualmente, podemos dividir o desconhecido em pedaços menores, mais fáceis de serem comparados. Podemos criar um modelo que encapsule a comparação com base em atributos mensuráveis do trabalho planejado, podemos criar um modelo estocástico ou simulação de Monte Carlo para tentar um grande número de variações, enfim, cada uma dessas estratégias gerais também possuem diversas variações.

No livro, trago algumas das variações, que são comuns a todas essas três estratégias principais. Existem diversas combinações, por isso tento ajudar as pessoas a entenderem o contexto específico. Este não é um livro de receitas que seguimos o passo a passo sem pensar, precisamos parar e analisar no nosso contexto.

InfoQ: Dada a ampla variedade de abordagens, como alguém que precisa de uma estimativa para tomar uma decisão de negócios escolhe o modelo correto a ser usado?

Dinwiddie: A escolha da estratégia da estimativa depende em grande parte de como pensamos sobre o trabalho a ser estimado. Comecemos com o que sabemos ou já decidimos. Depois, precisamos dividir o trabalho de acordo com o que faz sentido do ponto de vista comercial, e não da maneira que assumimos que será realizado. A escolha também depende da bagagem de conhecimento que temos. Como podemos fazer com que o trabalho proposto seja comparável ao que já temos de referência?

InfoQ: Houve um grande esforço contra a tentativa de estimar em ambientes incertos, na medida em que #NoEstimates se tornou um slogan. Como o que está propondo se alinha às ideias do #NoEstimates?

Dinwiddie: Ambientes incertos são exatamente onde mais precisamos de estimativas. É nesses ambientes que não conseguimos ver para onde estamos indo. Certa vez, estava voltando para casa quando um denso nevoeiro apareceu. Meu amigo e eu continuávamos navegando com o uso de uma bússola. Não tinha notado com precisão o último marco que poderíamos ter passado, mas depois de um tempo parecia que vimos um farol que ficava ao sul da entrada do rio. Se não tivesse feito essa estimativa, teríamos percorrido um longo caminho na direção errada. Presumi que tínhamos seguido um curso um pouco mais a leste do que o pretendido, então viramos para oeste. Após algum tempo, calculei que estaríamos chegando perto da terra. Pela profundidade rasa da água parecia que ainda estávamos um pouco ao sul do rio. Virando para o norte até encontrarmos o canal mais profundo e depois para o oeste novamente, encontramos a entrada. No meio do nevoeiro, não conseguimos saber nossa localização, exceto calculando a distância e a direção da viagem.

Deixarei outros definirem as ideias que regem o NoEstimates. Ao longo dos anos, recebi diversas definições que são confusas e contraditórias.

Se isso significa "não usar pontos de história", isso não quer dizer muita coisa. Bob Payne e eu éramos defensores da contagem de histórias antes dessa ideologia surgir, mas estimar histórias não parece muito prejudicial para definir o tempo da estimativa. Talvez seja muito trabalho e pouco valor.

Se estivermos usando as estimativas para fazer previsões de longo prazo, teremos muita precisão para a quantidade de acurácia. Mais do que isso, aconselho que não decomponha o trabalho em pedaços de histórias com muita antecedência. Como descrevi no livro Software Estimation without Guessing, há muitas desvantagens em fazer um trabalho tão detalhado com bastante antecedência, seja estimando ou contando uma história. Os pontos da história, ou a contagem de histórias, fazem sentido para uma equipe que tenta decidir quanto trabalho se encaixa nas próximas duas semanas. Parece uma enorme quantidade de trabalho e precisão para estimativas de longo prazo. E é o longo prazo que geralmente importa para os negócios.

Também me disseram que isso significa "fazer perguntas sobre estimativa", mas tive respostas hostis às perguntas que fiz. Não acho que eles considerem os pontos de vista e as necessidades dos outros. Talvez façam isso para tentar inverter a estrutura organizacional colocando os desenvolvedores de software no topo, mas acho que isso não resolveria os problemas, apenas mudaria a aparência deles. Ainda resulta em pessoas tratando mal umas às outras. Usar o poder sobre outras pessoas não é uma forma de colaboração. Respeitar as necessidades delas não significa desistir das próprias necessidades, e defender as próprias necessidades não significa largar mão das necessidades dos terceiros. Além disso, precisamos lembrar das necessidades e dos objetivos que todos se propuseram a cumprir. Este livro foca nos três conjuntos de preocupações.

A minha intenção com o livro é ajudar as pessoas a formularem as perguntas de que precisam, tirando-os da lama e colocando-os no caminho do sucesso organizacional. Como Esther Derby observou, este livro não é apenas sobre como estimar, mas também como podemos pensar nas estimativas.

InfoQ: A estimativa é inerentemente uma atividade baseada em pessoas e na colaboração. Como mantê-los centrados e sem influência ou expectativas surreais?

Dinwiddie: É claro que as estimativas serão influenciadas por tendências e expectativas surreais. Precisamos de um mecanismo de feedback para ajustar e corrigir ao longo do tempo.

Fazemos suposições sobre como as coisas serão, com base na experiência passada. Se fizermos estimativas, essas suposições serão incluídas nelas. Quando as premissas estão erradas, as estimativas estarão erradas. Parece algo ruim, mas na verdade é um recurso interessante. Ao verificar a precisão das estimativas com antecedência e frequência, podemos detectar quando as suposições estão erradas. Podemos dizer isso porque a realidade posterior difere do que esperávamos.

A única coisa que sabemos sobre uma estimativa é que ela estará errada até certo ponto. Quão errado, e de que maneira, são as perguntas mais importantes a serem respondidas. Fazer uma previsão antecipada e depois confiar nela por um longo tempo parece ser uma estratégia não muito inteligente. As estimativas têm um prazo de validade limitado. Se fizermos uma estimativa de longo prazo, também precisamos fazer algumas estimativas intermediárias de curto prazo que podem ser usadas para verificar as suposições. Isso fornece um meio de calibrar o processo para as condições reais.

A estimativa não é sobre um número e a exatidão ou precisão desse número. Trata-se de aprender o suficiente para que possamos orientar o desenvolvimento de software para uma conclusão satisfatória. Trata-se de perceber os problemas que estão aparecendo antes de nos afundarmos neles. É sobre a capacidade de tomar decisões razoáveis e, em seguida, saber revisitar essas decisões quando são construídas em terreno instável.

Embora a maioria das discussões sobre estimativas seja sobre o mau comportamento que todos nós já vimos, este livro oferece conselhos sobre como mudar este comportamento, oferecendo maneiras de obter valor, em vez de sofrimento da prática de estimativa de desenvolvimento de software.

Sobre o autor do livro

George Dinwiddie ajuda as empresas a desenvolver softwares com mais eficiência. Possui uma bagagem de décadas de experiência em desenvolvimento, de hardware eletrônico e firmware incorporado à tecnologia da informação comercial. Auxilia empresas, gerentes e equipes a resolver os problemas que enfrentam, fornecendo consultoria, treinamento, mentoria e coaching nos níveis organizacionais, de processo, equipes, interpessoal e técnico. Envolvido na comunidade ágil desde 2000, deu suporte a organizações que vão desde uma startup de 6 pessoas a uma empresa da Fortune 100, e um programa federal de mais de um bilhão de dólares, diretamente ou em parceria com outras empresas. É autor do Software Estimation without Guessing: Effective Planning in an Imperfect World (Pragmatic Bookshelf), Evolutionary Anatomy of Test Automation Code (LeanPub) e co-autor do Patterns of Agile Journeys (LeanPub).

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.