Agile Teams

Wir glauben, dass es eine bessere Art gibt, wie Teams arbeiten können. Aus diesem Grund haben wir eine Suite leistungsstarker Jira-Apps entwickelt. In diesem Beitrag werden wir mehr darüber erzählen Einfache agile Personas, Einfacher agiler Teamrhythmus (ehemals User Story Maps), Einfache agile Roadmaps, und Einfache agile Programme. Wir besprechen die Verwendung dieser Tools sowie die wichtigsten Funktionen, die Ihrem Team helfen werden.

Ein Schlüsselprinzip für agiles Arbeiten ist Flexibilität. Es wirft starre Pläne über den Haufen und setzt stattdessen auf einen iterativen Prozess, der sich mit den Bedürfnissen des Kunden weiterentwickelt.

Wir glauben an die Kraft der Agilität und unterstützen Teams mit Leidenschaft dabei, besser zusammenzuarbeiten. Für uns bedeutet das, mit einfachen Tools zu arbeiten, die flexibel, kollaborativ und kundenorientiert sind. Aus diesem Grund behalten Easy Agile-Apps für Jira den Kunden immer im Mittelpunkt. Schauen wir uns die Plugins genauer an, die die Art und Weise, wie dein Team in Jira arbeitet, verbessern werden.

Produktentwicklung mit Atlassian Jira Software

Bei den Cloud-Lösungen von Jira steht der Kunde im Mittelpunkt der Produktgestaltung. Und Atlassian-Produkte werden häufig von Softwareentwicklungsteams verwendet.

Wenn du in einem agilen Team bist oder deine agilen Fähigkeiten ausbauen möchtest, ist Jira Software von Atlassian ein wichtiges grundlegendes Tool.

Mit Jira kannst du:

• Erstellen Sie Jira-Workflows, um kundenorientierte Produkte zu planen, zu verfolgen und zu veröffentlichen
• Wählen Sie zwischen mehreren Frameworks, einschließlich Kanban, Scrum oder beidem
• Verwalte Backlogs mit vollständiger Transparenz
• Verwenden Sie strukturierte Funktionen, die speziell für die Sprint-Planung entwickelt wurden
• Suche nach Problemen und Jira-Instanzen mit JQL, Jira-Abfragesprache
• Verbessern Sie die Leistung auf der Grundlage von Echtzeitdaten
• Reduzieren Sie physische Abhängigkeiten, indem Sie Ihre agilen Lösungen online verlagern

Einfache Agile Apps für Jira

Jira ist eine fantastische Plattform mit unzähligen Funktionen, die agile Teams gut nutzen können, aber sie bietet möglicherweise nicht die beste Lösung für Ihren speziellen Anwendungsfall. Für spezifische Lösungen, wie z. B. integrierte Kundenpersonas oder ein Tool für PI Planning, benötigst du eine Jira-App aus dem Atlassian Marketplace, wie die Easy Agile-Tools, die wir gleich behandeln werden.

Einfache Agile Personas für Jira

Kunde Personas helfen Sie Entwicklungsteams dabei, sich auf einen kundenorientierten Ansatz zu konzentrieren. Sie graben tief ein, um genau zu verstehen, was Kunden brauchen und wollen, damit Softwareentwicklungsteams diese Wünsche erfüllen können.

Kundenpersönlichkeiten sind entscheidend, um zu verstehen, wie man Kunden einen konsistenten Mehrwert bietet. Sie beantworten Fragen zu Kundenproblemen, Verhaltensmustern, Zielen, demografischen Merkmalen, Kaufgewohnheiten und vielem mehr. Effektive Personas Gehen Sie wirklich auf den Punkt, was Kunden bewegt, sodass jede Softwareentwicklungsentscheidung auf den tatsächlichen Menschen basiert, die das Produkt verwenden.

Einfache Agile Personas für Jira ist darauf ausgelegt, kundenorientiertes Arbeiten zu ermöglichen. Es hilft Teams, sich in die Kunden hineinzuversetzen, sodass sie Entwicklungsentscheidungen auf der Grundlage dessen treffen können, was den Benutzern den größten Mehrwert bietet.

Unser Persona-Tool lässt sich direkt in deine aktuellen Jira-Projekte integrieren. Du kannst Kundenpersonas erstellen und speichern, um ein reibungsloses Erlebnis zu gewährleisten, bei dem die Kundenbedürfnisse bei jedem Schritt im Vordergrund stehen.

Sehen Sie sich eine Demo auf Abruf an um mehr zu erfahren. Und haben wir schon erwähnt, dass unsere Persona-Vorlage so konzipiert ist, dass sie mit Easy Agile TeamRhythm funktioniert? Du kannst füge Personas direkt zu deiner TeamRhythm User Story Map hinzu. Unsere agilen Plugins sind so konzipiert, dass sie besser zusammenarbeiten.

Einfacher agiler Teamrhythmus

Backlogs sind voller Potenzial, aber wenn Sie mehr als ein paar Artikel auf Ihrer Liste haben, ein flacher Rückstand kann schnell überwältigend werden. Womit fängst du zuerst an? Was passt in das Gesamtbild? Und was wird Ihren Kunden den größten Mehrwert bieten?

Flache Landkarten sind fad, kontextlos und bieten keinen Einblick in die Kundenreise. Es ist, als würdest du ein originales Nintendo-Spiel auswählen, wenn du ein VR-Headset zur Verfügung hast. Nett für Nostalgie, aber nicht für die Herstellung herausragender Produkte.

Rufen Sie die TeamRhythm User Story Map auf.

Unser Mitbegründer Nicolas Muldoon beschreibt User Story Mapping als „eine moderierte, kuratierte Konversation, die alle mit auf die Reise nimmt“.

Das User Story Mapping ist eine effektive Methode, um Ihre User Stories zu organisieren und zu priorisieren, um Ihre Arbeit zu planen und Releases zu entwerfen. Es hilft Teams bei der Visualisierung Der Weg des Kunden durch die Entwicklung Ihres Produkts von Anfang bis Ende, einschließlich aller Aufgaben, die auf dem Weg dorthin zu erledigen sind.

Eine User Story ist ein Ziel oder Ergebnis, das der Nutzer oder Kunde erreichen möchte. Es ist die kleinste Arbeitseinheit, die in der Lage ist, dem Kunden einen Mehrwert zurückzugeben.

Hier ist ein Beispiel dafür, wie eine User Story typischerweise geschrieben wird: „Als [Personatyp] möchte ich [handeln], damit [davon] [profitiert].“

Es ist die Geschichte Ihres Benutzers, also schreiben Sie es am besten aus seiner Perspektive. Jede User Story wird dann zu deinem Backlog hinzugefügt, wo sie auf einer User Story Map angeordnet und priorisiert werden kann, je nach deinem geplanten Release oder Sprint. Lesen Sie unsere ultimativer Leitfaden für User Story Maps um loszulegen.

Einfacher agiler Teamrhythmus ist ein Add-on, das Teams dabei helfen soll, Kunden schnell und häufig einen Mehrwert zu bieten. Verwalte und gliedere Epen innerhalb der Storymap auf, plane zentrale Benutzeraktivitäten, ordne Storys nach Priorität, bearbeite Story-Zusammenfassungen und mehr — und das alles während du dich nahtlos in deine agilen Boards in Jira integrierst.

Es ist an der Zeit, Ihren flachen Produktbestand in eine wirkungsvolle und visuelle Darstellung der Kundenreise umzuwandeln. Folgen Sie unseren Einfacher agiler Teamrhythmus um zu sehen, woran wir gerade arbeiten und welche Funktionen als Nächstes hinzukommen.

Jira-Plugin für einfache agile Programme

Program Increment (PI) Planning beinhaltet eine intensive, zielgerichtete Planung, um zu bestimmen, was wann und wie alles miteinander verbunden sein muss. Hier können Produktmanager den Backlog überprüfen, mit den Stakeholdern kommunizieren und letztendlich entscheiden, welche nächsten Schritte den größten Nutzen bringen.

Das Problem ist, dass diese Planungssitzungen ziemlich kompliziert werden können und es schwierig ist, alles auf einem physischen Program Board nachzuverfolgen. Agile Online-Tools helfen Teams dabei, Informationen zu konsolidieren, damit sie das Gesamtbild sehen können. Sie verhindern Informationsverluste, Fehlinformationen, schlechtes Testmanagement, doppelte Bearbeitung und Unzugänglichkeit, während gleichzeitig das Visuelle erhalten bleibt Prozess der PI-Planung.

Einfache Agile-Programme für Jira ist die komplette PI Planning-Lösung für agile Teams. Es ist der effektivste Weg, Programme in Jira zu visualisieren. Behalte alle Teile, die du möchtest, von deiner physischen Programmplatine entfernt, während du gleichzeitig die Automatisierung vorantreibst und die überwältigenden Schichten von Haftnotizen und Verbindern los wirst. Außerdem können Sie mit einem Online-Tool als Team aus der Ferne arbeiten, während Sie PI Planning durchführen.

Sie können Ihr Program Increment mit digitalen Karten planen, die alle Zeichenketten enthalten, die Sie zur Lösung komplexer Probleme benötigen. Unsere App stellt eine Verbindung zu Jira-Dashboards her, um dir zu helfen, Programme nahtlos zu verwalten, Prioritäten zu konfigurieren und die Sichtbarkeit zu optimieren. Mit einer Jira PI Planning-App erhältst du einen besseren Kontext, eine optimierter Arbeitsablauf, verstärkte Zusammenarbeit und verbesserte Transparenz.

Sehen Sie sich unsere Demoversion an und folge unseren Roadmap für einfache agile Programme für die neuesten Produktupdates.

Einfaches Jira-Plugin für Agile Roadmaps

Produkt-Roadmaps sind ein agiles Grundnahrungsmittel. Sie bieten einen iterativen und kollaborativen Prozess, sodass das Softwareentwicklungsteam Kunden und Stakeholdern kontinuierlich einen Mehrwert bieten kann.

Im Gegensatz zu statisch Gantt-Diagramme Oder Excel-Tabellen, Roadmaps sind flüssig und vielseitig. Sie sind ein lebendiges Dokument, das die Hoffnungen des Teams zu einem bestimmten Zeitpunkt wiedergibt, basierend auf den aktuellen Bedürfnissen des Kunden. So wie sich die Bedürfnisse und Anforderungen weiterentwickeln, ändert sich auch die Roadmap.

Einfache Agile Roadmaps für Jira helfen Sie Teams dabei, sich auf eine Produktvision auszurichten, um die wichtigsten Funktionen für die Auslieferung an den Kunden zu ordnen. Unsere Roadmaps ermöglichen es Teams, Themen für Unteraufgaben, Datumsmarkierungen und benutzerdefinierte Felder hinzuzufügen, geplante Arbeiten aufzuteilen, den Fortschritt zu verfolgen und jede Roadmap zu exportieren, um sie mit allen Beteiligten zu teilen.

Es ist intuitiv und einfach für alle in Ihrem Team zu verwenden, von Produktmanagern über Entwickler bis hin zu Stakeholdern. Easy Agile Roadmaps lassen sich nahtlos mit deiner Jira-Instanz verbinden, um Jira-Probleme direkt vom Issues-Panel aus zu planen. Es ist das einfachste und flexibelste Roadmapping-Tool für Jira mit Drag-and-Drop-Funktionalität mit einem Klick und einer supersauberen Benutzererfahrung.

Sie werden es lieben, Ihren Prozess zu visualisieren, und Sie werden es lieben, wie einfach der Einstieg ist. Lernen Sie wie man eine Jira-Roadmap erstellt mit Easy Agile Roadmaps oder eine Demo ansehen für weitere Informationen.

Testen Sie jedes Easy Agile Jira-Plugin 30 Tage lang kostenlos

Jedes unserer Easy Agile Jira-Plugins ist 30 Tage lang kostenlos erhältlich, sodass Sie es unverbindlich nutzen können. Wenn Sie Fragen haben, zögern Sie nicht kontaktiere unser Team.

Was ist eine Kundenpersona?

Customer Personas sind fiktive Verallgemeinerungen Ihrer wertvollsten Kunden.

Sie helfen Teams dabei, ihre Kunden zu verstehen, indem sie demografische Informationen wie Alter, Geschlecht, Standort und Einkommen sowie psychografische Informationen wie Interessen, Frustrationen und persönliche oder berufliche Beweggründe zusammenführen.

Was sind User Personas?

Auf den ersten Blick mag es trivial erscheinen, als Team zusammenzukommen und scheinbar gefälschte Dating-Profile für Ihre wichtigsten Kunden zu erstellen.

Diese Übung bildet jedoch die Grundlage für andere agile Praktiken in der weiteren Entwicklung, und ihre Vorteile werden oft unterschätzt.

Agile-Experten haben mehr funktionsübergreifende Teams gefordert, was bedeutet, dass dieses Wissen darüber, wer der Kunde ist, nicht mehr in der alleinigen Verantwortung Ihres Vertriebs- und Marketingteams liegt. Jeder ist dafür verantwortlich, zu verstehen, wer der Kunde ist.

Teams, die ein gemeinsames Verständnis haben und sich darüber einig sind, wer die von ihnen bereitgestellte Lösung tatsächlich nutzt, haben eine höhere Erfolgswahrscheinlichkeit.

Der Aufbau von Kundenpersönlichkeiten hilft Teams dabei, die folgenden Fragen zu beantworten:

• Wer sind unsere Kunden?
• Was sind ihre gemeinsamen Verhaltensmuster?
• Was sind ihre gemeinsamen Probleme (beruflich und persönlich)?
• Was sind ihre Ziele und Vorgaben?
• Welche allgemeinen demografischen und psychografischen Informationen können ihre Entscheidungen beeinflussen?
• Was treibt sie dazu, Kaufentscheidungen zu treffen?
• Ist der Kunde der Käufer oder der Entscheidungsträger?
  

Sie können zwei Schritte unternehmen, um diese Fragen zu beantworten und herauszufinden, wer Ihre Kundenpersönlichkeiten sind:

Definieren Sie zunächst Ihre Personas im Großen und Ganzen

Es ist nicht verrückt zu glauben, dass die meisten Unternehmen eine umfassende Vorstellung davon haben werden, wer zumindest einige ihrer Kundenpersönlichkeiten sind. Dieses Wissen wird im Laufe der Zeit gesammelt und basiert auf Kundenfeedback, Supportanfragen, Gesprächen/Interviews und ersten Marktforschungen.

Dieses Wissen darf nicht unterschätzt werden und ist ein guter Ausgangspunkt, bevor Sie sich mit Analysen befassen, um diese Personas in spezifischeren Details zu konkretisieren.

Zweitens sollten Sie auf Erkenntnisse und Analysen achten

Sobald Sie sich ein paar Kundenpersönlichkeiten ausgedacht haben, ist es an der Zeit, sie mit qualitativen und quantitativen Daten zu konkretisieren.

Also, wo können wir diese Informationen finden?

Schau dir Quellen an wie:

• Webseiten-Analytik
• Einblicke in Facebook
• Kundenbefragungen und Umfragen
• Branchenberichte
• Kundeninterviews oder
• Produktinterne Analytik

Nachdem Sie all diese Informationen durchgesehen haben, können Sie die Daten Ihren ursprünglichen Annahmen zuordnen.

Am Ende der Übung sollten Sie und Ihr Team eine ziemlich gute Vorstellung davon haben, wer Ihre Kunden sind und wie Sie sie am besten betreuen, mit ihnen kommunizieren und Lösungen für sie entwickeln können.

Kundenpersonas in Jira

Sobald diese Personas entwickelt wurden, besteht die Herausforderung darin, zu entscheiden, wo sie gespeichert werden sollen.

Wenn Sie die Personas gut sichtbar machen, sollten Sie Ihr Team dazu ermutigen, sie jedes Mal in Betracht zu ziehen, wenn neue Arbeit in den Backlog aufgenommen wird. Sie möchten, dass sie denken: „Was würde Sam, der Systemadministrator, von dieser neuen Funktion halten? Würde sie es benutzen? Wie würde sie ihrem Team die Vorteile vermitteln? Auf welche Probleme kann Sam beim ersten Gebrauch stoßen?“

Deshalb haben wir eine App für Jira entwickelt — Easy Agile Personas.

