Estimation des fonctionnalités d'un jeu logiciel
Ron Jeffries a posé un logiciel défi d'estimation pour déterminer l'effort probable requis pour fournir un prochain ensemble de fonctionnalités d'un jeu que lui et son équipe sont en train d'écrire. J'ai décidé de relever ce défi et de réaliser une estimation de dimensionnement COSMIC, et peut-être que ce faisant, je ferai tourner certaines têtes vers les mérites de l'estimation CFP et comment elle peut aider à la réflexion conceptuelle.
Il nous est demandé d'estimer l'effort requis pour concevoir certaines fonctionnalités au sein d'un jeu partiellement construit, voici l'exigence de haut niveau :
Offrir la possibilité à un membre de l'équipe de conception de niveaux de contrôler le placement des objets du donjon, y compris les monstres, le point de départ du joueur, les objets de décoration contenant du butin et le butin qu'ils contiennent, ainsi que les objets de butin autonomes.
Il y a plus de contexte qui peut être lu ici :
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
Il s'agit d'une exigence de haut niveau. Il y a beaucoup de choses que nous ne savons pas. Une mesure CFP précise du logiciel final livré n'est pas possible, mais nous pouvons mesurer les exigences à condition qu'elles soient suffisamment claires pour une interprétation cohérente.
Les deux principales raisons de demander une estimation afin d'avoir une indication fiable de la quantité d'effort nécessaire (qui nous indique généralement le coût) et de la durée probable écoulée. Armés de ces deux informations, nous pouvons planifier efficacement.
Une estimation de la taille fonctionnelle peut nous aider à répondre à ces deux questions, mais aussi à la le processus d’estimation est précieux. Le processus d'estimation nous aide à clarifier et à améliorer la qualité des exigences, ce qui peut contribuer à réduire les retouches.
Premièrement, nous devons établir ce que nous estimons (et ce que nous n’estimons pas). Nous pouvons considérer cela comme établissant les limites de l'estimation. Nous évaluerons la taille (et non l’effort) de la fonctionnalité à développer pour cet ensemble de fonctionnalités uniquement. Nous considérons uniquement la fonctionnalité telle que décrite, nous ne devinerons aucune autre fonctionnalité.
Compte tenu de la grande granularité des exigences fournies, nous ne pouvons dimensionner que ce que nous connaissons, puis autoriser ce que nous ne savons pas (ScopeMaster fait les deux). Alors maintenant, plongeons dans les détails.
Ce que le logiciel doit faire
"Fournir la possibilité à un membre de l'équipe de conception de niveaux de contrôler le placement des objets du donjon, y compris les monstres, le point de départ du joueur, les objets de décoration contenant du butin et le butin qu'ils contiennent, ainsi que les objets de butin autonomes."
L'objectif global est de contrôler le placement initial des objets dans un espace contraint.
Les considérations contenues dans l’explication sont les suivantes :
- Limites 2D prédéfinies des emplacements autorisés (sols et non murs)
- Nous devons reconnaître la contiguïté des murs
- Nous n'avons pas à nous soucier des halls, seulement des chambres.
- Il existe différents types d'objets qui ont pour la plupart les mêmes caractéristiques pour nos besoins : Trésor, Décor et Monstres.
- Décor qui contient un trésor
- Joueur (pour la position de départ)
Pour l'instant, nous ne nous soucierons pas des limites du nombre d'objets pouvant être placés sur un niveau, ni de savoir si de nombreux objets peuvent être placés au même endroit.
Nous commençons donc maintenant à décomposer cela en un ensemble de user stories (ou d'exigences fonctionnelles orientées utilisateur FUR). Bien sûr, nous avons utilisé ScopeMaster pour nous aider à accélérer cela. Au total, j'ai passé un peu moins d'une heure à lire et comprendre les exigences, à créer les user stories et à les affiner. (J'ai ensuite passé 1,5 heure supplémentaire à rédiger ceci et à publier ces résultats). ScopeMaster a dimensionné les histoires pour nous, mais a également contribué à améliorer simultanément notre réflexion sur les exigences et la conception.
Voici les étapes que j'ai suivies :
Tout d'abord, déterminez avec quels objets identifiables l'utilisateur nous devons travailler.
• Niveaux (qui ont des pièces)
• Pièces (qui ont des dimensions)
• Objets (qui ont un emplacement de départ)
• Confinement (décrit quand le Décor contient un trésor).
Décrivez ensuite la fonctionnalité du point de vue d'un utilisateur et le résultat n'est que ces trois user stories.
-
En tant que level_designer, je peux sélectionner le niveau sur lequel je souhaite travailler et les pièces qui s'y trouvent.
-
En tant que level_designer, je peux sélectionner une pièce [dans un niveau] et créer un level_object [avec room_location où placer un objet]
-
En tant que level_designer, je peux rechercher level_object puis créer un level_object_containment
Ce n'étaient pas mes versions initiales de l'exigence. Chacun a eu quelques révisions. ScopeMaster a fourni des commentaires qui m'ont aidé à améliorer la qualité et à déterminer la taille de chaque exigence.
Diagramme de modèle de cas d'utilisation généré automatiquement pour un ensemble d'exigences
Pour chaque exigence, nous obtenons une interprétation fonctionnelle, qui détermine l'estimation du CFP et la répartition des mouvements de données :
Interprétation fonctionnelle d'une exigence montrant les mouvements de données et la taille du CFP
Une autre perspective potentiellement utile sur l'exigence sous la forme d'un diagramme de séquence (également généré automatiquement).
Diagramme de séquence généré automatiquement pour une exigence fonctionnelle individuelle
Étant donné que l'intention fonctionnelle est révélée, nous pouvons commencer à réfléchir à la manière de tester le logiciel fourni par ces exigences. ScopeMaster fait une grande partie de ce travail pour nous :
Scénarios de test générés automatiquement pour une exigence fonctionnelle individuelle
Améliorer la qualité de la réflexion et des exigences
Les illustrations ci-dessus, générées automatiquement à partir du texte des exigences, nous aident à comprendre clairement l'intention fonctionnelle de ce qui a été écrit. Pour les professionnels du développement de logiciels très expérimentés, ces illustrations peuvent révéler peu d'informations supplémentaires sur seulement trois exigences, mais lorsque vous travaillez sur un large ensemble d'exigences, elles peuvent être très efficaces pour exposer les problèmes potentiels avant que le code ne soit écrit. ScopeMaster peut analyser un ensemble allant jusqu'à 2 500 exigences.
Estimation de la taille
Le dimensionnement COSMIC est une méthodologie agile pour mesurer la taille des fonctionnalités logicielles, car elle vous permet de dimensionner les exigences que vous connaissez sans avoir besoin de connaître d'autres exigences. J'ai peut-être mal lu le défi et j'aurais idéalement quelques questions de suivi, mais étant donné ce que je sais en lisant le défi, la taille (de ce que nous savons) est 17 CFP.
Estimations d’effort et de durée
Ce que nous aimerions vraiment savoir, c'est combien d'efforts et combien de temps il faudrait pour fournir la fonctionnalité. Des études, des benchmarks et des expériences ont montré que la moyenne typique pour les tests de développement et unitaires est d'environ 4 à 8 heures par CFP. Des situations bien pires que cela sont parfois observées (plus de 20 heures/CFP) dans des organisations inefficaces. À l’autre extrémité du spectre, des équipes hautement compétentes, avec des niveaux élevés de réutilisation, peuvent réduire ce délai à 2-3 heures/CFP, mais cela est rare. Pour les besoins de cet exercice, nous supposerons que des développeurs hautement qualifiés et dotés de bons outils travaillent sur ce sujet. Leur seule contrainte réside dans les exigences volatiles, donc 4 à 6 heures par CFP est une fourchette raisonnable. En général, je ne propose jamais d'estimations ponctuelles, seulement des fourchettes, avec des explications. Nous avons donc une fourchette estimée de 68 à 102 heures d’effort. Un développeur est rarement productif plus de 5 heures par jour, cela représenterait donc 14 à 20 jours.
Mais attendez! Il pourrait y en avoir plus (inconnues connaissables). ScopeMaster a effectué une analyse CRUD sur l'ensemble des 3 exigences et a identifié qu'il pourrait y avoir des fonctionnalités supplémentaires que nous avons manquées :
Si le développeur doit également créer toutes les fonctionnalités CRUD manquantes, il est alors possible que ce travail atteigne 53 CFP (42 à 63 jours).
Conclusion
Le dimensionnement COSMIC suit les principes de conception logicielle, mesurant les mouvements de données uniquement dans le contexte donné. Il est applicable à la grande majorité des domaines logiciels, y compris les jeux. La méthodologie de dimensionnement facilite la réflexion sur la conception et, en tant que telle, nous obtenons généralement de meilleures exigences et une meilleure adéquation de la conception. Le dimensionnement peut être effectué manuellement et cela prend un très petit pourcentage du temps du développeur pour le faire. C'est encore plus rapide lorsque vous utilisez ScopeMaster®. Dans ce cas, le travail de lecture, de compréhension, d’analyse, de clarification et de dimensionnement des besoins n’a pris qu’une heure. Cela ne représente que 1,4% de l'effort total (ou seulement 0,3% pour tenir compte des exigences manquantes de taille). N'oubliez pas que ce que vous devez savoir pour dimensionner les exigences de la PCP est un sous-ensemble de ce que vous devez savoir pour les élaborer – c'est-à-dire qu'il n'y a pas de gaspillage.
Lorsqu'il est mis au défi par un manager/dirigeant, il est important de connaître la limite de l'impossibilité. CFP nous aide à comprendre le temps minimum qu'il faudra probablement pour fournir cette fonctionnalité. Dans ce cas, moins de 68 heures serait bien, moins de 32 heures serait tout à fait extraordinaire.
Plus nous en savons sur l’endroit où nous voulons aboutir, moins nous serons confrontés à des impasses en cours de route. En d’autres termes, avoir des exigences claires réduira les retouches. COSMIC sizing et ScopeMaster accélèrent le travail visant à clarifier les exigences, la taille et la conception. Ensemble, ils peuvent ainsi réduire les retouches et apporter une plus grande certitude quant aux efforts et à la durée de livraison des logiciels.
J'aimerais remercier Ron Jeffries pour le défi et j'espère que vous trouverez cela utile.
Addenda
Après avoir écrit ceci, j'y suis retourné et j'ai remarqué que j'avais omis la fonctionnalité de « placement initial du lecteur ». Cela ferait au moins 3 CFP.
