Agile - Kurzanleitung

Agile - Grundierung

Agile ist eine Softwareentwicklungsmethode zum schrittweisen Erstellen einer Software in kurzen Iterationen von 1 bis 4 Wochen, damit der Entwicklungsprozess auf die sich ändernden Geschäftsanforderungen abgestimmt ist. Anstelle einer Entwicklung in einem Durchgang von 6 bis 18 Monaten, bei der alle Anforderungen und Risiken im Voraus vorhergesagt werden, wendet Agile einen Prozess mit häufigem Feedback an, bei dem ein funktionsfähiges Produkt nach einer bis vierwöchigen Iteration geliefert wird.

Agile Vs Traditional SDLC

Rollen in Agile

Scrum Master

Ein Scrum Master ist ein Teamleiter und Moderator, der den Teammitgliedern hilft, agile Praktiken zu befolgen, damit sie ihren Verpflichtungen nachkommen können. Die Aufgaben eines Scrum Masters lauten wie folgt:

  • Um eine enge Zusammenarbeit zwischen allen Rollen und Funktionen zu ermöglichen.

  • Blockierungen entfernen.

  • Um das Team vor Störungen zu schützen.

  • Mit der Organisation zusammenarbeiten, um den Fortschritt und die Prozesse des Unternehmens zu verfolgen.

  • Sicherstellen, dass die Prozesse von Agile Inspect & Adapt ordnungsgemäß genutzt werden, einschließlich

    • Tägliche Stand-ups,
    • Geplante Besprechungen,
    • Demo,
    • Rezension,
    • Retrospektive Treffen und
    • Vereinfachung von Teambesprechungen und Entscheidungsprozessen.

Product Owner

Ein Product Owner ist derjenige, der das Produkt aus geschäftlicher Sicht steuert. Die Verantwortlichkeiten eines Product Owners lauten wie folgt:

  • Anforderungen definieren und deren Werte priorisieren.
  • So bestimmen Sie das Erscheinungsdatum und den Inhalt.
  • Eine aktive Rolle bei der Iterationsplanung und bei Versionsplanungsbesprechungen übernehmen.
  • Um sicherzustellen, dass das Team an der am meisten geschätzten Anforderung arbeitet.
  • Zur Darstellung der Stimme des Kunden.
  • Akzeptieren der User Stories, die die Definition von erledigten und definierten Akzeptanzkriterien erfüllen.

Funktionsübergreifende Team

Jedes agile Team sollte ein autarkes Team mit 5 bis 9 Teammitgliedern und einer durchschnittlichen Erfahrung von 6 bis 10 Jahren sein. In der Regel besteht ein agiles Team aus 3 bis 4 Entwicklern, 1 Tester, 1 technischen Leiter, 1 Product Owner und 1 Scrum Master.

Funktionsübergreifende Team

Product Owner und Scrum Master gelten als Teil von Team Interface, während andere Mitglieder Teil von Technical Interface sind.

Wie plant ein agiles Team seine Arbeit?

Ein agiles Team arbeitet in Iterationen, um User Stories mit einer Iterationsdauer von 10 bis 15 Tagen zu liefern. Jede User Story wird basierend auf ihrer Priorisierung und Größe des Backlogs geplant. Das Team verwendet seine Kapazität - wie viele Stunden mit dem Team zur Verfügung stehen, um an Aufgaben zu arbeiten -, um zu entscheiden, wie viel Umfang geplant werden muss.

Planung

Punkt

Ein Punkt definiert, wie viel ein Team verpflichten kann. Ein Punkt bezieht sich normalerweise auf 8 Stunden. Jede Geschichte wird in Punkten geschätzt.

Kapazität

Kapazität definiert, wie viel eine Person festlegen kann. Die Kapazität wird in Stunden geschätzt.

Was ist eine User Story?