Easy Agile Personas ermöglicht es dir, deine User Personas parallel zu deiner Arbeit in Jira zu erstellen und zu verwalten, sodass das gesamte Team den Kunden im Auge behalten kann.

Unabhängig davon, ob Sie sich für Easy Agile Personas entscheiden oder nicht, die von Ihnen entwickelten Kundenpersonas sind für die Erstellung von User Story Maps von entscheidender Bedeutung.

Probiere es jetzt

Manchmal scheint die Idee, User Stories zu schreiben, eine weitere „Sache“ zu sein, die zu einer ohnehin schon vollen Arbeitsbelastung hinzukommt. Aber für Softwareentwicklungsteams, die ihre eigenen Verbesserungen selbst vorantreiben und Software liefern wollen, die für ihre Kunden funktioniert, ist das Schreiben effektiver User Stories der erste Schritt.

Wenn Sie diesen Beitrag lesen, bedeutet das, dass Sie herausfinden möchten, was für die Menschen, die Ihre Software verwenden, am besten funktioniert, und Ihre Herangehensweise an die Softwareentwicklung verbessern möchten. Das ist großartig! Unser Ziel bei Easy Agile ist es, Ihnen dabei zu helfen.

Beginnen wir also damit, warum gute User Stories wichtig sind.

Warum User Stories schreiben?

Sie fragen sich vielleicht, warum Sie User Stories schreiben sollten, anstatt stattdessen Funktionen oder Aufgaben zu schreiben.

Wenn das nach Ihnen klingt, haben Sie vielleicht noch nicht erkannt, wie wichtig es ist, User Stories zu schreiben, und dass sie einem ganz anderen Zweck dienen als das Schreiben von Funktionen oder Aufgaben.

Es ist leicht, sich in einem Zyklus der Feature-Entwicklung zu verlieren, dem es an Kontext mangelt. Das Ziel besteht mehr darin, sich den Weg durch einen großen Backlog freizumachen, als Lösungen zu entwickeln, die Ihren Kunden einen Mehrwert bieten. Um erfolgreiche Software zu entwickeln, müssen Sie sich auf die Bedürfnisse der Menschen konzentrieren, die sie verwenden werden. Ihre menschlichen Kunden. Nutzerberichte bringen diesen Kontext und diese Perspektive in den Entwicklungszyklus ein.

Was ist eine User Story?

Eine User Story hilft agilen Softwareentwicklungsteams, sich in ihre Kunden hineinzuversetzen. Aus der Sicht des Kunden (oder Benutzers) geschrieben, helfen User Stories dem Entwicklungsteam zu verstehen, was es entwickeln muss und warum es es erstellen muss.

User Stories sind vereinfachte, allgemeine Beschreibungen der Anforderungen eines Benutzers, die aus der Sicht des Endbenutzers verfasst wurden. Eine User Story ist kein kontextloses Feature, das in der Sprache der Entwickler geschrieben ist.

Eine User Story = das „Was“

Eine User Story beschreibt eine Funktion aus der Sicht des Benutzers.

User Stories unterteilen Funktionen in Geschäftsprozesse.

Eine Aufgabe = das „Wie“

Aufgaben sind die Aktivitäten, die ausgeführt werden müssen, um ein Ergebnis zu erzielen.

Aufgaben sind einzelne Arbeiten.

Wie schreiben wir User Stories?

Vielleicht möchten Sie sich eine User Story als „Gleichung“ vorstellen:

Als [Benutzer] + möchte ich [Absicht] +, damit [Wert]

Lassen Sie uns das weiter aufschlüsseln;

Als [Benutzer] — das ist die WHO. Für wen bauen wir das? Wer ist der Nutzer?

Ich will [Absicht] — das ist das WAS. Was bauen wir? Was ist die Absicht?

Also das [Wert] — das ist das WARUM. Warum bauen wir es? Was ist der Wert für den Kunden?

Schauen wir uns ein paar einfache Beispiele an;

Als Internetbanking-Kunde

ich will um einen fortlaufenden Saldo für meine täglichen Konten zu sehen

Also das Ich kann nach jeder Transaktion den Überblick über meine Ausgaben behalten

ODER

Als Administrator

ich will um andere Administratoren für bestimmte Projekte erstellen zu können

Also das Ich kann Aufgaben effizienter delegieren

Gemäß dieser Gleichung sollten Teams sicherstellen, dass ihre User Stories alle der folgenden Checkboxen ankreuzen:

Um erfolgreiche User Stories zu schreiben:

• Halte sie kurz
• Halte sie einfach
• Schreiben Sie aus der Sicht des Benutzers
• Machen Sie den Wert oder Nutzen der Geschichte deutlich
• Beschreiben Sie eine Funktion
• Schreiben Sie im Team User Stories
• Verwenden Sie Akzeptanzkriterien, um einen MVP anzuzeigen.

Akzeptanzkriterien

User Stories ermöglichen es agilen Teams, die Bedürfnisse, Wünsche und Werte ihrer Kunden mit den Aktivitäten in Einklang zu bringen, die sie durchführen müssen, um diesen Mehrwert zu bieten.

Der Link, der diese beiden Dinge miteinander verbindet, sind Akzeptanzkriterien.

Die Akzeptanzkriterien oder „Erfüllungsbedingungen“ geben einen detaillierten Überblick über die Benutzeranforderungen. Sie helfen dem Team, den Wert der User Story zu verstehen und helfen dem Team zu wissen, wann es erwägen kann, etwas zu tun.

Ziele der Akzeptanzkriterien

Die Akzeptanzkriterien sollten:

• klären Sie, was das Team bauen soll, bevor es mit der Arbeit beginnt
• Sicherstellung eines gemeinsamen Verständnisses des Problems oder der Bedürfnisse des Kunden
• Helfen Sie den Teammitgliedern, zu wissen, wann die Geschichte abgeschlossen ist
• helfen Sie dabei, die Geschichte durch automatisierte Tests zu überprüfen.

Schauen wir uns ein Beispiel für eine abgeschlossene User Story mit Akzeptanzkriterien an:

Als potenzieller Konferenzteilnehmer möchte ich mich online für die Konferenz anmelden können, sodass die Registrierung einfach und papierlos ist.

Akzeptanzkriterien:

• Teilnahmeformular für die Konferenz
• Ein Benutzer kann kein Formular einreichen, ohne alle Pflichtfelder auszufüllen (Vorname, Nachname, Firmenname, E-Mail-Adresse, Position, Rechnungsinformationen)
• Informationen aus dem Formular werden in der Registrierungsdatenbank gespeichert.
• Der Schutz vor Spam funktioniert
• Die Zahlung kann per Paypal, Lastschrift oder Kreditkarte erfolgen
• Nach dem Absenden des Formulars wird dem Teilnehmer eine Bestätigungs-E-Mail gesendet

Vor diesem Hintergrund sollten die Teams sicherstellen, dass ihre Akzeptanzkriterien alle folgenden Punkte berücksichtigen:

• Negative Szenarien der Funktionalität
• Funktionale und nicht funktionale Anwendungsfälle
• Leistungsbedenken und Richtlinien
• Was das System oder die Funktion zu tun beabsichtigt
• durch/Benutzerfluss
• Der Einfluss einer User Story auf andere Funktionen
• UX-Bedenken

Die Akzeptanzkriterien sollten NICHT Folgendes beinhalten:

• Die Codeüberprüfung wurde durchgeführt
• Nichtblocker oder größere Probleme
• Leistungstests durchgeführt
• Abnahme und Funktionstest abgeschlossen
  

Warum?

Ihre Akzeptanzkriterien sollten keines der oben genannten Punkte enthalten, da Ihr Team bereits ein klares Verständnis davon haben sollte, was Ihre Definition of Done (DoD) beinhaltet, zum Beispiel:

• Einheit/integriertes Testen
• bereit für den Abnahmetest
• auf dem Demoserver bereitgestellt
• lösbar

Das Schreiben effektiver User Stories ist eine wertvolle Praxis, die Ihnen und Ihrem Team dabei hilft, Software bereitzustellen, die für Ihre Kunden relevant bleibt.

Wenn Sie User Stories als mehr als nur eine weitere Aufgabe auf Ihrer Checkliste betrachten, sondern sie stattdessen als unverzichtbares Instrument betrachten, um Kontext und Wert für Ihre Projekte zu schaffen, können Sie mit Ihrem wichtigsten Fokus in Verbindung bleiben — Ihrem Kunden.

Verwandeln Sie Ihr Backlog in ein aussagekräftiges Bild der Arbeit, um Kontext für die Sprint- und Versionsplanung, die Backlog-Verfeinerung und das User Story Mapping zu erhalten.

Konzentrieren Sie sich auf Ihre Kunden

Einfacher agiler Teamrhythmus

Die Erstellung einer Produkt-Roadmap in Jira kann einige wirklich wichtige Rollen erfüllen.

1. Es kann eine Vision für ein agiles Team entwickeln, das um Dynamik kämpft.
2. Es kann dem breiteren Unternehmen mitteilen, woran Sie in zukünftigen Iterationen oder Sprints arbeiten möchten.
3. Es kann dem Produktmanager helfen, Abhängigkeiten zwischen Problemen visuell aufzuzeichnen.

Bonus: Wenn du eine Jira-Roadmap erstellst, musst du die Roadmap, die du in Google Sheets oder PowerPoint erstellt hast, nicht ausfindig machen (oder habe ich sie als Tabelle in Confluence erstellt?) 🤷

Sortiert. Verkauft. Zeig mir wie!

Ok — so kannst du mithilfe von Easy Agile Roadmaps eine kostenlose Roadmap in Jira erstellen:

Schritt 1. Gehe zum Atlassian Marketplace

Hüpf rüber zum Atlassian Marketplace-Seite für Easy Agile Roadmaps.

Schritt 2. Starten und installieren Sie die kostenlose 30-Tage-Testversion

Klicken Sie auf die gelbe Schaltfläche „Jetzt testen“, um Ihre kostenlose 30-Tage-Testversion zu starten. Das bedeutet, dass Sie eine vollständige Roadmap erstellen und Ihr Team beeindrucken können, bevor Sie entscheiden, ob es das Richtige für Sie ist.

Du benötigst Administratorrechte auf deinem Jira, um eine kostenlose Testversion zu starten. Oder kaufe Kaffee für jemanden, der das tut.

Wähle zwischen Cloud, Server oder Rechenzentrum (je nachdem, welchen Jira-Hosting-Typ dein Unternehmen verwendet).

Schritt 3. Öffnen Sie die Roadmap

Sobald Easy Agile Roadmaps installiert ist, verfügt jedes Scrum- und Kanban-Board in Jira über eine verknüpfte Roadmap.

Um es zu öffnen, suche in der Projekt-Seitenleiste nach dem Roadmaps-Symbol für alle agilen Boards auf Jira Server und für agile Boards für einzelne Projekte in Jira Cloud.

Wenn du in Jira Cloud auf einem agilen Board mit mehreren Projekten arbeitest, findest du den Link zur Roadmap im Drop-down-Menü „...“ oben rechts auf deinem Agile-Board-Bildschirm.

Schritt 4. Füge dein erstes Objekt zur Jira-Roadmap hinzu

Ihre leere Roadmap sollte Sie jetzt anstarren. ✅

Sie können der Roadmap eines Teams jeden Problemtyp hinzufügen. Um vom Agile-Board eines Teams aus auf die Probleme zuzugreifen, wähle oben rechts auf der Roadmap die blaue Schaltfläche mit der Aufschrift „Issues“ oder „Epics“ aus.

Wählen Sie das Drop-down-Menü „Optionen“, um die Problemtypen auszuwählen, die in Ihrem Roadmap-Backlog erscheinen sollen.

Ziehen Sie dann per Drag & Drop auf die Roadmap. Sie können das Start- und Enddatum sowie die Phasen der einzelnen Ausgaben anpassen, indem Sie das linke oder rechte Ende der farbigen Felder ziehen.

Wenn du deine Roadmap an jemanden senden möchtest, der Jira nicht verwendet, kannst du sie als PDF exportieren.

Herzlichen Glückwunsch! Du hast gerade eine Produkt-Roadmap in Jira erstellt. Jetzt kannst du sie deinem Team zeigen und deine Excel-Roadmaps FÜR IMMER löschen.

Easy Agile Roadmaps bietet eine Menge weiterer Funktionen, wie Themes, Versionsmarkierungen und Datumsmarkierungen.

Wir werden das in einem zukünftigen Beitrag behandeln. Sie können all dies in der ausprobieren kostenlose 30-Tage-Testversion.

Aber genießen Sie vorerst die Pracht Ihrer neuen Roadmap.

Lehnen Sie sich zurück und bestaunen Sie, was Sie geschaffen haben. Du hast es verdient.

Testen Sie Roadmapping noch heute mit Einfache Agile Roadmaps für Jira

👉 👉 Weiter lesen: Prinzipien einer agilen Produkt-Roadmap

Heb deine Hand, falls du jemals einen Streit hattest, hoppla 😳 — ich meine eine hitzige Diskussion — darüber, wie Jira eingerichtet und organisiert werden kann. Ja, wir auch.

Zu den heiß umkämpften Themen gehören:

• Projekt: Ist es am besten, nach Team, Funktion, Funktion oder Produkt zu organisieren?
• Agile Epen, Features, Stories, Aufgaben, Unteraufgaben, Bugs — was solltest du wann verwenden?
• Spaltenüberschriften und Swimlanes im Sprint-Board — da gehen wir gar nicht hin.

Leider gibt es in Jira oder einem anderen Tool, das dein Agile-Team verwendet, nicht den besten Workflow. Wichtiger als dein Workflow ist es, deine Teammitglieder so einzurichten, dass sie deinen Endbenutzern einen konsistenten Geschäftswert bieten. Das Ziel Ihres agilen Projektmanagements ist es, Ihr Scrum-Team bei diesem Unterfangen zu befähigen und zu unterstützen.

Wir werden uns einen Aspekt Ihres Prozesses ansehen — anhand der Epics, die agile Teams verwenden. Bleiben Sie bei uns und wir erklären, was ein Epos ist, warum agile Epen wichtig sind und wie Sie einige epische Fehler vermeiden können.

Was ist ein Epos?

Einfach ausgedrückt ist ein Epos ein Eimer, der kleinere Arbeitsaufgaben enthält, die erledigt werden müssen, um die Aufgabe zu erfüllen. Manche Leute betrachten Epics als eine große Nutzerstory. Das ist in Ordnung, wenn es dir hilft, es zu visualisieren, aber Epen unterscheiden sich stark von Geschichten.

• Agile Teams verwenden Epics für die Planung unterschiedlich oder gar nicht.
  Dein Team kann ihm zwar eine T-Shirt-Größe geben, aber der Arbeitsaufwand in einem Epos ist normalerweise zu groß, um ihn in Storypoints abzuschätzen. Manche Epen sind so umfangreich, dass sie in kleinere Epen aufgeteilt werden müssen, bevor du überhaupt nach Schätzungen für das Team fragst.
• Ein Epos ist nicht wie eine User Story geschrieben.
  Sie kennen die Vorlage — „Als Benutzer möchte ich X, damit ich Y kann.“ Das ist perfekt für eine User Story, aber nicht so sehr für ein Epos. Ein episches Beispiel könnte „Cross-Sells hinzufügen“ mit einer Beschreibung sein, die Orte auflistet, an denen der Product Owner dem Endverbraucher Gelegenheiten zum Kauf verwandter Produkte bieten möchte. Das ist keine Geschichte, sondern eine Bitte um Funktionalität.
• Das Epos könnte als Platzhalter für Arbeiten dienen, die noch definiert werden müssen.
  Ihr Product Owner kann Epics als Platzhalter in einer Produkt-Roadmap für die langfristige Planung verwenden. Sie werden mit der Definition der Arbeit warten, bis der Zeitrahmen für die Implementierung näher rückt.
• Ein Epos wird selten in einem einzigen Sprint abgeschlossen.
  Aufgrund ihrer Größe passen Epen normalerweise nicht in eine Iteration. Ihr Softwareentwicklungsteam teilt die Funktionalität so auf, dass es in jedem Sprint funktionierende Software liefern kann. Das kann bedeuten, dass sie zwei Sprints lang eine oder zwei Geschichten aus einem Epos fertigstellen, einen Sprint überspringen und dann im nächsten Sprint zu den Geschichten in diesem Epos zurückkehren.
• Epics können Akzeptanzkriterien haben oder nicht.
  In einigen Scrum-Teams müssen Epics keine Akzeptanzkriterien haben, da diese in den Geschichten enthalten sind. Wenn alle Kindergeschichten dem entsprechen, was das Scrum als Definition von Erledigt definiert, ist das Epos auch erledigt.

Epen sind Eltern und Großeltern von Geschichten und Aufgaben. Entwicklungsteams arbeiten nicht an Epics, sondern programmieren eher für die kleineren User Stories unter dem Epos.

Die Bedeutung von Epics in Ihrer agilen Praxis

Unterschätzen Sie nicht den organisatorischen Wert, den Epen für Ihr Produkt-Backlog haben. Das Korrigieren von 10 oder 20 verwandten Backlog-Elementen kann die Sprint-Planung stören. Epics bieten einen kohärenteren Blick auf die Arbeit und ermöglichen es Ihrem Scrum-Team, das Gesamtbild zu sehen.

Epics bieten Führungskräften und Produktmanagern einen umfassenden Überblick über laufende Arbeiten und zukünftige Entwicklungen.

Product Owner verwenden Epics, um einen Produktplan aus geschäftlicher Sicht zu erstellen. Aktuelle Geschäftsziele können vorschreiben, dass sich die Entwicklungsarbeit auf ein bestimmtes Merkmal konzentriert, das durch Epics repräsentiert wird. Im Gegensatz dazu helfen Epics Product Ownern auch dabei, Sprints mit einem angemessenen Arbeitsverhältnis aus mehreren Epics zu planen. Product Owner können einen Schritt von den detaillierten Nutzerberichten Abstand nehmen und sicherstellen, dass jede Iteration Geschichten aus mehreren Epen enthält, um mehrere Stakeholder zufrieden zu stellen.

Die Art und Weise, wie Epics in Produkt-Backlogs und Roadmaps visuell dargestellt werden, ist für die langfristige Planung von entscheidender Bedeutung. Können Sie sich vorstellen, eine sechsmonatige Roadmap auf User-Story-Ebene zu planen? Es wäre Chaos!

Agile Frameworks fördern — nein — fordern die Fähigkeit, den Kurs nach Bedarf anzupassen, um den sich ändernden Bedürfnissen der Interessengruppen, Marktanforderungen und Geschäftsziele gerecht zu werden. Mit Epics können Sie Ihre Roadmaps einfach und schnell an Veränderungen anpassen.

Wie Epics der agilen Entwicklung einen Mehrwert verleihen

Discovery ist ein wichtiger Aspekt agiler Methoden und des Produktmanagements. Zu Beginn dieses Prozesses werden Ihre Teams Events stürmen, Personas erstellen und Journey Maps erstellen. Die umsetzbaren Ergebnisse dieser Aktivitäten können in Jira mit Epics einfach protokolliert und organisiert werden.

Wenn diese Epen weiter verfeinert werden, werden sie einer Roadmap hinzugefügt und dann auf die Tagesordnung einer Verfeinerungszeremonie gesetzt. Während der Verfeinerung engagieren sich die Mitglieder des Scrum-Teams für Zuordnung von Benutzergeschichten Übungen und beginnen Sie mit der Erstellung der Details, die das Entwicklungsteam zur Ausführung benötigt.

Epics bieten zwar einen weniger detaillierten Überblick über Funktionen und Anfragen Ihres Product Owners, sind aber für die Erstellung von User Stories von entscheidender Bedeutung. Ohne den kohärenten Überblick über Ihren Sprint-Backlog, der mithilfe von Epics präsentiert wird, besteht bei agilen Sprints die Gefahr, dass eine Menge Arbeit geleistet wird, die nichts miteinander zu tun hat, aber nur einen geringen Mehrwert bietet.

Wann sollte man kein Epos benutzen

Wir lieben das Agile Epic, aber es ist nicht für alles perfekt. Hier sind einige Dinge, die Sie bei der Verwendung von Epics vermeiden sollten.

Das immergrüne Epos

Du kennst den einen. Das Epos entstand, als die Leute aufgehört haben, kabelgebundene Telefonleitungen zu benutzen, und es ist seither in einem halbfertigen Zustand in Ihrem Backlog hängen geblieben. Tief im Inneren findest du Geschichten und Aufgaben von Nutzern, die vielleicht kaum oder gar nichts miteinander zu tun haben. Dieses arme Epos ist zur Müllhalde für verwaiste Geschichten geworden, die nirgendwo anders ein Zuhause gefunden haben.

Immergrüne Epen können das Ergebnis einer Änderung der Geschäftsziele oder der Produktmerkmale sein. Das ist großartig — du hast dich angepasst! Jetzt musst du dein Epos aktualisieren, um das widerzuspiegeln. Geschichten können entfernt werden, Code kann bereitgestellt oder zurückgestellt werden, und unvollständige Geschichten können gelöscht oder aus dem Epos entfernt und neu priorisiert werden.

Brainstorming ist auch ein Grund für immergrüne Epen. Oben haben wir erwähnt, dass die Ergebnisse von UX-Aktivitäten eine großartige Möglichkeit sind, umsetzbare Elemente zu verwalten. Wir haben nicht gesagt, dass Sie Epics als Zuhause für jede Idee verwenden sollten, die während des Brainstormings auftaucht und die es vielleicht nie in Ihre Roadmap schaffen wird oder auch nicht.

Epen sind nicht dafür bestimmt, ewig zu leben. Sie stellen eine Reihe von Arbeiten dar, die Ihren Endbenutzern einen Mehrwert bieten. Sie müssen abgeschlossen sein, damit Sie die Ergebnisse Ihrer Bemühungen messen können. Immergrüne Epen überladen Ihre Roadmap, lassen Ihren Fokus verschwimmen und schränken deren Planungswert ein.

Das Themen-Epos

Es ist einfach, Geschichten Epen zuzuordnen, weil sie sich auf einen bestimmten Bereich im Produkt beziehen, eine bestimmte Codebasis berühren oder eine Einzelperson oder eine Gruppe von Stakeholdern zufrieden stellen. Das ist nicht der Zweck eines Epos. Themes eignen sich besser, um Arbeiten nach anderen Attributen als nach einer bestimmten Feature-Implementierung zu gruppieren.

Sie können Ihre Unternehmensziele erreichen, indem Sie Themen verwenden, um diese Geschichten miteinander zu verknüpfen und gleichzeitig die Integrität des Umfangs innerhalb Ihres Epos zu wahren.

Verwenden Sie Epics, um sich auf bestimmte Ergebnisse oder Funktionen zu konzentrieren. Verwandt oder nicht, wenn eine Geschichte innerhalb eines Epos nicht zum Hauptfokus des Epos beiträgt, entferne sie. Das heißt nicht, dass es nicht wichtig ist oder dass es nicht die richtige Arbeit ist, die während der Iteration erledigt werden muss. Das heißt nur, dass es nicht Teil dieses Epos ist.

Wenn Sie sorgfältig mit dem Umfang umgehen, sind Ihre Schätzungen übersichtlicher und für die zukünftige Planung nützlicher. Unnötige Geschichten in Epen übertreiben ihre Schätzungen und den tatsächlichen Aufwand. Wenn Sie einmal auf ältere Arbeitsaufgaben zurückblicken müssen, werden Sie sich wahrscheinlich nicht erinnern, dass das Hinzufügen von zwei Geschichten, die nichts miteinander zu tun haben, ein Epos von einem mittleren zu einem großen gemacht hat. Wenn Sie dieses alte Arbeitselement als Leitfaden für die zukünftige Planung verwenden, haben Sie den Aufwand einfach überschätzt, weil Sie den Umfang nicht auf das Ziel des Epos beschränkt haben.

Denken Sie daran — nicht jede Geschichte braucht ein episches Elternteil. Manche Geschichten stehen für sich alleine gut da und lassen sich anhand von Themen vielleicht besser visualisieren und planen.

Das Release-Epos

Eine Veröffentlichung ist kein Epos. Eine Version ist ein bestimmter Satz von Code und Dateien, die gebündelt und gleichzeitig an die Produktion geliefert werden. Eine Veröffentlichung kann ein Epos oder viele Epen enthalten oder auch nicht. Aber an sich ist eine Veröffentlichung kein Epos.

Es gibt hervorragende Tools auf dem Markt, die speziell entwickelt wurden, um Sie beim Release-Management zu unterstützen. Ordnen Sie Ihre Epics auf jeden Fall einer Version zu, aber verwenden Sie Release-Tools, um Ihre Releases zu organisieren, und verwenden Sie Epics, um Ihre Funktionen zu organisieren.

Epics sind mehr als eine große User Story

Ihr agiler Coach oder Scrum Master hat Sie wahrscheinlich mit den Prinzipien agiler Software vertraut gemacht, daher kennen Sie das folgende Zitat von Die 12 Prinzipien agiler Software:

„Einfachheit — die Kunst, die Menge zu maximieren
wenn die Arbeit nicht erledigt ist — das ist essenziell.“

Aber was hat das mit Epen zu tun?

Epics vereinfachen deinen Backlog. Sie ermöglichen es Ihnen, sich zur richtigen Zeit auf die richtigen Dinge zu konzentrieren und den Lärm fernzuhalten. Sie behalten den Ball im Auge, wenn es darum geht, Werte zu priorisieren und die Knöchelbeißer in Ihrem Backlog zu ignorieren.

Wir glauben, dass die Verwendung von Epics zu einer besseren Organisation Ihres Backlogs und einer besseren Planung für Ihre agilen Teams führt. Epics helfen Ihnen dabei, schneller einen Mehrwert zu liefern, indem Sie sich auf das große Ganze konzentrieren und sich vom Unklaren fernhalten.

Wenn du eine kontextuellere Ansicht deiner Epen und User Stories in Jira haben möchtest, probieren Sie Easy Agile TeamRhythm aus. Das stark visuelle Story-Map-Format verwandelt das flache Jira-Backlog in ein aussagekräftiges Bild der Arbeit, sodass Sie Ihr Backlog einfacher verwalten und Sprints oder Versionen planen können.

DevOps vs. Agile — was ist der Unterschied? Diese beiden Methoden haben viele Gemeinsamkeiten, aber es gibt auch viele wichtige Unterschiede, auf die wir in diesem Beitrag eingehen werden. Man könnte sagen, dass sie sich gegenseitig Komplimente machen. Wir würden nicht so weit gehen zu sagen, dass sie wie Erdnussbutter und Gelee sind, aber wenn sie zusammen verwendet werden, ergeben sie sicherlich eine schöne Kombination.

Im Grunde genommen läuft es auf Folgendes hinaus: Agile löst die Lücke, die zwischen Endbenutzern und Entwicklern bestehen kann, während DevOps die Lücke schließt, die zwischen Entwicklern und Operations bestehen kann.

Klingt einfach genug? Nun, da steckt noch viel mehr dahinter. Lassen Sie uns etwas tiefer in die Definition von Agile und DevOps eintauchen, was diese Methoden gemeinsam haben, was sie unterscheidet und wie sie zusammenarbeiten können.

Definition von Agilität

Die agile Methode wurde zuerst in der Softwareentwicklung populär gemacht, aber in den letzten Jahren haben sich agile Praktiken sowie die Leitprinzipien von Agile auf eine Reihe verschiedener Branchen ausgeweitet, die kontinuierliche Verbesserung und Wachstum priorisieren wollen.

Der agile Ansatz für das Projektmanagement unterscheidet sich stark vom traditionellen Ansatz für das Projektmanagement. Traditionelles Projektmanagement folgt einem Wasserfallmodell. Jedes Projektelement muss abgeschlossen sein, bevor in einer strikten Reihenfolge zum nächsten übergegangen wird, und der Arbeitsablauf bleibt von Projekt zu Projekt gleich.

Agile konzentriert sich auf Flexibilität, Anpassungsfähigkeit, Zusammenarbeit zwischen Teammitgliedern und darauf, den Stakeholdern durch kontinuierliches Kundenfeedback und schnelle Releases einen gleichbleibenden Mehrwert zu bieten. Jede Iteration bietet neue Erkenntnisse darüber, was funktioniert und was nicht und was verbessert werden könnte. Es handelt sich um einen multidimensionalen Ansatz, der die für das traditionelle Projektmanagement so charakteristischen Engpässe beseitigt.

Agile Teams können Agile auf verschiedene Arten implementieren, darunter Scrum, Kanban, schlank, und mehr. Ein wesentlicher Vorteil der agilen Softwareentwicklung ist die Fähigkeit, die Lücke zwischen Kunden oder Benutzern und Entwicklungsteams zu schließen.

Erfahre mehr über Agile, tauche ein in die Agiles Manifest, und lesen Sie unseren Artikel: Agile 101: Ein Leitfaden für Anfänger zur agilen Methodik.

Definition von DevOps

DevOps ist eine Softwareentwicklungsmethode, die es Teams ermöglicht, Software schnell und konsistent zu entwickeln, zu testen und zu veröffentlichen. Dabei werden agile Praktiken und Prinzipien integriert, einschließlich verbesserter Automatisierung und verbesserter Kommunikation und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams.

DevOps konzentriert sich auf die Abstimmung von Entwicklung und IT-Betrieb, um durchgängige Engineering-Prozesse besser zu verwalten. In der Vergangenheit schrieben Entwicklungsteams Anwendungen und gaben sie dann an ein Betriebsteam weiter, das die Software dann bereitstellte und verwaltete. Das Problem bei diesem Ansatz ist, dass das Betriebsteam keinen Einblick in die Entwicklung der Anwendung erhält.

DevOps-Praktiken überbrücken die Lücke zwischen Entwicklern, die die Software entwickeln und schreiben, und den Betriebsabläufen, die die Software ausführen.

➡️ Erfahre mehr über andere beliebte Methoden der Softwareentwicklung.

DevOps vs. Agile: Was haben sie gemeinsam?

Sowohl Agile als auch DevOps zielen darauf ab, den Softwareentwicklungsprozess zu unterstützen, aber woher kommen sie und welche Gemeinsamkeiten haben sie gemeinsam?

In diesem „Was war zuerst da, das Huhn oder das Ei?“ In diesem Szenario wissen wir tatsächlich, was zuerst da war. 🐓🥚 Agile, das in der Anfang der 2000er, bot Entwicklungsteams einen Ansatz zur Lösung komplexer Probleme. Obwohl Agile viele Probleme löste, blieb eine Lücke bestehen: Die Betriebsteams, die die Software einsetzten, wurden ins Abseits gedrängt und verharrten in einem Silo, sodass sie die Vorteile der Agilität nicht nutzen konnten.

Hier kommt DevOps ins Spiel, das agile Prinzipien anwendet, um die Lücke zu schließen, die häufig zwischen Entwicklungs- und Betriebsteams besteht. Es bietet Betriebsteams einen Einblick in den Entwicklungsprozess, sodass sie besser verstehen können, wie und warum ein Produkt hergestellt wurde. Diese Klarheit unterstützt den Entwicklungsprozess, da beide Gruppen von Teams bei der Entwicklung und Bereitstellung zusammenarbeiten können.

Das Ergebnis sind Entwicklungspraktiken, die reibungslos von einem Team zum nächsten ablaufen, eine stärkere Berücksichtigung der Benutzer und eine kontinuierliche Bereitstellung sowohl für Kunden als auch für Stakeholder.

DevOps ist also in vielerlei Hinsicht eine Erweiterung der ursprünglichen agilen Methodik. DevOps-Teams konzentrieren sich auf einen wichtigen Aspekt des Entwicklungsprozesses, um Entwicklung und Betrieb zusammenzubringen. Viele der gleichen agilen Prinzipien werden angewendet, wie z. B. kontinuierliche Bereitstellung, verbesserte Zusammenarbeit, Iteration und Automatisierung sowie die Implementierung von Feedback auf Schritt und Tritt.

Hauptunterschiede zwischen DevOps und Agile

Agile und DevOps haben zwar viele Gemeinsamkeiten, aber es gibt einige wichtige Unterschiede, die es zu beachten gilt. Die Unterschiede sind hauptsächlich auf die verschiedenen Arten von Teams zurückzuführen, die agile Prinzipien anwenden. Diese verschiedenen Teams haben unterschiedliche Bedürfnisse, arbeiten in einem anderen Tempo und werden von separaten Feedbacksystemen geleitet.

AgileDevOpsAgile ist eine breit gefächerte Methode, die sich auf die Lösung komplexer Probleme und die Überbrückung der Kluft zwischen Entwicklungsteams und Produkt-/Projektmanagement durch verbesserte Kommunikation und Zusammenarbeit, kontinuierliche iterative Entwicklung, Feedback von Stakeholdern und häufige Veröffentlichungen konzentriert. DevOps geht noch einen Schritt weiter und konzentriert sich darauf, die Lücke zwischen Entwicklungs- und Betriebsteams zu schließen, um durchgängige Engineering-Prozesse besser verwalten zu können. Agile kann auf jede Branche angewendet werden, die Wert auf kontinuierliche Verbesserung, Zusammenarbeit und Kommunikation legen möchte. DevOps wird hauptsächlich in der Softwareentwicklung eingesetzt. Es gibt viele verschiedene Frameworks, die zur Implementierung von Agile verwendet werden können, darunter Scrum, Kanban, Lean und XP (eXtreme Programming) .DevOps ist ein agiles Framework, das aufgrund von Agilität existiert.Agile konzentriert sich auf iterative Entwicklung und die Arbeit in kleinen Batches. DevOps legt Wert auf ständige Tests und die Automatisierung der Bereitstellung. Die agile Entwicklung wird in der Regel durch Sprints gesteuert: 2 bis 4 Wochen, in denen eine festgelegte Menge an Arbeit abgeschlossen und den Stakeholdern zur Rückmeldung vorgelegt wird. Das Ziel von DevOps ist es, Code so oft wie möglich an die Produktion zu liefern, entweder täglich oder alle paar Stunden. Feedback kommt von Stakeholdern, Kunden und Benutzern. Das Feedback kommt vom internen Team. Agile verwendet den Shift-Left-Testansatz (frühes und häufiges Testen, um den Code gleich beim ersten Mal richtig zu machen, wodurch die Zeit reduziert wird, die benötigt wird, um das Produkt auf den Markt zu bringen). DevOps verwendet sowohl Shift Left- als auch Shift Right-Tests, um den Code gleich beim ersten Mal richtig zu machen und die Funktionalität und Benutzerfreundlichkeit der Software in realen Situationen zu verstehen und zu optimieren, was eine breitere Testabdeckung ermöglicht.

Überbrückung jeder Lücke im Entwicklungsprozess

Lassen Sie uns alles auf die einfache Definition zurückbringen, mit der wir begonnen haben. Obwohl es viele Komplexitäten, Ähnlichkeiten und Unterschiede zwischen DevOps und Agile gibt, läuft es im Grunde genommen auf Folgendes hinaus:

Agile, das vor DevOps existierte, ist eine breit gefächerte Methode, die sich in erster Linie darauf konzentriert, die Kluft zwischen den Kunden-/Benutzern und den Entwicklungsteams zu überbrücken. DevOps, das an zweiter Stelle stand, nutzt agile Praktiken, um die Lücke zwischen Entwicklungsteams und Betriebsteams zu schließen.

Einfach und agil hat es sich zur Aufgabe gemacht, allen Arten von Teams zu helfen, mithilfe verschiedener agiler Methoden besser zu arbeiten. Wir entwerfen agile Apps für Jira mit einfacher, kollaborativer und flexibler Funktionalität. Von der Agilität des Teams mit Einfacher agiler Teamrhythmus, zu skalierter Agilität mit Einfache agile Programme, unsere Apps können Ihren agilen Teams helfen, besser zusammenzuarbeiten und Ihre Kunden zufriedenzustellen.

Buchen Sie eine 1:1 -Demo

Inzwischen sind Sie mit Scrum ziemlich vertraut. Es gibt Ihrem Team einen Rahmen, mit dem es arbeiten kann, um interne Ziele zu erreichen, damit es seinen Kunden hochwertige Software liefern kann. Aber du kannst deine Scrum-Praktiken jederzeit verbessern, um deine Kunden weiterhin zu begeistern. 😁 Eine davon ist das tägliche Scrum — eine Praxis, die einfach klingt, aber leicht falsch verwaltet werden kann (dazu bald mehr 😉).

Das tägliche Scrum besteht aus drei Elementen — Scrum-Rollen, Scrum-Artefakte, und Scrum-Ereignisse.

In diesem Artikel zeigen wir Ihnen, wie diese Komponenten in das wichtige tägliche Scrum-Meeting passen, geben einige Tipps, damit Ihr tägliches Scrum reibungslos abläuft, und besprechen, welche Fallen Sie vermeiden sollten, damit Ihr Team immer am Ball ist. Wir weisen Sie auch auf Ressourcen hin, mit denen Sie die anderen Elemente der Agilität beherrschen können. Unser Ziel ist es wie immer, dich zu einem agilen Profi zu machen. 🏄🏽 ‍ ♀️

Was ist das Daily Scrum Meeting?

Lassen Sie uns eine kurze Zusammenfassung der einzelnen Punkte machen, bevor wir in das tägliche Gedränge eintauchen:

• Scrum-Rollen: Dies sind der Product Owner, der Scrum Master und das Entwicklungsteam. Diese Scrum-Teammitglieder arbeiten als Einheit zusammen, um ihre Ziele zu erreichen.
• Scrum-Artefakte: Zu den Artefakten gehören das Produkt-Backlog, das Sprint-Backlog und das Increment. Die Artefakte stellen Informationen für das Team dar, die es ihnen ermöglichen, transparente Ansichten zu haben, anhand derer sie ihren Fortschritt messen können.
• Scrum-Ereignisse: Der Sprint, die Sprint-Planung, das tägliche Scrum, das Sprint-Review und Sprint-Rückblick geben Sie dem Team die Möglichkeit, alle Scrum-Artefakte zu erfüllen und zu verfeinern, die angepasst werden müssen, um die Ziele des Teams im Blick zu behalten.

Das Daily Scrum ist ein Treffen zwischen Teammitgliedern, um den aktuellen Sprintfortschritt zu besprechen. Es ist an der Zeit herauszufinden, ob Anpassungen am Sprint oder am Produkt-Backlog vorgenommen werden müssen, um das Ziel zu erreichen Sprintziel.

Bedeutung von Daily Scrum

Das tägliche Scrum spielt eine entscheidende Rolle bei der Verbesserung der Teamkoordination und Kommunikation. Dieses kurze, fokussierte Meeting bietet dem Team ein strukturiertes Umfeld, in dem es sich über Fortschritte und Hindernisse abstimmen kann. Es leistet einen Beitrag zu mehreren Schlüsselbereichen:

1. Fortschrittstransparenz: Die Teammitglieder erhalten einen klaren Überblick darüber, woran alle gerade arbeiten, was die Rechenschaftspflicht und die gegenseitige Unterstützung fördert.
2. Identifizierung von Hindernissen: Probleme und potenzielle Hindernisse werden frühzeitig erkannt, sodass das Team sie umgehend beheben und Projektverzögerungen minimieren kann.
3. Gezielte Zusammenarbeit: Indem die Diskussionen relevant und auf den Punkt gebracht werden, kann das Team seine Zeit effektiver nutzen und sich auf Lösungen statt auf langwierige Debatten konzentrieren.
4. Ausrichtung der Ziele: Das Treffen hilft dabei, die Bemühungen auf die Sprintziele zu bekräftigen und neu auszurichten und sicherzustellen, dass alle an einem Strang ziehen und sich in die gleiche Richtung bewegen.

Durch die Einhaltung von Best Practices, wie z. B. die Einhaltung des Zeitrahmens für die Besprechung und die Förderung einer inklusiven Atmosphäre, können Teams die Vorteile des täglichen Scrums maximieren, was zu einem kohärenteren und effizienteren Arbeitsumfeld führt.

Die wichtigsten Teilnehmer des Daily Scrum

Entwicklungsteam

Die Mitglieder des Entwicklungsteams sind die Hauptteilnehmer am täglichen Scrum. Während des Treffens berichten sie über ihre Fortschritte bei der Erreichung des Sprintziels, um herauszufinden, ob Anpassungen vorgenommen werden müssen. Sie können dies tun, indem sie jeweils drei Fragen beantworten:

1. Woran habe ich gestern gearbeitet, um das Sprintziel zu erreichen?
2. Wie werde ich heute auf das Sprintziel hinarbeiten?
3. Gibt es etwas, das mich daran hindert, das, woran ich gerade arbeite, zu beenden?

Auf diese Weise ist jeder im Team über den Fortschritt des gesamten Teams auf dem Laufenden. Die Antworten auf diese Fragen ermöglichen es dem Team auch, etwaige Blocker aufzudecken und den Sprint-Backlog entsprechend anzupassen. Ein Beispiel für einen Blocker kann ein Bug sein, der eine Entwicklerin daran hindert, ihre zugewiesene User Story im Sprint fertigzustellen.

Scrum Master und Product Owner

Im traditionellen Scrum ist der Scrum Master und Product Owner nehmen nicht aktiv am täglichen Scrum-Meeting teil — und sind auch technisch nicht erforderlich —, da sie nicht die Entwicklungsarbeit leisten, mit der das Sprintziel erreicht werden kann. Sie können jedoch immer noch wertvolle Besprechungsteilnehmer sein. Es liegt am Scrum-Team, zu entscheiden, ob sie teilnehmen sollen.

• Der Product Owner kann wegweisend bei der Anpassung der Backlog-Elemente des Sprints sein. Zum Beispiel kann der Bug, der andere Arbeiten blockiert, verschoben werden, sodass er rechtzeitig behoben wird, um das Sprintziel in Reichweite zu halten.
• Der Scrum-Master kann sicherstellen, dass die Best Practices für das tägliche Scrum befolgt werden und dass das Team einige der häufigsten Fallstricke vermeidet, die die Ziele des täglichen Scrum-Meetings verraten. Schauen wir uns diese als Nächstes an.

Was ist der Unterschied zwischen Daily Scrum und Daily Standup?

Manchmal kann es verwirrend sein, die Unterschiede zwischen Daily Scrum und täglicher Stand Up — und manchmal werden die Begriffe synonym verwendet. Es lohnt sich jedoch, auf die Unterschiede zwischen den beiden hinzuweisen.

Ein Daily Scrum ist ein Ereignis, das definiert ist in Scrum-Leitfaden. Also, was ist dann täglicher Stand-up und wie unterscheidet er sich? 🤔

Ein tägliches Stand-up ist ein tägliches Meeting, dessen Ziel es ist, den Teammitgliedern Fortschritte auf dem Weg zu einem gemeinsamen Ziel zu vermitteln. Es ist jedoch weniger restriktiv, was die Teilnehmer und die Zeitlimits angeht. Mit anderen Worten, Teammitglieder außerhalb des Scrum-Teams können teilnehmen und das Meeting kann länger als 15 Minuten dauern. Beispielsweise kann ein Unternehmen täglich ein Stand-up durchführen, an dem die gesamte Belegschaft oder eine bestimmte Abteilung teilnehmen, deren Fortschrittsberichte nicht auf die Softwareentwicklung beschränkt sind.

Best Practices für das tägliche Scrum

Was sind also die besten Methoden, um Ihre täglichen Scrum-Meetings effektiv durchzuführen?

1. Schließe das tägliche Gedränge in einer Zeitbox ab

Ein Zeitrahmen von 15 Minuten wird am häufigsten verwendet, um sicherzustellen, dass das Team konzentriert und auf den Punkt kommt. Schließlich müssen die Teammitglieder ihre drei Fragen nur kurz und effektiv beantworten.

2. Führen Sie das Meeting jeden Tag zur gleichen Zeit und am gleichen Ort durch

Dies wird für ein gewisses Maß an Kohärenz und Regelmäßigkeit sorgen und dazu beitragen, Scrum-Werte von Engagement und Fokus.

3. Beziehen Sie in jedes tägliche Scrum-Meeting dieselben Teammitglieder ein

Wenn Sie eine wechselnde Besetzung von Charakteren haben, laufen Sie Gefahr, dass es zu Unterbrechungen kommt. Bei einigen Teilnehmern der Besprechung fehlt wahrscheinlich der Kontext aus früheren Besprechungen und sie müssen auf dem Laufenden gehalten werden.

Tägliche Scrums für entfernte oder verteilte Teams

Tägliche Scrums sind für die Ausrichtung der Teams von entscheidender Bedeutung, aber für Teams an verschiedenen Standorten oder an verschiedenen Standorten ist eine durchdachte Ausführung erforderlich, um die Effektivität aufrechtzuerhalten. So können Sie das Beste aus Ihren virtuellen täglichen Scrums herausholen:

Intelligente Nutzung von Videokonferenzen

Videokonferenzen bieten den Vorteil einer Live-Konversation, die für die Zusammenarbeit und Klarheit in Echtzeit von entscheidender Bedeutung ist.

• Respektiere persönliche Bedürfnisse: Erkenne, dass es anstrengend sein kann, vor der Kamera zu stehen. Bieten Sie Flexibilität, indem Sie den Teammitgliedern die Wahl lassen, wann sie ihre Kameras verwenden möchten.
• Ermüdung vermeiden: Ermutigen Sie dazu, bei wichtigen Diskussionen die Kamera zu verwenden, bieten Sie jedoch die Möglichkeit, nur Audio zu hören, um Erschöpfung zu vermeiden.

Zeitzonen mit Bedacht verwalten

Verteilte Teams erstrecken sich oft über mehrere Zeitzonen. So meistern Sie die Herausforderung:

• Intelligent planen: Finden Sie eine geeignete Besprechungszeit, die für die Mehrheit geeignet ist. Zum Beispiel könnte jemand am Vormittag teilnehmen, während es für andere früh am Morgen ist.
• Ziehen Sie asynchrone Updates in Betracht: Wenn die Zeitzonen sehr unterschiedlich sind, sollten Sie sich auf asynchrone Kommunikation wie Kommentare in der Taskleiste oder Chat-Kanäle verlassen, um alle auf dem Laufenden zu halten, ohne ihre Work-Life-Balance zu stören.

Verwenden Sie visuelle Tools

Visuelle Hilfsmittel können das Verständnis und die Teilnahme an virtuellen Besprechungen erheblich verbessern.

• Bildschirmübertragung: Verwenden Sie die Bildschirmübertragung, um Taskboards oder Projektmanagement-Software anzuzeigen und so einen klaren, visuellen Kontext für Diskussionen zu bieten.
• Tools für die Zusammenarbeit: Nutze Tools wie Miro oder Trello für visuelles Brainstorming und Aufgabentracking während des Scrums.

Arbeitsvereinbarungen definieren

Durch die Erstellung klarer Arbeitsvereinbarungen wird sichergestellt, dass alle in Bezug auf Prozesse und Erwartungen auf derselben Wellenlänge sind.

• Kommunikationsmethoden: Geben Sie an, wie Teammitglieder kommunizieren sollen, sei es über Videoanrufe, Messaging-Apps oder E-Mails.
• Tools für die Zusammenarbeit: Entscheiden Sie, welche Tools Sie für Dokumentation, Zusammenarbeit in Echtzeit und asynchrone Updates verwenden möchten. Zu den beliebten Optionen gehören Slack für die Kommunikation und Jira für das Aufgabenmanagement.

Fallstricke bei Daily Scrum

Es gibt verlockende Aktivitäten, die Sie bei der Durchführung Ihres täglichen Scrum-Meetings vermeiden sollten. Dies sind einige der häufigsten Fallstricke, die es zu vermeiden gilt:

1. Das Meeting als Status-Update verwenden

An den Product Owner, Scrum Master oder andere Stakeholder. Das Hauptziel dieses Treffens besteht darin, dass das Entwicklungsteam seine drei Fragen beantwortet, damit es alle erforderlichen Anpassungen vornehmen kann, um das Sprintziel beizubehalten. Es sollte nicht als Status-Meeting für Entwickler genutzt werden, um über den Fortschritt ihrer Arbeit zu berichten.

2. Machen Sie daraus eine Problemlösungssitzung

Um alle Blockaden, die in der Sitzung besprochen werden, innerhalb des 15-minütigen Zeitrahmens zu lösen. Eines wird zweifellos passieren, wenn das Team dies versucht — das Meeting wird zu lang dauern! Der Scrum Master sollte dem Team raten, während des Meetings bei der Arbeit zu bleiben und diese Problemlösungsversuche auf einen Zeitpunkt außerhalb des täglichen Scrum-Meetings zu verschieben.

3. Konzentrieren Sie sich auf ein Taskboard

Um den Fortschritt zu verfolgen. Das tägliche Scrum-Meeting ist eine Zeit für Diskussionen. Wenn das Team auf ein Taskboard starrt, verschwendet es wertvolle Zeit, indem es sich auf den Status der Aufgaben konzentriert und nicht darüber spricht, Anpassungen an seiner Arbeit vorzunehmen.

Zusätzlich zu diesen wichtigen Punkten gibt es mehrere andere häufige Fehler, die die Effektivität eines täglichen Scrums beeinträchtigen können:

• Es ist ein langweiliges Statusmeeting geworden an dem niemand teilnehmen will. Dies deutet auf einen Mangel an Engagement und Zielstrebigkeit hin.
• Entwickler berichten über persönliche Leistungen an einen Scrum Master oder Manager, was den kollaborativen Geist des Teams untergraben kann.
• Das Treffen findet nicht statt wenn der Scrum Master es an diesem Tag nicht schafft. Diese Abhängigkeit kann die Konsistenz der täglichen Fortschrittskontrollen stören.
• Das Team versucht Probleme zu lösen und finden Sie während des täglichen Scrums Lösungen, die vermieden werden sollten, um die Timebox zu respektieren.
• Das tägliche Scrum wird verwendet, um Arbeitselemente zu verfeinern, was nicht der beabsichtigte Zweck ist. Die Verfeinerung sollte separat erfolgen.
• Die Timebox wird nicht respektiert, was dazu führt, dass einige Teammitglieder das Gefühl haben, dass das Meeting eine Belastung ist. Es ist wichtig, das 15-Minuten-Limit einzuhalten.
• Einige Entwickler denken, dass sie nicht auftauchen müssen, was zu Fehlausrichtungen und verpassten Gelegenheiten zur Teamsynchronisierung führen kann.

Indem Teams sich dieser häufigen Fallstricke bewusst sind und ein konzentriertes und effizientes tägliches Scrum pflegen, können sie sicherstellen, dass sie das Beste aus ihrer gemeinsamen Zeit machen und ihre Sprintziele auf Kurs halten.

Meistere Daily Scrum und werde ein agiler Profi

Bei Einfach und agil, wir bieten Produkte um all Ihre Scrum-Events zu verwalten. Wir setzen uns leidenschaftlich dafür ein, Agile für seine Teilnehmer zugänglich und leicht verständlich zu machen. Zusätzlich zu unseren Produkten stellen wir gerne Ressourcen zur Verfügung, damit du dein agiles Spiel verbessern kannst 💪. Schau dir unsere an Blog und unsere Podcast um ein agiler Profi zu werden!

Agil sein oder agil handeln — was ist der Unterschied?

Organisationen auf der ganzen Welt haben erkannt, dass sie schnell reagieren müssen, um den Herausforderungen des ständigen Wandels zu begegnen. Infolgedessen kämpfen sie um die Einführung agiler Arbeitsweisen, und die Pandemie beschleunigt die Einführung agiler Methoden.

Diejenigen, die es richtig machen, können einen starken Einfluss auf ihr Geschäftsergebnis und ihren Wettbewerbsvorteil haben. Aber für andere sind die Vorteile vielleicht noch abzuwarten.

Hier kann „agil handeln“ und „agil sein“ den entscheidenden Unterschied ausmachen. Denn um die Vorteile agiler Methoden wirklich nutzen zu können, müssen Unternehmen von tun zu Sein.

Dieser Artikel erklärt den Unterschied zwischen agil sein oder agil handeln. Außerdem werden wir Sie durch einige der häufigsten Herausforderungen führen, mit denen viele Unternehmen auf ihrem Weg zur Agilität konfrontiert sind.

Die wichtigsten Punkte

• Um das volle Potenzial agiler Arbeitsweisen auszuschöpfen, müssen Teams eine agile Denkweise entwickeln und agile Prozesse einführen.
• Der Übergang von „agil handeln“ zu „agil sein“ erfordert Zeit, Coaching und einen neuen Managementansatz.
• Richtig gemacht, kann Agilität die Kundenzufriedenheit, das Engagement der Mitarbeiter, das Wachstum und die Rentabilität steigern.

Warum agil und warum jetzt?

Agile erfreut sich bereits seit über 20 Jahren zunehmender Beliebtheit, aber als die Pandemie ausbrach, beschleunigte sich dieses Wachstum.

In allen Branchen ist es heute von entscheidender Bedeutung, digitale Erlebnisse bieten zu können. Unternehmen müssen heute wie Softwareunternehmen handeln und denken, wobei das Online-Erlebnis der Kunden im Mittelpunkt steht. Zusammen mit einem aktiven Ansatz bei der Kundengewinnung müssen Sie einen echten Mehrwert bieten, um sich von der Konkurrenz abzuheben.

Für Unternehmen, die in diesem Umfeld überleben und gedeihen wollen, wenden sich viele an agile Frameworks um schnell einen Mehrwert für Kunden zu schaffen und Geschäftsergebnisse zu erzielen. Agilität ermöglicht es Teams:

• Machen Sie das Komplexe einfach — durch das Arbeiten in einem klaren, strukturierten Rahmen wird aus Chaos Ordnung.
• Behalten Sie den Überblick — Agile Teams haben ein gemeinsames Verständnis von ihren Fortschritten auf dem Weg zu ihren Zielen.
• Erfolge replizieren — Wenn ein Team einen effektiven Weg findet, Ergebnisse zu erzielen, kann es Lösungen für andere Zwecke verwenden und unternehmensweit austauschen.
• Schaffen Sie eine abgestimmte, zielgerichtete Kultur — wenn Hunderte von Mitarbeitern in einer Organisation Dutzende agiler Teams bilden, bilden sie ein stabiles Rückgrat und gehen denselben Weg zum gleichen Ziel.

„Agile Organisationen, die als lebende Systeme betrachtet werden, haben sich weiterentwickelt, um in einem unvorhersehbaren, sich schnell verändernden Umfeld erfolgreich zu sein. Diese Organisationen sind sowohl stabil als auch dynamisch. Sie konzentrieren sich auf die Kunden, passen sich flexibel an Umweltveränderungen an und sind offen, inklusiv und hierarchiefrei. Sie entwickeln sich kontinuierlich weiter und akzeptieren Ungewissheit und Ambiguität. Wir glauben, dass solche Organisationen für die Zukunft weitaus besser gerüstet sind als traditionelle Organisationen.“

- McKinsey & Company

Was bedeutet es, agil zu sein?

Viele Organisationen verwenden einige agile Prozesse, um Projekte zu verwalten. Das heißt aber nicht, dass die Teams die agile Methodik vollständig verstanden und angenommen haben. Es könnte sein, dass sie „agil handeln“, anstatt tatsächlich „agil zu sein“.

Hier ist der Unterschied zwischen den beiden:

Agil handeln

„Agile handeln“ ist das Missverständnis, dass Ihr Unternehmen agil wird und auf Veränderungen reagiert, wenn Sie agile Dinge tun. Unternehmen, die in diese Falle getappt sind, könnten einige agile Prozesse durchmachen, wie zum Beispiel tägliche Stehaufsteher, Sprints, und Rückblicke. Teams sind so strukturiert, dass sie klein, funktionsübergreifend und kollaborativ sind. Aber wenn sie dort aufhören, werden diese Teams nicht wirklich agil und es kann sein, dass sie Schwierigkeiten haben, Ergebnisse zu erzielen.

Agile Zeremonien, Tools und Strukturen sind zwar entscheidend für die Implementierung, aber sie sind nur ein Teil dessen, was ein Unternehmen agil macht.

Agil sein

„Agil sein“ bedeutet, dass Sie die oben genannten Aktivitäten einbeziehen, aber über die Prozesse hinausgehen. Das bedeutet, eine agile Denkweise und agile Werte auf alle Bereiche der Organisation anzuwenden. Teams müssen geschult werden, um die agile Denkweise zu beherrschen und alle Herausforderungen zu meistern, die sich auf dem Weg dorthin ergeben. Es erfordert mehr Zeit und Mühe, als einfach agil zu arbeiten, aber es ist entscheidend, wenn Sie die Vorteile nutzen möchten.

Was ist eine agile Denkweise?

Eine agile Denkweise anzunehmen bedeutet, ihre vier Kernwerte zu verstehen und zu leben. Um agil zu sein, müssen Sie:

1. Respektiere die Menschen - Erkennen Sie, dass Mitarbeiter für den Erfolg Ihres Unternehmens von entscheidender Bedeutung sind. Sorgen Sie dafür, dass die Mitarbeiter gemeinsame Ziele verfolgen, sich sicher und in der Lage fühlen, Ideen auszutauschen, und dass Sie eine „Wir“ -Mentalität gegenüber „Ich“ annehmen.
2. Fluss optimieren - Erhöhen Sie die Qualität bei jedem Schritt, damit Sie Probleme erkennen und frühzeitig Kurskorrekturen vornehmen können. Dies trägt dazu bei, den Wert zu maximieren und Verschwendung zu minimieren und gleichzeitig einen konsistenten, nachhaltigen Arbeitsablauf zu schaffen.
3. Innovation fördern — Fördern Sie das Experimentieren mit Zusammenarbeit, konstruktivem Feedback und Autonomie. Planen Sie Zeit und Raum ein, damit Kreativität und Ideen fließen können.
4. Unermüdlich verbessern - Denken Sie daran, dass es mit der agilen Denkweise keinen Endpunkt gibt. Es geht um kontinuierliche Verbesserung. Daher müssen Sie zukünftige Prozesse im Rahmen einer kontinuierlichen Praxis kontinuierlich reflektieren und verbessern.

Um diese Werte zur Grundlage für die Arbeit in Ihrem gesamten Unternehmen zu machen, müssen Sie agile Prozesse mit einer agilen Denkweise kombinieren. Ohne die agile Denkweise sind Sie nicht „agil“, und Ihre Prozesse werden nicht das volle Potenzial Ihres Unternehmens entfalten.

„Die agile Denkweise ist ein Denkprozess, der Verständnis, Zusammenarbeit, Lernen und Flexibilität beinhaltet, um leistungsstarke Ergebnisse zu erzielen. Durch die Kombination der agilen Denkweise mit Prozessen und Tools kann sich das Team an Veränderungen anpassen und seinen Kunden einen Mehrwert bieten.“

- Atlassian

Agile Prozesse und Tools reichen nicht aus

Agile Prozesse, einschließlich der Zeremonien, Tools und Apps, sind dazu da, die Denkweise des Teams zu unterstützen. Aber ohne die richtige Denkweise in Ihrem Unternehmen zu vermitteln, werden Sie nicht wirklich agil sein.

Die Förderung der agilen Denkweise gibt einem Unternehmen die Möglichkeit, sich jederzeit schnell in eine bestimmte Richtung zu bewegen, um den Kunden den besten Wert zu bieten. Teams, die Agilität beherrschen, sind in der Regel:

• Autonom und ermächtigt um Entscheidungen rund um das Produkt und das Kundenerlebnis zu treffen.
• In der Lage an Veränderungen anpassen schnell.
• Immer bereit zu lernen etwas Neues.

Verlobt mit einem geteilter Zweck und eine Kultur der Zusammenarbeit.

„Es geht darum, sich auf Veränderungen einstellen zu können. Ob das nun in Bezug auf Mitarbeiter, Ressourcen oder Budget ist — wie auch immer das für ein Unternehmen aussieht. Wenn Sie in der Lage sind, schnell von einem Schwerpunktbereich zum anderen zu wechseln, bevor es Ihr Konkurrent tut, dann haben Sie einen Wettbewerbsvorteil auf dem Markt.“

- Sean Blake, Marketingleiter, Easy Agile

Häufige Herausforderungen, auf die Sie achten sollten, wenn Sie von agiler zu agiler Arbeit übergehen

Je früher Sie handeln und von agiler zu agiler Vorgehensweise übergehen können, desto eher profitieren Ihre Kunden, Mitarbeiter und Ihr Geschäftsergebnis.

Im Folgenden finden Sie einige häufig auftretende Herausforderungen und Tipps zu deren Bewältigung.

• Die Leute könnten an alten Gewohnheiten festhalten
  Menschen finden Veränderungen schwierig, besonders wenn Gewohnheiten tief verwurzelt sind. Sie werden vielleicht feststellen, dass einige Leute auf ihrem Standpunkt beharren und an der alten Art festhalten, Dinge zu tun. Es ist wichtig, sich daran zu erinnern, dass dies einige Zeit in Anspruch nehmen kann und die Menschen Unterstützung benötigen, um neue Arbeitsweisen zu erlernen. Stellen Sie sicher, dass Sie genügend Gelegenheiten für Feedback und Diskussionen bereitstellen, damit Sie als Team das wiederholen können, um einen Prozess zu finden, der für Ihr Unternehmen funktioniert.
• Nicht nur das Team muss gecoacht werden
  Agil zu sein ist eine Denkweise für das gesamte Unternehmen, einschließlich Manager und Führungskräfte. Wenn Ihre Führungskräfte Agilität nicht verstehen und unterstützen, wird es schwierig sein, an Dynamik zu gewinnen und alte Prozesse und Hierarchien zu verändern. Scrum Master und Agile Trainer müssen Zeit damit verbringen, Führungskräfte zu coachen, um neue agile Denkweisen und Fähigkeiten zu entwickeln.
• Für viele Unternehmen erfordert Agilität einen neuen Führungsstil
  Der traditionelle Führungsstil von Command and Control mag im Industriezeitalter funktioniert haben. Aber jetzt passt es nicht mehr zu der Art und Weise, wie Unternehmen und Mitarbeiter heute arbeiten müssen, und es unterstützt nicht die agile Denkweise. Um agil zu sein, benötigen Teams das Vertrauen, die Autonomie und die Fähigkeit, eine Idee ohne Hindernisse bis zur Umsetzung umzusetzen. Damit dies gelingt, müssen Führungskräfte hinter diesen vielseitigen Bemühungen zur kulturellen Transformation stehen.

Bist du bereit, agil zu sein?

Über agile Prozesse hinauszugehen und ein agiles Mindset im gesamten Unternehmen zu skalieren, ist nichts, was Sie über Nacht in Angriff nehmen können. Es erfordert Zeit, Mühe, Training und Unterstützung durch Führungskräfte, um agile Werte zu verinnerlichen und die Kommando-Mentalität der Vergangenheit hinter sich zu lassen.

Unterwegs stehen Sie möglicherweise vor Herausforderungen, Sie werden feststellen, dass es immer mehr zu lernen gibt, und Sie müssen agil sein, wenn es um die Einführung von Agile geht.

Der Preis für echte Agilität ist jedoch erheblich, einschließlich der Steigerung der Kundenzufriedenheit, der Steigerung des Mitarbeiterengagements und der Verbesserung der Produktivität — die Investition lohnt sich also.

Agilität hilft modernen Unternehmen, durch Veränderungen in einer unsicheren und unvorhersehbaren Welt erfolgreich zu sein. Für die meisten von uns ist dies keine wünschenswerte Arbeitsweise mehr — sie ist unverzichtbar.

Wenn eines in der Produktentwicklung (oder im Leben) sicher ist, dann ist es, dass die Zeit immer vergeht und es immer Aufgaben gibt, die erledigt werden müssen. Es gibt keine einfachere Methode, diese beiden kritischen Kennzahlen zu berechnen als ein einfaches Burndown-Diagramm.

Burndown-Diagramme helfen agilen Teams dabei, Zeit und Aufgabenerledigung zu visualisieren. Das bedeutet, wie viel Arbeit noch übrig ist, verglichen mit der Zeit, die für die Entwicklung eines Produkts oder eines bestimmten Sprints geplant ist.

In diesem Beitrag erklären wir, was Burndown-Charts sind, welche Vorteile ihre Verwendung hat und wie sie von Entwicklungsteams verwendet werden. Wir erklären auch den Unterschied zwischen Burndown- und Burnup-Diagrammen, Produkt-Burndown-Diagrammen und Sprint-Burndown-Diagrammen und stellen hilfreiche Tools zur Integration kritischer Metriken in Jira vor. Lassen Sie uns nun die Y-Achse nach unten gleiten!

Was ist ein Burndown-Diagramm?

