Fundamentos do dimensionamento do backlog
Examine cada história de usuário E o conjunto
O ScopeMaster fornece automaticamente uma estimativa de tamanho com base no texto da história do usuário.
Por que o dimensionamento automatizado com ScopeMaster é melhor que o dimensionamento de equipe
O ScopeMaster não apenas fornece uma estimativa de tamanho razoável para o backlog, mas também pode fazê-lo sem esforço, instantaneamente e pode dimensionar os itens do backlog que estão faltando!
Dimensionamento de backlog de software automatizado pelo ScopeMaster®
Dimensionamento e estimativa do backlog de software normalmente são um desperdício de tempo e jogos. No entanto, estimativas fiáveis são essenciais para decisões de investimento sólidas e um planeamento eficaz.
Estimar o tamanho do backlog de 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 desenvolvedores muitas vezes têm dificuldade com estimativas. A estimativa usando técnicas como pontos de história ou tamanho de camisetas é, na verdade, apenas um substituto para adivinhar horas ou dias de trabalho. As equipes argumentarão o contrário, mas isso é principalmente uma ofuscação para promover. Quando os desenvolvedores fornecem estimativas para uma parte de um trabalho, eles podem subestimar deliberadamente o trabalho, talvez para “ganhá-lo” e protegê-lo. Eles também podem superestimar para evitar ter que fazer algum trabalho que não querem.
O uso indevido das estimativas do desenvolvedor é predominante
Depois que os desenvolvedores fornecerem ao gerente uma estimativa de uma história de usuário, um sprint cheio de trabalho ou até mesmo um backlog inteiro, o gerente poderá então usar essa estimativa como uma meta, uma medida de controle ou até mesmo um compromisso, todos os quais são usos inadequados da estimativa básica de esforço.
Subestimar é a natureza humana
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”.
Como estimar o backlog do produto de software de maneira 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 O fator mais significativo na determinação do esforço ou custo é o tamanho, especificamente tamanho funcional.
O tamanho funcional do software é a base da estimativa do backlog
Uma vez que você conhece o funcional tamanho, você pode derivar rapidamente estimativas válidas para outras dimensões, como:
- pessoal
- hora de desenvolver
- custos
- testes necessários para alcançar a qualidade adequada
- e muito 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.
Estimativa inovadora do backlog do produto
ScopeMaster é a primeira e única ferramenta para estimar de forma confiável o tamanho funcional direta e automaticamente a partir de uma lista de pendências 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.
Estimativa automatizada de software com ScopeMaster
Três padrões líderes automatizados:
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.
O tamanho não é o único fator que determina os custos e o cronograma do software, mas é o mais significativo.
Problemas com story points e camisetas
- 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.
