Agile Schätztechniken: Eine echte Schätzung in einem agilen Projekt

agile estimation techniques

Wahre Schätzungen in einem agilen Projekt: Ein vollständiger Einblick mit Beispielen zur agilen Schätzung

Es ist sehr wichtig, eine agile Schätzung auf verschiedenen Ebenen durchzuführen. Dies geschieht für eine ordnungsgemäße Planung, Verwaltung und Schätzung des Gesamtaufwands, den wir für die Implementierung, Prüfung und Lieferung des gewünschten Produkts an die Kunden innerhalb der angegebenen Fristen in Bezug auf die Zeit verwenden werden.

Aufgrund fehlender Schätzungen in Agile Project gibt es möglicherweise keine ordnungsgemäße Planung und Verwaltung, die dazu führen kann, dass das unerwünschte Produkt geliefert wird und der Kunde dadurch unzufrieden bleibt.

Story-Point-Schätzungen werden in agilen Projekten mit verschiedenen Techniken wie Planning Poker, Bucket System, Affinity Mapping usw. durchgeführt. Zu diesem Zweck werden verschiedene Schätzvorlagen auf verschiedenen Ebenen verwendet, z. B. Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , User Story Template etc.

Was du lernen wirst:

• Einführung
• Schätzungen der Story Points in Agile
• Empfohlenes Werkzeug
• Verschiedene agile Schätztechniken
  • # 1) Poker planen
  • # 2) T-Shirt Größen
  • # 3) Punktabstimmung
  • # 4) Das Eimersystem
  • # 5) Groß / Unsicher / Klein
  • # 6) Affinitätszuordnung
  • # 7) Bestellmethode
• Budget in Agile berechnen
• Schätzvorlagen im agilen Entwicklungsprojekt
  • 1) Agile Projektplanvorlage:
  • 2) Agile Release Plan Vorlage:
  • 3) Agile Product Backlog-Vorlage:
  • 4) Agile Sprint Backlog-Vorlage:
  • 5) Agile Testplanvorlage:
  • 6) Agile User Story-Vorlage:
  • 7) Agile Road Map Vorlage:
• Schätzungsstufen in einem agilen Projekt
  • # 1) Schätzung des Vorschlags oder der Projektebene
  • # 2) Release Level Estimation
  • # 3) Sprint Level Estimation
• Fazit
• Literatur-Empfehlungen

Einführung

Nachstehend sind die drei Hauptebenen der agilen Schätzung aufgeführt.

# 1) Projekt- oder Vorschlagsebene ist diejenige, die in den Anfangsphasen der Projektentwicklung die Schnellfunktionspunktanalyse verwendet.

# 2) Release Level Dazu gehört das Zuweisen der Story-Punkte zu den User-Storys, mit deren Hilfe die Reihenfolge der User-Storys basierend auf der Priorität definiert und entschieden werden kann, welche Storys in der aktuellen Version und welche später aufgenommen werden können.

# 3) Sprint Level ist diejenige, bei der die User Stories in die Aufgaben unterteilt werden und den Aufgaben geschätzte Stunden entsprechend ihrer Komplexität zugewiesen werden. Hier definieren wir neben dem Status der Aufgaben auch die für die Aufgabe verantwortliche Person.

Diese Informationen können später zur Berechnung des Budgets für das Agile-Projekt verwendet werden. Die Berechnung des Budgets ist entscheidend, um sicherzustellen, dass das Projekt aufgrund von Aufgaben vor und nach der Iteration oder aus anderen Gründen nicht über das Budget hinausgeht.

Schätzungen der Story Points in Agile

Story Points Estimations ist eine vergleichende Analyse, um die Product Backlog-Elemente mit relativer Größe grob zu schätzen. Zu den Teammitgliedern für die Schätzung von User Stories gehören: Product Owner, Scrum Master, Entwickler, Tester und Stakeholder.

Im Folgenden sind einige Schritte aufgeführt, um die endgültige Entscheidung über die relative Größe zu treffen:

# 1) Analysieren Sie alle User Stories und identifizieren Sie die Basis- oder Referenzstory. Dies ist wichtig für die relative Dimensionierung. Diese Geschichte kann aus dem aktuellen oder dem zuvor durchgeführten Produktbestand ausgewählt werden. Diese Geschichte sollte nach Zustimmung aller Mitglieder als Referenzgeschichte ausgewählt werden.

#zwei) Wählen Sie eine andere Story aus dem aktuellen Product Backlog aus, und die Teammitglieder können Fragen oder Zweifel mit dem Product Owner besprechen und gleichzeitig die Anforderungen der Story verstehen. Der Product Owner ist dafür verantwortlich, alle seine Fragen und Zweifel zu klären.

