BT

Estimativas em Agile: Quanto tempo vai demorar para terminar o produto?

por Vikas Hazrati , traduzido por Rafael Buzon em 13 Out 2011 |

Uma estimativa do tempo necessário para entregar um produto é uma das informações solicitadas com mais frequência pelos clientes, e é um pedido que costuma deixar desconfortável uma equipe ágil. Embora estimar as funcionalidades de um produto inteiro, sem ter começado a trabalhar nele efetivamente, tenda a gerar muitos erros, trata-se de uma pergunta prática que as equipes não podem ignorar.

Jarrod Roberson disse que nunca se deveria estimar um projeto inteiro, pois isso iria totalmente contra a filosofia ágil. O melhor a se fazer seria atribuir uma data dependente do custo ou de outras restrições - e o Product Owner decidir o que deve ser feito até aquela data. Pascal Thivent acresenta que qualquer estimativa inicial resultaria em um escopo fixo, o que vai contra os princípios do Agile. Outro extremo sugerido foi que times ágeis nunca entrem em projetos que envolvam estimativas iniciais.

Entretanto, isso funciona no mundo real? Com frequência, times ágeis se defrontam com a situação em que o cliente precisa de uma estimativa, mesmo que grosseira, a fim de tomar decisões. Sobre isso, disse Hugo Palma no site StackOverflow:

Acredito que todo cliente quer ter pelo menos uma estimativa de quanto irá custar certo conjunto de funcionalidades. Não concordo com pessoas que afirmam que isso é impossível quando se usa práticas ágeis. O Agile pode ser adaptado ao mundo real, em que clientes querem saber quanto irão gastar em um projeto, ou pelo menos obter uma ideia aproximada.

Mike Cohn comenta que costuma receber perguntas sobre estimativas de horas para a entrega de produtos. Sua primeira recomendação, nesses casos, é adiar a análise até que se tenha informações históricas adequadas, ou pelo menos até terem sido realizadas algumas reuniões de planejamento. Entretanto, há situações que precisam de uma estimativa aproximada antes disso. Para estas situações, Cohn sugere uma técnica de trabalhar com uma amostragem do backlog, verificando uma média de horas para cada tamanho de história.

Se medirmos as histórias, podemos verificar que uma história de 1 ponto pode corresponder a 3,2 horas por ponto; as de 2 pontos (que foram quebradas em tarefas) teriam 4,3 horas por ponto; e as de 3 pontos, 4,1 horas por ponto; e assim por diante. Poderemos então multiplicar o número médio de horas pelo número de histórias do backlog do produto, para cada tamanho.

Mike adverte que esta técnica herdaria todas as deficiências introduzidas durante a identificação de tarefas e na fase de estimativas. Rob Bowley comentou que a técnica de amostra do backlog não funcionaria, já que o desenvolvimento de software é imprevisível e que técnicas como esta acabariam subestimando a quantidade de trabalho necessária.

Não há justificativa para se tentar fazer algo desse tipo. A quantidade de trabalho vai acabar sendo subestimada enormemente. E considerando a quantidade de dinheiro envolvida no desenvolvimento de software, isso acabará causando danos financeiros reais a uma organização, ou mesmo destruindo carreiras.

Matteo Vaccari comenta que, apesar da estimativa por amostragem do backlog poder ajudar com alguns números, continuará existindo várias incógnitas, como a maturidade do time, a experiência em trabalhar juntos, a definição de "pronto" utilizada etc., que tornariam a estimativa menos útil.

Outra opção nessas situações é o Escopo Flexível, sugerido por Martin Fowler. A ideia é começar com um contrato de escopo fixo e aos poucos educar o cliente sobre os méritos das práticas ágeis, ajudando-o a superar a Miragem do Escopo Fixo. Rob Thomsett também sugere um jogo de dobrar e adicionar, que é similar à técnica descrita por Fowler.

Assim, nenhuma das técnicas parece realmente completa. Cada uma sofre com algum elemento subjetivo e tem suas próprias armadilhas. De qualquer forma, as aplicações das técnicas em situações que demandem uma estimativa aproximada pode ser útil ao cliente e a outros interessados, para que tenham mais informações nas quais basear suas decisões.

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.

Dê sua opinião

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

Receber menssagens dessa discussão

Estimativas em Agile: Quanto tempo vai demorar para terminar o produto? by Luiz Henrique Ferreira

No mundo corporativo existe uma grande confusão no significado da palavra Estimativa, mudar o nome para Projeção, eliminaria metade do problema, Estimativa apesar de todo mundo saber o significado da palavra, ja esta chumbado na cabeça das pessoas, inclusive a famosa afirmação: "A estimativa estava errada..." , como dito, a questão é mais cultural.

Re: Estimativas em Agile: Quanto tempo vai demorar para terminar o produto? by Vinicius Serpa

É muito difícil convencer o cliente de que ele não pode ter uma estimativa de um serviço que será prestado (ou um produto a ser entregue) simplesmente porque em qualquer relação de trabalho essas são características básicas (quanto eu vou gastar e quanto tempo vai levar?). Para contornar a situação nós customizamos a nossa metodologia baseada em práticas do PMBoK para o planejamento (incluindo as métricas), e durante a execução do projeto o escopo é transferido para um backlog e passamos a considerar o Agile.

O UCP tem nos ajudado nas estimativas. Quando o projeto atrasa devido a incompreensão dos requisitos no início do projeto, nós tentamos utilizar o conselho do Martim Fowler e "jogar limpo", educando o cliente sobre os motivos da alteração de prazo e escopo. Na maioria das vezes ele acaba entendendo, porque o próprio trabalho que o nosso cliente presta (que no geral são as engenharias tradicionais - mecânica, elétrica, etc) também passa pelo mesmo problema de estimativa em seus projetos.

Re: Estimativas em Agile: Quanto tempo vai demorar para terminar o produto? by Rafael Buzon

Oi Vinicius, tudo bom?

Como descreve o Vinícius Teles no seu livro Extreme Programming, o desenvolvimento de software está mais para a construção de um livro que para a construção de um prédio. E, portanto, por ser de natureza mais criativa e mutante, precisa considerar todos os vieses de ser assim.

Eu acredito (I have a dream) que o entendimento dos clientes sobre produtos de software virá com o tempo. Quando então teremos Product Owners consciêntes sobre como extrair valor para seus negócios de forma priorizada e colaborativa.

O crescimento do modelo ágil também depende do amadurecimento dos clientes sobre este tipo de investimento. Eu trabalho em uma empresa cujo core business são revistas impressas. Os mesmos editores destas revistas são também colocados no papel de PO de produtos de software. E isso acontece em todas as indústrias.

Enquanto isso, creio que quanto mais se buscar a colaboração entre o cliente e fornecedor, melhor será o resultado final. Com ou sem um tempo estimado para o produto.

Abs,

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

Receber menssagens dessa discussão

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

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT