Abordagem Tradicional
Uma abordagem convencional ou tipo cascata em que os projetos têm requisitos rígidos e não mudam ao longo do tempo. As demandas do sistema são divididas em partes de trabalho fáceis de estimar sob o conceito de estrutura analítica do projeto (WBS). É uma estrutura em árvore que visualiza cada estágio do desenvolvimento do aplicativo e se concentra nas entregas.
Após o término da WBS, a equipe estima o tempo de desenvolvimento de software para cada tarefa. Aqui estão os principais métodos que podem ser aplicados:
Estimativa por Analogia
A estimativa de desenvolvimento de software é baseada em dados históricos. Os especialistas comparam a atividade atual com outra semelhante que ocorreu no passado. É aplicado principalmente quando a equipe tem poucas informações sobre o projeto e usa sua experiência trabalhando com análogos. Se eles perceberem que a avaliação atual e o tempo real gasto anteriormente não concordam, a equipe saberá quais atividades provavelmente aumentarão o cronograma.
Delphi de banda larga
Este método é uma forma rápida de chegar a um consenso e tomar decisões. É usado quando há muitos especialistas envolvidos e todos eles têm visões conflitantes, então se torna um desafio fazer com que eles concordem em uma única decisão. Em vez disso, os membros da equipe avaliam individualmente as tarefas da WBS, comparam os resultados, apresentam problemas e negociam cada estimativa.
Essência da WBS — amostra
Estimativa ágil é o processo de avaliação do tempo necessário (horas ou dias) para cumprir uma atividade priorizada no backlog do produto . Horas ou dias exibem quanto tempo levará para concluir esta atividade. O projeto é dividido em vários ciclos chamados sprints, e cada processo passa por iterações até que as pequenas partes do aplicativo sejam executadas. Normalmente, cada sprint leva de 2 a 4 semanas para tornar o progresso mensurável e fornecer resultados previsíveis.
Vamos dar uma olhada rápida nos estágios principais da estimativa de desenvolvimento de software ágil:
Passo 1. Conduza entrevistas com as partes interessadas. Os analistas de negócios analisam a documentação inicial e recuperam as lacunas e consultas. Em seguida, eles agendam workshops regulares com os stakeholders para negociar essas lacunas e refinar as dúvidas no fluxo de trabalho do sistema. Depois disso, os BAs apresentam os requisitos de negócios e funcionais.
Etapa 2. Determinar o backlog de produto de alto nível. Os analistas de negócios e arquitetos técnicos moldam os resultados iniciais que as partes interessadas esperam com uma solução. Um backlog de produto de alto nível implica “o esqueleto” do software. A equipe de especialistas molda os resultados iniciais que as partes interessadas esperam com uma solução. Em seguida, eles verificam se o backlog atende ao escopo do projeto para o cliente.
Etapa 3. Entender o cliente e seus audiência.
Esta etapa envolve designers de UI/UX no quadro. Eles trabalham nos perfis dos usuários, no ecossistema no qual os usuários usarão o aplicativo e nos pontos de contato dos usuários no sistema. Mapas de ecossistemas, personas, jornadas de usuários e storyboards são as entregas do estágio.
Etapa 4. Priorize os requisitos. A equipe lida com o backlog de alto nível após a confirmação do stakeholder. O arquiteto de soluções decide quais funcionalidades adicionar primeiro, quais podem ser adicionadas posteriormente e quais remover.
Etapa 5. Crie um MVP. Os BAs adicionam demandas obrigatórias ao backlog e as identificam como requisitos para o desenvolvimento de MVP. A lista de pendências do MVP também contém funcionalidades como “deveria ter” para destacar o software.
Etapa 6. Estimativa o cronograma e o custo do projeto. A equipe avalia o backlog do MVP para determinar um prazo aproximado (assim como o preço) para a primeira versão. Ele é seguido pela construção e repetição até que a equipe apresente uma estimativa que atenda às necessidades do negócio. A abordagem ágil também permite flexibilidade para integrar alterações, independentemente do estágio da arquitetura do aplicativo.
Comparação de abordagens tradicionais e ágeis
Depois de entender como estimar tempo de desenvolvimento de software usando Agile, vamos ver quais são as principais técnicas de estimativa disponíveis.
Planejamento de Poker
Os resultados são baseados na opinião e no consenso de cada membro da equipe, contribuindo para uma estimativa de tempo de desenvolvimento mais precisa do que outras técnicas. No início do pôquer de planejamento, cada pessoa da equipe segura um conjunto de cartas de “pôquer” com valor, fala os requisitos para o item e oferece sua melhor estimativa anonimamente. A discussão dura até que o consenso seja alcançado.
Agrupamento de afinidade
A abordagem de agrupamento de afinidade é uma maneira simples de estimar o tempo de desenvolvimento de software. É uma ótima técnica quando: o projeto acabou de começar e tem um backlog que ainda não foi avaliado ou está em preparação para o planejamento de lançamento. A equipe organiza itens semelhantes em grupos de tarefas. Se as tarefas estiverem interligadas em escopo e esforço, elas serão compiladas até que surja um conjunto de grupos claro.
Método de três pontos
Esta técnica usa três estimativas em vez de uma para determinar a duração aproximada do projeto:
- Valor Otimista (O): Quanto tempo levará se todos vai para o plano?
Valor Pessimista (P): Quanto tempo levará se as coisas quebrarem ou houver obstáculos chegando?
- Valor Mais Provável (M): Qual é a estimativa mais pragmática para cumprir a tarefa?
-
Com tantos métodos disponíveis, a equipe pode fornecer uma estimativa detalhada dos esforços necessários para criar um produto digital. No entanto, há outra questão: como esse esforço pode ser calculado? Aqui estão as unidades de medida
mais populares
para estimar as horas de desenvolvimento de software.
Story points
É uma métrica usada por equipes ágeis para calcular a dificuldade de realizar um determinado usuário História. Uma estimativa do esforço envolvido pode ser influenciada pela quantidade de trabalho, riscos e incertezas e pela complexidade do produto. Os pontos de história confiam um valor numérico que aponta para sua complexidade. Em seguida, esses dados são comparados com uma tarefa semelhante de um projeto anterior que foi estimado da mesma forma.
Pontos de função
Outro método para estimativa de tempo de engenharia de software são os pontos de função. É uma medida que delineia o tamanho funcional dos produtos de software. Os pontos de função sistematizam métricas que explicam uma unidade de trabalho do produto adequada para quantificar aplicativos com base nas solicitações e recebimentos do usuário. Assim, ele mede a funcionalidade do sistema do ponto de vista do usuário, como o que o usuário recebe do software e o que ele solicita dele.
Tamanhos de camisetas
Em vez de atribuir um valor numérico às tarefas, os especialistas dão um tamanho relacionado aos tamanhos padrão de camisetas , como XS, S, M, L e XL. Assim, por exemplo, a equipe pode dizer: “podemos entregar uma tarefa extragrande, três tarefas grandes e sete pequenas tarefas em um sprint”. Este método é usado para estimativas aproximadas e em estágio inicial com uma grande lista de pendências.