Eine User Story ist eine Anforderung, die definiert, was der Benutzer als Funktionalität benötigt. Eine User Story kann in zwei Formen vorliegen:

  • Als <Benutzerrolle> möchte ich <Funktionalität>, damit <Geschäftswert>
  • Um <Geschäftswert> als <Benutzerrolle> zu definieren, möchte ich <Funktionalität>

Während der Release-Planung wird eine User Story anhand der relativen Skalierung als Punkt grob geschätzt. Während der Iterationsplanung wird die Story in Aufgaben unterteilt.

Beziehung von User Stories und Aufgaben

  • Die User Story erzählt, was zu tun ist. Es definiert, was ein Benutzer benötigt.
  • Aufgabe spricht darüber, wie es gemacht werden soll. Es definiert, wie eine Funktionalität implementiert werden soll.
  • Geschichten werden durch Aufgaben umgesetzt. Jede Geschichte ist eine Sammlung von Aufgaben.
  • Die User Story ist in Aufgaben unterteilt, wenn sie in der aktuellen Iteration geplant ist.
  • Aufgaben werden in Stunden, normalerweise zwischen 2 und 12 Stunden, veranschlagt.
  • Geschichten werden mit Abnahmetests validiert.
Beziehung von User Stories und Aufgaben

Wenn eine Geschichte fertig ist

Das Team entscheidet, was getan wird. Die Kriterien können sein -

  • Alle Aufgaben (Entwicklung, Test) sind erledigt.
  • Alle Abnahmetests laufen und sind bestanden.
  • Kein Defekt ist offen.
  • Der Product Owner hat die Story akzeptiert.
  • Lieferung an den Endbenutzer.

Was sind Akzeptanzkriterien?

Kriterien definieren die Funktionalität, das Verhalten und die Leistung, die für ein Feature erforderlich sind, damit es vom Product Owner akzeptiert werden kann. Es definiert, was zu tun ist, damit der Entwickler weiß, wann eine User Story abgeschlossen ist.

Wie sind die Anforderungen definiert?

Anforderungen sind definiert als

  • Eine User Story,
  • Mit Abnahmekriterien und
  • Aufgaben zur Umsetzung der Geschichte.

Agile - Manifest

Im Februar 2001 trafen sich 17 Softwareentwickler im Snowbird-Resort in Utah, um Methoden für die Entwicklung von Leichtbauprodukten zu diskutieren. Das Ergebnis ihres Treffens war das folgende Agile Manifest für die Softwareentwicklung:

Wir entdecken bessere Wege, um Software zu entwickeln, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit sind wir zu Wert gekommen -

  • Individuen und Interaktionen über Prozesse und Werkzeuge
  • Arbeitssoftware über Umfassende Dokumentation
  • Kundenkooperation über Vertragsverhandlungen
  • Reagieren auf Umstellung Nach einem Plan

Das heißt, während es Wert in den Gegenständen auf der rechten Seite gibt, schätzen wir die Gegenstände auf der linken Seite mehr.

