Backlog-Größenbestimmung – automatisiert

Grundlagen der Backlog-Größenbestimmung

Untersuchen Sie jede User Story UND das Set

ScopeMaster liefert automatisch eine Größenschätzung basierend auf dem Text der User Story.

Warum die automatisierte Größenbestimmung mit ScopeMaster besser ist als die Team-Größenbestimmung

ScopeMaster liefert nicht nur eine angemessene Schätzung der Größe des Backlogs, sondern kann dies auch mühelos und sofort tun und die Größe fehlender Backlog-Elemente ermitteln!

Automatisierte Software-Backlog-Größenbestimmung durch ScopeMaster®

Dimensionierung und Schätzung des Software-Backlogs sind normalerweise verschwenderisch, zeitaufwändig und spielfreudig. Für fundierte Investitionsentscheidungen und eine effektive Planung sind jedoch verlässliche Schätzungen unerlässlich.

Die Schätzung der Größe des Software-Backlogs (und damit der Kosten und des Zeitplans) ist wichtig, um Managern eine Vorstellung davon zu geben, wie viel es kosten wird und wie lange es dauern wird. Manager und Führungskräfte stehen ständig vor schwierigen Entscheidungen rund um die Softwarearbeit. Bei größeren Projekten werden Budgets und Zeitpläne häufig überschritten, was zu erheblicher Verschwendung und Ineffizienz führt. Manager Sie müssen die voraussichtlichen Kosten und die Dauer kennen Software so zu entwickeln, dass sie entsprechend planen können. Von ihnen wird erwartet, dass sie verlässliche Entscheidungen über Prioritäten und Personalzuteilung treffen, tun dies jedoch oft ohne zuverlässige Software-Einschätzung des benötigten Zeit- und Arbeitsaufwands.

Die meisten Softwareexperten glauben, dass es unmöglich ist, die Arbeit an der Softwareentwicklung abzuschätzen, oder dass sie sehr zeitaufwändig ist. Das ist nicht so.

Warum sind Entwicklerschätzungen unzuverlässig?

Entwickler haben oft Schwierigkeiten mit Schätzungen. Schätzungen mithilfe von Techniken wie Story Points oder T-Shirt-Größen sind eigentlich nur ein Näherungswert für die Schätzung von Arbeitsstunden oder -tagen. Die Teams werden etwas anderes argumentieren, aber das ist größtenteils eine Verschleierung, die es zu fördern gilt. Wenn Entwickler Kostenvoranschläge für ein Werk abgeben, geben sie die Arbeit möglicherweise absichtlich zu niedrig an, vielleicht um die Arbeit zu „gewinnen“ und ihre Arbeit zu schützen. Möglicherweise überschätzen sie sich auch, um eine Arbeit zu vermeiden, die sie nicht tun möchten.

Der Missbrauch von Entwicklerschätzungen ist weit verbreitet

Sobald Entwickler einem Manager eine Schätzung einer User Story, eines Arbeitssprints oder sogar eines gesamten Backlogs vorgelegt haben, verwendet der Manager diese Schätzung möglicherweise als Ziel, als Maß für die Kontrolle oder sogar als Verpflichtung sind ungeeignete Anwendungen der einfachen Aufwandsschätzung.

Unterschätzen liegt in der Natur des Menschen

Entwickler unterschätzen fast immer den Zeit- und Arbeitsaufwand, der tatsächlich für die Bereitstellung von Software erforderlich ist. Es liegt in der Natur des Menschen, dies zu tun. Sie berücksichtigen nur die Faktoren, die ihnen bekannt sind, und doch gibt es bei Software oft Unbekannte, die zu Verzögerungen führen, Thesen werden in der technischen Schätzung selten berücksichtigt. Darüber hinaus sind die anfänglichen Vorschläge der Entwickler in der Regel niedrig, um „die Arbeit zu gewinnen“.

Wie kann man den Software-Produkt-Backlog zuverlässig schätzen?

Dutzende Faktoren können den Zeit- und Arbeitsaufwand für die Entwicklung von Software beeinflussen (z. B. Komplexität, Arbeitsumgebung, Unterstützung durch Führungskräfte, technische Erfahrung, Volatilität der Anforderungen). Der Der wichtigste Faktor bei der Bestimmung von Aufwand oder Kosten ist die Größe, konkret funktionale Größe.

Die Software-Funktionsgröße ist das Fundament der Backlog-Schätzung

Sobald Sie das wissen funktionell Größekönnen Sie schnell gültige Schätzungen für andere Dimensionen ableiten, wie zum Beispiel:

• Personalbesetzung
• Zeit, sich zu entwickeln
• Kosten
• Tests, die zur Erzielung einer geeigneten Qualität erforderlich sind
• und vieles mehr

Was ist funktionale Größe?

