Estimando recursos para um jogo de software
Ron Jeffries apresentou um software desafio de estimativa para determinar o esforço provável necessário para entregar um futuro conjunto de recursos de um jogo que ele e sua equipe estão escrevendo. Decidi aceitar este desafio e realizar uma estimativa de dimensionamento COSMIC e, talvez, ao fazê-lo, irei chamar a atenção para os méritos da estimativa CFP e como ela pode ajudar no design thinking.
Somos solicitados a estimar o esforço necessário para projetar algumas funcionalidades dentro de um jogo parcialmente construído. Aqui está o requisito de alto nível:
Fornece a capacidade de um membro da equipe de design de nível controlar a colocação de objetos de masmorra, incluindo monstros, ponto de partida do jogador, itens de decoração contendo saques e os saques que eles contêm, e itens de saque independentes.
Há mais contexto que pode ser lido aqui:
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
Este é um requisito de alto nível. Há muita coisa que não sabemos. Uma medição precisa do CFP do software final entregue não é possível, mas podemos medir os requisitos desde que sejam suficientemente claros para uma interpretação consistente.
As duas principais razões para procurar uma estimativa para ter uma indicação fiável da quantidade de esforço necessário (que normalmente nos indica o custo) e a provável duração decorrida. Munidos dessas duas informações, podemos planejar com eficácia.
Uma estimativa do tamanho funcional pode nos ajudar a responder essas duas questões, mas também a processo de estimativa é valioso. O processo de estimativa nos ajuda a esclarecer e melhorar a qualidade dos requisitos, o que por sua vez pode ajudar a reduzir o retrabalho.
Primeiro, devemos estabelecer o que estamos estimando (e o que não estamos estimando). Podemos considerar isso como o estabelecimento dos limites da estimativa. Estaremos estimando o tamanho (não o esforço) da funcionalidade a ser desenvolvida apenas para este conjunto de recursos. Estamos considerando apenas a funcionalidade descrita, não adivinharemos nenhuma outra funcionalidade.
Dada a alta granularidade dos requisitos fornecidos, só podemos dimensionar o que sabemos e depois considerar o que não sabemos (o ScopeMaster faz as duas coisas). Então agora vamos mergulhar nos detalhes.
O que o software precisa fazer
“Fornecer a capacidade de um membro da equipe de design de nível controlar a colocação de objetos de masmorra, incluindo monstros, ponto de partida do jogador, itens de decoração contendo saque e o saque que eles contêm, e itens de saque independentes.”
O objetivo geral é controlar o posicionamento inicial de objetos em um espaço restrito.
As considerações contidas na explicação incluem o seguinte:
- Limites 2D predefinidos de locais permitidos (pisos, não paredes)
- Precisamos reconhecer a adjacência da parede
- Não precisamos nos preocupar com corredores, apenas com quartos.
- Existem diferentes tipos de Objetos que possuem em sua maioria as mesmas características para nossos propósitos: Tesouro, Decoração e Monstros.
- Decoração que contém Tesouro
- Jogador (para posição inicial)
Por enquanto não nos preocuparemos com os limites de quantos objetos podem ser colocados em um nível, nem se muitos objetos podem ser colocados no mesmo local.
Então agora começamos a dividir isso em um conjunto de histórias de usuários (ou requisitos funcionais de usuário orientados ao usuário FUR). É claro que usamos o ScopeMaster para nos ajudar a acelerar isso. No total, passei pouco menos de 1 hora lendo e entendendo os requisitos, criando histórias de usuários e refinando-as. (Depois passei mais 1,5 horas escrevendo isso e postando esses resultados). O ScopeMaster dimensionou as histórias para nós, mas também ajudou a melhorar nosso pensamento sobre os requisitos e o design simultaneamente.
Aqui estão as etapas que executei:
Primeiro, descubra com quais objetos identificáveis pelo usuário precisamos trabalhar.
• Níveis (que possuem salas)
• Salas (que possuem dimensões)
• Objetos (que possuem um local inicial)
• Contenção (descrevendo quando na Decoração contém um tesouro).
Em seguida, descreva a funcionalidade da perspectiva do usuário e o resultado serão apenas essas três histórias de usuário.
-
Como level_designer posso selecionar o nível em que quero trabalhar e as salas nele contidas
-
Como level_designer posso selecionar uma sala [dentro de um nível] e criar um level_object [com room_location no qual colocar um objeto]
-
Como level_designer posso pesquisar level_object e então criar um level_object_containment
Estas não foram minhas versões iniciais do requisito. Cada um teve algumas revisões. O ScopeMaster forneceu feedback que me ajudou a melhorar a qualidade e também a determinar o tamanho de cada requisito.
Diagrama de modelo de caso de uso gerado automaticamente para um conjunto de requisitos
Para cada requisito obtemos uma interpretação funcional, que determina a estimativa do CFP e a discriminação da movimentação de dados:
Interpretação funcional de um requisito mostrando as movimentações de dados e o tamanho do CFP
Outra perspectiva potencialmente útil sobre o requisito na forma de um diagrama de sequência (também gerado automaticamente).
Diagrama de sequência gerado automaticamente para um requisito funcional individual
Dado que a intenção funcional é revelada, podemos começar a pensar em como testar o software entregue por estes requisitos. O ScopeMaster faz muito desse trabalho para nós:
Cenários de teste gerados automaticamente para um requisito funcional individual
Melhorando a qualidade do pensamento e dos requisitos
As ilustrações acima, geradas automaticamente diretamente do texto dos requisitos, nos ajudam a alcançar uma compreensão clara da intenção funcional do que foi escrito. Para profissionais de desenvolvimento de software altamente experientes, essas ilustrações podem revelar poucos insights adicionais sobre apenas três requisitos, mas ao trabalhar em um grande conjunto de requisitos, elas podem ser muito eficazes na exposição de possíveis problemas antes que o código seja escrito. O ScopeMaster pode analisar um conjunto de até 2.500 requisitos.
Estimativa de tamanho
O dimensionamento COSMIC é uma metodologia ágil para medição de tamanho de funcionalidade de software, pois permite dimensionar os requisitos que você conhece sem precisar conhecer outros requisitos. Posso ter interpretado mal o desafio e, idealmente, teria algumas perguntas de acompanhamento, mas dado o que sei ao ler o desafio, o tamanho (do que sabemos) é 17 PCP.
Estimativas de esforço e duração
O que realmente gostaríamos de saber é quanto esforço e quanto tempo levaria para entregar a funcionalidade. Estudos, benchmarks e experiências mostraram que as médias típicas para desenvolvimento e teste de unidade são de cerca de 4 a 8 horas por CFP. Consideravelmente pior do que isto é ocasionalmente observado (mais de 20 horas/CFP) em organizações ineficientes. No outro extremo do espectro, equipas altamente competentes, com elevados níveis de reutilização, podem reduzir este tempo para 2-3 horas/CFP, mas isto é raro. Para este exercício, assumiremos que desenvolvedores altamente qualificados e com boas ferramentas estão trabalhando nisso. A sua única restrição são os requisitos voláteis, pelo que 4-6 horas por CFP é um intervalo razoável. Normalmente nunca ofereço estimativas pontuais, apenas intervalos, com explicações. E assim temos uma estimativa de 68 a 102 horas de esforço. Um desenvolvedor raramente é produtivo por mais de 5 horas por dia, então seriam de 14 a 20 dias.
Mas espere! Pode haver mais (incógnitas cognoscíveis). O ScopeMaster realizou uma análise CRUD no conjunto de 3 requisitos e identificou que pode haver funcionalidades extras que perdemos:
Se se espera que o desenvolvedor também construa todas as funcionalidades CRUD ausentes, então o potencial é que esse trabalho aumente para 53 CFP (42 -63 dias).
Conclusão
O dimensionamento do COSMIC segue princípios de design de software, medindo movimentos de dados apenas dentro de um determinado contexto. É aplicável à grande maioria dos domínios de software, incluindo jogos. A metodologia de dimensionamento ajuda no design thinking e, como tal, geralmente acabamos com melhores requisitos e melhor ajuste do design. O dimensionamento pode ser feito manualmente e leva uma porcentagem muito pequena do tempo do desenvolvedor para fazer isso. É ainda mais rápido ao usar o ScopeMaster®. Neste caso o trabalho de leitura, compreensão, análise, esclarecimento e dimensionamento dos requisitos durou apenas 1 hora. Isso representa apenas 1,4% do esforço total (ou apenas 0,3% considerando requisitos faltantes dimensionados). Lembre-se que o que você precisa saber para dimensionar os requisitos no CFP é um subconjunto do que você precisa saber para construí-los – ou seja, não há desperdício.
Quando desafiado por um gestor/executivo é importante conhecer o limite da impossibilidade. O CFP nos ajuda a entender o tempo mínimo que provavelmente levará para entregar essa funcionalidade. Neste caso, menos de 68 horas seria bom, menos de 32 horas seria extraordinário.
Quanto mais sabemos sobre onde queremos chegar, menos becos sem saída teremos que percorrer ao longo do caminho. Em outras palavras, ter requisitos claros reduzirá o retrabalho. O dimensionamento COSMIC e o ScopeMaster aceleram o trabalho para obter clareza sobre requisitos, tamanho e design, assim, juntos, podem reduzir o retrabalho e trazer maior segurança ao esforço e duração da entrega do software.
Gostaria de agradecer a Ron Jeffries pelo desafio e espero que isso seja útil para você.
Termo aditivo
Depois de escrever isso, voltei e percebi que havia omitido a funcionalidade de “posicionamento inicial do player”. Isso seria pelo menos 3 CFP.
