Agiles Projektmanagement für Zwischenstufen: Releases planen, Teams leiten und Erfolg messen

1. Einführung: Hallo und willkommen zur Agile Project Management Sprint Masterclass Agile Project Management Sprint at Scale Wenn Sie die Grundlagen von Agile und Scrum bereits gelernt haben , ist es an der Zeit, den nächsten Schritt zu tun In diesem Kurs gehen wir über das Management eines einzelnen Sprints hinaus und beginnen wie ein Agile-Projektleiter zu denken Mein Name ist Luke Phillips. Ich bin ein Projektmanager mit rund sieben Jahren Erfahrung in der Leitung von Agile-Teams und der Durchführung Projekten in einer Vielzahl von Branchen Im Laufe meiner Karriere habe ich mit Scrum-, Camban- und hybriden Agile-Ansätzen gearbeitet Camban- und hybriden Agile-Ansätzen Teams dabei zu helfen, effektiver zusammenzuarbeiten, sich an sich ändernde Prioritäten anzupassen und konsistent Mehrwert zu In diesem Kurs werde ich die praktischen Techniken vorstellen, die ich verwendet habe, um Projekte über die Grundlagen hinaus zu managen Wir werden uns zunächst das Gesamtbild ansehen, wie einzelne Sprints in Projekt-Roadmaps und Release-Pläne passen Projekt-Roadmaps und Release-Pläne Sie werden lernen, mehrere Sprints zu planen und längerfristige Projektziele mithilfe von Tools wie Nein zu organisieren Als Nächstes werden wir uns eingehender mit Schätzungen und Prognosen befassen Sie werden lernen, wie Agile-Teams Arbeit schätzen, die Geschwindigkeit messen und realistische Vorhersagen treffen, ohne so zu tun, als ob jede Schätzung absolut Wir vergleichen auch Scrum-, Cam Ban- und Hybridansätze, damit Sie verstehen, wann jedes Framework am besten funktioniert und wie Sie Ihren Workflow an verschiedene Arten von Projekten anpassen an verschiedene Arten von Kommunikation ist ein weiterer wichtiger Schwerpunkt dieses Kurses. Sie lernen, mit Stakeholdern zusammenzuarbeiten, mit sich ändernden Anforderungen umzugehen, produktive Prüfungen durchzuführen und den Projektfortschritt klar und effizient zu kommunizieren . Schließlich werden wir uns mit Agile-Kennzahlen befassen und verstehen, was gemessen und was ignoriert werden muss und wie Sie Daten verwenden können, um die Leistung Ihres Teams zu verbessern , anstatt einfach Berichte zu erstellen. Am Ende dieses Kurses verfügen Sie über das Wissen und die praktische Erfahrung, um größere Agile-Projekte zu verwalten, effektiver zu kommunizieren und mit Zuversicht bessere Projektentscheidungen zu mit Zuversicht bessere Projektentscheidungen treffen. Lass uns anfangen. 2. Willkommen beim Fortgeschrittenen-Projektmanagementkurs: Hallo und willkommen zum Agile-Projektmanagement-Kurs für Fortgeschrittene. Wenn Sie bereits ein oder zwei Sprints gelaufen sind und bereit sind, über einen einzigen zweiwöchigen Zyklus hinaus zu denken, ist dieser Kurs genau das Richtige für Sie. Wir zeigen Ihnen, wie Sie mehrere Sprints planen, wie Sie ehrlich und in großem Maßstab abschätzen können, wann Sie sich für Cam Ban statt Scrum entscheiden sollten und wie Sie die Beteiligten auf dem Laufenden halten können, ohne in Status-Updates zu ertrinken In dieser kurzen Eröffnungsstunde gehen wir darauf ein, was Sie bereits wissen sollten bevor Sie mit diesem Fortgeschrittenenkurs beginnen, was dieser Kurs abdeckt und was Sie beachten müssen Also eine kurze Zusammenfassung dessen, was Sie bereits wissen sollten, bevor Sie mit diesem Fortgeschrittenenkurs beginnen Sie benötigen die Grundlagen der agilen Denkweise und des Agile-Manifests Wenn Ihnen irgendetwas davon ungewohnt vorkommt, sollten Sie zunächst Ihre Grundlagen vertiefen, bevor Sie weitermachen Sie sollten also die agile Denkweise und das Manifest verstehen und nicht nur in der Lage sein, die Werte zu rezitieren, sondern sie auch darin erkennen, wie ein Sie sollten die drei Scrum-Rollen, den Product Owner, den Scrum Master und das Entwicklungsteam, kennen und wissen, was jedes Team tut und was Sie sollten sich wohl dabei fühlen, User Stories zu schreiben, Akzeptanzkriterien zu definieren und zu wissen, wann etwas tatsächlich erledigt ist Außerdem solltest du bereits einen Trello- und Notion-Workspace mit einem aufgefüllten Backlog für das Projekt eingerichtet haben, an dem du gerade arbeitest Und am wichtigsten ist, dass Sie mindestens einen Sprint von Anfang bis Ende durchgeführt, geplant, ausgeführt, überprüft und anschließend eine Retrospektive durchgeführt haben sollten mindestens einen Sprint von Anfang bis Ende durchgeführt, geplant, ausgeführt, überprüft und anschließend eine Retrospektive Gelebte Erfahrung ist hier wichtig, weil alles in diesem Kurs auf dieser Grundlage aufbaut Schauen wir uns also an, was dieser Kurs für Fortgeschrittene abdeckt. Wir haben sechs Abschnitte. Die Umstellung erfolgt von einem Sprint auf viele Sprints. Wir werden uns mit der Erstellung von Release-Plänen befassen, die mehrere Sprints miteinander verknüpfen Wir werden uns damit befassen, die Geschwindigkeit richtig einzuschätzen und zu verfolgen. Wir werden uns die Unterschiede zwischen Scrum und Caban ansehen und wie man Wir werden uns mit der Verwaltung von Stakeholdern befassen, ohne bei lebendigem Leib gefressen zu werden, und wir werden uns die Kennzahlen ansehen, die wirklich wichtig sind, und diejenigen, die nicht Am Ende dieses Kurses werden Sie also wissen, wie Sie eine Reihe von Sprints planen und durchführen , die auf etwas Größeres abzielen Und das ist der wichtigste Schritt von der Durchführung einzelner Sprints zur Entwicklung von etwas Sinnvollem mit Agile. Was du brauchst. Hier sind die praktischen Tools. Du benötigst Trello für dein Board. Du benötigst Notion für die Dokumentation. Wenn Sie diese bereits aus früheren Arbeiten eingerichtet haben , können Sie loslegen. Sie werden auch Ihre Projektbeschreibung und Ihren bestehenden Backlog vor sich haben wollen Projektbeschreibung und Ihren bestehenden Backlog vor sich haben Der Großteil dieses Kurses baut auf echter Arbeit auf, sodass Sie das Beste daraus machen werden ihn in jeder Lektion auf ein echtes Projekt anwenden Wir sind also bereit zu beginnen. Danke, dass du zu mir gekommen bist. In der nächsten Lektion werden wir aus einem einzelnen Sprint herauszoomen und uns das Gesamtbild ansehen, wie einzelne Sprints in Releases passen und warum das wichtig ist. Wir sehen uns dort 3. Vom Sprint bis zum Release: Willkommen zurück. In der realen Welt läuft kein Team nur einen Sprint. Sie laufen Dutzende, Hunderte oder bauen auf etwas Größeres zu. Dieses Etwas wird als Veröffentlichung bezeichnet. Am Ende dieser Lektion werden Sie verstehen, was ein Release ist, wie Sprints dazu passen und warum das Denken auf Release-Ebene Ihre Planung verändert Was ist also ein Release? Eine Version ist ein bedeutender Teil der Arbeit, der Benutzern zur Verfügung gestellt wird Nicht nur ein Sprint ist einen Teil wert , von dem es sich lohnt, den Leuten davon zu erzählen Es könnte eine neue Produktversion sein, ein wichtiges Feature, eine Kampagne, die live geht Etwas, das die Außenwelt bemerkt. Bei einem Softwareprodukt könnte eine Version mit dem neuen Dashboard und dem neu gestalteten Onboarding die zweite Bei einer Veranstaltung ist die Veröffentlichung die Veranstaltung selbst. Für den E-Commerce könnte eine Veröffentlichung die Herbst-Produktlinie, alle sechs Produkte, die neue Landingpage und die Marketingkampagne sein. Veröffentlichungen geben Ihrer Arbeit Form. Sie sind die Meilensteine auf der Reise. Wie also Sprints zu Releases führen . Jeder Sprint ist wie ein Sprungbrett. Die meisten Releases dauern also mehrere Sprints. Drei sind üblich, sechs sind nicht ungewöhnlich. Manche Releases können zehn Sprints dauern. Also hier ist die Beziehung. Ein Sprint liefert ein Inkrement, einen kleinen Teil der Arbeitsleistung Ein Release ist eine Sammlung von Schritten, die zusammen etwas Größeres bewirken Also stell es dir so vor. Ihr Sprintziel könnte sein Lernende nach Abschluss der Lektionen Sterne verdienen können Es ist nützlich, aber für sich genommen ist es ein Feature und kein Release Ihr Veröffentlichungsziel könnte Version zwei sein, oh, eine vollständig spielerische Lernerfahrung Diese Version enthält die Sterne plus Streaks plus Badges sowie das übergeordnete Dashboard . Sie haben mehrere Sprints , die zusammen aufgebaut werden. Das ist wichtig , weil sich jeder Sprint wie ein Fortschritt auf dem Weg zur Veröffentlichung anfühlen sollte Wenn Sie nicht sehen können, wie dieser Sprint mit einem Release-Ziel verknüpft ist, machen Sie entweder den falschen Sprint. Oder Sie haben kein klares Veröffentlichungsziel. Warum also auf Release-Ebene denken? Schauen wir uns an, warum das wichtig ist. Es gibt drei Gründe, warum Release-Level-Denken wichtig ist. Erstens interessieren sich die Stakeholder für Releases, nicht für Sprints. Ihrem Manager ist es egal, dass Sie Geschichte 47 letzten Dienstag beendet Ihnen ist wichtig, dass das neue Feature in drei Wochen veröffentlicht wird. in Pressemitteilungen sprechen, verbinden Sie Ihre Sprint-Arbeit mit den Dingen, auf die die Leute tatsächlich warten. Der zweite Grund ist, dass Abhängigkeiten frühzeitig aufgedeckt werden. Wenn Sie drei Sprints zusammen planen, Sie fest, dass Story B davon abhängt, dass Story A zuerst ins Ziel kommt, und dass diese Abhängigkeit unsichtbar ist wenn Sie immer nur einen Sprint gleichzeitig planen Der dritte Grund ist, dass dadurch Ehrlichkeit in Bezug auf das Timing erzwungen wird. Diese Version, die in acht Wochen veröffentlicht wird, ist also eine viel schwierigere Behauptung als dieses Sprintziel. Entweder du glaubst es oder du glaubst es nicht. Bei der Veröffentlichungsplanung wird Wunschdenken aufgedeckt. Also Release-Planung versus Sprint-Planung, etwas unterschiedlicher Rhythmus und unterschiedliche Präzision Eine schnelle Unterscheidung zwischen der Sprint-Planung findet also alle zwei Wochen Die Release-Planung erfolgt einmal pro Version. Die Sprint-Planung ist also detailliert. Sie wählen bestimmte Geschichten aus und verpflichten sich zu ihnen. Sie wissen genau, was Sie in den nächsten zwei Wochen tun werden. Die Veröffentlichungsplanung ist grober. Sie gruppieren Geschichten in Themen und schätzen, wie viele Sprints jedes Thema benötigen könnte Sie ordnen sie an und erstellen einen groben Zeitplan. Beides ist sehr wichtig. Sprint-Planung ohne Release-Kontext führt zu geschäftiger Arbeit. Release-Planung ohne Sprint-Disziplin erzeugt Fantasie. Es gibt also drei Fallen, die man vermeiden sollte, wenn Releases schief gehen. Also einige häufige Fehler beim Release-Thinking. Nummer eins ist Scope Creep. Die Veröffentlichung beginnt mit drei Themen. Bis zum vierten Sprint sind es sechs. Jetzt bist du im Rückstand. Du musst skrupellos sein Alles Neue gehört in die nächste Version, nicht diese. Nummer zwei sind versteckte Abhängigkeiten. Sie stellen nach der Hälfte fest , dass zwei Themen ohne ein drittes nicht veröffentlicht werden können Ermitteln Sie Abhängigkeiten während der Release-Planung, nicht während des Sprints Und drittens ignorieren wir die Realität. Die Geschwindigkeit des Teams sagt fünf Sprints aus, aber die Führung will drei Eine späte Veröffentlichung ist normal. Diese Realität bis zum letzten möglichen Moment zu verstecken , führt dazu, dass Leute gefeuert werden. Also ignoriere das. Danke, dass du zu mir gekommen bist. In der nächsten Lektion werden wir uns mit den drei Planungsebenen befassen , die jedes Agile-Team verwendet, Roadmaps, Releases und Sprints, wie sie sich unterscheiden und wie man sie miteinander verbindet. Also werde ich dich dort sehen 4. Drei Ebenen der Planung: Willkommen zurück. In der letzten Lektion haben wir Releases vorgestellt. In dieser Lektion werden wir das Objektiv noch weiter vergrößern. Jedes Agile-Team plant auf drei Ebenen der Roadmap, dem Release-Plan und dem Ferne sehen sie ähnlich aus, beantworten aber sehr unterschiedliche Fragen Am Ende dieser Lektion werden Sie wissen, wofür sie jeweils gedacht sind und wie Sie sie miteinander in Verbindung halten können, ohne in Plänen zu ertrinken Also die drei Ebenen der Planung. Stellen Sie sich drei konzentrische Kreise vor. Von außen haben wir eine Roadmap, Release-Plan und einen Sprint Die Roadmap ist die äußerste. Es ist die allgemeine Richtung über sechs Monate, 12 Monate, manchmal sogar zwei Darin heißt es: „Das ist die Richtung, in die wir gehen, wenn es um allgemeine Themen geht. Es sind keine spezifischen Funktionen oder Themen. Der Release-Plan ist die mittlere Ebene. Da steht: Hier ist die Hauptlieferung. Es gruppiert bestimmte Funktionen und Themen in einer Version. Und das erstreckt sich normalerweise über ein paar Monate. Sprint ist das Innerste. Es heißt: Genau das werden wir in den nächsten zwei Wochen tun , mit spezifischen Geschichten, engagierter Arbeit, und jedes Level beantwortet eine andere Frage Roadmaps beantworten, wohin wir gehen, Releases geben die Antwort, was ist das nächste große Ding, und Sprints geben die Antwort: Was machen wir gerade? Schauen wir uns also an, was in einer Roadmap enthalten ist. Straßenkarten sind thematisch. Sie zeigen die Richtung , aber keine Verpflichtungen. Ein typischer Fahrplan könnte drei bis fünf Schwimmbahnen mit einer Laufzeit von sechs bis zwölf Monaten vorsehen Jede Spur ist ein Thema. Innerhalb der Gasse haben Sie grobe Arbeitsblöcke, die nach Quartalen oder Monaten sortiert Vermeiden Sie es, bestimmte Daten in den Roadmap-Elementen anzugeben. Bei Straßenkarten geht es um die Richtung und Daten schaffen falsche Gewissheit Beide Quartale sind in Ordnung. Der 15. August ist eine Geisel des Glücks. Roadmaps sind Eigentum des Produkteigentümers oder Produktmanagers und werden häufig geteilt Stakeholder schauen sich die Roadmap an, um zu verstehen, was das Team in diesem Jahr tut Veröffentlichungsplan, der mittlere Kreis. Die Veröffentlichungspläne sind konkreter. Sie machen aus einer Roadmap ein Ergebnis. Ein typischer Release-Plan umfasst also zwei bis sechs Monate. Es listet die wichtigsten Funktionen oder Geschichten der Version in grober Prioritätsreihenfolge auf. Es gibt zwar ein Zieldatum für die Veröffentlichung, aber das Datum ist eher ein Ziel als eine Garantie. Release-Pläne berücksichtigen auch Abhängigkeiten. Story X hängt von Story Y ab. Ohne die Produkte können wir die Startseite nicht versenden Ohne den Veranstaltungsort können wir die Veranstaltung nicht durchführen. All diese Abhängigkeiten müssen auf der Release-Ebene sichtbar sein , auch wenn die Details im individuellen Sprintplan enthalten sind. Diese Pläne werden bei jedem Sprint überprüft. Es sind lebendige Dokumente, die aktualisiert werden, wenn Sie lernen. Und schließlich haben wir den Sprintplan. Das ist detailliert, es ist verbindlich und es dreht sich alles um das Jetzt. Ein Sprintplan umfasst in der Regel zwei Wochen. Es listet bestimmte Geschichten mit Akzeptanzkriterien auf. Es verpflichtet sich zu einem Sprintziel. Es beinhaltet Kapazitäten, Risiken und Abhängigkeiten für die nächsten zwei Wochen Sprint-Pläne sind die genauesten der drei Stufen, da die Arbeit gerade stattfindet, was bedeutet, dass Sie auch spezifisch sein können. Je weiter du planst, desto weniger spezifisch kannst du sein, ohne dich selbst zu belügen. Oh, einige Tipps Sie diese drei separaten Pläne miteinander verbinden können. Die drei Ebenen funktionieren nur, wenn sie miteinander verbunden sind. Der erste Tipp ist also jedes Sprintziel zu einem Release-Ergebnis führen sollte. Wenn ein Sprint nicht auf die Veröffentlichung zusteuert, warum machst du den Sprint dann überhaupt? Nummer zwei: Jede Veröffentlichung sollte einem Roadmap-Thema Wenn eine Veröffentlichung nicht in die Roadmap passt, die Roadmap falsch oder die Veröffentlichung ist falsch Drittens: Überprüfe sie in unterschiedlichen Abständen. Sprint-Pläne alle zwei Wochen, Pläne bei jeder Sprint-Überprüfung, Roadmaps jedes Quartal Viertens: Verwenden Sie in allen dreien dasselbe Vokabular. Wenn auf Ihrer Roadmap Engagement steht und Ihrer Pressemitteilung Absicht steht und in Ihrem Sprint Sterne stehen, dann haben Sie diesen Zusammenhang unterbrochen Stellen Sie sicher, dass die Sprache einheitlich ist. Und der fünfte Tipp lautet: Bewahren Sie sie nach Möglichkeit alle am selben Ort auf. Notion funktioniert sehr gut für diese eine Seite pro Ebene, die alle miteinander verknüpft sind. Okay, drei Ebenen, Roadmap, Release und Sprint, die durch klare Ziele und eine gemeinsame Sprache miteinander verbunden durch klare Ziele und eine gemeinsame Sprache Danke, dass du an dieser Lektion teilgenommen hast. In der nächsten Phase werden wir uns mit der Erstellung eines aktuellen Release-Plans für Ihr Projekt in Notion befassen. Ich werde dich dort sehen. 5. Erstellen Ihres Releaseplans: Hallo und willkommen zurück. In diesem Video schauen wir uns an, wie Sie Ihren ersten Release-Plan erstellen. Wir werden das innerhalb von Notion machen. Zunächst werde ich die Schritte durchgehen, die wir unternehmen werden, um diese Seite zu erstellen, und dann zeige ich Ihnen die gesamte in Notion eingerichtete Seite. Ich zeige Ihnen auch, wie Sie Ihre bidirektionalen Links hinzufügen, die die Veröffentlichung mit dem Sprint verknüpfen Oh, zunächst werden Sie das, was wir erstellen, zu Ihrem bestehenden Notion-Arbeitsbereich hinzufügen Sie werden eine neue Unterseite hinzufügen. Sie werden eine neue Datenbank hinzufügen. Sie werden möglicherweise Seitenvorlagen verwenden. Und dann werden wir uns auch ansehen, wie Sie Ihre bidirektionalen Links hinzufügen, die das Release mit dem Sprint und den Sprint mit dem Release verbinden Sprint und den Sprint mit dem Release erste Schritt besteht darin , den Unterseitentyp Forward Slash-Seite zu erstellen und eine neue Seite namens Release-Plan auf Ihrer Hauptprojektseite zu benennen Release-Plan auf Ihrer Hauptprojektseite Nummer zwei besteht darin, die Datenbank zu dieser Seite hinzuzufügen. Also Schrägstrichtabelle, und dann können Sie die Spalten mit den Namen Name, Veröffentlichungsziel, Zieldatum, Status und Sprint Planned konfigurieren die Spalten mit den Namen Name, Veröffentlichungsziel, Zieldatum, . Die dritte Möglichkeit besteht darin, Ihre erste Version zu füllen. Klicken Sie also auf die Zeile und geben Sie Ihr erstes Veröffentlichungsziel, Ihr Ziel, den Status usw. ein Schritt vier besteht darin, die Release-Seite in fünf Abschnitte mit Ihren Themen, Ihrer Sprint-Aufschlüsselung, den Abhängigkeiten, den Risiken und dem Fortschritt zu strukturieren die Release-Seite in fünf Abschnitte mit Ihren Themen, Ihrer Sprint-Aufschlüsselung, den Abhängigkeiten, den Risiken und dem Fortschritt Und dann besteht Schritt fünf darin, Ihren Sprint zu verknüpfen, was eine bidirektionale Verknüpfung von Version zu Sprint und von Sprint zu Version wäre zu Sprint und von Sprint zu Version Schauen wir uns also das Setup in Notion an. Also habe ich hier unten den Release-Plan für die Seite hinzugefügt, also zeige ich dir, wie das aussehen sollte. Ich habe eine Datenbank hinzugefügt. Wir haben hier die erste Version, die Version 1.0 für mein Projekt, das ein Ed Tech-Projekt ist. Die erste Veröffentlichung ist Game Fide Learning. Ich habe das Veröffentlichungsziel hier. Das Feld, das ich dort ausgewählt habe, ist Text, mit dem ich ab Version 1.0 die Lernenden durch Sterne, Streifen und Avatar-Anpassungen dazu motivieren kann, täglich zurückzukehren Streifen und Avatar-Anpassungen Die nächste Spalte ist das Zieldatum, wobei ich als Eingabe Datum ausgewählt habe Es ist der 14. August 2026, in sechs Wochen, und ich habe auf Status geklickt, das ist das Auswahlfeld, dem Sie dann die verschiedenen Status hinzufügen können Ich habe „veröffentlicht“ und „In Planung “ und dann „Geplante Sprints“ hinzugefügt und dann Diese Eingabe wäre eine Zahl. Ich habe gerade drei eingegeben. Wir haben also drei Sprints für diese Veröffentlichung geplant Schauen wir uns also die Release-Seite an. Wenn Sie also die Release-Seite öffnen, können Sie Ihre Release-Seite dann so strukturieren. Sie enthält bereits alle Informationen aus der Datenbank oben und unten Hier haben wir die Struktur. Wir haben also Themen wie das Belohnungssystem mit Sternen, Serien und Gewohnheiten sowie die Anpassung von Avataren Wir haben eine Sprint-Aufschlüsselung mit dem ersten Sprint und dem Link zum ersten Druck Wir haben den Abschnitt mit den wichtigsten Abhängigkeiten mit einer Entscheidung über die Animationsbibliothek falls dies bis zum Ende des ersten Sprints erforderlich ist, Backend-API-Endpunkte für Star Assistant Design-Assets für Avatar-Optionen Im Grunde haben wir einige Risiken, die Komplexität der Animation könnte in Sprint drei übergehen Die Abmilderung besteht darin, die Spitzen frühzeitig zu erhöhen und dann die Logik, Grenzfälle, versäumte Tage, Zeitzonenänderungen Und ganz unten haben wir den Fortschritt , den Sie während des Sprints eingeben würden während Also, wie füge ich den Link hinzu. Hier habe ich den Link zum ersten Sprint hinzugefügt, das ist das Star-Belohnungssystem. Um das zu tun, fügst du einfach das App-Zeichen hinzu und fängst dann an, den Namen der Seite einzugeben, die als Star Reward-System bezeichnet wird. Sie klicken dort darauf und es fügt den Link hinzu. Und wenn Sie dann auf den Link klicken, gelangen Sie zum Star Reward System Sprint. Und wie Sie sehen können, haben wir die Kapazität. Wir haben die ausgewählten Geschichten, wir haben die Risiken und Abhängigkeiten und das Engagement. Das ist das Detail des Sprints. Und ganz oben habe ich einen Teil des Release-Plans angegeben. Auch hier klicken Sie einfach, um den Link hinzuzufügen . Geben Sie das At-Zeichen ein. Hier können Sie nach einem beliebigen Namen auf jeder Seite suchen, die Sie haben, und Sie können auf diese Seite verlinken. Sie haben hier also einen Release-Plan. Also klicken Sie einfach auf Versionsplan und wir können sehen, dass es da ist. Und das bringt uns zurück zum Release-Plan , den wir auf dieser Seite hier haben. Also lass mich einfach schnell wieder da rein gehen. Ich entferne das. Es ist sehr einfach, Ihre bidirektionalen Links hinzuzufügen. Ich kann das nur empfehlen. Dadurch bleibt alles gut miteinander verknüpft. Das ist also das Ende der Idee, schrittweise Anleitung zur Einrichtung Ihrer Release-Seite. Im nächsten Video haben wir eine kleine Übungsübung, die Ihr Release-Plan wäre. Erstellen Sie also einen Plan mit drei Sprints für Ihr ausgewähltes Briefing. Das ist als Nächstes dran. Wir sehen uns im nächsten. 6. Übung: 3-Sprint-Releaseplan: O Willkommen zurück. Es ist Zeit, alles, was Sie in diesem Abschnitt gelernt haben, in die Praxis umzusetzen. In dieser kleinen Übung werden Sie einen Release-Plan mit drei Sprints für Ihr eigenes Briefing entwerfen für Ihr eigenes Briefing Am Ende haben Sie einen echten Release-Plan, den Sie für den Rest dieses Kurses verwenden können. Ihre Aufgabe besteht aus fünf Schritten. Nehmen Sie sich Zeit, aber quälen Sie sich nicht damit. Der erste Schritt besteht darin, Ihr Veröffentlichungsziel zu definieren. Es sollte aus einem Satz bestehen , der ergebnisorientiert ist, und das ist es, was Sie am Ende von drei Sprints wahr haben wollen am Ende von drei Sprints wahr Schritt zwei besteht darin, drei Themen zu identifizieren. Jedes Thema wird zum Mittelpunkt eines Sprints, und jedes Thema sollte das Veröffentlichungsziel voranbringen. Schritt drei besteht darin, jedes Thema in drei bis fünf Geschichten zu unterteilen , hauptsächlich Geschichten, die bereits in Ihrem Backlog existieren, falls Sie eine haben Schritt vier besteht darin, Abhängigkeiten und Risiken aufzudecken, was zutreffen muss, damit diese Version ausgeliefert Und Schritt fünf besteht darin, ein Zieldatum auszuwählen und realistisch zu sein. Sechs Wochen sind ein guter Ausgangspunkt für eine Veröffentlichung in drei Sprints. Schauen wir uns nun mein funktionierendes EdTech-Beispiel an. So sieht ein gutes Release-Ziel aus und wie ein fertiger Plan für meinen EdTech-Briefing aussehen könnte Das Veröffentlichungsziel ist also, dass ab Version 1.0 Lernende im Alter von vier bis acht Jahren motiviert werden, durch tägliche Sternschnuppen und Personalisierung zurückzukehren . Das erste Thema ist Sprint One, das Belohnungssystem mit Sternen, die Geschichten, Sterne nach dem Unterricht, Sternenanzeige Thema zwei ist der zweite Sprint , der aus Serien und Gewohnheiten besteht Geschichten handelt es sich um den täglichen Streakzähler, Belohnungen für die Serie und die Bearbeitung von Rundenserien Thema drei oder Sprint drei ist dann Bei den Geschichten handelt es sich um den täglichen Streakzähler, die Belohnungen für die Serie und die Bearbeitung von Rundenserien. Thema drei oder Sprint drei ist dann die Avatar-Anpassung. Die Geschichte ist da Wir haben Avatar-Auswahl, Avatar Persistent und Avatar im Unterricht. Einige Abhängigkeiten, die Animationsbibliothek, die am Ende des ersten Sprints ausgewählt wurde, die Risiken bestehen darin, dass eine Streak-Logik komplexer sein könnte als erwartet, und das Zieldatum ist in sechs Wochen Wir müssen einige häufige Fehler vermeiden. Hier sind die großen Drei. Die erste besteht darin, die Veröffentlichung zu groß zu machen. Zum Beispiel ist die App in Version eins perfekt, was bedeutet, dass sie nutzlos ist. Wählen Sie ein kleineres, engeres Ergebnis. Zwei sind, wenn die Themen nicht in einen Sprint passen, wenn es zwei Sprints braucht, es eigentlich zwei Themen, also teilen Sie es Und das dritte ist das Ignorieren von Kapazitäten. Planen Sie Arbeit im Wert von drei Sprints nicht in zwei Sprints ein. Überprüfe deine Geschwindigkeit, auf die wir im nächsten Abschnitt näher eingehen Also ein paar Plausibilitätsprüfungen, bevor du es als abgeschlossen bezeichnest. Erstens: Fühlt sich das Release-Ziel in drei Sprints mit dem Team, das Sie haben, erreichbar drei Sprints mit dem Team, das an? Du musst ehrlich sein. Zweitens, wenn ich nur den ersten Sprint versenden würde, wäre das für sich genommen nützlich? Gute Veröffentlichungen haben frühe Erfolge, nicht nur ein großes Finale. Und Schritt drei: Kann ich jemandem, der das Projekt noch nie gesehen hat, die Veröffentlichung in einem Satz erklären der das Projekt noch nie gesehen hat, die Veröffentlichung in einem Satz ? Falls ja, ist klar, wenn Sie sich qualifizieren, das Ziel nicht eng genug. Speichern Sie also Ihren Begriff zur Release-Planung in der Release-Plan-Datenbank , die Sie in der letzten Lektion erstellt haben , und verknüpfen Sie sie Ihren vorhandenen Sprint-Planungsseiten , sodass die Ebenen miteinander verknüpft sind. Und das ist jetzt Ihr Referenzdokument für die nächsten Abschnitte. Jede Schätzung oder Metriken, Lektion für Stakeholder in diesem Kurs, wird sich also Lektion für Stakeholder in diesem Kurs, darauf beziehen Als Nächstes, in Abschnitt zwei, haben wir es mit Schätzung und Geschwindigkeit zu tun. In diesem Abschnitt haben wir vom ersten Sprint zur Version etwas herausgezoomt , und wir haben den Seitenplan Also danke, dass du zu mir gekommen bist. Im nächsten Abschnitt werden wir uns ernsthaft mit Schätzungen und Geschwindigkeit befassen und mit den Techniken, die Multisprint-Planung tatsächlich glaubwürdig machen Wir sehen uns im nächsten Abschnitt. 7. Warum Schätzungen schwierig und oft falsch sind: Willkommen zurück. Im Projektmanagement Schätzungen zu den schwierigsten Aufgaben eines Teams , und sie gehören zu den am meisten missverstandenen Bevor wir uns im Rest dieses Abschnitts mit den Techniken befassen , müssen wir ehrlich sagen, warum Schätzungen so schwierig Schätzungen Am Ende dieser Lektion werden Sie die Verzerrungen verstehen, die Schätzungen unzuverlässig machen, und wissen, warum sich das ändert wie Sie Schätzungen überhaupt verwenden sollten Zunächst haben wir den Planungsfehler. Fangen Sie also mit dem größten Problem an. Menschen sind schrecklich darin abzuschätzen, wie lange Dinge dauern werden Es gibt eine wohlbekannte kognitive Verzerrung den sogenannten Planungsfehler, der erstmals in den 1970er Jahren von Daniel Carnman und Amos Tversky beschrieben wurde und Amos Tversky Die Feststellung ist einfach. Wenn Menschen abschätzen, wie lange eine Aufgabe dauern wird, unterschätzen sie sie durchweg, nicht um ein bisschen, sondern um viel Studien haben ergeben, dass Menschen immer noch unterschätzen, selbst wenn sie über den Planungsfehler informiert und gebeten werden, ihn zu korrigieren Warum? Denn wenn wir über eine Aufgabe nachdenken, stellen wir uns den idealen Weg vor. Wir stellen uns vor, reibungslos zu arbeiten , ohne Unterbrechungen, ohne Rückschläge, ohne zu entdecken dass die Anforderungen unklar waren Und so sieht die Realität nicht aus. Warum ist unsere Arbeit also schlechter? Nun, der Planungsfehler gilt für alles, aber einige Arten von Arbeit sind schwieriger abzuschätzen als andere Und leider fällt das meiste, was wir tun, in die schwierigere Kategorie Sie malen zum Beispiel einen Zaun, können Sie ziemlich gut einschätzen. Du hast es schon einmal gemacht. Es ist eine körperliche Aufgabe mit sichtbaren Fortschritten, und es gibt ein paar Unbekannte Wenn Sie jedoch Software entwickeln, eine Kampagne durchführen oder eine Veranstaltung organisieren, ist alles anders Jede Aufgabe ist ein bisschen neu. Sie lösen oft ein Problem, das Sie noch nie zuvor gelöst haben. Anforderungen ändern sich, wenn Sie lernen, treten Abhängigkeiten auf, mit denen Sie nicht gerechnet haben, und Sie stellen nach der Hälfte fest , dass der von Ihnen gewählte Ansatz nicht funktioniert Und Sie müssen etwas anderes ausprobieren. Deshalb sind unsere Schätzungen bei dieser Art von Arbeit in der Regel falsch, nicht weil wir schlecht schätzen können, sondern weil die Arbeit selbst von Natur aus unberechenbar ist Also einige häufig vorkommende Vorurteile bei Schätzungen. Neben dem Planungsfehler gibt es noch einige andere Vorurteile , über die es sich Die erste ist die optimistische Voreingenommenheit. Wir gehen davon aus, dass die Dinge auch dann gut laufen werden , wenn die Vergangenheit etwas anderes aussagt. Sie vergessen, wie Ihre Schätzung die letzten drei Mal explodiert ist, konzentrieren sich stattdessen auf die Zeiten, in denen sie funktioniert hat . Als Nächstes geht es ans Ankern Die erste Zahl, die in einer Diskussion erwähnt wird zum Anker, zu dem sich alle hingezogen fühlen. Wenn Ihr Manager sagen würde, dass das in zwei Wochen erledigt sein könnte? Plötzlich fühlen sich zwei Wochen vernünftig an , unabhängig davon, ob es wirklich so ist oder nicht. Der nächste ist sozialer Druck. Niemand möchte die Person sein, die sagt, dass dies sechs Monate dauern wird , und das in einem Raum voller eifriger Interessengruppen. Die Schätzungen schwanken also leise nach unten , um dem zu entsprechen, was die Leute hören wollen. Und zuletzt haben wir den Kegel der Ungewissheit. Zu Beginn eines Projekts, wenn Sie am wenigsten wissen, sind Ihre Schätzungen am wenigsten zuverlässig. Aber das ist normalerweise auch der Zeitpunkt, an dem die Leute sie am meisten wollen. Der Kegel wird schmaler , je mehr man lernt, aber die frühesten Schätzungen sind im Grunde Vermutungen Also, was das für Ihre Schätzung bedeutet. Also drei praktische Implikationen. Erstens: Behandeln Sie Schätzungen als Bereiche, nicht als Punkte. Das dauert 2-5 Sprints, das ist ehrlicher als das, dass es drei Sprints braucht Jede einzelne Schätzung verbirgt Ungewissheit . Zweitens: Vergleicht eure Schätzungen mit der Realität. Mit der Zeit werden Sie herausfinden, welche Vorurteile Ihr Team tatsächlich hat. Wenn Sie ständig um 40% unterschätzen, können Sie damit beginnen, dies zu korrigieren, aber Sie können nicht korrigieren, was Sie nicht messen Drittens: Verwenden Sie Schätzungen für die Planung und nicht für erfolgversprechende Ergebnisse. Das ist die größte Veränderung. Eine Schätzung ist ein Instrument, um Entscheidungen darüber zu treffen, woran gearbeitet werden soll. Es ist keine Verpflichtung, an einem bestimmten Datum zu liefern. In dem Moment, in dem aus einer Schätzung ein Versprechen wird, haben Sie die Ehrlichkeit gebrochen , die sie nützlich macht. Warum führen wir immer noch Schätzungen durch? Warum sich die Mühe machen? Angesichts all dessen wundern Sie sich vielleicht, warum Sie sich die Mühe machen, zu schätzen. Um fair zu sein, ist das eine faire Frage, aber die Antwort ist, dass selbst schlechte Schätzungen helfen Sie zwingen dich, über die Arbeit nachzudenken. Sie bringen Unbekanntes ans Licht. Sie geben Ihnen grobe Größen, um Optionen zu vergleichen. Das ist also definitiv größer als das, was nützlicher ist als die genauen Zahlen. den Techniken, die wir im Rest dieses Abschnitts behandeln werden es nicht nur darum, genaue Schätzungen zu erstellen. Niemand erstellt ständig wirklich genaue Schätzungen. Es geht darum, nützliche Schätzungen zu erstellen, Schätzungen, die als Grundlage für Entscheidungen dienen , die ehrliche Gespräche erzwingen , die ehrliche Gespräche erzwingen und die mit der Zeit besser Sie verfolgen, wie sie im Vergleich zur Realität abschneiden. Okay, Schätzungen sind schwierig, aber ehrlich zu sein, ist der erste Schritt, um es gut zu machen . Danke, dass du zu mir gekommen In der nächsten Lektion werden wir uns eingehend Story Points befassen, was sie sind, wie man sie einsetzt und wie man die Fallen vermeidet, in die die meisten Teams tappen . Ich werde dich dort sehen 8. Story-Punkte: Tieftauchen: Willkommen zurück. Story Points sind die gängigste Schätzmethode in Agile, aber sie werden auch am häufigsten missverstanden In dieser Lektion werden wir etwas tiefer gehen als die Oberflächenebene Wir werden uns ansehen, was Story Points wirklich sind, warum sie funktionieren und welche spezifischen Praktiken sie eher nützlich als performativ machen sie eher nützlich als performativ Was sind also Story Points? Sie sind eine Einheit zur Messung der relativen Größe eines Werkes. Sie kombinieren drei Dinge wie viel Aufwand eine Geschichte erfordert, wie komplex sie ist und wie viel Unsicherheit sie mit sich bringt. Fünf-Punkte-Geschichte ist ungefähr fünfmal so groß wie eine Ein-Punkt-Story, nicht fünfmal so viele Stunden, fünfmal so groß. Aufwand, Komplexität und Unbekanntes werden alle zu einer Zahl zusammengefasst Der Punkt ist, dass menschliche Gehirne viel besser darin sind, Größen zu vergleichen als absolute Dauern abzuschätzen Fragen Sie jemanden, wie lange eine Aufgabe in Stunden dauern wird, wird ihn wahrscheinlich fragen, ob sie größer oder kleiner als eine andere Aufgabe ist, wird es normalerweise richtig machen Also die Fibonacci-Sequenz richtig erklärt. Die meisten Teams verwenden die Fibonacci-Sequenz eins, zwei, drei, fünf, acht, 13, 21, manchmal 40 und Für diese spezielle Reihenfolge gibt es zwei Gründe. Erstens werden die Lücken größer, je größer die Zahlen werden. Der Unterschied 1—2 ist gering. Der Unterschied 13-21 ist riesig. Und das spiegelt echte Unsicherheit wider. Wenn etwas klein ist, kann man es tatsächlich deutlich sehen. Wenn etwas groß ist, verstehst du es wahrscheinlich nicht gut genug, um eine Acht von einer Neun zu unterscheiden. Zweitens zwingen die großen Lücken zu Entscheidungen. Sie können nicht auf dem Zaun zwischen zwei benachbarten Zahlen sitzen. Entweder es ist eine Fünf oder eine Acht, diese erzwungene Wahl beschleunigt die Schätzung und verhindert endloses Debattieren Verankern Sie also Ihre Referenzgeschichte . Die wichtigste Methode bei der Verwendung Story Points ist die Auswahl einer guten Referenzstory. Das ist der Anker, eine Geschichte die jeder im Team gut kennt und von der Sie sich alle einig sind, dass eine bestimmte Größe hat, normalerweise zwei oder drei. Jede andere Schätzung bezieht sich auf diese Referenz. Eine kleine Referenzgeschichte , die klein genug ist, um leicht verstanden zu werden, gut dokumentiert und bereits geliefert, sodass sich jeder daran erinnern kann, wie es gelaufen ist. Wenn Sie dann eine neue Geschichte einschätzen, die Frage nicht, wie groß diese abstrakt ist. Es geht darum, wie sich das mit unserer Referenz vergleichen lässt? Wenn Ihr Team in Ihrer Projektstory über das Verdienen von Sternen für den Abschluss einer Lektion schreibt, stimmt One zu, dass das eine Drei war. Wenn Sie sich dann eine neue Geschichte wie das Hinzufügen von Streifen ansehen, fragen Sie sich, ist das größer oder kleiner als die Sterne Um wie viel, zweimal um die Hälfte. Ohne eine Referenzgeschichte beginnen die Schätzungen zu schwanken. Bei jedem Sprint bedeuten sie etwas anderes und die Zahlen Laufe der Zeit nicht mehr vergleichbar. Poker richtig planen. Story Points funktionieren am besten, wenn sie vom gesamten Team geschätzt werden. Poker ist die klassische Technik, aber lassen Sie mich tiefer gehen als nur auf die Oberfläche. Jeder im Team erhält einen Kartensatz mit den Fibonacci-Zahlen Der Product Owner liest die Geschichte vor. Das Team stellt kurz klärende Fragen. Dann wählt jede Person heimlich eine Karte aus und alle enthüllen sie gleichzeitig. Der kritische Moment ist, wenn die Schätzungen nicht übereinstimmen. Nehmen wir an, drei Personen sagten drei und eine Person sagte acht, dann ist das nicht nur ein Durchschnittswert Nimm nicht einfach den höchsten oder niedrigsten Wert. Bitten Sie die Ausreißer um eine Erklärung. In neun von zehn Fällen weiß die Person, die acht geschätzt hat, etwas , was die anderen nicht wissen Vielleicht gibt es eine Abhängigkeit, eine Komplexität oder einen Fehler in der Vergangenheit, an den sie sich erinnern, und dieses Wissen muss an die Oberfläche kommen. Sobald sie es geteilt haben, schätzen es alle anderen neu. Die Zahl konvergiert dann normalerweise. Wenn Sie alleine arbeiten, sind Sie das gesamte Team, was bedeutet, dass Sie besonders streng sein müssen Versuchen Sie, dieselbe Geschichte im Abstand von einem Tag zu schätzen und zu vergleichen. Achten Sie auf Konsistenz. Ihre erste errötende Schätzung ist oft ziemlich optimistisch. Welche Storypoints oder nicht? Einige häufige Missverständnisse. Wenn Sie diese falsch verstehen, werden Storypoints ziemlich nutzlos Erstens sind Story Points keine Stunden. Zehn Story Points bedeuten nicht 10 Stunden oder zehn Tage oder eine bestimmte Zeit. Die Beziehung zwischen Punkten und Zeit zeigt sich erst über mehrere Sprints und nur für dieses bestimmte Team Zweitens sind Story Points keine Leistungskennzahl. Wenn Ihnen jeder sagt, dass das Team 40 Punkte pro Sprint erzielen sollte , haben sie das falsch verstanden Story Points dienen der Planung. Sie sind kein Stock , mit dem man Teams schlagen kann. Drittens sind Story Points zwischen Teams nicht vergleichbar. fünf von Team A sind nicht dasselbe wie die fünf von Team B , da Storypoints auf die spezifische Referenzgeschichte eines Teams abgestimmt sind und nur innerhalb dieses Teams von Bedeutung Viertens sind die Storypoints nicht festgelegt. Wenn sich herausstellt, dass eine Geschichte, die Sie auf drei geschätzt haben, viel umfangreicher ist, als Sie dachten, aktualisieren Sie die Schätzung nicht rückwirkend Sie lassen die Schätzung unverändert und verwenden die Differenz, um zukünftige Schätzungen zu verbessern Wenn Story Points nicht funktionieren, also nicht immer das richtige Tool für jede Situation sind. Es gibt drei Situationen , in denen Sie sie möglicherweise nicht benötigen. Sehr kleine Teams, die sehr ähnliche Arbeiten ausführen. Wenn du alleine bist und jede Geschichte ungefähr gleich ist, brauchst du keine Punkte. Zähle einfach Geschichten. Sehr variable Arbeit, wenn ein Sprint aufwändiger Feinschliff ist und der nächste ein leichter Feinschliff. Punkte werden nicht vergleichbar sein, Cam Ban mit dem Radteam , das könnte besser funktionieren. Jede Situation, in der die Schätzung verwendet wird, um ein Datum zu versprechen. Wenn die Unternehmensleitung Ihre Gesamtpunktzahl nimmt und daraus eine Frist macht, wird diese Technik missbraucht Es ist besser, überhaupt keine Schätzungen vorzunehmen , als einen kaputten Prozess voranzutreiben Richtig umgesetzte Story Points sind ein leistungsstarkes Planungstool. Schlecht gemacht, können sie zu Verwirrung führen. Danke, dass Sie sich mir bei dieser Lektion angeschlossen haben. In der nächsten Folge schauen wir uns an, was Story Points bei mehreren Sprints und beim Tracking der Geschwindigkeit möglich machen mehreren Sprints und beim Tracking der Geschwindigkeit möglich Wir sehen uns dort. 9. Verfolgen der Geschwindigkeit über Sprints hinweg: Willkommen zurück. Nachdem wir die wichtigsten Punkte behandelt haben, können wir über die Metrik sprechen, die sie ermöglichen, nämlich die Geschwindigkeit. Geschwindigkeit ist eine der mächtigsten und häufigsten missbrauchten Metriken in Agile In dieser Lektion werden wir uns damit befassen, was Geschwindigkeit ist, wie man sie gut verfolgt und wie man sie nützlich hält, und wie man sie nützlich hält ohne dass sie gefährlich wird Also, was Geschwindigkeit eigentlich ist. Geschwindigkeit ist einfach. Es ist die Gesamtzahl der Story Points ein Team in einem einzigen Sprint abschließt. Das Team beendete vier Storys mit drei, fünf , fünf und acht Punkten. Die Geschwindigkeit für diesen Sprint betrug 21. Beachten Sie, dass die Geschwindigkeit nur abgeschlossene Storys zählt. Alles, was am Ende des Sprints übrig bleibt , zählt nicht, und das ist gewollt Was am wichtigsten ist, ist die abgeschlossene Arbeit. Teilweise Anerkennung fördert genau das Verhalten Sie nicht möchten, wie zum Beispiel das Anhäufen von halb erledigter Arbeit Sie berechnen die Geschwindigkeit für jeden Sprint. Im Laufe der Zeit erhalten Sie eine Reihe von Zahlen, die zeigen, wie viel Ihr Team durchweg liefert. Also sehr nützlich. Warum es wichtig ist. Es gibt drei Gründe, warum Geschwindigkeit wertvoll ist, sobald Sie Daten im Wert von ein paar Sprints haben Erstens hilft es bei der Sprint-Planung. Wenn Ihre Durchschnittsgeschwindigkeit 25 Punkte beträgt, legen sich im nächsten Sprint nicht auf 40 Punkte fest, da Sie sonst scheitern werden. Sie werden sich überanstrengen und Ihre zukünftigen Schätzungen werden durch diesen falschen Datenpunkt vergiftet Zweitens ermöglicht es Prognosen. Wenn Ihre verbleibende Version 100 Arbeitspunkte hat und Ihre Geschwindigkeit 25 beträgt, sind Sie ungefähr vier Sprints entfernt Genau, aber genug, um echte Pläne zu schmieden. Drittens, es gibt Probleme mit der Bedienung. Ein plötzlicher Geschwindigkeitsabfall ist ein Signal. War jemand krank? Haben Sie ungewöhnlich komplexe Arbeiten übernommen? Brennt das Team aus? Geschwindigkeitsdaten führen zu den richtigen Gesprächen. Wie kann man es gut verfolgen? Also praktische Anleitung. Ignorieren Sie zunächst die ersten drei Sprints. Die Anfangsgeschwindigkeit jedes Teams ist unzuverlässig. Sie sind immer noch dabei, Ihre Story-Point-Größen zu kalibrieren. Ihre Referenzstory stabilisiert sich. Drei Sprints geben also ungefähr an, wie lange es dauert, bis die Zahlen aussagekräftig werden Zweitens: Verwenden Sie einen gleitenden Durchschnitt, nicht einen einzigen Sprint. Schauen Sie sich Ihre letzten drei oder fünf Sprints und nehmen Sie den Durchschnittswert Dadurch werden Geräusche von Sprint zu Sprint geglättet. Ein einziger Sprint mit Geschwindigkeit 40 bedeutet nichts , wenn Ihr gleitender Durchschnitt bei 25 liegt Drittens: Verfolge ihn sichtbar. Ein einfacher Tisch funktioniert. Fügen Sie Ihrem Notion-Workspace ein Velocity-Protokoll mit einer Zeile pro Sprint hinzu. Spalten, Sprintnummer, geplante Punkte, abgeschlossene Punkte und alle Notizen darüber, warum der Sprint so verlief, wie er lief. Mit der Zeit werden diese Daten zu Gold. Viertens: Überprüfe sie bei jedem Sprint. Schauen Sie sich in Ihrer Retrospektive Ihren Geschwindigkeitstrend an, nicht um ihn zu kalibrieren oder zu beschimpfen, sondern nur um Muster sondern nur Wir haben in jedem der letzten drei Sprints verloren. Warum ist das so? Du wirst es herausfinden können. Als Nächstes haben wir die Gefahren der Geschwindigkeit. Geschwindigkeit ist mächtig, aber sie kann auch leicht missbraucht werden. Es gibt vier Gefahren, über die Sie Bescheid wissen sollten. Erstens: Geschwindigkeit als Ziel. In dem Moment, in dem Geschwindigkeit ein Ziel wird, hört sie auf zu messen, was Sie zu tun glaubten. Teams übertreiben ihre Story-Point-Schätzungen. Plötzlich ist eine Geschichte, die eine Drei war, eine Fünf, Geschwindigkeit steigt, obwohl sich eigentlich nichts geändert hat Zweitens: Geschwindigkeitsvergleiche zwischen Teams. Team A erzielt 40 Punkte. Team D hat 25. Team B sieht faul aus, aber vielleicht schätzen sie es einfach anders. Vielleicht ist ihre Arbeit wirklich schwieriger. Vergleichen Sie niemals die Geschwindigkeit zwischen Teams. Drittens: Geschwindigkeit als Produktivität. Hohe Geschwindigkeit ist nicht dasselbe wie hoher Wert. Ein Team könnte 100 Punkte mit Funktionen bereitstellen , die niemand nutzt. Story Points messen Größe, nicht aber Wert. Und für Geschwindigkeit, die früher Scham war. In zu vielen Organisationen wird Geschwindigkeit zu einem Knüppel , mit dem Führungskräfte Teams unter Druck setzen. Dadurch wird die Ehrlichkeit zunichte die die Kennzahl überhaupt erst nützlich macht. So bringen Sie mehr Geschwindigkeit in Ihren Arbeitsbereich. Dies könnte eine neue Notion-Unterseite mit vier Spalten sein. Öffnen Sie also Ihren Notion-Arbeitsbereich, fügen Sie eine neue Unterseite zu Ihrer Hauptprojektseite nennen Sie sie Velocity Log Fügen Sie auf dieser Seite eine Datenbank mit vier Spalten hinzu, Sprint-Nummer eine Zahl ist. Geplante Punkte als Zahl, abgeschlossene Punkte als Zahl und Notizen als Text. Füllen Sie eine Zeile pro Sprint aus, wenn Sie sie abgeschlossen haben. Wenn Sie bereits ein oder zwei Sprints hinter sich haben, können Sie sie jetzt wieder auffüllen, denn selbst grobe historische Daten sind nützlicher als nichts, und im Laufe der Zeit werden diese Daten zum Gedächtnis Ihres Teams Jetzt können die Teammitglieder die Geschichte sehen, Rückblicke können auf die Daten verweisen und Prognosen können auf der Realität basieren. Also absolutes Gold für ein Projekt. Die Geschwindigkeit kann jedoch zu einigen Schwankungen führen. Einige Teams haben von Sprint zu Sprint eine stark variable Geschwindigkeit Wenn du das bist, gerate nicht in Panik. Dafür gibt es drei häufige Ursachen. Erstens, Ihre Referenzgeschichte ändert sich ständig. Korrigieren Sie die Referenz, verankern Sie eine Geschichte, an die sich jeder erinnert. Zweitens ist Ihre Sprintlänge inkonsistent. Wenn einige auf zwei Wochen sprinten und andere auf eine Woche, wird die Geschwindigkeit natürlich variieren Lege einfach die Länge des Sprints fest. Drittens, du machst bei jedem Sprint völlig unterschiedliche Arbeiten Manche Sprints sind schwer gebaut, andere sind Tests. Also sind sie nur polnisch In diesem Fall sind Story Points möglicherweise nicht das richtige Tool für Ihr Team. Wir werden Caban als Alternative im nächsten Abschnitt behandeln. Velocity ist ein echtes Prognoseinstrument, aber wenn es schlecht eingesetzt wird, wird es zum Theater Stellen Sie also sicher, dass Sie es richtig verwenden , denn wenn es richtig verwendet wird, kann es zu Gold werden Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Version setzen wir Velocity ein und prognostizieren, wie viele Sprints Ihr Release tatsächlich dauern wird. Wir sehen uns dort O 10. Vorhersage der Freigabe: Willkommen zurück. Alles, was bisher in diesem Abschnitt stand, war die Grundlage. Jetzt werden wir es in die Tat umsetzen. In dieser Lektion erfahren Sie, wie Sie die Frage beantworten können, die sich jeder Interessent irgendwann stellt: Wie lange wird das dauern Am Ende werden Sie wissen, wie Sie eine vertretbare und ehrliche Prognose erstellen können, ohne so zu eine vertretbare und ehrliche Prognose tun, als ob Sie in die Zukunft schauen Die grundlegende Berechnung, diese eine Rechenlinie, ist ziemlich einfach, die Summe verbleibenden Punkte geteilt Wenn Ihr Release also noch 100 Storypoints zu erledigen hat und die durchschnittliche Geschwindigkeit Ihres Teams 25 Punkte pro Sprint beträgt, dann benötigen Sie ungefähr 100/25, was vier Sprints entspricht Das ist einfach und für die meisten Zwecke zuverlässig genug Aber es steckt noch ein bisschen mehr dahinter, denn die Berechnung hängt von zwei Zahlen ab, die beide mit einer gewissen Unsicherheit behaftet sind. Die Gesamtpunktzahl und die Geschwindigkeit. Wenn Sie eine dieser Angaben falsch verstehen, ist auch die Prognose falsch. Wir beginnen also mit der Gesamtpunktzahl. Dies setzt voraus, dass Sie jede Geschichte in der Veröffentlichung geschätzt haben. In der Praxis haben Sie das selten getan. Manche Geschichten sind gut verstanden, aber manche sind immer noch vage und manche existieren vielleicht noch gar nicht Es gibt diese alte Regel in Agile nicht alles im Backlog wird geschätzt Nur die Geschichten , die im Backlog fast ganz oben stehen , werden richtig geschätzt Geschichten weiter unten oder Platzhalter, Ideen oder sogar Wünsche Wenn Sie also Prognosen erstellen, sollten Sie ehrlich sagen, was Ihre Gesamtpunktzahl tatsächlich bedeutet Handelt es sich um eine Summe gut geschätzter Geschichten oder handelt es sich um eine Mischung aus soliden Schätzungen und groben Vermutungen Hier ist eine nützliche Übung für Geschichten, für die noch keine Schätzungen vorliegen Fügen Sie anhand der durchschnittlichen Story-Größe Ihres Teams einen Platzhalter Wenn deine Geschichten fünf Punkte haben, verwende fünf Punkte für alles , was vage ist Es ist besser als nichts, aber kennzeichnen Sie es in der Prognose ausdrücklich Problem mit der Geschwindigkeit. Was die Geschwindigkeit angeht, ist Ihre Durchschnittsgeschwindigkeit nur nützlich, wenn die Zukunft wie die Vergangenheit aussieht, und oft ist sie es nicht. Teammitglieder fahren in Urlaub, neue Leute kommen hinzu, die Arbeit wird schwieriger , je mehr Sie sich mit den komplexeren Geschichten auseinandersetzen , die ganz oben im Backlog stehen Es entstehen Abhängigkeiten , die die Dinge verlangsamen. Eine ehrlichere Prognose verwendet eine Spanne anstelle einer einzelnen Zahl. Sie schauen sich also Ihre letzten fünf oder sechs Sprints an, und die niedrigste Geschwindigkeit ist Ihr schlimmster Fall Der höchste Wert ist dein bester Fall. Durchschnitt ist Ihr Mittelfall. Geben Sie dann drei Zahlen an. Im besten Fall sind drei Sprints. wahrscheinliche Fall sind vier Sprints, und der schlechteste Fall sind sechs Sprints Das ist weitaus ehrlicher, als vier Sprints zu sagen und dann so zu tun, als wüsstest du es also mit den Stakeholdern sprechen, hier sind einige Regeln für das Gespräch mit den Stakeholdern, denn die Art und Weise, wie Sie Ihre Prognose kommunizieren, ist genauso wichtig wie die Zahlen selbst Geben Sie keine einzige Zahl an. Sag nicht, dass es in sechs Wochen versendet wird. Das endet immer schlecht. Die Realität stimmt nie mit einer einzigen Punktschätzung überein. Geben Sie jedoch einen Bereich mit explizitem Kontext an. Basierend auf unserer aktuellen Geschwindigkeit wird diese Version 4-6 Sprints dauern, wahrscheinlich aber fünf Dieser Bereich setzt voraus, dass es keine Teamwechsel und keine größeren Überraschungen Wir werden die Sprint-Schätzung bei jedem Sprint verfeinern , sobald wir mehr erfahren. Nennen Sie Ihre Annahmen explizit. Dies setzt voraus, dass wir keine anderen Prioritäten übernehmen . Das setzt voraus , dass Sie niemanden verlieren. Dies setzt voraus, dass die Schätzungen, die uns vorliegen, in etwa korrekt sind, und die Beteiligten können diese Annahmen dann Das ist genau die Konversation, dass Sie die Prognose bei jedem Sprint aktualisieren. Eine neue Prognose liefert Ihnen aktuelle Daten Kommunizieren Sie die Änderung offen. Vor zwei Wochen habe ich zum Beispiel von vier bis sechs Sprints gesprochen. Basierend auf diesen Sprint-Daten sieht es jetzt wie fünf bis sieben aus, und das normalisiert Niemand erwartet, dass eine Prognose vor Monaten gemacht wurde, immer noch korrekt ist Hier sind einige häufige Fehler, die Sie vermeiden sollten. Man geht davon aus, dass die Geschwindigkeit stabil ist, was sie auch ist. Manche Sprints sind schlechter als andere, deshalb verwenden wir Bereiche und keine Durchschnittswerte Zweitens: Sie vergessen die Arbeit, die nichts mit der Story , Bugfixes, Besprechungen, Verwaltung, technische Schulden all das zwischen den Kapazitäten, sind aber oft nicht in Ihrer Story-Point-Gesamtsumme enthalten, also sollten Sie sich darauf einstellen Drittens, vorausgesetzt, das Team kann schneller arbeiten, wenn wir alle am Wochenende arbeiten, werden wir in drei Sprints liefern Das ist völlige Fantasie. Geschwindigkeitsmessung ist nachhaltiges Tempo. Überstunden sind nicht skalierbar und entsprechen auch nicht der Realität Viertens: Abhängigkeiten außerhalb des Teams werden ignoriert. Wenn Ihre Veröffentlichung von der Entscheidung eines anderen Teams, eines Anbieters, eines Kunden oder eines Stakeholders abhängt , ist Ihre Prognose nur so gut wie deren Machen Sie die Abhängigkeit in der Prognose sichtbar. Was ist also, wenn Ihre Prognose unerwünscht ist? In diesem Fall musst du sowieso ehrlich sein. Manchmal widerspricht Ihre ehrliche Prognose also den Wünschen der Führung, und das passiert ständig. Was machst du in solchen Situationen? Ehrlichkeit ist die beste Politik. Basierend auf unserer Geschwindigkeit sieht das nach einer Veröffentlichung mit sechs Sprints aus. Ich weiß, du wolltest drei. Lass uns darüber reden, was wir tun könnten, um das zu erreichen. Legen Sie sich niemals still und leise auf ein Datum fest, das Sie nicht erreichen können. Das verschafft dir keine Zeit. Das verschiebt einen Misserfolg einfach auf einen späteren Zeitpunkt , wo es nur noch mehr wehtut. Wenn der Druck stark ist, schreiben Sie ihn schriftlich. Wir waren uns einig, dass wir es drei Sprints versucht haben . Das zu verstehen, liegt weit unter unserer Durchschnittsgeschwindigkeit und würde bedeuten, X, Y und Z fallen zu lassen. Das schützt alle, falls der Zeitplan nicht eingehalten wird. Eine Prognose ist also kein Versprechen. Es handelt sich um eine wohlüberlegte Schätzung, die auf den besten Daten basiert Sie uns mit Ehrlichkeit und Ehrlichkeit über ihre Grenzen mitgeteilt haben. Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Übung werden wir diese Übung zusammenstellen, und Sie werden Ihre eigene Freisetzung schätzen und eine reale Prognose erstellen. In der nächsten sehen wir uns. 11. Übung: Schätzung und Prognose: Willkommen zurück. Es ist an der Zeit, alles aus diesem Abschnitt in eine richtige praktische Übung zu bringen. Sie werden die Geschichten in Ihrer Pressemitteilung einschätzen, eine echte Prognose erstellen und diese so kommunizieren , dass sie mit echten Stakeholdern funktioniert. Am Ende haben Sie eine belastbare Prognose für Ihren Release-Plan, tatsächlichen Daten basiert Richten Sie also zunächst Ihren Workspace ein , öffnen Sie Notion und Trello Auf deinem Trello hast du also dein Board und du hast deinen Notion-Arbeitsbereich oder deine Dokumentation, du wirst mit beiden arbeiten Wenn Sie es noch nicht getan haben, fügen Sie in Notion eine Velocity-Log-Unterseite hinzu, eine einfache Datenbank mit vier Spalten Anzahl der Sprints, geplante Punkte, abgeschlossene Punkte und Notizen. Wenn Sie bereits ein oder zwei Sprints gelaufen sind, füllen Sie Ihr Geschwindigkeitsprotokoll mit dem was Sie in diesen Sprints tatsächlich erreicht haben, auf Grobe Schätzungen hier sind in Ordnung. Etwas ist besser als nichts. auf deinem Trello-Board sicher, dass alle Stories in deiner aktuellen Version sichtbar sind Wenn sie über den gesamten Backlog verteilt sind, gruppiere sie irgendwie, vielleicht mit einem Label wie Release 1.0 Auf diese Weise können Sie den gesamten Umfang an einem Ort einsehen. Als Nächstes müssen Sie Ihre Referenzgeschichte auswählen. Das ist der Anker, an dem alles andere hängt. Das ist der erste Schritt der Übung. Schauen Sie sich also die Geschichten an, die Sie bereits abgeschlossen haben , und wählen Sie eine aus, die klein und gut verstanden ist und an die sich jeder erinnern kann. Ganz klar. Das ist dein Anker. Weisen Sie ihm einen Punktwert zu. Zwei ist eine gute Standardeinstellung. Schreiben Sie jetzt auf, was es zu einer Zwei macht So etwas ist eine einfache Änderung der Benutzeroberfläche, die ein paar Stunden gedauert hat , ohne Unbekannte und ohne Abhängigkeiten. Es sind unsere beiden Diese Beschreibung wird Ihnen helfen, in Zukunft andere Schätzungen zu kalibrieren Schätzen Sie jede Geschichte in Ihrer Veröffentlichung im Verhältnis zu Ihrer Referenzstory Gehen Sie also Ihre Geschichten nacheinander durch. Fragen Sie bei jeder Geschichte, ob diese größer oder kleiner ist als meine Referenz? Wie viel größer? Wählen Sie eine Fibonacci-Zahl, eins, zwei, drei, fünf, acht, 13 oder 21. Ein paar Tipps. Wenn Sie zwischen den Zahlen zögern, wählen Sie die größere Optimistische Vorurteile sind real. Wenn sich eine Geschichte also wie eine Acht anfühlt, schätze acht. Wenn sich eine Geschichte wie eine 21 oder größer anfühlt, hören Sie auf, sie ist zu groß und teilen Sie sie in kleinere Geschichten auf und schätzen Sie diese dann ab. Wenn du die Geschichte wirklich nicht gut genug verstehst , um sie einzuschätzen, markiere sie als verfeinerungsbedürftig Raten Sie nicht, denn das wird Ihnen falsches Selbstvertrauen geben. Streben Sie zehn oder 20 geschätzte Geschichten an, aber versuchen Sie nicht, den gesamten Rückstand in dieser Version abzuschätzen , den gesamten Rückstand in dieser Version Füge deinen Kostenvoranschlag als Beschriftungen zu den Kartenbeschreibungen auf Trello hinzu, damit er sichtbar bleibt Schritt drei besteht darin, alles zusammenzuzählen. Summieren Sie die Punkte für all Ihre geschätzten Geschichten. Dies ist Ihre Gesamtsumme für die Veröffentlichung. Schau dir dein Geschwindigkeitsprotokoll an. Wenn Sie Daten aus früheren Sprints haben, nehmen Sie einen gleitenden Durchschnitt Wenn Sie noch keine Daten haben, ist das in Ordnung. Sie können anhand der Ergebnisse Ihres ersten Sprints eine grobe Schätzung vornehmen , oder Sie können abschätzen, was ein realistischer Sprint Ihrer Meinung nach bewirken wird. Teilen Sie die Gesamtzahl der Release-Punkte durch Ihre Geschwindigkeit, und das ist Ihre grundlegende Prognose. Führen Sie nun die Reichweitenberechnung durch, dividieren Sie durch Ihre niedrigste Geschwindigkeit für den besten Fall durch Ihre höchste Geschwindigkeit für den schlechtesten Fall, und Sie erhalten eine korrekte Spanne. Das Schreiben der Prognose in Notion ist der nächste Schritt, und das ist der wichtigste Teil. Öffnen Sie Ihren Versionsplan in Notion unter Ihrer Fortschrittsüberschrift oder fügen Sie einen neuen Plan namens Prognose hinzu. Schreiben Sie Folgendes. Der Prognosebereich in Sprints, bester Fall, wahrscheinlicher Fall, schlimmster Fall, der Datenbereich, dem diese Sprints entsprechen Wenn ein Sprint zwei Wochen dauert, vier Sprints acht Wochen ab Schreiben Sie also die Annahmen auf, die Sie getroffen haben, die Verfügbarkeit des Teams, keine Änderungen des Umfangs, keine größeren Überraschungen, keine Verfeinerung der Schätzungen Die letzte Sache ist das Konfidenzniveau auf drei Sprints mit Geschwindigkeitsdaten basiert, mittleres Konfidenzniveau oder niedriges Konfidenzniveau, das auf einem Sprint basiert niedriges Konfidenzniveau, das auf einem Sprint Dies ist Ihr Prognosedokument, und das würden Sie mit allen Beteiligten teilen Es ist echt, es ist ehrlich und es ist vertretbar. Goldene Daten Bevor Sie es als erledigt bezeichnen, gibt es drei Überprüfungen, die Sie wirklich durchführen sollten. Erstens, fühlt sich die Prognose richtig an? Wenn es drei Sprints sagt und dein Bauchgefühl sechs sagt, solltest du deinem Bauchgefühl wirklich vertrauen Entweder mit Ihren Schätzungen oder Ihrer Geschwindigkeit stimmt etwas Ihren Schätzungen oder Ihrer Geschwindigkeit Zweitens, könnte ich das vor einem Stakeholder verteidigen? Wenn jemand die Zahlen in Frage stellen würde, könntest du ihn durch das Training führen? Falls ja, dann ist es gut. Wenn nicht, müssen Sie weitere Details hinzufügen. Drittens, was würde meine Meinung ändern? Wenn eine neue Abhängigkeit auftaucht oder wenn das Team schrumpft oder wenn sich die Geschichte als viel größer herausstellt, werden sie durch Benennung sichtbar Sie haben jetzt also eine echte und ehrliche Prognose für Ihre Veröffentlichung Also speichere das und aktualisiere jeden Sprint. Vielen Dank, dass Sie sich mir für diesen Abschnitt angeschlossen haben. Im nächsten Abschnitt werden wir uns mit Scrum, Canban und der Wahl des richtigen Ansatzes für die Arbeit befassen, die Sie tatsächlich ausführen. Ich werde dich dort sehen 12. Scrum im Überblick: Wann es funktioniert, wann es nicht funktioniert: Willkommen zurück. In dieser Lektion werfen wir einen ehrlichen Blick auf Scrum und fassen kurz zusammen, was es ist Scrum ist das am häufigsten verwendete Agile-Framework der Welt und das aus gutem Grund, aber es ist nicht das richtige Tool für jede einzelne Situation Am Ende dieser Lektion werden Sie also wissen, wo Scrum wirklich glänzt und wo es still und leise gegen Sie arbeitet und wie Sie die Warnsignale erkennen können, dass es möglicherweise nicht zu die Warnsignale erkennen können, dass es möglicherweise Ihrem Projekt passt Okay, eine kurze Zusammenfassung von Scrum, zusammengefasst Stellen wir einfach sicher, dass wir hier alle auf derselben Wellenlänge sind. Falls Scrum neu für Sie ist, hier ist das Ganze in nur 1 Minute Scrum organisiert die Arbeit in Blöcke fester Länge, sogenannte Sprints, die in der Regel ein bis zwei Wochen lang sind Sie planen einen Sprint, verpflichten sich zu einer Reihe von Aufgaben und schützen das Team vor Änderungen während dieses Sprints Am Ende überprüfen Sie, was Sie aufgebaut haben, und überlegen, wie es gelaufen ist , und dann wiederholen Sie alles erneut Drei Rollen: ein Product Owner, der entscheidet, was in welcher Reihenfolge gebaut wird, Scrum Master, der dem Team hilft, gut zu arbeiten und Hindernisse zu beseitigen , und das Team, das die Arbeit tatsächlich erledigt Es gibt eine Handvoll regelmäßiger Treffen, die Planung am Anfang, einen kurzen täglichen Check-In und am Ende die Überprüfung und eine Retrospektive die Planung am Anfang, einen kurzen täglichen Check-In und am Ende die Überprüfung und eine Retrospektive . Das ist Scrum. Es ist ein fester Rhythmus mit klaren Rollen und einer Verpflichtung bei jedem Sprint Scrum ist also unter den richtigen Bedingungen brillant, und hier funktioniert es wunderbar Erstens, wenn Ihre Arbeit einen Sprint im Voraus geplant werden kann, wenn Sie am Montag vernünftigerweise entscheiden können , was Sie in den nächsten vierzehn Tagen aufbauen werden, und diese Entscheidung meistens gilt, bietet Ihnen Scrum einen Zweitens, wenn die Arbeit in sprint-große Teile passt, Entwicklung einer neuen Funktion für unsere Sprachlern-App für Kinder, wie z. B. lässt sich die Entwicklung einer neuen Funktion für unsere Sprachlern-App für Kinder, wie z. B. eine Reihe von Vokabeltests, gut in Geschichten unterteilen, die Sie innerhalb eines Sprints beenden können Und das ist das ideale Gebiet für Scrum. Drittens, wenn Ihre Stakeholder Wert auf Berechenbarkeit legen, bedeutet der feste Rhythmus , dass jeder weiß es am Ende jedes Sprints etwas zu sehen Für einen nervösen Stakeholder dieser regelmäßige Herzschlag sehr beruhigend Und viertens, wenn das Team stabil und engagiert ist, geht Scrum von einer konsistenten Gruppe von Personen aus, die sich auf ein von Personen Wenn das stimmt, entwickelt das Team einen Rhythmus und ein gemeinsames Tempogefühl Schauen wir uns an, wo das Scrum-Framework Probleme hat. Scrum fängt also an, Sie in einigen häufig auftretenden Situationen zu bekämpfen. Die erste ist unterbrechungsorientiertes Arbeiten. Wenn Ihr Tag von dringenden Dingen dominiert wird , die unvorhersehbar eintreffen, wie Support-Probleme oder Live-Vorfälle, dann scheitert die Idee, sich für zwei Wochen auf einen festen Plan Der Plan ist am Dienstag veraltet . Der zweite ist, dass die Arbeit nicht still steht. Wenn sich die Prioritäten wirklich mehrmals pro Woche ändern, nicht weil Ihre Stakeholder schwierig sind, sondern weil die Situation wirklich so fließend ist, dann wird eine Sprint-Planung zu einer Fiktion, die Sie am Ende ständig neu schreiben werden Die dritte ist Arbeit, die nicht in die Sprintbox passt. Manche Aufgaben sind winzig und konstant. Manche sind groß und langsam. Wenn es sich bei Ihrer Arbeit einen chaotischen Strom völlig unterschiedlicher Größe handelt, das zu ordentlichen zweiwöchigen Verpflichtungen führt das zu ordentlichen zweiwöchigen Verpflichtungen mehr Reibung als Und das vierte ist, wenn sich die Zeremonien hohl anfühlen. Wenn Ihre tägliche Überprüfung zu einem Statusbericht für einen Manager geworden ist und Ihre Retrospektive alle zwei Wochen dieselben Beschwerden hervorbringt , ohne dass sich etwas ändert, dann ist Ihnen das Framework Schauen wir uns also einige Warnsignale an, die darauf hinweisen, dass Scrum Woher weißt du, dass Scrum die falsche Lösung ist? Halten Sie nach diesen verräterischen Anzeichen Ausschau. eins unterschreibst, überträgst du am Ende fast jedes Sprints einen Workover Das gelegentliche Überlaufen ist normal, aber wenn unvollendete Geschichten immer wieder in den nächsten Sprint einfließen, bedeutet Ihr Engagement nichts Zeichen zwei: Planung fühlt sich an wie Theater. Sie machen die Regeln der Sprintplanung durch, aber jeder weiß, dass der Plan innerhalb weniger Tage zunichte gemacht wird Wenn niemand dem Plan vertraut, warum erstellen Sie ihn dann überhaupt? Unterschreiben Sie drei. Änderungen kommen ständig mitten im Sprint an, und du lässt sie immer wieder einfließen. Scrum soll den Sprint schützen. Wenn Sie den Sprint alle paar Tage neu verhandeln, haben Sie eigentlich keine Zeichen vier, das Team fürchtet sich vor den Zeremonien . Treffen, die einen Mehrwert bieten, werden nicht verärgert. Treffen, die zu einem Ritual geworden sind, tun es. Ihre Teamgröße am Standort einer anderen Planungssitzung, das sind Daten. Keines dieser Anzeichen bedeutet, dass Sie versagt haben. Sie bedeuten, dass das Tool und die Arbeit nicht mehr zusammenpassen, und das ist es wert, ernst genommen zu werden. Scrum ist also keineswegs der einzige Weg. Also hier sind Dinge, die viele Teams vermissen. Scrum ist nicht agil. Scrum ist eine Möglichkeit, agil zu sein. Agile ist die Denkweise, früh Mehrwert zu schaffen, auf Veränderungen zu reagieren und sich kontinuierlich zu verbessern Scrum ist eine beliebte Reihe von Praktiken, die diese Denkweise unterstützen Es ist nicht die einzige. Wenn Scrum zu Ihrem Projekt passt, wunderbar. Nutze es gut. Aber wenn Sie den Warnsignalen gefolgt sind, ist dies ein weiterer Ansatz, mit dem unvorhersehbare, fließende, unterbrechungsbedingte Arbeit weitaus besser bewältigt fließende, unterbrechungsbedingte Arbeit weitaus Es heißt Kanban, und das ist es, wo wir als Nächstes hingehen werden. Scrum ist also ein sehr mächtiges Framework, aber nur, wenn die Arbeit dazu passt Zu wissen, wann dies nicht der Fall ist, ist ein Zeichen von Reife und nicht von Misserfolg Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Phase werden wir uns eingehend mit Kanban befassen und erfahren, wie es mithilfe von Flow- und Arbeitsfortschrittsgrenzen genau die Art von Arbeit erledigt, mit der Scrum zu genau die Art von Arbeit erledigt, mit der kämpfen hat. Wir sehen uns dort 13. Kanban Deep Dive: WIP-Grenzen und -Ablauf: Willkommen zurück. In dieser Lektion werden wir uns mit Caban befassen, dem auf Arbeitsabläufen basierenden Ansatz Wenn es bei Scrum nur um Rhythmus und Engagement geht, es bei Cam Ban um Flow und Limits Am Ende dieser Lektion werden Sie verstehen, wie ein Cam Ban-Board aussieht, was Grenzen für den Arbeitsfortschritt sind und warum Sie mehr erreichen können, wenn Sie bewusst weniger auf einmal tun . Lassen Sie uns darauf eingehen. Camban stammt also aus japanischer Herstellung, wo es ein optisches Signal oder eine Karte bedeutet In unserer Welt ist es eine Möglichkeit, Arbeit als kontinuierlichen Fluss und nicht in festen Sprints zu verwalten kontinuierlichen Fluss und nicht in festen Sprints In Cam Ban gibt es keine Sprints. Es gibt keine Verpflichtung zu einer zweiwöchigen Arbeit. Stattdessen fließt die Arbeit durchgängig von links nach rechts, ein Punkt nach dem anderen, und das Team nimmt neue Arbeit auf, wann immer es in der Lage ist, sie zu übernehmen Und das ist der Kern der Sache. Camban hat drei Kernpraktiken. Visualisieren Sie Ihre Arbeit begrenzen Sie, an wie viel Sie gleichzeitig arbeiten und verwalten Sie den Arbeitsablauf, damit die Arbeit weitergeht Wir nehmen jeden von ihnen nacheinander vor. Beginnen Sie also zunächst mit der Visualisierung der Arbeit. Ein Cam Ban-Board besteht aus einer Reihe von Spalten, und jede Spalte ist eine Phase, die die Arbeit durchläuft Hier ist ein typisches fünfspaltiges Brett für unsere Sprachlern-App für Kinder. Ganz links haben wir den Rückstand, alles, was wir tun könnten, in der Reihenfolge der Priorität Als Nächstes müssen wir die kleinen Dinge erledigen , die bereit sind, abgeholt zu werden Dann in Bearbeitung, woran gerade aktiv gearbeitet wird, dann die Arbeit überprüfen, die erledigt ist und darauf wartet, überprüft zu werden und schließlich erledigt zu werden, was bedeutet, abgeschlossen und verifiziert zu werden. Jede Arbeit ist eine Karte, und sie bewegt sich im Laufe der Zeit nach rechts durch diese Spalten Auf einen Blick kann jeder genau sehen, wo sich alles befindet, und diese Sichtbarkeit allein ist schon viel wert Aber die wahre Macht von Camban kommt vom Nächsten. Das sind Grenzen des Arbeitsfortschritts. Also sieh dir die Tafel noch einmal an. Beachten Sie die kleinen Zahlen auf den beiden Spalten. In Bearbeitung hat ein Limit von drei. Die Überprüfung hat ein Limit von zwei. Dabei handelt es sich um Grenzwerte für den Arbeitsfortschritt oder WIP-Grenzwerte für Kurzfilme WIP bedeutet einfach Working Progress. Alles, was du angefangen , aber noch nicht beendet hast. Ein WIP-Limit ist eine Obergrenze dafür wie viele Elemente gleichzeitig in einer Spalte enthalten sein können Wenn ein Limit für „In Bearbeitung“ ein Limit von drei hat, darf das Team höchstens an drei Dingen aktiv arbeiten, nicht an vier, nicht an zehn Drei. Nun, hier ist, was das in der Praxis bedeutet. Wenn „In Bearbeitung“ voll ist und Sie eine Karte fertig haben, beginnen Sie nicht sofort mit etwas Neuem zu tun. Zuerst schaust du dir an, ob etwas feststeckt , und hilfst dabei, weiterzumachen Sie nehmen nur dann neue Arbeit , wenn wirklich Platz dafür ist Das Limit konzentriert das Team darauf, Dinge zu beenden , bevor neue Dinge beginnen Nun, das fühlt sich zunächst vielleicht etwas kontraintuitiv an Sicherlich bedeutet mehr Dinge gleichzeitig zu tun, mehr Dinge zu erledigen, aber in Wirklichkeit ist es das Gegenteil, und es lohnt sich zu verstehen, warum Warum also weniger mehr ist. Drei Gründe, warum Sie durch die Begrenzung laufender Arbeiten schneller und nicht langsamer werden. Der erste Grund: weniger Umschalten. Jedes Mal, wenn Sie mit einer anderen Aufgabe jonglieren, zahlen Sie Kosten für den Wechsel zwischen ihnen. Du verlierst deinen Platz, du lädst den Kontext neu, du machst mehr Fehler Ein Team mit fünf Dingen, die unterwegs sind, wechselt ständig Ein Team mit drei Spielern ist jeweils früher fertig. Zweitens werden Engpässe sichtbar. Wenn die Bewertung auf zwei begrenzt ist und voll ist, fließt keine Arbeit mehr hinein Es ist kein Problem, das zu verstecken. Das ist nur ein Signal. sagt dir genau , wo der Stau ist damit das Team ihn überfallen und löschen kann Ohne Grenzen häuft sich die Arbeit einfach unsichtbar an. Und drittens: Die Arbeit ist beendet, eine Karte, die halb fertig ist, bringt nichts Sie ist nur dann wertvoll, wenn sie fertig ist und in den Händen von jemandem liegt. Einschränkung von Arbeit und Fortschritt zwingt das Team dazu , alle Dinge den Weg zu bringen, anstatt viel anzufangen und wenig zu beenden Sogar ein grobes Gesetz steckt dahinter. Je mehr Dinge Sie gleichzeitig in Bearbeitung haben, desto länger dauert es, bis sie fertig sind. Weniger Dinge im Flug bedeuten eine schnellere Lieferung, und das ist das ganze Spiel von Caban Also ziehen, nicht drücken. Das gibt Caban seinen prägenden Rhythmus Zieh, nicht drück. In einem Push-System wird Ihnen die Arbeit übertragen, unabhängig davon, ob Sie bereit sind oder nicht. Ihr Stichwort wächst einfach. In einem Pull-System nehmen Sie nur dann neue Aufgaben an , wenn Sie die Kapazitäten dafür haben. Die WIP-Grenzwerte setzen dies automatisch durch. Wenn eine Spalte Platz hat, ziehen Sie das nächste Element hinein Wenn sie voll ist, tut man es nicht . Das ist der Unterschied zwischen einer Küche, in der sich Bestellungen schneller anhäufen, als die Köche bewältigen können, und einer, in eine neue Bestellung erst aufgenommen wird, wenn ein Koch frei Pull sorgt dafür, dass das gesamte System in einem nachhaltigen Tempo Der Gedankenwechsel, der im Mittelpunkt von Cam Ban steht, ist also Fluss, nicht Verpflichtung. Cam Ban rät Ihnen, sich auf den Flow zu konzentrieren , nicht auf eine Sprint-Verpflichtung, sondern auf den Flow und den reibungslosen, stetigen Arbeitsablauf von links nach rechts. Es gibt keine Sprints, du fragst nicht , worauf wir uns in diesen zwei Wochen festlegen werden Du fragst, ich arbeite fließend, und wo bleibt es hängen? Sie messen zum Beispiel, wie lange es dauert, bis eine Karte das Brett von Anfang bis Ende durchquert, und wir werden später im Kurs auf diese Durchflussmessungen zurückkommen . Im Moment ist die Denkweise, die Änderung der Denkweise der wichtige Teil von der Festlegung auf eine Charge hin zur Aufrechterhaltung eines stetigen diesem Grund eignet sich Cam Ban so gut für unterbrechungsgetriebene und unvorhersehbare, sich ständig ändernde Arbeit sich ständig ändernde Es gibt keinen festen Plan, um zu explodieren. Es gibt nur das Nächstwichtigste. Es wurde reingezogen, wenn Platz dafür ist. Caban ist also täuschend einfach. Man visualisiert die Arbeit, begrenzt laufende Arbeit und lässt sie fließen Aber diese wenigen Ideen können die Art und Weise, wie ein Team Ergebnisse erzielt, verändern. Vielen Dank, dass Sie sich mir bei dieser Lektion angeschlossen haben. In der nächsten Folge werden wir Schritt für Schritt gemeinsam ein echtes Cam-Ban-Board in Trello erstellen , sodass du genau sehen kannst, wie das alles zusammenkommt. Wir sehen uns dort 14. Einrichten eines Kanban-Boards in Trello: Willkommen zurück. In dieser Lektion werden wir in Trello ein Cam Ban-Board von Grund auf neu erstellen. Trello ist also Es läuft in deinem Browser und alles, was wir heute tun, funktioniert mit dem kostenlosen Tarif, ohne dass kostenpflichtige Funktionen und keine Add-Ons erforderlich sind Am Ende dieser Lektion haben Sie also einen funktionierenden Cambabard mit fünf Spalten für Ihr Projekt, komplett mit Grenzwerten für den Arbeitsfortschritt Fangen wir also an. Schauen wir uns schnell an, was wir bauen werden. Hier ist der Plan. Wir werden ein Board mit fünf Listen erstellen, von links nach rechts, dem Backlog to do do in Bearbeitung, Überprüfung und fertig zwei dieser Listen, die gerade bearbeitet und überprüft werden, gelten Grenzwerte für in Bearbeitung befindliche Aufgaben, die festlegen, wie viele Karten gleichzeitig darin gespeichert werden können Ich werde es Schritt für Schritt erklären und dir dann zeigen, wie es in Trello aussehen sollte Also zuallererst die WIP-Grenzkonvention. Hier ist einer der Nachteile des kostenlosen Trello-Kontos. Es gibt keine integrierte Funktion, die Sie physisch daran hindert einer auf drei begrenzten Spalte eine vierte Karte hinzuzufügen Stattdessen verwenden wir eine einfache, aber zuverlässige Konvention , die nichts verwendet. Wir setzen das Limit einfach direkt in den Namen der Liste. Anstatt also „In Bearbeitung“ zu heißen, wird es „In Bearbeitung“ heißen, WIP drei Schauen wir uns also an, wie das Board aussehen sollte. Also hast du deinen Backlog. Ich habe vier Karten zu dieser hinzugefügt. habe mit einer Karte zu tun, ich habe Ding , bei der es ein Arbeitsfortschrittslimit von drei gibt. Da sind drei Karten drin. Wir haben eine Überprüfung mit einem Limit für den Arbeitsfortschritt von zwei, und da sind zwei Karten drin, und ich habe eine Spalte mit zwei weiteren Karten . Das ist alles. Das ist ein einfaches Caban-Board. Also sehr schnell, Beschriftungen und Ziehen funktionieren, das ist wahrscheinlich der wichtigste Teil eines jeden Caban-Boards Wenn das Team bereit ist, etwas zu beginnen, sollte es die Karte von „Zu erledigen“ in „In Bearbeitung“ oder „Zu tun“ ziehen erledigen“ in „In Bearbeitung“ oder „Zu tun Achte auf das Limit. In Bearbeitung ist auf drei begrenzt Bevor also jemand eine vierte Karte hineinzieht, hält er an und fragt, ob wir etwas fertigstellen oder blockieren können , das schon da ist Arbeit wird von links nach rechts bewegt, ein Zug nach dem anderen, und sie wird nur dann in eine Spalte verschoben wenn diese Spalte Platz hat So können wir zum Beispiel den Fortschritts-Badge aus dem Backlog von rechts nach links in die Aufgabenliste verschieben den Fortschritts-Badge aus dem Backlog von rechts nach links in die So einfach ist das. Es ist eine sehr intuitive App. Zum Glück ist sie sehr einfach zu bedienen, Trello. Aber auch hier ist Caban ein ziemlich einfaches Konzept. Bevor wir einige häufige Fehler beheben, sollten Sie sich zunächst daran erinnern, das Limit nicht zu überspringen Ein Board ohne Limit für den Arbeitsfortschritt ist im Grunde nur eine schicke Liste mit zusätzlichen Spalten. Das Limit für den Arbeitsfortschritt ist ein Konzept von Caban, also überspringe es nicht, sonst ist es kein Caban-Board mehr Zweitens: Erledigte Arbeit zu einem Friedhof werden lassen. So getan heißt wirklich fertig und verifiziert. Wenn es nicht überprüft wird, muss es weiterhin überprüft werden, und es sollte erst verschoben werden, wenn es entweder vom Product Owner oder vom Projektmanager geprüft und genehmigt wurde entweder vom Product Owner oder vom Projektmanager geprüft und genehmigt Product Owner oder vom Projektmanager Und schließlich zu viele Spalten. Fünf sind also genug für den Anfang. Sie müssen nicht für jeden winzigen Schritt eine Spalte hinzufügen. Füge erst später eine Stufe hinzu, wenn tatsächlich eine echte fehlt, sonst sorgen die zusätzlichen Spalten für viel Arbeit und das Board wird auch etwas unübersichtlicher. Also, das ist es. Wir haben uns angesehen, wie man in ein einfaches Cambmbard von Grund auf neu baut Es ist ein sehr einfaches Konzept. Es ist auch sehr einfach, es in Trello zu bauen. Mit dem kostenlosen Tarif ist das sehr, sehr einfach zu bewerkstelligen. Bei den professionellen Konten erhalten Sie die WIP-Limits für jede Spalte, und Sie erhalten natürlich auch einige andere Funktionen im kostenpflichtigen Konto In der nächsten Lektion werden wir uns also Hybridmodelle ansehen, was ein bisschen von beidem ist Also eine Mischung aus Scrum und Caban, was auch als Scrumban bekannt ist, und wir werden es auf Agile zuschneiden, damit es zu der Art und Weise passt, wie Ihr Also das ist als Nächstes dran. Danke, dass du mich bei dieser Lektion unterstützt hast. Wir sehen uns in der nächsten. 15. Hybridmodelle: Scrumban und maßgeschneiderter Ansatz: Willkommen zurück. In dieser Lektion werden wir über Hybriden sprechen und Agile Methoden kombinieren und anpassen, damit sie zu Ihrem Team passen Insbesondere werden wir uns mit Scrumban befassen, der beliebtesten Mischung aus Scrum und Cam Am Ende werden Sie also verstehen, was Scrumban ist, wenn es hilft, und die eine Regel, die verhindert, dass hybride Ansätze zu einem kompletten Chaos werden . Fangen wir mit einer Denkweise an. Scrum und Cam Ban sind keine Religionen. Sie sind Werkzeugsätze Niemand verleiht Ihnen eine Medaille dafür dass Sie sich perfekt an ein Framework halten, und niemand, der vernünftig ist, wird Ihnen sagen, dass Ihre Arbeitsweise falsch ist, nur weil sie ein bisschen von beidem enthält. Echte Teams sind mit realen und spezifischen Situationen konfrontiert, manchmal passt Scrum pur, manchmal passt Caban pur, und sehr oft liegt die beste Lösung irgendwo dazwischen Der Rhythmus von Scrum mit der Ablaufsteuerung von Camban, dass Hybriden im Zwischenraum leben und die gängigsten Scrumban ist genau das, wonach es sich anhört: Scrum plus Caban. Sie behalten einen Teil der nützlichen Struktur von Scrum und fügen die Flow-Tools In der Praxis hält ein Scrumban-Team normalerweise einen regelmäßigen Rhythmus ein, etwa einen zweiwöchigen Rhythmus, und hält nützliche Zeremonien wie ein Planungsgespräch und eine Retrospektive wie ein Planungsgespräch und eine Anstatt sich jedoch für die gesamten zwei Wochen auf einen festen Arbeitsblock festzulegen, arbeiten sie nach einem Board im Cam-Ban-Stil mit Grenzen für den Arbeitsfortschritt und ziehen kontinuierlich neue Arbeit hinzu, wenn Kapazitäten frei werden sie nach einem Board im Cam-Ban-Stil mit Grenzen für den Arbeitsfortschritt und ziehen kontinuierlich neue Arbeit hinzu, wenn Kapazitäten frei werden. So bekommen Sie durch die regelmäßige Planung und Reflexion den Herzschlag und den Rhythmus von Scrum, zusammen mit der Flexibilität von Cam Ban, dem pullbasierten Ablauf , der Veränderungen bewältigt Für viele Teams ist diese Kombination der wahre Clou. Also, wenn Scrumban tatsächlich hilft, wann sollten Sie nach Scrumban greifen? Es gibt drei häufige Situationen. Erstens, wenn Ihr Team einen Rhythmus haben möchte, Ihre Arbeit aber unberechenbar ist. Nehmen wir zum Beispiel an, unser App-Team zum Sprachenlernen trifft sich gerne alle zwei Wochen, um zu planen und zu reflektieren, aber die Hälfte ihrer Arbeit besteht aus dringenden Bugfixes , die ohne Vorwarnung eintreffen. Scrumban ermöglicht es ihnen, den vierzehntägigen Rhythmus beizubehalten gleichzeitig die Unterbrechungen über ein Flow-basiertes und gleichzeitig die Unterbrechungen über ein Flow-basiertes Board zu bewältigen. Zweitens, wenn Sie von Scrum zu Cam Ban wechseln, ist es verwirrend, den Gang eines Teams zu wechseln, in dem über Nacht gearbeitet wird . Scrumban ist eine sanfte Brücke. Sie halten an den vertrauten Zeremonien fest, während Sie Grenzen für den Arbeitsfortschritt und Pull einführen, und das Team Drittens: Wenn das Engagement von Scrum weiter sinkt, Sie aber die Struktur nicht verlieren wollen, wenn Sie bei jedem Sprint ein Workout durchführen, Sie aber die Planung in der Retrospektive verpassen würden, können Sie mit Scrumban die starre Verpflichtung fallen lassen und gleichzeitig die Teile behalten, die ursprünglich hilfreich waren wenn Sie bei jedem Sprint ein Workout durchführen, Sie aber die Planung in der Retrospektive verpassen würden, können Sie mit Scrumban die starre Verpflichtung fallen lassen und gleichzeitig die Teile behalten, die ursprünglich hilfreich waren . Also Tailoring jenseits von Scrumban, Scrumban ist der berühmte Hybrid, aber Tailoring geht noch aber Tailoring geht noch weiter. Hier sind ein paar andere sinnvolle Anpassungen, die Teams häufig vornehmen. Sie können Scrum ausführen, aber Ihrem Board Grenzen für den Arbeitsfortschritt hinzufügen, sodass das Team die Arbeit beendet, bevor es mit weiteren anfängt, auch innerhalb eines Sprints Du kannst Cam Ban ausführen, aber eine leichte, regelmäßige Schrittfrequenz hinzufügen, wie zum Beispiel einen kurzen Rückblick jeden Freitag So haben die Beteiligten immer noch einen vorhersehbaren Zeitpunkt, um sich über die Fortschritte zu informieren, und Sie können Zeremonien , die ihren Unterhalt nicht verdienen Wenn Ihr täglicher Check-In wirklich nichts zu einem kleinen Team beiträgt , das bereits ständig miteinander spricht, dann ist es in Ordnung, es zweimal pro Woche zu machen und zu sehen, was passiert Es geht darum, das zu behalten, was hilft , und stillschweigend zu entfernen , was nicht hilft Es gibt also eine Regel, nämlich bewusst zuzuschneiden. Dadurch bleibt das alles gesund. Ändern Sie die Dinge bewusst und überprüfen Sie das Ergebnis. Es gibt einen großen Unterschied zwischen Tailoring und Drift. Schneidern ist eine bewusste Entscheidung. Wir streichen die feste Verpflichtung weil sie immer wieder versagt, und wir schauen einmal im Monat nach, ob sich der Ablauf verbessert hat Drift gibt die schwierigen Dinge einfach still und leise auf, weil sie sich unwohl fühlen es keinen Plan und keine Überprüfung gibt Wenn Sie also Ihren Prozess anpassen, sollten Sie drei Dinge tun. Benennen Sie die Änderung, vereinbaren Sie, warum Sie die Änderung vornehmen und legen Sie einen Zeitpunkt fest, an dem Sie zurückblicken und fragen können, ob sie tatsächlich geholfen hat. Wenn ja, behalten Sie sie bei, wenn nicht, ändern Sie sie erneut. Diese Gewohnheit und die gezielte Änderung und Überprüfung des Ergebnisses sind Agile selbst Das Framework ist nur der Ausgangspunkt, aber Agile ist die Denkweise Hybriden wie Scrumban on sind also Kompromisse. Da draußen ist kein Cop Wenn sie bewusst gemacht werden, sind sie oft am ehrlichsten und passen dazu unser Team wirklich funktioniert. Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten werden wir all das zusammenstellen und herausfinden, wie Sie das richtige Framework für Ihr eigenes Projekt auswählen das richtige Framework für können. In der nächsten sehen wir uns. 16. Wählen Sie den richtigen Rahmen für Ihren Brief: Willkommen zurück. Wir haben uns Scrum bei Camban und Hybridmodelle wie Scrumban angesehen Camban und Hybridmodelle wie Nun die praktische Frage, wie wählt man eigentlich? In dieser Lektion gebe ich Ihnen eine kurze Reihe von Fragen, die Sie sich zu jedem Projekt stellen können, und dann werden wir sie gemeinsam für unsere Sprachlern-App für Kinder durcharbeiten , sodass wir zu einer echten Empfehlung gelangen können. Zuallererst gibt es also keine allgemeingültige Antwort. Lassen Sie uns diesen Mythos von Anfang an beenden. Jeder, der Ihnen sagt, dass Scrum immer Recht hat oder dass Cam Ban immer Recht hat , verkauft Ihnen etwas Das richtige Framework hängt ganz von Ihrem Kontext ab, von der Art Ihrer Arbeit, davon, wie vorhersehbar sie ist und was Ihre Stakeholder benötigen Das gleiche Team könnte Scrum für ein Projekt und Cam Ban für ein anderes verwenden ein Projekt und Cam Ban für ein anderes Anstatt also einen Favoriten auszuwählen und Ihre Arbeit dazu zu zwingen, zu ihm zu passen, beginnen wir mit Fragen zur Arbeit und lassen uns von den Antworten auf ein korrektes Framework verweisen Hier sind die vier Fragen , die am wichtigsten sind. Frage eins: Ist Ihre Arbeit planbar oder unterbrechungsabhängig? Können Sie vernünftigerweise ein paar Wochen Arbeit im Voraus festlegen ein paar Wochen Arbeit im Voraus oder kommen ständig dringende Dinge an und mischen alles neu? kommen ständig dringende Dinge an und Frage zwei: Passt deine Arbeit in Teile, die so groß sind wie ein Sprint Haben Ihre Aufgaben einen ziemlich gleichmäßigen Umfang und sind innerhalb von vierzehn Tagen erledigt, sie innerhalb von vierzehn Tagen erledigt, oder handelt es sich um eine wilde Mischung aus klein und riesig? Frage drei: Brauchen Ihre Stakeholder vorhersehbare Termine Verlassen sie sich darauf, zu wissen, dass etwas in einem festen Rhythmus geliefert wird, oder wollen sie hauptsächlich nur einen stetigen Fortschritt? Frage vier: Ist die Priorität innerhalb eines kurzen Zeitfensters stabil? Wenn Sie sich einig sind, was in diesen zwei Wochen wichtig ist, gilt es dann oder ändert es sich wirklich alle paar Im Großen und Ganzen deuten viele planbare, gleichmäßig dimensionierte, vorhersehbare und stabile Dinge auf Scrum hin Viele Interrupt-gesteuerte, gemischte Größen, stetige Ströme und ständige Verschiebungen deuten auf Camban hin Ein Mix weist Sie in Richtung Scrumban. Okay, wenden Sie es auf unsere App zum Sprachenlernen für Kinder Sprachenlernen für Kinder an, indem wir diese vier Frage eins, planbar oder unterbrechungsgesteuert. Diese App ist größtenteils planbar. Wir entwickeln Funktionen wie Quizfragen und Fortschrittsabzeichen , anhand derer wir entscheiden können, wir uns im Voraus dafür entscheiden können Aber es gibt einige Bugs. Es gibt auch ständig Bugfixes von Live-Benutzern, sodass dies größtenteils planbar ist, jedoch mit Frage zwei: Passen Aufgaben in Sprint-Größe? Ja, hauptsächlich ein Vokabelquiz, ein Abzeichen, eine E-Mail mit einer Zusammenfassung. Diese sind jeweils in Geschichten unterteilt , die wir in vierzehn Tagen beenden können Frage drei: Brauchen die Beteiligten vorhersehbare Termine? Ja. Unseren Stakeholdern, darunter Eltern und Unternehmen im Allgemeinen, gefällt die Gewissheit regelmäßig etwas Neues zu sehen. Frage vier hat innerhalb von vierzehn Tagen eine stabile Priorität . Meistens, aber nicht perfekt, kann ein lästiger Fehler, der das Lernen von echten Kindern beeinträchtigt , in die Warteschlange geraten Endlich haben wir das Urteil. Was ist also das Urteil für unsere App? Die Antworten tendieren eher zu Scrum. Die Arbeit ist größtenteils planbar und die Stakeholder schätzen den Rhythmus Aber dieses Rinnsal dringender Bugfixes bedeutet, dass reines Scrum gestört würde Am besten passt hier also Scrum mit einem Hauch von Cam-Ban-Disziplin. Also Scrum-Verbot Wir behalten den vierzehntägigen Rhythmus bei, wir behalten die Planung und die Retrospektive bei, weil sie zur Arbeit passen, und sie geben auch den Stakeholdern Sicherheit wir behalten die Planung und die Retrospektive bei, weil sie zur Arbeit passen, und sie geben auch den Stakeholdern Sicherheit. Aber wir haben ein Board mit Grenzwerten für den Arbeitsfortschritt, und wir reservieren alle zwei Wochen ein wenig Kapazität für dringende Lösungen, von denen wir wissen, dass sie eintreffen Nein. Machen Sie dasselbe für Ihr eigenes Projekt. Beantworten Sie die vier Fragen ehrlich. Wählen Sie das Framework nicht aus, weil Sie den Klang mögen oder weil Sie es bevorzugen. Wählen Sie den aus, auf den die Antworten zeigen. Und denken Sie daran, dass Sie es später jederzeit anpassen können, ganz bewusst, wenn Sie lernen. Okay, bei der Wahl eines Frameworks geht es nicht um Mode oder Dogma Es geht darum, das Tool an die Arbeit anzupassen, die direkt vor Ihnen liegt Beantworten Sie die Fragen und folgen Sie ihnen , und bleiben Sie bereit , Ihre Meinung zu ändern. Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Lektion werden Sie all diese Arbeit in die Praxis umsetzen und Ihr Projekt selbst in ein Cam-Ban-Board umwandeln . Ich werde dich dort sehen. 17. Übung: Konvertieren Sie Ihr Projekt in Kanban: Mm. Willkommen zurück. Dies ist eine Übungsstunde, also sind Sie an der Reihe , etwas zu arbeiten. Wir werden ein Projekt, das als Sprints läuft, nehmen und es in ein fließendes Cam-Ban-Board in Trello umwandeln Cam-Ban-Board in Trello In der kostenlosen Version von Trello funktioniert alles. Es sind keine kostenpflichtigen Funktionen erforderlich. Okay, hier ist, was du tun wirst. Nimm dein bestehendes Board, behalte die Karten, die du bereits geschrieben hast, und strukturiere die Listen zu einem Caban-Flow Fügen Sie den aktiven Spalten Grenzwerte für den Arbeitsfortschritt hinzu. Ordnen Sie dann Ihren Backlog nach Priorität neu an und überprüfen Sie, ob die Arbeit reibungslos von links nach rechts ablaufen kann Als Nächstes müssen Sie die Grenzen festlegen. Denken Sie daran, dass kostenloses Trello diese Listen für Sie nicht durchsetzt, daher verwenden wir die Namenskonvention Ändere den Namen von doing zu doing WIP three. Die Grenzen sind jetzt für das gesamte Team sichtbar. Achte zuletzt darauf, dass du auch deinen Backlog aufräumst und die wichtigste Karte nach oben ziehst, den Rest nach Priorität darunter anordnest deinen Backlog aufräumst und die wichtigste Karte nach oben ziehst, den Rest nach Priorität darunter anordnest Und dann der Plausibilitätstest zum Flow. Gibt es eine durchsichtige Karte, die ich einziehen oder abholen kann? Klemmt irgendwas fest? einem gesunden Cam-Bann-Board fließt die Arbeit stetig nach rechts, und keine Kolumne überschreitet ihr Limit . Also, wie gut aussieht Wenn du mit der Konvertierung deines Boards fertig bist, überprüfe es anhand dieser drei Dinge. Deine Listen bilden die tatsächliche Phase ab , in der sich deine Arbeit gerade befindet. Ihren aktiven Spalten sind die Grenzen für den Arbeitsfortschritt sichtbar, und Ihr Backlog ist von oben nach unten geordnet , wobei die wichtigsten Arbeiten ganz oben Wenn alle drei zutreffen, hast du ein funktionierendes Cam Ban-Board. Gut gemacht. Jetzt hast du ein Projekt vom Sprint zum Flow gebracht und hast ein Cam Bn-Board, das du tatsächlich ausführen kannst. Danke , dass du zu mir gekommen bist. In der nächsten Lektion wenden wir uns an die Personen rund um Ihr Projekt und beginnen mit Erfassung und Verwaltung Ihrer Stakeholder. Ich werde dich dort sehen. 18. Identifizierung und Zuordnung Ihrer Stakeholder: Willkommen zurück. In dieser Lektion werden wir uns die Leute rund um Ihr Projekt ansehen. An jedem Projekt gibt es Stakeholder, also die Menschen, die von dem, was Sie bauen, betroffen sind oder die es beeinflussen können, und sie richtig zu machen, ist oft der Unterschied zwischen einem reibungslosen und einem mühsamen Projekt. Am Ende dieser Lektion werden Sie wissen, wie Sie all Ihre Beteiligten finden, sie danach sortieren, wie wichtig sie sind und wie viel Aufmerksamkeit jeder einzelne wirklich benötigt. Also, wer ist ein Stakeholder? Lassen Sie uns mit der Definition beginnen , weil sie umfassender ist, als die meisten Leute denken Ein Stakeholder ist jeder , der ein Interesse an dem hat, was Sie aufbauen Sie werden vom Ergebnis beeinflusst oder können es mitgestalten, und sehr oft ist es beides Einige sind innerhalb des Teams, die Leute, die das Produkt entwickeln, sowie Ihr Product Owner und Ihr Scrum Master, aber die meisten sind außerhalb des Also dein Sponsor, der für die Arbeit bezahlt , die Nutzer unserer Sprachlern-App für Kinder , also die Kinder, aber auch ihre Eltern und ihre Lehrer Und diejenigen, die leicht übersehen werden , sind die Support-Mitarbeiter und die Rechts- oder Compliance-Mitarbeiter , von denen Sie nur hören, wenn etwas schief geht Wenn sie von der Arbeit betroffen sind, sind sie ein Stakeholder Bevor Sie Stakeholder verwalten können, müssen Sie herausfinden, wer sie sind, und das Ziel ist, niemanden zu verpassen Es gibt zwei einfache Fragen , die sich fast jedem stellen. Erstens, wer davon betroffen ist, wer das Produkt verwendet, wer es bezahlt, unterstützt oder mit dem Ergebnis leben muss. Zweitens, wer kann uns beeinflussen? Wer kann Sie beschleunigen, verlangsamen, finanzieren oder eine Veröffentlichung blockieren. Dann die dritte Aufforderung, denn das sind es, die dich später beißen. Wer vergisst leicht die stillen Stakeholder. Sie Endbenutzer, die selten an Ihren Besprechungen teilnehmen, Ihr Support-Team , diese Compliance-Person, die monatelang nichts sagt und dann im schlimmsten Moment nein sagt, all diese Leute aufschreiben. Ein Name auf Ihrer Liste kann verwaltet werden. Ein Stakeholder, den Sie vergessen haben, kann nicht verwaltet werden. Eine lange Liste ist kein Plan. Sie können nicht jedem die gleiche Aufmerksamkeit schenken, und Sie sollten es auch nicht wirklich versuchen. Deshalb sortieren wir sie mit einem einfachen und sehr bekannten Tool, dem Strom- und Zinsnetz. Stellen Sie sich ein vierteiliges Quadrat vor. Die Vertikale als Achse steht für Macht, wie viel Einfluss diese Person auf das Projekt hat. Der horizontale Zugang ist interessant, wie wichtig er ihnen ist. Das gibt Ihnen vier Gruppen, und jede möchte anders umgehen. Oben rechts stehen hohe Macht und hohes Interesse. Verwalte diese Leute genau. Sie sind Ihre Hauptakteure, also beziehen Sie sie oft mit ein. Links oben steht für hohe Macht, aber niedrigeres Interesse. Sorgen Sie dafür, dass diese Leute zufrieden sind. Sorgen Sie dafür, dass sie glücklich und beruhigt sind, aber ertränken Sie sie nicht mit Details, die sie nicht wollen Unten rechts steht weniger Leistung, aber hohe Zinsen. Halten Sie sie auf dem Laufenden. Sie interessieren sich sehr dafür, also halten Sie sie auf dem Laufenden. Und unten links stehen niedriger Stromverbrauch und niedriges Interesse. Überwachen Sie einfach diese Leute. Eine leichte Berührung genügt. Lassen Sie uns all das mit unserer Sprachlern-App konkret machen . Ihr Produktleiter hat sowohl Macht als auch großes Interesse. Also gehen sie nach oben rechts. Sie verwalten eng und beziehen sie in Ihre Bewertungen und Ihren Plan mit ein. Der Firmengründer kontrolliert das Budget, ist aber nicht im Tagesgeschäft, also stehen sie oben links, sorgen dafür, dass sie zufrieden sind , aber ersparen Sie ihnen die Details. Lehrer und Eltern haben formal wenig Einfluss auf Ihre Roadmap, aber sie kümmern sich enorm darum Also gehen sie nach unten rechts, halten sie auf dem Laufenden, und die Rechts- und Compliance-Vorschriften für den Großteil des Projekts überwacht, geringe Beteiligung, aber beachten Sie den Haken, werden für den Großteil des Projekts überwacht, geringe Beteiligung, aber beachten Sie den Haken, sie dürfen sich nie Ein unauffälliger Beteiligter kann eine Veröffentlichung immer noch verhindern. Was bekommt also jede Gruppe eigentlich von Ihnen? Ordne die Anstrengung dem Quadranten zu und du wirst deine Energie dort einsetzen, wo sie zählt Enge Verwaltung bedeutet häufigen und wechselseitigen Kontakt. Sie sind bei Besprechungen und Planungen im Raum. Bleibt zufrieden, bedeutet eine kurze, regelmäßige Zusammenfassung und eine frühzeitige Vorwarnung vor jeder wichtigen Entscheidung. Auf dem Laufenden bleiben bedeutet , dass sie jederzeit auf dem Laufenden gehalten werden können, und vor allem, dass keine Besprechungen erforderlich Sie informieren, nicht beraten, und überwachen bedeutet eine leichte Berührung, nur ein kurzes Wort, wenn etwas sie wirklich betrifft, und Wenn Sie das gut machen, werden zwei Dinge passieren: wichtige Stakeholder werden sich gut betreut fühlen und Sie werden aufhören Stunden in die Leute zu stecken, die sie weder brauchen noch wollen Also ja, es ist sehr wichtig , darüber nachzudenken, wie viel und wie oft Also finde alle, sortiere sie nach Macht und Interesse und schenke jeder Gruppe die richtige Aufmerksamkeit. Diese Karte ist die Grundlage für alles andere in diesem speziellen Abschnitt. Danke, dass du zu mir gekommen bist. In der nächsten Lektion nehmen wir Ihre wichtigsten Stakeholder und zeigen ihnen echte Arbeit, indem wir ein Sprint-Review durchführen , auf das sie wirklich Wert legen. Wir sehen uns dort. 19. Durchführen einer produktiven Sprint-Überprüfung: Willkommen zurück. In dieser Lektion führen wir ein Sprint-Review durch. Dabei handelt es sich um ein Meeting am Ende eines Sprints, bei dem Sie Ihren Stakeholdern zeigen , was Sie aufgebaut haben , und ihr Feedback einholen. Wenn das gut gemacht wird, kann es zu einer der wertvollsten halben Stunden in Ihrem gesamten Prozess werden. Aber wenn es schlecht gemacht wird, wird es wie ein langweiliges Status-Update-Meeting , an dem niemand teilnehmen möchte. Am Ende dieser Lektion werden Sie also wissen, wie Sie ein Sprint-Review durchführen, das Ihnen Vertrauen verschafft und Ihnen tatsächlich Feedback gibt, das Sie nutzen können Lassen Sie uns einfach klarstellen, wofür ein Sprint-Review gedacht ist , denn hier können manche Leute etwas falsch machen Die Sprint-Bewertung zeigt ein wirklich funktionierendes Produkt. Es ist ein Live-Blick darauf, was gebaut wurde. Auf diesen Sprint folgte ein ehrliches Gespräch darüber, wie es gelaufen ist. Was es ist, ist keine Diashow, und es ist keine Abzeichnungszeremonie, und es ist keine Stempelzeremonie Der alte Agile-Ausdruck bedeutet funktionierende Software statt umfassender Dokumentation Und in der Bewertung werden Sie dem gerecht. Du hast das Ding gezeigt, kein Slidedeck über das Ding. Es geht um das Feedback, auf das Sie reagieren können , nicht um Applaus. Eine gute Bewertung benötigt etwa 10 Minuten Vorbereitung. Und es gibt drei wichtige Dinge. Bereite zuerst die Demo vor. Halten Sie die funktionierende Funktion auf einem echten Gerät bereit und testen den Happy Path zuerst selbst, damit Sie nicht live vor Ihrem Sponsor debuggen Zweitens laden Sie die richtigen Leute ein, die Stakeholder, denen diese spezielle Arbeit wichtig ist, das gesamte Unternehmen Und drittens: Setzen Sie sich ein Ziel: Sie müssen wissen, welche einzelne Frage Sie am liebsten beantwortet haben möchten, bis der Raum leer ist. Vielleicht fühlt sich das neue Quiz für einen Lehrer richtig an oder so Gehen Sie rein und wissen, was Sie lernen möchten Also hier ist eine schnelle, einfache Agenda, die funktioniert, und sie besteht aus nur vier Schritten, und es wird insgesamt etwa eine halbe Stunde dauern. Eine besteht darin, das Sprintziel in einer einzigen Zeile zusammenzufassen. Was haben wir uns für diesen Sprint vorgenommen? Zweitens: Demonstrieren Sie das Werk, zeigen Sie es live und wo immer Sie können, lassen Sie sie es selbst ausprobieren. Nummer drei besteht darin, Feedback einzuholen, offene Fragen zu stellen und dann viel mehr zuzuhören als zu sprechen. Nummer vier: Sprechen Sie kurz über die nächsten Schritte. Was bedeutet das, was wir gerade gesehen haben für den Plan, und das war's. Zusammenfassung, Demo, Feedback und deine nächsten Schritte. Wenn du eine Gewohnheit aus dieser Lektion übernommen hast, nimm diese. Demo, zeig nicht. Zeigen Sie die Realität auf einem Gerät, sprechen Sie nicht auf einer Folie darüber. Ein funktionierendes Quiz, auf das Ihr Stakeholder beispielsweise tippen kann, ist besser jedes Mal zehn Stichpunkte, die es beschreiben In einer Live-Demo gibt es keinen Ort, an dem man sich verstecken kann, und genau darum geht es Sorgt dafür, dass alle ehrlich darüber sind, was wirklich getan wurde. Zwei Dinge sorgen dafür, dass eine Demo landet Lassen Sie sie fahren, das Gerät aushändigen und beobachten, wo sie zögern, wo eine reale Person innehält oder Stirn runzelt, mehr wert ist als jeder Statusbericht, und überspringen Sie den Rau aber echt ist besser als schlau aber unecht. Du verkaufst nicht, du lernst. Zeigen Sie, was wirklich funktioniert, was und so, wenn das Feedback kommt und es wird. Drei Gewohnheiten sorgen dafür, dass es nützlich ist Erfassen Sie zunächst das Feedback, verteidigen Sie es nicht, schreiben Sie es auf und widerstehen Sie dem starken Drang, zu erklären, warum es falsch ist Sie haben nach ihrer Meinung gefragt, also lassen Sie sie sie äußern. Zweitens ändert sich der Umfang des Parks. Wenn jemand sagt: Oh, könnte es das auch tun? Das ist eine großartige Idee für den Backlog, keine Änderung an diesem Sprint Also notieren Sie es, danken Sie ihnen und fahren Sie fort. Drittens, danke ihnen aufrichtig. Leute, die auftauchen und sich äußern, tun dir wirklich einen Gefallen, auch wenn das Feedback weh tut, besonders dann, wenn sie den Raum so behandeln und die Leute gehen und sich gehört fühlen, was bedeutet, dass sie zurückkommen und dir auch beim nächsten Mal die Wahrheit sagen werden Ein gutes Sprint-Review ist also wirklich einfach. Zeigen Sie echte Arbeit, hören Sie gut zu und handeln Sie dann nach dem, was Sie hören. Also danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Lektion werden wir uns damit befassen, was passiert, wenn Feedback den Plan ändert und wie Sie sich ändernde Anforderungen aufnehmen ohne Ihren Fokus zu verlieren. In der nächsten sehen wir uns. 20. Verwaltung wechselnder Anforderungen: Willkommen zurück. In dieser Lektion werden wir uns mit etwas befassen , mit dem jedes Projekt konfrontiert ist. Die Anforderungen ändern sich. Ein Stakeholder möchte etwas Neues, ein Benutzer tut etwas, das Sie nicht erwartet haben, also verschieben sich die Prioritäten In einem starren Prozess ist eine solche Änderung eine Krise, aber in Agile ist sie normal Es ist jedoch eine echte Fähigkeit, Veränderungen zu absorbieren, ohne dass Ihr Projekt im Veränderungen zu absorbieren, ohne Chaos versinkt, und mit dieser Fähigkeit werden wir uns in dieser Lektion befassen Zunächst einmal ist eine Änderung der Denkweise in Agile erlaubt, Ihre Meinung zu ändern Es wird sogar erwartet und gefördert. Der Sinn, in kurzen Zyklen zu arbeiten und echte Produkte zu zeigen , besteht darin, dass man Dinge lernt, und das Lernen sollte das, was man als Nächstes tut, verändern. Das Ziel besteht also nicht darin, den Plan einzufrieren und zu verteidigen. Ziel ist es, den Plan bewusst zu ändern anstatt jedes Mal, wenn Ihnen jemand eine neue Idee per E-Mail sendet, in Panik zu geraten. Veränderungen willkommen zu heißen und die Kontrolle zu verlieren sind nicht dasselbe, und in dieser Lektion geht es um diesen entscheidenden Unterschied. Es ist also hilfreich zu wissen, woher Veränderungen in der Regel kommen , denn keine dieser Quellen ist ein Versagen Ihrerseits. Es ist einfach Realität. Stakeholder ändern ihre Meinung, sobald sie die Arbeit gesehen haben. Oft entdecken sie erst, was sie wirklich wollen, wenn sie sich ansehen, was sie haben. Echte Nutzer verhalten sich anders, als Sie es sich vorgestellt haben Der Markt bewegt sich, ein Konkurrent liefert etwas anderes, eine Regel ändert sich, eine Priorität verschiebt sich über Sie und Ihr eigenes Team lernt, während es aufbaut, und letzteres ist wichtig Informationen sind kein Bug in Ihrem Plan Aus diesem Grund planen Sie in erster Linie in kurzen Zyklen. Also, wo sollten all diese Änderungen eigentlich in Ihrem Backlog landen Stellen Sie sich den Backlog als den Stoßdämpfer verhindert , dass jede neue Anfrage das gesamte Projekt erschüttert Also drei Schritte. Nehmen Sie es zunächst in aller Ruhe Eine neue Anfrage wird zu einer Notiz im Backlog, nicht zu einer sofortigen Kehrtwende. Zweitens: Handeln Sie nicht reflexartig. Fast nichts muss sich in dieser Sekunde ändern. Lassen Sie die Wogen sich glätten, bevor Sie sich bewegen. Lassen Sie drittens den Product Owner neue Prioritäten setzen. Der Product Owner oder der PO wägt die neue Anfrage gegen alles andere ab, was noch auf sie wartet, und entscheidet, wo sie sich wirklich Das ist ihre Aufgabe und schützt das Team davor, von demjenigen herumgeworfen zu werden , der zuletzt etwas gerufen hat Wie Sie eine Änderung aufnehmen, hängt also ein wenig davon ab, welches Framework Sie verwenden. Beides haben wir weiter oben in diesem Kurs behandelt In Scrum schützen Sie also den aktuellen Sprint. Neue Arbeiten werden auf die nächste Planungssitzung warten. Das heutige Engagement bleibt bestehen, sodass das Team das, was es begonnen hat, tatsächlich beenden kann. In Cam Ban gibt es keinen Sprint, den es zu schützen gilt, also ordnen Sie die Warteschlange einfach neu Sie können die neue Arbeit mit der richtigen Priorität einordnen und dabei Ihre Grenzen für den Arbeitsfortschritt einhalten. Dabei handelt es sich um die Obergrenzen dafür, wie viele Fortschritte gleichzeitig in Bearbeitung sein können gleichzeitig in Bearbeitung sein Die Tools unterscheiden sich, aber das Prinzip ist identisch. Änderungen werden bewusst zu einem vernünftigen Zeitpunkt vorgenommen, nicht indem alles gelöscht wird eine neue Anfrage eingeht. Hier ist ein einziger Satz, mit dem Sie mehr Projekt sparen können als mit fast allem anderen. Sagen Sie Ja zum Was und verhandeln Sie das Wann. Sag Ja zu der Idee und sei dann ehrlich, was den Kompromiss angeht. Anstatt also ein klares Nein oder ein leichtsinniges Ja zu sagen, das Ihren Plan stillschweigend ruiniert, sagen Sie etwas wie, ja, wir können das übergeordnete Dashboard hinzufügen, und hier ist, was in der Liste nach unten verschoben wird, um Platz dafür zu schaffen Sie lehnen die Änderung nicht ab. Sie machen die Kosten sichtbar und lassen sich von den Stakeholdern bei der Auswahl helfen In neun von zehn Fällen treffen sie, sobald sie den Kompromiss gesehen haben, sobald sie den Kompromiss gesehen haben, eine vernünftige Entscheidung, und das ist jetzt eher ihre Entscheidung als ein Kampf Bleiben Sie flexibel, ohne abzudriften Ein paar Leitplanken können Ihnen helfen Halten Sie sich an eine klare Prioritätsreihenfolge, einen einzigen Ranglistenrückstand, sodass das Wort wichtig immer Behalten Sie eine Definition von erledigt bei, die gilt. Ihre Qualitätsstandards können sich nicht ändern, nur weil sie eingehalten werden. Behandeln Sie Änderungen standardmäßig bei der Überprüfung, sammeln Sie Feedback zu diesem regulären Zeitpunkt, anstatt es als ständigen Strom von Unterbrechungen eintreffen zu lassen ständigen Strom von und Gold Plating abzulehnen Sag nein zu den glänzenden Nice To Haves, nach denen eigentlich niemand gefragt Fokus ist nicht etwas, das man hat, es ist etwas, das man immer wieder wählt. Veränderung ist also keine Gefahr für ein gutes Agile-Projekt. Es ist eigentlich der Treibstoff. Die Fähigkeit besteht darin, diese Veränderungen bewusst durch den Rückstand im richtigen Moment zu absorbieren durch den Rückstand im . Danke, dass du zu mir gekommen In der nächsten Lektion werden wir uns mit Status-Updates befassen und darüber, wie Sie Ihre Stakeholder auf dem Laufenden halten können, ohne Zeit anderer zu verschwenden. Wir sehen uns dort 21. Statusaktualisierungen, die die Zeit der Mitarbeiter respektieren: Willkommen zurück. In dieser Lektion werden wir uns ansehen, wie man Statusmeldungen schreibt , die die Leute tatsächlich lesen. Die meisten Updates sind also viel zu lang oder zu vage oder sie werden stillschweigend ignoriert, aber Ihre müssen es nicht sein Am Ende dieser Lektion haben Sie also eine einfache Struktur, die Sie jede Woche wiederverwenden können, und Sie werden auch ein gutes Gespür dafür haben, wann für eine Statusaktualisierung eine Besprechung erforderlich ist und wann nur eine einfache schriftliche Notiz erforderlich Lassen Sie uns damit beginnen, warum so viele Aktualisierungen fehlschlagen, denn wenn Sie diese vier Fallstricke vermeiden, werden Sie alles richtig machen Erstens sind sie zu lang, eine Textwand, die niemand fertigstellt, wo die eine wichtige Zeile im Detail untergeht. Zweitens sind sie zu vage Gute Fortschritte sagen einem Stakeholder genau nichts Drittens haben sie keine klare Frage. Wenn du eine Entscheidung brauchst, sag sie. Und wenn nicht, fragen Sie sich, warum diese Person es überhaupt liest. Und viertens, es ist das falsche Publikum. Umfangreiches technisches Detail, das an einen Sponsor geschickt wurde , der nur die Überschrift will. Wenn du diese vier Dinge reparierst, bist du den meisten Teams bereits einen Schritt voraus. Also hier ist die Struktur. Alles Wichtige passt unter drei Überschriften, und sie beginnen alle mit P, sodass man es sich leichter merken kann. Fortschritt, Plan und Probleme. Fortschritt. Was seit dem letzten Mal tatsächlich getan wurde, Dinge zu Ende bringen, keine laufenden Dinge. Plane, was du als Nächstes tust und ungefähr, wann sie es sehen werden und welche Probleme es gibt, was blockiert ist oder was eine konkrete Entscheidung mit einer klaren Aufforderung erfordert . Und das ist die ganze Vorlage. Wenn etwas nicht in den Fortschrittsplan oder in die Probleme passt, gehört es wahrscheinlich überhaupt nicht in das Status-Update. Also hier ist eine Vorlage, die du wiederverwenden kannst Lass uns sie für unsere Sprachlern-App ausfüllen damit du sehen kannst, wie kurz ein Status-Update wirklich sein kann. In Bearbeitung, wir haben das Tierquiz fertiggestellt und die Fortschrittsabzeichen sind jetzt für 40% der Nutzer verfügbar Plan, als nächstes folgt die E-Mail mit der Zusammenfassung der Eltern und wir werden beim Testbericht am Freitag eine Demo machen Probleme, es gibt einen Audio-Bug in der Zahlenstunde und wir müssen entscheiden, ob sich dadurch die Veröffentlichung verzögert. Das ist ein vollständiges, nützliches Update in drei Zeilen. Es gibt keinen Füller, und das Einzige, was Sie vom Leser benötigen, ist eine Entscheidung, die Sie nicht verpassen können. Für die meisten Updates ist kein Meeting erforderlich. Eine Entscheidung, die Sie treffen müssen, ist also, wie Sie das senden möchten. Die ehrliche Antwort lautet: Die meisten Updates erfordern überhaupt kein Meeting, weil Ihre Standardeinstellung geschrieben und asynchron oder asynchron sein sollte , was einfach bedeutet, dass die Leute es zu ihrer eigenen Zeit lesen , anstatt sich alle auf einmal zu versammeln Also eine kurze Notiz, die in einem Posteingang oder auf einer gemeinsam genutzten Seite landet und die große Mehrheit der Updates abdeckt Ein Meeting lohnt sich nur dann, wenn Sie eine Diskussion oder eine Entscheidung benötigen, etwas, mit dem hin- und hergeschriebenes Schreiben nicht sehr gut umgehen kann Als Faustregel gilt, dass ein Meeting, dessen Zweck nur darin besteht , Informationen auszutauschen, in der Regel eine E-Mail ist , die über ihre Reichweite hinausgeht, Informationen schreibt und sich trifft, um Entscheidungen zu treffen Sie haben also drei Überschriften: Fortschritt, Plan und Probleme, die kurz gehalten und über den neuesten Kanal gesendet werden, der die Aufgabe erledigt Also danke, dass Sie sich mir angeschlossen haben. In der nächsten Lektion sind Sie dran. Wir werden gemeinsam ein echtes Stakeholder-Update für Ihr eigenes Projekt schreiben gemeinsam ein echtes Stakeholder-Update für Ihr eigenes Projekt und es in Notion dokumentieren. Wir sehen uns dort 22. Übung: Verfassen eines Stakeholder-Updates: Willkommen zurück. In dieser Übungsstunde werden Sie die Arbeit erledigen. Wir werden ein echtes Stakeholder-Update für Ihr Projekt verfassen und dabei die dreiteilige Struktur vom letzten Mal verwenden die dreiteilige Struktur vom letzten Mal Ich zeige es dir auf einem Bildschirm in Notion First Dann kannst du das Video pausieren und dein eigenes schreiben Lassen Sie uns also anfangen. Also hier ist die Übung in vier Schritten. Wählen Sie die Zielgruppe aus, wählen Sie einen einzelnen Stakeholder oder eine Gruppe aus Ihrer Stakeholder-Map und schreiben Sie speziell für Zweitens: Nutze die drei Teile Fortschritt, Plan und Probleme und sonst nichts Drittens, mach es kurz und bündig. Wenn es nicht bequem auf einen Telefonbildschirm passt , ist es wahrscheinlich zu lang. Und viertens, der wichtigste Schritt, senden Sie es. Ein Update, das Ihre Entwürfe einsendet, ist wertlos. Es zu schreiben ist also die Praxis. Es zu schicken ist der Job. Schauen wir uns also unsere Notion-Seite an. Wir haben von vor der Seite mit den Stakeholder-Updates. Ich werde diese Seite hier öffnen und Ihnen den Statusbericht zeigen, den ich hier für Sprint One hinzugefügt habe Ich habe das Datum 22. Mai 2026 an einem Freitag hinzugefügt, was normalerweise ein guter Tag ist, um einen Statusbericht zu Und bei der Zielgruppe handelt es sich um den Produktleiter , den ich hier zu dieser Rubrik hinzugefügt habe, die an gesendet Und wenn wir diese Seite öffnen, sehen wir den Title Sprint One Statusbericht mit allen wichtigen Informationen ganz oben. Und im Hauptteil haben wir das Datum, den 22. Mai 2026, den Statusbericht mit den Fortschritten mit zwei Kugeln, Plan mit zwei Kugeln und die Probleme mit zwei Und so einfach ist das. Nun, das ist offensichtlich der Statusbericht, der geschrieben wurde. Jetzt müssen wir senden. Wenn Sie hier oben auf Teilen klicken Ihre Stakeholder in Notion sind Notion-Konten haben, können Sie es über dieses Feld hier an ihr Notion-Konto senden über dieses Feld hier oder Sie können den Link kopieren und ihnen den Link einfach direkt senden. Und das alles ist im kostenlosen Tarif von Notion verfügbar. benötigen Sie keine kostenpflichtigen Abonnements Dafür benötigen Sie keine kostenpflichtigen Abonnements. Das war es also auch schon. Also ja, das Wichtigste ist, dass du es tatsächlich sendest, ist die kostenlose Seite , die du in Notion hinzugefügt hast. Sie können das Video also pausieren und jetzt Ihre eigene Seite für einen Ihrer Stakeholder schreiben . Wenn Sie fertig sind, vergleichen Sie es den vier Dingen, dass es auf einen Bildschirm passt, dass es kurz genug ist, um es in weniger als einer Minute zu lesen, und dass jede Zeile ihren Platz verdient , sodass es kein Füllmaterial gibt, und wenn eine Zeile entweder informiert oder nach etwas fragt, schneiden Sie sie aus Die Frage liegt auf der Hand. Wenn Sie etwas brauchen, ist es unmöglich, es zu übersehen, und es passt zum Leser, wenn es darum geht, was diesem bestimmten Publikum wirklich wichtig ist, nicht alles, was Sie zufällig wissen Alle vier sind wahr, dann hast du ein Update geschrieben , das die Leute tatsächlich lesen werden Eine letzte Anmerkung hier: Der schwierigste Teil der Kommunikation mit den Stakeholdern ist nicht wirklich das Schreiben. Es ist die Angewohnheit Ein kurzes und ehrliches Update, das jede Woche gesendet wird, schafft routinemäßig mehr Vertrauen als ein schöner Bericht einmal im Quartal Halten Sie die Struktur also jedes Mal gleich, und es wird eine fünfminütige Arbeit , die Sie tatsächlich weitermachen, und Sie werden eine Haltung von Kompetenz und Eigeninitiative vermitteln , indem Sie dies jede Woche tun, und das zeugt von guter Disziplin im Projektmanagement Das ist also das Ende dieser Lektion. Gut gemacht für die Übungsübung. Als Nächstes werden wir messen, was am wichtigsten ist, und die Kennzahlen. Also die Zahlen, die zählen. Gut gemacht, dass Sie das Ende dieser Lektion erreicht haben. Danke, dass Sie zu mir gekommen Wir sehen uns in der nächsten. 23. Erläuterung von Burndown und Burnout-Diagrammen: Willkommen zurück. In dieser Lektion werden wir uns die beiden gängigsten Fortschrittsdiagramme in Agile ansehen , das Burndown-Diagramm und das Burnup-Diagramm Beide fassen einen unordentlichen Haufen Arbeit in einer einzigen Zeile zusammen, die Sie in Sekundenschnelle lesen können Am Ende dieser Lektion werden Sie also wissen, wie man die einzelnen Zeilen liest, was Ihnen die Form der Linie sagt und zu welchem Diagramm Sie greifen müssen, je nachdem, wer zuschaut Warum also Fortschritte visuell verfolgen? Erstens, warum sich überhaupt die Mühe machen? Weil ein Bild besser ist als eine Statusbesprechung. Ein Blick auf ein gutes Diagramm sollte Ihnen sagen, ob der Sprint auf dem richtigen Weg ist, und das ersetzt stillschweigend 100 „Wie geht's weiter“ -Meldungen. Es gibt also zwei Dinge, die dafür sorgen, dass diese Diagramme für einen sehr geringen Aufwand lohnen. Sie sind schnell. Eine Trendlinie zeigt Ihnen innerhalb von Sekunden was für ein Absatz den Status aktualisieren kann, wenn sie nicht ehrlich sind, die Linie dreht sich nicht. Sie zeigt die eigentliche Arbeit, unabhängig davon, ob das Lesen angenehm ist oder nicht. Also hier ist das Burndown-Diagramm. Fangen wir mit diesem Die Idee steckt im Namen. Die Arbeit brennt ab, wenn sie gegen Null geht. Die vertikale Achse ist die verbleibende Arbeit, normalerweise in Storypoints oder der Anzahl der Aufgaben, und die horizontale Achse ist die Zeit, also die verbleibenden Tage Ihres Sprints. Zu Beginn ist die gesamte Arbeit noch übrig, sodass die Linie oben links beginnt. Wenn das Team mit der Arbeit fertig ist, wird die Warteschlange kleiner. Wenn alles erledigt ist, erreicht es am letzten Tag Null. Die gestrichelte Linie ist dein Ideal, ein gerader Lauf von der ganzen Arbeit auf Null, in dem Tempo, das du brauchst , um pünktlich fertig zu werden. Und die durchgezogene Linie ist genau das, was passiert ist. Die ganze Fähigkeit besteht darin, die Lücke zwischen den beiden zu lesen Schauen wir uns also an, wie wir ein Burndown-Diagramm lesen Also, was sagt dir die Zeile genau? Es gibt vier Formen, die man erkennen kann. Liegt die tatsächliche Linie im Idealfall, dann liegen Sie ungefähr im Zeitplan. Du kannst weitermachen. Wenn es über dem Ideal bleibt, mehr Arbeit übrig als geplant, Sie laufen also hinterher. Wenn es unter dem Ideal liegt, sind Sie dem Zeitplan voraus, oder es ist genauso wahrscheinlich, dass Sie zu viel geplant und sich nicht genug Arbeit vorgenommen haben. Und die, auf die Sie achten sollten, nämlich eine flache Linie, bei der die Warteschlange für ein oder zwei Tage nicht mehr abfällt. Das bedeutet, dass nichts fertig wird , etwas klemmt, und was es wert ist zu fragen, und es lohnt sich, beim nächsten Stand zu fragen. Nun das Burnup-Diagramm, das zeigt den gleichen Fortschritt, aber andersherum Anstatt also die Arbeit herunterzuzählen, steigt die abgeschlossene Arbeit nach oben. Die aufsteigende durchgezogene Linie ist die Arbeit, die Sie abgeschlossen haben , wobei Sie von Null an aufgestiegen sind, und es gibt eine zweite Linie die den Gesamtumfang darstellt, die gesamte Menge an Arbeit, die Sie erledigen möchten Fortschritt bedeutet, dass sich die Lücke zwischen der Steiglinie und der obersten Linie schließt. Wenn die fertiggestellte Linie auf die Zielfernrohrlinie trifft, sind Sie fertig. Eine der Superkräfte des Burnup-Diagramms ist also der Umfang Nun, die oberste Zeile mag wie eine kleine Ergänzung aussehen, aber das ist die Superkraft des Burnups, denn sie zeigt dir, wann sich die Hier ist der Unterschied. Wenn beim Burndown jemand mitten im Sprint Arbeit hinzufügt, sinkt die Linie einfach merkwürdig oder flacht ab, und Sie können nicht so leicht flacht ab, und Sie können nicht so Änderungen am Umfang sind in diesem Fall ausgeblendet. Bei einem Burnup, wenn der Umfang wächst, springt die oberste Zeile sichtbar Die Veränderung ist da, sie ist ehrlich und für alle offensichtlich Genau aus diesem Grund bevorzugen viele Teams den Burnup, wenn sie mit Stakeholdern sprechen Wenn die Frist verrutscht weil jemand ständig Anfragen hinzugefügt hat, zeigt die Grafik, dass nicht das Team ins Ich war das Ziel, das sich bewegt hat. Das Bild zeigt das Gespräch für dich. Welches solltest du also verwenden und wann? Ehrlich gesagt sind beide sehr nützlich Sie wählen sie einfach anhand Ihrer Zielgruppe aus. Sie würden also nach dem Burndown innerhalb des Teams greifen , weil es ein einfacher täglicher Check Sind wir auf dem richtigen Weg, den Sprint zu beenden und dann mit den Stakeholdern nach dem Burnup zu greifen , weil dadurch Fortschritt und Umfang gemeinsam aufgezeigt werden, was viel weniger unangenehme Überraschungen darüber bedeutet , warum Aber der eigentliche Punkt ist folgender: Jedes Diagramm übertrifft kein Diagramm. Eine sichtbare Trendlinie verändert das Gespräch von Meinungen zu Fakten Also benutze einfach einen. Also Burndown zählt Arbeit runter, Burnup, klettert rauf, und die Form der Linie spricht Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Lektion werden wir uns zwei wichtige Kennzahlen für ablauforientiertes Arbeiten ansehen zwei wichtige Kennzahlen für ablauforientiertes Arbeiten das kumulative Flussdiagramm und die Durchlaufzeit. Wir sehen uns dort 24. Kumulativer Durchfluss und Durchlaufzeit: Willkommen zurück. In dieser Lektion werden wir ein Cam-Ban-System messen. Cam Ban hat also keine Sprints, also passen die Burndown- und Burnup-Charts nicht ganz hierher Stattdessen beobachten wir den Arbeitsablauf. Wir werden uns mit zwei Tools befassen, die den Großteil der Arbeit erledigen das kumulative Flussdiagramm und die Vorlaufzeit Am Ende werden Sie in der Lage sein, einen Engpass auf einen Blick zu erkennen und ehrlich zu sagen, wie lange Ihre Arbeit Also zwei Caban-Gesundheitschecks. Da Caban keine Sprint-Grenze hat, misst es stattdessen den Flow, also wie reibungslos die Arbeit auf der ganzen Linie abläuft, von links nach rechts Zwei Werkzeuge tragen den Großteil der Last. Das erste ist das kumulative Flussdiagramm, das zeigt, wie sich die Arbeit häuft oder reibungslos auf der ganzen Die zweite ist die Vorlaufzeit, die zeigt, wie lange es tatsächlich dauert, bis die Arbeit erledigt Zusammen beantworten sie die beiden Fragen , die bei der Arbeit mit Arbeitsabläufen am wichtigsten sind. Bleibt etwas hängen und wie lange dauern die Dinge? Schauen wir uns also das kumulative Flussdiagramm an, auch bekannt als CFD, was für kumulatives Flussdiagramm steht Es sieht zunächst etwas kompliziert aus, aber die Idee ist Die Zeit läuft unten entlang, und an der Seite oben ist die Anzahl der Karten. Und jedes farbige Band ist eine Stufe Ihres Spielbretts, und sie sind alle übereinander gestapelt . Das untere Band ist fertig, dann hast du „In Bearbeitung“ und dann „Zu tun“ oben Jeden Tag zählst du, wie viele Karten sich in jeder Phase befinden, und das bestimmt die Höhe der einzelnen Bänder. Das ganze Bild zeigt dir also deine Arbeit nach oben und nach hinten fließt. Neue Karten kommen oben in die Aufgabenleiste, und wenn sie fertig sind, wandern sie nach unten durch das Feld In Bearbeitung nach Dunn In einem funktionierenden Cam-Band-System klettern die Bänder in etwa parallelen Streifen zusammen Wenn die Streifen nicht mehr parallel verlaufen, lernt man tatsächlich etwas. So liest du die Form dieser Bänder ab. Parallele Bänder bedeuten, dass alles gleichmäßig wächst, und das bedeutet, dass ein gesunder, stetiger Arbeitsfluss ähnlicher Geschwindigkeit ein- und ausgeht. Ein Band, das sich plötzlich erweitert, ist Ihr Warnsignal. Das deutet auf einen Engpass hin. Die Arbeit stapelt sich schneller in einer Phase an, als Wenn sich in der Fortschritts-Band ein Ballon befindet, haben Sie weit mehr von oben angefangen als Ein flaches Band am unteren Rand ist das Schlimmste davon. Nichts wird tatsächlich abgeschlossen. Und ein flaches Dach, auf dem keine neuen Arbeiten eintreffen, ist normalerweise in Ordnung , obwohl es gelegentlich ein Hinweis darauf , dass Ihr Rückstand versiegt Schauen wir uns nun die Vorlaufzeit und die Zykluszeit an, das zweite Tool Diese lassen sich leicht verwechseln, also lassen Sie uns sie anhand der Tafel festhalten. Vorlaufzeit ist also die gesamte Reise von dem Moment an, in dem eine Anfrage in Ihrem Backlog landet , bis zu dem Moment, in dem sie erledigt ist Es ist die Uhr, die der Kunde fühlt, weil sie in dem Moment beginnt, in dem er nachfragt, und die Zykluszeit ist kürzer Es ist die Uhr, die beginnt, wenn das Team tatsächlich mit der Arbeit an der aktuellen Karte beginnt, und sie läuft, bis sie fertig ist. Vorlaufzeit ist das, was Ihr Stakeholder empfindet, und die Zykluszeit ist die Arbeitsgeschwindigkeit des Teams, sobald es etwas erledigt hat Wenn Ihre Karten wochenlang im Backlog liegen , bevor jemand anfängt, kann Ihre Zykluszeit großartig aussehen , während Ihre Vorlaufzeit schrecklich aussieht, aber nur der Kunde wird das bemerken Was sagt Ihnen also die Vorlaufzeit? Vorlaufzeit ist eine einzige Zahl, aber sie verdient sich ihren Bestand auf verschiedene Weise An erster Stelle steht die Berechenbarkeit. Sobald Ihre Vorlaufzeit stabil ist, können Sie ehrliche Zusagen machen, da die meisten Anfragen innerhalb von zwei Wochen bearbeitet werden Zweitens ist die Frühwarnung. Wenn die Vorlaufzeit schleichend zu steigen beginnt, blockiert etwas den Ablauf, und Sie werden es oft hier sehen, bevor es irgendwo anders auftaucht Und drittens sind Prognosen. Ihre bisherigen Vorlaufzeiten sind der beste Anhaltspunkt dafür, wann eine neue Arbeit realistischerweise abgeschlossen sein wird Es gibt also keine Vermutung, dass es nur das ist, was in diesen Fällen tatsächlich passiert Das kumulative Flussdiagramm zeigt Ihnen also , wo die Arbeit feststeckt, und die Vorlaufzeit zeigt Ihnen, wie lange es wirklich Beides macht aus einem geschäftigen Board etwas Sie tatsächlich nachdenken können. Das ist also das Ende. Danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten werden wir einen Schritt zurücktreten und eine umfassendere Frage stellen. Messen wir, wie viel wir produzieren oder welchen Unterschied das tatsächlich macht? Wir sehen uns in der nächsten Lektion. 25. Ergebnismetriken im Vergleich zu Ausgangsmetriken: Willkommen zurück. In dieser Lektion werden wir die wichtigste Messentscheidung treffen , den Unterschied zwischen Output und Ergebnis. Es ist der Unterschied zwischen viel zu tun und wertvoll zu sein, und wenn man etwas falsch macht, arbeiten Teams am Ende auf Hochtouren, während sich nichts , was wichtig ist, verbessert. Am Ende dieser Lektion werden Sie also in der Lage sein, die beiden voneinander zu unterscheiden und sie so zu verknüpfen, dass Ihre Zahlen tatsächlich einen Wert ergeben. Der wichtigste Unterschied in diesem Abschnitt ist also , dass Output das ist, was Sie produzieren, und Ergebnis ist der Unterschied, den es macht. Output ist das, was Sie ausliefern, wie Features, Tickets, Story Points, und das Ergebnis ist das was sich in der realen Welt dadurch ändert. Die Leute lernen mehr, kommen öfter zurück und zahlen gerne. Und die unbequeme Wahrheit ist, dass Sie viel versenden und nichts ändern können , was wichtig ist. Viel Leistung ohne Ergebnis. dieser Lektion geht es darum, diese beiden Ideen voneinander zu trennen. Schauen wir uns also zunächst die Output-Metriken an. Diese messen Ihre Aktivität, wie viel Arbeit das Team geleistet hat. Diese sind sehr nützlich, aber sie sind leicht begrenzt. Velocity ist der Klassiker. Es ist die Anzahl der Story Points , die ein Team pro Sprint abschließt, und sie ist ein Maß für den Durchsatz. versendeten Funktionen zählt, wie viele Dinge Sie veröffentlicht und wie viele Tickets Sie abgeschlossen haben, das schiere Arbeitsvolumen. Das haben sie alle gemeinsam. Sie sagen dir, dass das Team beschäftigt war und sie sagen dir nichts darüber, ob etwas davon tatsächlich geholfen hat. Also, Output antwortet, haben wir Dinge gebaut? Nein , sie waren wichtig. Jetzt kommen wir zu den Ergebniskennzahlen, das ist die andere Hälfte, und hier liegt der wahre Wert. Diese sind schwieriger zu messen, aber sie sind weitaus mehr wert. Bei unserer Sprachlern-App für Kinder sind die Ergebniskennzahlen also möglicherweise weniger vollständig. Lernenden tatsächlich den Unterricht, den sie begonnen haben, oder lernen sie wöchentlich aktiv oder kommen die Leute Woche darauf zurück oder driften sie ab? den Unterricht, den sie begonnen haben, oder lernen sie wöchentlich aktiv oder kommen die Leute Woche darauf zurück oder driften sie ab Oder Zufriedenheit der Eltern. Haben die Leute, die dafür bezahlen, das Gefühl, dass es sich lohnt? Diese sind heute schwieriger zu transportieren und schwerer zu fälschen , weil sie messen, ob das Produkt seinen Zweck erfüllt oder nicht. Das Ergebnis beantwortet also die Frage , die letztendlich zählt. Hat es geholfen? Nun, das ist die Falle, weil es leicht ist, in sie zu tappen. Wenn der Output alles ist, was Sie messen, fangen Sie an, ihn zu optimieren, und Sie können sehr damit beschäftigt sein, ins Leere zu gehen. Stellen Sie sich also den Quartalsbericht vor. In diesem Quartal haben wir zum Beispiel zehn neue Funktionen veröffentlicht. Jeder nickt und das Team sieht produktiv aus, aber keine dieser Funktionen wurde bis zur Fertigstellung verschoben Das ist also eine Menge Bewegung ohne Fortschritt. Die Funktionen waren echt, aber der Wert war es nicht. Also zwei Gewohnheiten, um Sie aus dieser Falle herauszuhalten: Die Lösung, jede Output-Metrik an ein Ergebnis zu binden, jede Output-Metrik an ein Ergebnis zu binden das sie verschieben soll , sodass der Versand immer einen Zweck hat , der über den Versand und den Test hinausgeht. bei jeder Zahl, die Sie verfolgen, Fragen Sie bei jeder Zahl, die Sie verfolgen, ob sie gestiegen ist und sich nichts wirklich verbessert Warum messe ich sie überhaupt? Die Antwort ist also nicht, Output-Metriken wegzuwerfen. Velocity und alles andere sind wirklich nützlich, um ein Team zu leiten Die Antwort besteht darin, jedes einzelne mit dem Ergebnis zu kombinieren , dem es dienen soll Die mitgelieferten Funktionen sollten der Fertigstellung der Lektion dienen. Die Geschwindigkeit sollte vorhersehbare Liefertermine gewährleisten. behobenen Fehler sollten Ihrer App Store-Bewertung und dem damit verbundenen Vertrauen dienen . Die hinzugefügten Inhalte sollten wöchentlich aktiven Lernenden dienen. Sie verfolgen sie also Seite an Seite, und in dem Moment, in dem die Leistung steigt, während das Ergebnis stagniert, haben Sie sich dabei ertappt, beschäftigt zu sein , anstatt nützlich zu sein. Genau das ist die Warnung, die Sie Der Output ist also das, was Sie tun, und das Ergebnis ist der Zweck, und die gesündesten Teams behalten beide Aspekte Vielen Dank, dass Sie mich in dieser Lektion begleitet haben. In der nächsten werden wir uns ansehen, wie selbst gute Kennzahlen wiederverwendet werden können und was Sie darauf achten sollten, niemals zu messen Wir sehen uns im nächsten. 26. Vermeiden von Missbrauch von Messwerten – Was nicht gemessen werden sollte: Willkommen zurück. Dies ist eine kurze, aber wichtige Lektion , denn eine Metrik kann ein zweischneidiges Schwert Wir werden uns ansehen, wie aus guten Zahlen schlechte werden und welche spezifischen Dinge Sie nicht messen sollten. Außerdem werden wir uns mit einer gesünderen Methode befassen, Kennzahlen so zu speichern , dass sie Ihrem Team helfen, anstatt es zu schädigen Fangen wir also an. Beginnen Sie also mit einem Metrikgesetz, das es wert ist, auswendig gelernt zu Es heißt Goodhartsches Gesetz, und es besagt, dass, wenn eine Kennzahl zu einem Ziel wird, sie kein gutes Maß sie kein gutes Einfach ausgedrückt: Sobald Sie eine Zahl in ein Tor verwandeln, Sobald Sie eine Zahl in ein Tor verwandeln für das die Leute belohnt oder bestraft werden, werden sie anfangen, mit der Zahl anstatt die eigentliche Arbeit dahinter zu erledigen Die Maßnahme war also gerade deshalb nützlich , weil niemand versuchte , sie direkt zu bewegen. Wenn man diese Kennzahl zum Ziel macht, dann macht man genau das kaputt, weshalb es sich überhaupt lohnt, sie sich anzusehen . Hier sind also vier gängige Methoden , bei denen Metriken schief gehen können, sodass Sie erkennen können, dass sie kommen. Das erste ist Geschwindigkeit als Ziel. Wenn Sie sich ein Story-Point-Ziel setzen und die Schätzungen schnell in die Höhe schnellen, steigen die Punkte, die tatsächliche Arbeit jedoch nicht Als Nächstes kommt die individuelle Leistung, eher Personen als Teams gemessen werden, was die Zusammenarbeit zuverlässig zunichte macht, weil die Unterstützung eines Kollegen Sie jetzt auf Ihrer eigenen Anzeigetafel kostet . Sind Zahlen, die wunderbar aussehen und nichts bedeuten wie App-Downloads, sondern ob jemand das Ding tatsächlich benutzt Und zu guter Letzt gibt es Metriken als Waffe. Zahlen, die früher den Leuten die Schuld gegeben haben , bringen einfach jedem bei, Probleme zu verstecken, anstatt sie an die Oberfläche zu bringen und zu lösen Das Wichtigste ist also , das Team zu messen, nicht die Person. Eine der schnellsten Methoden , ein Team zu messen, besteht darin eine Einzelperson und nicht das Team zu messen. Agile Metriken sollen das System eines Teams beschreiben, nicht den Wert einer Einzelperson. Geschwindigkeit, Vorlaufzeit, kumulativer Ablauf, diese beschreiben, wie der Ablauf funktioniert, nicht, wie sehr sich jemand diese Woche bemüht hat Moment ist eine Kennzahl , die verwendet wird , um Personen gegeneinander einzustufen Es hört auf, die Wahrheit zu sagen , weil jeder anfängt für seine eigene Zahl zu optimieren, anstatt für das gemeinsame Ergebnis zu optimieren. Sie messen also das System und unterstützen die einzelnen Personen. Also, wie benutzt man dieselben Zahlen gut? Es gibt drei Veränderungen im Geiste. Nutze sie zum Lernen, nicht zum Urteilen. Fragen Sie, was Sie aus einer Zahl lernen, und nicht, wer dafür verantwortlich Wir beobachten Trends, keine Schnappschüsse. Ein einziger Datenpunkt ist Rauschen, und die Richtung über mehrere Wochen ist das eigentliche Signal Behandeln Sie eine Kennzahl als Frage, nicht als Urteil Eine überraschende Zahl sollte eine Konversation beginnen nicht beenden. Gleiche Daten, völlig unterschiedliche Wirkung auf Ihr Team. Der Umgang mit Kennzahlen kann Ihnen als Richtschnur dienen, aber wenn sie unachtsam behandelt werden, können sie Sie in die Irre führen und dem Team schaden Halten Sie sie also auf das System gerichtet und Sie sie neugierig werden, anstatt sie zu beschuldigen Vielen Dank, dass Sie sich mir bei dieser Lektion angeschlossen haben. In der nächsten bist du dran. Wir erstellen ein einfaches Make Metrics-Dashboard für Ihr Projekt in Notion. Ich werde dich dort sehen. 27. Übung: Erstellen eines Metrik-Dashboards: Willkommen zurück. In dieser Übungsstunde werden Sie Ihre eigene Metrikdatenbank in Notion erstellen . Also stellen wir das für Ihr Projekt zusammen. Ich werde eine auf dem Bildschirm erstellen, und dann können Sie eine Pause einlegen und selbst eine erstellen. Notion ist also wie immer kostenlos, läuft in Ihrem Browser und alles funktioniert heute mit dem kostenlosen Plan, und alles funktioniert heute mit dem kostenlosen Plan ohne dass zusätzliche Add-Ons erforderlich sind. Also lass uns gehen. Hier ist die Übung in vier Schritten. Erstens: Wählen Sie drei oder vier Kennzahlen, eine bewusste Mischung aus Output und Ergebnis, und widerstehen Sie dem Drang, alles nachzuverfolgen Zwei für jede einzelne, sagen Sie, wofür sie gedacht ist. Die Frage, die es zu beantworten gibt. Drittens: Erstellen Sie eine Seite, die eigentlich nur eine einfache Tabelle ist, und viertens, der Schritt, der wirklich wichtig ist, ist, sie wöchentlich zu aktualisieren. Ein Dashboard, das niemand aktualisiert, ist nur Dekoration. Also ein kleiner Hinweis zur Auswahl Ihrer Metriken. Lass uns ein Saldo auswählen, das für unsere Sprachlern-App eingerichtet wurde, damit du die Mischung sehen kannst. Geschwindigkeit, bei der es sich um eine Output-Metrik handelt, beantwortet: Liefern wir in gleichbleibendem Tempo? Abschluss der Lektion, also ein Ergebnis, Antworten bedeuten, dass die Lernenden das, was sie begonnen haben, mit wöchentlichen aktiven Lernenden beenden , ein weiteres Ergebnis, Antworten sind, dass die Leute wiederkommen Und dann die Anzahl der offenen Bugs, das Ergebnis der Antworten, ist die Qualität unter Kontrolle Also nicht, es ist die Bilanz, zwei Zahlen darüber, was wir tun, und zwei Zahlen darüber , ob es funktioniert. Vier Metriken sind ausreichend. Ein Dashboard, das Sie tatsächlich behalten, ist besser als ein schönes, das Sie verlassen. Also halte es einfach. Okay, also baue ich es in Notion. Sie können es mit den folgenden Schritten in Ihrem kostenlosen Konto erstellen . Sie werden also eine Tabelle mit den Spalten für die Metrik diese Woche, letzte Woche und den Trend hinzufügen den Spalten für die Metrik diese Woche, , und dann haben Sie eine Zeile in der Tabelle pro Metrik. Und dann haben wir in der letzten Tabelle den Trendpfeil, egal ob er nach oben, unten oder flach verläuft, und das ist der am schnellsten gelesene Wert auf der Seite. Okay? Schauen wir uns also an , wie das in Notion aussehen wird. Ich habe unten eine neue Seite mit dem Namen Metriks-Dashboard hinzugefügt , und dann habe ich darin eine neue Tabelle hinzugefügt. In diesem Fall werden wir keine Datenbank verwenden. Wir werden einfach eine normale Tabelle verwenden. Und ich habe die vier Spaltenüberschriften oben, die Metrik diese Woche, letzte Woche und Trend. Ich habe die Geschwindigkeit, die einen Anstieg gegenüber letzter Woche zeigt. Ich habe einen Anstieg der Anzahl der abgeschlossenen Lektionen festgestellt. Also nochmal, mit dem Aufwärtspfeil. wöchentlichen aktiven Lernenden ist in dieser Woche höher als in der letzten Woche, es gibt also einen weiteren Aufwärtspfeil Schließlich haben wir offene Bugs, sieben in dieser Woche, neun letzte Woche, also ist der Trend rückläufig Das ist ein ziemlich positives Metrik-Dashboard Ich muss sagen, in diesem Projekt läuft alles sehr gut. Kehren wir zur Show zurück. Jetzt können Sie das Video pausieren und Ihr eigenes erstellen. Wenn es fertig ist, überprüfe es anhand dieser vier Dinge. Wir haben also ein paar Metriken , die gut gewählt sind, drei oder vier, denen Sie vertrauen, besser als 20, die Sie ignorieren. Sie haben eine Mischung aus Output und Ergebnis, nicht nur, was Sie getan haben, sondern auch, ob es tatsächlich geholfen hat. Drittens hat jede Metrik einen Zweck. Wenn du nicht sagen kannst, wofür es ist, dann lösche es. Und der letzte ist, dass es tatsächlich so geblieben ist. Die Zahlen sind also aktuell und werden nach einem Zeitplan aktualisiert , den Sie realistischerweise einhalten Wenn Sie alle vier dieser Dinge treffen, haben Sie ein Dashboard, das Sie im Stillen zu einem wunderbaren Entscheidungsträger machen wird Sie im Stillen zu einem wunderbaren Entscheidungsträger So gut gemacht. Sie können jetzt den Fortschritt bei Burndown und Burnup Sie können ein Cam-Band-System mit kumulativem Ablauf und Durchlaufzeit ablesen mit kumulativem Ablauf und Durchlaufzeit und Sie können das Ergebnis vom Ergebnis unterscheiden, die üblichen Fallstricke vermeiden und alles in einem einfachen Dashboard zusammenfassen So tolle Arbeit. Danke , dass du zu mir gekommen bist. Im nächsten Abschnitt werden wir den gesamten Agile-Kurs für Fortgeschrittene abschließen den gesamten Agile-Kurs für Fortgeschrittene und diese Fäden zusammenführen. Ich werde dich dort sehen. 28. Häufige Zwischenfallprobleme: M Das ist also eine gefährliche Phase. Du weißt gerade genug. Also hier ist die Sache mit dieser Phase. Die Grundlagen von Agile sind leicht zu erlernen und leider auch leicht zu fälschen. Sie können jede Zeremonie perfekt durchführen, jedes Meeting treffen, jede Tafel ausfüllen und trotzdem den Sinn aller Veranstaltungen komplett verfehlen. Das ist also die Zwischenfalle. Es geht makellos durch die Bewegungen , während der Wert leise durchsickert wir also diese Fallstricke durchgehen, stellen Sie fest, dass es bei fast keiner von ihnen darum geht, das Falsche zu tun Es geht darum, das Richtige zu tun, aber aus dem falschen Grund oder aus einem völlig vergessenen Grund Beginnen Sie also mit dem Prozess selbst. Wir haben vier Möglichkeiten, wie das Ritual überlebt, aber der Zweck stirbt Die ersten sind Fracht-Kult-Zeremonien, denen die Treffen auswendig ablaufen, die Choreographie durchgehen, die Choreographie durchgehen ohne wirklich zu wissen, wofür die einzelnen Als nächstes folgt der Zombie-Stand Up, ein täglicher Statusbericht, der dem Manager zugestellt wird , anstatt das Team tatsächlich miteinander synchronisiert Sprints, die heimlich Mini-Wasserfälle sind. Also eine Designwoche, dann eine Build-Woche, dann eine Testwoche, das ist der alte sequentielle Prozess, bei dem man ein Agile-Kostüm trägt Und schließlich bedeutet eine Definition von erledigt, die sich leise ändert, also erledigt fast dasselbe, wann immer eine Frist ansteht fast dasselbe, wann immer eine Frist In jedem Fall stimmt die Form, aber die Substanz ist weg Als Nächstes haben wir die Fallstricke der Menschen. Dies sind die subtileren und die teureren Misserfolge. Der Auftragsnehmer (PO), Product Owner, der einfach weiterleitet, was gefragt wird, anstatt Prioritäten zu setzen, sodass Backlog zu einem Hinweis auf die individuellen Wünsche aller wird Als nächstes kommt die Heldenkultur, in eine Person jeden Sprint in letzter Minute speichert. Das sieht beeindruckend aus , ist aber in Wirklichkeit äußerst fragil, weil an dem Tag, an dem sie frei haben, alles vorbei Der vergessene Stakeholder ist die stille Person, die Sie nie kartografiert haben, die im ungünstigsten Moment auftaucht, um Sie zu blockieren, und fragen also bei jeder Bewertung pflichtbewusst nach Feedback und ignorieren dann alles, was den Leuten beibringt, sich nicht mehr darum was den Leuten beibringt Als Nächstes haben wir metrische Fallstricke, die wir uns im letzten Abschnitt angesehen haben und die Das erste ist also Geschwindigkeit als Ziel. In dem Moment, in dem Punkte zu einem Ziel werden, erhöhen sich die Schätzungen, um es zu erreichen, und die Zahl steigt, während die eigentliche Arbeit nicht erreicht und die Zahl steigt, während die eigentliche Arbeit nicht Leistung ist wichtiger als Ergebnis, zehn ausgelieferte Funktionen die nichts bewegen, irgendjemand hat sich wirklich für Eitelkeitsmetriken interessiert, also Zahlen, die auf einer Folie gut aussehen aber im Grunde nichts bedeuten, wie zum Beispiel Herunterladen ohne Nutzung Und dann endlich Menschen messen. Wenn man also Kennzahlen nimmt, die ein Teamsystem beschreiben sollen , und sie in individuelle Scorecards umwandeln , was jedes Team zuverlässig vergiftet Also das Heilmittel ist in der Regel dasselbe, also einige gute Neuigkeiten Und es ist im Grunde nur eine einzige Frage. also bei jedem Ritual, jeder Metrik, Fragen Sie also bei jedem Ritual, jeder Metrik, jeder Gewohnheit, ob uns das wirklich hilft, einen Mehrwert zu schaffen? Wenn Übung dem nicht dient , darfst du es ändern. Das Framework dient dir. Sie speichern das Framework nicht. Also und darunter sitzen die beiden Gewohnheiten, auf denen die Hall of Agile beruht, und inspizieren. Schauen Sie sich also ehrlich an, was passiert, nicht die aufgeräumte Version, die in Ihrem Kopf vorgeht, und passen Ändern Sie also eine Sache, beobachten Sie, was passiert, und behalten Sie dann bei, was funktioniert Wenn du diese beiden Dinge wiederholt und ehrlich machst, wirst du aus fast jeder einzelnen Falle auf dieser Liste Die mittlere Gefahr ist nicht Unwissenheit. Es geht durch die Bewegungen. Fragen Sie sich also immer wieder, ob jede Praxis ihren Platz verdient. Danke, dass du zu mir gekommen In der nächsten Lektion werden wir diese Linse anhand einer ehrlichen Selbsteinschätzung auf Sie richten. Bist du bereit, tatsächlich ein Team zu leiten? Wir sehen uns im nächsten. 29. Selbstbewertung: Sind Sie bereit für Führung?: Willkommen zurück. Diese Lektion wird also ein ehrlicher Blick in den Spiegel sein. Wir werden eine Selbsteinschätzung durchführen , damit Sie klar erkennen können , was Sie bereits können und in welchen Bereichen Sie üben müssen. Das ist also kein Test mit einer Mindestpunktzahl. Es ist eher eine Möglichkeit, aus einer vagen Antwort, ob ich bereit bin, mich zu fühlen, eine konkrete und nützliche Antwort zu machen ich bereit bin, mich zu fühlen, eine konkrete und nützliche Antwort Schnappen Sie sich also einen Stift, wenn Sie möchten, und lassen Sie uns gemeinsam die Selbsteinschätzung durchführen Wie ich schon sagte, das ist ein Check-in, keine Prüfung. Regel Nummer eins, sei ehrlich und spezifisch. Antworten Sie auf jeden Punkt mit einem konkreten Beispiel, vielleicht nicht hoffnungsvoll Also ja, ich habe diesen letzten Sprint gemacht, zählt, aber ich glaube, ich könnte nicht zählen Der Wert dieser Übung liegt einzig und allein darin , wie ehrlich Sie darauf antworten. Eine großzügige Punktzahl, die Sie nicht verdient haben, beraubt Sie also nur eines klaren Verbesserungsplans, falls das notwendig ist Oh, kannst du die Mechanik kontrollieren, die beweglichen Teile eines Sprints? Kannst du einen kompletten Sprint von Ende zu Ende laufen? Können Sie es planen, ausführen, überprüfen und eine Retrospektive abhalten Kannst du dein Board einrichten? Kannst du ein Scrum - oder ein Caban-Board erstellen , das auch andere Leute nutzen können, nicht nur Kannst du einen Backlog priorisieren, indem du die Arbeit nach Wert ordnest und sie geordnet hältst, wenn sich diese Dinge ändern Und können Sie die Arbeit anhand von Punkten oder T-Shirt-Größen vernünftig einschätzen , ohne eine falsche Genauigkeit vorzugeben Wenn Sie hier vier Ja-Stimmen haben, dann sind Sie mit dem Konzept des agilen Sprints sehr vertraut mit dem Konzept des Als Nächstes: Kannst du mit den Leuten umgehen? Das ist wichtiger als der letzte Abschnitt. Dies ist der Bereich, der tatsächlich darüber entscheidet, ob Projekte erfolgreich sind oder nicht. Können Sie also Ihre Stakeholder kartieren und sagen , wer wichtig ist und wie viel Aufmerksamkeit jeder benötigt? Können Sie ein Sprint-Review durchführen, das echte Arbeit zeigt und Feedback einholt , das Sie tatsächlich nutzen können Können Sie Veränderungen aufnehmen und neue Anforderungen berücksichtigen, ohne das Team aus der Bahn zu werfen? Und schließlich: Können Sie in weniger als einer Minute ein klares Update verfassen, das einem Stakeholder mitteilt, was er benötigt Diese sind schwieriger als die Mechaniken eines Sprints und sie sind wichtiger Die nächste ist, kannst du die Signale lesen? Das sind also die Zahlen , die dich ehrlich halten. Können Sie sich ein Burn-down-Diagramm oder ein kumulatives Flussdiagramm ansehen und in einfachen Worten sagen, was wirklich vor sich geht? Können Sie das Ergebnis anhand eines Ergebnisses unterscheiden? Können Sie den Unterschied erkennen , ob Sie beschäftigt sind oder wirklich wertvoll Und können Sie den Missbrauch von Kennzahlen erkennen? Sie also feststellen, wenn eine Zahl hinzugewonnen oder stillschweigend in eine Waffe verwandelt wird , wenn Sie diese Signale lesen können, können Sie sich an Beweisen orientieren, statt an Bauchgefühl Also addiere deine ehrlichen Ja. Wenn es meistens ja ist, dann bist du bereit, ein Team zu leiten Sie können die Prozesse ausführen, Sie können mit den Mitarbeitern umgehen und die Signale lesen, was genau das ist, was der Job erfordert. Also mach weiter und mach es. Wenn Sie einige Lücken haben, ist das kein Misserfolg. Es ist nur eine Karte. Jedes Nein weist also direkt auf einen Abschnitt dieses Kurses hin, den es wert ist, erneut besucht Also fängt niemand mit einem vollständigen Ja-Wort an. Der Sinn dieser Übung besteht darin, zu wissen, was was ist, damit Sie genau wissen, worauf Sie sich als Nächstes konzentrieren müssen Eine ehrliche Selbsteinschätzung ist wirklich jedes Mal besser als falsches Selbstvertrauen , weil sie Ihnen sagt , wo Sie sich verbessern müssen. Danke, dass du zu mir gekommen bist. In der nächsten Lektion werden wir es an Ihrem aktuellen Projekt in die Praxis umsetzen Ihren Release-Plan und Ihre bisherigen Kennzahlen überprüfen. Wir sehen uns in der nächsten. 30. Projektüberprüfung: Releaseplan und Kennzahlen: Willkommen zurück. Dies ist eine praktische Lektion, also sind Sie an der Reihe, an Ihrem Projekt zu arbeiten. Wir werden eine Überprüfung Ihrer bisherigen Projekte, Ihres Release-Plans und Ihrer Kennzahlen durchführen , und wir werden sie alle an einem Ort zusammenfassen, und dieser eine Ort wird in Notion sein. Also hier ist die Übung in vier Schritten. Erstens: Sammeln Sie Ihre Artefakte, Ihr Board, Ihren Backlog, Release-Plan und Ihre Kennzahlen und haben Sie sie alle an einem Ort Zweitens: Überprüfe den Release-Plan und frage, ob er immer noch realistisch ist oder ob sich der Umfang stillschweigend verändert hat. Drittens: Überprüfen Sie die Kennzahlen und lesen Sie, was Ihnen die Trends tatsächlich sagen, sowohl das Ergebnis als auch die Ergebnisse. Und viertens: Notieren Sie sich, was Sie ändern würden. Also nur ein oder zwei ehrliche Anpassungen für das nächste Mal. Schauen wir uns nun die beiden mittleren etwas genauer an. Überprüfen Sie also zunächst Ihren Release-Plan. Falls Sie mit dem Begriff Releaseplan nicht vertraut sind, handelt es sich lediglich um eine grobe Übersicht darüber, was ausgeliefert werden soll , und nicht um einen starren Zeitplan, sondern um eine gemeinsame Erwartung. Für unsere Sprachlern-App könnte es also so aussehen. Version eins, die wichtigsten Lektionen sind bereits ausgeliefert. Version zwei handelt es sich um eine E-Mail mit einer Zusammenfassung von Badgers plus Eltern, die gerade in Bearbeitung ist, und in Version drei ist das Eltern-Dashboard geplant, aber noch nicht gestartet Die Bewertungsfrage hier ist einfach und wichtig. Entspricht das immer noch der Realität? Pläne driften also, vielleicht ist Version zwei gewachsen oder vielleicht hat sich Version drei als wichtiger herausgestellt, als Sie dachten. den Plan überprüfen, erkennen Sie diese Abweichung absichtlich , anstatt sich zu einem späteren Zeitpunkt davon überraschen zu lassen. Als Nächstes überprüfen wir Ihre Kennzahlen mithilfe des Dashboards , das wir in der letzten Lektion erstellt haben. Werfen Sie also nicht nur einen Blick auf die Zahlen, lesen Sie sie als Geschichte. konstante Geschwindigkeit zeigt Ihnen also Ihr Liefertempo vorhersehbar ist, was für jedes Versprechen, das Sie geben, eine gute Nachricht ist. Lektion abgeschlossen haben, wissen Sie, dass das Kernprodukt wirklich bei den Lernenden ankommt Wöchentlich aktive Benutzer zeigen Ihnen, dass die Leute wiederkommen und nicht wegdriften, und wenn Sie Bugs down öffnen, wissen Sie, dass Sie die Qualität also zusammen lesen, diese vier Zahlen also zusammen lesen, erhalten Sie ein überraschend ehrliches Bild vom Zustand des gesamten Projekts Hier ist also ein einfaches Bewertungsformat, dem Sie folgen sollten. Um all das zu erfassen, braucht man eigentlich nur vier ehrliche Überschriften. Was läuft gut? Also nenne die Siege klar , denn sie sind wirklich leicht zu vergessen, wenn du unter Druck stehst. Was steckt fest? Also die Engpässe und Blockaden, an denen du still und leise Als Nächstes hat sich das geändert. Sind es der Umfang, die Prioritäten oder Personen, die sich verändert haben, seit Sie angefangen haben? Und dann endlich, was kommt als Nächstes? Also ein oder zwei Dinge , die du im nächsten Sprint bewusst anders machen wirst. Das ist Ihre Bewertungsstruktur. Also alles auf einer Seite in Notion zusammenfassen. Auf dieser einzigen Seite sollten Sie einen Release-Plan haben. Sie sollten Ihr Velocity-Log und dann einige Bewertungsnotizen haben . Ich zeige dir genau das in Notion aussehen würde. Also habe ich eine Projektbewertung hinzugefügt. Nun, Sie werden wahrscheinlich in der ersten Woche keine Projektrezension haben, aber da wir in diesem Projekt bisher nur eine Woche gearbeitet haben, werde ich nur Woche eins hinzufügen. Auf dieser Seite habe ich zwei Links zum Versionsplan und zum Metriken-Dashboard. Um das zu tun, können Sie den Link kopieren und dann einfügen. Zeig dir, wie das aussieht. Wenn Sie es also einfügen, wird der Link direkt eingefügt. Und wenn Sie dann einfach auf Erwähnen klicken, erhalten Sie den direkten Link zu dieser Seite. Also habe ich auf dieser Seite auch den Link zu den Metriken und dem Dashboard hinzugefügt , und dann habe ich unten angegeben, was gut gelaufen ist, was nicht funktioniert hat, was sich geändert hat und was als Nächstes kommt. Also unter diesen Überschriften ist das übrigens Überschrift zwei Sie können eine Aufzählung erstellen und Sie sollten diese vier Fragen beantworten So sollte das Grundgerüst dieser Seite in einem Moment aussehen . Schauen wir uns nun an, wie gut aussieht Also pausiere das Video und erstelle deine eigene Bewertung. Wenn es fertig ist, überprüfe es anhand dieser vier Dinge. Erstens, dass es ehrlich ist, dass die festgefahrene Spalte nicht leer ist, weil eine Bewertung ohne Reibung keine echte Bewertung ist. Sie verwendet Beweise. Ihre Behauptungen werden vom Vorstand und den Kennzahlen untermauert , nicht nur vom Gefühl. Es ist kurz. Eine Seite könnte vor einem Treffen gelesen werden. Und schließlich endet es mit einer Aktion, zumindest einer konkreten Sache , die Sie beim nächsten Mal ändern werden. Wenn Sie diese vier Dinge erreichen, haben Sie etwas getan, das die meisten Teams nicht ganz schaffen, nämlich aufzuhören und wirklich aus ihrem eigenen Projekt zu lernen und aus dem Zustand ihres eigenen Projekts Eine gute Bewertung macht also ein paar arbeitsreiche Wochen zu Lektionen , die Sie tatsächlich nutzen können, und diese Angewohnheit unterscheidet Menschen, die ihre Fehler wiederholen, von Menschen, die ihre Fähigkeiten verbessern Also danke, dass du zu mir gekommen bist. In der letzten Lektion werden wir uns ansehen, wohin Sie von hier aus gehen und welchen Weg in Ihrem agilen Projektmanagement einschlagen werden. Wir sehen uns also beim nächsten Mal. 31. Was kommt als nächstes: Der Weg nach vorn: Willkommen zur letzten Lektion dieses Kurses. In dieser letzten Lektion werden wir nur die Ansicht verkleinern. Wir werden uns ansehen, wie weit Sie gekommen sind, und wir werden die nächste Schicht benennen und Sie auf den Weg hinweisen, der vor Ihnen liegt. Das ist also kurz, also lasst uns dafür sorgen, dass es zählt. Also zuerst wollen wir nur schauen, wie weit du gekommen bist. Also gönnen Sie sich etwas Anerkennung, denn Sie haben in diesem Kurs viel gelernt. Und lassen Sie mich es kurz für Sie zusammenfassen. Sie haben jetzt also Frameworks studiert. Sie können Scrum oder Cam Ban oder eine sinnvolle Mischung aus beiden wählen und ausführen eine sinnvolle Mischung , anstatt standardmäßig einem zu folgen Mit Stakeholdern können Sie die Personen rund um Ihr Projekt abbilden die Personen rund um Ihr Projekt Sie können Bewertungen mit ihnen durchführen und sie auf dem Laufenden halten, und sie auf dem Laufenden halten ohne die Zeit anderer zu verschwenden Und schließlich die Kennzahlen, Sie den Fortschritt, den Ablauf und die tatsächlichen Ergebnisse ehrlich messen können , und Sie können auch erkennen, wenn eine Zahl Sie irreführt Das ist also das Toolkit für jemanden, der wirklich ein Agile-Projekt durchführen kann . Gut gemacht. Also vom Tun zum Führen, das ist der Wandel , der als Nächstes kommt. Also ist es nicht einfach mehr vom Gleichen. Bisher haben Sie gelernt, ein Agile-Projekt gut durchzuführen. Der nächste Schritt ist in seiner Art anders. Es geht darum, die Mitarbeiter zu führen und Arbeitsweise eines gesamten Teams im Laufe der Zeit zu verbessern. Einen guten Sprint zu laufen ist also eine Fähigkeit, aber ein Team aufzubauen, das gute Sprints ablegt, ohne dass du über ihnen stehst und das von selbst immer besser wird, ist eine andere und tiefgründigere Fähigkeit Dieser Übergang von Agile zur Führung ist die nächste Phase Ihres Wachstums als agile Führungskraft Von hier aus führt Ihre Agile-Reise, nach der Zwischenstufe, zunächst um Skalierung, also darum, wie Sie mehr als ein Team koordinieren können, ohne alle im Prozess zu ertränken Als Nächstes geht es um Qualität und Risiko, also darum, wie man Qualität von Anfang an einbaut und ohne großen Papierkram vernünftig mit Risiken umgeht Als Nächstes folgt die kontinuierliche Verbesserung. Also Kais Ende, die Gesundheit des Teams im Auge zu behalten und scharf zu bleiben, ohne die Leute auszubrennen. Und schließlich geht es um Coaching, um ein Team aufzubauen, das sich selbst verbessert, und zu führen, ohne es zu kontrollieren. Mit anderen Worten, es ist die Führungshälfte von Agile, die zur Hälfte der Umsetzung passt , die Sie gerade gemeistert haben Das ist also das Ende dieses Kurses. Herzlichen Glückwunsch. Sie haben damit angefangen, sind in der Lage, einem agilen Prozess zu folgen, und Sie beenden ihn. Sie sind in der Lage, ihn mit gutem Urteilsvermögen durchzuführen, mit den Menschen an Ihrer Seite und mit ehrlichen Zahlen, an denen Sie sich orientieren Das ist also eine sehr reale Leistung, und darauf sollten Sie stolz sein Also vielen Dank, dass Sie sich mir angeschlossen haben und für all die Arbeit, die Sie investiert haben , und viel Glück auf Ihrem Weg zum agilen Projektmanagement. 32. Schulungsprojekt: Planung einer Multi-Sprint-Veröffentlichung und Erstellung eines Projektmanagement-Dashboards: Jetzt ist es an der Zeit, Ihr Agile-Projekt zu erweitern. Für Ihr Klassenprojekt bauen Sie auf dem Projekt auf, das Sie im Laufe des Kurses entwickelt haben , indem Sie eine komplette Multi-Sprint-Version planen und ein einfaches Projektmanagement-Dashboard erstellen. Definieren Sie zunächst ein Release-Ziel und teilen Sie Ihre Arbeit in mehrere Sprints Schätzen Sie dann Ihren Backlog ab, priorisieren Sie Ihre Arbeit und prognostizieren Sie, wie sich Ihr Projekt im Laufe der Zeit entwickeln könnte Wählen Sie als Nächstes das Framework aus , das am besten zu Ihrem Projekt passt. Sie können Scrum weiterhin verwenden, Ihre Arbeit auf Caban umstellen oder einen hybriden Ansatz erstellen, der auf Ihren Projektanforderungen basiert Sie werden auch Ihre wichtigsten Stakeholder identifizieren und ein Projekt-Update vorbereiten , in dem Fortschritte, Prioritäten und alle wichtigen Änderungen kommuniziert , Prioritäten und alle Erstellen Sie abschließend mit Notion oder einem anderen Tool Ihrer Wahl ein einfaches Metrik-Dashboard mit Notion oder einem anderen Tool Ihrer Wahl Fügen Sie Kennzahlen hinzu, die Ihnen helfen, den Fortschritt Ihres Projekts zu verstehen und bessere Entscheidungen zu treffen. Wenn Sie fertig sind, laden Sie Screenshots Ihres Release-Plans, Projektboards und Ihres Kennzahlen-Dashboards die Projektgalerie hoch. Sie können auch gerne eine kurze Erklärung beifügen, warum Sie Ihren Workflow gewählt haben und wie Sie bei der Sie Ihren Workflow gewählt haben und Planung Ihres Projekts vorgegangen sind. Das Ziel ist nicht, ein perfektes Projekt zu erstellen. Es geht nur darum zu zeigen, dass Sie über einen einzelnen Sprint hinaus denken und ein Projekt aus einer breiteren, strategischeren Perspektive managen können. 33. Wir gratulieren!Was kommt als Nächstes?: Herzlichen Glückwunsch zum Abschluss des Kurses. Sie haben jetzt die Grundlagen von Agile hinter sich gelassen und ein viel umfassenderes Verständnis dafür entwickelt ein viel umfassenderes Verständnis dafür wie erfolgreiche Projekte im Laufe der Zeit geplant, verwaltet und durchgeführt werden Laufe der Zeit geplant, verwaltet und durchgeführt In diesem Kurs haben Sie gelernt, Release-Pläne zu erstellen, Arbeitsabläufe effektiver einzuschätzen, Arbeitsabläufe effektiver einzuschätzen zwischen Scrum und MBA zu wählen, mit Stakeholdern zu kommunizieren und aussagekräftige Kennzahlen als Grundlage für Ihre Entscheidungen zu verwenden Denken Sie daran, dass es bei Agile nicht darum geht , ein Framework perfekt zu befolgen, sondern darum, kontinuierlich zu lernen, sich anzupassen und die Praktiken auszuwählen, Ihr Team und Ihr Projekt am besten unterstützen Falls Sie es noch nicht getan haben, stellen Sie sicher , dass Sie Ihr Projekt in die Galerie hochladen. Ich würde gerne sehen, wie du deine Veröffentlichung geplant und deinen Arbeitsablauf strukturiert hast. Wenn dir der Kurs gefallen hat, erwäge bitte, uns eine Bewertung zu hinterlassen. Es hilft uns, zukünftige Kurse zu verbessern , und hilft anderen Lernenden, den Kurs zu entdecken Danke, dass du zu mir gekommen bist und ich hoffe , dich in der nächsten Klasse zu sehen