Zwölf Prinzipien des Agilen Manifests

  • Kundenzufriedenheit - Die Erfüllung der Kundenanforderungen durch frühzeitige und kontinuierliche Lieferung wertvoller Software hat höchste Priorität.

  • Welcome Change - Änderungen sind während der Softwareentwicklung unumgänglich. Sich ständig ändernde Anforderungen sollten auch spät in der Entwicklungsphase willkommen sein. Agile Prozesse sollen den Wettbewerbsvorteil der Kunden steigern.

  • Bereitstellen einer funktionierenden Software - Stellen Sie häufig eine funktionierende Software bereit, von einigen Wochen bis zu einigen Monaten, unter Berücksichtigung des kürzeren Zeitrahmens.

  • Zusammenarbeit - Geschäftsleute und Entwickler müssen während der gesamten Laufzeit eines Projekts zusammenarbeiten.

  • Motivation - Projekte sollten auf motivierten Einzelpersonen aufbauen. Bieten Sie eine Umgebung, in der Sie einzelne Teammitglieder unterstützen und ihnen vertrauen können, damit sie sich für die Erledigung ihrer Aufgaben verantwortlich fühlen.

  • Face-to-Face-Konversation - Face-to-Face-Konversation ist die effizienteste und effektivste Methode, um Informationen an und innerhalb eines Entwicklungsteams zu übermitteln.

  • Messung des Fortschritts gemäß der Arbeitssoftware - Arbeitssoftware ist der Schlüssel und sollte das primäre Maß für den Fortschritt sein.

  • Konstantes Tempo einhalten - Agile Prozesse zielen auf eine nachhaltige Entwicklung ab. Das Unternehmen, die Entwickler und die Benutzer sollten in der Lage sein, ein konstantes Tempo mit dem Projekt beizubehalten.

  • Überwachung - Achten Sie regelmäßig auf technische Exzellenz und gutes Design, um die Beweglichkeit zu verbessern.

  • Einfachheit - Halten Sie die Dinge einfach und verwenden Sie einfache Begriffe, um die Arbeit zu messen, die noch nicht abgeschlossen ist.

  • Selbstorganisierte Teams - Ein agiles Team sollte selbstorganisiert sein und nicht stark von anderen Teams abhängen, da die besten Architekturen, Anforderungen und Entwürfe von selbstorganisierten Teams stammen.

  • Regelmäßige Überprüfung der Arbeit - Überprüfen Sie die geleistete Arbeit in regelmäßigen Abständen, damit das Team darüber nachdenken und sein Verhalten entsprechend anpassen kann.

Agile - Eigenschaften

Iterativ / inkrementell und bereit zur Weiterentwicklung

Die meisten agilen Entwicklungsmethoden unterteilen ein Problem in kleinere Aufgaben. Es gibt keine direkte langfristige Planung für einen Bedarf. Normalerweise sind Iterationen geplant, die von kurzer Dauer sind, beispielsweise 1 bis 4 Wochen. Für jede Iteration wird ein funktionsübergreifendes Team erstellt, das in allen Funktionen der Softwareentwicklung wie Planung, Anforderungsanalyse, Design, Codierung, Komponententest und Abnahmetest arbeitet. Das Ergebnis am Ende der Iteration ist ein funktionierendes Produkt und wird den Stakeholdern am Ende einer Iteration demonstriert.

Nach der Demo werden Überprüfungskommentare aufgenommen, die bei Bedarf in die Arbeitssoftware integriert werden sollen.

Kommunikation von Angesicht zu Angesicht

Jedes agile Team sollte einen Kundenvertreter wie einen Product Owner in Scrum-Methodik haben. Dieser Vertreter ist befugt, im Namen der Stakeholder zu handeln, und kann die Fragen der Entwickler zwischen den Iterationen beantworten.

Ein Informationsstrahler (physisches Display) befindet sich normalerweise an prominenter Stelle in einem Büro, wo Passanten den Fortschritt des agilen Teams verfolgen können. Dieser Informations-Radiator zeigt eine aktuelle Zusammenfassung des Status eines Projekts.

Rückkopplungsschleife

Tägliches Aufstehen ist eine gängige Kultur jeder agilen Entwicklung. Es ist auch als tägliches Gedränge bekannt . Es ist eine Art kurze Sitzung, in der jedes Teammitglied sich gegenseitig über den Status der von ihm geleisteten Arbeit, die nächsten Schritte und die Probleme, mit denen es konfrontiert ist, Bericht erstattet.

Agile - Tägliches Aufstehen

Tägliches Aufstehen ist, wie der Name schon sagt, eine tägliche Statusbesprechung aller Mitglieder eines agilen Teams. Es bietet nicht nur ein Forum für regelmäßige Aktualisierungen, sondern stellt auch die Probleme der Teammitglieder in den Mittelpunkt, damit diese schnell angegangen werden können. Tägliches Aufstehen ist ein Muss, egal wie ein agiles Team aufgebaut ist, unabhängig von seinem Bürostandort.