Ein Burndown-Diagramm visualisiert, wie viel Arbeit noch zu erledigen ist und wie viel Zeit für die Fertigstellung noch zur Verfügung steht. Diese grafische Darstellung ist für alle sichtbar und sagt voraus, wie viel Arbeit das Team innerhalb der vorgegebenen Zeit erledigen will. Burndown-Diagramme werden auch verwendet, um zu messen, wie schnell ein agiles Team die Nutzerberichte von Kunden bearbeitet und fertiggestellt hat. Sie eignen sich hervorragend, um das Team über jede Änderung des Arbeitsumfangs auf dem Laufenden zu halten.

Schauen wir uns an, was jeder Teil des Diagramms darstellt. Der verbleibende Arbeitsaufwand wird auf der vertikalen Achse angezeigt. Die Zeit, die seit dem Start des Projekts oder des Sprints vergangen ist, wird auf der horizontalen Achse angezeigt. Die X-Achse ist also die Zeitleiste des Projekts oder der Iteration, und die Y-Achse ist die Arbeit, die abgeschlossen werden muss.

Der gesamte Arbeitsaufwand für das Projekt befindet sich links oben auf der Y-Achse, und der Endpunkt ganz rechts auf der X-Achse steht für den letzten Tag des Projekts oder einer bestimmten Iteration. Die Start- und Endpunkte sind durch die ideale Arbeitslinie miteinander verbunden. Dabei handelt es sich um eine gerade Linie, die zeigt, was das Team innerhalb eines vorher festgelegten Zeitrahmens zu erreichen hofft. Eine weitere Linie, die eigentliche Arbeitslinie, zeigt, wie viel Arbeit noch übrig ist und wie schnell das Team tatsächlich arbeitet.

Tatsächliche Arbeitslinie im Vergleich zur idealen Arbeitslinie

Ein Burndown-Diagramm zeigt sowohl die tatsächliche Arbeitslinie als auch die ideale Arbeitslinie. Beide Linien beginnen am Startpunkt oben auf der Y-Achse. Im Laufe des Projekts oder der Iteration oszilliert die tatsächliche Arbeitslinie um die ideale Arbeitslinie, je nachdem, wie das Team voranschreitet.

Wenn das Team den Zeitplan einhält, weicht die tatsächliche Arbeitslinie nicht wesentlich von der idealen Arbeitslinie ab und bleibt anständig gerade. Wenn das Team während des Projekts oder Sprints auf viele zeitraubende Hindernisse stößt, wird die eigentliche Arbeitslinie eher ein wildes Kringel sein, und es kann sein, dass der Endpunkt der X-Achse nicht erreicht wird, bevor die Zeit abgelaufen ist.

Die Vorteile der Verwendung von Burndown-Charts

Burndown-Charts sind in vielerlei Hinsicht hilfreich. Diese Diagramme:

• Stellen Sie den Fortschritt der im Laufe der Zeit abgeschlossenen Arbeiten visuell dar.
• Halten Sie die Produktverantwortlichen über den Entwicklungsfortschritt eines Produkts oder eines bestimmten Sprints auf dem Laufenden.
• Sorgen Sie dafür, dass das gesamte Entwicklungsteam auf dem Laufenden ist, wie weit ein Produkt fortgeschritten ist.
• Werden regelmäßig aktualisiert, sobald die Arbeit abgeschlossen ist und die Zeit vergeht, um den Produktfortschritt in Echtzeit anzuzeigen.
• Informieren Sie im Voraus, wenn ein Produkt nicht schnell genug entwickelt wird.
• Erfassen Sie klare Kennzahlen, die im Nachhinein überprüft werden können.

Burndown-Diagramm im Vergleich zu Burnup-Diagramm

Ein Burndown-Diagramm zeigt, wie viel Arbeit noch übrig ist, indem es an der Spitze der Y-Achse beginnt und im Laufe der Zeit und Abschluss der Arbeit nach unten zu der Stelle führt, an der der Endpunkt auf die X-Achse trifft.

Ein Burnup-Diagramm bewirkt das Gegenteil. Der Startpunkt befindet sich in der unteren Ecke des Diagramms, ganz links von der X-Achse. Die ideale Arbeitslinie und die tatsächliche Arbeitslinie eines Burn-up-Diagramms verlaufen nach oben, wenn die Arbeit abgeschlossen ist und die Zeit vergeht. Oben auf der Y-Achse befindet sich eine weitere horizontale Linie, die den Umfang des Projekts darstellt, z. B. die Anzahl der Story Points, die für die Fertigstellung benötigt werden. Wenn der Umfang größer wird, z. B. wenn Story Points oder Sprint-Backlog Wenn Elemente hinzugefügt werden, erhöht sich die Umfangslinie, um dem erhöhten Ziel Rechnung zu tragen.

Wenn sich der Umfang eines Sprints oder Projekts aufgrund unerwarteter Entwicklungen oder Erkenntnisse der Stakeholder ändert, was im Laufe der Entwicklung unvermeidlich ist, werden diese Änderungen durch die Scope-Linie dargestellt. Dies kann Burnup-Charts zu einem etwas anpassungsfähigeren Tool machen.

Sowohl Burndown- als auch Burnup-Diagramme verfolgen die Geschwindigkeit, den Arbeitsablauf und den Fortschritt eines Teams. Die Umfangslinie eines Burnup-Diagramms berücksichtigt die Entwicklung der Softwareentwicklung und die Art und Weise, wie sich die Ziele im Laufe eines Projekts bewegen können, weshalb sie sich ideal für die Nachverfolgung eines Projekts als Ganzes eignen. Obwohl beide Tools effektiv sind, könnte ein Burndown-Diagramm während eines Sprints besser genutzt werden, da die Wahrscheinlichkeit, dass sich die Anzahl der Aufgaben in einem Sprint ändert, geringer ist.

Grafik zum Produkt-Burndown im Vergleich zum Sprint-Burndown

Es gibt zwei verschiedene Arten von Burndown-Charts. Ein Produkt-Burndown-Diagramm zeigt, wie viel Arbeit für das gesamte Projekt noch übrig ist, wohingegen ein Sprint-Burndown-Diagramm zeigt, wie viel Arbeit in einer bestimmten Iteration noch übrig ist.

Ein Produkt-Burndown-Diagramm erfasst eine größere Datenmenge. Es stellt alles dar, was an einem Produkt innerhalb des zu Beginn des Projekts vereinbarten spezifischen Zeitrahmens fertiggestellt werden muss.

Ein Sprint-Burndown-Diagramm hilft Scrum-Mastern dabei, zu visualisieren, wie schnell das agile Team die Arbeit erledigt und wie viel Arbeit während eines Sprints noch zu erledigen ist. Es zeigt den Fortschritt des Scrum-Teams, indem es anzeigt, wie viel Arbeit tatsächlich noch übrig ist, anstatt wie viel Zeit aufgewendet wurde. Im Laufe eines Sprints wird das Diagramm entlang der abgeschlossenen Storypoints nach unten geneigt sein.

Wenn die Burndown-Linie in einem Sprint-Burndown-Diagramm nicht bis zur Mitte des Sprints nach unten zeigt, ist das ein Zeichen dafür, dass der Sprint nicht gut läuft, und es ist Sache des Scrum Masters, das Team wieder auf Kurs zu bringen.

Arbeiten Sie an Ihrem nächsten Produktplan? Erfahren Sie häufige Fehler bei der agilen Planung und wie Ihr Team diese häufigen Fallstricke vermeiden kann.

Burndown-Charts in Jira

Kaputte Builds Agile Berichte und Gadgets beinhaltet Burndown- und Burnup-Charts für beide Scrum und Kanban.

Die Anwendung wurde für Jira entwickelt, sodass Sie die Berichterstattung in Echtzeit integrieren können. Der Zugriff auf sofortige Kennzahlen hilft Teams, Engpässe und Abhängigkeiten zu erkennen, sodass diese eher früher als später behoben werden können. Mit der Anwendung können Sie Diagramme und anpassbare Berichte exportieren, um sie mit Teammitgliedern und Stakeholdern zu teilen oder im Nachhinein zu überprüfen.

Wie Easy Agile Ihrem Team helfen kann

Unsere Leidenschaft ist es, agilen Teams dabei zu helfen, effizienter und effektiver zu arbeiten, wobei die Bedürfnisse des Kunden immer an erster Stelle stehen. Wir entwickeln Produkte, die speziell für Jira-Benutzer entwickelt wurden, darunter Einfacher agiler Teamrhythmus, Programme, Personas, und Straßenkarten.

Versuche Einfacher agiler Teamrhythmus um einfache und kollaborative Storymaps in Jira zu erstellen. Unser Tool hilft Ihnen dabei, Ihre Produkt-Backlogs in eine wirkungsvolle visuelle Darstellung der Kundenreise umzuwandeln. Es ist die Story-Mapping-App für Jira mit den höchsten Bewertungen, der über 120.000 Nutzer von Unternehmen wie Amazon, Twitter, Starbucks, Rolex und Adobe vertrauen.

Product development Ohne agilen Arbeitsablauf wäre das so, als würde man ein Haus ohne Plan oder definierte Rollen im Bauteam bauen. Niemand weiß, was zu tun ist oder wer was tut. 🤔

The result: time and energy verschwendung beim bau eines einzelnen hauses, das im Laufe der Jahre höchstwahrscheinlich seine dunkelsten Mängel aufweisen wird.

Also, hier ist, was Sie wissen müssen: Der Prozess erhöht die Effizienz. Es erhöht auch die Effizienz, die Kundenzufriedenheit und eine bessere Erfahrung für die Teammitglieder, die an dem Prozess beteiligt sind.

Follow this guide to build and to implementation a agile workflows in JIRA. In diesem Artikel behandeln wir, was ein agiler Workflow ist, und definieren die Schritte für seine Erstellung und seine Prinzipien im Detail.

Der Begriff Arbeitsablauf

The ausführung of a team work is defined by one or several processes. With other Worts, an process is an art and way, how the team with the results the line. Und wenn sie Produkte entwickeln Agiles Framework, ein agiler Arbeitsablauf ist eine Möglichkeit, diesen Prozess zu strukturieren.

Im Allgemeinen besteht ein Arbeitsablauf aus:

• Activities, Tasks and Steps
• Rolles
• Produits travail
• Ein paar andere Dinge, die zur Verbesserung der Teamzusammenarbeit und Arbeitsführung beitragen

Mit einer solchen Struktur wird es einfacher:

• Um den Vorgang zu wiederholen
• Damit Teammitglieder miteinander arbeiten können
• Um den Prozess und die Arbeit selbst zu skalieren

Es scheint, als ob ein Arbeitsablauf so gut organisiert ist, dass die Teamarbeit reibungslos ablaufen würde, nur weil er existiert. Nun, das ist nicht der Fall. Im nächsten Abschnitt erfahren Sie, dass es für kein Team oder Projekt einen Arbeitsablauf gibt. Stattdessen gibt es einen oder mehrere Workflows, die funktionieren für dein Team oder dein projekt.

Warum gibt es keinen einheitlichen Arbeitsablauf

Die Größe und Reife der Teams wirken sich auf ihre Arbeitsabläufe aus. Also the art of project and both corporate culture as also the team culture, the configuration of workflows. Fazit: Ihr agiler Arbeitsablauf hängt von vielen Faktoren ab und wird wahrscheinlich einzigartig sein.

Eventuell find it online suggestions for workflows, which are perform with other companies as functional. If you want, you can also use this as access point for the definition your own workflows. Es könnte der Fall sein, dass einige Schritte für Sie ausgeschlossen sind. Dann könnten sie ihren eigenen Arbeitsablauf von Grund auf neu definieren.

Jira ist eine sehr vielseitige Lösung for workflow-Management, the many different agile workflows supports.

Mit Jira kannst du Workflows an verschiedene Unternehmens- oder Teamkulturen anpassen. In this connection means culture the art and wise, as team members work together. In gleicher Weise drückt ein Arbeitsablauf, ein dynamisches Team in einem oder mehreren Projekten aus.

Wenn wir jetzt über Jira-Workflows sprechen, sollten Sie wissen, was einer davon enthält.

Was genau ist ein Jira-Workflow?

Ein Jira-Workflow ist ein agiler Workflow, der auf Jira aufbaut und mit Hilfe von Jira implementiert wird. It is a digital board, with you can check the status of Arbeitselemente. Es kann auch Benachrichtigungen senden, wenn sich der Status dieses Artikels ändert. Sie können auch Ihre verwenden Jira-Board for Scrum Chats wie tägliche Standups und Sprint-Retrospektiven.

Sie müssen unbedingt dafür sorgen, dass der Status ALLER Arbeitselemente korrekt ist. Das bedeutet, dass der Status jedes Arbeitselements aktualisiert wird, wann und sobald er sich ändert.

Nur ein aktueller agiler Workflow — and a Jira Board — erfüllt seinen Zweck und bietet Vorteile. Es ist ein großartiges Tool für Teammitglieder, Produkteigenschaften, und Scrum Master um den Arbeitsfortschritt jederzeit zu verfolgen.

we go now to our guide over. Du erfährst, ein Tipp nach den anderen, wie du mit Hilfe von Jira ein agiler Workflow-Rockstar wirst.

Dein Leitfaden für agile Workflows in Jira

Startet eure Motoren! Du begibst dich auf eine fabelhafte Lernreise über die Erstellung und Verwaltung agiler Workflows in Jira. Hier sind unsere besten Tipps, um diesen Prozess zu verwirklichen:

1. Fangen Sie jetzt an

Zögere nicht, sie machen die Hände schmutzig mit der Workflow-Definition.

Also wenn Sie einfach anfangen, fangen Sie einfach an. Tue you not before think that you be successful in the agile area, if they large start. Es könnte tatsächlich sein, dass sich das gegen Sie und Ihr Projekt auswirkt.

2. Überanstrengen Sie sich nicht

Sie verbringen nicht Wochen damit, ihre Arbeitsabläufe strukturieren, umstrukturieren und dann noch einmal umstrukturieren.

Überarbeitete Arbeitsabläufe sind schwer zu verstehen und viel schwieriger zu implementieren und umzusetzen. Das würde schaden the basic principles of Agile Methodologie.

Bei einem überlasteten Arbeitsablauf würden die Teammitglieder am Ende nicht wissen, was zu tun ist und wann sie tun sollten. Folglich, am Ende von der Sprint — or iteration — and project, no results are ready for the introduction.

3. Vergessen Sie nicht den Workflow-Stakeholder

Sie sollten Rollen berücksichtigen, die den von Ihnen definierten Arbeitsablauf irgendwie verwenden. When some is daily use, to do your work, use other is only for a art of management analysis.

Sie sollten mit ihnen verstehen, was ihre Workflow-Anforderungen sind. Es wird einige Zeit dauern, also müssen Sie geduldig sein.

4. Verstehe das Konzept von „Problem“ in Jira

Describir a problem a problem, for this is still no solution. This problems are caused on risks, which risk the development process of the project and the final success. The add an function to the project beginning — the problem — may also be return on the possible of requirements changes — on the risk.

In Jira gibt es ein Problem, aber es ist nicht unbedingt ein Problem. Es stellt jedoch eine Arbeit dar, die Teams müssen erledigen. Ein Jira-Problem kann beispielsweise eine Aufgabe oder ein Helpdesk-Ticket sein.

Bei der Softwareentwicklung kann ein Jira-Problem spezifische Konzepte symbolisieren, wie zum Beispiel:

• Properties of the product und Funktionen, die das Entwicklungsteam implementieren muss
• Bugs, die gelöst werden müssen

5. Kenne die Teile des Puzzles

In Jira gibt es einen Workflow aus vier Arten von Komponenten:

1. Status. This is the position of a problems in the workflow. This can be process to a offen — or ungelösten — status or to a closed — or closed — status.
2. Übergang. This defined as a problem change the status, and it can be either uni or bidirektional. Je nachdem, wie sich der Status ändert, can you create more or less restrictions. Sie können sogar definieren, dass nur bestimmte Personen oder bestimmte Rollen ein Problem von einem bestimmten Status in einen anderen ändern können.
3. Abtretungsempfänger. This is the person, that is responsible for a problem.
4. resolution. This described why a problem from status „Offen“ to the status „closed“ is overgoing. Außerdem sollte ein Problem nur bearbeitet werden, solange es gelöst ist.

In Softwareteams oder Projekten ist es üblich, Status wie die folgenden zu finden:

• „Zu erledigen“ für Probleme, die noch nicht begonnen haben
• „In Bearbeitung“ für Probleme, mit denen das Team bereits begonnen hat, werden
• „Code Review“ für abgeschlossene Codierungsaufgaben, die eine Überprüfung erforderlich machen
• „quality assurance“ for closed problems, that must be tested by a team of tester
• „Fertig“ für abgeschlossene, überprüfte und getestete Arbeiten

If an code review is successful, the work is finished. In this example is the success of code check an change from „code check“ to status „ready“. Und die Lösung wäre der Grund, warum die Codeüberprüfung fehlgeschlagen ist.

Schließlich können Sie Übergänge einrichten mit:

• Conditions. Sie verhindern, dass eine unzureichende Rolle den Status eines Problems verändert.
• Validatoren. This ensure that a transfer only under specific environment. Wenn nicht, findet der Übergang nicht statt.
• Post-Funktionen. Sie beschreiben Aktionen zu Problemen und ändern nicht nur deren Status, und Sie können automatisieren. Sie entfernen beispielsweise die Lösung eines gelösten Problems, bevor Sie den Status wieder auf ungelöst ändern. Ein anderes Beispiel wäre, die Bevollmächtigten aus dem Problem zu entfernen.
• Properties. This are features of overganges. Ein Merkmal könnte beispielsweise darin bestehen, dass nur Lösungen angezeigt werden, die für die Art des Problems relevant sind.

6. Definiere „erledigt“

Jedes Team ist einzigartig. Es besteht aus unterschiedlichen Menschen, unterschiedlichen Gewohnheiten und unterschiedlichen Erfahrungen mit Technologie und Methoden. Various types, work to done. Das bedeutet, dass Sie definieren müssen, was „geleistete Arbeit“ für Ihr Team oder Ihr Projekt bedeutet.

Zum Beispiel müssen Sie die folgenden Fragen für Ihr Team oder Projekt beantworten:

• Welchen Status sollte ein Produkt oder eine Funktion haben, wenn die Markteinführung oder die Veröffentlichung genehmigt wurde?
• Was sollten Ihre Teammitglieder tun, um jedes Arbeitsergebnis auf diesen Status zu bringen?
• Wer sollte unterwegs Entscheidungen — wie etwa Genehmigungen — treffen, welche Entscheidungen und zu welchen Zeitpunkten?
• Wer erklärt Arbeit als erledigt?

7. Passen Sie den Jira-Standard-Workflow an

Erinnerst du dich, dass du Jira verwenden könntest, um Workflows an verschiedene Arbeitsweisen als Team anzupassen? Hier erfährst du, wie das geht:

Schritt #1: Definiere die Status und Übergänge deines Workflows im Jira Workflow Designer.

Sie können Jira als Standard verwenden Scrum oder Kanban Workflow — klassische Jira-Vorlagen — oder nehmen Sie einige Änderungen daran vor. Alternativ können Sie den vereinfachten Scrum-Workflow von Jira wählen, der für einigermaßen grundlegende Anforderungen ausreichend ist.

Die vereinfachte Version des Scrum-Workflows beinhaltet:

• Drei Status: „Zu erledigen“, „In Bearbeitung“ und „Erledigt“
• Zwei Übergänge: von „Zu erledigen“ zu „In Bearbeitung“ und von „In Bearbeitung“ zu „Erledigt“
• Vier Spalten zur Organisation der Themen, die auf verschiedenen Foren verteilt sind: „Backlog“, „Zur Entwicklung ausgewählt“, „In Bearbeitung“ und „Erledigt“

Schritt #2: Erstellen Sie Ihren Workflow, indem Sie Komponenten zum vereinfachten Scrum-Workflow hinzufügen.

Um den Fortschritt von Problemen in der agilen Entwicklung zu verfolgen, können Sie Status wie „Code Review“ und „Quality Assurance“ hinzufügen. Und Sie könnten dem Übergang von „Code Review“ zu „Done“ einen Validator hinzufügen, um zu erzwingen, dass Sie eine erfolgreiche Code-Überprüfung benötigen, um den Status „Fertig“ zu kennzeichnen.

Darüber hinaus können Sie Genehmigungsphasen in den Workflow einbeziehen, z. B. „Warten auf QA“. Diese Phasen gehen den Phasen voraus, in denen ein Problem geschlossen wird oder in den Status „Abgeschlossen“ übergeht.

Schritt #3: Verschaffen Sie sich einen Überblick über die visuelle Darstellung des Diagramms.

Wenn Sie mit der Anpassung des Workflows an Ihr Team oder Projekt fertig sind, stellen Sie sicher, dass das Diagramm visuell lesbar ist. Das ist wichtig, wenn Sie das Diagramm mit Stakeholdern teilen, um Feedback zu erhalten. Sie sollten Feedback von mindestens einem Vertreter jeder Art von Interessengruppen einholen.

Eine interessante Funktion von Jira ist der Workflow, mit dem Sie Probleme visuell hervorheben können. Auf diese Weise können Sie anhand seines Status sehen, wo sich das Problem im Workflow befindet. Öffnen Sie einfach das Problem und klicken Sie neben dem Status des Vorgangs auf die Schaltfläche „Workflow anzeigen“.

8. Verlassen Sie sich bei der Fortschrittsverfolgung auf Jira-Berichte

Jira bietet zwei nützliche Berichte, mit denen Sie den Arbeitsfortschritt des Teams in einem Sprint verfolgen können:

• Das Burndown-Diagramm, was zeigt:
• Die Menge an Arbeit, die in einem Sprint noch zu erledigen ist
• Die Arbeit, die die Teammitglieder gerade ausführen
• Die Verteilung der Arbeit während des Sprints
• Ob die Probleme in den Sprint passten und die Aufwandsschätzung ausreichend war
  
• Der Sprint-Bericht, das beinhaltet:
• Das Burndown-Diagramm
• Eine Liste offener und geschlossener Probleme für diesen Sprint
• Zusätzliche Arbeit zum Sprint hinzugefügt

Wie bei jedem anderen Bericht können Sie mit Jira-Berichten über Erfolg und Misserfolg nachdenken. In diesem Fall geht es um den Erfolg und Misserfolg jedes Sprints in Bezug auf:

• Schätzung des Aufwands
• Leistung des Teams
• Unregelmäßigkeiten im Prozess
• Sprint-Planung

Am wichtigsten ist, dass Sie Jira-Berichte verwenden können, um diese Aspekte kontinuierlich zu verbessern und Probleme wie die folgenden zu vermeiden:

• Zu viel Arbeit für einen Sprint
• Eilige Arbeit
• Plötzliche Änderungen der Prioritäten

Ein Jira-Workflow ist praktisch, wenn Sie Ausreißer im Entwicklungsprozess erkennen, wie zum Beispiel:

• Eine große Anzahl offener Probleme
• Häufiges Wiederöffnen von Ausgaben
• Eine hohe Anzahl ungeplanter Probleme wurde zum Sprint hinzugefügt

In der Lage zu sein, diese Probleme zu erkennen, ist äußerst wertvoll, da so ein massiver Sprintausfall vermieden werden kann.

9. Informationen teilen

Mitarbeiter in Ihrem Unternehmen, die nicht zu Ihrem Team gehören, benötigen möglicherweise Informationen aus Ihrem Arbeitsablauf. Berücksichtigen Sie dies also, wenn Sie den Workflow Ihres Teams oder Projekts definieren.

Diese Leute müssen vielleicht wissen über:

• Die Menge der abgeschlossenen Arbeiten
• Das Produkt-Backlog Dimension im Vergleich zur Teamleistung
• Die Anzahl der offenen und geschlossenen Probleme oder die Anzahl der Probleme in einem bestimmten Status
• Die durchschnittliche Bearbeitungszeit einer Ausgabe
• Die durchschnittliche Anzahl von Problemen, die zu lange dauern oder bei denen es zu Engpässen kommt, was bedeutet, dass bestimmte Status wie „Qualitätssicherung“ nicht erreicht werden

10. Halte es einfach

⚠️ Es kann verlockend sein, Problemstatus zu erstellen, während Probleme durch den Workflow bewegt werden, aber tun Sie es nicht! Jeder zusätzliche Status fügt weitere Übergänge mit all ihren individuellen Merkmalen hinzu.

❌ Wenn Ihr Workflow es Ihnen bereits ermöglicht, den Sprint zu bewerten und Ihre Stakeholder mit wertvollen Informationen zu versorgen, ist das einfach perfekt. Sie müssen ihm keine weiteren Problemstatus hinzufügen.

✔️ Fügen Sie zusätzliche Problemstatus nur hinzu, wenn Sie keine andere Option haben. Wenn beispielsweise verschiedene Teams die Arbeit in verschiedenen Entwicklungsphasen verfolgen müssen, benötigen Sie möglicherweise unterschiedliche Status.

11. Begrenzen Sie die laufenden Arbeiten

Sie können ein bestimmtes Limit für die Anzahl der Probleme in einem bestimmten Status festlegen. Dabei sollten Sie sicherstellen, dass das gesamte Team in jedem Workflow-Status genügend Arbeit hat.

Außerdem sollten Sie sicherstellen, dass die Grenzen, die Sie in den Workflow einführen, die Kapazität des Teams nicht überschreiten. Wenn Sie dies nicht tun, muss das Team Prioritäten setzen, und Sie möchten möglicherweise nicht, dass dies geschieht.

Die Teamleistung sollte steigen, wenn Sie die richtigen Grenzwerte für laufende Arbeiten festlegen. 🤗

12. Bereite dich auf die Skalierung vor

Agile Teams sollten klein sein. Nichtsdestotrotz sollte ein agiler Workflow einer Zunahme der Anzahl von Personen gerecht werden, die damit arbeiten. Das bedeutet, dass niemand bemerken sollte, wenn eine Erhöhung stattfindet.

Hier sind einige goldene Regeln für Skalierung agiler Workflows:

• Vereinbaren Sie agile Methoden für die Workflow-Definition und minimieren Sie Anpassungen auf ein Minimum, wenn mehrere Teams, die an ihren eigenen Projekten arbeiten, zusammenarbeiten müssen.
• Verschiedene Teams, die an demselben Projekt arbeiten, sollten denselben Arbeitsablauf verwenden, da sonst die Dinge chaotisch werden könnten.
• Teams sollten bei der Definition eines gemeinsamen Workflows Kompromisse eingehen. In diesem Fall erstellen Teams jedoch Workflows, die auf mehreren erfolgreichen Erfahrungen aus der Vergangenheit basieren.

Was kannst du noch tun?

Wann immer Sie von Workflows hören, ist das ein Zeichen dafür, dass die Ausführung der Arbeit strukturiert wird. Es ist auch ein Zeichen dafür, dass noch ein langer Weg vor uns liegt, aber das Ergebnis wird großartig sein, wenn Sie:

• Befolge die 12 oben genannten Regeln
• Wählen Sie einen flexiblen Issue Tracker in Bezug auf die Workflow-Anpassung, wie z. B. Jira
• Ergänzen Sie den Issue Tracker mit den richtigen Apps

Zwingen Sie Ihr Team oder Projekt nicht dazu, sich an ein Tool zu halten. 😨 Tun Sie lieber genau das Gegenteil! Wählen Sie das Tool, mit dem Sie den richtigen Workflow für Ihren Kontext erstellen und implementieren können.

Dadurch werden der Durchsatz und die Workflow-Konformität erhöht, was genau das ist, was Sie bei der Erstellung eines Workflows erwarten.

Sorgen Sie für einen starken agilen Ansatz — optimieren Sie, diskutieren Sie und wiederholen Sie. Dies sind die Schlüsselwörter für den Aufbau und die Implementierung eines agilen Workflows. Vergessen Sie sie also nicht für eine Sekunde! Dadurch vermeiden Sie:

• Den Arbeitsablauf komplizieren, wenn er nicht unbedingt erforderlich ist
• Ignorieren Sie die Probleme, die Stakeholder und Teammitglieder bei der Verwendung oder Anzeige des Workflows haben
• Ein veralteter Arbeitsablauf, der sowohl der Unternehmens- als auch der Teamkultur nicht mehr angemessen ist

Bringen Sie Ihren agilen Arbeitsablauf auf ein neues Level

Einfacher agiler Teamrhythmus hilft dir beim Aufbau und der Implementierung eines Scrum-Workflows in Jira. Optimiere deinen agilen Workflow, indem du:

• Visualisieren Sie, was das Team wann liefern wird, indem Sie Folgendes vereinbaren Anwenderberichte in Sprint-Schwimmbahnen
• Priorisierung der User Stories in jedem Sprint, indem sie innerhalb der jeweiligen Sprint-Swimlane angeordnet werden
• Überprüfung der Sprint-Statistiken auf einen Blick, um sicherzustellen, dass die Kapazität des Teams nicht überschritten wird
• Erfassung der Aufwandsschätzung in User Stories.

Story Points in Agile sind ein Mikrokosmos der agilen Entwicklung selbst. Wenn Sie als Team zusammenarbeiten, um den Umfang abzuschätzen, entsteht eine Atmosphäre der Zusammenarbeit, des gemeinsamen Verständnisses und der kontinuierlichen Verbesserung. Agile Story Points können auch für Klarheit in einer User Story Map sorgen, indem sie Aufschluss darüber geben, wie viel Aufwand Sie in die Entwicklung der einzelnen Abschnitte der Customer Journey durch Ihr Produkt investieren möchten.

Story Points sind Aufwandsschätzer. Sie sind eine Alternative zu herkömmlichen Schätzverfahren, mit denen der erwartete Aufwand eines Projekts in Tagen, Wochen oder Monaten gemessen wird. Mit agilen Storypoints, anstatt zu fragen: „Wie lange wird dieses Projekt dauern?“ Wir verwenden relative Schätzungen über den Aufwand, der erforderlich sein könnte, um jedes Element im Backlog abzuschließen. Beispielsweise wird erwartet, dass ein Objekt, dem zwei Story Points zugewiesen sind, doppelt so viel Aufwand erfordert wie ein Objekt, das auf einen Punkt geschätzt wird.

Warum sollten agile Teams also Nutze Story Points? Schauen wir uns an, wie Story-Point-Schätzungen, Sprint-Retrospektiven und Geschwindigkeitsmetriken zu einem Konsens führen und den Teammitgliedern eine klare Vorstellung von der Priorisierung Ihres Produkt-Backlogs ermöglichen.

Schätzung des Storypoints für das gesamte Team 🙌

Bei der Sprint-Planung arbeiten Produkt- und Entwicklungsteams zusammen, um ein gemeinsames Verständnis des Aufwands zu erlangen, der zur Fertigstellung von Backlog-Elementen erforderlich ist. Während der Planung stimmt das Team einer Story-Point-Schätzung für jede User Story im Sprint zu.

Punkteschätzungen sind eine Praxis der Zusammenarbeit und Konsensbildung zwischen Teammitgliedern. Das gesamte Team beteiligt sich an der Bestimmung des Punktewerts für jedes Item im Sprint. Indem wir die Sichtweise des jeweils anderen auf die Schätzungen erörtern:

• Produktbesitzer verstehen die Gründe der Entwickler für ihre Schätzungen besser.
• Entwickler entwickeln Empathie für das Bedürfnis des Product Owners, Kompromisse abzuwägen und Entscheidungen zur Priorisierung von Sprint zu Sprint zu treffen.
• QA-Tester haben die Möglichkeit, die Komplexität und das Risiko der geschätzten Arbeit sowie den Arbeitsaufwand, der für die Erstellung und Durchführung von Tests erforderlich ist, abzuwägen.

Eine gängige Methode für den Einsatz agiler Story Points besteht darin, Backlog-Elementen mithilfe der Fibonacci-Sequenz Werte zuzuweisen — 1, 2, 3, 5, 8, 13, 21... Sie verstehen es. Mike Cohn bietet eine kurze Beschreibung Grund für diesen Ansatz — Zahlen, die zu nahe beieinander liegen, sind schwer zu unterscheiden. Diese Punktefolge bietet Ihrem Team einen viel besseren Ausgangspunkt, um den relativen Aufwand von Backlog-Elementen zu besprechen als ein lineares Punktesystem (d. h. 1, 2, 3, 4, 5... Sie verstehen es immer noch).