#3) Erstellen Sie eine Liste der Dinge, die bei der Implementierung der User Story zu beachten sind. Dies kann durch Schreiben von Notizen im Abschnitt 'Notizen' des Tools oder durch Hinzufügen von Aufzählungspunkten auf der Story-Karte erfolgen. Dies wird meistens vom Scrum Master durchgeführt.

# 4) Nachfolgend sind einige häufig gestellte Fragen unter den Teilnehmern aufgeführt:

• Design: Was ist das vorherige und obligatorische Wissen, das wir haben sollten, bevor wir anfangen, daran zu arbeiten?
• Codierung: Wie viel Codierung ist für die Implementierung dieser User Story erforderlich? Haben wir schon einmal eine ähnliche User Story gesehen?
• Unit Testing: Sind für die Durchführung von Unit-Tests für diese User Story Scheinobjekte erforderlich?
• Integrationstests: Beeinflusst diese Geschichte auch die anderen Funktionen desselben Moduls und anderer Module?
• Abnahmetests: Was sind die Punkte, die zu beachten sind, um das gewünschte Produkt wie vom Kunden gewünscht zu liefern?
• Sachverstand: Hat einer der Teilnehmer schon einmal eine ähnliche Geschichte gemacht und ist ein Experte darin?

# 5) Nehmen Sie die relative Größe für die ausgewählte Story vor. Wenn es den gleichen Arbeits- und Arbeitsaufwand erfordert, weisen Sie ihm die gleiche Nummer zu. von Punkten, wie der Referenzgeschichte zugeordnet. Wenn es mehr Aufwand erfordert, weisen Sie ihm einen höheren Wert zu. Wenn es weniger Aufwand erfordert, weisen Sie ihm einen niedrigeren Wert zu.

# 6) Erreichen Sie mit allen Teilnehmern einen Konsens, um die relative Größe für die ausgewählte User Story gemäß der Definition von 'erledigt' festzulegen.

wie man das Standard-Gateway verfügbar macht

# 7) Stellen Sie nach der relativen Dimensionierung aller Product Backlog-Elemente sicher, dass alle User Stories mit derselben Nr. Die Anzahl der ihnen zugewiesenen Punkte erfordert den gleichen Aufwand und die gleiche Größe, um konsistent zu sein.

Empfohlenes Werkzeug

# 1) Agiles Poker

Agiles Poker ist eine bekannte App für Jira zur schnellen und bequemen Planung und Schätzung von Remote- und Co-Location-Teams.

Der Einstieg in Agile Poker ist einfach und unkompliziert, da er von drei branchenüblichen Schätzmethoden inspiriert wurde: Planning Poker®, Wideband Delphi und Magic Estimation (auch bekannt als Silent Grouping, Affinity Estimation, Swimlanes Sizing oder Relative Estimations).

Verschiedene agile Schätztechniken

Es gibt viele Techniken, um Schätzungen in einem agilen Projekt durchzuführen. Zu den Hauptprinzipien für die Durchführung von Schätzungen gehören die relative Schätzung, Diskussionen, um mehr Informationen über Elemente zu erhalten, deren Schätzungen durchgeführt werden müssen, und die Sicherstellung des Engagements des gesamten Teams für die ihnen zugewiesenen Aufgaben.

Es gibt hauptsächlich 7 agile Projektschätzungstechniken:

# 1) Poker planen

• Bei dieser Schätztechnik sitzen alle Personen, die die Schätzungen vornehmen sollen, für die Planning Poker-Sitzung in einem runden Kreis.
• Jeder Schätzer verfügt über eine Reihe von Planning Poker-Karten mit Werten: 0,1,2,3,5,8,13,20,40 und 100. Diese Werte stellen Story Points oder Kennzahlen dar, in denen das Team schätzt.
• Zu Beginn der Sitzung liest der Product Owner oder Kunde die User Story vor und beschreibt alle Funktionen und Anforderungen.
• Nach dem Vorlesen der Geschichte finden die Gespräche zwischen den Schätzern und mit dem Product Owner / Kunden statt. Die Schätzer können Fragen stellen oder ihre Zweifel mit dem Produktbesitzer klären.
• Nach den Diskussionen werden alle Schätzer gebeten, eine Karte auszuwählen, um eine User Story zu schätzen. Wenn alle Schätzer den gleichen Wert angeben, wird dies zur endgültigen Schätzung.
• Wenn die Werte unterschiedlich sind, erklären die Schätzer mit den höchsten und niedrigsten Werten ihre Meinung und warum sie diesen Wert gewählt haben, bis ein Konsens erreicht ist.
• Eine gute Technik, wenn klein nein. von Gegenständen ist in einem kleinen Team zu schätzen.

=> Weitere ausführliche Lektüre am Planung der Poker-Schätzungstechnik .