Was ist tägliches Aufstehen?

  • Ein tägliches Stand-up ist eine tägliche Statusbesprechung aller Teammitglieder, die ungefähr 15 Minuten dauert.

  • Jedes Mitglied muss drei wichtige Fragen beantworten:

    • Was ich gestern gemacht habe?
    • Was mache ich heute?
    • Jedes Hindernis, dem ich gegenüberstehe ... / Ich bin blockiert wegen ...
  • Tägliches Aufstehen dient der Statusaktualisierung und nicht zur Diskussion. Zur Diskussion sollten die Teammitglieder eine weitere Besprechung zu einem anderen Zeitpunkt planen.

  • Die Teilnehmer stehen in der Regel anstatt zu sitzen, damit die Besprechung schnell beendet wird.

Warum ist Stand-up wichtig?

Die Vorteile eines täglichen Stand-Ups in Agile sind:

  • Das Team kann den Fortschritt täglich bewerten und prüfen, ob es den Iterationsplan einhält.
  • Jedes Teammitglied informiert über seine täglichen Verpflichtungen.
  • Es bietet dem Team Sichtbarkeit bei Verzögerungen oder Hindernissen.

Wer nimmt an einem Stand-up teil?

  • Der Scrum Master, der Product Owner und das Delivery Team sollten täglich am Stand-up teilnehmen.

  • Stakeholder und Kunden werden ermutigt, an der Besprechung teilzunehmen, und sie können als Beobachter auftreten, sie dürfen jedoch nicht an Stand-ups teilnehmen.

  • Es liegt in der Verantwortung des Scrum Masters, die Fragen der einzelnen Teammitglieder und die Probleme, mit denen sie konfrontiert sind, zur Kenntnis zu nehmen.

Geografisch verteilte Teams

Stand-ups können auf verschiedene Arten durchgeführt werden, falls die agilen Teammitglieder aus verschiedenen Zeitzonen operieren.

  • Wählen Sie ein Mitglied im Rotationsverfahren aus, das am Stand-up-Meeting von Teams in verschiedenen Zeitzonen teilnehmen kann.

  • Verfügen Sie über einen separaten Stand-up pro Team, und aktualisieren Sie den Stand-up-Status in einem Tool wie Rallye, SharePoint, Wikis usw.

  • Halten Sie eine Vielzahl von Kommunikationstools wie Telefonkonferenzen, Videokonferenzen, Sofortnachrichten oder andere Tools für den Wissensaustausch mit Drittanbietern bereit.

Agile - Definition von Done

Die Definition von " Fertig" für User Story, Iteration und Release ist unten angegeben.

Benutzer Geschichte

Eine User Story ist eine Anforderung, die in wenigen Sätzen in der Alltagssprache eines Benutzers formuliert ist und innerhalb einer Iteration abgeschlossen werden sollte. Eine User Story ist fertig wenn

  • Der gesamte zugehörige Code wurde eingecheckt.
  • Alle Unit-Testfälle wurden bestanden.
  • Alle Abnahmetestfälle wurden bestanden.
  • Hilfetext wird geschrieben.
  • Der Product Owner hat die Story akzeptiert.

Wiederholung

Eine Iteration ist eine Sammlung von User Stories / Fehlern, die in einer Zeitbox bearbeitet und bei der Veröffentlichung eines Produkts akzeptiert werden müssen. Iterationen werden während der Iterationsplanungsbesprechung definiert und mit einer Iterationsdemo- und Überprüfungsbesprechung abgeschlossen. Eine Iteration wird auch als Sprint bezeichnet . Eine Iteration wird ausgeführt, wenn

  • Die Produktsicherung ist abgeschlossen.
  • Leistung wurde getestet.
  • User Stories wurden akzeptiert oder in die nächste Iteration verschoben.
  • Fehler wurden behoben oder auf die nächste Iteration verschoben.

Freisetzung

Ein Release ist ein wichtiger Meilenstein, der eine interne oder externe Lieferung einer funktionsfähigen, getesteten Version des Produkts / Systems darstellt. Eine Freigabe erfolgt wann

  • Das System ist auf Stress getestet.
  • Die Leistung ist abgestimmt.
  • Sicherheitsüberprüfungen werden durchgeführt.
  • Disaster Recovery-Plan wird getestet.

