wideband delphi

A técnica de estimar wideband delphi é uma técnica popularizada nos anos 80 do século XX.

Baseada noutra técnica, o método de delphi, é uma forma bastante democrática de obter uma estimativa.

Sem mais demoras vou explicar o essencial desta técnica:

1 – o gestor de projectos reúne uma equipa de especialistas apresentando a cada um de forma individual um requisito e um formulário de estimativa;

2 – o gestor de projectos convoca uma reunião onde é discutido cada requisito entre ele próprio e os especialistas;

3 – os especialistas preenchem o formulário de estimativa de forma secreta (tipo voto);

4 – o gestor de projectos compila as estimativas dos formulários;

5 – convoca nova reunião para apresentar de forma anónima as estimativas obtidas e incentivar a discussão dos requisitos que tenham tido maiores discrepâncias de estimativas;

6 – após a discussão os especialistas volta a preencher os formulários e repetem-se os passos de 4 a 6 até se chegar a um consenso.

Após esta descrição é possível que comecem a pensar: “mas eu já li isto em algum lado… espera lá… isto parece o planning poker!”

Exactamente! O planning poker baseia-se no wideband delphi. Com pequenas alterações (cartas em vez de formulários) mas no essencial está lá tudo.

Assim sendo, para vocês verem os principais benefícios desta técnica convido-vos a visitar (ou revisitar) o post sobre o planning poker. As vantagens são as mesmas.

Até para a semana.

Anúncios

planning poker

Já ouviram falar?

É natural que não visto ser um método de estimar mais usado em projectos de desenvolvimento de software AGILE.

O planning poker consiste numa reunião dos vários membros da equipa em que se tenta chegar a um consenso relativamente a um determinado tempo ou esforço/complexidade necessários para executar uma determinada user story (requisito).

Vou passar a descrever como funciona o planning poker, que apesar de parecer uma brincadeira, é para ser levado a sério e com resultados bastante satisfatórios:
– o gestor de projectos, gestor do produto ou cliente expõe o requisito que pretende ver implementado às pessoas que vão estimar (normalmente toda a equipa);
– a equipa coloca as dúvidas que achem necessárias e passa-se para uma votação;
– cada pessoa que vai estimar dispõe de cartas numeradas (não existe uma regra para a numeração das cartas, podendo ser por exemplo a sequência Fibonacci ou 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100);
– as pessoas pensam no número que acham que faz sentido para o requisito em questão e mostram ao mesmo tempo a sua escolha (desta forma garante-se que a opinião de cada pessoa é genuína e própria e não influenciada pela escolha de outra pessoa qualquer);
– se todas as pessoas escolheram o mesmo número então a estimativa está dada. Se não então quem deu a estimativa mais alta e mais baixa terá de expor os motivos pela sua opção. Após nova discussão outra sessão de voto terá lugar nos mesmos moldes da primeira;
– após mostrarem as respectivas cartas ou temos um consenso no número ou então fazemos uma média de forma a chegar a uma estimativa.

O planning poker pode ser feito até chegar-se a um total consenso, mas na minha opinião se deixarmos que um requisito “consuma” várias votações começa a ser contra-produtivo. Existem outras técnicas para rentabilizar ao máximo o tempo como a utilização de um cronómetro ou de uma ampulheta para limitar o tempo das discussões.

Existem também algumas variantes do planning poker que passam por adicionar uma carta:
– com um símbolo de café para alguém indicar que precisa de um intervalo (uma pausa) para poder estimar. Particularmente útil quando as discussões forem longas ou decorrerem várias votações para um requisito;
– com o símbolo de infinito para representar que o requisito é muito grande para ser executado de uma só vez e que deve ser redimensionado;
– com um ponto de interrogação para representar a incerteza sobre a estimativa.

Não existe total consenso sobre a representação dos valores das cartas.

Os números representam story points que podem ser dias, esforço ou outra unidade de medida. Recomendo-vos que representem dias visto ser a unidade de medida mais facilmente quantificável e menos subjectiva. Se optarmos pela complexidade teremos sempre de usar outro requisito como comparação o que pode tornar-se complicado se a equipa não for sempre a mesma (rotação dos elementos da equipa).

Para vocês “jogarem” planning poker basta comprar ou imprimir as cartas de poker ou então online através desta ferramenta gratuita disponibilizada pela Mountain Goat Software. A ferramenta online revela-se particularmente útil quando a equipa de projecto está geograficamente distribuída.

Os principais benefícios do planning poker são:
– toda a equipa dá uma estimativa o que é particularmente interessante visto obtermos a opinião de todas as pessoas envolvidas e obtermos o seu comprometimento (team engagement);
– as estimativas não são influenciadas pelos restantes membros da equipa visto na primeira votação reflectir a opinião de cada um;
– as discussões seguintes obrigam todas as pessoas a reflectir novamente no requisito, o que aumenta a precisão da estimativa;
– é uma técnica de consenso, pois a estimativa resulta de uma opinião partilhada ou em último caso de uma média;
– torna divertido a tarefa, normalmente chata, de estimar.

Quero por fim dizer-vos que apesar do planning poker ser essencialmente usado em AGILE, não há nada que impeça de ser usado noutra metodologia de desenvolvimento de software (exemplo: waterfall model)

Espero ter dado uma visão geral sobre esta divertida e original técnica de estimar.

Até para a semana.

COCOMO

