Estimativa de Produtividade

Engenharia de Software | Gerenciamento de Projetos de Software | Estimativa de Produtividade

Estimativas ágeis

Um dos grandes desafios de profissionais da área de desenvolvimento de software é como estimar o esforço para a criação de novas funcionalidades, tarefas ou histórias. O principal objetivo de se estimar é criar uma métrica comum para definição e comparação de esforços, e consequentemente definições de prazos (e orçamentos) para projetos e/ou atividades. Temos diversas formas de estimar software desde os antigos KLOCs (KiloLlines of Code ou mil linhas de código), homem-hora, pontos de função, entre outras. É inegável que estimar é fundamental, mas vemos que grande parte do esforço empreendido em estimar com precisão é perdido, devido a alguma premissa que não se tornou verdadeira ou porque à medida que trabalhamos no projeto, com mais conhecimento, somos obrigados a ajustar nossas estimativas.

As formas mais comuns em estimativas são as apresentadas pelo PMBok®, Guia de Boas Práticas do Project Management Institute® e estão expostas a seguir:

1 – Estimativa de um ponto: Apresenta a estimativa por atividade. Pode ser baseada na opinião especializada, informações históricas ou simplesmente adivinhação.

2 – Estimativa Análoga (“Top Down”): Usam opinião especializada e informações históricas para prever o futuro.

3 – Estimativa Paramétrica: Observa os relacionamentos entre as variáveis em uma atividade para calcular estimativas.

4 – Estimativa de Três Pontos (Análise PERT): Considera a média entre a estimativa no melhor cenário (O), adicionada quatro vezes à estimativa mais provável (M), mais a estimativa do pior cenário (P) , dividida por seis.

( P + 4M +O ) / 6

Atividades de desenvolvimento de software

Atividades de desenvolvimento de software (projetos orientados a valor) geralmente são bem mais complexas do que atividades da construção civil, como uma pintura de corredor, por exemplo, (projetos orientados a planos) pois em um novo projeto de software os requisitos nunca serão completamente conhecidos até que o usuário os tenha utilizado, assim, o grande desafio nas estimativas de software está relacionado às dificuldades da clara definição do escopo do produto, da definição da estratégia de como uma atividade será realizada e pelo simples fato que em um grupo distinto a experiência, conhecimento técnico, cultura etc. irão influenciar na estimativa de cada um, por isso todas as estimativas tendem a apresentar imprecisão.

Lembre-se de que quando utilizamos “horas ou dias” como unidade de medida, estamos estimando não só o esforço necessário para a tarefa, mas também a velocidade individual dos membros que trabalharão nela.

A comunidade adepta aos métodos e frameworks ágeis geralmente procura utilizar estimativas que levam em consideração apenas o esforço para a realização de determinada tarefa (histórias), onde todos os envolvidos no desenvolvimento medem as diversas tarefas e assim definem estimativas comparativas (com margens de erro) entre todo o trabalho que precisa ser realizado.

Veja a história relatada por James Surowiecki que em seu trabalho intitulado “A Sabedoria das Multidões” apresenta uma experiência realizada em 1906, quando o cientista britânico Francis Galton ficou chocado com o resultado de um experimento realizado por ele, em uma feira municipal. O desafio era que um açougueiro profissional deveria adivinhar com precisão o peso de um boi abatido. Sua surpresa ocorreu ao descobrir que pessoas que visitavam a feira (com pouca ou nenhuma experiência em cortes de carne) eram capazes não só de adivinhar o peso final do animal, mas eram capazes de adivinhar com grande precisão (inclusive com quilogramas e os detalhes em gramas). A expectativa de Sir Francis era que os peritos (açougueiros profissionais) estavam sempre bem e iria superar com folga uma multidão, o que não ocorreu.

Planning Poker

Quando estamos jogando o Planning Poker, uma técnica de estimativa utilizada pela comunidade ágil, nós igualmente estamos aproveitando a sabedoria das multidões com relação a nossas estimativas. Estamos apostando que o público será capaz de chegar a um melhor palpite do que qualquer indivíduo único.

O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos (pontos) relativos.

Como funciona:

Uma pessoa apresenta a tarefa ou história para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa.

Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, essas diferenças são discutidas de forma breve. Geralmente, quem estimou com os maiores e menores valores explicam o motivo de sua estimativa, e uma nova rodada acontece até que haja a convergência.

