O tamanho do software é o maior determinante de esforço ou custo em um projeto de software.
O dimensionamento consistente de software pode ajudar todos os aspectos do gerenciamento do portfólio de software
Estimativa de software e especificamente estimativa ágil de software é considerado difícil e certamente notoriamente não confiável. No entanto, ter estimativas fiáveis é essencial para decisões de investimento sólidas e um planeamento 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, os orçamentos e os cronogramas são frequentemente excedidos, o que leva a desperdícios e ineficiências consideráveis. 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 consome muito tempo. Isto não é assim.
Por que as estimativas dos desenvolvedores não são confiáveis?
Os promotores muitas vezes resistem a oferecer estimativas, por vezes porque temem que as suas estimativas possam ser tratadas como compromissos. Além disso, eles resistem a análises de dimensionamento muito detalhadas antecipadamente, caso os requisitos não sejam implementados. A estimativa em story points (usando o Planning Poker) é uma prática comum em equipes Agile. Mas, apesar da sua popularidade, é uma abordagem falha e muitas vezes pode ser ultrapassada por ordens de grandeza. Os pontos da história são um meio útil de comunicação dentro da equipe sobre como algo pode ser difícil de fazer. Mas isso é tudo! Eles são facilmente manipulados, jogáveis, inconsistentes e, para a maioria dos propósitos, sem sentido.
É natural subestimar
Os desenvolvedores quase sempre subestimam o tempo e o esforço realmente necessários para entregar o software. É da natureza humana fazer isso. Eles consideram apenas os fatores que conhecem e, ainda assim, com o software, muitas vezes há incógnitas que causam atrasos; teses raramente são permitidas na estimativa técnica. Além disso, as propostas iniciais dos promotores são geralmente baixas para “ganhar o trabalho”.
A indústria de software deve fazer melhor
A estimativa inadequada é uma das causas principais de falhas em grandes projetos. Cabe à indústria melhorar a estimativa de software (esforço, custo e duração). Com estimativas iniciais mais confiáveis do trabalho do software, decisões melhores podem ser tomadas mais cedo e atrasos desnecessários podem ser evitados.
Como estimar o trabalho do software de maneira confiável?
Até 60 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 O fator mais significativo é o tamanho, especificamente tamanho funcional. (coloque os pontos da sua história de lado por enquanto, pois eles não são uma medida de tamanho, mas uma suposição de pseudo-esforço).
Dimensionamento confiável de software é possível – e também não é tão difícil.
Estime primeiro o tamanho funcional do software
Uma vez que você conhece o funcional tamanho, você pode derivar rapidamente estimativas válidas para outras dimensões, como:
- pessoal necessário
- custos
- hora de desenvolver
- testes necessários para alcançar a qualidade adequada
- e muitos mais
O que é tamanho funcional?
O tamanho funcional surge da Medição do Tamanho Funcional (FSM). É uma técnica padronizada madura e comprovada para dimensionamento de software. É um prática formal de engenharia aprovada pelos grupos de padrões ISO. É agnóstico em relação à tecnologia e metodologia de desenvolvimento. O tamanho funcional é uma medida universal que se aplica a todos os tipos de software. É considerado desde o perspectiva dos usuários. É objetivo, válido e consistente. Duas pessoas medindo o tamanho funcional devem chegar sempre ao mesmo número. A unidade de medida é o ponto de função, especificamente o ponto de função COSMIC ou CFP. O CFP pode ser estimado ou contado (exatamente) apenas a partir de requisitos e especificações. O tamanho funcional é independente da linguagem de codificação usada para desenvolvê-lo. O FSM existe há muitos anos e provou ser a medida mais confiável do tamanho do software. O FSM permite estimar ou medir o tamanho antes, durante e depois da escrita do código.
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!
Posso automatizar a estimativa de software?
Sim. ScopeMaster é a primeira e única ferramenta para estimar de forma confiável o tamanho funcional direta e automaticamente a partir de requisitos escritos. Não acredite apenas na nossa palavra. Especialistas e acadêmicos de todo o mundo concordam que o ScopeMaster® é uma ferramenta inovadora de dimensionamento automatizado: Validação acadêmica do ScopeMaster como ferramenta de dimensionamento automatizado.
Traga certeza 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
A grande vantagem de saber o tamanho antes de codificar é que você pode alocar a quantidade correta de tempo e recursos para realizar o trabalho. Apenas sabendo o tamanho, geralmente você pode economizar 10% ou mais em um projeto de software maior, às vezes até mais.
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 automatizada de software com ScopeMaster
O ScopeMaster foi concebido como uma ferramenta para automatizar o trabalho administrativo de medição do tamanho funcional do software a partir dos requisitos. “A razão pela qual decidi escrever uma ferramenta para fazer isso é porque, como gerente de projetos de software, descobri que tamanho funcional é o fator mais significativo que preciso para gerenciar um projeto com sucesso.” Colin Hammond, fundador.
O ScopeMaster interpreta a intenção funcional da história do usuário ou requisito de software e, portanto, é capaz de automatizar o dimensionamento funcional, que pode então ser usado para mais estimativa de desenvolvimento de software.
O ScopeMaster não só é muito mais rápido do que medir manualmente (pelo menos 4 vezes mais rápido), como também custa substancialmente menos do que o dimensionamento manual, os contadores certificados são escassos e o ScopeMaster elimina grande parte do trabalho enfadonho 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 3 CFP por segundo. Você poderia dimensionar um conjunto de requisitos de 1.000 CFP (cerca de $1m de software terceirizado) em cerca de 2 ou 3 minutos. Você pode então revisar os resultados para a) corrigir quaisquer erros de requisitos eb) verificar o tamanho funcional de cada requisito. Uma vez verificada pelo analista, a estimativa torna-se uma contagem/medição exata, que pode até ser usada para terceirização de trabalho de desenvolvimento de software a preço fixo.
Dimensionamento Funcional COSMIC
Ao longo dos anos, diversas variações de métricas de tamanho funcional foram criadas. Apenas cinco alcançaram o reconhecimento ISO (COSMIC, IFPUG, Mark II, NESMA e FiSMA). IFPUG, Mark II, NESMA e FiSMA são todos semelhantes no sentido de que derivam do conjunto de regras original criado por Allan Albrecht na IBM na década de 1980. O Metodologia de tamanho funcional COSMIC evoluíram a partir de metodologias anteriores, especificamente concebidas para resolver as suas deficiências. As principais vantagens que tornam a metodologia COSMIC Sizing mais relevante 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 – altamente adequados para o desenvolvimento Agile.
- Foi automatizado e, portanto, requer um aprendizado insignificante.
Os pontos da história prevalecem em todos os projetos Agile e são uma medida proxy de esforço específica da equipe. Cada equipe tem um entendimento comum da magnitude de um ponto da história, normalmente da ordem de algumas horas de esforço, mas não há regras rígidas. Os pontos da 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 da história são um indicador interno útil do esforço previsto, se nenhum outro meio de estimativa estiver disponível. Os pontos de função, entretanto, são universais, padronizados e altamente aplicáveis ao desenvolvimento Ágil, tanto quanto a qualquer outra metodologia de desenvolvimento. Clique aqui para ler mais sobre os méritos de CFP vs Story Points
O tamanho é a base da estimativa de software
Depois de conhecer o tamanho funcional nos pontos de função COSMIC (CFP), você poderá estabelecer rapidamente outras métricas que estão diretamente relacionadas ao tamanho, como custo, esforço e cronograma. Uma vez estabelecido o tamanho do CFP, você poderá usar valores de conversão do setor que mapeiam pontos de função para esforço, custo e cronograma. 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 perder tempo discutindo pontos da história ou brincando com as cartas de Fibonacci. A estimativa ágil, em nossa experiência, é melhor alcançada por meio do dimensionamento funcional com COSMIC FP.
O que você pode estimar com base no tamanho?
- 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 contar (medir) pontos de função a uma taxa de cerca de 100-500 FP por dia (aproximadamente $100k – $500k de software). Isto depende 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 cerca de 4 vezes mais rápido.
Estimando enquanto você escreve histórias de usuários
Usando o ScopeMaster Story Analyzer para Jira, você pode estimar o tamanho funcional de suas histórias sem 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 anteriores e insira seus requisitos no ScopeMaster para obter o tamanho funcional. Dado que você já conhece o custo do projeto anterior, 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. E a melhor medida de tamanho é o Ponto de Função CÓSMICO.
Problemas com pontos da história
- Inconsistente
- Capaz de jogar
- Não linear
Os pontos da história são uma opinião baseada em equipe sobre a quantidade de esforço necessária para construir algum software da perspectiva de um desenvolvedor. Os pontos da história são essencialmente um proxy para estimativas de esforço, por exemplo, um ponto da história pode ser equivalente a 1 pessoa por dia ideal. Eles são altamente subjetivos e dependentes das opiniões da equipe. Eles variam de equipe para equipe e até mesmo ao longo do tempo dentro da mesma equipe. Sua inconsistência e habilidade de jogo os tornam impraticáveis como uma métrica de engenharia confiável.
Para aqueles que consideram a estimativa prejudicial, sem importância ou muito difícil, confira o excelente artigo de Steve Mconnell sobre o porquê estimativa é uma habilidade importante e valiosa que os gerentes de projeto precisam.
Conselhos na web:
Bom:
