-
Acredito que o erro esteja em: “serão consideradas funcionalidades novas relativas a uma sprint específica para que seja possível realizar a referida contagem.”
Para realizar a contagem, não há necessidade de considerar uma nova sprint.
-
Olá,
No meu entendimento o erro esta em dizer "funcionalidades novas", dados que o texto fala em alterações do escopo. Você pode já ter desenvolvido aquela funcionalidade ! Então, você teria uma nova sprint com o tipo de contagem de pontos de função por melhorias (que mede as modificações).
Tomei como base as seguintes informações que tenho anotada:
Os tipos de contagem:
1)- Projeto de desenvolvimento - novo software
2)-Projeto de melhoria - mede modificações
3)- Projeto de aplicação - (mede aplicações instaladas / prontas).
Para melhorias = EFP + ADD + CHGA + CFD + DEL
EFP = Enhacement Function Points (aprimoramentos), envolve apenas manutenções evolutivas e não prevê melhorias corretivas ou preventivas.
ADD = Addictional (melhorias adicionadas)
CHGA = Change (FP) After Enhacements (funções alteradas)
CFD = Converton Function Points (funções de conversão)
DEL = Delete (funções excluídas).
Se alguém tiver mais informações que possam invalidar esse entendimento, pf. me corrijam !
-
ERRADO
Complementando o Lucas P
É importante salientar que APF FAZ SOMENTE A MEDIDA DO TAMANHO DE UM SOFTWARE, ela não especifica nada. Assim as funcionalidades já devem estar definidas, porém não é necessário que eles estejam vinculadas a nenhuma Sprint.
-
A análise de ponto de função analisa as funcionalidades e não como foram implementadas ou desenvolvidas essas funcionalidades.
-
As mudanças em funcionalidades podem ser decorrentes de mudanças no domínio do negócio - como alteração de escopo, de regras de negócio - ou mudanças legais/regulamentares ou, ainda, refinamentos de requisitos. Considerando os aspectos do desenvolvimento ágil, as mudanças em funcionalidades que ocorrerem após o término da release em que essas funcionalidades ficaram prontas, devem ser tratadas de acordo com o item Projeto de Melhoria deste Roteiro. Além disso, é prática comum existirem mudanças em uma funcionalidade ainda durante a execução das sprints de uma release. Neste guia considera-se que, no desenvolvimento de software com métodos ágeis, o ciclo de trabalho evolutivo em funcionalidades desenvolvidas em uma release encerra-se ao final da release. Assim, este guia sugere que as mudanças em funcionalidades ocorridas dentro dessas características não sejam contadas e, consequentemente, não sejam remuneradas durante a release (ou seja, nos ciclos de pagamento do projeto), mas que já estejam absorvidas pela contratada como parte inerente do processo ágil de desenvolvimento adotado para o projeto.
https://www.governodigital.gov.br/transformacao/cidadania/arquivo-consultas-publicas/arquivo-de-consultas-publicas/156_final.pdf