O Constructive Cost Model (COCOMO) é uma técnica, dos anos 80 do século passado, de estimar apenas aplicável em projectos de desenvolvimento de software.

A base da estimativa do COCOMO são as linhas de código necessárias para o desenvolvimento do software.

O COCOMO decompõem-se em três níveis:
– Básico;
– Intermédio;
– Detalhado.

O COCOMO básico recorre ao esforço aplicado (em linhas de código i.e. KLOC), tempo de desenvolvimento e pessoas necessárias.

O COCOMO intermédio tem como ponto de partida o COCOMO básico e tem em consideração diversos aspectos:
– Atributos do produto;
– Hardware;
– Características da equipa;
– Características do projecto.

O COCOMO detalhado aplica os resultados do COCOMO intermédio nas várias fases do projecto de desenvolvimento de software.

Esta técnica assenta num modelo matemático, baseado em dados estatísticos. Só se justifica a sua utilização em projectos de grande dimensão e com base histórica.

O COCOMO é uma técnica complexa que vai devolvendo estimativas cada vez mais precisas à medida que a base histórica aumenta.

O ponto forte desta técnica é basear-se na complexidade do projecto e não no tempo do projecto. O principal calcanhar de Aquiles do COCOMO é que se mudarmos a equipa de projecto ao longo do tempo o histórico dos projectos torna-se irrelevante. O mesmo aplica-se aos restantes factores considerados pelo COCOMO intermédio, pois o COCOMO baseia-se no passado para dar as estimativas.

Julgo que a utilização desta técnica deve ser muito bem ponderada, pois tem um “custo” muito elevado em termos de complexidade e de time consumption. Por fim, não tenho dúvidas em afirmar que o COCOMO precisa de um ambiente fechado, controlado, muito estável para ser eficiente (algo muito raro de acontecer nos projectos de consultoria).

Cabe a vocês decidir até que ponto o COCOMO se enquadra na vossa realidade.

Até para a semana.

PERT

Existem várias formas de estimarmos a duração de tarefas e por conseguinte de um projecto.

Uma das mais famosas é a Program Evaluation and Review Technique, mais conhecida pela abreviatura PERT.

Esta técnica baseia-se no tempo e na probabilidade e tem como principio estimar um tempo optimista (Topt), um tempo realista (Treal) e um tempo pessimista (Tpess). A partir destes 3 tempos podemos chegar ao tempo médio (Tm) através da fórmula: Tm = (Topt + 4 * Treal + Tpess) / 6.

Se calcularmos todas as tarefas de um projecto através deste método ao subtrairmos ao Tm o Treal iremos encontrar o nosso buffer (tempo de reserva).

Exemplo: em condições normais uma tarefa é executada em 5 dias, se tudo corresse bem seria executada em 3 dias e se alguma desgraça acontecesse demoraria 10 dias.
Usando a fórmula acima descrita faríamos (3 + 4 * 5 + 10) / 6 para encontrarmos o Tm que é igual a 5,5 dias.

O nosso buffer seria de meio dia visto em condições normais a tarefa ser executada em 5 dias.

Claro que não devemos seguir esta fórmula cegamente. Olhando para este buffer devemo-nos questionar se será suficiente tendo em conta que numa perspectiva pessimista demoraríamos 10 dias para completar a tarefa. Depende obviamente da sensibilidade e experiência de cada um

Se a gestão de projectos fosse apenas aplicar fórmulas então éramos todos matemáticos. 🙂

Para me explicar melhor, se na fórmula aplicarem os seguintes dados:
Topt=2, Treal=5 e Tpess=7
constatam que o PERT torna-se optimista. Lá está, não deve ser seguido cegamente. Depende de situação para situação.

A partir deste momento podemos montar uma rede de PERT. Para isso precisamos de “alinhar” as nossas tarefas do projecto e apurar para cada uma os seguintes dados:
ES – Early Start
D – Duration
EF – Early Finish
LS – Late Start
S – Slack
LF – Late Finish

Early Start:
A primeira tarefa tem sempre o ES igual a 0. A próxima tarefa terá o ES igual à soma do ES e da duração da tarefa anterior e por aí adiante (no caso de estar precedida de mais do que uma tarefa será igual à maior soma de ES e duração das tarefas anteriores).
Nota: Para calcularem o ES deverão partir da primeira tarefa do projecto até à última.

Duration:
É o tempo médio calculado através da fórmula acima descrita: Tm = (Topt + 4 * Treal + Tpess) / 6.

Early Finish:
É igual ao Early Start + Duration.

Late Start:
É igual ao Late Finish – Duration.

Slack:
Pode ser calculado de duas formas. LF – EF ou LS – ES.
Nota: As tarefas do caminho crítico têm sempre folga zero.

Late Finish:
É o menor dos LS das tarefas seguintes. Se for a última tarefa o LF é igual ao EF.
Nota: Para calcularem o LF deverão partir da última tarefa do projecto até à primeira.

Depois de termos tudo isto calculado podemos e devemos determinar o critical path (caminho crítico) que é o caminho que mais tempo demora a ser concluído. Para sabermos o caminho crítico basta somarmos a duração das tarefas dos vários trilhos do projecto.

Agora é uma questão de pegar nas várias tarefas, fazer os cálculos e desenhar o diagrama de PERT do vosso projecto. Não se esqueçam de adicionar a vossa experiência e o vosso feeling qb.

Até para a semana.