# 2) T-Shirt Größen

• Genau wie bei T-Shirts sehen wir Größen: XS (extra klein), S (klein), M (mittel), L (groß), XL (extra groß). Ein ähnlicher Ansatz wird hier verfolgt. Artikel werden in T-Shirt-Größen geschätzt.
• Dies ist eine perfekte Technik, um eine grobe Schätzung des großen Auftragsbestands zu erhalten.
• Nützlich, wenn eine schnelle und grobe Schätzung erforderlich ist. Später können diese Größen gemäß den Anforderungen in Nein-Größen umgewandelt werden.
• Eine relative Größe (meistens mittel) wird nach gegenseitiger Diskussion und Zustimmung der Teammitglieder oder Schätzer festgelegt. Anschließend werden die Elemente den Elementen entsprechend der relativen Größe zugewiesen, die der mittleren Größe zugewiesen ist.
• Nachteil: Was jemandem L erscheint, scheint für jemanden XL zu sein.
• Alle Schätzer weisen den Elementen ihre eigene Größe zu. Nach Diskussionen und der Behebung der Nichtübereinstimmungen wird ein Konsens erzielt, um die endgültige Schätzung zu erhalten.

# 3) Punktabstimmung

• Dies ist im Grunde eine Ranking-Methode, um die Reihenfolge des Product Backlogs von Storys mit der höchsten Priorität zu Storys mit der niedrigsten Priorität zu bestimmen. Dies geschieht, um die wichtigsten Geschichten auszuwählen, die vorangebracht werden sollen.
• Stellen Sie zunächst alle User Stories zusammen mit ihrer Beschreibung mit gelben Stickies an die Wand oder das Brett oder auf eine Weise, die sie für den Erhalt der Stimmen auszeichnet.
• Alle Stakeholder erhalten 4 bis 5 Punkte (meist in Form von Aufklebern, Stiften oder Markern können auch Punkte gemacht werden).
• Alle Stakeholder werden gebeten, ihre Stimmen zu den von ihnen bevorzugten User Stories abzugeben.
• Der Product Owner bestellt die Product Backlog-Elemente von den am meisten bevorzugten (eine mit den meisten Punkten) bis zu den am wenigsten bevorzugten (eine mit den wenigsten Punkten).
• Dies kann der Fall sein, wenn nur wenige Stakeholder mit der beschlossenen Reihenfolge unzufrieden sind. In diesem Fall werden die User Stories nach den Diskussionen in drei Gruppen unterteilt: hohe Priorität, niedrige Priorität und mittlere Priorität. User Stories mit hoher Priorität werden an die Wand gehängt, um die Stimmen zu erhalten. Dies geschieht, bis die endgültige Bestellung mit Zustimmung aller Beteiligten erreicht ist.

# 4) Das Eimersystem

• Es ist eine gute Technik, wenn eine große Nr. Anzahl der Artikel sind im Großen und Ganzen zu schätzen. von Teilnehmern. Es ist schneller und vernünftiger als Planning Poker.
• Es werden verschiedene Buckets mit folgenden Werten erstellt: 0,1,2,3,4,5,8,13,20,30,50,100, 200. Diese können bei Bedarf erweitert werden. Diese Eimer sind nichts anderes als Karten, die Werte darstellen, die nacheinander auf einer Tabelle angeordnet sind.
• Die Geschichten müssen dort platziert werden, wo der Schätzer sie für geeignet hält. Alle zu schätzenden Gegenstände sind auf die Karten geschrieben.
• Wählen Sie einen Gegenstand nach dem Zufallsprinzip aus und legen Sie ihn in Eimer 8. Dies dient nur als Referenz. Wählen Sie eine andere Geschichte nach dem Zufallsprinzip aus, besprechen Sie alle Funktionen und Anforderungen mit der Gruppe und legen Sie sie nach Konsens in den entsprechenden Eimer. Ebenso wird der dritte Gegenstand kommissioniert und in einen geeigneten Eimer gestellt.
• Die Bucket-Sequenz kann auch geändert werden, falls die Gruppe der Ansicht ist, dass das erste ausgewählte Element zum Bucket 1 anstelle von Bucket 8 gehören sollte.
• Der Divide and Conquer-Ansatz wird verfolgt. Alle übrigen Gegenstände werden unter allen Teilnehmern aufgeteilt. Alle Teilnehmer können den Artikel ohne Zustimmung anderer Teilnehmer platzieren.
• Die Gegenstände sollten richtig platziert werden. Es kann kein Gegenstand zwischen die Eimer gelegt werden.
• Wenn ein Teilnehmer das Product Backlog-Element nicht versteht oder wenn die anderen Teilnehmer ihre User Storys platziert haben, können die User Stories auf die anderen Teilnehmer übertragen werden.
• Zuletzt wird die Sanity-Prüfung von allen Teilnehmern durchgeführt. Wenn ein Teilnehmer einen falschen Eimer findet, der einem Artikel zugewiesen ist, kann er ihn anderen Teilnehmern zur Kenntnis bringen und mit ihnen diskutieren. Dies geschieht so lange, bis ein Konsens für den gesamten Produktbestand erzielt ist.
• Der Moderator sollte überprüfen, ob niemand die Gegenstände bewegt, es sei denn, es wird eine Überprüfung der geistigen Gesundheit durchgeführt.
• Dies geschieht auch, um die Prioritätsreihenfolge der Product Backlog-Elemente zu erreichen.