Agile - Release-Planung

Der Zweck der Release-Planung besteht darin, einen Plan zu erstellen, um ein Inkrement für das Produkt bereitzustellen. Es wird alle 2 bis 3 Monate durchgeführt.

Release-Planung

Wer ist beteiligt?

  • Scrum Master - Der Scrum Master fungiert als Vermittler für das agile Lieferteam.

  • Product Owner - Der Product Owner repräsentiert die allgemeine Ansicht des Product Backlog.

  • Agiles Team - Das agile Lieferteam bietet Einblicke in die technischen Möglichkeiten oder Abhängigkeiten.

  • Stakeholder - Stakeholder wie Kunden, Programmmanager und Fachexperten fungieren als Berater, wenn Entscheidungen über die Release-Planung getroffen werden.

Planungsvoraussetzungen

Voraussetzungen für die Release-Planung sind:

  • Ein klassifizierter Produktstau, der vom Product Owner verwaltet wird. In der Regel werden fünf bis zehn Funktionen verwendet, die nach Ansicht des Produktbesitzers in einer Version enthalten sein können

  • Beiträge des Teams zu Fähigkeiten, bekannter Geschwindigkeit oder zu technischen Herausforderungen

  • Vision auf hohem Niveau

  • Markt- und Geschäftsziel

  • Bestätigung, ob neue Artikelrückstände erforderlich sind

Erforderliche Materialien

Die Liste der für die Freigabeplanung erforderlichen Materialien lautet wie folgt:

  • Gepostete Agenda, Zweck
  • Flipcharts, Whiteboards, Marker
  • Projektor, Möglichkeit zur gemeinsamen Nutzung von Computern mit Daten / Tools, die während des Planungsmeetings benötigt werden
  • Planungsdaten

Planungsdaten

Die Liste der Daten, die für die Release-Planung erforderlich sind, lautet wie folgt:

  • Vorherige Iterationen oder Release-Planungsergebnisse
  • Feedback von verschiedenen Stakeholdern zu Produkt, Marktbedingungen und Fristen
  • Aktionspläne früherer Releases / Iterationen
  • Merkmale oder Mängel sind zu berücksichtigen
  • Geschwindigkeit aus früheren Versionen / Schätzungen.
  • Organisatorische und persönliche Kalender
  • Beiträge von anderen Teams und Fachexperten, um eventuelle Abhängigkeiten zu verwalten

Ausgabe

Die Ausgabe einer Release-Planung kann wie folgt aussehen:

  • Plan freigeben
  • Engagement
  • Probleme, Bedenken, Abhängigkeiten und Annahmen, die überwacht werden sollen
  • Vorschläge zur Verbesserung zukünftiger Release-Planungen

Agenda