Exemplo de cartas que geralmente são utilizadas no Planning Poker.

O Planning Poker funciona porque utiliza opinião de diversos especialistas (que irão realmente realizar a tarefa) e promove o diálogo que permite maior acuracidade das estimativas, principalmente em itens com maior incerteza. Além de ser uma técnica de estimar considerando a experiência de todos da equipe, proporciona um conhecimento do negócio mais homogêneo e é mais atraente (e divertida) que as demais técnicas.

Geralmente o baralho do Planning Poker apresenta cartas com escala da sequência de Fibonacci, isso se deve ao fato da sequência de Fibonacci ser uma função quadrática, ao invés de uma função linear, assim, as diferenças entre valores são produzidas de forma muito rápida criando intervalos logo no início da sequência. Veja que as estimativas apresentam erros, mas quando podemos comparar as tarefas (uma tarefa com 8 pontos não significa que ela tem exatamente este tamanho, mas é algo entre 5 e 13 pontos) conseguimos dimensionar com mais precisão o esforço que deverá ser empreendido. Existe também a opção infinito, carta com a marcação “∞“, geralmente quando o time identificou um história que considera EPIC.

Técnica PMG

Outra forma de estimativa muito utilizada no mundo ágil é a técnica PMG, uma analogia as medidas de roupas, onde cada item é classificado como P para pequeno, M para médio e G para grande, de acordo com a percepção de esforço do time para entregá-la.

Sempre devemos lembrar que:

1 – A definição do pontos de cada história é de exclusividade do Time.

Lembre-se de que o esforço empreendido em cada Sprint (ou interação) pode variar de acordo com cada time. 18 pontos para o “time A” e 18 pontos para o “time B” não são o mesmo esforço. A percepção de quanto esforço é necessário para realizar um ponto é subjetiva e diferente para cada time.

2 – Os pontos definidos em cada história devem envolver todo o esforço para entregá-la pronta para funcionar no ambiente real. Significa que devemos considerar a complexidade devido ao desconhecimento ou incertezas, o esforço do trabalho e os riscos associados em nossas estimativas.

3 – O tamanho do esforço deve ser relativo. Isto é, quando dizemos que para entregar a “história A” definimos 8 pontos e para a ”história B” 16 pontos, significa que o esforço para entregar B é o dobro de A (mesmo que haja uma pequena variação devida à natureza imprecisa das estimativas ágeis). Observe que neste ponto devemos estar atentos às estimativas por afinidade, podemos agrupar as histórias por proximidade de esforço pontuado (pelo time), o que facilita o dimensionamento do trabalho como um todo.

Um pouco mais sobre times ágeis

Como podemos ver, nos diversos métodos ágeis temos processos e eventos como as reuniões de planejamento, reuniões diárias, retrospectivas e outras, porém o primeiro valor do manifesto ágil é:

“Indivíduos e interações mais que processos e ferramentas”

Os processos e eventos são facilmente descritos (até seguidos), porém eles sempre dependerão dos indivíduos e suas interações, e estes já são mais difíceis de serem generalizados e documentados como regras. Veja que cada indivíduo possui características únicas como personalidade, conhecimento técnico, cultura, valores, momento de vida etc. e todos esses fatores influenciarão nas interações e em como o trabalho fluirá. Esse valor do manifesto ágil reflete a seguinte sentença mensagem:

“Bons profissionais mesmo com poucos processos (ou até mesmo sem nenhum) conseguem superar os maiores desafios. Mesmo utilizando os melhores processos, um time ruim irá falhar até mesmo em algumas tarefas simples. Líderes de times ágeis devem concentrar-se nos fatores humanos (pessoas e relacionamentos) para obterem o melhor resultado”.

Liderança adaptativa

O termo liderança adaptativa se refere a como devemos lidar com o time dependendo da maturidade do time e de cada circunstância. O autor Bruce Tuckman, no trabalho “Developmental Sequences in Small Groups“ – Psychological Bulletins 63 (1965), foi um dos primeiros a identificar as fases em que um time pode se encontrar desde a sua formação até chegar a um estado de time de alta performance.

