Estimativa não Exatimativa!
Estimar não é uma tarefa fácil. Porem vivemos em um mundo de estimativas. Queremos saber quando vamos ganhar um aumento, quando vai subir o preço das passagens, quando o taxista vai chegar no local que você solicitou. Enfim esse é o nosso mundo e em software não tem por que ser diferente.
Essa é uma das práticas mais malhada dos últimos anos pelo pessoal do movimento ágil. De fato a técnica se trata de uma arte mais negra do que muitos rituais de magia. :) Mas não é tão negra assim como alguns devem estar pensando agora.
Quantas vezes não vimos gerentes de projetos fazendo WBS detalhadas nos primeiros ciclos de planejamento de projetos? A WBS per se não é o problema, o problema é o uso que as pessoas fizeram dela. Os problema nesse tipo de abordagem são:
Para começar apenas 1% dos projetos (projetos muito bem estimados) sabem com precisão quando o projeto começou. Eu particularmente sempre tive essa angustia do tipo "Mas que dia o projeto iniciou?". O que de fato ocorre é que predicar essa data é algo complicado, por que o projeto pode iniciar quando:
Se você se acha vou de estimativas me responda:
Quando você tenta fazer esse tipo de coisa para um projeto de desenvolvimento de software você não esta estimando está tentando fazer aplicar um processo de exatimação e previsão do futuro, isso eu acho que você não quer fazer!
Além do mais uma unica data de termino nos deixa com apenas uma chance de acertar, logo se acontecer um imprevisto os nossos problemas só tendem a aumentar.
Qual é a solução para esse caso?
Estime não exatime. Use várias datas ao invés de uma data. Então podemos fazer algo do tipo:
Realizar planejamento especifico muito cedo
Planejar no inicio é necessário. Estimar no inicio também. A Questão é que no inicio de um projeto o grau de variabilidade dos requisitos é extremamente alta. A medida que vamos desenvolvendo os requisitos e mitigando os riscos técnicos do projeto essa variabilidade vai diminuindo. Sim estou falando do Cone de incertezas. O cone são desafunila por si próprio. Essa diminuição de riscos pode ser dado através do uso de práticas de um bom processo de desenvolvimento de software como o RUP.
É necessário fazer planos específicos, mas no inicio até 2 iterações a frente é o ideal. Mais do que isso é possível que você fique a merce do plano.
Estabelecer Datas com requisitos muito instáveis
O melhor momento para se estimar é quando os requisitos já estão mais maduros, no RUP essa a fase da análise de negócio de alto nível onde cerca de 75% dos requisitos mais importantes para o produto de software são levantados. Após esse ponto você tem condições de fazer uma estimativa muito mais acertiva do que antes.
Plano cria o efeito "Marcha da Morte"
Se criarmos um plano detalhado e estimarmos um unico ponto de entrega estaremos sendo sérios candidatos ao efeito "Marcha da Morte". Esse fenômeno consiste em no fato de que o projeto já esta condenado ao fracasso e mesmo assim as pessoas seguem os planos e vão realizando suas atividades diariamente marchando em caminho da morte.
Eu já participei de projetos onde este fenômeno aconteceu. Não é divertido, muito disso acontece por conta de Requisitos mal elicitados ou nem isso. Além de estimativas muito mal feitas.
Estimar não é uma ciência é uma arte
Para estimar, independente da técnica de estimativas que você use, é importante que você tenha em mente isso. Planos baseados em Premissas(Assumptions) não servem para nada. Muitas vezes o que estraga tudo são as malditas Assumptions que fazemos. Devemos tomar muito cuidado com esse tipo de coisa, é natural do ser humano fazer isso.
As estimativas bem feitas são mais difíceis ainda, mas por que? Isso ocorre por que os desenvolvedores em geral tendem a estimar em torno de 20% para baixo do que a tarefa é de verdade. Estimativas para baixo são muito mais perigosas do que estimativas para cima.
Nota: Estimativas para baixo(Otimistas, até de mais) podem fazer com que o GP ache que a equipe pode ser de um tamanho X e na verdade depois pode se descobrir que o tamanho ideal seria X + 20. Uma vez isso, de nada vai adiantar contratar essas 20 pessoas depois, existiram diversos problemas. (É... Já passei por isso também).
A dica que eu dou para vocês é: Não reduzam as estimativas dos desenvolvedores, por que elas já são reduzidas por natureza. Se você quer entregar antes, existem outras formas, as quais falarei mais a frente neste post :)
Mas por que é importante estimar mesmo?
Por que boas estimativas dão as condições para que o projeto possa ser controlado de maneira adequada. Através de boas estimativas vamos saber se a equipe deve ser maior ou menor. O controle que pode ser realizado é:
Abordagem orientada a Objetivos
A melhor maineira de se trabalhar com estimativas é através da orientação a metas e objetivos. Por exemplo um stakeholder seta uma meta ou objetivo de negócio e a equipe técnica estima. Então ai existe o comprometimento do time para alcançar essa meta.
A equipe técnica não questiona a meta, os stakeholders não questionam a estimativa. Caso as datas não fechem eles devem discutir o comprometimento, ou seja, reduzir o escopo ou aumentar a equipe, etc...
Este tipo de abordagem nos dá mais alguns beneficio como:
Para estimar precisamos nos basear em algumas informações. Basicamente as estimativas são influencias pelos seguintes fatores:
Técnicas de Estimativas
Existem diversas técnicas para se estimar, algumas delas são muito velhas e datam até muito antes do computador ser criado.
Contar, Computar e Julgar: Nessa técnica nos contamos, pode ser qualquer coisa: linhas de código, requisitos, casos de uso, paginas na web. Após isso precisamos computar para ver o quando isso se representa e ai sim após isso precisamos de um julgamento para estimar os dias.
Opinião do Especialista: Neste método o especialista proferi sua opinião com base no seu conhecimento no domínio da questão. Podemos utilizar a evolução de desta técnica que é Opinião do Especialista Estruturada que consiste um usar formulas que vão do mais realista ao otimistas e até levando em considerações margens de erro.
Decomposição e Recomposição: Essa todos conhecem é onde se encaixa a WBS. Consiste em quebrar o que deve ser entregue em pequenas unidades de trabalho.
Estimativas por Analogia: Quando você já fez um software antes e esta fazendo um muito parecido com o anterior. Ai você pode usar analogias para estimar, mas cuidado essa técnica é perigosa.
Estimativas Baseadas em Proxy: Aqui se encaixam os Story Points utilizados no XP, entre outras técnicas como Fuzzy Logic, T-Shirt Sizing entre outras. Esse conjunto de técnicas é baseado em alguma escala e em um conjunto de informações.
Julgamento de Expecialistasem grupo: Na minha modesta opinião é a melhor técnica para se estimar em um projeto de software. Aqui entra o Planning Game do Scrum e o famoso Wideband Delphi. Essas técnicas consistem em realizar diversas estimativas através de um grupo de pessoas e utilziar ou as médias no caso do Wideband ou a votação no caso do Scrum.
A diferença das estimativas
Projetos que não dominam a arte negra das estimativas são assim:
Nesse tipo de projeto se tenta mudar as estimativas, no desenho a cima as estimativas são representas pelos Outputs. Nesse tipo de projeto o procedimento é totalmente Ad Hoc, ou seja, sem um mecanismo efetivo de estimativas. Nesse projeto existem uma série de problemas com comprometimento e alcance de metas e entrega de valor ao negócio.
Projetos que tem um mecanismo eficiente de estimativas são assim:
Os inputs (Boas informações para se estimar) são bem definidos, como por exemplo: escopo, priorização do product champion, constantes de negócio e dados históricos da organização e mais adiante do próprio projeto.
Existe um mecanismo de estimativas efetivo com alguma técnica aplicada, pode ser qualquer uma ou várias das técnicas que descrevi a cima. No final temos Outputs bem definidos (Estimativas) de: custo, esforço, cronograma, funcionalidades.
Esse projeto usa a abordagem orientada a Objetivos/Goals/Targets (São todos sinônimos) e tem excelente comprometimento com o negocio além de entregar valor.
Por hoje é só. Até a próxima :)
Essa é uma das práticas mais malhada dos últimos anos pelo pessoal do movimento ágil. De fato a técnica se trata de uma arte mais negra do que muitos rituais de magia. :) Mas não é tão negra assim como alguns devem estar pensando agora.
Quantas vezes não vimos gerentes de projetos fazendo WBS detalhadas nos primeiros ciclos de planejamento de projetos? A WBS per se não é o problema, o problema é o uso que as pessoas fizeram dela. Os problema nesse tipo de abordagem são:
- Unico ponto de acerto
- Realizar planejamento especifico muito cedo
- Estabelecer Datas com requisitos muito instáveis
- Plano cria o efeito "Marcha da Morte"
Para começar apenas 1% dos projetos (projetos muito bem estimados) sabem com precisão quando o projeto começou. Eu particularmente sempre tive essa angustia do tipo "Mas que dia o projeto iniciou?". O que de fato ocorre é que predicar essa data é algo complicado, por que o projeto pode iniciar quando:
- Quando o setor de marketing envisionou o produto
- Quando o Sponsor do projeto comprou o projeto
- Quando a equipe começou a ser montada
- Quando o projeto foi vendido ao cliente
- Quando a analise começou
- Quando o gerente fechou o escopo
Se você se acha vou de estimativas me responda:
- Qual é a área da superfície do Sol?
- Qual é a latitude de Buenos Aires?
- Qual é a área do continente africano?
- Qual é o valor total de circulação de dinheiro na china em 1945?
- Qual é o número total de livros publicados nos EUA em 1976?
Quando você tenta fazer esse tipo de coisa para um projeto de desenvolvimento de software você não esta estimando está tentando fazer aplicar um processo de exatimação e previsão do futuro, isso eu acho que você não quer fazer!
Além do mais uma unica data de termino nos deixa com apenas uma chance de acertar, logo se acontecer um imprevisto os nossos problemas só tendem a aumentar.
Qual é a solução para esse caso?
Estime não exatime. Use várias datas ao invés de uma data. Então podemos fazer algo do tipo:
- 01/03/2002 - Entrega do Módulo de Contas Correntes
- 05/05/2002 - Entrega do processo de Qualidade de Software
- 06/06/2002 - Treinamento para os novos usuários de Contas Correntes
- 11/08/2002 - Entrega do Módulo de Notas Fiscais
- 12/09/2002 - Entrega do processo de Manutenção de Contas
- 20/12/2002 - Entrega do Sistema de autenticação por Digitais
- ...
- 12/09/2003 - Finalização de migrações e Entrega final do sistema
Realizar planejamento especifico muito cedo
Planejar no inicio é necessário. Estimar no inicio também. A Questão é que no inicio de um projeto o grau de variabilidade dos requisitos é extremamente alta. A medida que vamos desenvolvendo os requisitos e mitigando os riscos técnicos do projeto essa variabilidade vai diminuindo. Sim estou falando do Cone de incertezas. O cone são desafunila por si próprio. Essa diminuição de riscos pode ser dado através do uso de práticas de um bom processo de desenvolvimento de software como o RUP.
É necessário fazer planos específicos, mas no inicio até 2 iterações a frente é o ideal. Mais do que isso é possível que você fique a merce do plano.
Estabelecer Datas com requisitos muito instáveis
O melhor momento para se estimar é quando os requisitos já estão mais maduros, no RUP essa a fase da análise de negócio de alto nível onde cerca de 75% dos requisitos mais importantes para o produto de software são levantados. Após esse ponto você tem condições de fazer uma estimativa muito mais acertiva do que antes.
Plano cria o efeito "Marcha da Morte"
Se criarmos um plano detalhado e estimarmos um unico ponto de entrega estaremos sendo sérios candidatos ao efeito "Marcha da Morte". Esse fenômeno consiste em no fato de que o projeto já esta condenado ao fracasso e mesmo assim as pessoas seguem os planos e vão realizando suas atividades diariamente marchando em caminho da morte.
Eu já participei de projetos onde este fenômeno aconteceu. Não é divertido, muito disso acontece por conta de Requisitos mal elicitados ou nem isso. Além de estimativas muito mal feitas.
Estimar não é uma ciência é uma arte
Para estimar, independente da técnica de estimativas que você use, é importante que você tenha em mente isso. Planos baseados em Premissas(Assumptions) não servem para nada. Muitas vezes o que estraga tudo são as malditas Assumptions que fazemos. Devemos tomar muito cuidado com esse tipo de coisa, é natural do ser humano fazer isso.
As estimativas bem feitas são mais difíceis ainda, mas por que? Isso ocorre por que os desenvolvedores em geral tendem a estimar em torno de 20% para baixo do que a tarefa é de verdade. Estimativas para baixo são muito mais perigosas do que estimativas para cima.
Nota: Estimativas para baixo(Otimistas, até de mais) podem fazer com que o GP ache que a equipe pode ser de um tamanho X e na verdade depois pode se descobrir que o tamanho ideal seria X + 20. Uma vez isso, de nada vai adiantar contratar essas 20 pessoas depois, existiram diversos problemas. (É... Já passei por isso também).
A dica que eu dou para vocês é: Não reduzam as estimativas dos desenvolvedores, por que elas já são reduzidas por natureza. Se você quer entregar antes, existem outras formas, as quais falarei mais a frente neste post :)
Mas por que é importante estimar mesmo?
Por que boas estimativas dão as condições para que o projeto possa ser controlado de maneira adequada. Através de boas estimativas vamos saber se a equipe deve ser maior ou menor. O controle que pode ser realizado é:
- Remover requisitos que não são tão críticos
- Redefinir Requisitos
- Trocar equipe com menos experiência para equipe mais experiente
- Remover impedimentos como: Adquirir máquinas mais rápidas
Abordagem orientada a Objetivos
A melhor maineira de se trabalhar com estimativas é através da orientação a metas e objetivos. Por exemplo um stakeholder seta uma meta ou objetivo de negócio e a equipe técnica estima. Então ai existe o comprometimento do time para alcançar essa meta.
A equipe técnica não questiona a meta, os stakeholders não questionam a estimativa. Caso as datas não fechem eles devem discutir o comprometimento, ou seja, reduzir o escopo ou aumentar a equipe, etc...
Este tipo de abordagem nos dá mais alguns beneficio como:
- Aumentar a visibilidade do projeto para os stakeholders
- Aumento de Qualidade de produto de software
- Melhor coordenação com produtos que não são de softwares
- Melhor controle financeiro do projeto
- Detecção de Riscos mais cedo
- A credibilidade do time de desenvolvimento aumenta
Para estimar precisamos nos basear em algumas informações. Basicamente as estimativas são influencias pelos seguintes fatores:
- Tamanho do projeto (Pode ser linhas de código, ou número de páginas web, etc...)
- Tipo de projeto (Financeiro é mais difícil do que E-Comerce)
- Diversos Fatores específicos como: Capacitação de Requisitos, Desenvolvimento e experiência no domínio.
- Até mesmo as linguagens de programação (Java e mais produtivo que C)
Técnicas de Estimativas
Existem diversas técnicas para se estimar, algumas delas são muito velhas e datam até muito antes do computador ser criado.
Contar, Computar e Julgar: Nessa técnica nos contamos, pode ser qualquer coisa: linhas de código, requisitos, casos de uso, paginas na web. Após isso precisamos computar para ver o quando isso se representa e ai sim após isso precisamos de um julgamento para estimar os dias.
Opinião do Especialista: Neste método o especialista proferi sua opinião com base no seu conhecimento no domínio da questão. Podemos utilizar a evolução de desta técnica que é Opinião do Especialista Estruturada que consiste um usar formulas que vão do mais realista ao otimistas e até levando em considerações margens de erro.
Decomposição e Recomposição: Essa todos conhecem é onde se encaixa a WBS. Consiste em quebrar o que deve ser entregue em pequenas unidades de trabalho.
Estimativas por Analogia: Quando você já fez um software antes e esta fazendo um muito parecido com o anterior. Ai você pode usar analogias para estimar, mas cuidado essa técnica é perigosa.
Estimativas Baseadas em Proxy: Aqui se encaixam os Story Points utilizados no XP, entre outras técnicas como Fuzzy Logic, T-Shirt Sizing entre outras. Esse conjunto de técnicas é baseado em alguma escala e em um conjunto de informações.
Julgamento de Expecialistasem grupo: Na minha modesta opinião é a melhor técnica para se estimar em um projeto de software. Aqui entra o Planning Game do Scrum e o famoso Wideband Delphi. Essas técnicas consistem em realizar diversas estimativas através de um grupo de pessoas e utilziar ou as médias no caso do Wideband ou a votação no caso do Scrum.
A diferença das estimativas
Projetos que não dominam a arte negra das estimativas são assim:
Nesse tipo de projeto se tenta mudar as estimativas, no desenho a cima as estimativas são representas pelos Outputs. Nesse tipo de projeto o procedimento é totalmente Ad Hoc, ou seja, sem um mecanismo efetivo de estimativas. Nesse projeto existem uma série de problemas com comprometimento e alcance de metas e entrega de valor ao negócio.
Projetos que tem um mecanismo eficiente de estimativas são assim:
Os inputs (Boas informações para se estimar) são bem definidos, como por exemplo: escopo, priorização do product champion, constantes de negócio e dados históricos da organização e mais adiante do próprio projeto.
Existe um mecanismo de estimativas efetivo com alguma técnica aplicada, pode ser qualquer uma ou várias das técnicas que descrevi a cima. No final temos Outputs bem definidos (Estimativas) de: custo, esforço, cronograma, funcionalidades.
Esse projeto usa a abordagem orientada a Objetivos/Goals/Targets (São todos sinônimos) e tem excelente comprometimento com o negocio além de entregar valor.
Por hoje é só. Até a próxima :)