Die Agenda einer Release-Planung kann sein:

  • Eröffnungsfeier - Begrüßungsnachricht, Prüfungszweck und -agenda, Organisationstools und Einführung für Geschäftssponsoren.

  • Produktvision, Roadmap - Zeigen Sie das große Bild des Produkts.

  • Frühere Versionen überprüfen - Diskussion über alle Elemente, die Auswirkungen auf den Plan haben können.

  • Release-Name / Thema - Überprüfen Sie den aktuellen Status der Roadmap-Themen und nehmen Sie gegebenenfalls die erforderlichen Anpassungen vor.

  • Velocity - Zeigt die Velocity für die aktuelle Version und für frühere Versionen an.

  • Release-Zeitplan - Überprüfen Sie wichtige Meilensteine und entscheiden Sie, welche Zeitrahmen für die Freigabe und Iterationen innerhalb der Freigabe gelten.

  • Probleme und Bedenken - Überprüfen Sie alle Bedenken oder Probleme und zeichnen Sie sie auf.

  • Überprüfen und Aktualisieren der Definition von "Fertig" - Überprüfen Sie die Definition von "Fertig" und nehmen Sie die entsprechenden Änderungen basierend auf Technologie, Fähigkeiten oder Änderungen bei Teammitgliedern seit der letzten Iteration / Veröffentlichung vor.

  • Zu berücksichtigende Storys und Elemente - Präsentieren Sie die User Storys und Features aus dem Product Backlog, die für die Planung in der aktuellen Version berücksichtigt werden sollen.

  • Größenwerte ermitteln - Wenn die Geschwindigkeit unbekannt ist, planen Sie die Größenwerte, die in der Freigabeplanung verwendet werden sollen.

  • Grobe Größe von Storys - Das Übermittlungsteam bestimmt die entsprechende Größe der in Betracht gezogenen Storys und teilt die Storys in mehrere Iterationen auf, wenn eine Story zu groß ist. Der Product Owner und die Fachexperten klären die Zweifel auf, erarbeiten die Akzeptanzkriterien und machen die richtigen Storysplits. Der Scrum Master erleichtert die Zusammenarbeit.

  • Zuordnen von Storys zu Iterationen - Das Auslieferungsteam und der Product Owner verschieben die Storys / Defekte in den Iterationen basierend auf der Größe und Geschwindigkeit. Der Scrum Master erleichtert die Zusammenarbeit.

  • Neue Bedenken oder Probleme - Überprüfen Sie alle neuen Probleme, die auf früheren Erfahrungen basieren, und notieren Sie diese.

  • Abhängigkeiten und Annahmen - Überprüfen Sie alle Abhängigkeiten / Annahmen, die während der Release-Planung geplant wurden.

  • Commit - Der Scrum Master fordert die Planung an. Das Auslieferungsteam und der Product Owner geben an, dass dies der beste Plan ist, und verpflichten sich dann, zur nächsten Planungsebene überzugehen, dh zur Iterationsplanung.

  • Kommunikations- und Logistikplanung - Überprüfen / Aktualisieren Sie die Kommunikations- und Logistikplanung für das Release.

  • Parkplatz - Prozessparkplatz bedeutet, dass alle Elemente entweder aufgelöst oder als Aktionselemente festgelegt werden sollten.

  • Aktionselemente und Aktionspläne verteilen - Verteilen Sie die Aktionselemente unter ihren Eigentümern und verarbeiten Sie den Aktionsplan.

  • Rückblick - Bitten Sie die Teilnehmer um Feedback, um das Meeting erfolgreich zu gestalten.

  • Schließen - Feiern Sie den Erfolg.

Agile Iterationsplanung

Der Zweck der Iterationsplanung besteht darin, dass das Team den Satz der bestplatzierten Product Backlog-Elemente vervollständigt. Diese Verpflichtung wird basierend auf der Länge der Iteration und der Teamgeschwindigkeit zeitlich begrenzt.

Iterationsplanung

Wer ist beteiligt?

  • Scrum Master - Der Scrum Master fungiert als Vermittler für das agile Lieferteam.

  • Product Owner - Der Product Owner kümmert sich um die Detailansicht des Product Backlogs und deren Akzeptanzkriterien.

  • Agiles Team - Agile Bereitstellung definiert ihre Aufgaben und legt die Aufwandsschätzungen fest, die zur Erfüllung der Verpflichtung erforderlich sind.

Planungsvoraussetzungen

  • Artikel im Product Backlog haben eine Größe und einen relativen Story Point.
  • Portfolio-Artikel wurden vom Product Owner in der Rangliste aufgeführt.
  • Die Annahmekriterien wurden für jedes Portfolioelement klar angegeben.

Planungsprozess

Im Folgenden sind die Schritte zur Iterationsplanung aufgeführt:

  • Bestimmen Sie, wie viele Storys in eine Iteration passen.
  • Teilen Sie diese Geschichten in Aufgaben auf und weisen Sie jede Aufgabe ihren Besitzern zu.
  • Jede Aufgabe wird in Stunden geschätzt.
  • Mithilfe dieser Schätzungen können Teammitglieder überprüfen, wie viele Arbeitsstunden jedes Mitglied für die Iteration hat.
  • Den Teammitgliedern werden Aufgaben unter Berücksichtigung ihrer Geschwindigkeit oder Kapazität zugewiesen, damit sie nicht überlastet werden.