# 5) Groß / Unsicher / Klein

• Dies ist eine grobe Version und die Vereinfachung des Eimersystems, bei dem es nur drei Größen gibt: Groß, Klein und Unsicher.
• Die Teilnehmer oder Schätzer werden gebeten, die Elemente in eine der Kategorien einzuteilen. Zunächst werden die einfachen User Stories ausgewählt und in die großen und kleinen Kategorien eingeteilt. Dann werden die komplexen Gegenstände aufgenommen.
• Dies ist eine gute Technik, wenn das Product Backlog vergleichbare Elemente enthält.

# 6) Affinitätszuordnung

• Eine gute Technik, wenn das Team klein ist und nein. der Rückstandselemente ist geringer.
• Der erste Schritt ist Silent Relative Sizing: An einer Wand befindet sich eine Karte mit der Aufschrift 'Kleiner' ganz links und die Karte mit der Aufschrift 'Größer' ganz rechts. Der Product Owner stellt allen Teilnehmern eine Teilmenge der Artikel zur Verfügung. Alle Teilnehmer werden gebeten, die Größe jedes Elements im Verhältnis zu den Größen auf den Karten an der Wand zu bestimmen, wobei der Aufwand für deren Implementierung zu berücksichtigen ist. Es ist die alleinige Entscheidung des Teilnehmers ohne Diskussion mit den anderen Teammitgliedern. Der Product Owner oder Stakeholder ist anwesend, um die Zweifel des Teilnehmers zu klären. Product Backlog-Elemente, die zu mehrdeutig sind, um von den Teammitgliedern zur Schätzung verstanden zu werden, werden separat platziert. Es dauert 5-20 Minuten.
• Bearbeitung der Wand: Die Teammitglieder können die Position der Gegenstände an der Wand ändern. Sie können Design- und Implementierungsanforderungen mit den anderen Teammitgliedern besprechen. Diese Aktivität kann geschlossen werden, wenn sich an der Wand nur wenig ändert. Es dauert ungefähr 20-60 Minuten .
• Elemente an den richtigen Stellen platzieren: Nach den Diskussionen platziert das Team die Product Backlog-Elemente an ihren relativen und geeigneten Positionen. Wir können hier T-Shirt-Größen, Fibonacci-Serien usw. verwenden, um die Größe der Artikel relativ abzuschätzen.
• Product Owner Challenge: Der Product Owner kann einige Abweichungen in den vom Team vorgenommenen Schätzungen feststellen und muss weitere Funktionen oder Anforderungen für einen Artikel mit dem Team besprechen. Nach den Diskussionen werden endgültige Schätzungen vorgenommen.
• In Project Backlog Management Tool exportieren: Um sicherzustellen, dass die Informationen zu den endgültigen Schätzungen nicht verloren gehen, exportieren Sie sie in ein Tool zur Verwaltung des Produktrückstands.

# 7) Bestellmethode

• Eine gute Technik, wenn groß nein. von Gegenständen und kleine Nr. von Menschen sind da.
• Es gibt genaue relative Größen für die Produktrückstände an.
• Es wird eine Skala von niedrig bis hoch erstellt. Alle Gegenstände werden zufällig darauf platziert. Jeder Teilnehmer wird gebeten, einen beliebigen Gegenstand auf der Waage gleichzeitig zu verschieben. Die Bewegung kann eine nach oben oder eine nach unten sein oder die Drehung an ein anderes Mitglied weitergeben.
• Dies wird so lange fortgesetzt, bis alle Teilnehmer zufrieden sind und keinen Gegenstand auf der Waage verschieben möchten.
• Dies gibt auch die Prioritätsreihenfolge der Product Backlog-Elemente an.

Budget in Agile berechnen

Die Berechnung von Budgets spielt in agilen Projekten eine wichtige Rolle. Dies geschieht, um sicherzustellen, wie hoch das tatsächlich bereitgestellte Budget ist, welches Budget mehr erforderlich ist und wie das Budget für verschiedene Product Backlog-Elemente aufgeteilt wird.

