quarta-feira, 13 de novembro de 2013

Como estimar seu trabalho


Gestão de tempo! Uma das disciplinas de Gestão de projetos menos compreendidas por todos. Cronograma e estimativa são frequentemente confundidos, gerando problemas de entrega de software. Infelizmente, não existe uma metodologia perfeita para estimar o trabalho de desenvolvimento, porém, há alternativas mais simples, que podem dar resultados positivos, especialmente em equipes ágeis.


O tempo é relativo

Para muitas pessoas, o tempo que vai demorar para executar um trabalho é um pacote completo e fechado. Assim sendo, elas consideram apenas dois fatores: Data e Produto. 

Sempre que posso, pergunto às pessoas o que é um "cronograma", e sabe o que a maioria delas me responte? Isso: "É uma lista de datas e entregáveis". Você também pensa assim? 

Na verdade, o tempo gasto para executar uma tarefa depende de mais fatores, entre eles:
  • Quando os recursos estarão disponíveis?
  • Por quanto tempo os recursos estarão disponíveis?
  • Os recursos disponíveis terão a capacidade para atender às estimativas?
  • Há risco de não termos os recursos estipulados, no tempo necessário?
Para começar, a maioria das pessoas não faz estimativas, e, quando o fazem, não consideram a capacidade e disponibilidade dos recursos necessários. Tampouco consideram a própria experiência (ou da equipe). Simplesmente "chutam" uma data e pronto. 

Além disso, frequentemente, a data "chutada" contém alguma "gordura", por conta de possíveis riscos. 

Logo, o tempo é relativo e depende, entre outras coisas, da aversão ao risco de quem está estimando. 




A diversidade e a comunidade

Quando falamos de recursos, muitas vezes estamos falando de pessoas, e as pessoas diferem entre si, em vários aspectos. Quando falamos em trabalho, temos que considerar como as pessoas vão desempenhar o papel esperado nas tarefas. Isto depende, entre outras coisas, da experiência de cada pessoa individualmente. A experiência pode ser medida em Senioridade, ou seja, tempo de experiência, mas, com alguma frequência, isto não é suficiente. 

Se a pessoa passou muito tempo trabalhando apenas em um determinado sistema ou com uma determinada tecnologia, pode se tornar refratária às novidades, logo, esta resistência poderá gerar problemas no desenvolvimento de um software.

