Schätzen von Funktionen für ein Softwarespiel
Ron Jeffries stellte eine Software vor Schätzungsherausforderung um den wahrscheinlichen Aufwand zu bestimmen, der erforderlich ist, um einen bevorstehenden Funktionsumfang eines Spiels bereitzustellen, das er und sein Team schreiben. Ich habe beschlossen, mich dieser Herausforderung zu stellen und eine COSMIC-Größenschätzung durchzuführen. Vielleicht werde ich dadurch einige Aufmerksamkeit auf die Vorzüge der CFP-Schätzung lenken und darauf, wie sie beim Design-Thinking helfen kann.
Wir werden gebeten, den Aufwand abzuschätzen, der erforderlich ist, um einige Funktionen innerhalb eines teilweise erstellten Spiels zu entwerfen. Hier ist die Anforderung auf hohem Niveau:
Bieten Sie einem Level-Design-Teammitglied die Möglichkeit, die Platzierung von Dungeon-Objekten zu steuern, einschließlich Monstern, Startpunkten des Spielers, Beute enthaltenden Dekorationsgegenständen und der darin enthaltenen Beute sowie freistehenden Beutegegenständen.
Es gibt mehr Kontext, der hier gelesen werden kann:
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
Dies ist eine Anforderung auf hohem Niveau. Es gibt ziemlich viel, was wir nicht wissen. Eine genaue CFP-Messung der endgültig gelieferten Software ist nicht möglich, aber wir können die Anforderungen messen, sofern sie klar genug für eine konsistente Interpretation sind.
Die beiden Hauptgründe für die Suche nach einem Kostenvoranschlag sind zuverlässige Angaben zum erforderlichen Aufwand (der uns in der Regel die Kosten angibt) und zur voraussichtlich verstrichenen Dauer. Mit diesen beiden Informationen können wir effektiv planen.
Eine funktionale Größenschätzung kann uns bei der Beantwortung dieser beiden Fragen helfen, aber auch die Der Schätzprozess ist wertvoll. Der Schätzungsprozess hilft uns, die Qualität der Anforderungen zu klären und zu verbessern, was wiederum dazu beitragen kann, Nacharbeiten zu reduzieren.
Zuerst müssen wir feststellen, was wir schätzen (und was nicht). Wir können dies als Festlegung der Grenzen der Schätzung betrachten. Wir werden nur die Größe (nicht den Aufwand) der zu entwickelnden Funktionalität für diesen Funktionsumfang abschätzen. Wir berücksichtigen nur die beschriebene Funktionalität, andere Funktionalitäten werden wir nicht vermuten.
Angesichts der hohen Granularität der bereitgestellten Anforderungen können wir nur das einschätzen, was wir wissen, und dann das berücksichtigen, was wir nicht wissen (ScopeMaster erledigt beides). Lassen Sie uns nun in die Details eintauchen.
Was die Software tun muss
„Geben Sie einem Level-Design-Teammitglied die Möglichkeit, die Platzierung von Dungeon-Objekten zu steuern, einschließlich Monstern, Spielerstartpunkten, Beute enthaltenden Dekorationsgegenständen und der darin enthaltenen Beute sowie freistehenden Beutegegenständen.“
Das übergeordnete Ziel besteht darin, die anfängliche Platzierung von Objekten auf engstem Raum zu kontrollieren.
Zu den Überlegungen, die in der Erklärung enthalten sind, gehören die folgenden:
- Vordefinierte 2D-Grenzen zulässiger Standorte (Böden, keine Wände)
- Wir müssen die Wandangrenzung erkennen
- Wir müssen uns nicht um Flure, sondern nur um Räume kümmern.
- Es gibt verschiedene Arten von Objekten, die für unsere Zwecke meist die gleichen Eigenschaften haben: Schätze, Dekorationen und Monster.
- Dekor, das Schätze enthält
- Spieler (für Startposition)
Im Moment kümmern wir uns nicht um die Grenzen, wie viele Objekte auf einer Ebene platziert werden können, noch um die Frage, ob viele Objekte an derselben Stelle platziert werden können.
Deshalb beginnen wir nun damit, dies in eine Reihe von User Stories (oder benutzerorientierten funktionalen Benutzeranforderungen FUR) zu zerlegen. Natürlich haben wir ScopeMaster verwendet, um dies zu beschleunigen. Insgesamt habe ich knapp eine Stunde damit verbracht, die Anforderungen zu lesen und zu verstehen, die User Stories zu erstellen und sie zu verfeinern. (Ich habe dann weitere 1,5 Stunden damit verbracht, dies aufzuschreiben und diese Ergebnisse zu veröffentlichen). ScopeMaster hat die Storys für uns dimensioniert, uns aber gleichzeitig dabei geholfen, unsere Anforderungen und unser Design zu verbessern.
Hier sind die Schritte, die ich unternommen habe:
Überlegen Sie zunächst, mit welchen vom Benutzer identifizierbaren Objekten wir arbeiten müssen
• Ebenen (die Räume haben)
• Räume (die Abmessungen haben)
• Objekte (die einen Startort haben)
• Eindämmung (beschreibt, wann ein Dekor einen Schatz enthält).
Beschreiben Sie dann die Funktionalität aus der Sicht eines Benutzers und das Ergebnis sind genau diese drei User Stories.
-
Als Leveldesigner kann ich die Ebene, auf der ich arbeiten möchte, und die Räume darin auswählen
-
Als Leveldesigner kann ich einen Raum [innerhalb eines Levels] auswählen und ein Levelobjekt [mit Raumposition, an der ein Objekt platziert werden soll] erstellen.
-
Als Leveldesigner kann ich nach Level_object suchen und dann ein Level_object_containment erstellen
Dies waren nicht meine ersten Versionen des Erforderlichen. Jeder hatte ein paar Überarbeitungen. ScopeMaster lieferte Feedback, das mir half, die Qualität zu verbessern und den Umfang jeder Anforderung zu bestimmen.
Automatisch generiertes Anwendungsfallmodelldiagramm für eine Reihe von Anforderungen
Für jede Anforderung erhalten wir eine funktionale Interpretation, die die CFP-Schätzung und die Aufschlüsselung der Datenbewegung bestimmt:
Funktionale Interpretation einer Anforderung, die die Datenbewegungen und die CFP-Größe zeigt
Eine weitere potenziell nützliche Perspektive auf die Anforderung in Form eines Sequenzdiagramms (ebenfalls automatisch generiert).
Automatisch generiertes Sequenzdiagramm für eine einzelne Funktionsanforderung
Nachdem die funktionale Absicht bekannt ist, können wir darüber nachdenken, wie wir die durch diese Anforderungen bereitgestellte Software testen können. ScopeMaster erledigt einen Großteil dieser Arbeit für uns:
Automatisch generierte Testszenarien für eine einzelne Funktionsanforderung
Verbesserung der Denk- und Anforderungsqualität
Die obigen Abbildungen, die automatisch direkt aus dem Anforderungstext generiert werden, helfen uns, ein klares Verständnis der funktionalen Absicht des Geschriebenen zu erlangen. Für sehr erfahrene Softwareentwicklungsexperten bieten diese Abbildungen vielleicht kaum zusätzliche Einblicke in nur drei Anforderungen, aber bei der Arbeit an einer großen Menge von Anforderungen können sie sehr effektiv sein, um potenzielle Probleme aufzudecken, bevor der Code geschrieben wird. ScopeMaster kann einen Satz von bis zu 2500 Anforderungen analysieren.
Größenschätzung
COSMIC Sizing ist eine agile-freundliche Methode zur Messung der Softwarefunktionalitätsgröße, da Sie damit die Anforderungen, die Sie kennen, dimensionieren können, ohne andere Anforderungen kennen zu müssen. Ich habe die Herausforderung möglicherweise falsch verstanden und hätte im Idealfall ein paar weitere Fragen, aber angesichts dessen, was ich aus der Lektüre der Herausforderung weiß, ist die Größe (von dem, was wir wissen). 17 GFP.
Aufwands- und Dauerschätzungen
Was wir wirklich gerne wissen würden, ist, wie viel Aufwand und wie viel Zeit es kosten würde, die Funktionalität bereitzustellen. Studien, Benchmarks und Erfahrungen haben gezeigt, dass typische Durchschnittswerte für Entwicklungs- und Unit-Tests bei etwa 4–8 Stunden pro CFP liegen. In ineffizienten Organisationen wird gelegentlich deutlich Schlimmeres beobachtet (20+ Stunden/CFP). Am anderen Ende des Spektrums können hochkompetente Teams mit hohem Wiederverwendungsgrad diese Zeit auf 2-3 Stunden/CFP reduzieren, aber das ist selten. Aus diesem Grund gehen wir bei dieser Übung davon aus, dass hochqualifizierte Entwickler mit guten Werkzeugen daran arbeiten. Ihre einzige Einschränkung sind schwankende Anforderungen, daher sind 4–6 Stunden pro CFP ein angemessener Bereich. Normalerweise biete ich nie Punktschätzungen an, sondern nur Spannen mit Erläuterungen. Wir gehen also von einer geschätzten Aufwandspanne von 68 bis 102 Stunden aus. Ein Entwickler ist selten länger als 5 Stunden pro Tag produktiv, das wären also 14-20 Tage.
Aber warte! Möglicherweise gibt es noch mehr (erkennbare Unbekannte). ScopeMaster hat eine CRUD-Analyse der drei Anforderungen durchgeführt und festgestellt, dass es möglicherweise zusätzliche Funktionen gibt, die wir übersehen haben:
Wenn vom Entwickler erwartet wird, dass er auch alle fehlenden CRUD-Funktionen erstellt, besteht die Möglichkeit, dass diese Arbeit auf 53 CFP (42–63 Tage) ansteigt.
Abschluss
Die COSMIC-Größenbestimmung folgt den Prinzipien des Softwaredesigns und misst Datenbewegungen nur innerhalb des gegebenen Kontexts. Es gilt für die überwiegende Mehrheit der Softwaredomänen, einschließlich Spiele. Die Dimensionierungsmethode hilft beim Design-Denken, und so erhalten wir in der Regel bessere Anforderungen und eine bessere Design-Passform. Die Größenanpassung kann manuell erfolgen und nimmt dafür nur einen sehr geringen Prozentsatz der Entwicklerzeit in Anspruch. Noch schneller geht es mit ScopeMaster®. In diesem Fall dauerte das Lesen, Verstehen, Analysieren, Klären und Dimensionieren der Anforderungen nur eine Stunde. Dies entspricht nur 1,41 TP3T des Gesamtaufwands (oder nur 0,31 TP3T unter Berücksichtigung der fehlenden Anforderungen in der Größe). Denken Sie daran, dass das, was Sie wissen müssen, um die Anforderungen in CFP zu dimensionieren, eine Teilmenge dessen ist, was Sie wissen müssen, um sie zu erstellen – es gibt also keine Verschwendung.
Wenn Sie von einem Manager/einer Führungskraft herausgefordert werden, ist es wichtig, die Grenze des Unmöglichen zu kennen. CFP hilft uns zu verstehen, wie viel Zeit die Bereitstellung dieser Funktionalität voraussichtlich mindestens in Anspruch nehmen wird. In diesem Fall wären weniger als 68 Stunden gut, weniger als 32 Stunden wären ganz außergewöhnlich.
Je mehr wir darüber wissen, wo wir landen wollen, desto weniger Sackgassen müssen wir auf dem Weg nehmen. Mit anderen Worten: Klare Anforderungen reduzieren die Nacharbeit. COSMIC Sizing und ScopeMaster beschleunigen die Arbeit, um Klarheit über Anforderungen, Größe und Design zu erhalten. Gemeinsam können sie so die Nacharbeit reduzieren und mehr Sicherheit in Bezug auf Aufwand und Dauer der Softwarebereitstellung schaffen.
Ich möchte Ron Jeffries für die Herausforderung danken und hoffe, dass Sie dies hilfreich finden.
Nachtrag
Nachdem ich das geschrieben habe, bin ich zurückgegangen und habe festgestellt, dass ich die Funktionalität „Erstplatzierung des Players“ weggelassen hatte. Das wären mindestens 3 CFP.