Geschwindigkeitsberechnung

Ein agiles Team berechnet die Geschwindigkeit basierend auf vergangenen Iterationen. Die Geschwindigkeit ist eine durchschnittliche Anzahl von Einheiten, die erforderlich sind, um User Storys in einer Iteration zu beenden. Wenn ein Team beispielsweise in den letzten drei Iterationen in jeder Iteration 12, 14 oder 10 Story-Punkte gesammelt hat, kann das Team für die nächste Iteration 12 als Geschwindigkeit verwenden.

Die geplante Geschwindigkeit gibt dem Team an, wie viele Benutzergeschichten in der aktuellen Iteration abgeschlossen werden können. Wenn das Team die zugewiesenen Aufgaben schnell erledigt, können mehr User Storys abgerufen werden. Andernfalls können die Storys auch in die nächste Iteration verschoben werden.

Aufgabenkapazität

Die Kapazität eines Teams ergibt sich aus den folgenden drei Fakten:

  • Anzahl der idealen Arbeitsstunden pro Tag
  • Verfügbare Personentage in der Iteration
  • Prozentsatz der Zeit, in der ein Mitglied ausschließlich für das Team verfügbar ist.

Angenommen, ein Team besteht aus 5 Mitgliedern, die verpflichtet sind, 8 Stunden pro Tag in Vollzeit an einem Projekt zu arbeiten, und während einer Iteration ist niemand in Urlaub, dann beträgt die Aufgabenkapazität für eine zweiwöchige Iteration:

5 × 8 × 10 = 400 Stunden

Planungsschritte

  • Product Owner beschreibt den bestplatzierten Artikel des Product Backlogs.
  • Team beschreibt die Aufgaben, die zum Abschließen des Artikels erforderlich sind.
  • Teammitglieder besitzen die Aufgaben.
  • Die Teammitglieder schätzen die Zeit bis zum Abschluss jeder Aufgabe.
  • Diese Schritte werden für alle Elemente in der Iteration wiederholt.
  • Wenn eine Person mit Aufgaben überlastet ist, wird ihre Aufgabe auf andere Teammitglieder verteilt.

Agile - Product Backlog

Ein Product Backlog ist eine Liste der zu erledigenden Aufgaben. Elemente werden mit Funktionsbeschreibungen geordnet. Im Idealfall sollten Elemente in User Stories unterteilt werden.

Warum ist Product Backlog wichtig?

  • Es ist so vorbereitet, dass Schätzungen für jedes einzelne Merkmal vorgenommen werden können.
  • Es hilft bei der Planung der Roadmap für das Produkt.
  • Dies hilft bei der Neueinstufung der Funktionen, damit dem Produkt ein höherer Wert beigemessen werden kann.
  • Es hilft bei der Bestimmung, was zuerst priorisiert werden soll. Team ordnet den Gegenstand und baut dann Wert auf.

Eigenschaften des Product Backlog

  • Jedes Produkt sollte einen Product Backlog haben, der eine Reihe von großen bis sehr großen Features enthalten kann.

  • Mehrere Teams können an einem einzigen Produktstau arbeiten.

  • Die Rangfolge der Funktionen basiert auf dem Geschäftswert, dem technischen Wert, dem Risikomanagement oder der strategischen Fitness.

  • Elemente mit dem höchsten Rang werden während der Release-Planung in kleinere Storys zerlegt, damit sie in zukünftigen Iterationen vervollständigt werden können.

Agil - Nützliche Begriffe

Akzeptanzkriterium

Es sind die Bedingungen, die vom Produktbesitzer oder Kunden festgelegt werden, um ein Merkmal als gültig zu akzeptieren und seine Anforderungen zu erfüllen.