Die funktionale Größe ergibt sich aus der funktionalen Größenmessung (FSM). Es handelt sich um eine ausgereifte und bewährte standardisierte Technik zur Softwaredimensionierung. es ist ein formelle Ingenieurpraxis, die von den ISO-Normungsgruppen genehmigt wurde. Es ist unabhängig von der Technologie und der Entwicklungsmethodik. Die funktionale Größe ist ein universelles Maß, das für alle Arten von Software gilt. Es gilt als aus der Benutzerperspektive. Es ist objektiv und gültig und konsistent. Zwei Personen, die die Funktionsgröße messen, sollten jedes Mal die gleiche Zahl ermitteln. Die Maßeinheit ist der Funktionspunkt, genauer gesagt der KOSMISCHE Funktionspunkt oder CFP. Der CFP kann allein aus Anforderungen und Spezifikationen (exakt) geschätzt oder gezählt werden. Die funktionale Größe ist unabhängig von der Programmiersprache, mit der sie entwickelt wurde. FSM gibt es schon seit vielen Jahren und hat sich als das zuverlässigste Maß für die Softwaregröße erwiesen. Mit FSM können Sie die Größe vor, während und nach dem Schreiben des Codes schätzen oder messen.

Bahnbrechende Product-Backlog-Schätzung

ScopeMaster ist das erste und einzige Tool zur zuverlässigen Schätzung der Funktionsgröße direkt und automatisch aus einem Rückstand an schriftlichen Anforderungen. Aber vertrauen Sie uns nicht nur beim Wort. Experten und Wissenschaftler auf der ganzen Welt sind sich einig, dass ScopeMaster® ein bahnbrechendes automatisiertes Dimensionierungstool ist: Akademische Validierung von ScopeMaster als automatisiertes Dimensionierungstool.

Bringen Sie Sicherheit in Ihre Softwarearbeit mit der automatisierten Funktionsgrößenmessung.

Weitere Informationen zur funktionellen Größenmessung von COSMIC finden Sie unter https://www.cosmic-sizing.org

Das Tolle daran, die Größe vor dem Codieren zu kennen, besteht darin, dass Sie die richtige Menge an Zeit und Geld für die Erledigung der Arbeit einplanen können. Allein durch die Kenntnis der Größe können Sie bei einem größeren Softwareprojekt normalerweise 10% oder mehr einsparen, manchmal sogar mehr.

Automatisierte Softwareschätzung mit ScopeMaster

Drei führende Standards automatisiert:

ScopeMaster wurde als Tool zur Automatisierung der Büroarbeit zur Messung der funktionalen Größe von Software anhand der Anforderungen konzipiert. „Der Grund, warum ich mir vorgenommen habe, ein Tool dafür zu schreiben, liegt darin, dass ich als Software-Projektmanager das gefunden habe funktionale Größe ist der wichtigste Faktor, den ich brauche, um ein Projekt erfolgreich zu managen.“ Colin Hammond, Gründer.

ScopeMaster interpretiert die funktionale Absicht der User Story oder der Softwareanforderung und ist daher in der Lage, dies zu tun Automatisieren Sie die funktionale Größenbestimmung, die dann weiterverwendet werden kann Einschätzung der Softwareentwicklung.

ScopeMaster ist nicht nur viel schneller als die manuelle Messung (mindestens viermal schneller), es kostet auch wesentlich weniger als die manuelle Dimensionierung, zertifizierte Zähler sind rar und ScopeMaster nimmt Ihnen einen Großteil der mühsamen Arbeit ab. ScopeMaster „liest“ die Anforderungen, interpretiert die funktionale Absicht und dimensioniert sie dann entsprechend. Die Größe kann auf etwa 3 CFP pro Sekunde geschätzt werden. Sie könnten einen Anforderungssatz von 1.000 CFP (etwa $1m an ausgelagerter Software) in etwa 2 oder 3 Minuten dimensionieren. Anschließend können Sie die Ergebnisse überprüfen, um a) etwaige Anforderungsfehler zu korrigieren und b) die funktionale Größe jeder Anforderung zu überprüfen. Nach der Überprüfung durch den Analysten wird die Schätzung zu einer genauen Zählung/Messung, die sogar für die Auslagerung von Softwareentwicklungsarbeiten zum Festpreis verwendet werden kann.

KOSMISCHE funktionale Größenbestimmung

Im Laufe der Jahre wurden verschiedene Variationen der funktionalen Größenmetrik erstellt. Nur fünf haben die ISO-Anerkennung erhalten (COSMIC, IFPUG, Mark II, NESMA und FiSMA). IFPUG, Mark II, NESMA und FiSMA ähneln sich alle darin, dass sie von dem ursprünglichen Regelsatz abgeleitet sind, der von Allan Albrecht in den 1980er Jahren bei IBM erstellt wurde. Der KOSMISCHE funktionale Größenmethodik wurden aus früheren Methoden entwickelt und sind speziell darauf ausgelegt, deren Mängel zu beheben. Die wichtigsten Vorteile, die die COSMIC-Sizing-Methodik für moderne Software relevanter machen, sind:

1. Es basiert auf Softwareprinzipien und befasst sich elegant mit miteinander verbundenen Softwareschichten und Softwarearchitekturen.
2. Schätzungen und Messungen können durchgeführt werden, bevor alle Anforderungen bekannt sind – sehr gut geeignet für die agile Entwicklung.
3. Es wurde automatisiert und erfordert daher nur einen vernachlässigbaren Lernaufwand.

Story Points sind in allen agilen Projekten weit verbreitet, sie sind ein teamspezifisches Proxy-Maß für den Aufwand. Jedes Team hat ein gemeinsames Verständnis über die Größe eines Story Points. Der Aufwand liegt normalerweise in der Größenordnung von ein paar Stunden, es gibt jedoch keine strengen Regeln. Story Points sind keine universelle Währung. Sie stellen keinen Standard dar und können nicht zuverlässig zum Vergleich von Teams oder Projekten herangezogen werden. Story Points sind ein nützlicher interner Indikator für den erwarteten Aufwand, wenn keine andere Möglichkeit zur Schätzung verfügbar ist. Funktionspunkte sind jedoch universell, Standard und in hohem Maße auf die agile Entwicklung anwendbar, ebenso wie auf jede andere Entwicklungsmethodik. Klicken Sie hier, um mehr über die Vorzüge von CFP im Vergleich zu Story Points zu erfahren

Größe ist der Eckpfeiler der Softwareschätzung

Sobald Sie die funktionale Größe in COSMIC Function Points (CFP) kennen, können Sie schnell andere Metriken ermitteln, die in direktem Zusammenhang mit der Größe stehen, wie z. B. Kosten, Aufwand und Zeitplan. Sobald die Größe in CFP festgelegt ist, können Sie Branchenumrechnungswerte verwenden, die Funktionspunkte Aufwand, Kosten und Zeitplan zuordnen. Anstatt Branchenumrechnungen zu verwenden, können Sie Ihre eigenen historischen Projektdaten verwenden, um Ihre eigenen Geschwindigkeits-Benchmarks zu erstellen.

Agile Schätzung

Anstatt Zeit damit zu verschwenden, Story Points zu besprechen oder mit Fibonacci-Karten zu spielen. Agile Schätzungen lassen sich unserer Erfahrung nach am besten über die funktionale Dimensionierung mit COSMIC FP erreichen.

Was können Sie anhand der Größe abschätzen?

• Geschwindigkeit (durchschnittliche CFPs, die pro Woche geliefert werden)
• Zeitplan (Anzahl der Wochen, die für die Lieferung benötigt werden)
• Kosten (Gesamtkosten für Entwurf, Entwicklung, Test und Lieferung)
• Bemühung (Aufwand zum Entwerfen, Entwickeln, Testen und Bereitstellen erforderlich)
• Qualität (Fehlerpotenziale für jeden Bestandteil der Lieferung)

Wie schnell können Sie Schätzungen ableiten?

Manuell kann ein kompetenter Analyst Funktionspunkte mit einer Rate von etwa 100–500 FP pro Tag zählen (messen) (ca. $100k – $500k Software). Dies hängt von der Qualität und Klarheit der Anforderungen und Spezifikationen ab. Die Geschwindigkeit hängt auch von der Erfahrung und den Fähigkeiten des Analytikers ab. Mit ScopeMaster können Sie davon ausgehen, dass Sie diese Regeln etwa viermal schneller umsetzen.

Schätzen, während Sie User Stories schreiben

Mit dem ScopeMaster Story Analyzer für Jira können Sie die funktionale Größe Ihrer Storys abschätzen, ohne Jira zu verlassen. Der Text Ihrer User Story wird von der leistungsstarken Sprach-Engine von ScopeMaster analysiert, um die funktionale Absicht und funktionale Größe zu ermitteln.

Die Größe ist nicht der einzige Faktor, der die Softwarekosten und den Zeitplan bestimmt, aber sie ist der wichtigste.

Probleme mit Story Points und T-Shirts

• Inkonsistent
• Spielbar
• Nichtlinear

Story Points sind eine teambasierte Meinung über den Aufwand, der aus der Sicht eines Entwicklers erforderlich sein könnte, um eine Software zu erstellen. Story Points sind im Wesentlichen ein Indikator für Aufwandsschätzungen, z. B. könnte ein Story Point einem idealen Personentag entsprechen. Sie sind höchst subjektiv und abhängig von der Meinung des Teams. Sie variieren von Team zu Team und sogar im Laufe der Zeit innerhalb desselben Teams. Ihre Inkonsistenz und Spielfähigkeit machen sie als zuverlässige technische Messgröße unbrauchbar.

Für diejenigen, die Schätzungen für schädlich, unwichtig oder einfach zu schwierig halten, lesen Sie Steve Mconnells hervorragenden Artikel über die Gründe dafür Schätzung ist eine wichtige und wertvolle Fähigkeit, die Projektmanager benötigen.