Outro fator a ser considerado é o próprio estilo de trabalho de cada pessoa. O professor Ichak Adizes (http://en.wikipedia.org/wiki/Ichak_Adizes), criou o conceito de estilos gerenciais, que pode ser muito bem aplicado à forma como as pessoas gostam de trabalhar e interagir em equipe: (PAEI
  • P - Produtividade: Pessoas com este estilo são cheias de energia, gostando de trabalhar muito. Frequentemente se ocupam de diversas tarefas simultaneamente e gostam de antecipar prazos. São muito focadas em prazos imediatos, não tendo muita paciência com coisas futuras. Além disto, como o "P" é mais importante para elas, trabalham de qualquer maneira e sob quaisquer condições, frequentemente criando um ambiente tenso e desorganizado;
  • A - Administração: São pessoas metódicas, mais preocupadas com a maneira de trabalhar do que com o prazo de entrega. Sabem organizar muito bem o trabalho e produzir relatórios muito bem feitos, porém, não são muito bons em situações onde devem lidar com criatividade. Frequentemente batem de frente com os "P"s, pois os consideram como caóticos;
  • E - Empreededorismo: Estes são visionários por natureza. Sempre antenados com as últimas novidades, vivem pulando de pico em pico das montanhas, como águias, enquanto a equipe, com pernas, não conseguem acompanhá-los. Normalmente, acabam tendo platéia, que os aplaude, mas que não seguem suas ideias. Não conseguem produzir de forma linear porque sempre mudam de ideia quanto à tecnologia envolvida;
  • I - Integração: As pessoas com este etilo procuram manter as pessoas unidas em torno de um objetivo comum. Não se preocupam muito com organização, com regras ou com prazos, mas com as pessoas e seu relacionamento. Gostam de manter um excelente "networking" e, na maioria das vezes, são vistos como "políticos".
A diferença entre "equipe" e "comunidade" é justamente a combinação das diversidades pessoais. Equipe, na maioria das empresas, é um ajuntamento aleatório de pessoas, sem considerar a experiência ou o estilo de cada um. Equipes são caóticas por natureza. Por exemplo: 
  • Equipe com maioria de juniores: A falta de experiência pode gerar resultados insatisfatórios, e afeta a distribuição do conhecimento tácito;
  • Equipe com maioria de seniores: Os juniores serão colocados "de lado", e, frequentemente tratados sem maiores considerações;
  • Equipe com maioria de "P"s: Apaga "incêndios" criando outros! Realmente, conseguem atender prazos ridículos, trabalhando de maneira destrutiva;
  • Equipe com maioria de "A"s: Escreve belos relatórios, mas trabalho, que é bom, nada... Servem para fazer uma briga de gangues com a equipe de "P"s;
  • Equipe com maioria de "E"s: É um bando de "malucos", que vivem "inventando moda" às custas dos outros e não conseguem produzir nada útil. Os "A"s e os "P"s vivem querendo bater neles;
  • Equipe com maioria de "I"s: Um grupo de "conversinhas-fiadas", que passam o tempo todo de "lero-lero" e não conseguem produzir nada. Vivem tentando apartar os "P"s e os "A"s, e gostam de bater papo no café com os "E"s;
Antes de estimar, é preciso agregar pessoas, e, para isto, é necessário lidar com a "diversidade", formando "comunidades", ao invés de equipes. É isto que cria times vencedores!




Riscos e recompensas

Todo empreendimento tem riscos. Quanto maiores os riscos, maiores as recompensas. É assim e sempre será. Quando falamos de projetos de software, isto também é verdade, pois, se ficarmos evitando os riscos, acabaremos evitando a inovação. 

Empregar técnicas ou alternativas arriscadas é saudável para criar projetos inovadores e bem sucedidos, porém, é necessário tomar algumas precauções:
  1. Deve haver critérios claros para todas as alternativas;
  2. Os riscos de cada alternativa devem estar claros e explícitos;
  3. Os riscos devem ser tratados.
Infelizmente, a maioria das pessoas prefere "esconder" os riscos, "engravidando" prazo e custo, de forma a se precaver. Isto pode acontecer por vários motivos:
  • O Cliente é chato e frequentemente fica mudando de opinião;
  • Os recursos são difíceis de obter e podem ser desalocados abruptamente;
  • A tecnologia não é bem compreendida pela equipe;
Parece sensato, não? Porém, o lado negativo desta abordagem é: E SE NÃO ACONTECER? Você vai chegar para o Cliente e dizer: "Tá aqui o excesso de grana que você pagou, pois você não foi tão chato assim" ou então: "Eu sei que previmos seis meses, mas fizemos em 2"? É claro que não!

Embutir risco é falta de transparência! As estimativas devem ser sempre feitas de forma objetiva e de maneira mais realista possível. Riscos podem e devem ser considerados, mas devem ser explícitos, por exemplo: 
  • "Olha, eu estimo o esforço dessa mudança em 48 homens-hora, porém, como você é chato e indeciso, eu estou reservando mais 24 homens-hora e mais US$ 2.000, para caso este risco ocorra, ok?"
Assim como os riscos vindos do Cliente, existem os riscos vindos da equipe. Por exemplo, usar uma abordagem ou tecnologia diferente, pode gerar melhores resultados, porém, pode haver riscos novos. Isto tem que ficar claro para o Cliente. Por exemplo: 
  • "Nós sempre usamos este componente, mas agora, soubemos desse novo componente, que é mais fácil de usar e pode melhorar a performance do Web Site, mas não temos muita experiência com ele, então, vou reservar mais 32 homens-hora e mais US$ 1.500,00 para o risco causado por isto. O que você prefere? Prefere que façamos com o componente antigo ou com este novo?"


Como estimar?

Estimar o trabalho a ser desenvolvido é fornecer o esforço necessário: Tempo, recursos envolvidos e custo:
  • Tempo: Pode ser medido em homens-hora, ou seja, qual é o tempo que uma pessoa demora para executar a tarefa;
  • Recursos: Quais recursos são necessários para que a estimativa seja cumprida? Qual a capacidade? Por exemplo, quantas pessoas serão empregadas e qual a experiência exigida para que o tempo informado seja verdadeiro? E outros recursos? Por exemplo: Um servidor de arquivos.
  • Custo: Quanto custará para alocar e usar os recursos estimados, de modo que o tempo seja alcaçado?
Note que, até agora, não falamos em prazo ou em dadas. Estimativa e prazo são coisas diferentes!

Exemplo de estimativa: 

  • Atividade: "Criar o Web service de consulta à base";
  • Tempo: 60 hh;
  • Recursos: 
    • 1 Desenvolvedor SR, com experiência em RESTful web services em Java;
    • 1 Servidor Web de desenvolvimento, compatível com a plataforma, pelo menos 40 horas;
  • Custo:
    • Desenvolvedor SR: Custo por hora = US$ 200,00, total = US$ 12.000,00;
    • Servidor Web: Custo por hora = US$ 15,00, total = US$ 600,00;
    • Total geral: US$ 12.600,00.
E os riscos? 

Bem, consideramos os seguinte risco e seu tratamento:
  • Não há desenvolvedor com este perfil disponível:
    • Estratégia: Aceitar;
    • Mitigação: Trocar um desenvolvedor da tarefa X e colocar dois plenos;
    • Tratamento: Alocar um pleno e um júnior;
    • Impacto: mais 32 horas de prazo, com mais US$ 80 de custo por hora;
Este risco não está "embutido" na estimativa, e deve ser considerado para a formação de reservas de contingência, uma vez que estamos aceitando a sua possibilidade.

Mas, e o prazo?

Putz! Você ainda está "encucado" com isso? O Cronograma só pode ser feito quando TODAS as tarefas, das quais esta tarefa depende, estiverem estimadas. Antes disto, não dá nem para pensar em prazo, Cacilda!

O prazo é função da estimativa e da disponibilidade dos recursos necessários!

Depois das estimativas prontas, devemos avaliar nossa equipe disponível, de modo a ver se atendem às necessidades. Precisamos saber SE E QUANDO os recursos estarão disponíveis, além disto, precisamos saber POR QUANTO TEMPO. Pode ser que os recursos não estejam disponíveis durante um dia inteiro de trabalho, mas apenas algumas horas, e temos que considerar: Férias e Feriados. 

De posse do "Cronograma de recursos", podemos finalmente fazer o "casamento" com as estimativas, gerando o MALDITO CRONOGRAMA!


Estimativa não é bola, para ser chutada!

Eu fiquei te "enrolando" até agora, só para, finalmente, falar do assunto deste artigo: Como estimar o esforço!

Como você estima o esforço? Alguns falarão em "Ponto de função", coisa que me deixa ESPUMANDO DE ÓDIO! Ponto de função não é métrica de esforço! Por acaso, você sabe a produtividade da sua equipe, expressa em "pontos de função"? É claro que não!

É claro que algumas fábricas de software têm essas estimativas e as utilizam, mas nem todo ponto de função é igual a outro! Existem especificidades que podem comprometer toda a sua estimativa. 

Então, como estimar? Uma das maneiras bem hilárias, porém efetivas é o "Poker Planning".

Poker Planning


É uma maneira de alcançar o consenso em torno de estimativa de esforço, utilizado em métodos ágeis. Consiste em reunir a equipe para avaliar as estórias de usuário (casos de uso), tentando formar uma estimativa em unidades (geralmente, dias). 

Os participantes recebem um deck de cartas, numerado, geralmente assim: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 e "?", significando incerteza. Quando um consenso é alcançado, então esta estimativa é utilizada. Se o consenso for "?", então a história é muito grande para ser estimada, ou faltam detalhes. Neste caso, ela é trabalhada para se chegar a histórias mais simples.

O Poker planning evita o problema de "ancoragem no primeiro tiro", por exemplo, eu digo; "Para mim, creio que seriam 3 dias", então, as outras pessoas podem ficar influenciadas por este prazo e usá-lo. Ao esconder minhas estimativas, evitamos qualquer viés, tornando a opinião mais pessoal. 

O método pomodoro


Pomodoro é tomate, em italiano, e se refere à queles cronômetros de cozinha, em forma de tomate, no qual marcamos o tempo de cozimento. Geralmente, eles têm até 25 minutos. 

Um pomodoro é o tempo máximo do cronômetro, e é a sua unidade de tempo de trabalho, logo, você deve dividir seu tempo em "pomodoros". Você deve dividir sua tarefa em "pomodoros", calculando suas estimativas desta forma. 

É uma simplificação do método. 

Unidade de produção

Eu costumo usar um método pessoal, derivado do Método Pomodoro, que eu chamo, informalmente, de "Unidade de produção". 

Para mim, uma unidade de produção é o tempo mínimo para concluir alguma coisa útil, e é dividido em:
  • Compreensão da meta a ser alcançada;
  • Estudos necessários;
  • Obtenção dos recursos;
  • Criação do caso de teste;
  • Codificação;
  • Teste unitário.
Cada tarefa de desenvolvimento envolve todas estas atividades. Eu estimo que 2 horas é a minha unidade de produção, assim, posso gastar a primeira hora nas quatro primeiras atividades e a segunda na codificação e teste.

Se eu demorar mais de duas horas para criar uma determinada classe, eu procuro dividi-la em classes menores, de modo que caibam na minha "Unidade de produção".

Eu procuro refatorar meu trabalho, de forma que cada unidade a ser desenvolvida possa ser partida em "Unidades de produção", e as desenvolvo em sequência. 

E posso manter um registro de quantas unidades de produção estou fazendo por dia, logo, posso calcular prazos de acordo com a minha produtividade. 

Resumo da fritada

Seja usando o "Poker Planning" ou o Método Pomodoro, duas coisas são importantes para você estimar esforço: 
  • Dividir o trabalho em unidades mensuráveis e administráveis;
  • Ter um registro do seu histórico de produção de unidades, ANTES de calcular prazos.