Backlog-Pflege

Es ist ein fortlaufender Prozess, in dem der Produktmanager oder der Kunde den Produktbestand verwaltet, indem er Feedback von agilen Teams erhält. Bei diesem Prozess werden die Portfolioelemente priorisiert, in kleinere Elemente aufgeteilt, für zukünftige Iterationen geplant, neue Storys erstellt, Akzeptanzkriterien aktualisiert oder Akzeptanzkriterien im Detail ausgearbeitet.

Kapazität

Dies ist die Menge an Arbeit, die ein Team in einer Iteration erledigen kann.

Feature

Eine Verbesserung an einem Produkt oder eine Fähigkeit, die für den Stakeholder von Nutzen ist und in einer Version entwickelt werden kann.

Wiederholung

Ein themenbasiertes Arbeitselement, das innerhalb eines Zeitrahmens abgeschlossen und mit der Veröffentlichung eines Produkts akzeptiert werden kann. Die Iterationsarbeit wird während der Iterationsplanung definiert und endet mit dem Demo-Meeting und dem Review-Meeting. Es wird auch als Sprint bezeichnet.

Zuwachs

Ein Inkrement ist der sich ändernde Zustand eines Produkts, wenn es schrittweise weiterentwickelt wird. Es wird normalerweise durch Meilensteine oder die Anzahl festgelegter Iterationen dargestellt.

Product Owner

Der Product Owner ist Mitglied des Agile Delivery-Teams, das für die Erfassung und Rangfolge der Geschäftsanforderungen im Product Backlog verantwortlich ist. Ein Product Owner teilt mit, was in einem Release / einer Iteration zu tun ist. Er legt die Verpflichtungen fest und ist dafür verantwortlich, das Team während einer Iteration vor Änderungen der Anforderungen zu schützen.

Produktrückstand

Reihe von funktionalen und nicht funktionalen Produktanforderungen.

Product Backlog Items

Dies können User Stories, Defekte oder Features sein, die vom agilen Team entwickelt werden sollen.

Punkte

Eine allgemeine Einheit zum Festlegen der relativen Größe von User Storys, Features oder anderen Portfolioelementen.

Freisetzung

Ein Zeitfenster, in dem die Arbeit erledigt wird, um die Bereitstellung eines testbaren Inkrements für eine Software zu unterstützen. In Scrum besteht ein Release aus mehreren Iterationen.

Anforderung

Eine Spezifikation eines Softwareprodukts, um einen festgelegten Vertrag oder eine bestimmte Funktionalität zu erfüllen. User Stories und Portfolioelemente sind Arten von Anforderungen.

Story-Punkte

Eine Einheit, die vom agilen Team zum Schätzen der relativen Größe von User Stories und Features verwendet wird.

Sprint

Gleich wie Iteration.

Zeitkasten

Eine feste Zeitdauer, in der ein Liefergegenstand entwickelt werden soll. Normalerweise wird neben dem Anfangs- und Enddatum einer Timebox auch die Anzahl der Ressourcen festgelegt.

Aufgabe

Es ist eine Arbeitseinheit, die zur Vervollständigung einer User Story innerhalb einer Iteration beiträgt. User Stories werden in mehrere Aufgaben zerlegt und jede Aufgabe kann auf Teammitglieder aufgeteilt werden, die sie als Eigentümer der Aufgaben kennzeichnen. Die Teammitglieder können die Verantwortung für jede Aufgabe übernehmen, Schätzungen aktualisieren, erledigte oder zu erledigende Aufgaben protokollieren.

Benutzer Geschichte

Ein aufgelistetes Akzeptanzkriterium, um bestimmte Anforderungen eines Nutzers zu erfüllen. Es wird normalerweise aus der Perspektive eines Endbenutzers geschrieben.

Geschwindigkeit

Ein Maß zum Gewichten der akzeptierten Arbeit in einer Iteration oder Timebox. Normalerweise ist es die Summe der Story-Punkte, die in einer Iteration akzeptiert werden.