O tamanho do software é o maior determinante de esforço e custo em um projeto de software. Quanto mais cedo você puder estimar (com precisão) o tamanho, mais produtivas suas equipes serão, levando a um projeto mais bem-sucedido no geral.
O dimensionamento consistente de software pode ajudar todos os aspectos do gerenciamento do portfólio de software
Estimativa de software—e especificamente Ágil estimativa de software— é considerada difícil e notoriamente pouco confiável, mas estimativas confiáveis são essenciais para decisões de investimento sólidas e planejamento eficaz.
Estimar o tamanho do software (e subsequentemente o custo e o cronograma) é importante para dar aos gerentes uma compreensão de quanto custará e quanto tempo levará. Gerentes e executivos enfrentam constantemente decisões difíceis sobre o trabalho de software. Em projetos maiores, orçamentos e cronogramas são frequentemente excedidos, o que leva a consideráveis desperdícios e ineficiências. Gerentes preciso saber o custo e a duração prováveis desenvolver software para que possam planejar adequadamente. Espera-se que tomem decisões fiáveis sobre prioridades e alocação de pessoal e, no entanto, muitas vezes fazem-no sem uma estimativa de software fiável do tempo e esforço necessários.
A maioria dos profissionais de software acredita que é impossível estimar o trabalho de desenvolvimento de software, ou que ele consome muito tempo. Este não é necessariamente o caso.
Por que as estimativas dos desenvolvedores não são confiáveis?
Às vezes, os desenvolvedores resistem a oferecer estimativas, geralmente porque temem que suas estimativas sejam tratadas como compromissos. Eles resistem a muitas análises detalhadas de dimensionamento antecipadamente, caso os requisitos não sejam implementados. A estimativa em pontos de história (usando planning poker) é uma prática comum em equipes Agile. Mas, apesar de sua popularidade, é uma abordagem falha e pode frequentemente estar errada por ordens de magnitude. Os pontos de história são um meio útil de comunicação dentro da equipe sobre o quão difícil algo pode ser de fazer. Mas isso é tudo! Eles são facilmente manipulados, jogáveis, inconsistentes e, para a maioria dos propósitos, sem sentido.
Infelizmente, os desenvolvedores quase sempre subestimam o tempo e o esforço realmente necessários para a entrega do software. É da natureza humana fazer isso. Eles consideram apenas fatores conhecidos, mas com o software, muitas vezes há incógnitas que causam atraso. Teses raramente são permitidas em estimativas técnicas por esse motivo.
Estimativa ruim é uma das causas raiz de falhas em grandes projetos. Com estimativas mais confiáveis e antecipadas do trabalho de software, melhores decisões podem ser tomadas e atrasos desnecessários podem ser evitados.
Então, como estimamos o trabalho do software de forma confiável?
Dezenas de fatores podem afetar o tempo e o esforço para desenvolver software (como complexidade, ambiente de trabalho, suporte executivo, experiência técnica, volatilidade de requisitos). O fator mais significativo na determinação do esforço ou custo é o tamanho, especificamente o tamanho funcional. Depois de saber o tamanho funcional, você pode rapidamente derivar estimativas válidas para outras dimensões, como:
Uma vez que você conhece o funcional tamanho, você pode derivar rapidamente estimativas válidas para outras dimensões, como:
- pessoal
- custos
- tempo de desenvolvimento
- testes necessários para alcançar a qualidade adequada
- …e muito, muito mais
O que é tamanho funcional?
O tamanho funcional surge de Medição de Tamanho Funcional (FSM). É uma técnica padronizada madura e comprovada para dimensionamento de software, uma prática formal de engenharia aprovada por grupos de padrões ISO e agnóstica de tecnologia, codificação e metodologia de desenvolvimento. Como medida universal que se aplica a todos os tipos de software, é considerada da perspectiva do usuário. Acima de tudo, o tamanho funcional é objetivo, válido e consistente — em outras palavras, duas pessoas medindo o tamanho funcional devem chegar ao mesmo número todas as vezes. A unidade de medida é o ponto de função; para ser mais específico, é o ponto de função COSMIC (ou CFP), que pode ser estimado ou contado única e precisamente a partir de requisitos e especificações. O FSM existe há muitos anos e provou ser a medida mais confiável de tamanho de software, permitindo que você estime ou meça o tamanho antes, durante e depois do processo de codificação.
Posso aprender a estimar o tamanho do software rapidamente?
Sim, você pode aprender a dimensionar o software (usando corretamente um padrão de dimensionamento funcional) em alguns dias ou menos. Você pode se tornar totalmente proficiente e certificado em apenas algumas semanas. Pode levar mais tempo para aprender como aproveitar o valor da medição, mas para isso existem consultores experientes. O ScopeMaster faz o trabalho pesado aqui, então usar o ScopeMaster irá acelerar seu aprendizado e estimativa de software!
O ScopeMaster é a primeira e única ferramenta para estimar de forma confiável o tamanho funcional direta e automaticamente a partir de um backlog de requisitos escritos. Mas não acredite apenas em nossa palavra; especialistas e acadêmicos ao redor do mundo concordam que o ScopeMaster é um ferramenta de dimensionamento automatizada inovadora.
Se você deseja começar a usar estimativas de software rápidas e eficazes, use o ScopeMaster para estimar os pontos de função COSMIC diretamente e instantaneamente a partir de seus requisitos ou histórias de usuários. Junto com o ScopeMaster, você pode trazer segurança ao seu trabalho de software com medição automatizada de tamanho funcional.
Para obter mais informações sobre medição de tamanho funcional COSMIC, visite https://www.cosmic-sizing.org.
Se você quiser começar estimativa de software eficaz e rápida, use o ScopeMaster para estimar os pontos de função COSMIC direta e instantaneamente a partir de seus requisitos ou histórias de usuários.
Estimativa de software automatizada com ScopeMaster
O ScopeMaster foi concebido como uma ferramenta para automatizar o trabalho administrativo de medir o tamanho funcional do software a partir de requisitos. Nas palavras do nosso fundador, Colin Hammond, “A razão pela qual me propus a escrever uma ferramenta para fazer isso é porque, como gerente de projeto de software, descobri que tamanho funcional é o fator mais significativo que preciso para gerenciar um projeto com sucesso.”
O ScopeMaster interpreta a intenção funcional da história do usuário ou do requisito de software e, portanto, é capaz de automatizar o dimensionamento funcional, que pode então ser usado para posterior estimativa de desenvolvimento de software.
O ScopeMaster não só é muito mais rápido do que medir manualmente, como também custa substancialmente menos do que o dimensionamento manual. Contadores certificados são escassos, e o ScopeMaster tira muito do trabalho penoso de fazer o trabalho. O ScopeMaster “lê” os requisitos, interpreta a intenção funcional e então os dimensiona de acordo. Ele pode estimar o tamanho em cerca de três CFP por segundo. Você poderia dimensionar um conjunto de requisitos de 1.000 CFP (cerca de $1m de software terceirizado) em cerca de dois ou três minutos. Você pode então revisar os resultados para corrigir quaisquer erros de requisitos e verificar o tamanho funcional de cada requisito. Uma vez verificada pelo analista, a estimativa se torna uma medida exata, que pode então ser usada para terceirização de preço fixo de trabalho de desenvolvimento de software.
Dimensionamento funcional COSMIC
Ao longo dos anos, várias variações de métrica de tamanho funcional foram criadas. Apenas cinco obtiveram reconhecimento ISO (COSMIC, IFPUG, Mark II, NESMA e FiSMA). IFPUG, Mark II, NESMA e FiSMA são todos semelhantes, pois são derivados do conjunto de regras original criado por Allan Albrecht na IBM na década de 1980. A metodologia de tamanho funcional COSMIC evoluiu de metodologias anteriores, projetadas especificamente para lidar com suas deficiências. As principais vantagens que tornam Metodologia de dimensionamento COSMIC mais relevantes para o software moderno são:
- É baseado em princípios de software, lidando elegantemente com camadas e arquiteturas de software interconectadas.
- Estimativas e medições podem ser feitas antes que todos os requisitos sejam conhecidos, o que é altamente adequado ao desenvolvimento ágil.
- Ele foi automatizado e, portanto, requer aprendizado insignificante.
Os pontos de história são predominantes em todos os projetos Agile; eles são uma medida proxy específica da equipe para esforço. Cada equipe tem um entendimento comum da magnitude de um ponto de história — normalmente na ordem de algumas horas de esforço — embora não haja regras rígidas. Os pontos de história não são uma moeda universal; eles não são um padrão e não podem ser usados de forma confiável para comparar equipes ou projetos. Os pontos de história são um indicador interno útil de esforço antecipado quando nenhum outro meio de estimativa está disponível. Os pontos de função, no entanto, são universais, padrão e altamente aplicáveis ao desenvolvimento Agile tanto quanto qualquer outra metodologia de desenvolvimento. Clique aqui para ler mais sobre os méritos de CFP vs Story Points.
O tamanho é a pedra angular da estimativa de software
Depois de saber o tamanho funcional em pontos de função COSMIC (CFP), você pode estabelecer rapidamente outras métricas que são diretamente relacionadas ao tamanho, como custo, esforço e cronograma. Depois que o tamanho em CFP for estabelecido, você pode usar valores de conversão do setor que mapeiam pontos de função para essas métricas. Em vez de usar conversões do setor, você pode usar seus próprios dados históricos do projeto para estabelecer seus próprios benchmarks de velocidade.
Estimativa ágil
Em vez de queimar tempo discutindo pontos de história ou brincando com cartas de Fibonacci, achamos que a estimativa Agile é idealmente alcançada por meio de dimensionamento funcional com COSMIC FP. Isso significa que você pode estimar melhor:
- Velocidade (média de CFPs entregues por semana)
- Agendar (número de semanas necessárias para entrega)
- Custo (custo total para projetar, desenvolver, testar e entregar)
- Esforço (esforço necessário para projetar, desenvolver, testar e entregar)
- Qualidade (potenciais de defeito para cada constituinte da entrega)
Com que rapidez você consegue obter estimativas?
Manualmente, um analista competente pode medir pontos de função a uma taxa de várias centenas de FPs por dia (o que se traduz em software que vale centenas de milhares de dólares), embora isso dependa da qualidade e clareza dos requisitos e especificações. A velocidade também depende da experiência e habilidade do analista. Com o ScopeMaster, você pode esperar atingir essas regras sobre quatro vezes mais rápido.
Estimando enquanto você escreve histórias de usuário no Jira
Usando o Analisador de histórias ScopeMaster para Jira, você pode estimar o tamanho funcional das suas histórias sem nem mesmo sair do Jira. O texto da sua história de usuário é analisado pelo poderoso mecanismo de linguagem do ScopeMaster para detectar a intenção funcional e o tamanho funcional.
Benchmarking com ScopeMaster
Pegue alguns projetos passados e insira seus requisitos no ScopeMaster para obter o tamanho funcional. Dado que você já sabe o custo daquele projeto passado, agora você pode estimar o esforço e o cronograma do novo projeto.
O tamanho não é o único fator que determina os custos e o cronograma do software, mas é o mais significativo. A melhor medida de tamanho é o ponto de função COSMIC.
Para aqueles que consideram a automação prejudicial, sem importância ou simplesmente muito difícil, confira o excelente artigo de Steve McConnelle por que estimativa é uma habilidade importante e valiosa que os gerentes de projeto precisam.
Problemas com pontos da história
- Inconsistente
- jogável
- Não linear
Os pontos de história são uma opinião baseada em equipe sobre a quantidade de esforço que pode ser necessário para construir software da perspectiva de um desenvolvedor. Os pontos de história são essencialmente um proxy para estimativas de esforço, por exemplo, um ponto de história pode ser o equivalente a um funcionário ideal trabalhando por um dia ideal. Eles são altamente subjetivos e dependem das opiniões da equipe. Além disso, eles variam de equipe para equipe, e até mesmo dentro da mesma equipe ao longo do tempo. Sua inconsistência e jogabilidade os tornam impraticáveis como uma métrica de engenharia confiável.
Leitura adicional