Es verwendet die aus den vorherigen Projekten gesammelten Daten und verwendet die mathematische Formel, um das geschätzte Budget für das aktuelle Projekt zu erhalten.

Nachfolgend finden Sie die Abfolge der Schritte zur Berechnung des Budgets in einem agilen Projekt:

# 1) Listen Sie alle Anforderungen des Projekts auf und führen Sie die aus Schätzungen für sie mit Planning Poker, Bucket System, Fibonacci-Serie usw. Alle Teammitglieder sollten sich nach klarer Analyse und Verständnis der User Stories auf die Schätzungen für die aufgeführten Anforderungen einigen. Schätzungen werden basierend auf den Funktionen durchgeführt, die in einer User Story implementiert werden sollen.

#zwei) Bestimmen Sie die Dauer der Iterationen, die als Sprints bezeichnet werden, und der ihm zugewiesenen Product Backlog-Elemente. Es dauert normalerweise 2 bis 3 Wochen. Die User Stories werden in einer Reihenfolge ausgewählt, beginnend mit der User Story mit maximaler Priorität, mit niedrigerer Priorität und mit User Story mit niedrigster Priorität am Ende. Dies hilft bei der Entscheidung, welche User Stories im ersten Sprint aufgenommen werden müssen und welche Storys später aufgenommen werden können.

#3) Bereiten Sie ein abgebranntes Diagramm vor, um ein klares Bild davon zu erhalten, wie viel Arbeit noch zu erledigen ist und wie viel Zeit für die Implementierung verbleibt. Es gibt im Grunde die Fortschrittsrate eines agilen Teams. Es gibt ein klares Bild darüber, wie sich das Team verhält und wie es sich voraussichtlich verhalten wird.

Der Teamfortschritt wird anhand der erledigten Aufgaben, des verbleibenden Aufwands, des idealen Burndowns und der verbleibenden Aufgaben gemessen (siehe unten):

# 4) Fügen Sie zusätzliche Kosten wie den Kauf von Geräten, Tools, Infrastrukturunterstützung, das Erhalten von Lizenzen für die zu verwendenden Softwaretools, Projektmanagement-Tools, die Installation von Antivirenprogrammen und Updates hinzu.

# 5) Fügen Sie Budgets vor und nach der Iteration hinzu. Alle agilen Mitglieder sollen funktionsübergreifend sein, aber es gibt Grenzen. Alles, was ein Teammitglied außerhalb seines Fachwissens tut, wird als Vor- oder Nachiterationsarbeit betrachtet. Diese Arbeiten vor und nach der Iteration erfordern ein zusätzliches Budget für die Implementierung.

# 6) Die versteckten Risiken im Auge behalten. Zu den Risiken des Agile-Projekts gehören: Risiko, dass das Projekt über das Budget hinausgeht, Abwesenheit von Teammitgliedern, Mitglieder haben keine klaren oder vollständigen Kenntnisse, Mitglieder verfügen nicht über die erforderlichen Fähigkeiten, Fristen wurden überschritten usw.

Schätzvorlagen im agilen Entwicklungsprojekt

Es gibt viele Schätzvorlagen, die im Agile-Entwicklungsprojekt auf verschiedenen Ebenen erstellt werden. Der einzige Zweck besteht darin, die Schätzungen, die für die Umsetzung einer Anforderung oder eines Elements erforderlich sind, klar anzugeben und deren Fortschritt zu verfolgen.

Die Hauptvorlagen sind wie folgt:

1) Agile Projektplanvorlage:

Es gibt einen Überblick darüber, wie viel Zeit erforderlich ist, um die Funktionen der Anforderungen bereitzustellen, und welchen Status sie haben. Es wird auch die Person erwähnt, die für eine bestimmte Aufgabe verantwortlich ist.

(Hinweis: Klicken Sie auf ein Bild, um es zu vergrößern.)

2) Agile Release Plan Vorlage:

Es enthält Release-Details zu den Aufgaben, die den Anforderungen entsprechen, sowie deren Status und Sprint, in dem sie ausgeführt werden müssen.

3) Agile Product Backlog-Vorlage:

Es beschreibt das gesamte für das Projekt definierte Produkt-Backlog. Es enthält Details zu den Aufgaben der Sprints sowie Status, Priorität, Story-Punkte und ob sie einem Sprint zugewiesen sind oder ob es zusätzliche Aufgaben wie Fehler usw. gibt.

4) Agile Sprint Backlog-Vorlage:

Es enthält eine Beschreibung der User Stories, die im Backlog eines bestimmten Sprints erwähnt werden. Es gibt die gesamten Story-Punkte an, die einer User Story zugewiesen wurden, und wie diese in verschiedene Aufgaben unterteilt sind. Es gibt auch den Status der entsprechenden Aufgaben und die tägliche Arbeit für die entsprechenden Aufgaben an.