Na fase de Formação os membros (ainda não são um time) começam a trabalhar em grupo. Eles iniciam o processo de aprendizado uns sobre os outros e nesse momento inicia-se o autoconhecimento do futuro time. Nesta fase identificamos um grupo altamente comprometido, porém sem grandes conhecimentos, logo, a liderança deverá atuar bastante no direcionamento do trabalho, para isso questionamentos como “Deixe-me ver isso?” “Onde está o problema?” “Qual o próximo passo?” serão bem comuns.

A formação ocorre sempre que um novo membro é introduzido no time (mesmo que os demais, ou a maior parte do time permaneça). Nesses casos o tempo tende a ser menor do que a formação de um time completamente novo.

Com o andamento do trabalho diversos conflitos e divergências irão surgir. O grupo passou para a fase de tempestade, onde se torna um pseudo-time. Os seus membros desafiam-se entre si para a realização dos trabalhos. Durante a fase da tempestade observa-se diálogos mais ásperos, conflitos abertos e até insatisfação, por isso a liderança precisa atuar orientando o time nos diversos aspectos e auxiliando na solução de questões.

Quando falamos em conflito, devemos sempre lembrar que:

• O conflito é natural e força uma busca de alternativas;
• O conflito é uma questão de equipe;
• A abertura resolve conflitos;
• A resolução de conflitos deve se concentrar em questões e não em personalidade;
• A resolução de conflitos deve se concentrar no presente e não no passado.

O Project Management Body of Knowledge (PMBok)®, Guia de Boas Práticas do Project Management Institute (PMI)®, sugere que podemos mitigar os conflitos, sempre lembrando e relembrando ao time:

• Exatamente para onde o projeto está direcionado;
• As restrições e objetivo do projeto;
• O conteúdo do Termo de Abertura do Projeto;
• Mudanças;
• Decisões Importantes;
• Tornar as tarefas desafiadoras;
• Seguir as boas práticas de gerenciamento de projetos.

O PMBoK®, apresenta as sete origens de Conflitos em ordem de frequência:

1ª) Cronogramas;

2ª) Prioridades do Projeto;

3ª) Recursos;

4ª) Opiniões Técnicas;

5ª) Procedimentos Administrativos;

6ª) Custo;

7ª) Personalidade.

Na fase de normalização o time em potencial começa a se tornar um verdadeiro time, aprendendo como trabalhar uns com os outros. Neste momento o time deve criar regras para ajudar/governar o próprio trabalho. A liderança é um pouco mais “tímida” e concentra-se mais no auxílio à resolução de alguns conflitos, assim como lembrar constantemente das regras criadas por eles mesmos. Nesta fase é um bom momento para desafiar o time, para auxiliá-lo a se tornar um time de alta performance.

Na fase de performance os times são altamente competentes e comprometidos, autônomos, empoderados, auto-organizados e autopoliciados. O time trabalha com um só, com alta performance no trabalho e nas suas entregas. Cada indivíduo conhece bem as características dos demais membros do time, a liderança assume um papel de trazer novos desafios (para que o time resolva) sempre buscando a melhoria contínua. Muitos times dificilmente chegam à fase final devido a mudanças na sua composição.

Inteligência emocional

Inteligência emocional é a nossa capacidade de identificar, avaliar e influenciar nossas próprias emoções, de outros indivíduos e de grupos. O quadro a seguir identifica os diferentes aspectos da inteligência emocional. Veja:

A separação dos aspectos da inteligência emocional nos quadrantes significa que primeiro precisamos conhecer nossas emoções para poder controlá-las, isto é, precisamos saber o que nos irrita, nos frustra, nos faz perder o foco para depois escolhermos uma estratégia para tratar e responder a essas situações e sentimentos. Devemos desenvolver essas habilidades para decidir se vamos deixar essas emoções nos afetar ou se iremos responder de maneira diferente.

Daniel Goleman, no artigo “Primal Leadership: The Hidden Driver of Great Performance”, publicado na Harvad Business Review, em 2001, afirma:

“O humor e comportamento do Líder conduz os humores e comportamentos de todos os outros. Um chefe mal-humorado e cruel cria uma organização tóxica preenchida com sentimentos negativos que ignoram as oportunidades“.

Como líderes de times devemos trabalhar as habilidades que nos permitam identificar as situações que influenciam negativamente os membros do time a ajudá-los (os membros) a desenvolver estratégicas para mitigar ou eliminá-las. Reconhecer que outros precisam de ajuda nos ajuda a melhorar a performance individual e do time, promove a colaboração e o trabalho em equipe.

