| layout | title | meta-title | meta-description | bigimg | author | date |
|---|---|---|---|---|---|---|
post |
6 atitudes para acertar nas estimativas e entregar software dentro do prazo |
Prazos e Estimativas: 6 atitudes para acertar nas estimativas e entregar software dentro do prazo |
/img/posts/clock-and-computer.jpg |
Vítor Nogueira |
2017-06-21 01:00:00 -0700 |
Você já teve dificuldade em dar prazo para a entrega de uma funcionalidade no seu projeto? Já recebeu um projeto e quando olhou para o prazo disse: huuuuum, não vai dar para entregar...
Se sua resposta foi sim para essas perguntas, não se preocupe, a maioria dos programadores tem dificuldade em lidar com prazos, mas existem algumas atitudes que você pode ter para diminuir seu sofrimento.
Essas atitudes vão te ajudar a trabalhar melhor com prazos seja quando você e sua equipe precisarem dar o prazo para entrega de um produto ou quando começarem um projeto com um prazo pré-determinado.
É até meio óbvio a necessidade de entender o projeto antes de dar um prazo para entrega, não é? Mas como você e sua equipe sabem que entenderam todo o projeto antes de estimar uma data para entrega?
Entender todo o projeto, esclarecer todas as dúvidas e definir todos os requisitos é o primeiro passo para começar a estimar prazos. Existem algumas técnicas que podem te ajudar a entender o projeto de um jeito mais simples e eficaz, como por exemplo Inception e Design Sprint.
Por experiência própria posso te garantir que se você dedicar mais tempo entendendo o problema que você precisa resolver você economizará um tempo valioso no futuro com possíveis refatorações e mudanças no escopo por não ter entendido bem suas funcionalidades.
Outro ponto importante é envolver todas as pessoas que participam do projeto nesse processo de descoberta, quanto menos dúvidas e quanto mais claro é o projeto fica mais fácil estimar uma data para a entrega ou descobrir se o projeto será entregue na data já estipulada pelo cliente.
Depois de entender bem o projeto, divida em pequenas partes. Trabalhar com backlog e sprints pode te ajudar a acompanhar o progresso, fica mais fácil saber o quanto já foi feito e o quanto ainda falta entregar.
Fazendo isso você e sua equipe conseguem entregar valor para o cliente antes do prazo final. Assim que concluir uma parte mostre para o cliente, quando ele ver algo funcionando vai ficar mais feliz, a pressão das entregas vai diminuir e a equipe vai ficar mais motivada vendo o sucesso do projeto, com isso é natural que produzam mais e não deixem a qualidade do software cair.
Com essa divisão fica mais fácil identificar qual parte é mais importante. A equipe pode começar o desenvolvimento pelas partes que geram mais valor para o cliente e se chegar no prazo final sem todas as funcionalidades entregues o impacto para o negócio será menor.
Essa atitute também pode fazer com que o escopo diminua, o cliente pode identificar que alguma parte é irrelevante para a entrega final e assim fica mais fácil para negociar a remoção de partes do projeto.
Nós somos ruins em estimar quanto tempo em meses, dias ou horas algo vai levar até que fique pronto, mas então como podemos determinar um prazo de entrega?
No livro Scrum: A Arte de Fazer o Dobro do Trabalho em Metade do Tempo, O autor diz que somos melhores em comparar o tamanho de uma coisa com o tamanho de outra (dimensionamento relativo), como por exemplo, diferenciar o tamanho entre camisetas (P, M, G) ou cachorros (Poodle, Labrador, Dogue Alemão).
A medida mais utilizada em projetos de software são os números da sequência de Fibonacci para dar "pontos" as tarefas do projeto, sendo eles 1, 2, 3, 5, 8, 13 e por ai vai, sempre comparando quanto uma tarefa é "maior" ou "menor" que outra.
Em um projeto recente em que trabalhei pontuamos todas as tarefas referentes a determinadas funcionalidades e com base na velocidade da equipe (falo sobre isso mais pra frente) demos o prazo para a entrega. Sabe o que aconteceu? Conseguimos entregar as funcionalidades na data prevista e com qualidade :)
Pode parecer meio bobo, mas utilizar user stories (histórias de usuário) no lugar de simples tarefas na hora de montar o backlog do projeto faz uma grande diferença.
Na empresa que trabalho, escrevíamos tudo como tarefas simples, por exemplo "Criar model client", e então decidimos começar a escrever as tarefas como user stories. De cara percebemos que melhoramos a forma como pontuamos, o processo ficou mais rápido por que tinhamos menos cards para pontuar e a comunição da equipe melhorou.
Isso ocorre por que só de ler a descrição da story a equipe já entende a necessidade do cliente e começa a perceber o real valor entregue no final da sprint.
Faça um teste e comece a utilizar user stories, se puder escrever critérios de aceitação melhor ainda, mas só mudando o título das tarefas você já vai começar a sentir a diferença.
Quanto sua equipe consegue entregar no período de um sprint? Você consegue responder essa pergunta?
Pontuar user stories vai te ajudar a achar a resposta. É simples, some a quantia de pontos executados em todos os sprints e divida pela quantidade de sprints. Exemplo:
- Sprint 1: 30 pontos
- Sprint 2: 36 pontos
- Sprint 3: 34 pontos
- Sprint 4: 32 pontos
(30 + 36 + 34 + 32) / 4 = 33
Nesse cenário podemos afirmar que por sprint a equipe pode entregar 33 pontos.
Mas e no primeiro sprint? Como faço para saber quantos pontos minha equipe consegue entregar?
Defina uma quantidade de pontos para o primeiro sprint e vá ajustando nos próximos. Com três ou quatro sprints você já consegue dizer com mais certeza quantos pontos a equipe pode entregar.
Mais uma vez, por experiência própria, posso afirmar que você não vai atrasar e vai entregar todos os sprints do projeto.
Você ainda pode utilizar outras medidas, como lead time e throughput para saber o quanto a equipe pode produzir, mas a explicação dessas duas métricas fica pra outro post :)
Então chega a data de entrega e não foi possível concluir o projeto, todos ficam frustrados: o cliente por que não recebeu o produto e os desenvolvedores por não entregar na data.
Mesmo seguindo boas práticas e fazendo um bom planejamento, coisas que você não esperava podem acontecer, por exemplo, alguém da sua equipe pode ficar doente, uma tarefa pode ter sido subestimada, surgiu outra demanda mais urgente e parte da equipe teve que ser realocada.
"Nenhum plano de batalha sobrevive ao contato com o inimigo" - Helmuth von Moltke
Acompanhando o projeto de perto e medindo a velocidade da equipe você consegue prever o futuro e dizer se vai conseguir entregar no prazo ou não.
Se você detectar isso, apenas comunique todos os envolvidos sobre os problemas e o possível atraso na entrega, com isso vocês podem rever as prioridades, planejar novamente as entregas ou simplesmente jogar a data de entrega mais pra frente.
Ser ágil tem mais a ver com adaptação do que com antecipação.
E você? Tem dificuldade em dar estimativas? Tem outra dica para deixar mais fácil a estimativa de prazos? Escreve aí nos comentários ;)
Até o próximo post!
Referências:
- Inception; O quê? Quem? Onde? Quando? Como?{:target="_blank"}
- The Design Sprint{:target="_blank"}
- Scrum: a arte de fazer o dobro do trabalho na metade do tempo{:target="_blank"}
- Antecipação ou adaptação?{:target="_blank"}