5) Agile Testplanvorlage:

Es unterteilt das gesamte Testszenario in Unterszenarien. Es enthält Details zu den Unterszenarien wie Implementierungsdatum, erwartetes Ergebnis, tatsächliches Ergebnis, Status usw.

Außerdem werden der Projektname, der kompatible Browser, die Version der zu testenden Anwendung, die Testfall-ID für ein ausgewähltes Szenario, Geschrieben von, Getestet von, Beschreibung usw. erwähnt.

6) Agile User Story-Vorlage:

Es enthält die Details, die für die Analyse der User Story spezifisch sind, z. B. Welche Rollen sind für das Testen einer bestimmten Funktionalität erforderlich, welche Voraussetzungen sind erforderlich (Umgebung eingerichtet und Links aktiviert) und was ist das erwartete Ergebnis?

7) Agile Road Map Vorlage:

Es gibt dem Projekt im Unternehmen kurzfristig und langfristig eine Richtung. Es hilft bei der Festlegung von Erwartungen innerhalb des Unternehmens. Und die Übersicht darüber, wohin das Projekt führt.

Schätzungsstufen in einem agilen Projekt

In einem agilen Projekt werden Schätzungen auf drei Ebenen durchgeführt, wie unten erwähnt:

• Projekt- / Vorschlagsebene: Die Gesamtfunktionsgröße der gesamten Anwendung wird mithilfe der QFPA-Methode (Quick Function Point Analysis) geschätzt, wenn nur Anforderungen auf hoher Ebene verfügbar sind.
• Release Level: Den User Storys werden Story Points zugewiesen, die bei der Ermittlung der Nr. der im Rahmen eines Projekts geplanten Veröffentlichungen und der Nr. von User Stories, die in einem Release und Sprint aufgenommen werden sollen.
• Sprint Level: Die geschätzten Stunden werden den Aufgaben der User Stories innerhalb eines Sprints zugewiesen. Dies geschieht, um das Engagement der Entwicklung für die Bereitstellung von User Stories im Sprint sicherzustellen.

S1, S2, S3, S4, S5, S6 sind Sprints.

# 1) Schätzung des Vorschlags oder der Projektebene

Es ist eine sehr hochrangige Schätzung für das Projekt. Es konzentriert sich auf die Gesamtzahl der Anforderungen im Product Backlog-Element. Mit Funktionspunkten wird die Größe der Software / des Projekts geschätzt, bevor eine detaillierte Beschreibung der Funktionsanforderungen dokumentiert wird.

Funktionspunkte sind die allgemein akzeptierte Methode zur Berechnung der Größe der Software. Es konzentriert sich auf die Funktionen, die in den Softwareprojekten enthalten sind. Ein Funktionspunkt ist eine Metrik, die die Anforderungen oder User Stories in eine Zahl umwandelt.

In der Anfangsphase des Projekts wird empfohlen, die QFPA-Methode (Quick Function Point Analysis) anzuwenden.

Die Methode zur schnellen Funktionspunktanalyse ist ein einzigartiger Ansatz zur Schätzung des FP, wenn nur Anforderungen auf hoher Ebene verfügbar sind.

Handy-Spionage-Apps für Android

Wie berechnet man die Gesamtfunktionsgröße?

• Verstehen Sie alle Funktionen einer Anwendung mithilfe von Domain-Experten.
• Identifizieren und listen Sie alle möglichen Funktionen einer Anwendung auf.
• Datenspeicherfunktionen werden in interne Logikdateien (Daten, die intern in der Anwendung gespeichert sind) und externe Schnittstellendateien (Daten, die nur zu Referenzzwecken verwendet werden) unterteilt.
• Transaktionsfunktionen werden in externe Eingänge (Daten, die von externen Quellen zur Anwendung kommen), externe Ausgänge (abgeleitete Daten gehen von der Anwendung nach außen) und externe Anfragen (Daten, die von einem oder mehreren externen Eingängen und externen Ausgängen abgerufen werden) unterteilt.
• Berechnen Sie die FP-Größe für jede Funktion, indem Sie ihre durchschnittliche Komplexität berechnen.
• Fassen Sie die FP-Größe aller Funktionen zusammen, um die Gesamtfunktionsgröße der Anwendung zu erhalten.
• Mindestens zwei Personen mit Fachkenntnissen in der FP-Analyse sollten unabhängig voneinander rechnen, die Ergebnisse abgleichen und die Unterschiede beheben.

Beispiel für die Schätzung auf Projektebene:

Unten finden Sie eine Liste der Anforderungen für ein Projekt wie im Product Backlog:

• Ein Benutzer sollte sich auf der Website anmelden können, indem er den Benutzernamen und das Passwort angibt.
• Nach erfolgreicher Anmeldung sollte ein Benutzer mit definiertem rechten und linken Fenster zur Hauptseite weitergeleitet werden.
• Ein Benutzer sollte die Möglichkeit haben, sich von der Anwendung abzumelden.
• Ein gültiger Benutzer hat die Möglichkeit, das Kennwort durch Angabe der aktuellen Anmeldeinformationen zu ändern.

Das Team verwendet eine Quick FP-Schätzung, um die Projektgröße zu schätzen.

Es folgt die Analyse:

• Die Datenspeicherfunktion speichert hier die Benutzeranmeldeinformationen, um sich anzumelden und das Kennwort zu ändern.
• Da die Anmeldeinformationen innerhalb der Anwendungsgrenze gespeichert werden, werden sie in ILFs (Internal Logical Files) gespeichert.
• Die Transaktionsfunktionen umfassen:
  • Benutzeranmeldung und Anzeige der Hauptseite.
  • Benutzerabmeldung und Anzeige des Abmeldebildschirms.
  • Möglichkeit, das Passwort zu ändern.

Im Folgenden sind die Schritte aufgeführt, die zum Schätzen der Projektgröße mithilfe der Schnellfunktionspunktanalyse ausgeführt werden:

SCHRITT 1: Listen Sie alle Datenfunktionen auf

UFP (Unadjusted Function Point) wird aus der Caper Jones-Tabelle entnommen.

SCHRITT 2: Listen Sie alle Transaktionsfunktionen auf

UFP (Unadjusted Function Point) wird aus der Caper Jones-Tabelle entnommen.

SCHRITT 3: Ableiten der geschätzten Projektgröße in Funktionspunkten