Comunicação e o ambiente de trabalho

Segundo o Antigo Testamento (Gênesis 11,1-9), os descendentes de Noé, com a intenção de eternizar seus nomes, iniciaram o projeto da construção da torre do templo de Marduk, (nome cuja forma em hebraico é Babel ou Bavel e significa “porta de Deus”), uma torre tão alta que chegaria céu.

O projeto provocou a ira de Deus que para puni-los, decidiu criar os diversos idiomas para o povo da Terra, assim o processo de comunicação entre os “construtores” foi comprometido e a torre não foi terminada.

Esse mito é uma tentativa de se explicar as diversas origens dos idiomas e apresenta um risco real em todos os projetos (inclusive nos projetos atuais).

Segundo o Project Management Institute (PMI)® existe uma correlação direta entre a capacidade de comunicação e o desempenho do projeto, isto é, um bom gerenciamento de comunicações é fator determinante de sucesso ou fracasso em projetos. Segundo o Project Management Body of Knowledge (PMBok)® que é um conjunto de boas práticas em gerenciamento de projetos, o gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada.

Observe que muitas vezes não dedicamos o tempo necessário nesse gerenciamento, mas vamos a um simples exemplo:

Se o projeto possui 5 integrantes, existem 10 canais de comunicação.

Pode-se descobrir o número de canais de comunicação de uma forma relativamente simples, veja:

[N * (N-1)]/ 2

Onde: N é o número de pessoas envolvidas no projeto.

Plano de comunicação

Existem várias barreiras no processo de comunicação, como:

Um ponto crítico das interações dentro do projeto é deixar claro que as comunicações precisam de formalidade e devem necessariamente passar pelo gerente de projeto. Caso contrário, os riscos de problemas de comunicação podem crescer significativamente.

O primeiro passo para um bom plano de comunicação é identificar todas as partes interessadas em um projeto – elas são: quem influencia ou é influenciado pelo projeto ou pelo resultado do projeto – já que podem influenciar o fracasso ou o sucesso do projeto. É claro que algumas partes interessadas podem influenciar mais do que outras em um projeto, mas é importante que todas sejam identificadas. Dentre muitos fatores, a identificação das partes interessadas possibilita ao gerente ter uma visão dos interesses e expectativas de cada parte em relação ao projeto, o que ajuda muito em negociações e no gerenciamento das expectativas.

Um conceito básico é que as comunicações devem ser eficientes (fornecendo apenas as informações necessárias) e eficazes (informações nos formatos certos e no momento certo). Veja:

• Quem deve receber quais informações?
• Quais são as reais necessidades de informação?
• Qual informação é necessária, de que tipo?
• Em que formato e meio deve ser transmitida a informação?
• Com que frequência?
• Qual é o fluxo de informações?

Existem diversos tipos de comunicação: escrita, verbal, formal, informal, não formal, paralinguística, interativa, passiva, ativa etc.

A cultura da empresa pode ser uma barreira ou um facilitador, por isso uma análise da cultura organizacional é fundamental no papel do gerente de projetos como integrador de áreas, ou seja, inteligência conversacional.

Um gerente de projeto passa aproximadamente 90% do seu tempo se comunicando e para que o projeto tenha maiores chances de sucesso, entre outras coisas, um bom plano de comunicação é fundamental.

Comunicação osmótica

Muitas técnicas, ferramentas e recomendações ágeis preveem a interação “cara-a-cara”, assim o espaço onde o time irá trabalhar pode ser um fator de melhora nos processos. Times ágeis preferivelmente devem trabalhar em espaços sem barreiras e de fácil acesso. Agrupar os times em um mesmo ambiente facilita a interação, diminui o desperdício (provocado por espera por uma informação ou deslocamento), além de promover a comunicação osmótica.

Você sabe o que é comunicação osmótica?

Comunicação osmótica refere-se a toda informação útil que flui de membros da equipe como parte de conversas e perguntas diárias, quando trabalham em estreita proximidade um do outro. Alistair Cockburn, em seu trabalho “Agile Software Development” define a comunicação osmótica como: “Campos de energia que irradiam de pessoas. Se você está muito longe, você recebe muito pouco, mas se você estiver trabalhando em estreita proximidade, você obter todos os benefícios”.