Durch die Planung mit agilen Storypoints vermeiden Sie die Versuchung, künstliche Deadlines für Sprint-Elemente zu setzen. Es ist auch einfacher, einen Konsens über den relativen Umfang der Elemente zu erzielen, als zu versuchen, für jedes Element einen Zeitrahmen festzulegen. Du wirst weniger Zeit mit der Planung verbringen und mehr Zeit mit der Arbeit an deinem Sprint verbringen!

Schätzungen sind... Schätzungen

Ratet mal was? Ihre Schätzungen müssen nicht perfekt sein! Der Prozess von agiles Schätzen ist schwierig bietet Softwareentwicklungsteams jedoch die Möglichkeit, sich damit vertraut zu machen, dass Story-Point-Schätzungen gerade genau genug sind, um sie kontinuierlich weiterzuentwickeln. Im Laufe der Zeit werden Sie voneinander lernen und besser darin werden, bessere Schätzungen zu erstellen.

Unvorhersehbarkeit besteht in jedem Projekt. Indem Sie grobe Schätzungen verwenden, die relativ zueinander sind, vermeiden Sie die Falle einer Überplanung und ermöglichen es den Entwicklern, sich an die Arbeit zu machen. Story-Point-Schätzungen ermöglichen es Teams, reibungslose Planungsabläufe zu erstellen und nahtlos von einem Sprint zum nächsten überzugehen.

Sprintgeschwindigkeit und andere wichtige Kennzahlen 📈

Agile Story Points bieten Teams ein weiteres wertvolles Tool, mit dem sie ihren Schätzprozess kontinuierlich verbessern können — Metriken. Im Zusammenhang mit Story Points und Schätzungen können mehrere Metriken verwendet werden, aber wir konzentrieren uns auf zwei der beliebtesten — Burndown und Velocity.

Burndown im Sprint

In jeder Sprint-Iteration verpflichtet sich das Team zu dem Umfang an Arbeit, von dem es glaubt, dass es in diesem Zeitrahmen fertig sein kann. EIN Burndown-Diagramm visualisiert, wie sich das Team im Laufe des Sprints im Vergleich zu seinem Engagement entwickelt.

Die Y-Achse ist die Anzahl der Punkte im Sprint, und die X-Achse zeigt die Zeit im Sprint an. Das Diagramm enthält zwei Linien. Die ideale Linie für verbleibende Arbeit verbindet das Startdatum des Sprints mit seinem Enddatum (sie kreuzt die X-Achse, um anzuzeigen, dass die gesamte Arbeit des Sprints erledigt ist). Die Linie für die tatsächliche verbleibende Arbeit zeigt, was noch zu tun ist. Die Grundidee ist, dass diese Linie so genau wie möglich der Ideallinie folgt, was bedeutet, dass Ihre Schätzungen solide sind und Sie die Arbeit des Sprints in einem schönen Tempo abschließen.

Wenn Sie sich dieses Diagramm ansehen, werden Sie feststellen, mit welchen Problemen agile Teams häufig konfrontiert sind. Hier sind einige Beispiele:

• Über- oder Unterverpflichtung zu viel Arbeit
• Punkte zum Sprint hinzufügen, nachdem er bereits gestartet wurde
• Unregelmäßige Bewegung in der tatsächlichen Arbeitsrestlinie
• Übermäßige Verpflichtungen, die User Stories in den nächsten Sprint drängen

Burndown steht in engem Zusammenhang mit der Geschwindigkeit, die das Arbeitstempo Ihres Teams misst.

Sprintgeschwindigkeit

Die Geschwindigkeit eines Entwicklungsteams ist die Menge an Arbeit, die in jedem Sprint abgeschlossen wird. Sie kann als Maß dafür verwendet werden, wie lange das Team braucht, um seinen Backlog abzuarbeiten. Da es sich bei agilen Storypoints um eine relative Schätzung handelt, können Teams sie als Ausgangsbasis verwenden, um zu verstehen, wie sich ihre Geschwindigkeit entwickelt.

Hier sehen wir eine Darstellung der Geschwindigkeit eines Teams im Verlauf mehrerer Sprints.

Sprint-Retrospektiven sind eine Gelegenheit, alle Probleme zu besprechen, die sich aus dem Burndown des Sprints oder der Geschwindigkeit des Teams ergeben. Es ist an der Zeit, als Team nachzudenken, Ihre Kennzahlen zu überprüfen und herauszufinden, ob es Möglichkeiten gibt, Ihren Prozess zu verfeinern und gemeinsam zu verbessern.

Hier sind einige Fragen, die Sie sich während dieses Vorgangs stellen sollten:

• Sollten wir unsere Erwartungen an die Überwindung des Rückstands anpassen?
• Müssen wir unseren Schätzungsprozess optimieren?
• Sollten wir erwägen, ein Teammitglied hinzuzufügen?
• Engagieren wir uns zu viel oder zu wenig für den Arbeitsaufwand in unseren Sprints?

Diese Kennzahlen geben zwar Aufschluss über Ihren Schätzungsprozess und das Tempo, mit dem Ihr Team Ihr Backlog bearbeitet, aber die Aufnahme Ihrer Elemente in eine User Story-Map bietet eine weitere Ebene des Kontextes für Ihre allgemeinen Priorisierungsentscheidungen.

User-Story-Mapping mit agilen Storypoints

Storypoints sind nicht nur im Zusammenhang mit Sprints wichtig. Wenn Sie sie in User Story Maps platzieren, entsteht ein visuelles Bild der strategischen Produktpriorisierung.

User Story Mapping auf den Punkt gebracht 🥜

Eine User Story Map nimmt die Elemente in Ihrem flachen Backlog und platziert sie in den Kontext Ihrer Benutzerreise durch Ihr Produkt. Sie bietet einen Überblick über alle Aktionen, die Ihre Kunden von der Anmeldung bis zur Abmeldung ergreifen, sowie über alle wichtigen Maßnahmen, die sie dazwischen ergreifen. Anstatt eine klare Liste von Elementen (Backlog) zu haben, organisiert die User Story Map diese nach den Arbeitsabläufen Ihrer Kunden.

Einen umfassenderen Überblick über diese Methode finden Sie in unserem ultimativer Leitfaden für User Story Maps.

Entfessle dein Jira-Backlog mit User Story Maps

Mit Einfache Agile User Story Maps für Jira, können Sie die Anzahl der agilen Story Points sehen, die jeder Phase der Story-Map Ihrer Benutzer zugewiesen sind. Wenn Produktteams und Stakeholder anhand von Punktschätzungen aus der Customer Journey einen nutzerorientierten Überblick über die Priorisierung erhalten.

Dies kann helfen, Fragen zu beantworten wie:

• Investieren wir zu viel Mühe in einen Teil der Reise?
• Sollten wir die Punktevergabe während der gesamten Reise glätten oder uns auf einen wichtigen Problembereich konzentrieren?
• Wird die nächste Version unseren Kunden in einer bestimmten Phase ihrer Produktreise genügend Mehrwert bieten?

Es bietet auch eine weitere Möglichkeit für Ihr Team, zusammenzuarbeiten! Wenn Sie Ihre Story-Map gemeinsam überprüfen, werden Sie mit Sicherheit mehr Erkenntnisse gewinnen und Ihre Priorisierungsentscheidungen wiederholen.

Agile Storypoints in Kombination mit User Story Mapping sind eine effektive Methode, Teams zusammenzubringen, um eine gemeinsame Sicht auf die Priorisierung während der gesamten Customer Journey zu erstellen.

Ein häufiges Missverständnis bei agilen Softwareentwicklungsmethoden ist, dass sie keinem formalen Prozess folgen. Jedes Team macht einfach sein eigenes Ding mit wenig oder gar keiner Planung, und irgendwie klappt alles. Nun, wir hassen es, Ihre Seifenblase platzen zu lassen, aber Softwareentwicklung funktioniert so nicht, agil oder nicht. 🤯

Genau wie bei traditionellen Wasserfallprojekten folgt agile Projekte einem agilen Softwareentwicklungszyklus (SDLC). Aus der Prozessperspektive besteht der Hauptunterschied in einem linearen Ansatz mit Wasserfall und einem iterativen Ansatz mit Agilität. We are something later into into there.

Lassen Sie uns zunächst erläutern, wie ein agiles SDLC mit agilen Prinzipien im Einklang steht. Dann werden wir sowohl in Scrum- als auch in Kanban-Umgebungen über agile SDLC sprechen.

How the cycle of agile softwaredevelopment agile principles supports

Das Agiles Manifest nennt vier Grundwerte, die zur Verbesserung der Softwareentwicklungsprozesse beitragen. Sie sind:

Individuals and Interactions about Processes and Tools
Funktionende Software über eine umfassende Dokumentation
Zusammenarbeit mit Kunden over Contracts
Reagieren Sie auf Veränderungen anstatt einem Plan zu folgen.

Das sind großartige Werte! Heben Sie jetzt Ihre Hand, wenn Sie sich an den nächsten Satz erinnern. Irgendjemand?? Lass uns dein Gedächtnis auffrischen: „Das heißt, obwohl die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr ein. “

Allzu oft sind neue agile Softwareentwicklungsteams so begeistert davon, „agil zu werden“, dass sie vergessen, den gesamten Inhalt des Agilen Manifests vollständig zu verstehen. Wir verstehen es — es ist schwer, sich an alle 68 Wörter zu erinnern, wenn man begeistert ist. 🤓

Schauen wir uns das noch einmal an: The article on the right page have a value. Das klingt nicht so, als ob Sie alle Dokumentationen, Prozesse und Tools entfernen sollten. Sie benötigen tatsächlich einige dieser Dinge, um effizient als Team zu arbeiten. The least must to take any art of contract, when they want develop software for a external stakeholder and paid.

Wir würden Ihnen gerne genau sagen, wie viele Prozesse und wie viel Dokumentation und Planung Sie benötigen, aber das können wir nicht. Ein Teil der Agilität besteht darin, die Dinge im Laufe der Zeit anhand Ihrer Teamumgebung und der Bedürfnisse der Kunden zu erkennen. If your agile team ready, start you to check the processes, tools and project documentation and that your team needs to efficient and effective to work.

Wir schauen uns nun einige Lebenszyklusmodelle für agile Softwareentwicklung an.

Das Scrum SDLC model

Erinnerst du dich, dass wir bereits darüber gesprochen haben, dass Wasserfall linear und agil iterativ ist? Scrum ist das perfekte agile Framework, um den Unterschied hervorzuheben.

The traditional water fall model of the product development requires several steps before you going to a final product. Waterfall projects meet the definition of ready, when the complete project is completed and in the hands of users or stakeholders. Es ist linear — ein gerader Weg von Anfang bis Ende.

The agile method of Scrum is dagegen iterativ and adaptiv. Scrum-Teams teilen die Ergebnisse in kleineren Teilen mit kürzeren Zeitrahmen, die als Sprints bezeichnet werden. Es ist das Ziel, bei jeder Iteration während des gesamten Produktentwicklungsprozesses Teile der funktionierenden Software bereitzustellen.

Anstatt eines einzelnen Sprints, wie oben gezeigt, sieht ein vollständiger Scrum-Lebenszyklus eher so aus:

Für jede Iteration plant, entwickelt, überprüft und implementiert das Team Updates der Produktfunktionen. If the involved agreement tests and you see the functional product, they may questions by new priority or requirements. This feedback is added the product backlog, sodass the Product Owner with other functions and work priorisiert wird. Dann beginnt der Prozess erneut.

Da sich die Software ständig weiterentwickelt, wiederholt sich dieser Prozess, bis das Produkt entweder einen Wartungsgrad erreicht hat oder das Ende seiner Nutzungsdauer erreicht und außer Betrieb genommen wird.

Inparticular in Scrum is planning a great part of the SDLC. The Sprint Planning bringt das Team zusammen, um die Arbeit auf der Grundlage der vom Product Owner definierten Sprintziele zu priorisieren. The daily standup provides the team the possible to coordinating his activities for the day. The Sprint-Review ermöglicht es dem Product Owner und anderen Stakeholdern, die während des Sprints Ergebnisse zu überprüfen und zu besprechen. Und schließlich bietet die Sprint-Retrospektive dem Team die Gelegenheit, über den Prozess, die Teamdynamik und mögliche Verbesserungen für die Zukunft nachzudenken.

Reibungslose Sprint-Planung mit

Einfache Agile User Story Maps

Testing now

Verfeinerung des Backlogs is also a art of planning, that should be completed before a sprint planning ession or on end of a sprint. When the verfeinerung can be review the teams the ability specific functions or Ideas for development methods to meet the Acceptance criteria. Sie können auch die Verfügbarkeit von Ressourcen bei der Planung berücksichtigen. Sie könnten beispielsweise erwägen, zusätzliche Komponententests erstellen, um den Aufwand eines Testers zu reduzieren, der während der nächsten Sprints im Urlaub sein wird.

The difference between the planning in Scrum and Waterfall is darin, how much work you want planning. Wasserfallpflanze zu Beginn des gesamten Projekts. The Scrum planning does during the complete product development, from beginning to the end.

Die agile Kanban-Methode

Ein Kanban-Framework hat einen etwas anderen agilen Prozess. Workelemente sind nicht unbedingt miteinander verwandt oder voneinander abhängig. Einzelne Teammitglieder können asynchron arbeiten, um neuen Code in die Produktion einzubringen, sobald er fertig ist. Kanban ist jedoch immer noch iterativ, da die Arbeitselemente in einem Backlog priorisiert werden, und dann werden sie entwickelt, überprüft und zur Produktion gebracht.

Basierend auf dem Feedback der Endbenutzer werden dem Board neue Backlog-Elemente hinzugefügt. The priority of work elements is regular checked and adjusted that they is perfect to the agile value, to react on veränderungen.

Ein großer Unterschied mit Kanban Bedeutet, dass jede Spalte im Kanban-Board nur eine begrenzte Anzahl von Arbeitselementen enthalten kann (WIP-Grenzwerte), anstatt sie auf der Grundlage von Storypoints und Teamgeschwindigkeit zur Arbeit zu verpflichten. This helps Teams, konzentriert zu bleiben, in ihrem Prozess zu erkennen, zu erfahren, wo Automation hilfreich sein könnte, und allgemein zu verstehen, wo ihr Prozess funktioniert und wo er wenig Hilfe benötigt.

Bei Kanban liegt der Fokus mehr auf dem kontinuierlichen Arbeitsfluss in jeder Phase. The WIP border values helps teams to identify specific phases, they behind the work process, that they detect the cause, they detect and last the efficiency work.

Jedes Kanban-Team kann die Spalten auf seinem Board nach seinen Bedürfnissen auswählen. Das Ziel von Kanban ist es, die Geschwindigkeit zu verbessern, indem die Arbeit auf dem Board voranschreitet. A precise monitoring and measurement of movement of work elements is for kanban teams of significant meaning.

Working with the agile software development cycle

Egal, ob Sie in einem ausgerüsteten Unternehmen oder einem Startup-Team arbeiten, eine angemessene Menge an Dokumentation, Tools und Prozessen in agilen Softwareentwicklungsmethoden ist von Wert. Actual helps the facility a agile software development cycle your team, efficient to work.

TIPP! Auf der Suche nach mehr Teamzusammenstellung? Probiere es aus Einfaches agiles Programm

Think you, on the Agile Manifest and The back access Die 12 Prinzipien hinter dem Agilen Manifest wenn du nicht weiterkommst. This values and principles applies not only for the what you build, but also for the work type your team. The key concept behind agile Frameworks contains in, they to check and adapt — both the software as also also the art and way how you work as team.

Use so much process and documentation, how you need, but not more. Schauen Sie sich an, was Sie heute haben, und identifizieren Sie wichtige Punkte, ohne dass das Team Ihrer Meinung nach nicht funktionieren kann. Fügen Sie dann Schritte hinzu oder entfernen Sie sie, wenn Sie herausfinden, wie Ihr Team am besten in einem agilen Framework arbeiten kann.

Bei Easy Agile are here, to help them, the best from your agile Practices, and help them to help them to develop a powerful, agile team. 💪 If you want more learn, look you see our weitere Blogartikel zu agilen Themen.

If you help with the Jira tool by Atlassian, we have einige tolle Apps damit du es versuchst. Unser Simple Agile Programs for the Jira App can support your planning activities by skalable direction and visualization of dependencies.

Testing now