UFP = Daten-FP + Transaktions-FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (unter der Annahme von VFP (Wertanpassungsfaktor = 1)

Produktivität = 16 FP / Monat (normaler Standard)

Aufwand = FP / Produktivität = 22/16-Personen-Monat = 1,37-Personen-Monat

# 2) Release Level Estimation

Schätzungen des Release-Levels werden während der Release-Planung durchgeführt. Dies ist die nächste Aktivität nach der Schätzung auf Projektebene. Die priorisierten Anforderungen werden dem Product Backlog in Form von User Stories entnommen.

Die User Stories werden während der Release-Planung in Bezug auf Story-Punkte geschätzt, wobei der Schwerpunkt auf der Schätzung der Größe der für dieses Release zu liefernden Software liegt. Auf diese Weise sind keine Veröffentlichungen und insgesamt keine Story Points in jeder Veröffentlichung geplant.

Ein Story Point repräsentiert im Wesentlichen den relativen Aufwand, der zum Implementieren eines Features oder der Funktionalität im Vergleich zu den anderen Features erforderlich ist. Dies dient im Wesentlichen der Dimensionierung der Product Backlog-Elemente.

Die Schätzung des Story Points erfolgt auf der Grundlage von:

• Die Komplexität der zu implementierenden Funktion.
• Erfahrung und technische Fähigkeiten aller Mitglieder.

S1, S2, S3, S4, S5 sind Sprints.

Schritte zum Zuweisen von Story-Punkten zu einer User-Story:

• Alle Teammitglieder versammeln sich an einem Tisch und gehen die im Sprint Backlog enthaltenen User Stories durch.
• Die Bedeutung eines Story Points und der entsprechende Aufwand wird festgelegt.
• Eines der Teammitglieder liest eine User Story vor und bittet die Teammitglieder, die relativen Story Points zuzuweisen.
• Wenn es einen signifikanten Unterschied zwischen den von den Teammitgliedern zugewiesenen Story-Punkten gibt, geben sie eine Erklärung für die von ihnen zugewiesenen Story-Punkte und erreichen so am Ende einen Konsens.
• Der Vorgang wird 3-4 Mal wiederholt, bis kein wesentlicher Unterschied zwischen den Schätzungen der Teammitglieder mehr besteht.
• Die Größe von Storys hilft bei der Bestimmung, wie viele Storys innerhalb eines Sprints und einer Veröffentlichung aufgenommen werden.

Beispiel für die Schätzung des Release-Levels:

Dies beinhaltet das Erstellen einer priorisierten Liste von User Stories mit dem Namen Product Backlog. Der Product Owner erstellt ein Product Backlog und gibt für jeden darin aufgeführten Artikel einen Geschäftswert an.

Wir können die folgenden Methoden für die Schätzung von Story-Punkten verwenden:

• Numerische Größe: 1 bis 10
• T-Shirt Größe: Jede Anforderung wird als extra klein (XS), klein (S), mittel (M), groß (L), extra groß (XL) klassifiziert.
• Fibonacci-Serie: Schätzung durch Fibonacci-Sequenz (1,2,3,5,8,13,21,34,….)

Schätzung der obigen User Stories durch die Fibonacci-Sequenz:

# 3) Sprint Level Estimation

Sprint-Level-Schätzungen werden während der Sprint-Planung durchgeführt. Produkt-Backlog-Elemente mit der höchsten Priorität werden übernommen und in verschiedene Aufgaben wie Detaillierung, Design, Analyse, Entwicklung, Erstellen von Testfällen, Ausführen von Testfällen, Testen der Benutzerakzeptanz usw. unterteilt.

Aufgaben werden in geschätzten Stunden geschätzt, d. H. In der Zeit, die erforderlich ist, um diese Aufgabe für eine entsprechende User Story zu erledigen. Der Bottom-Up-Ansatz wird für die Aufgabenschätzungen verwendet, bei denen die Geschäftsanforderungen in Aktivitäten auf niedriger Ebene unterteilt werden und jeder Aktivität geschätzte Stunden zugewiesen werden.

Der Zweck der Schätzungen besteht darin, zu wissen, wie viele User Stories das Entwicklungsteam für einen Sprint festlegen kann. Die Entwicklung muss mit dem Engagement zufrieden sein und die Product Owners müssen zuversichtlich sein, dass das Team das Engagement einhalten wird.

S. Schritte zum Zuweisen der geschätzten Stunden zu den Aufgaben:

• Die Teammitglieder nehmen die User Stories auf. Anschließend werden sie gebeten, den tatsächlichen Aufwand für die der User Story entsprechenden Aufgaben in Stunden oder Tagen zu schätzen.
• Wenn diese Schätzungen unter den Teammitgliedern nicht übereinstimmen, diskutieren sie darüber und kommen zu einem Konsens.
• Wenn eine Aufgabe länger als sechs Stunden dauert, wird sie in kleinere Aufgaben aufgeteilt.
• Wenn es zwei oder mehr Aufgaben mit geschätzten Stunden von weniger als zwei gibt, werden sie zu einer neuen Aufgabe kombiniert.

Beispiel für die Sprint Level Estimation:

Das Sprint Planning-Meeting besteht aus zwei Teilen:

• Erster Teil: Der Schwerpunkt liegt auf der Klärung der Anforderungen für User Stories, die aus dem Product Backlog ausgewählt wurden.
• Zweiter Teil: Der Schwerpunkt liegt darauf, die Anforderungen in Aufgaben zu unterteilen und die dafür erforderlichen Stunden zu schätzen. Alle Aufgaben, die erforderlich sind, um das Product Backlog-Element lieferbar zu machen, sollten enthalten sein. Die Aufgaben sollten klein sein. Im Idealfall sollte der Arbeitsaufwand nicht mehr als sechs Stunden betragen.

Fazit

Die Schätzungen im Agile-Projekt spielen eine wichtige Rolle, um die richtige Ausrichtung, Planung und Verwaltung sicherzustellen. Sie enthalten Schritte zur künftigen Aufnahme des Projekts.

Die Techniken zum Schätzen von Story-Punkten wie Planning Poker, Bucket System usw. verwenden Karten oder Punkte, auf denen Werte oder Zahlen gedruckt sind, und weisen diese dann zu. zu den User Stories zur relativen Größenschätzung.

Der einzige Zweck besteht darin, die Elemente in einer priorisierten Reihenfolge von maximaler Priorität zu minimaler Priorität festzulegen. Die für die Product Backlog-Elemente geschätzten relativen Größen helfen bei der Schätzung oder Berechnung des für das Projekt erforderlichen Budgets.

Ich hoffe, Sie hätten einen großartigen Einblick in die Schätzungen agiler Projekte erhalten. Fühlen Sie sich frei, Ihre Gedanken zu diesem Tutorial im Kommentarbereich unten auszudrücken.

Literatur-Empfehlungen

• So vereinfachen Sie den agilen Schätzprozess mit Planning Poker
• Agile Vs Waterfall: Welches ist die beste Methode für Ihr Projekt?
• Techniken zur Schätzung von Softwaretests (Vollständiger Leitfaden zur Schätzung des Testaufwands)
• VersionOne-Lernprogramm: All-in-One-Handbuch für agiles Projektmanagement
• Jira Portfolio Tutorial: Agiles Projektportfolio-Management-Plug-In für JIRA (Überprüfung)
• TOP 10 der besten agilen Projektmanagement-Tools im Jahr 2021
• Grundlagen für eine erfolgreiche agile Reise: Auswahl der richtigen Methode, Werkzeuge und Techniken
• 4 Schritte zur Entwicklung der Denkweise für agile Tests für einen erfolgreichen Übergang zu agilen Prozessen