Para facilitar a comunicação cara a cara e o compartilhamento de conhecimentos, é recomendado que os times sejam de tamanho reduzido, geralmente com até 12 membros ou menos (Lembre-se de que o aumento da complexidade da comunicação é diretamente proporcional ao número de pessoas envolvidas). Quando os projetos são maiores, o recomendado é trabalhar com diversos times, utilizando técnicas como o Scrum sob Scrum.

Equipes virtuais

Quando trabalhamos com equipes virtuais (distantes geograficamente) temos que utilizar os recursos tecnológicos, como por exemplo, programas de mensagens instantâneas, videoconferências, VoIPs, interfaces remotas e colaborativas etc. para promover a comunicação constante.

Sempre que possível promova pelo menos uma reunião onde todos os membros do time estejam presentes, mesmo que no dia a dia eles trabalhem distantes, uma atividade para que eles se conheçam (fisicamente) catalisa a fase de formação e melhora as futuras comunicações.

Acompanhamento de produtividade

Um dos grandes desafios de projetos ágeis é o acompanhamento de produtividade. A medição é fundamental para planejarmos cronologicamente as versões e itens que serão entregues em cada Sprint.

Antes de apresentarmos as formas de acompanhamento de produtividade, devemos lembrar que:

A mudança do tamanho do Sprint ou da composição do time (mesmo que seja a saída ou entrada de apenas um novo membro) alterará a base histórica de entrega do time e as medições deverão ser novamente contabilizadas.

Release Burndown Chart

A ferramenta de Release Burndown permite acompanhar a evolução das versões de seu produto de maneira simples e visual. O eixo vertical apresenta o esforço da release (este esforço foi estimado pelo time, em pontos, horas ou outra métrica pré-acordada), o eixo horizontal representa as sprints. Observe que o eixo tem comportamento decrescente e inicia-se no topo do eixo vertical e termina na base (ponto O) desse mesmo eixo.

O gráfico Burndown Chart também pode ser aplicado para o acompanhamento do Sprint, seguido os mesmos princípios. A diferença está no eixo horizontal, onde, ao invés de marcar o número do Sprint, ele acompanha a evolução dos dias do Sprint, conforme apresentado na figura a seguir:

Observe na imagem que baseado no número de pontos (eixo vertical) podemos planejar a evolução do trabalho até que ele esteja completamente pronto, representado pela linha azul na imagem. Com o Sprint iniciada, atualizamos o gráfico e medimos nossa evolução em relação ao planejado, representado pela linha vermelha.

Cumulative Flow Diagram (CFD)

O CFD é uma ótima ferramenta para monitoramento do trabalho de desenvolvimento. Com ele podemos acompanhar o trabalho que falta, o trabalho em progresso (WIP) e o trabalho pronto. Seu funcionamento é simples, no eixo vertical temos o trabalho estimado em pontos, horas ou outra métrica predefinida pelo time, no eixo horizontal, o tempo (em dias, semanas ou sprints). Uma grande diferença entre o CFD e o Burndown Chart é que podemos visualizar o trabalho em progresso.

Veja na imagem que a área em cor amarela apresenta o trabalho que está pendente, isto é, trabalho não iniciado, a área laranja representa o trabalho em progresso e a azul o trabalho pronto.

Observe que o gráfico pode ajudar o Scrum Master e o time a analisarem o comportamento do processo e auxiliar os ajustes necessários. No exemplo da imagem temos uma área com grande amplitude na cor laranja (WIP), significa que o time iniciou mais tarefas em paralelo antes de finalizar as que já estavam em desenvolvimento, essa ação, em geral, deve ser evitada, lembre-se que é mais importante entregar tarefas do que iniciar novas (acumulo de WIP não é bom sinal).

Quando o gráfico de seu time apresenta grande distância do pronto para o não iniciado significa que seu time está com muitos trabalhos em progresso, é possível (e aconselhável) determinar um limitador para atividades em andamento, por exemplo, só 2 histórias em paralelo, para evitar o acúmulo do trabalho em andamento e o atraso nas entregas.

Referências

SCRUM GUIDE. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf>. Acesso em: 20 jan. 2015.

Engenharia de Software | Gerenciamento de Projetos de Software | Estimativa de Produtividade