Masterclass Projektmanagement für Einsteiger: Führen Sie Ihr erstes agiles Projekt durch

1. Willkommen Zur Masterclass Für Anfänger In Agiles Projektmanagement!: Mm hmm. Willkommen zum Kurs Agiles Projektmanagement für Einsteiger Haben Sie sich jemals gefragt, wie erfolgreiche Teams Projekte organisieren, wechselnden Prioritäten umgehen und konsistent Ergebnisse erzielen? Wenn ja, sind Sie hier richtig. Mein Name ist Luke Phillips und ich bin Projektmanager mit sieben Jahren Erfahrung in der Arbeit mit agilen Methoden für verschiedene Arten von Projekten und Teams In diesem Kurs werde ich Ihnen helfen, agiles Projektmanagement auf praktische, anfängerfreundliche Weise zu verstehen agiles Projektmanagement auf praktische, anfängerfreundliche Weise praktische, anfängerfreundliche Eine der größten Herausforderungen beim Erlernen von Projektmanagement besteht darin, dass sich viele dieser Kurse auf die Theorie konzentrieren ohne zu zeigen, wie Projekte in der Praxis tatsächlich funktionieren. Aus diesem Grund ist dieser Kurs darauf ausgerichtet , Schritt für Schritt ein echtes Projekt aufzubauen. Gemeinsam werden wir die agile Denkweise erforschen. Wir werden die Prinzipien hinter Scrum kennenlernen, verstehen, wie Produkt-Backlogs und User Stories funktionieren, und wir werden beliebte Tools wie Trello und Notion verwenden , um unser Projekt zu organisieren Sie werden lernen, Sprints zu planen, Arbeit zu priorisieren, Aufgaben zu schätzen, Besprechungen abzuhalten, Änderungen zu verwalten und Fortschritte zu überprüfen, genau wie es Agile-Teams Während des gesamten Kurses wenden Sie alles auf ein Projekt-Briefing Ihrer Wahl an und helfen Ihnen so, praktische Erfahrung zu sammeln anstatt sich Konzepte einfach einzuprägen Am Ende dieses Kurses werden Sie also den gesamten Agile-Projektlebensstil verstehen und haben Ihren eigenen Projektarbeitsplatz , Ihren Backlog und Ihren eigenen Sprintplan , den Sie Backlog und Ihren eigenen Sprintplan , können. Lass uns anfangen 2. Die agile Denkweise: Einführung in das agile Projektmanagement: Hallo und willkommen. In den nächsten 5 Minuten werde ich Ihnen eine der am meisten diskutierten Ideen im modernen Projektmanagement vorstellen . Agil. Am Ende dieses Videos werden Sie genau wissen, was Agile ist, woher es stammt und warum so viele Teams, die weit über die Softwarewelt hinausgehen , es übernommen haben. Ich bin Luke und habe die letzten etwa sieben Jahre als Projektmanager bei Edtech gearbeitet Das ist Bildungstechnologie, die Leitung digitaler Lernprojekte mit funktionsübergreifenden und internationalen Teams, und Agile war die ganze Zeit Teil meines täglichen Arbeitslebens, und ich möchte das für Sie entmystifizieren Was ist Agile also? Fangen wir einfach an. Agile ist eine Methode zur Verwaltung von Projekten, die die Arbeit in kleine, überschaubare Teile aufteilt in kleine, überschaubare Teile aufteilt und Schritt für Schritt einen Mehrwert liefert, anstatt am Ende alles Um zu verstehen, warum das wichtig ist, stellen sich die traditionelle Alternative vor, die als Wasserfall bezeichnet wird Bei Wasserfallprojekten planen Sie alles im Voraus und führen dann jede Phase in der Reihenfolge der Anforderungen, des Entwurfs, des Builds, des Tests und der Markteinführung Das funktioniert wunderbar, aber nur solange sich nichts ändert Und in der realen Welt ändern sich die Dinge ständig. Kunden könnten also ihre Meinung ändern, Märkte können sich verändern, neue Informationen könnten auf halbem Weg auftauchen, und Agile wurde genau für diese Realität entwickelt Statt eines großen Plans und einer großen Markteinführung arbeiten Sie also in kurzen Zyklen, normalerweise ein bis vier Wochen Und am Ende jedes Zyklus haben Sie etwas Reales vorzuweisen, Feedback zu erhalten und zu verbessern. Woher kam Agile also? Im Februar 2001 trafen sich 17 Softwareentwickler in einer Skihütte in Utah, und sie waren frustriert, dass herkömmliches dokumentenintensives Projektmanagement für Software nicht funktionierte Also schrieben sie an diesem Wochenende das Agile Manifesto Es besteht aus vier kurzen Werten und 12 unterstützenden Prinzipien. Und die vier kurzen Werte sind es wert, auswendig gelernt zu werden. Agile schätzt also Einzelpersonen und Interaktionen mehr als Prozesse und Tools Es legt mehr Wert auf funktionierende Produkte als auf umfassende Dokumentation. Es legt mehr Wert auf die Zusammenarbeit mit den Kunden als auf Vertragsverhandlungen, und es legt Wert darauf, auf Veränderungen zu reagieren, anstatt einem Plan zu folgen. Beachten Sie jetzt, dass das Wort vorbei ist. Die Artikel in der zweiten Zeile sind immer noch wichtig. Sie benötigen Prozesse, Unterlagen und Pläne, aber wenn Sie sich entscheiden müssen, sollten Sie die Dinge priorisieren, die ganz oben stehen Nun, obwohl Agile in der Softwareentwicklung begann, gelten diese Werte fast überall dort, wo Sie mit Sicherheit etwas Neues schaffen, sei es Marketing, Produktdesign, Bildung oder sogar Gesundheitswesen Wie sieht Agile also tatsächlich von Tag zu Tag aus? Im Kern ist es eine Schleife. Sie planen ein kleines Stück Arbeit, Sie erstellen es, überprüfen es mit den Beteiligten, Sie lernen aus dem Feedback und dann machen Sie alles noch einmal. Agile, dieser kurze Zyklus wird oft als Sprint bezeichnet und dauert in der Regel zwei Wochen. Zu Beginn wählen Sie eine kleine Gruppe von Elementen aus einer priorisierten Aufgabe aus , die als Backlog bezeichnet wird Dann erstellt das Team diese Aufgaben , zeigt die Ergebnisse an und überlegt dann, was gut gelaufen ist und was verbessert werden kann Und dann wiederholt sich der Zyklus. Agile ist eine Denkweise, aber um sie anzuwenden, werden Sie in den meisten Teams ein bestimmtes Framework verwenden Die beiden häufigsten, von denen Sie hören werden sind Scrum und Cam Ban Scrum verwendet diese festen zweiwöchigen Sprints mit definierten Produktrollen wie Product Owner und Sie veranstalten regelmäßig Zeremonien wie Planung, tägliche Stand-ups, Reviews und Cam Ban hingegen ist kontinuierlicher, die Arbeitsabläufe verlaufen über eine visuelle Tafel, und der Schwerpunkt liegt darauf, zu begrenzen, wie viel auf einmal in Bearbeitung ist Viele Teams werden eine echte Mischung aus beidem verwenden. Warum es wichtig ist. Warum ist Agile so dominant geworden? Es gibt drei Gründe. Erstens reduziert es das Risiko weil Probleme früh auftauchen, nicht erst am Ende. Zweitens sorgt es dafür, dass sich die Teams mit den Kunden abstimmen, weil Sie sich ständig mit ihnen in Verbindung setzen, anstatt zu raten Und drittens respektiert es die Menschen indem es kleinen Teams vertraut, ihre Arbeit selbst zu organisieren Perfekt für Telearbeit. Zusammenfassend lässt sich sagen, dass Agile eine Denkweise ist, bei Arbeit in kurzen , auf Feedback basierenden Es stammt aus dem Agile-Manifest von 2001, priorisiert Menschen, Arbeitsleistung, Zusammenarbeit und Anpassungsfähigkeit und nimmt in der Praxis normalerweise die Form von Scrum, nimmt in der Praxis normalerweise die Form von Scrum, Cam Ban Was ich Ihnen mit Agile überlasse, betrifft also nicht wirklich Sprints oder Stand-ups oder Haftnotizen an Sprints oder Stand-ups oder einer Wand. Sie sind nur die Tools Im Kern ist Agile eine Möglichkeit, etwas Ehrliches zuzugeben Wir wissen die Antwort nicht immer im Voraus, und das Klügste, was wir tun können, ist, ein bisschen zu bauen, ein bisschen lernen und immer besser Egal, ob Sie später Softwareteams leiten , Marketingkampagnen durchführen oder Lernprogramme koordinieren, oder Lernprogramme koordinieren, diese agile Denkweise wird Ihnen gute Dienste leisten Vielen Dank fürs Zuschauen und viel Glück auf Ihrem Weg zum Projektmanagement 3. Für wen dieser Kurs ist und was Sie aufbauen werden?: Hallo und willkommen zurück. Im letzten Video haben wir uns das Gesamtbild dessen angesehen, was Agile ist, und wir haben es mit dem traditionellen Wasserfall-Projektmanagementstil verglichen . In diesem Video möchte ich zwei Dinge tun. Zunächst möchte ich Ihnen helfen, zu überprüfen, ob dies der richtige Kurs für Sie ist. Und zweitens möchte ich dir zeigen, womit du am Ende davonkommen wirst. Dies ist keiner dieser Kurse, in denen Sie sich einfach eine Menge Theorie ansehen und sich dann fragen, was Sie damit anfangen sollen. Am Ende dieses Kurses wirst du etwas Reales aufgebaut haben. dieser Kurs für dich? Es gibt vier Arten von Menschen, für die dieser Kurs konzipiert wurde. Zuallererst wurde er für absolute Anfänger gebaut. Wenn Sie das Wort Agile bei der Arbeit oder in Stellenanzeigen gehört haben und sich nicht ganz sicher sind, was es bedeutet, sind Sie hier genau richtig. Sie benötigen keine Vorkenntnisse, um an diesem Kurs teilzunehmen. Zweitens wurde dieser Kurs für Personen konzipiert, die in das Projektmanagement oder in eine Produktrolle wechseln. Vielleicht wurden Sie befördert oder Sie versuchen, in diesem Bereich Fuß zu fassen. Agile ist die Sprache meisten modernen Teams sprechen, also werden Sie sie brauchen, und Wortschatz ist im Projektmanagement tatsächlich von großer Bedeutung. Es zeigt, dass Sie sich des Konzepts zumindest bewusst sind. Der dritte Personentyp besteht aus Personen, die Projekte bereits auf herkömmliche Weise verwalten Projekte bereits auf herkömmliche Weise vermuten , dass es einen besseren Weg gibt. Es gibt sie, und Sie werden hier mehr darüber erfahren. Und die vierte Art von Menschen sind Leute, die überhaupt nicht mit Software arbeiten . Im Marketing, bei Veranstaltungen, im Bildungswesen, im Gesundheitswesen und bei Kleinunternehmern gilt Agile also für fast alles, wo man etwas Neues kreiert und nicht alle Antworten im Voraus hat Also, wenn Sie das sind, ist dies der richtige Kurs. Eine kurze Anmerkung dazu, für wen dieser Kurs nicht gedacht ist. Wenn Sie bereits ein zertifizierter Scrum Master mit langjähriger Erfahrung sind , wird sich dieser Kurs recht einfach anfühlen Das ist okay. Die Kurse für Fortgeschrittene und Fortgeschrittene in dieser Reihe gehen viel tiefer. Stellen Sie also sicher, dass Sie dort beginnen, wo Sie tatsächlich sind. Schauen wir uns also an, was Sie bauen. Sie haben drei Artefakte, die ein echtes Portfolio wert sind, nicht nur Notizen aus einem Kurs. Also, was wirst du tatsächlich bauen? Dieser Kurs ist von Anfang bis Ende projektbasiert. Im nächsten Video wählen Sie eine Projektbeschreibung aus. Sie haben drei zur Auswahl. Und dann wirst du alles, was du lernst, auf dieses Projekt anwenden. Am Ende des Kurses werden Sie drei Dinge haben, die wirklich portfoliowürdig sind Das Erste, was Sie haben werden, ist ein vollständig gefüllter Produkt-Backlog Das ist die priorisierte Liste von Aufgaben , mit der jedes echte Agile-Team beginnen muss Zweitens haben Sie ein Sprint-Board, das einen vollständigen Sprintzyklus zeigt das einen vollständigen Sprintzyklus Sie tatsächlich ausgeführt haben, und drittens haben Sie ein schriftliches Dokument mit Rückblick auf den Sprint, haben Sie ein schriftliches Dokument mit Rückblick auf den Sprint in dem Sie darüber nachdenken, was gut gelaufen ist und was Sie beim nächsten Mal ändern würden Dies sind dieselben Artefakte jedes funktionierende Produktteam alle zwei Wochen produziert Und Sie können diese Dinge in ein Portfolio aufnehmen. Sie könnten sie in einem Vorstellungsgespräch zeigen und sie als Vorlagen für Ihr nächstes echtes Projekt verwenden . Sie gehören dir. Schauen wir uns also an, was Sie benötigen werden. Dies sind alles kostenlose Tools. Es sind keine kostenpflichtigen Pläne erforderlich. Es gibt keine Prüfungen. Es gibt keine Probleme mit der Anmeldung. Die beiden kostenlosen Tools, die wir verwenden werden, sind Trello und NS beide haben kostenlose Stufen Wir werden dich niemals bitten, für etwas zu bezahlen oder dich für eine Testversion anzumelden Und als Drittes benötigen Sie Stift und Papier. Manchmal ist also die technisch schlechteste Option die beste Möglichkeit zum Nachdenken. Wählen Sie als Nächstes Ihr Projekt aus. Sie haben die Wahl zwischen drei Slips. Sie werden eine Wahl haben, und dann werden wir bauen. Wählen Sie also diejenige aus, die Ihrer Meinung nach am besten zu Ihnen passt. Denken Sie nicht zu viel über die Wahl nach. Im nächsten Video helfe ich Ihnen bei Ihres Briefings. Also werde ich dich dort sehen. 4. Wählen Sie Ihre Projektbeschreibung: EdTech, E-Commerce oder Veranstaltungen: Willkommen zurück. Jetzt zum spaßigen Teil. In diesem Video wählst du das Projekt aus, an dem du für den Rest dieses Kurses arbeiten wirst. Ich habe drei verschiedene Slips für Sie vorbereitet. Sie decken bewusst sehr unterschiedliche Branchen ab, hauptsächlich um zu zeigen, dass Agile nicht nur für Softwareprojekte Sie werden gleich sehen, was ich meine. Machen Sie sich also keine Sorgen über diese Wahl. Wählen Sie die, die Sie am meisten begeistert oder die, die Ihrem eigentlichen Job am nächsten kommt Hier gibt es keine richtige oder falsche Antwort. Jeder dieser Slips wird Ihnen für diesen Kurs gute Dienste leisten. Also kurz A ist Bildungstechnologie von Edtech zur Entwicklung einer Funktion für eine Sprachlern-App für Kinder Stellen Sie sich also vor, Sie sind der Produktmanager oder der Projektmanager eines kleinen Edtech-Startups Ihr Team entwickelt eine App zum Sprachenlernen für Kinder, und die erste Version ist live, aber nach der zweiten Woche nimmt das Engagement ab Ihre Aufgabe ist es, einen Sprint zu planen und durchzuführen, der eine neue Funktion bereitstellt , die Kinder zurückbringen soll. Vielleicht ist das ein Streak-System oder ein neuer Spielmodus oder einige Belohnungen Das liegt an dir. Wählen Sie also dieses aus , wenn Sie Konsumgüter oder Apps mögen. Sie befinden sich in oder in der Nähe von Bildungseinrichtungen und möchten über die Motivation und das Engagement der Nutzer nachdenken . Auftrag B ist E-Commerce , um eine neue Produktlinie für einen nachhaltigen Einzelhändler auf den Markt zu bringen. In diesem Fall arbeiten Sie also mit einem kleinen Online-Händler zusammen, der nachhaltige Haushaltswaren verkauft. Sie wollen pünktlich zur Weihnachtseinkaufssaison eine neue Produktlinie auf den Markt bringen, zum Beispiel umweltfreundliche Küche eine umweltfreundliche Küche. Bei diesem haben Sie jetzt viele bewegliche Teile. Wir haben Fotos, wir haben Produktbeschreibungen, wir haben Preise, Lieferantenverhandlungen, Marketing, sogar die Website. Ihre Aufgabe ist es also, einen Sprint zu planen und durchzuführen , der den Start vorbereitet. Ich würde mich für diesen entscheiden, wenn Sie sich für Business Non-Operations interessieren oder wenn Sie sich für Marketing oder Unternehmertum im Allgemeinen oder wenn Sie ein Briefing mit vielen funktionsübergreifenden und beweglichen Teilen wünschen . Wenn C ein Branchenevent ist. Organisieren Sie also eine zweitägige Hybridkonferenz. Hybridkonferenz bedeutet, dass Personen persönlich und online teilnehmen. Bei diesem Projekt gibt es also einen Ort, an dem Sie buchen können. Es gibt Redner, die eingeladen werden müssen. Es gibt Sponsoren, denen man nachjagen kann. Wir müssen eine Website erstellen. Sie müssen die Technik einrichten und eine Marketingkampagne durchführen. Die Veranstaltung ist in drei Monaten, und Ihre Aufgabe ist es, einen Sprint zu planen und durchzuführen , der das Projekt voranbringt. Ich würde diesen speziell wählen wenn Sie nicht in der Technik arbeiten. Events ist der Auftrag, der beweist, dass Agile auch außerhalb von Software funktioniert. Wenn Sie im Marketing, in der Personalabteilung oder in einem anderen Bereich tätig sind, der nicht im IT-Bereich tätig ist, ist dieser Bereich wahrscheinlich am besten für Sie geeignet. Also, wie soll man wählen. Dies sind die drei Fragen, wenn Sie nicht weiterkommen. Erstens, welche Branche kommt Ihrem eigentlichen Job am nächsten? Wenn Ihr Tagesjob im Einzelhandel ist, wählen Sie E-Commerce. Wenn es nicht um Technik geht, wählen Sie Veranstaltungen aus. Je näher das Briefing Ihrer Realität oder dem entspricht , was Sie tun möchten, desto mehr werden Sie aus diesem Kurs herausholen. Zweitens, welcher begeistert dich am aufrichtigsten? Du wirst mindestens 3 Stunden damit verbringen, also such dir die aus, die dir gefallen Und Nummer drei, wenn Sie immer noch nicht weiterkommen, wählen Sie Ereignisse aus. Es ist für Anfänger am zugänglichsten und wahrscheinlich das beste, das alle Vorteile des agilen Projektmanagements zur Geltung bringt. Halten Sie also das Video an, wählen Sie einen Brief aus und schreiben Sie ihn auf. Im nächsten Video gehen wir auf das Agile Manifest selbst ein, die vier Werte und 12 Prinzipien, die allem anderen zugrunde liegen. Ich werde dich dort sehen 5. Das Agile Manifest: Vier Werte, zwölf Prinzipien: Willkommen zurück. Im Einführungsvideo habe ich das Agile Manifesto erwähnt, das Dokument, das 17 Entwickler auf der Skihütte in Utah geschrieben haben, falls Sie sich daran erinnern In diesem Video werden wir untersuchen, was darin tatsächlich steht Wir werden uns die vier Werte und die 12 unterstützenden Prinzipien ansehen . Nun, das ist ein wichtiges Video. Dies ist der philosophische Kern von allem anderen im Kurs und in Bezug auf den Wortschatz. Vielleicht möchten Sie für dieses Video Ihren Stift und Ihr Papier herausnehmen . Also zuallererst, warum Manifest? Nun, es gab ein Problem , das gelöst werden musste. Und hier ist dein Kontext. In den späten 90ern scheiterten also Softwareprojekte, große und teure, hauptsächlich, weil die Teams Monate und Monate damit verbrachten, detaillierte Spezifikationen zu schreiben und dann noch mehr Monate damit zu verbringen , und dann noch mehr Monate erstellen, was in diesen Spezifikationen stand, nur um etwas zu liefern , das der Kunde nicht mehr wollte. Sie wollten es nicht , weil sich die Märkte verändert und die Anforderungen geändert hatten. Der Plan war also perfekt, aber das Ergebnis war nutzlos. Das war das Hauptproblem. Jetzt, im Februar 2001, trafen sich 17 Entwickler in einem Skigebiet in Utah Nun waren sie sich über die Methoden nicht einig, aber sie waren sich alle einig, dass es einen besseren Weg geben müsse Also haben sie am Wochenende ein sehr kurzes Dokument geschrieben, das überraschenderweise nur 68 Wörter lang ist. Schauen wir es uns also an. Nun, dieses Dokument besteht hauptsächlich aus den vier Werten, und wir schätzen die Elemente auf der linken Seite mehr als die Elemente auf der rechten Seite. In dem Manifest heißt es: Wir entdecken bessere Möglichkeiten, Software zu entwickeln, indem wir es tun und anderen helfen, es zu tun Durch diese Arbeit haben wir einen Mehrwert gewonnen, und dann haben wir die vier Aussagen also Wert auf eins: Einzelpersonen und Interaktionen gegenüber Prozessen und Tools. Das bedeutet, dass ein großartiges Team mit mittelmäßigen Tools ein mittelmäßiges Team mit großartigen Tools übertreffen wird ein mittelmäßiges Miteinander zu sprechen ist also sehr wichtig. Verstecken Sie sich nicht hinter der Software. Wert zwei: funktionierende Software statt umfassender Dokumentation. Das bedeutet also, dass 100 Seiten mit schönen Spezifikationen, die niemand liest, viel weniger wert sind als ein kleiner funktionierender Prototyp , den die Leute tatsächlich benutzen und ausprobieren können. Also baue so schnell wie möglich etwas Echtes. Dritter Wert: Zusammenarbeit mit Kunden statt Vertragsverhandlungen. Das bedeutet, dass Sie Ihre Energie nicht damit verschwenden darüber zu streiten, was genau im ursprünglichen Briefing vereinbart wurde Arbeiten Sie mit Ihren Kunden zusammen, arbeiten Sie mit ihnen zusammen, finden Sie heraus, was tatsächlich benötigt wird Und der vierte Wert besteht darin, auf Veränderungen zu reagieren , anstatt einem Plan zu folgen. Das bedeutet nun, dass ein Plan nicht wie eine Hypothese ist. Das ist kein Vertrag. Wenn die Realität dem Plan widerspricht, ändere den Plan Und hier ist der Teil , den die Leute vermissen. Manifest endet damit, dass die Dinge auf der rechten Seite zwar einen Wert haben, aber wir schätzen die Dinge auf der linken Seite mehr Also diese traditionellen Dinge wie Prozesse und Dokumentation, Verträge und Pläne, sie sind alle immer noch wichtig Sie sind keine schlechte Sache, aber sie haben keine Priorität, wenn es hart auf hart kommt Schauen wir uns also die 12 Prinzipien an. die Gruppierung der Prinzipien werden sie nun Durch die Gruppierung der Prinzipien werden sie nun etwas einprägsamer Ich werde also nicht alle 12 Prinzipien nacheinander lesen 12 Prinzipien nacheinander Das wäre ziemlich mühsam. Außerdem können Sie sie in ein paar Minuten einfach selbst lesen sie in ein paar Minuten einfach selbst Denken Sie daran, es ist nur 68 Wörter lang. Anstatt also eins bis zwölf durchzugehen, werde ich sie in vier verschiedene Themen gruppieren. Nun, das erste Thema, bietet früh und häufig einen Mehrwert. Das erste Prinzip besagt, den Kunden durch frühzeitige und kontinuierliche Lieferung zufrieden zu stellen. Und der dritte Wert besagt, dass funktionierende Software häufig geliefert werden muss, eher Wochen als Monate. Übersetzung, was das eigentlich bedeutet, etwas Reales Benutzern so schnell wie möglich etwas Reales präsentieren und dann weitermachen. Das zweite Thema, willkommene Abwechslung. Das zweite Prinzip der 12 besagt wörtlich, dass sich ändernde Anforderungen, auch wenn sie sich erst spät in der Entwicklung befinden, willkommen geheißen werden. Nun, das klingt verrückt, wenn Sie aus dem traditionellen Wasserfall-Projektmanagement kommen . Aber die agile Wette ist , dass Veränderungen sowieso passieren werden , also können Sie genauso gut darauf bauen. Das dritte Thema lautet: Die Menschen stehen an erster Stelle. In diesem Thema lassen sich mehrere Prinzipien zusammenfassen. Sie bauen Projekte rund um motivierte Personen auf und vertrauen darauf, dass sie die Arbeit erledigen. Persönliche Gespräche sind die effizienteste Art, Informationen auszutauschen, und die besten Architekten und Designer entstehen aus sich selbst organisierenden Teams. Wenn Sie ein Muster feststellen, vertraut Agile den Personen, die an den Projekten arbeiten Das vierte Thema ist Nachhaltigkeit und Reflexion, zwei Prinzipien, die ich liebe Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Nutzer sollten in der Lage sein , auf unbestimmte Zeit ein konstantes Tempo aufrechtzuerhalten Mit anderen Worten, keine Todesmärsche. Und das letzte Prinzip: In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden Sie haben eine kontinuierliche Verbesserung eingebaut. Schauen wir uns also an, was das in der Praxis bedeutet und was das Manifest für Ihr Projekt bedeutet Was bedeutet es also, wenn Sie Ihr Projekt-Briefing erstellen? Es bedeutet, dem Versand von etwas Kleinem Vorrang vor der Planung von etwas Perfektem Das heißt, wenn Ihr Stakeholder seine Meinung ändert, behandeln Sie das als nützliche Information und nicht als ein Problem, über das Sie sich Gedanken machen sollten. Bedeutet, dass Sie Ihrem Team vertrauen, häufig darüber nachdenken, was Sie getan haben, und sich ständig verbessern Also, nichts davon ist Hexenwerk. Es ist hauptsächlich der gesunde Menschenverstand , den diese großen Organisationen vergessen haben , die sehr festgefahren sind. Die Aufgabe des Manifests ist es, uns daran zu erinnern. Im nächsten Video werden wir uns mit den Missverständnissen des agilen Projektmanagements befassen , denn wissen Sie, da es so weit verbreitet ist, tauchen diese Es ist überraschend, wie viele Dokumente mit 68 Wörtern missverstanden werden können. Im nächsten Video werden wir uns also mit den entlarvten Mythen von Agile befassen . Wir sehen uns dort 6. Agile Mythen und Missverständnisse: Willkommen zurück. Wenn du dich nur an eine Sache aus diesem Video erinnerst, mach es zu dieser. Das meiste, was die Leute Agile nennen, ist es nicht. Nun gibt es eine große Kluft zwischen dem, was das Manifest sagt, und dem, was Teams tatsächlich tun Schauen wir uns also die Missverständnisse an und entlarven wir die Mythen. Mythos Nummer eins: Agile bedeutet keine Planung. Dieser macht mich verrückt, weshalb er die Nummer eins ist. Das Manifest besagt, auf Veränderungen zu reagieren , statt einem Plan zu folgen, nicht niemals einem Plan zu folgen Agile Teams planen ständig. Sie planen einfach häufiger in kleineren Teilen und sind bereit, diese Pläne zu ändern, wenn sie lernen Wenn Ihnen jemand sagt, dass wir nicht planen, sind wir agil, sie sind nicht Sie sind einfach unorganisiert. Also Vorsicht Mythos Nummer zwei: Agile bedeutet keine Dokumentation. Auch hier treibt es mich in den Wahnsinn. Das Manifest besagt, dass funktionierende Software besser ist als umfassende Dokumentation, das heißt nicht, dass es keine Dokumentation Das heißt, schreibe keine 200 Seiten, die niemand liest. Schreiben von Dokumentation hilft tatsächlich dabei, eine klare Benutzergeschichte, ein einfaches Entscheidungsprotokoll, ein einseitiges Architekturdiagramm all das ist willkommen. Mythos Nummer drei: Agile ist einfach Scrum. Nein. Scrum ist ein agiles Framework Es gibt andere Frameworks, darunter Caban, Extreme Programming, Lean und Scrumban, das Hybrid Agile ist die Denkweise, die Werte und die Prinzipien, die wir gerade behandelt haben, und Scrum ist eine spezifische Methode Wenn also jemand sagt: Machen Sie Agile, ist die ehrlichste Antwort normalerweise, dass wir Scrum machen, was eine Variante von Agile ist Wir werden uns im zweiten Kurs eingehender damit befassen. M Nummer vier, Agile ist nur für Software. Das Manifest wurde von Entwicklern geschrieben, aber die Prinzipien und Werte sind universal Marketingteams verwenden Agile, Krankenhäuser verwenden Agile, Schulen verwenden Agile Sogar Bauunternehmen nutzen es. Wenn Sie also etwas Neues schaffen und Unsicherheit besteht und Sie viele Stakeholder haben, dann gilt Agile, und das ist sehr effektiv. Aus diesem Grund handelt es sich bei einer Ihrer Projektbeschreibungen diesem Kurs um ein Veranstaltungsprojekt und nicht um ein Softwareprojekt Meine Nummer fünf, Agile bedeutet schneller. Das ist wahrscheinlich der schädlichste Mythos , denn so werden Führungskräfte von Agile-Projekten überzeugt. Dadurch können wir schneller versenden. Ich meine, manchmal schon, aber der wahre Vorteil von Agile ist nicht die Geschwindigkeit. Es ist die Anpassungsfähigkeit. Sie konzentrieren sich auf die Dinge, die am wichtigsten sind, weil Sie im Laufe des Projekts gelernt haben, was diese Dinge sind Aus diesem Grund könnten Sie insgesamt weniger Arbeit verrichten. Geschwindigkeit ist also ein Nebeneffekt. Nicht das Ziel. Jetzt, im nächsten Video, werden wir das Agile-Verhalten erkennen. Sie werden die Möglichkeit haben, dies selbst zu testen. Wir werden eine schnelle, praktische Übung machen. Ich zeige Ihnen einige Szenarien, und Sie entscheiden, welche tatsächlich agil sind und welche nur so verkleidet sind , dass sie aus einer oberflächlichen Perspektive agil aussehen . Also sehe ich dich dann 7. Übungsübung: Erkennen Sie agiles Verhalten im Vergleich zu nicht-agiles Verhalten: Willkommen zurück. Jetzt kommen wir zu unserer ersten Übungsübung, ob agil oder nicht. Ich möchte, dass du das agile Verhalten erkennst. Ich gebe Ihnen fünf kurze Szenarien. Halten Sie für jedes Video an und entscheiden Sie, ob agiles Verhalten handelt oder nicht. Und dann gebe ich dir die Antwort. Also zuerst, Szenario eins, ein Team schreibt ein detailliertes 80-seitiges Spezifikationsdokument bevor eine einzige Codezeile geschrieben wird. jetzt eine Pause, wenn Sie möchten. Ist das agil oder nicht agil? Das ist nicht Agile. Das ist also klassisches Wasserfall-Denken , umfangreiche Planung im Voraus und dann bauen Sie, was der Agile-Methodik widerspricht Szenario zwei Ein Team veröffentlicht alle zwei Wochen ein kleines Feature, erhält Feedback von echten Benutzern und entscheidet anhand dessen, was als Nächstes erstellt werden soll hier eine Pause, wenn Sie möchten. Ist das agil oder nicht agil? Das ist Agile. Wir haben kurze Zyklen. Wir haben echtes Benutzerfeedback und Entscheidungen, die auf den Erkenntnissen basieren die während dieses Pilotprojekts gewonnen wurden, so könnte man es nennen. Okay, Szenario drei. Der Kunde bittet nach der Hälfte des Projekts um eine Änderung Das Team antwortet: Entschuldigung, das steht nicht im ursprünglichen Briefing hier eine Pause, wenn Sie möchten. Ist das agil oder nicht agil? Das ist nicht Agile. Denken Sie also daran, dass wir den dritten Wert der Zusammenarbeit mit Kunden gegenüber Vertragsverhandlungen haben. Begrüßen Sie die Veränderung. Kämpfe nicht dagegen an. Nun, Szenario vier: Das Team hat ein 15-minütiges Meeting jeden Morgen ein 15-minütiges Meeting, in dem jede Person über Fortschritte, Pläne und etwaige Hindernisse spricht. Sie sprechen auch darüber, was sie gestern getan haben, was sie heute tun, Dinge wie diese Ist das agil oder nicht? Das ist Agile. Das ist das klassische tägliche Stand-up, das Prinzip sechs unterstützt. Gespräch von Angesicht zu Angesicht ist die effizienteste Art , Informationen auszutauschen. Und Szenario fünf: Ein Team hält jeden Freitag ein Treffen ab, um zu besprechen, was gut gelaufen ist, was nicht und was als Nächstes versucht werden soll. Machen Sie hier eine Pause. Ist das agil oder nicht agil? Das ist Agile. Dies wird als Retrospektive Dies ist Principal 12, dem das Team bei regelmäßigen Interviews darüber nachdenkt, wie es effektiver werden Also schauen sie sich die Dinge an, die gut gelaufen sind, die Dinge, die gescheitert sind. Also bewerte dich selbst. Wie viele hast du bekommen? Mach dir keine Sorgen, wenn du ein paar verpasst hast. Diese Konzepte und Werte werden sich im Laufe der Zeit durchsetzen. Aber das ist das Ende von Abschnitt eins. 8. Die Bausteine: Sprints, Inkrementelle Und Die Empirische Schleife: In diesem Abschnitt werden wir uns mit dem Maschinenraum von Agile befassen. Im letzten Abschnitt haben wir über die Denkweise gesprochen, und in diesem werden wir über die Mechanik sprechen Am Ende dieses Videos werden Sie wissen, was ein Sprint ist, was ein Inkrement ist, und Sie werden auch die einfache dreistufige Schleife kennen, die Agile-Teams verwenden , um Mehrwert zu schaffen Lassen Sie uns also darauf eingehen. Was ist ein Sprint? Ein Sprint ist ein Arbeitscontainer mit fester Länge. Es ist ein fester Zeitraum, in dem ein Team daran arbeitet, einen kleinen, vereinbarten Arbeitsaufwand zu erledigen. Die Länge ist konsistent. Normalerweise sind es eine, zwei, drei oder vier Wochen. Zwei Wochen sind bei weitem am häufigsten. Und das Schlüsselwort dort ist behoben. Ein Sprint beginnt immer am selben Tag und endet am selben Tag. Sie verlängern ihn nicht, weil die Arbeit nicht erledigt ist, und Sie verkürzen ihn nicht, weil jemand im Urlaub ist. Die Zeitbox ist heilig. Warum ist das wichtig? Weil Vorhersehbarkeit eines der Dinge ist , die Aja dir bietet Nach ein paar Sprints beginnen Sie zu lernen, was Ihr Team realistischerweise in zwei Wochen schaffen kann, und diese Informationen sind Gold für die Planung Sie verlängern es also nicht, Sie verkürzen es nicht. Diese Zeitbox ist festgelegt. Was ist als Nächstes ein Inkrement Das ist es, was Sie am Ende jedes Sprints produzieren. Es ist ein kleiner, aber vollständiger Wert, der veröffentlicht oder verwendet werden könnte, etwas Reales. Der entscheidende Punkt dabei ist das Wort „funktionieren“. Es ist kein halbfertiges Feature. Es ist kein Wireframe. Es ist kein Stapel von Notizen oder Unterlagen Es ist ein kleines, aber vollständiges Werk, das von Wert her veröffentlicht oder verwendet werden könnte. Für Ihr Edtech-Projekt könnte ein Inkrement ein funktionierender Streakzähler sein , während es für E-Commerce eine fertige Produktseite sein könnte Für Veranstaltungen, eine bestätigte Buchung eines Veranstaltungsorts und ein veröffentlichtes Datum, Dinge So echt, fertig und brauchbar. Als Nächstes haben wir die empirische Schleife. Wir haben drei Wörter. Das ist der gesamte Motor von Agile. Dies ist wahrscheinlich das wichtigste Konzept in diesem Video. Es klingt schick, aber es nur drei einfache Schritte , die sich immer wieder wiederholen. Transparenz, Inspektion und Anpassung. Transparenz bedeutet, dass jeder sehen kann, was vor sich geht. Die Arbeit ist auf einer Tafel, in einem Backlog, irgendwo sichtbar , wo sie sich jeder ansehen kann Wir haben keine versteckten Fortschritte und keine Überraschungen. Inspektion bedeutet, dass wir uns regelmäßig ansehen , was wir produziert haben und wie wir arbeiten. Wir fahren nicht einfach voran, wir halten an und überprüfen. War es das, was der Kunde wollte? Sind wir auf dem richtigen Weg? Ist etwas blockiert? Und Anpassung bedeutet, dass wir uns auf der Grundlage dessen, was wir sehen, verändern. Wenn also etwas nicht funktioniert, ändern wir es. Wenn uns ein Interessent neue Informationen gibt , aktualisieren wir den Plan Wir machen nicht weiterhin das Falsche, nur weil es im ursprünglichen Plan enthalten war Wir müssen uns anpassen. Transparenz, Inspektion, Anpassung. Das ist der gesamte Motor von Agile. Schauen wir uns also an, wie es zusammenpasst. Sie haben Ihren Sprint inkrementiert und wiederholen den Vorgang. Das ist im Grunde das, was Agile ist. Du läufst einen Sprint. Nehmen wir an, es ist zwei Wochen lang. Während des Sprints machst du die Arbeit auf einem Board transparent. Am Ende des Sprints hast du ein funktionierendes Inkrement erstellt Dann inspizieren Sie. Du zeigst es den Leuten. Du fragst sie, was sie denken, du darüber nach, wie das Team zusammenarbeitet, und dann passt du dich an den nächsten Sprint an und du machst alles noch einmal. Das ist der grundlegende Rhythmus agilen Arbeitens. Sprint, Inkrement, Schleife, Sprint, Inkrement, Schleife. Oh. Als Nächstes haben wir die drei Rollen, die dafür sorgen, dass es funktioniert den Product Owner, den Scrum Master und das Entwicklungsteam. Wir sehen uns beim nächsten Mal 9. Rollen: Product Owner, Scrum Master, Entwicklungsteam: Willkommen zurück. In dieser Lektion werden wir uns die drei Rollen ansehen , die Agile-Teams zum Funktionieren bringen. Am Ende dieses Videos werden Sie wissen, wer was macht und warum es jede Rolle gibt. Wir konzentrieren uns hier auf das Scrum-Framework , weil es am gebräuchlichsten ist und die Rollendefinitionen klarsten sind. Fangen wir also an Zunächst haben wir den Product Owner, auch bekannt als PO. Das ist die Stimme des Kunden im Team. Ihre Aufgabe ist es, zu entscheiden was das Team baut und in welcher Reihenfolge. Ihnen gehört der Produkt-Backlog, also die Liste der Aufgaben, die nach Prioritäten geordnet sind, und sie sind die Person, die sagt: Das ist das Wichtigste . Tun Sie das als Nächstes Entscheidend ist, dass der PO nicht der Chef des Teams ist. Sie sagen dem Team nicht, wie die Arbeit zu erledigen ist. Sie sagen dem Team , was zu tun ist und warum es wichtig ist. Das Wie ist Sache des Teams. Ein guter Product Owner verbringt Zeit mit Kunden. Sie verstehen das Geschäft und treffen schwierige Entscheidungen über Prioritäten. Sie sagen oft nein , weil es immer mehr Nachfrage gibt , als sie aufnehmen können. Ihr Projektauftrag, vielleicht spielen Sie diese Rolle selbst, was völlig in Ordnung ist. Denken Sie einfach an die Denkweise des Product Owners, seien Sie sich über Prioritäten im Klaren, sprechen Sie mit Ihren Benutzern und gehen Sie Kompromisse Die nächste Rolle ist der Scrum Master, auch bekannt als SM Diese Rolle hilft dem Team, gut zu arbeiten. Nun, das ist eine der am meisten missverstandenen Rollen in Agile Scrum Master ist nicht der Projektmanager. Sie weisen keine Aufgaben zu. Sie verfolgen nicht, wer was getan hat. Sie jagen Leuten nicht nach Updates oder Ergebnissen, und sie sind auch nicht der Boss Was sie tatsächlich tun, ist, dem Team zu helfen, gut zu arbeiten. Sie erleichtern die Treffen. Sie beseitigen Hindernisse, Dinge, die das Team daran hindern, voranzukommen, und sie coachen das Team in agilen Praktiken Sie schützen das Team auch vor jeglichen Einflüssen von außen. Eine der besten Analogien hier ist, dass der Scrum Master wie ein Fußballtrainer ist . Sie spielen das Spiel nicht Sie sagen den Spielern nicht, wie sie den Ball kicken sollen, aber sie schaffen die Bedingungen, unter denen die Mannschaft ihre besten Leistungen erbringen kann. kleinen Teams übernimmt der Scrum Master oft eine andere Rolle, vielleicht den leitenden Entwickler Die gesamte Verantwortung wird geteilt, was völlig in Ordnung ist Solange die Arbeit erledigt wird, ist das eigentlich egal. Die nächste Rolle ist das Entwicklungsteam. Das sind die Leute, die das Produkt tatsächlich bauen. Trotz des Namens sind dies nicht nur Softwareentwickler oder Programmierer Das Entwicklungsteam besteht allen, die das Produkt tatsächlich Software, das wären Entwickler, aber auch Designer und Tester Für ein Marketingprojekt wären es Texter, Designer, Bei einer Veranstaltung sind es die Betriebsmitarbeiter, die Rednerkoordinatoren, der Veranstaltungsleiter, zwei wichtige Dinge des Zum einen organisieren sie sich selbst. Niemand sagt ihnen , wie sie die Arbeit aufteilen sollen. Sie finden es selbst heraus. Und zweitens sind sie funktionsübergreifend. Das Team verfügt über alle Fähigkeiten, die es benötigt, um Fortschritte zu erzielen, ohne von Außenstehenden abhängig zu Die typische Größe besteht aus drei bis neun Personen, groß genug, dass Sie über alle erforderlichen Fähigkeiten verfügen , und klein genug, dass jeder weiß was vor sich geht und wer was tut Schauen wir uns also an, wie diese drei Rollen zusammenarbeiten. Wir haben drei Aufgaben und es gibt kaum Überschneidungen. Der Product Owner entscheidet, was gebaut werden soll. Das Entwicklungsteam entscheidet, wie es erstellt wird, und der Scrum Master stellt sicher , dass der Prozess reibungslos abläuft Diese drei Rollen und Verantwortlichkeiten überschneiden sich kaum Und diese Klarheit ist einer der Gründe, warum Scrum funktioniert. Jeder weiß, wessen Entscheidung wessen ist. Wenn ein Stakeholder eine neue Funktion wünscht, spricht er mit dem Product Owner Wenn ein Entwickler blockiert ist, hilft der Scrum Master dabei, ihn zu entsperren. Das Team muss sich für einen technischen Ansatz entscheiden, es entscheidet selbst Im wirklichen Leben, insbesondere in kleinen Teams, könnte eine Person zwei Rollen übernehmen. Sie könnten der Product Owner und ein Scrum Master sein. Oder, wie ich bereits sagte, der leitende Entwickler könnte auch der Scrum Master sein, was völlig normal ist Bei den Rollen geht es um Verantwortlichkeiten und nicht speziell um Berufsbezeichnungen Vielen Dank, dass Sie sich mir bei dieser Lektion angeschlossen haben. Als Nächstes werden wir uns den Produkt-Backlog ansehen. Wir werden uns ansehen, was darin enthalten ist, wie es strukturiert ist und wie man ein gutes baut. Wir sehen uns im nächsten. 10. Der Produkt-Backlog im Überblick: Willkommen zurück. In dieser Lektion werden wir uns mit dem Produkt-Backlog befassen Dies ist wahrscheinlich das wichtigste Artefakt bei der agilen Arbeit Und wenn Sie es einmal verstanden haben, werden sich viele andere Dinge zusammenfügen. Am Ende dieses Videos werden Sie also wissen, was ein Backlog ist, was darin enthalten ist und was einen guten Backlog ausmacht Was ist also ein Produkt-Backlog? Schauen wir uns eine einfache Definition mit drei Schlüsselwörtern an. Beim Produkt-Backlog handelt es sich um eine einzelne, nach Prioritäten geordnete Liste aller Arbeiten , die möglicherweise an einem Projekt oder einem Produkt ausgeführt werden an einem Projekt oder einem Nun, in dieser Definition gibt es drei Schlüsselwörter . Der erste ist Single. Es gibt nur einen Rückstand. Es gibt keinen pro Teammitglied. Es gibt keinen pro Stakeholder. Wir haben einen Rückstand. Das nächste Schlüsselwort hat Priorität. Die Punkte ganz oben auf der Liste sind die wichtigsten. Und der dritte ist bestellt. Es gibt kein Unentschieden. Wenn zwei Artikel gleich wichtig sind, wählt der Product Owner einen aus , der eine höhere Priorität hat als der andere. Stellen Sie sich das wie eine Wunschliste mit einer Bestellung vor. Alles, was jemand möchte, dass das Team tut, steht irgendwann auf dieser Liste, und die Reihenfolge sagt dem Team, woran es als Nächstes arbeiten soll. Was gehört also in einen Backlog? Im Allgemeinen haben wir drei Arten von Elementen in einem Backlog. Sie gehören alle auf dieselbe Liste. Die ersten sind Funktionen. Das sind also neue Dinge , die Sie bauen möchten. Fügen Sie also zum Beispiel einen Streak Counter hinzu, erstellen Sie eine Checkout-Seite oder buchen Sie den Veranstaltungsort Der zweite Punkt wären Korrekturen. Das sind also Dinge, die kaputt sind oder verbessert werden müssen. Beispielsweise funktioniert die Anmeldeschaltfläche auf Android-Geräten nicht. Die Produktfotos sind zu dunkel. Die dritte sind Hausarbeiten. Das sind also technische Gegenstände. sind Dinge, die das Team tun muss und die zwar nicht direkt zu einem Feature führen , aber notwendig sind. Richten Sie also zum Beispiel das Analysetool ein, verlängern Sie den Domainnamen, alle drei leben im gleichen Backlog, priorisieren Sie gemeinsam, was wichtig ist Sie sind also gezwungen, eine neue Funktion gegen eine kritische Lösung gegen eine technische Schuld abzuwägen eine kritische Lösung gegen eine technische Es gibt keine separaten Listen, in denen die Kompromisse versteckt sind. Sie priorisieren sie alle in derselben Liste. Was also einen guten Produkt-Backlog ausmacht, sollten Sie sich das Akronym genau merken Nun, nicht jedes Element in einem Backlog ist gleich gut definiert. Hier haben wir also ein nützliches Akronym dafür, was ein guter Backlog sein sollte Also, TIEF oder tief. D steht für angemessen detailliert. Punkte ganz oben im Backlog, an denen bald gearbeitet wird , sollten viele Details Artikel im unteren Bereich können vage sein. Verschwenden Sie also nicht Ihre Zeit etwas zu perfektionieren, das vielleicht nie fertig E steht für geschätzt. Für jeden Artikel sollte eine Größenschätzung vorliegen. Es müssen keine Stunden oder Tage sein. Wir werden später über die Storypoints sprechen, aber das Team sollte eine ungefähre Vorstellung davon haben , wie groß jeder Gegenstand ist. Das nächste E steht für Emergent. Das Backlog ist nie fertig. Es werden ständig neue Artikel hinzugefügt . Alte Artikel werden geändert oder gelöscht. Nun, das ist gesund. Das ist kein Zeichen von Misserfolg. Und schließlich hat P Priorität. Es gibt eine klare Reihenfolge. Top-Artikel haben höchste Priorität. Der Product Owner ist dafür verantwortlich, diesen aktuellen Fluss aufrechtzuerhalten. Um Ihren Backlog aufzubauen. Wir haben drei Schritte Das dauert, ja, ein oder zwei Stunden Arbeit, abhängig von der Größe des Projekts. Der erste der drei Schritte ist also Brainstorming. Holen Sie sich alles aus Ihrem Kopf und fügen Sie eine Liste zusammen. Machen Sie sich noch keine Gedanken über eine Bestellung. Mach dir keine Sorgen über die Größe. Wirf einfach alles auf deine Seite. Jede Funktion, jede Lösung, jede Aufgabe. Strebe mindestens 20 Gegenstände an. Zweiter Schritt: Clustern und Aufräumen. Schau dir deine Liste an. Bei einigen Artikeln kann es sich um Duplikate handeln. Artikel werden also zu groß sein, um sie in einem Sprint zu erledigen , und müssen auseinandergenommen werden. Einige werden zu klein sein und können mit anderen Aufgaben kombiniert werden. Der dritte Schritt ist die Priorisierung. Stellen Sie den wichtigsten Gegenstand ganz oben auf. Am wichtigsten bedeutet , welches Produkt dem Benutzer am schnellsten und mit dem geringsten Aufwand den meisten Wert bietet dem Benutzer am schnellsten und mit dem geringsten Aufwand den meisten Wert , und dann dasselbe für den nächsten und den nächsten Artikel zu tun Und am Ende hätten Sie einen geordneten Auftragsbestand. Diese ganze Übung sollte eine Stunde dauern, vielleicht zwei. Wir werden es im nächsten Abschnitt wirklich machen. Als Nächstes haben wir also User Stories, das ist das Format für jedes Element in Ihrem Backlog Danke, dass du mich bei dieser Lektion unterstützt hast. Wir sehen uns in der nächsten. 11. User Stories: Schreiben im "Als ... möchte ich ... , damit ... " Format: Willkommen zurück. In dieser Lektion lernen wir die nützlichste Vorlage in Agile kennen, die User Story. Am Ende dieses Videos werden Sie also in der Lage sein, eine User Story für jedes Element in Ihrem Backlog zu schreiben , und Sie werden wissen, was eine gute und was eine schlechte User Story ausmacht Also absolut wichtiger Aspekt von Agile-Projekten. Das klassische Template, fangen wir damit an, was eine User Story nicht ist. Eine User Story ist keine detaillierte Spezifikation. Es ist kein Vertrag oder eine Liste von Anforderungen. Eine User Story ist eine kurze Aussage , die aufzeigt, was ein Benutzer will und warum. Die klassische Vorlage, die Sie überall sehen werden, sieht so aus. Als Benutzertyp möchte ich ein Ziel haben. Also das aus irgendeinem Grund. Es gibt drei Teile, wer, was und warum. Als Beispiel als wiederkehrender Lernender sehen, möchte ich als wiederkehrender Lernender sehen, wie viele Tage hintereinander ich geübt habe , damit ich motiviert bin, weiterzumachen Beachten Sie alle drei Punkte, den Benutzer, das Ziel und den Grund Warum funktioniert dieses Format also? Es gibt drei Gründe, warum sich die starre Struktur lohnt. Erstens zwingt es Sie, den Benutzer zu identifizieren. Heutzutage werden so viele Funktionen erstellt ohne dass jemand darüber nachdenkt, für wen sie gedacht sind. Erstellen Sie ein Dashboard, aber für wen für was, das User-Story-Format macht diese Frage unausweichlich Zweitens konzentriert es sich auf das Ziel, nicht auf die Lösung. Beachten Sie also, dass es in der Geschichte nicht heißt, fügen Sie ein Streak-Counter-Widget auf der Startseite Da steht: Schau, wie viele Tage hintereinander ich geübt habe. Dadurch steht es dem Team nun frei, die beste Lösung zu finden, um dieses Ziel zu erreichen. Vielleicht ist es ein Zähler, vielleicht ist es eine Kalenderansicht, vielleicht ist es eine Benachrichtigung. Die Geschichte diktiert es nicht. Und drittens zeigt es, warum dieser Teil oft am meisten übersprungen wird, aber er ist der wichtigste Ohne sie kann man nicht sagen, ob es sich überhaupt lohnt, die Geschichte zu spielen. Wenn du also keine überzeugende Geschichte schreiben kannst, sollte die Geschichte vielleicht gar nicht im Backlog sein Schauen wir uns also für jede Projektbeschreibung einige Beispiele an. In Edtech möchte ich als Elternteil wöchentliche Fortschrittsberichte über mein Kind sehen , damit ich weiß ob die App tatsächlich funktioniert Im E-Commerce kann es sich bei einer Benutzerstory um einen ersten Besucher handeln. Ich möchte, dass die Versandkosten klar bevor ich etwas in meinen Warenkorb lege, damit ich beim Checkout nicht überrascht werde Und bei Veranstaltungen könnte eine User-Story so aussehen, als ob ich als Sponsor eine klare Aufschlüsselung der einzelnen Sponsoring-Stufen haben möchte , damit ich entscheiden kann, für welche ich mich engagieren möchte Beachten Sie nun, dass es in jedem Fall einen echten Nutzer, ein klares Ziel und einen vernünftigen Grund für dieses Ziel Keiner von ihnen ist technisch. Keiner von ihnen schreibt eine Lösung vor, und das ist die beste Lösung. Nun, was macht eine schlechte Geschichte aus? Schauen wir uns die vier häufigsten Fehlerarten an. Erstens ist Misserfolg zu vage. Als Benutzer wünsche ich mir zum Beispiel eine bessere Benutzererfahrung , damit ich zufrieden bin Nun, das ist keine Geschichte. Das ist wie ein Wunsch. Was heißt besser überhaupt? Das ist völlig undurchführbar. Ein zweiter Fehler würde eine Lösung verbergen. Als Benutzer möchte ich eine rote Schaltfläche in der oberen rechten Ecke haben, damit ich darauf klicken kann. Nun, das ist keine Geschichte. Das ist nur eine Designspezifikation, die als solche verkleidet ist. Wir haben kein Ziel und keinen Grund ohne vorgeschriebene Lösung. Der dritte Fehler ist zu groß. Als Benutzer möchte ich ein vollständiges Kontoverwaltungssystem haben, damit ich mein Konto verwalten kann. Das ist keine Geschichte. Das ist wie ein ganzes Projekt. Eine gute Geschichte sollte klein genug sein , um sie in einem einzigen Sprint fertigzustellen, und wenn nicht, sollte sie aufgeschlüsselt werden. Beim vierten Misserfolg fehlt also der Grund. Also als Benutzer möchte ich mich anmelden. Warum? Ohne das kann man nicht beurteilen, ob es sich überhaupt lohnt, es zu tun. Es gibt also ein nützliches Akronym , das wir hier für eine gute Geschichte verwenden können : Invest INVEST. Unabhängig, verhandelbar, wertvoll, schätzbar. Klein und testbar. Unabhängig bedeutet, dass es nicht darauf ankommt zuerst eine andere Geschichte gedreht wird, wenn das überhaupt möglich ist Verhandelbar bedeutet, dass sich die Details ändern können, wenn wir mehr erfahren. Wertvoll bedeutet, dass es etwas bietet , das dem Benutzer wichtig Schätzbar bedeutet, dass das Team es ungefähr einschätzen kann. Klein bedeutet, dass es in einen Sprint passt, und testbar bedeutet, dass Sie erkennen können, wann es fertig ist Merken Sie sich das jetzt nicht. Schreiben Sie es vielleicht auf, aber denken Sie nur an das Akronym. Und wenn Sie bei einer User Story nicht weiterkommen, können Sie dieses Akronym durchgehen, um zu versuchen, es zu verbessern. Oh, danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Lektion werden wir die letzten Teile einer guten Benutzergeschichte hinzufügen , nämlich die Akzeptanzkriterien und die Definition von Erledigt. Das sind die Teile, die dir sagen , dass der Sprint tatsächlich beendet ist. Also werde ich dich im nächsten sehen. 12. Akzeptanzkriterien und Definition von "Fertig": Willkommen zurück. In dieser Lektion werden wir uns mit einer der kniffligsten Fragen in Agile befassen Woher wissen wir, wann etwas fertig ist? Es gibt zwei wichtige Instrumente, anhand derer wir das verstehen werden : die Akzeptanzkriterien und die Definition von „Erledigt“. Fangen wir also an. Also, was heißt fertig überhaupt? Wenn Sie sich darüber nicht einig sind, wird sich das Team in jedem Sprint streiten. Also hier ist eine Frage. Wann ist ein Feature fertig? Ist es, wenn der Code geschrieben wird? Ist es, wenn es getestet wurde? Ist es fertig, wenn es eingesetzt wurde? Ist es fertig, wenn der Benutzer es verwenden kann? Ist es fertig, wenn die Dokumentation aktualisiert wird? Wenn Sie sich in diesen Dingen nicht einig sind, werden Sie am Ende bei jedem Schritt auf Argumente stoßen. Jemand könnte sagen: Ja, das ist erledigt, und jemand anderes sagt, nein, es ist nicht getan. Die Tests wurden nicht durchgeführt. Diese Mehrdeutigkeit kann also das Momentum beeinträchtigen. Aus diesem Grund verwenden Agile-Teams zwei sich ergänzende Tools: Akzeptanzkriterien Die sind spezifisch für eine einzelne Geschichte und die Definition von Erledigt, die für alles gilt. Schauen wir uns also zunächst die Akzeptanzkriterien an. Dies sind kurze und spezifische Aussagen, die beschreiben können, was eine Geschichte leisten muss, um vom Product Owner akzeptiert zu werden. Sie gehen mit der User Story einher. Nehmen wir also die Streak-Counter-Story , die wir zuvor geschrieben haben Als wiederkehrender Lernender möchte ich also sehen, wie viele Tage hintereinander ich geübt habe , damit ich motiviert bin, weiterzumachen Akzeptanzkriterien hierfür könnten die Streak-Shows auf dem Startbildschirm sein Die Serie wird auf Null zurückgesetzt, wenn ein Tag verpasst wird. Die Serie zeigt die aktuelle Zahl an, keine Der Streak wird auf dem Telefon und dem Tablet korrekt angezeigt. Beachten Sie nun, dass diese spezifisch sind, testbar sind und mit dieser einzigen Benutzerstory verknüpft sind dieser einzigen Benutzerstory verknüpft Sie schreiben das Design nicht vor, aber sie sagen dir genau, was das fertige Ding leisten muss Eine gute Faustregel hier sind also drei bis fünf Akzeptanzkriterien pro Geschichte. Wenn Sie mehr als das haben, ist Ihre Geschichte wahrscheinlich zu groß. Schauen wir uns nun die Definition von Fertig an. Dies ist eine Checkliste , die für jede einzelne Arbeit gilt , die das Team produziert Es ist nicht nur eine Geschichte. Es ist für sie alle. Eine typische Definition von Erledigt könnte beinhalten, dass die Arbeit von Experten begutachtet wurde, die Arbeit getestet wurde. Die Arbeit wurde gegebenenfalls dokumentiert. Die Arbeit wurde an einem Ort veröffentlicht, an dem sie von den Benutzern eingesehen werden kann. Alle Akzeptanzkriterien für die jeweilige Geschichte wurden erfüllt, und das Team schreibt diese Liste auf und wendet sie konsequent an. Dies ist das Sicherheitsnetz , das Dinge auffängt, die bei den Akzeptanzkriterien möglicherweise nicht berücksichtigt Die Akzeptanzkriterien werden besagen, dass diese spezielle Geschichte tut, was sie sollte Eine Definition von Erledigt besagt, dass diese Arbeit unseren Qualitätsanforderungen entspricht. Bei einem nicht softwarebasierten Briefing würde die Definition von erledigt anders aussehen. Bei einem Ereignis kann es sein, die Aufgabe im Projektprotokoll dokumentiert ist. Alle Verträge werden unterzeichnet und archiviert. Alle Kosten werden im Budget-Tracker erfasst. Die betroffenen Interessengruppen wurden benachrichtigt. Das ist zum Beispiel die Definition von erledigt für eine Veranstaltung. Also, wie passen sie zusammen? Eine Geschichte ist wirklich fertig, wenn sowohl ihre Akzeptanzkriterien auch die Definition von erledigt erfüllt sind. Beides, weder das eine noch das andere, beides. Das ist der Standard. Sobald Sie diese beiden Tools eingerichtet haben, sollten diese Argumente, ob es fertig ist oder nicht , am Ende eines Sprints verschwinden. Das war's also den Akzeptanzkriterien und der Definition von „Erledigt“. Als Nächstes haben wir eine kleine Übungsaufgabe, bei der es darum geht, drei Anwenderberichte für das von Ihnen gewählte Projekt-Briefing zu schreiben , komplett mit Akzeptanzkriterien. Wir sehen uns also in der nächsten. 13. Übungsübung: Schreiben Sie drei User Stories für Ihr Briefing: Hallo und willkommen zurück. Dies ist das letzte Video der Sektion. Wir werden eine Übungsübung machen. Im letzten Video haben wir uns Nutzerberichte und Akzeptanzkriterien angesehen . In diesem Video machen wir eine kleine Übung, bei der Sie Ihre eigenen User Stories schreiben. Am Ende haben Sie also Ihre ersten richtigen Backlog-Elemente einsatzbereit Also was Sie brauchen, alles was Sie brauchen, ist etwas zum Schreiben, also verwenden Sie Stift und Papier Oder wenn Sie Trello bereits eingerichtet haben, können Sie Trello verwenden und eine Trello-Karte verwenden, oder Sie können eine Notion-Seite verwenden, wenn Sie lieber tippen, aber das Tool hier ist wirklich nicht wichtig Es sind eher die Inhalte , auf die wir uns konzentrieren müssen. Also zuerst einer, Schritt eins. Bevor Sie Geschichten schreiben, identifizieren Sie drei verschiedene Benutzertypen für Ihr Projekt. Verschiedene Benutzer haben unterschiedliche Bedürfnisse, und ein guter Backlog sollte dies widerspiegeln Bei Edtech könnten Sie also ein Lernkind, einen Elternteil und einen Lehrer haben Elternteil und einen Lehrer E, das sind übrigens drei sehr unterschiedliche Leute, also werden sie drei verschiedene Ziele haben Im Bereich E-Commerce könnten Ihre drei Personen ein Erstbesucher, ein wiederkehrender Kunde und ein Kunde sein , der ein Produkt zurückgibt. Und für Veranstaltungen könnten Sie einen Teilnehmer, einen Redner und einen Sponsor haben Redner und einen Sponsor Und noch einmal, jeder von ihnen kümmert sich um andere Dinge. Wählen Sie also drei Personen aus, schreiben Sie sie auf und pausieren Sie das Video jetzt. Du brauchst etwas Zeit zum Nachdenken. Lass uns mit Schritt zwei fortfahren. Jetzt ist es an der Zeit, die Geschichten zu schreiben. Sie haben eine Geschichte pro Benutzer. Verwenden Sie diese Vorlage also als Benutzer. Ich will ein Ziel, also aus diesem Grund. Eine Geschichte pro Benutzer, halten Sie sich strikt an dieses Format. Es fühlt sich zunächst starr an, aber diese Kraft ist klares Denken. Und ja, es müssen nicht die klügsten Geschichten sein. Denk einfach an offensichtliche. Was ist die grundlegendste Sache, die jeder Benutzer möchte, und fangen Sie dort an. So kannst du das Video jetzt pausieren und deine drei Geschichten aufschreiben deine drei Geschichten aufschreiben falls du dafür ein paar Minuten brauchst. Schritt drei: Schreiben Sie für jede Geschichte drei bis fünf Akzeptanzkriterien auf. Denken Sie also daran, spezifisch testbar und an diese eine Geschichte gebunden Wenn Ihre Geschichte zum Beispiel so ist, dass ich als Teilnehmer einen klaren Konferenzplan haben möchte, ich als Teilnehmer einen klaren Konferenzplan haben möchte damit ich meinen Tag planen kann Ihre Aufnahmekriterien könnten hier sein, dass der Zeitplan alle Sitzungen mit Uhrzeiten anzeigt Der Zeitplan ist vor der Veranstaltung online verfügbar, und in jedem Abschnitt wird der Name des Redners angezeigt. Der Zeitplan kann nach Titel oder Thema gefiltert werden. Also pausiere das Video jetzt. Sie können jetzt zusätzliche Kriterien hinzufügen, tut mir leid, zu Ihren drei Geschichten. Da haben wir es also. Sie sollten jetzt Ihre drei User Stories und Ihre Akzeptanzkriterien haben. Bewahren Sie diese jetzt sicher auf. Wir werden sie im dritten Abschnitt wieder verwenden. Wir werden sie verwenden, um deinen Backlog aufzufüllen. Also, gut gemacht, Sie haben das Ende des zweiten Abschnitts erreicht das Ende des zweiten Abschnitts Im nächsten Abschnitt werden wir uns mit der ordnungsgemäßen Einrichtung Ihres Projektarbeitsbereichs befassen. Gut gemacht, dass Sie so weit gekommen Wir sehen uns in Abschnitt drei. Willkommen zurück. In dieser Lektion werden wir uns die drei Rollen ansehen , die Agile-Teams zum Funktionieren bringen. Am Ende dieses Videos werden Sie wissen, wer was macht und warum es jede Rolle gibt. Wir konzentrieren uns hier auf das Scrum-Framework, weil es am gebräuchlichsten ist und die Rollendefinitionen am klarsten sind Fangen wir also an. Zunächst haben wir den Product Owner, auch bekannt als PO. Das ist die Stimme des Kunden im Team. Ihre Aufgabe ist es, zu entscheiden was das Team baut und in welcher Reihenfolge. Ihnen gehört der Produkt-Backlog, also die Liste der Aufgaben, die nach Prioritäten geordnet sind, und sie sind die Person, die sagt: Das ist das Wichtigste, tun Sie das Entscheidend ist, dass der PO nicht der Chef des Teams ist. Sie sagen dem Team nicht, wie die Arbeit zu erledigen ist. Sie sagen dem Team , was zu tun ist und warum es wichtig ist. Das Wie ist Sache des Teams. Ein guter Product Owner verbringt Zeit mit Kunden. Sie verstehen das Geschäft und treffen schwierige Entscheidungen über Prioritäten. Sie sagen oft nein , weil es immer mehr Nachfrage gibt , als sie aufnehmen können. Für Ihre Projektbeschreibung könnten Sie diese Rolle selbst spielen , was völlig in Ordnung ist. Denken Sie an die Denkweise des Product Owners, seien Sie sich über Prioritäten im Klaren, sprechen Sie mit Ihren Benutzern und gehen Sie Kompromisse Die nächste Rolle ist der Scrum Master, auch bekannt als SM Diese Rolle hilft dem Team, gut zu arbeiten. Nun, das ist eine der am meisten missverstandenen Rollen in Agile Der Scrum Master ist nicht der Projektmanager. Sie weisen keine Aufgaben zu. Sie verfolgen nicht, wer was getan hat. Sie jagen Leuten nicht nach Updates oder Ergebnissen, und sie sind auch nicht der Boss Was sie tatsächlich tun, ist, dem Team zu helfen, gut zu arbeiten. Sie erleichtern die Treffen. Sie beseitigen Hindernisse, Dinge, die das Team daran hindern, voranzukommen. Coachen Sie das Team in Bezug auf agile Praktiken. Sie schützen das Team auch vor jeglichen Einflüssen von außen. Eine der besten Analogien hier ist, dass der Scrum Master wie ein Fußballtrainer ist . Sie spielen das Spiel nicht Sie sagen den Spielern nicht, wie sie den Ball kicken sollen, aber sie schaffen die Bedingungen, unter denen die Mannschaft ihre besten Leistungen erbringen kann. In kleinen Teams übernimmt der Scrum Master oft eine andere Rolle, vielleicht den Senior Die gesamte Verantwortung wird geteilt, was völlig in Ordnung ist Solange die Arbeit erledigt wird, ist das eigentlich egal. Die nächste Rolle ist das Entwicklungsteam. Das sind die Leute, die das Produkt tatsächlich bauen. Trotz des Namens sind dies nicht nur Softwareentwickler oder Programmierer Das Entwicklungsteam besteht allen, die das Produkt tatsächlich Bei Software wären das Entwickler, aber auch Designer und Tester Für ein Marketingprojekt wären es Texter, Designer, Bei einer Veranstaltung sind es die Betriebsmitarbeiter, die Rednerkoordinatoren, der Zwei wichtige Dinge über das Entwicklungsteam. Zum einen organisieren sie sich selbst. Niemand sagt ihnen , wie sie die Arbeit aufteilen sollen. Sie finden es selbst heraus. Und zweitens sind sie funktionsübergreifend. Das Team verfügt über alle Fähigkeiten, die es benötigt, um Fortschritte zu erzielen, ohne von Außenstehenden abhängig zu Die typische Größe besteht aus drei bis neun Personen, groß genug, dass Sie über alle erforderlichen Fähigkeiten verfügen , und klein genug, dass jeder weiß was vor sich geht und wer was tut Schauen wir uns also an, wie diese drei Rollen zusammenarbeiten. Wir haben drei Zuständigkeiten und es gibt kaum Überschneidungen. Der Product Owner entscheidet, was gebaut werden soll. Das Entwicklungsteam entscheidet, wie es erstellt wird, und der Scrum Master stellt sicher , dass der Prozess reibungslos abläuft Diese drei Rollen und Verantwortlichkeiten überschneiden sich kaum Und diese Klarheit ist einer der Gründe, warum Scrum funktioniert. Jeder weiß, wessen Entscheidung wessen ist. Wenn ein Stakeholder eine neue Funktion wünscht, spricht er mit dem Product Owner Wenn ein Entwickler blockiert ist, hilft der Scrum Master dabei, ihn zu entsperren. Und wenn das Team sich für einen technischen Ansatz entscheiden muss, entscheidet es selbst Im wirklichen Leben, insbesondere in kleinen Teams, könnte eine Person zwei Rollen übernehmen. Sie könnten der Product Owner und ein Scrum Master sein. Oder, wie ich bereits sagte, könnte der Senior Developer auch der Scrum Master sein, was völlig normal ist Bei den Rollen geht es um Verantwortlichkeiten und nicht speziell um Berufsbezeichnungen Vielen Dank, dass Sie sich mir bei dieser Lektion angeschlossen haben. Als Nächstes werden wir uns den Produkt-Backlog ansehen. Wir werden uns ansehen, was darin enthalten ist, wie es strukturiert ist und wie man ein gutes baut. Wir sehen uns im nächsten. 14. Einrichten deines Projekts: Tour durch Trello: Boards, Listen, Karten, Labels: Hallo und willkommen zu Abschnitt drei unseres Projektmanagement-Kurses In diesem Abschnitt werden wir uns einige der kostenlosen Tools ansehen , mit denen Sie Ihr Projekt verwalten können . Das erste, das wir uns ansehen werden, heißt Trello. Es ist ein kostenloses und recht einfaches Tool , mit dem wir unsere Produkt-Backlogs verwalten können, und wir können auch unsere Sprints verwalten Daher werden wir einige der vorherigen Konzepte, die wir uns angesehen haben, in diesem Abschnitt verwenden. Lassen Sie uns also darauf eingehen. Zuerst werde ich die vier Hauptkomponenten von Trello durchgehen , dann öffne ich Trello und zeige dir ein Beispiel dafür, wie man es benutzt, und ja, ich zeige dir, wie einfach es ist und ja, ich zeige dir, wie einfach Zuallererst besteht Trello hauptsächlich aus einem Board, einem Cam-Band-Board Wir haben ein Board pro Projekt. Ihr gesamtes Projekt würde hier angezeigt werden. Also würden alle User Stories hier angezeigt. Das Board besteht aus Listen. In unserem Beispiel verwenden wir vier Spalten oder vier Listen , die die Arbeitsphasen darstellen. Wir haben also den Backlog , der alle Aufgaben und alle User Stories umfassen würde und alle User Stories umfassen Wir müssen das erledigen, was für den Sprint vorgesehen wäre für den Sprint vorgesehen wäre Also, wie viele werden wir in diesem Zeitraum von zwei Wochen machen. Tun ist das, woran jemand aktiv arbeitet und dann erledigt, das sind all die Aufgaben, die erledigt sind und gefeiert werden können. Also ja, der Arbeitsablauf läuft von links nach rechts. Ganz einfach. Jetzt werden wir in jeder Liste einzelne Karten haben. Das sind also einzelne Arbeitselemente oder Aufgaben. Wir haben eine User Story pro Karte. In eine Karte schreiben wir also, dass der Titel die User Story sein würde. In diesem Fall geben wir einfach das als Person ein, ich möchte, und dann geben wir diesen Abschnitt als Titel an. Die Beschreibung wird die gesamte Benutzerstory enthalten und wir werden auch einen Link zu Notion einfügen, da Notion ein weiteres kostenloses Tool ist , das wir uns in diesem Abschnitt ansehen werden, und es ist möglich, Notion mit Trello zu verknüpfen Das ist also sehr nützlich. Wir haben die Checkliste, die wir Akzeptanzkriterien nennen Das sind die Dinge , die erledigt werden müssen , damit die Karte als erledigt gilt Und dann haben wir Labels mit dem Prioritätstyp und dann der Benutzerkategorie. Also zeige ich dir die verschiedenen Labels. Dies sind die farbigen Etiketten, die das Board auf einen Blick lesbar machen . Wir haben die Prioritätsbezeichnungen , für die wir Rot, Gelb und Grün verwenden werden. Wir haben die Typbezeichnungen, und wir werden die Typbezeichnungen noch nicht verwenden, und dann haben wir die Benutzerbeschriftungen. diesem Sinne ist es eine gute Idee, Farben zu wählen, die sich unterscheiden lassen. Und noch einmal, ich werde dir das zeigen, wenn wir uns die Tour ansehen. Also nochmal: Es ist eine gute Idee, es einfach zu halten. Es ist eine gute Praxis. Fünf bis acht Etiketten, Max. Mehr als das wird ziemlich komplex, und Sie benötigen wahrscheinlich einen Schlüssel um zu verstehen, was all die Farben sind. Gehen wir also zu Trello. In Trello kannst du dich kostenlos registrieren Sobald du dich angemeldet hast und in Trello bist, gehst du hier zu den Pinnwänden , wo du all deine Boards siehst Hier wird es eine Standardversion geben, als Standardeinstellung wie bei Aber wir wollen ein neues Board erstellen. Wenn du also auf Neues Board erstellen klickst, hier den Titel des Boards ein, also geben wir ihn einfach ein. Das Beispiel, das ich verwenden werde, ist Edtech. Also werden wir es hier platzieren. Wir nennen es einfach Beispiel. Und dann klicken Sie auf Erstellen. Und so einfach ist das. Nun, hier müssen wir dann das Board mit unseren Listen füllen Wir haben also den Backlog. Wenn Sie auf Liste hinzufügen klicken, müssen wir etwas tun, wir haben etwas getan und wir haben es getan Das ist es. Wir haben also die vier, die vier Listen. Jetzt zeige ich Ihnen die Tafel, die ich zuvor vorbereitet habe. Es ist also genau dasselbe, aber ich habe das Backlog mit einigen User-Stories gefüllt Also ja, um das zu tun, fügen wir eine neue Karte Also werde ich mir eine neue User Story einfallen lassen. Als Lernender möchte ich mir Zubehör für meinen Avatar verdienen. Okay? Also füge die Karte hinzu. Wenn Sie nun auf die Karte klicken, um sie zu öffnen, haben Sie jetzt diese verschiedenen Optionen. Geben wir zunächst die Beschreibung ein, geben wir die gesamte Benutzergeschichte ein. Okay. Als Lernender möchte ich mir mit meinem Avatar Accessoires verdienen, damit ich es anpassen kann. Ich habe das Gefühl, dass es meins ist, und das speichern wir Und dann für die Labels, also habe ich die Labels hier ausgefüllt Sie können auf „Neues Etikett erstellen“ klicken , um das Etikett zu bearbeiten. Du klickst es einfach an. Sie können dann den Titel und dann eine beliebige Farbe auswählen. Ich habe mich für einige leicht zu unterscheidende Farben entschieden. Lass uns das einfach auch ändern . Da hast du's. , Nehmen wir an, es hat mittlere Priorität und es ist der Lernende Okay? Also, wir haben diese beiden Labels und wir können sie hier sehen. Und dann werden wir die Checkliste hinzufügen. Diese Checkliste würde also als Akzeptanzkriterien bezeichnet werden. Und dann klicken wir auf Hinzufügen, und hier fügen wir die Elemente hinzu, die abgeschlossen werden müssen , damit die Akzeptanzkriterien als erfüllt gelten Dafür benötigen wir also eine Zubehörbibliothek. Signiert. Wir benötigen Animationen für neues Zubehör und wir benötigen auch eine Soundbibliothek für Zubehör. Also Soundeffektbibliothek. Okay? Also haben wir diese drei Dinge und das war's. Also haben wir die gesamte User Story hinzugefügt, wir haben die Akzeptanzkriterien hinzugefügt, und hier ist es. Nun, wenn es Teil des bevorstehenden Sprints ist, würdest du es hier in die Tat umsetzen. Ähm, du klickst es einfach an und ziehst es, und so einfach ist das. Oder Sie können es auf „ Tun“ verschieben. Wenn es jetzt funktioniert, könnten Sie damit beginnen, einige dieser Kontrollkästchen zu markieren, um zu zeigen, dass es erledigt ist Und wenn dann alle drei fertig sind, können wir sehen, dass es auf 100% steigt Wenn wir es schließen. Drei von drei Punkten sind hier abgeschlossen, die Checklistenpunkte, sodass Sie hier die Checklistenpunkte sehen können hier die Checklistenpunkte sehen Wenn Sie darauf klicken, wird es erweitert. Sie können mehr anzeigen, wenn Sie möchten. Ja, sehr einfach. Sehr intuitiv. Und dann, ja, sobald es fertig ist, verschieben wir es auf Fertig. Das ist es. Das wäre also die Art und Weise, wie Sie Ihren Produkt-Backlog verwalten, und Sie werden, Sie wissen schon, User Stories in Aufgabenstellungen umwandeln Wenn Sie nun der Product Owner sind, weisen Sie diese Aufgaben möglicherweise dem Entwicklungsteam zu In diesem Fall würden Sie hier auf Mitglieder klicken und dann nach den Mitgliedern suchen, die Teil Ihres Teams sein würden , und Sie können sie hinzufügen und sie der Aufgabe zuweisen Das war's also für Trello. Im nächsten Abschnitt werden wir einen kurzen Überblick über Notion 15. Einführung in die Grundlagen: Seiten, Datenbanken, Vorlagen: Hallo und willkommen zurück. In diesem Video werden wir uns Notion ansehen , ein weiteres kostenloses Tool, das wir verwenden können. In diesem Fall werden wir es verwenden , um unsere Sprints zu verwalten Wie im vorherigen Video gebe ich Ihnen erneut einen kurzen Überblick über Notion und seine Konzepte. Anschließend werde ich Sie in Notion einführen und Ihnen genau zeigen, Anschließend werde ich Sie in Notion einführen und Ihnen genau zeigen wie Sie diese Seiten erstellen Notion ist also sehr einfach. Es ist im Grunde ein Dokument , das andere Dokumente enthalten kann. Die empfohlene Struktur wäre also ungefähr so. Wir haben die Überschrift mit My Agile Project und darunter haben wir verschiedene Unterseiten für jede Art von Dokument. Ich zeige dir genau , wie das geht , wenn du dir die Tour ansiehst. Eine weitere Sache, die Sie hinzufügen können, sind Tabellen oder Datenbanken. Es ist also wie eine Tabelle, aber jede Zeile ist eine Seite. Sie können also zum Beispiel dort öffnen, wo in der Spalte Sprint steht, Sie haben Sprint eins Wenn du darauf klickst, öffnet sich die Seite von Sprint One weiteren Details. Und ich werde dir in Kürze zeigen , wie das geht. Sie klicken also auf eine beliebige Straße, um sie als ganze Seite zu öffnen. Das sind dieselben Daten. Es gibt zwei Betrachtungsweisen. Es ist eine durchsuchbare Tabelle und eine Sammlung detaillierter Seiten Datenbanken sind in Notion äußerst nützlich, und sie werden eines der wichtigsten Dinge sein , die Sie verwenden, wenn Sie sie verwenden Und dann werden wir uns auch Vorlagen ansehen. Also, zum Beispiel bei User Stories, hätte das wahrscheinlich jedes Mal dieselbe Struktur. So können wir die Struktur jedes neuen Eintrags vorab ausfüllen. Bei einer Vorlage für die Sprint-Planung hätten wir zum Beispiel das Sprint-Ziel, die ausgewählten Backlog-Elemente und die Kapazitätsprüfung Und das wäre jedes Mal dieselbe Struktur, wenn sie für jeden Sprint wiederholt würde So können wir diese Vorlage erstellen und immer wieder verwenden. Wir schauen uns also eine Vorlage für die Sprint-Planung an und wir schauen uns auch eine Vorlage für die Retrospektive an. Dabei handelt es sich um die Besprechungen, die Sie nach jedem Sprint abhalten, in denen Sie besprechen, was gut gelaufen ist, was verbessert werden muss und welche Maßnahmen für den nächsten Sprint Und dann können Sie alles mit dem At-Zeichen verbinden. Sie können also „Wir haben das entschieden“ bei den Decision Streak Awards eingeben , und das würde Sie zu einer bestimmten Seite weiterleiten, und alles, was Sie tun müssen, ist auf Okay zu klicken, also schauen wir uns jetzt Notion an. Nun, das wird kein detailliertes Video zur Verwendung von Notion sein , weil das den Rahmen dieses Kurses bei weitem sprengen würde den Rahmen dieses Kurses bei weitem sprengen Notion hat viele, viele Funktionen, von denen Sie, wissen Sie, wahrscheinlich nie verwenden werden, aber die grundlegendsten sind diejenigen , die Sie wahrscheinlich verwenden. Sie können also online Videos finden, in denen Sie lernen, wie Sie das nutzen können. Sogar auf der Notion-Website selbst gibt es einige recht einfache Tutorials, und das ist alles, was Sie wirklich wissen müssen , um Notion gut zu nutzen. Hier habe ich also ein Beispiel für den Edtech-Projektsprint , den ich in Notion erstellt habe Es besteht aus vier Seiten. Wir haben Sprint-Planung. Wir haben Rückblicke, wir haben Entscheidungen und wir haben Updates für alle Beteiligten Bei der Sprint-Planung habe ich also eine neue Datenbank erstellt und einige verschiedene Spalten hinzugefügt Also habe ich den Namen. Ich habe die Sprintnummer. Ich habe den Datumsbereich. Ich habe das Sprintziel und ich habe den Status. Wenn ich jetzt diese Seite öffne, kann ich auch verschiedene Details zu dieser Phase des Sprints sehen . Ich kann die Kapazität sehen und ich kann mir ausgewählte Geschichten ansehen. Hier gibt es einen Link zu Trello, den ich dir in einem späteren Video zeigen werde Ich habe hier eine Kolumne für Risiken und Abhängigkeiten. Also alle Probleme, die Sie voraussehen und die Sie im Sprint blockieren könnten , sollten Sie hier aufschreiben und dann auch hier einen Abschnitt mit Verpflichtungen für also ja, das Team verpflichtet sich zu diesem Plan und dann zum Startdatum Sie würden das also mit verschiedenen Sprints ausfüllen , wenn Sie Retrospektiven machen Das ist also wieder eine weitere Datenbank, die Besprechungen nutzen kann Ich empfehle nun, den Umgang mit Vorlagen zu erlernen , da es in Retrospektiven immer wieder dieselbe Besprechungsstruktur geben wird immer wieder dieselbe Besprechungsstruktur So können Sie eine Vorlage für eine Sprint-Retrospektive erstellen. Und darin können Sie eintragen, was gut gelaufen ist. Sie können angeben, was verbessert werden muss, und Sie können einige Aktionspunkte festlegen. Deshalb habe ich hier nur einige Beispiele aufgeführt. Das Sprintziel war vom ersten Tag an klar, Stars-Feature wurde pünktlich geliefert. Stand-ups blieben unter 10 Minuten, was verbessert werden muss. Wir haben die Komplexität der Animation unterschätzt, wir benötigen eine klare Definition von Fertig, um Komplexität der Animation unterschätzt, wir benötigen eine klare Definition von Fertig, das Bild optisch aufzupolieren, und Aktionspunkte fügen die vom Designer überprüften Animationen zur Definition von Fertig hinzu und erhöhen die Animationsbibliotheken vor Animationsbibliotheken Hier können Sie also eine Datenbank mit all Ihren Sprint-Retrospektiven haben , was im agilen Projektmanagement sehr, was im agilen Projektmanagement sehr wichtig ist. Es ist sehr wichtig, dass Sie diese Retrospektiven als Grundlage für Ihre Produktentscheidungen nutzen diese Retrospektiven als Grundlage für Ihre Produktentscheidungen nutzen. Die nächste Seite hier heißt Entscheidungen. Hier haben wir also die Entscheidungen, auf die wir nach dem letzten Sprint reagiert haben . Also hier habe ich eine neue Datenbank erstellt. Ich habe zwei neue Entscheidungen hinzugefügt. Ich habe verschiedene Spalten hinzugefügt. Ich habe die Entscheidung. Ich habe das Datum. Ich habe das Warum und ich habe das Wer. Also, wenn wir das öffnen, können wir schon sehen, das Datum der 12. Mai war. Wer hat entschieden, dass es das Team war? Das Team entschied sich, die Plattform Lottie für die Animationen zu verwenden , da diese Animationen leichter und einfacher zu aktualisieren sind Wir haben hier also den Konsens im Team. Es ist also gut, alle Ihre Entscheidungen im Auge zu behalten , weil Sie die Leute für ihre Entscheidungen zur Rechenschaft ziehen können Hier nur ein weiteres Beispiel: Eltern-Dashboard wurde auf Sprint 3 verschoben, etwas, das länger dauern wird als erwartet Wir haben das Datum, wir haben, wer über PO, Product Owner, entschieden hat, warum begrenzte Kapazitäten, warum begrenzte Kapazitäten, Funktionen für Lernende haben eine höhere Priorität Also die Entscheidungen, warum die Entscheidungen getroffen wurden und wer sie entschieden hat, alle hier gespeichert. Die letzte Seite, die Sie wahrscheinlich erstellen sollten, sind Updates für Interessengruppen Also hier habe ich wieder eine weitere Datenbank mit Sprint Nummer eins hinzugefügt, dem Datum, an dem sie gesendet wurde und an wen sie gesendet wurde Also hier habe ich eine neue Seite erstellt, ein Update zum Thema Führung. Es wurde an das Führungsteam geschickt. Also wurde das Sprintziel erreicht? Ja, es wurden die Artikel versandt, die an das Star-Belohnungssystem und die Avatar-Auswahl gesendet wurden. Dies sind die funktionierenden Produkte, die versendet werden. die übergeordnete E-Mail-Zusammenfassung versendet, die wir auf Sprint verschoben haben. Oh, Sprint drei, nicht Sprint zwei Und die nächsten Sprint-Fokusserien und täglichen Erinnerungen Also Updates für Stakeholder, wem haben Sie den Projektfortschritt auf dem Laufenden gehalten Das alles können Sie hier speichern. Also, ja, das ist das Ende unserer Tour durch Notion. Als Nächstes baust du deinen ersten Backlog auf. Also werden wir in Trello ein neues Backlog von Grund auf neu erstellen. Das ist sehr praktisch, also sehen wir uns beim nächsten Video 16. Erstellen Sie Ihr erstes Produkt-Backlog in Trello: Hallo und willkommen zurück. In diesem Abschnitt erstellst du dein erstes Produkt-Backlog in Trell Du wirst das von Grund auf neu machen. Jetzt können Sie das vorherige Video als Referenz verwenden, aber ich werde Ihnen Schritt für Schritt erklären, wie Ihr erstes Produkt-Backlog in Trell aufbauen Der erste Schritt besteht also darin, dein Board einzurichten, das Board zu erstellen und es nach dem Briefing zu benennen, das du zu Beginn dieses Kurses ausgewählt hast Im zweiten Schritt fügst du vier Listen hinzu, dein Backlog ist erledigt und fertig Und wenn Sie möchten, können Sie dann eine Hintergrundfarbe wählen. Sie können es anpassen. Das liegt an dir. Schritt zwei ist das Brainstorming. Jetzt möchten Sie einen Brain-Dump von allem erstellen , was Ihr Projekt Jetzt müssen Sie es noch nicht filtern oder verfeinern. Streben Sie also etwa 15 bis 20 Rohartikel an. Ich meine, wenn du nur zehn bekommen kannst, ist das in Ordnung. Oder weniger, es ist in Ordnung. Stellen Sie einfach sicher, dass Sie mehrere haben. Geben Sie jedes als schnelle Trelcard in die Backlog-Liste ein. Und dann mach dir noch keine Gedanken über das Format der Geschichte, hol dir alles Dann wäre der nächste Schritt, die User Stories zu schreiben. Verwandeln Sie diese Rohdaten also in richtige Geschichten mit den Kriterien. In diesem Fall würden sich vielleicht zwei Rohelemente zu einer User Story zusammenfügen. Um das zu tun, öffne jede Karte und schreibe den Titel in der als Benutzer neu Ich möchte das , damit ich es formatieren kann. Fügen Sie in der Beschreibung die vollständigen Story-Details hinzu. Wie Sie im vorherigen Video gesehen haben, habe ich nur den Abschnitt ASA und I Want als Titel verwendet, und dann verwende ich das Ganze in der Beschreibung. Darunter fügen Sie Ihre Akzeptanzkriterien mit den zwei oder drei testbaren Elementen hinzu. Es könnten mehr sein Im vorherigen Video hatten wir vier Artikel. Dies wären die Dinge, die getan werden müssen, damit diese User Story als vollständig angesehen werden kann. Und dann ist das Letzte, was Sie tun können, zuerst die fünf bis sieben wichtigsten Elemente zu verfeinern. Die anderen können warten und so viele machen, wie Sie möchten, aber tun Sie nicht zu viele. Auch hier lernen wir gerade, wie man Trello benutzt . Schritt vier wäre , jede Karte zu kennzeichnen und zu priorisieren Erstellen Sie also Ihre Prioritätsbezeichnungen hoch, rot, mittel, gelb oder orange, und niedrige Priorität ist normalerweise Fügen Sie bei Bedarf Typ- oder Benutzerbezeichnungen hinzu. Bei meinem EdTech-Projekt die drei verschiedenen Benutzer beteiligt waren die drei verschiedenen Benutzer beteiligt: der Lehrer, der Schüler und der Elternteil Sie dürfen hier nur einen oder zwei Benutzer haben. Oder mehr. Dann sollten Sie Ihre Karten mit der höchsten Priorität an den Anfang der Backlog-Liste ziehen an den Anfang der Backlog-Liste Das ist, wissen Sie, die typische Rolle eines Product Owners. Sie priorisieren die Aufgaben entsprechend. Und dann denken Sie bei der Priorisierung an die Werte-F-Matrix Sie bei der Priorisierung an die Werte-F-Matrix Die schnellsten Aufgaben setzen sich in der Regel durch, und dann ist der fünfte Schritt eine Verfeinerung und Überprüfung Zuallererst, entsprechen meine fünf wichtigsten Punkte der Abkürzung Invest der Abkürzung Invest Wenn ich nur die ersten fünf zusammenstellen würde, wären die Nutzer dann besser dran, ja oder nein, und es fehlt offensichtlich etwas. Stellen Sie also sicher, dass Sie all diese drei Dinge überprüfen bevor Sie Ihr Protokoll für abgeschlossen Es gibt einige häufige Fallstricke , die Sie vermeiden sollten. Der erste ist, zu groß zu sein. Auch hier ist es nicht notwendig, einen absolut riesigen Rückstand aufzubauen. Also ja, erstelle keinen Backlog mit 80 Artikeln, den du dir nie wieder ansehen wirst Nur 15 bis 25 anzustreben, ist vielleicht ein bisschen zu viel Zehn ist eine gute Zahl. Machen Sie es nicht zu vage, sondern geben Sie sehr genau an, wer, was und warum Und dann endlich, ja, es in Stein gemeißelt haben. Das ist ein häufiger Fallstrick Sie werden wöchentlich hinzufügen, entfernen und neu bestellen. Der Produkt-Backlog ist eine Sache, die sich ewig bewegt. Er ist nie in Stein gemeißelt. Die Dinge werden sich immer ändern. Sie werden immer ändern, sogar die Spaltennamen, die Sie vielleicht irgendwann ändern werden. Als Nächstes werden wir uns ansehen, wie Sie Notion mit Trello verknüpfen. Das verbindet also die beiden Tools zu einem verbundenen System Wir sehen uns beim nächsten Mal. 17. Verknüpfen von Notion mit Trello zur Dokumentation: Hallo, willkommen zurück. In diesem kurzen Video werden wir uns ansehen, wie Sie Notion mit Trello verknüpfen Inzwischen sollten Sie also Ihr Produkt-Backlog-Beispiel in Trello erstellt haben , und Sie sollten auch Ihr Dokumentations-Skelett in Notion erstellt haben Ihr Dokumentations-Skelett in Notion erstellt Ich werde Ihnen schnell zeigen, wie und warum wir die beiden Tools miteinander verknüpfen Zuallererst, warum sie verknüpfen? Trello und Notion sind zwar beide sehr nützlich für das Projektmanagement, aber beide sind irgendwie miteinander verknüpft und orientieren sich an unterschiedlichen Denkweisen Trello ist also eher für was für eine Arbeit? Wo ist es, wer macht es, also der tatsächliche tägliche Fortschritt der Projekte Bei Begriff hingegen handelt es sich eher um Informationen über die getroffenen Entscheidungen. Warum haben wir das entschieden? Was haben wir gelernt und was ist der Plan? Notion ist als Dokumentationstool in der Regel besser für langfristiges Denken und langfristige Planung geeignet, wohingegen Trello für die kurzfristige Planung und das kurzfristige Management von Projekten und Sprints geeignet ist und das kurzfristige Management von Projekten und Sprints Es gibt also zwei Methoden, Notion und Trello zu verknüpfen. zunächst die Trello-Links in Notion, die etwas ausgefeilter sind als die Notion-Links in Und ich werde dir gleich zeigen, was ich meine. Aber zuerst klickst du in Trello auf eine Karte und hast die URL aus dem Browser kopiert Fügen Sie es in Ihre Notion-Seite und dann zeigt Ihnen Notion eine Live-Vorschau dieser Karte Es ist also etwas ausgeklügelter, dass beim Einfügen einer Vorschau der Karte die Stelle geladen wird, an der Sie diese URL eingefügt haben Methode zwei: Notion-Links in Trello sind nicht so ausgefeilt, und es geht nur um den Dazu öffnen Sie also Notion-Seite, die Sie verlinken möchten Sie klicken auf Teilen und kopieren den Link zu dieser Seite Anschließend können Sie ihn in die Kartenbeschreibung in Trello einfügen , was sehr nützlich ist jedoch nicht der Fall, es gibt keine Vorschau einer Karte oder so, aber jeder, der Zugriff auf die Karte hat, kann direkt durch den Link klicken und auf diese Seite zugreifen. Wenn Sie also Ihre Begriffsstruktur noch nicht erstellt haben, tun Sie das jetzt. Sie sollten also vier Unterseiten haben, eine für die Sprint-Planung, eine für Retrospektiven, eine für Entscheidungen und eine für Updates für Stakeholder Wie in der Realität werden diese Unterseiten mit dem Fortschreiten Ihrer Projekte werden diese Unterseiten immer größer und größer, und es werden immer mehr Details hinzugefügt Es ist also sehr wichtig , dass Sie, Sie wissen schon, das Grundgerüst dieser Struktur haben . Also ja, in der nächsten Übung werden wir uns ansehen, wie wir das alles zusammenfügen, aber bevor wir weitermachen werde ich Ihnen kurz zeigen, wie Sie genau das hinzufügen können, was wir hinzufügen müssen, um die beiden Tools miteinander zu verknüpfen. Also haben wir unser Trello-Board. Wir haben unser Notion-Dokument. Und was ich tun werde, ist Trello mit Notion zu verknüpfen. Also werde ich einen Link von Trello kopieren und ihn in Notion einfügen Schauen wir uns also die Sprint-Planung an. Wir haben diesen Star Reward System Sprint. Ich werde diese Seite öffnen. Und vielleicht erinnerst du dich daran aus dem vorherigen Video , als ich diese Seite geöffnet habe . Hier gab es eine Vorschau einer Karte. Das ist der Trello-Link. Ich werde dir jetzt zeigen, wie das geht. Also muss ich diese Geschichte in meinem Trello-Board finden , und ich habe sie hier. Als Lernender möchte ich Sterne verdienen, wenn ich Lektionen abschließe Um dies zu verlinken, klicken wir nur mit der rechten Maustaste auf diese Karte und klicken dann auf diese Schaltfläche hier, Link kopieren Sobald es kopiert ist, können wir zu Notion zurückkehren und es dann hier einfügen. Und wie Sie sehen können, haben wir jetzt die Option. Wir können es als Vorschau einfügen. Sie können es als Erwähnung einfügen oder wir können einfach die URL einfügen. Wir werden eine Vorschau einfügen. Und das ist alles. Wenn du also darauf klickst, wird die Karte direkt in Trello geöffnet die Karte direkt in Trello Das ist also sehr, sehr nützlich. Schauen wir uns nun an, wie wir hinzufügen, wie wir den Link von Notion zu Trello hinzufügen Wenn wir also diese Karte öffnen, habe ich, wie du siehst, den Link hier schon Ich habe ihn gerade kopiert und in die Beschreibung eingefügt. Mit Notion zum Kopieren und Einfügen ist es also ganz einfach. Klicken Sie darauf. Welche Seite auch immer Sie verlinken möchten: In Trello öffnen Sie sie, klicken auf die drei Punkte und dann auf Link kopieren. So einfach ist das Und dann fügen Sie es dort in die Beschreibung ein. Und wie Sie sehen können, ist es genau derselbe Link. Also ja, ich werde das löschen. Und das ist es. So einfach ist das. Sie kopieren nur Links und fügen sie an den richtigen Stellen Als Nächstes richtest du deinen Workspace ein und stellst alles zusammen. Ich sehe dich dann. 18. Übung: Einrichten des Projektarbeitsbereichs: Willkommen zurück. Es ist also Zeit für die praktische Übung, die diesen gesamten Abschnitt abschließt. Falls du es noch nicht getan hast, richtest du den kompletten Arbeitsbereich ein, den du für den Rest des Kurses verwenden wirst, dein Trello-Board, deine Begriffsstruktur Am Ende dieses Videos und Abschnitts bist du also bereit für die Sprint-Planung in Abschnitt vier Wenn Sie es also noch nicht getan haben, finden Sie hier Ihre Checkliste mit acht Punkten Das müssen Sie bis zum Ende der Übung erledigt haben , acht Punkte Ich werde sie kurz durchgehen, und dann können Sie eine Pause einlegen und sie in Ihrem eigenen Tempo durcharbeiten. Das erste ist das Trello-Board, das nach deinem Briefing erstellt und benannt wurde Zweitens sind mindestens 15 Einträge im Backlog als User Stories Prioritätskennzeichnungen erstellt und angewendet Also Listen mit noch zu erledigendem und erledigenem Rückstand, fünf wichtigsten Geschichten mit Checklisten für die Akzeptanzkriterien Ein Begriff auf der Hauptseite mit dem Titel Mein Agile-Projekt oder so ähnlich Und mindestens eine Konzeptseite hat einen Trello-Link, und mindestens eine Trello-Karte hat einen Begriffs-Link Das sollte also deine Checkliste mit acht Punkten sein. Für das Trello-Setup nur eine kurze Erinnerung: Wenn Sie die letzte Lektion gemacht haben, sollte alles trotzdem erledigt sein Aber Nummer eins: Stelle sicher, dass dein Board existiert. Es ist benannt. Sie haben die vier Listen an Ort und Stelle. Sie haben Ihren Backlog aufgefüllt und Ihre fünf wichtigsten User Stories mit Akzeptanzkriterien und Labels verfeinert Ich würde sogar empfehlen , sie alle mit Labels zu versehen , da Sie das tun müssen. Begriff einrichten. Stellen Sie also sicher, dass Sie einige Vorlagen erstellt haben und Ihre Struktur vorhanden Sie sollten Ihre Hauptseite mit dem Titel haben, und das ist die Startseite für alles. Dann sollten Sie Ihre vier Unterseiten mit Sprint-Planung, Rückblicken, Entscheidungen und Stakeholder-Updates Auch hier gilt: Wenn Sie das auf eine andere Art strukturieren möchten , ist das in Die Struktur, die ich verwendet habe, ist nur ein einfacher Weg, dies zu tun. Wenn du es ausgefallener oder raffinierter machen willst. Mach weiter. Es ist dein Vorrecht Versuchen Sie abschließend, mindestens zwei Vorlagen zu erstellen. Also eine für die Sprint-Planung und eine für die rückwirkende Planung, sodass sie sofort verwendet werden können, da es sich um zwei Vorlagen handelt , die Sie immer wieder und wieder verwenden Sie müssen die Sprints planen und Sie müssen Ihre Retrospektive über diese Sprints durchführen Ihre Retrospektive Für die Sprint-Planung ist es also sehr wichtig , dass diese beiden Vorlagen bereits eingerichtet und Also drei Fragen, bevor Sie fertig sind. Öffnen Sie beide Tools nebeneinander, und Sie können mit einem Klick zwischen ihnen wechseln. Die zweite Sache, die Sie überprüfen sollten, ist , ob jemand, der neu im Projekt ist, Ihr Projekt innerhalb von 5 Minuten versteht , wenn er sich nur das Board ansieht und sich nur die Idee ansieht. Und dann könntest du dich auch fragen: Fehlt offensichtlich etwas, von dem du denkst, dass du es nächste Woche brauchen wirst ? Wahrscheinlich die Vorlagen. Die Vorlagen sind vielleicht etwas , das du vielleicht vergisst. Stellen Sie sicher, dass Sie mindestens zwei Vorlagen für unseren Abschnitt zur Sprint-Planung bereit haben . Das war's für das Ende von Abschnitt drei. Wir haben Trello abgeschlossen. Wir haben Notion abgeschlossen. Wir haben, weißt du, ein paar nackte Knochen, mit denen wir in unserem nächsten Abschnitt arbeiten können, in dem wir deinen ersten Sprint planen werden. Das ist also unser Einstieg in die eigentliche Projektplanungsarbeit. Wir sehen uns in Abschnitt vier. 19. Planung Ihres ersten Sprints: Priorisierung des Backlogs: Moskau und Wert vs. Aufwand: Hallo und willkommen zu Abschnitt vier unseres Projektmanagement-Kurses In Abschnitt drei haben wir uns mit der Einrichtung Ihrer Arbeitsbereiche in Trello und Notion befasst Einrichtung Ihrer Arbeitsbereiche in Trello und Und jetzt kommen wir zum Kern von Agile, entscheiden, was tatsächlich getan werden soll und in welcher Reihenfolge In dieser Lektion werden wir uns mit den beiden einfachen, leistungsstarken Priorisierungstechniken befassen, leistungsstarken Priorisierungstechniken die Sie sofort anwenden können Moscow und die Value versus Warum ist die Priorisierung also schwierig? Nun, diese Priorisierung ist wahrscheinlich die schwierigste Fähigkeit im Projektmanagement im agilen Projektmanagement Das liegt nicht daran, dass die Techniken kompliziert sind. Das liegt daran, dass es schmerzhaft sein könnte, etwas zu sagen. Jeder Artikel in Ihrem Backlog ist also für jemanden wichtig, und jeder einzelne wurde aus einem bestimmten Grund hinzugefügt Aber die Wahrheit ist, du kannst nicht alles machen. Wenn du versuchst, alles zu machen, wirst du nichts gut abliefern. Priorisierung ist die Disziplin , das zu akzeptieren und zu entscheiden, wo Sie Ihre begrenzte Zeit verbringen möchten Die Techniken, die wir behandeln werden, sind lediglich Werkzeuge, um diese Entscheidungen einfacher und vertretbarer Die erste Technik ist also die Moskauer Methode. Die erste Technik hat die Abkürzung MoSCoW. Die Großbuchstaben stehen für vier Kategorien. Must-Haves hätten haben müssen, Die Must-Haves hätten haben müssen, hätten können und werden nicht haben, ohne sie scheitern der Sprint oder das Release Sie sind nicht verhandelbar. Wenn Sie also beispielsweise ein Zahlungssystem einführen, ist die Möglichkeit, tatsächlich Geld anzunehmen, ein Muss Wenn Ihre Veranstaltung Redner hat, dann ist eine Bühne ein Muss. Sollten sie haben, sind sie wichtig, aber der Sprint oder die Veröffentlichung können auch ohne sie erfolgreich sein Es mag unangenehm sein , sie wegzulassen, aber das macht nichts kaputt. Also, zum Beispiel eine gute Fehlermeldung auf einem Anmeldeformular, das sollte man haben. Es ist nett, aber Sie können ohne das Produkt versenden oder ohne es arbeiten. Könnte haben, die sind nett zu haben. Sie haben eine niedrigere Priorität. Wenn Sie Zeit haben, können Sie sie einbeziehen. Also zum Beispiel eine ausgefallenere Ladeanimation oder eine Bonus-Integration, Dinge, die Freude bereiten, also wie ein Sahnehäubchen, damit sie es nicht schaffen oder Und dann werden wir endlich nicht zulassen, dass es sich dabei um explizite Entscheidungen handelt , etwas nicht in einen Sprint oder in ein Release aufzunehmen etwas nicht in einen Sprint oder in ein Release Willküre sind also eine aktive Wahl, um Prioritäten zu setzen. Wenn Sie sie dokumentieren, können Sie verhindern, dass sich der Umfang zu einem späteren Zeitpunkt ändert. Die Disziplin ist also ein gesunder, von Moskau priorisierter Rückstand rund 60% müssen, 20% sollten, 20% könnten Wenn Sie 80% der Dinge haben müssen, haben Sie keine Prioritäten gesetzt. Sie haben gerade alles auf dringend umbenannt. Schauen wir uns nun die Matrix zwischen Wert und Aufwand an. Wir haben das in Abschnitt zwei ein wenig angesprochen. Schauen wir uns nun an, wie es richtig verwendet wird. Dafür können Sie also schnell ein Zwei-mal-Zwei-Raster zeichnen. Die vertikale Achse ist ein Wert. Wie wird dieser Artikel Ihren Benutzern oder Ihrem Unternehmen helfen? Jetzt ist die horizontale Achse Anstrengung. Wie viel Arbeit wird die Lieferung kosten? Und das gibt Ihnen vier Quadranten. Oben links steht hoher Wert, geringer Aufwand, schnelle Gewinne. Machen Sie diese zuerst Sie sorgen für Dynamik. Sie entsperren Dinge und sie sind ziemlich billig. Es gibt keinen Grund, sie zu verzögern. Oben rechts steht viel wert, hoher Aufwand, große Wetten. Machen Sie sie an zweiter Stelle. Sie sind sehr wichtig, aber sie erfordern echte Arbeit. Plane für sie, schlage sie auf und mache sie bewusst. Unten links haben wir einen niedrigen Wert, aber wenig Aufwand. Das sind also Füllstoffe. Sie sind nicht entscheidend, aber sie sind zeit- und ressourcenschonend Platziere sie zwischen deinen größeren Gegenständen , wo das Team freie Kapazitäten hat. Und dann unten rechts haben wir einen niedrigen Wert und einen hohen Aufwand. Wirf sie einfach weg, lösche sie einfach. Sie verdienen nicht die Zeit, die sie gekostet haben. Wenn sie wirklich wichtig sind, kommen sie zurück und du kannst es dir noch einmal überlegen Aber eine der Fallen, in die die meisten Teams tappen, ist viel Zeit im Big Bet-Quadranten zu verbringen Große, wichtige Funktionen , deren Auslieferung Monate in Anspruch nimmt, zwingen Sie sich, schnelle Gewinne zu finden, gehen Sie Kompromisse Dadurch wird die Dynamik aufrechterhalten, während die großen Wetten getätigt werden. beide zusammen verwenden, sollten Sie sie jetzt gegenseitig ergänzen Sie sollten sie nicht im Wettbewerb einsetzen. Sie arbeiten sehr gut zusammen. Fangen Sie also mit Moskau an, um Ihren gesamten Rückstand zu kategorisieren. Das gibt dir ein schnelles Bauchgefühl über den Fortschritt. Und jetzt nehmen Sie Ihre Must-Haves und Ihre Soll-Haves und platzieren Sie sie in der Nutzen-Aufwand-Matrix Und das gibt Ihnen die Reihenfolge, in der Sie sie angehen Nun, warum würdest du diese kombinieren? Weil Moskau Ihnen sagt, worauf es ankommt, Wert versus Aufwand sagt Ihnen, was Sie zuerst tun müssen. Zusammengenommen erhalten Sie also einen Rückstand, der nach Wichtigkeit priorisiert und auch nach Sensibilität geordnet ist. Wenden Sie es nun auf Ihr Briefing an. Öffnen Sie also Ihr Trello-Board. Nimm deine Top 15, deine Top Ten oder 15 Artikel Führe sie zuerst durch Moskau. Verwenden Sie die Labels, die Sie in Abschnitt drei eingerichtet haben. Fügen Sie also vier Moskauer Labels Rot für Most, Orange für Shod, Gelb für Cud, Grau für Wont, und dann nehmen Sie Ihre Most und Shmuds und ordnen Sie Die schnellen Siege stehen ganz oben auf deiner Backlog-Liste, die große Wette auf den zweiten Platz, Filler dazwischen Alles, was im Wurf landet . Archivieren Sie es jetzt. Sei bei diesen Dingen nicht wertvoll. also zwei einfache Tools anwenden, werden Sie ehrlich gesagt Ihre Planung und Prioritätensetzung grundlegend verändern Sie ehrlich gesagt Ihre Planung und Prioritätensetzung Also danke, dass du mich bei dieser Lektion unterstützt hast. In der nächsten Lektion werden wir uns mit Schätzungen befassen, ohne zu lügen, anhand einiger Beispiele anhand von T-Shirt-Größen und Hintergrundinformationen. In der nächsten sehen wir uns. 20. Grundlagen der Schätzung: T-Shirt-Größen und Story-Punkte: Hallo, willkommen zurück. Schätzungen sind einer der Bereiche des agilen Projektmanagements , den viele Leute falsch verstehen Sie behandeln es wie eine Vorhersage, und das ist es nicht. In dieser Lektion werden wir uns also zwei ehrliche Methoden zur Schätzung der Größe eines Werks, der T-Shirt-Größen und der Story Points ansehen zwei ehrliche Methoden zur Schätzung der Größe eines Werks, der . So wissen Sie, wie Sie Ihren Rückstand einschätzen können, ohne sich selbst oder Ihre Stakeholder zu belügen Lassen Sie uns zunächst wissen, was eine Schätzung ist und was nicht. Lassen Sie von Anfang an eines klarstellen Eine Schätzung ist eine Vermutung, die auf dem basiert, was Sie jetzt wissen. Dies ist kein Versprechen und es ist keine Verpflichtung und es ist keine Frist. Das klingt ziemlich offensichtlich, aber die meisten Teams vergessen es. Jemand fragt, wie lange das dauern wird, und das Team sagt drei Wochen. Und aus drei Wochen wird ein Datum. Es wird zu einer Verpflichtung. Jetzt gerät das Team in Panik, arbeitet spät, macht Abstriche oder weil jemand einen Kostenvoranschlag mit einem Vertrag verwechselt hat einen Kostenvoranschlag mit einem Vertrag verwechselt Eine gute Schätzung ist ehrlich, wenn es um Ungewissheit geht. Es sagt: Das fühlt sich klein an oder das fühlt sich groß an, und dann nutzt es das, um zu planen, nicht um etwas zu versprechen Die T-Shirt-Größen sind also bewusst vage. Menschen sind schlecht in absoluten Zahlen. Also die erste und einfachste Schätztechnik, T-Shirt-Größen, extra klein, klein, mittel, groß, extra groß Das ist es. Keine Zahlen, keine Stunden, keine Tage. Aber warum so vage? Das, weil das der Punkt ist Menschen sind sehr schlecht darin, in absoluten Einheiten zu schätzen. Fragen Sie einen Entwickler, wie lange etwas in Tagen dauern wird, und Sie werden wahrscheinlich eine falsche Antwort erhalten Aber wenn Sie sie fragen, ob es sich um eine kleine oder mittlere Frage handelt, werden Sie eine genaue Antwort erhalten . Also hier ist, wie man es benutzt. Für jeden Artikel in deinem Backlog vereinbart das Team eine T-Shirt-Größe Extra klein ist trivial, klein, vielleicht ein halber Arbeitstag, mittel, ein oder zwei Tage, groß ist meistens ein Sprint und extra groß ist zu groß, es muss aufgeteilt werden Nun, dieser letzte Punkt ist wichtig. Wenn etwas immer als L bezeichnet wird, ist das ein Zeichen dafür, dass es in kleinere Teile aufgeteilt werden muss . Und alles, was größer ist als ein einziger Sprint ist keine Geschichte, es ist ein Epos. Das muss aufgeschlüsselt werden. T-Shirt-Größen sind perfekt für Anfänger und für Arbeiten, die nichts mit Software zu tun haben. Wenn Sie die Ereignisse kurz fassen, ist das wahrscheinlich die Technik , mit der ich beginnen würde. Als Nächstes folgen Story Points. Das ist etwas strukturierter und kommt in Softwareteams häufiger vor. Story Points sind Zahlen normalerweise der Fibonacci-Sequenz folgen Eins, zwei, drei, fünf, acht, 13, 21, ich Fibonacci, das liegt daran, dass die Lücken immer größer werden, je größer die Zahlen werden, was widerspiegelt, wie Unsicherheit die Lücken immer größer werden, je größer die Zahlen werden, was widerspiegelt, wie Unsicherheit funktioniert. Der Unterschied 1—2 ist gering. Der Unterschied 13-21 ist riesig, weil man nicht wirklich weiß, wie groß einer von beiden ist Storypoints gehören nicht uns. Story Points stellen die relative Größe einer Arbeit im Vergleich zu anderen dar. Fünf sind nicht 5 Stunden oder fünf Tage. Das ist fünfmal so viel Aufwand eine One-Punkt-Story in Ihrem Team. Um Storypoints zu verwenden, wählen Sie eine kleine Referenzstory Ihr Team sich einig ist, dass sie beispielsweise zwei Punkte wert ist. Dann schätzen Sie, dass alles andere , was damit zusammenhängt, die Geschichte doppelt so lang ist. Sie ist fünf, halb so groß, sie ist eine Eins. Es hat ungefähr die gleiche Größe, es ist eine Zwei. Der Zauber von Story Points besteht darin, dass Ihr Team damit messen kann, wie viel es normalerweise pro Sprint abliefert Das nennt man Velocity. In Kurs zwei werden wir uns eingehender mit der Geschwindigkeit befassen. Also, wie man als Team tatsächlich gemeinsam schätzt. Für welche Technik Sie sich auch entscheiden, die Art und Weise, wie Sie die Schätzungen tatsächlich durchführen, ist wichtig. Die klassische Technik heißt Planning Poker. Das Team kommt zusammen, liest eine Geschichte vor. Jeder wählt heimlich eine Größe oder eine Zahl aus, und wenn man bis drei zählt, verrät es jeder auf einmal Wenn Sie sich alle ungefähr einig sind, dann ist die Schätzung das, was Sie alle wählen Erledigt. Wenn es Unstimmigkeiten gibt, ist das Interessante daran . Ermitteln Sie nicht den Durchschnitt. Sie bitten die höchsten und niedrigsten Schätzer, ihr Denken zu erklären Oft weiß einer von ihnen etwas, das die anderen nicht wissen , zum Beispiel, oh, Sie wussten nicht, dass die API dieses Feld nicht hat, wir müssen es selbst erstellen also nach der Diskussion erneut ab, Stimmen Sie also nach der Diskussion erneut ab, und dann kommen Sie normalerweise zusammen. Wenn du alleine an deinem Projekt für diesen Kurs arbeitest, kannst du das trotzdem tun, schätze ehrlich Und jedes Mal, wenn Sie eine Geschichte beenden, die ganz anders aussah als Ihre Schätzung, können Sie das zur Kenntnis nehmen. So wirst du besser. Oh, Schätzungen sind Lebewesen. Ein letzter Grundsatz ist , dass Schätzungen nicht in Stein gemeißelt sind. Wenn Sie mehr erfahren, werden Sie sie ändern. Auch hier das grundlegende Konzept des agilen Projektmanagements, das ist also sehr gesund. Eine Geschichte, die Sie letzte Woche als mittelgroß eingestuft haben, könnte jetzt, wo Sie eine ähnliche Geschichte geschrieben haben, klein aussehen . Eine Geschichte, die Sie für besonders klein hielten, erwies sich als riesig, als Sie anfingen, an der Oberfläche zu kratzen. Sie sind also geschätzt. Es ist kein Misserfolg. Lernen und Anpassen. Die Teams, die die Schätzung richtig machen , behandeln ihre Schätzungen wie alles andere in Agile als Hypothese wie alles andere in Agile Sprintziele also, auf die es ankommt. Das wird in unserer nächsten Lektion sein, ein Satz, aber er ist sehr ergebnisorientiert. Vielen Dank, dass Sie an dieser Lektion teilgenommen Wir sehen uns in der nächsten. 21. Festlegen eines Sprintziels, das wichtig ist: Hallo und willkommen zurück. haben wir über Priorisierung und Schätzung gesprochen, und jetzt kommen wir zu einem kleinen, aber sehr wirkungsvollen Konzept, dem Sprintziel Am Ende dieser sehr kurzen Lektion werden Sie also wissen, was ein Sprintziel ist, warum jeder Sprint eines braucht und wie Sie tatsächlich eines schreiben, das Ihr Team in den Mittelpunkt stellt Sehr wichtiges Zeug hier. Okay, was ist ein Sprintziel? Dies ist ein einziger, aber prägnanter Satz über das Ergebnis eines Sprints Es ist ein Satz, der beschreibt, was Ihr Team in diesem speziellen Sprint zu erreichen versucht Nicht welche Arbeit du machen wirst. Es ist das Ergebnis, das du willst. Das Sprintziel ist die Antwort auf die Frage. Was am Ende dieses Sprints wahr sein wird , war zu Beginn nicht wahr. Das ist also keine Liste oder ein Meilenstein. Das ist eine echte und bedeutsame Veränderung. Warum sind sie wichtig? Wir haben also drei Hauptgründe, warum jeder Sprint Sprintziele benötigt . Diese Ziele sind also sehr wichtig, auch wenn viele Teams sie überspringen. Erstens konzentrieren sie das Team. Ohne ein Ziel sieht jede Geschichte im Sprint-Backlog gleich wichtig Wenn du ein Ziel hast, kannst du sehen, welche Geschichten es tatsächlich voranbringen und welche nur wie Nebenquests sind Zweitens helfen sie dir, mitten im Sprint Entscheidungen zu treffen. Dinge ändern sich immer. Ohne ein Ziel wird jede Änderung zu einer Debatte mit Ihrem Team. ein Ziel haben, fragen Sie, hilft uns diese Änderung, das Ziel zu erreichen? Falls ja, machst du es, wenn nein, bis zum nächsten Sprint oder du machst es überhaupt nicht. Und der dritte Grund , warum sie ein gemeinsames Zielbewusstsein schaffen. Menschen arbeiten härter und besser , wenn sie verstehen, warum. Ein Sprint-Backlog ohne Ziel ist nur eine Aufgabenliste. Ein Sprintziel mit einem Backlog, der es unterstützt, ist wie eine Hauptaufgabe Was macht also ein gutes Sprintziel aus? Wir haben vier Eigenschaften, die alle wichtig sind. Erstens ist ergebnisorientiert. Beschreibt, was sich ändert, nicht, was Sie erstellen werden. Das Versenden der Login-Funktion ist also eine Aufgabe. wiederkehrende Benutzer auf ihre Bestellhistorie zugreifen können Ergebnis ist, dass wiederkehrende Benutzer auf ihre Bestellhistorie zugreifen können. Um genau zu sein, es ist spezifisch genug, um zu wissen, dass Sie es getroffen haben. Vage Ziele wie die Verbesserung der App helfen niemandem. Viel zu vage. Sie können jedoch die Kundenbindung am zweiten Tag erhöhen, indem Sie das Onboarding vereinfachen Sie sind etwas, auf das man tatsächlich zielen kann. Dritter ist erreichbar. Es ist im Sprint erreichbar. Wenn dein Ziel drei Monate dauern würde, dann ist es kein Sprintziel Es ist wie das Release-Ziel. Beschränken Sie es, damit es erreichbar ist. Und die vierte ist, dass es eine einzige Sache ist. Ein Ziel pro Sprint, keine Ausnahmen. Wenn Sie drei Ziele haben, haben Sie eigentlich kein Ziel, weil keines davon Priorität hat. So wichtig, dass du nur ein Ziel pro Sprint hast. Lassen Sie mich Ihnen also zeigen, wie ein gutes Sprintziel für jedes Briefing für Edtech aussieht Am Ende dieses Sprints können 6-jährige Lernende nach Abschluss des Unterrichts Sterne sammeln und sehen Das ist spezifisch, ergebnisorientiert und innerhalb von zwei Wochen realisierbar Beachten Sie, dass es nichts über die Funktionen aussagt , die Sie erstellen werden Die Geschichten im Sprint-Backlog beantworten das. den E-Commerce betrifft, so sind am Ende des Sprints unsere drei besten neuen umweltfreundlichen Produkte auf der Website online , mit vollständigen Beschreibungen, Fotos und Preisen Auch hier handelt es sich um ein klares Ergebnis, das beim und für das Veranstaltungsprojekt leicht überprüfbar ist . Am Ende des Sprints sind alle fünf Hauptredner mit gebuchten Reisen und Unterkünften bestätigt Sie haben ein konkretes und messbares Ergebnis. Wenn Sie also das Muster hier erkennen, beginnt jedes Ziel mit dem Ende dieses Sprints und beschreibt dann eine reale und beobachtbare Veränderung in der Welt Nun, wo legst du es hin? Also der praktische Teil: Schreib dein Sprintziel ganz oben in deine Trello-Beschreibung oder hefte es als Karte ganz oben auf deine To-Do-Liste Stellen Sie es einfach ganz oben auf Ihre Sprint-Planungsseite, wie ich es Ihnen bereits gezeigt habe Das gesamte Team sollte es ständig sehen Wenn es versteckt ist, könnte es genauso gut nicht existieren. Okay, das ist also das Ende dieser Lektion. Sprintziele. Ein richtig durchdachter Satz kann einen Sprint verändern. Es ist also sehr, sehr wichtig, dass du die ganze Zeit klare und präzise Sprints schreibst Als Nächstes führen wir das Sprint-Planungstreffen durch. Also ein zweistündiger Sprint mit fünf Schritten, einer Vorlage und das ist als Nächstes dran. Also sehe ich dich dann. 22. Durchführen eines Sprintplanungsmeetings (mit Vorlage): Mm hmm. Willkommen zurück. Inzwischen haben Sie also Ihren Backlog priorisiert Sie haben Ihr Sprintziel geschätzt, Sie haben über Ihr Sprintziel nachgedacht. Jetzt ist es an der Zeit, all diese Dinge in einem Sprint-Planungstreffen zusammenzubringen . Am Ende dieser Lektion werden Sie genau wissen, wie ein Meeting durchgeführt wird, und Sie haben eine Vorlage, die Sie für jeden Sprint immer wieder verwenden können . Also zunächst, was ist Sprintplanung? Dies ist mit Abstand das wichtigste Treffen des Sprints. Sie haben es zu Beginn jedes Sprints, da hier das Team entscheidet, woran es in den nächsten zwei Wochen arbeiten wird. Alles, was auf dieses Treffen folgt, hängt von den Entscheidungen ab , die Sie hier treffen. extrem wichtig. Die klassische Anleitung hier ist also, es zeitlich begrenzt zu halten. 2 Stunden für einen zweiwöchigen Sprint sind der Standard. Wenn es länger dauert, planen Sie wahrscheinlich ein wenig zu viel. Es wurde ein Sprintziel vereinbart, und wir haben fünf Schritte auf der Agenda. Es gibt also zwei Fragen, die jede Sprint-Planung in dieser Reihenfolge beantworten sollte. Frage eins: Was ist das Ziel dieses Sprints? Und hier vereinbaren Sie das Sprintziel, das wir in der vorherigen Lektion behandelt haben. Nun, der Product Owner hier würde es normalerweise vorschlagen, und dann wird das gesamte Team darüber diskutieren und sich dann der zweiten Frage stellen: Mit welcher Arbeit werden wir dieses Ziel erreichen? Das heißt, du ziehst Elemente aus deinem Backlog und verschiebst sie in die Aufgabenliste von Trello Und du bringst nur die Elemente voran, die das Ziel voranbringen. Also sei hier skrupellos Alles, was das Ziel nicht direkt unterstützt, sollte für den nächsten Sprint im Backlog bleiben Und das ist alles. Das Treffen beantwortet diese beiden Fragen und endet. Alles andere wäre eine Ablenkung. Schauen wir uns also die Fünf-Schritte-Agenda an, die Sie für jeden Sprint verwenden sollten Sie können dies immer wieder verwenden. Es sind fünf sehr einfache Schritte. Schritt eins besteht darin, das Sprintziel zu überprüfen Nehmen Sie sich dafür etwa fünf bis zehn Minuten Zeit. Der Product Owner schlägt ein Ziel vor, und dann bespricht das Team es, und Sie sind sich alle einig. Schritt zwei besteht darin, die Kapazität des Teams zu überprüfen. Es dauert also ungefähr 5 Minuten. Sei ehrlich darüber, wie viel Team er tatsächlich hat. Wenn es also Feiertage oder Krankheitstage, Besprechungen oder andere Verpflichtungen gibt, sollten Sie niemals so planen, als ob alle zu 100% arbeiten würden , weil das nie der Fall ist. Die meisten Teams planen normalerweise eine Kapazität von etwa 70 bis 80% Schritt drei besteht darin, Geschichten aus dem Backlog auszuwählen. Dies sollte zwischen einer halben und einer Stunde dauern. Sie können jedes Ihrer priorisierten Backlog-Elemente durchgehen Ihrer priorisierten Backlog-Elemente Du fragst dich bei jeder Story, ob dadurch das Sprintziel erreicht wird Falls ja, können wir es unseren Kapazitäten entsprechend anpassen? Wenn Sie können, dann nehmen Sie es zu tun und hören auf, wenn Sie Ihre Kapazität erreicht haben. Schritt vier besteht darin, den Plan zu überprüfen Nehmen Sie sich etwa zehn bis 15 Minuten Zeit. Treten Sie also zurück. Funktioniert das Sie ausgewählt haben? Erreicht es tatsächlich das Ziel? Wenn nicht, solltest du ein paar Geschichten austauschen. Gibt es offensichtliche Abhängigkeiten? Bringen Sie sie jetzt zum Vorschein, nicht am fünften Tag. Und dann ist Schritt fünf: Bestätigen und bestätigen. Alle sind sich einig, dauert ungefähr 5 Minuten. Das ganze Team sagt ja. Das ist es, was wir tun. Jeder verlässt den Raum, kennt das Ziel, weiß genau, woran er arbeiten muss, und weiß, welche Rolle er bei dieser Arbeit spielt. Schauen wir uns also einige häufig vorkommende Fallen an. Dies sind vier Fallen, in die Teams bei der Planung immer wieder tappen. Versuche, diese zu vermeiden Das erste ist also, sich zu sehr zu engagieren. Das Team fühlt sich unter Druck gesetzt, mehr zu tun, weshalb es zu viele Geschichten in den Bereich „Aufgaben“ schreibt und dann nicht liefert Als Nächstes überwinden sie es im nächsten Sprint erneut , um es wieder wettzumachen, was ein Teufelskreis ist Es ist also besser, sich weniger zu verpflichten und dann konsistent zu liefern Die zweite Falle ist perfekte Planung. Die Planung eines Sprints ist ein Arbeitstreffen, kein Verhör Wenn Sie 15 Minuten damit verbringen, über den genauen Wortlaut eines Akzeptanzkriteriums zu debattieren , dann sind Sie im Das wäre Raffinesse und keine Planung. Also mach weiter. Falle drei ist das Überspringen des Ziels wir nehmen einfach die Gegenstände auf und machen weiter. Nein, nein, nein, nein. Ohne ein Ziel ist der Sprint nur eine Aufgabenliste. Das Ziel ist es also, was einen Sprint zu einem Sprint macht. Und die vierte Falle ist isoliertes Planen. Der Product Owner sollte den Plan nicht schreiben und dem Team vorlegen . Das Team muss gemeinsam planen. Sie verpflichten sich gemeinsam. Diese gemeinsame Eigentümerschaft ist der springende Punkt. Und auch hier ist agiles Management darauf angewiesen, Menschen selbst Verantwortung für ihre eigene Arbeit übernehmen. Jetzt die Vorlage. Öffnen Sie also Ihre Sprint-Planungsdatenbank und erstellen Sie einen neuen Eintrag, eine neue Seite. Füllen Sie diese Abschnitte für jeden Sprint aus. Also dein erster Abschnitt , den du verwenden kannst, Überschrift drei oder Überschrift zwei, Sprintnummer und Datumsbereich nur zur Nachverfolgung. Abschnitt zwei wäre das Sprintziel, das nur aus einem Satz besteht. Denken Sie daran, sich auf das Ergebnis zu konzentrieren. Abschnitt drei ist Kapazität. Also keine Krankheitstage, keine Feiertage oder bekannte Zeitverpflichtungen, die Gesamtzahl der verfügbaren Stunden oder Tage für das Team. Abschnitt vier ausgewählte Geschichten, bezahlt die Trello-Kartenlinks für alles, was Sie sich verpflichten, mit den Kostenvoranschlägen, sofern Sie diese haben Abschnitt fünf befasst sich mit den Risiken und Abhängigkeiten. Also irgendwas, das das Team daran hindern könnte externe Gewichte, irgendwelche Unbekannten, irgendwelche Abhängigkeiten von anderen Teams oder Anbietern zu Und dann wäre Abschnitt sechs die Verpflichtung. Also nur eine Zeile, die besagt: Ja, wir verpflichten uns zu diesem Plan mit dem Datum. Klingt vielleicht unnötig, macht aber einen echten Unterschied. Das Aufschreiben schafft Rechenschaftspflicht. Also ja, hier ist deine Vorlage. Speichern Sie dies in Notion , sodass Sie es jedes Mal verwenden können, wenn Sie einen neuen Sprintplanungseintrag erstellen. 5 Minuten Einrichtungszeit, wodurch Sie später viele, viele Minuten und wahrscheinlich Stunden sparen später viele, viele Minuten werden. Wenn Sie jetzt alleine arbeiten, gilt die Disziplin immer noch. Wenn Sie kein Team haben, mit dem Sie planen können, ist das in Ordnung. Leiten Sie das Meeting selbst, blockieren Sie 30 Minuten, gehen Sie die fünf Schritte durch, sprechen Sie laut, wenn es Ihnen hilft. Es mag albern klingen, aber es hilft. Es funktioniert. Das Ziel der Einzelplanung ist dasselbe. Sie sind sich einig, was Sie tun, warum und wie viel. Die Disziplin, es aufzuschreiben, gilt immer noch, und in Zukunft werden Sie es Ihnen danken. Das ist also Sprintplanung für zwei Fragen, fünf Schritte, eine Vorlage. Im nächsten Abschnitt werden wir uns das Sprint-Backlog in Trello ansehen das Sprint-Backlog in Trello Wir schauen uns an, wie Sie Ihr Sprint-Board für die bevorstehende Arbeit einrichten , die als Nächstes im nächsten Video behandelt wird. Wir sehen uns dann. 23. Erstellen Sie Ihr Sprint-Backlog in Trello: Willkommen zurück. Inzwischen hast du deinen Sprint geplant. Lass es uns tatsächlich auf deinem Trello einrichten. In dieser Lektion werde ich dir genau erklären, was in welcher Reihenfolge zu tun Am Ende haben Sie also einen Sprint-Backlog, der einsatzbereit ist. Zuallererst: Produkt-Backlog versus Sprint-Backlog. Es ist wichtig, dass wir diese beiden nicht verwechseln. Deshalb ist es wichtig, dass wir schnell unterscheiden. In Agile gibt es tatsächlich zwei Backlogs, obwohl wir nur das Wort Backlog sagen, der Produkt-Backlog ist alles, was jemals gebaut werden könnte Es befindet sich also in deiner Backlog-Liste auf Trello. Wir haben das in Abschnitt drei erstellt. Das wäre alles, was Sie zum Ausfüllen benötigen. Ihr Projekt. Der Sprint-Backlog ist eine viel kleinere Teilmenge, der Sie sich in diesem Sprint verpflichtet haben Es befindet sich in Ihren Listen mit Aufgaben, Aufgaben und Erledigtem . Es ist eine Momentaufnahme eines Sprints. Der Aufbau Ihres Sprint-Backlogs bedeutet also nicht, neue Karten zu erstellen. Es geht darum, die richtigen Karten aus dem Produkt-Backlog in die Aufgabenliste zu verschieben dem Produkt-Backlog in die Aufgabenliste zu Schritt eins besteht also darin, das Sprintziel hinzuzufügen, das an die immer sichtbare Stelle angeheftet ist , eine neue Karte zu erstellen, Ihr Sprintziel ganz oben auf Ihre Aufgabenliste zu setzen, es also nach oben zu ziehen In Trello kannst du auf Karte hinzufügen klicken, sie an den Anfang deiner Aufgabenliste verschieben, eine Karte mit dem Namen Sprintziel erstellen, dein Ziel aus einem Satz in den Titel einfügen, ein farbiges Etikett hinzufügen, etwas, das unverwechselbar ist, sodass es sich von den normalen Story-Karten abhebt. Du könntest zum Beispiel eine leuchtend orange Karte mit dem Namen Ziel oder vielleicht eine schwarze Manche Leute ziehen es vor, das Sprintziel stattdessen in die Beschreibung des Boards aufzunehmen, was in Ordnung ist. Einer von ihnen funktioniert. Das Wichtigste ist, dass es sichtbar ist. Schritt zwei besteht darin, die Geschichten in To Do zu übertragen. höchste Priorität an der Spitze. Denken Sie daran, Sie ziehen sie aus Ihrem Backlog. All die Geschichten, auf die Sie sich bei Ihrer Sprint-Planung festgelegt haben, werden Sie also verschieben. Gehen Sie also zu Ihrer Backlog-Liste, suchen Sie jede Karte, zu der Sie sich verpflichtet haben, und ziehen Sie sie aus dem Backlog in die Aufgabenliste Die Reihenfolge, in der Sie sie platzieren, ist wichtig Stellen Sie Ihre höchste Priorität an die Wenn also jemand eine Karte fertig hat und die nächste abholen muss, liegt die Wahl auf der Hand. Bringen Sie nicht alles mit ein , wozu Sie sich verpflichtet haben. Der Rest bleibt für den zukünftigen Sprint im Backlog. Schritt drei besteht darin, die Kartendetails zu aktualisieren, und Sie könnten vielleicht auch eine Verbindung zu Notion und Trello herstellen Schritt drei: Öffne jede Karte auf deiner To-Do-Liste und überprüfe alle Details Hat es eine richtige User Story im Titel? Enthält die Beschreibung einen zusätzlichen Kontext, den das Team benötigt, oder enthält sie die Akzeptanzkriterien in der Checkliste Wenn Sie Schätzungen hinzugefügt haben, sind diese irgendwo entweder als Etikett oder wie in der Kartenbeschreibung aufgezeichnet? als Etikett oder wie in der Kartenbeschreibung Das ist also Ihre letzte Gelegenheit, eine Plausibilitätsprüfung durchzuführen und zu verfeinern, bevor mit der Arbeit begonnen wird Also überspringe diesen Teil nicht. Eine Karte mit schwachen Akzeptanzkriterien wird später zu einem Argument und ist nur ein Beispiel für schlechte Planung. Schritt vier besteht darin, Ihre Etiketten anzubringen, falls Sie dies noch nicht getan haben. also noch einmal daran, dass wir uns in den vorherigen Abschnitten mit den T-Shirt-Größen in Moskau befasst haben . Bringen Sie Ihre Etiketten zur besseren Sichtbarkeit an, fügen Sie Moskauer Etiketten hinzu, wenn Sie sie verwenden, müssen, sollten und könnten. Wenn Sie eine Schätzung vorgenommen haben, könnten Sie auch die T-Shirt-Größen SML oder L oder die Story-Point-Etiketten zwei, drei, fünf und acht hinzufügen SML oder L oder die Story-Point-Etiketten zwei, , wenn Sie die Fibonacci-Sequenz Diese Beschriftungen bedeuten, dass Sie schon auf einen Blick erkennen können, wie der Sprint aussieht Wenn es viele Most-Etiketten und große Formate gibt , haben Sie zu viel gebunden, wenn Sie viele kleine Karten haben, dann haben Sie vielleicht etwas mehr Kapazität Schritt fünf: Machen Sie sofort vor Beginn der Arbeit einen Screenshot Ihres Sprint-Backlogs und speichern Sie ihn irgendwo Die besten Orte in Notion. Und warum? Weil Sie am Ende des Sprints das, wozu Sie sich verpflichtet haben, mit dem vergleichen möchten , was Sie tatsächlich erreicht haben. Der Screenshot macht diesen Vergleich sehr einfach. Es ist auch ein großartiges Portfolio-Artefakt. Das haben wir geplant, und hier ist, was wir versendet haben. Oh, sehr wichtig. Also das war's für diesen Abschnitt. Als nächstes steht die Übungsübung an. Du planst deinen ersten Sprint jetzt, da du dein Gold an der Spitze hast und du eine Reihe von Geschichten mit Labels zur besseren Sichtbarkeit und auch den Screenshot hast. Wir sind jetzt bereit, alles zusammenzustellen und Abschnitt vier abzuschließen . Ich werde dich also im letzten Video von Abschnitt vier sehen. 24. Übung: Planen Sie Ihren ersten Sprint: Hallo und willkommen zurück. Zeit , alles zusammenzustellen. In dieser Übung planen Sie Ihren ersten Sprint für das von Ihnen gewählte Briefing von Anfang bis Ende. Wenn du fertig bist, hast du ein Sprintziel, einen geschätzten und priorisierten Backlog und einen festen Sprint-Backlog in Trello sowie ein Sprint-Planungsdokument Trello sowie ein Sprint-Planungsdokument Und das wäre ein vollständiger Sprint-Plan, und Sie sind bereit, ihn in der nächsten Lektion auszuführen Also zunächst fünf Schritte. Also das Ende bis zum Ende sollte ungefähr 45 Minuten dauern. Es könnte weniger dauern. Vielleicht hast du schon einige davon gemacht. Der erste Schritt wäre also, Ihre zehn wichtigsten Backlog-Einträge anhand von Moskau zu priorisieren und Ihre Labels hinzuzufügen Schritt zwei ist die Schätzung anhand T-Shirt-Größen oder der Story Points, je nachdem, welche Variante Schritt drei wäre, dein Sprintziel mit einem kurzen und ergebnisorientierten Satz zu formulieren Schritt vier besteht darin, alle Geschichten, die das Ziel voranbringen, in Ihre Aufgabenliste auf Trello aufzunehmen und sich auf einen realistischen Betrag festzulegen Und der letzte Schritt besteht darin, Ihre Vorlage für die Sprint-Planung in Motion auszufüllen Ihre Vorlage für die Sprint-Planung in Motion Überspringen Sie das nicht. Das ist das Artefakt, das beweist, dass Sie die Arbeit gemacht haben also lassen Sie uns kurz durchgehen, was gut aussieht Hier ist ein funktionierendes Beispiel aus einem Brief von Ed Tech, damit Sie wissen, was Sie anstreben Sprintziel Am Ende dieses Sprints können 6-jährige Lernende nach Abschluss jeder Lektion Sterne sehen nach Abschluss jeder Lektion Sterne Die Aufgabenliste enthält vier Geschichten. der ersten Geschichte sehen die Lernenden nach Abschluss der Lektion eine Animation Geschichte zwei: Sterne werden im Profil des Lernenden gespeichert. Geschichte drei werden Sterne auf dem Startbildschirm angezeigt, und in Geschichte vier können Eltern sehen, wie viele Sterne ihr Kind in dieser Woche verdient hat Alle vier Punkte bringen das Ziel voran. Alle vier zusammen sind ungefähr zwei Wochen Arbeit, und die Kapazität ist ehrlich. Das Ziel ist sehr spezifisch und die Geschichten unterstützen es. So sieht also gut aus. Und es gibt auch einige Plausibilitätsprüfungen, die Sie durchführen können, bevor Sie alles als erledigt bezeichnen Also diese drei Fragen, die ich stellen muss, die erste wenn ich alle Geschichten auf meiner To-Do-Liste geliefert hätte, hätte ich mein Sprintziel erreicht? Falls nein, hast du die falschen Geschichten oder du hast das falsche Ziel. Nummer zwei ist, war ich ehrlich, was meine Fähigkeiten angeht, oder mache ich mir etwas vor Es ist besser, sich auf weniger festzulegen und zu viel zu liefern, als zu viel zu verpflichten und die Leute im Stich zu lassen Denken Sie daran, das ist der Schlüssel. Und drittens, versteht jemand von außen der auf mein Trello-Board schaut , der auf mein Trello-Board schaut, diesen Sprint in 30 Sekunden Wenn die Antwort nein ist, ist dein Ziel nicht sichtbar genug oder es ist nicht klar genug Fehler, die es in dieser Phase zu vermeiden gilt. Der erste ist das Überspringen des Ziels. Das Ziel überspringen, weil Geschichten für sich selbst sprechen. Nein, tun sie nicht, tun sie nicht. Ohne ein Tor weiß man nicht, wann man gewinnt. Überspringe also niemals das Tor. Zweitens, jedes Muss in die To-Do-Liste aufzunehmen, ohne an die Kapazität zu denken, ist ein Nein. Nur weil etwas ein Muss ist, heißt das nicht , dass es in diesem Sprint erledigt werden muss. Manchmal muss ein Muss auf die Zukunft warten. Und drittens: Wenn der Sprint zu 100% ausgelastet ist, bleibt immer Raum für Unerwartetes. Echte Sprints verlaufen kaum nach Plan. Also noch etwas, an das man sich erinnern da es nie zu 100% gefüllt wurde. Und damit sind wir am Ende von Abschnitt vier angelangt, also hervorragende Arbeit, dass Sie bis jetzt bei mir geblieben sind. In Abschnitt fünf werden wir uns den Vor- und Nachteilen des Sprints befassen. Wir werden uns Stand-ups, Kritiken, Retros und die Arbeit selbst Gut gemacht, dass Sie das Ende von Abschnitt vier erreicht Wir sehen uns in Abschnitt fünf 25. Sprint durchführen: Der tägliche Stand-Up: Format, Timing und häufige Fallstricke: Willkommen im fünften Abschnitt unseres Projektmanagement-Kurses. Bis jetzt haben Sie Ihren Sprint geplant . Jetzt beginnt die Arbeit. In dieser Lektion werden wir uns der bekanntesten Agile-Zeremonie befassen, die als Daily Stand Up bezeichnet wird. Am Ende dieses Abschnitts wirst du also wissen, wie du eine in 15 Minuten durchführst, was du sagen musst, was du vermeiden solltest und warum so viele Teams es falsch machen. Was ist also ein Stand? Das ist ein kurzer täglicher Team-Untergang. Das ist kein Statusbericht. Es sind normalerweise etwa 15 Minuten. Normalerweise hast du es an jedem Tag des Sprints zur gleichen Zeit, am selben Ort. Und der Name stammt von der ursprünglichen Idee, dass jeder buchstäblich aufsteht, weil Stehen das Treffen kurz hält. Setz dich und du redest eine Stunde lang. Es ist also kein Statusbericht. Es ist kein Meeting, bei dem der Chef nach Leuten schaut. Es ist ein schneller Abstecher, bei dem sich das Team darauf konzentriert, was passiert Zeigt alle Probleme an und die Gerste laufen, falls erforderlich. Also die drei wichtigsten Fragen, jede Person beantwortet diese Fragen nacheinander innerhalb von jeweils etwa 60 Sekunden Dies ist das klassische Format. Also spricht jede Person nacheinander. Frage eins ist, was habe ich gestern gemacht? Eine kurze Zusammenfassung Ihrer Fortschritte. Zweitens, was werde ich heute tun, was lernst du? Drei blockiert mich. Wenn es also Hindernisse oder Fragen oder Abhängigkeiten gibt , wird das dort behandelt. Und jede Person sollte alle drei in etwa 60 Sekunden beantworten . Bei einem fünfköpfigen Team sind das 5 Minuten. Und die verbleibenden 10 Minuten sind für die eigentlichen Gespräche vorgesehen, die Dinge, die aufgrund dessen, was die Leute gerade gesagt haben, zur Sprache kommen, und darin liegt der wahre Wert dieser Treffen. Die neueren Leitlinien aus dem Scrum-Leitfaden konzentrieren sich also weniger auf die drei Fragen als vielmehr auf das Ziel Wie können wir als Team heute die meisten Fortschritte in Richtung des Sprintziels machen Beide Ansätze funktionieren. Die drei Fragen sind einfacher , wenn Sie anfangen. Sie können im Laufe der Zeit Ihren eigenen Ansatz entwickeln Als Nächstes haben wir das Timing und die Logistik. Hier sind einige praktische Dinge , mit denen Stand-ups funktionieren. Also zuerst, nimm dir maximal 15 Minuten Zeit , stelle einen Timer ein, wenn er erlischt, du hörst auf, auch wenn es mitten im Satz ist Der Druck des Timers zwingt dich zu Disziplin. Du solltest es jeden Tag zur gleichen Zeit einnehmen. Wählen Sie eine Zeit, die für alle funktioniert. Üblich ist 9:30 Uhr oder 10:00 Uhr, weil die Frühstarter dann Zeit haben, sich einzugewöhnen , ohne den Morgen zu verlieren Und legen Sie es nicht auf 16:00 Uhr. Bis dahin ist der größte Teil des Tages vorbei Es sollte sich am selben Ort befinden, egal ob physisch oder virtuell Ein vorhersehbarer Standort ist sehr wichtig Die meisten Remote-Teams nutzen normalerweise einen täglichen Videoanruf. Persönlich sollten Sie sich alle rund um das Cambanbard versammeln Oder für die Fernsteuerung, lass wenigstens deine Kameras Die Energie ist auf diese Weise etwas anders und die Leute bleiben konzentriert, wenn sie aufstehen. Am Ende geht es also darum, durch den Vorstand zu gehen, nicht durch die Leute. Das ist eine subtile, aber wichtige Veränderung. Anstatt im Team herumzugehen, wie Sarah es als Nächstes macht, dann James, gehen Sie die Karten in den Listen „Aufgaben“ und „Erledigt“ durch . Und für jede Karte spricht die Person, die an der jeweiligen Karte arbeitet. Und so bleibt der Fokus auf der Arbeit, nicht auf den einzelnen Personen. Einige gängige Fallen, einige vier Arten , wie Stand-Ups schief gehen, vermeiden Sie Vermeiden Sie es, daraus einen Statusbericht zu machen. Leute sprechen mit dem Manager oder dem Projektleiter und listen detailliert auf, was sie getan haben. Das ist das falsche Publikum. Das ist für das Team, nicht für den Chef. Sprich mit deinen Kollegen. Die zweite Falle ist die Problemlösung in der Besprechung. In diesem Meeting löst man keine Blockaden. Wenn jemand einen Blocker erwähnt, speichern wir das für einen späteren Zeitpunkt Das Team beginnt mit der Ideenfindung und 20 Minuten später sind Sie immer noch da und 20 Minuten später sind Sie immer noch da. Also tu das nicht Es geht darum, Probleme aufzudecken, nicht sie zu lösen. Falle drei: Die Besprechung auslassen, wenn viel los ist. Wenn wir heute zu beschäftigt sind, um den Stand Up zu machen, ist das genau der Zeitpunkt, an dem Sie es am dringendsten brauchen Vielbeschäftigte Teams sind normalerweise beschäftigt, weil sie sich nicht gut genug koordinieren Den Stand Up zu überspringen macht das nur noch schlimmer. Es ist wie ein Teufelskreis Lassen Sie diesen täglichen Stand Up also nicht aus. Und schließlich wird Trap Four abgesagt, wenn Leute in der Ferne sind Lass uns jetzt einfach Updates in Slack posten. Ich meine, das ist für einen Tag in Ordnung, aber du machst es an jedem Tag der Woche, dann verliert das Team seinen gemeinsamen Sinn für den Sprint, und der Sinn des Meetings ist die Live-Koordination, nicht das schriftliche Update Wenn Sie das also alleine machen, finden Sie hier einige Anpassungen, die Sie für Soloprojekte vornehmen können. Alleinstehende profitieren immer noch von einem täglichen Check-in. Nehmen Sie sich jeden Morgen 5 Minuten Zeit, um Trello zu öffnen, schauen Sie sich Ihr Board an und fragen Sie sich, was ich gestern gemacht habe Was werde ich heute tun? Was blockiert mich? Schreiben Sie es irgendwo auf, auch nur in einem kurzen Notion-Eintrag, das ist in Ordnung. Es mag lächerlich klingen, mit dir selbst zu reden, aber der Akt, es zu artikulieren , bringt Probleme zum Vorschein, die du sonst ignorieren würdest Probieren Sie es also mindestens eine Woche lang aus und Sie werden sehen, wie es ist. Als Nächstes müssen wir also die Arbeit visualisieren und erledigen Der Ablauf mit drei Spalten , den wir in Trello eingerichtet haben. Darauf werden wir im nächsten Video näher eingehen. 26. Visualisierung der Arbeit: Erledigen, Erledigen, Erledigt: Hallo und willkommen zurück. Die einfachste und mächtigste Agile-Idee, der Sie jemals begegnen werden, ist diese. Machen Sie die Arbeit sichtbar. In dieser kurzen Lektion behandeln wir den Ablauf mit drei Spalten, jedes Agile-Board bestimmt, und wie man ihn sinnvoll einsetzt. Warum also visualisieren? Hier sind drei Gründe, die die Visualisierung so leistungsfähig machen. Erstens: Sie können nicht verwalten, was Sie nicht sehen können. Wenn Arbeit in den Köpfen der Menschen oder in E-Mail-Threads lebt , ist sie unsichtbar. Man weiß nicht, wo Dinge feststecken, was überlastet ist, wer überlastet ist oder was zwei sind, das schafft ein gemeinsames Bewusstsein Das gesamte Team kann dasselbe Bild sehen. Nicht mehr. Ich wusste nicht, dass du das tust. Ich wusste nicht, dass du daran arbeitest. Jeder weiß, woran jeder arbeitet. Drittens, es behebt alle Strömungsprobleme. Wenn Sie also die gesamte Arbeit an einem Ort sehen können , springen Muster hervor, Karten häufen sich beim Durchführen, Karten bleiben in der Überprüfung stecken, lange Verzögerungen zwischen den Listen Jedes Muster weist auf etwas hin, das repariert werden muss. Hier haben wir also die drei Listen zu erledigen, zu erledigen und zu erledigen. Auf jedem Agile-Board erledigen diese drei Listen die Schwerstarbeit. Zu tun ist die Arbeit für diesen Sprint, die aber noch nicht begonnen hat. Die Karten warten nur dort. Ganz oben auf der Liste steht das, was jemand als Nächstes abholen sollte. Tun ist Arbeit, die gerade aktiv erledigt wird. Darauf richtet sich die Aufmerksamkeit des Teams. Und entscheidend ist, dass Arbeit erst dann in Angriff genommen wird, wenn jemand in diesem Moment tatsächlich daran arbeitet. Nein, darauf komme ich heute später zurück. Sie machen es gerade. Erledigt ist Arbeit, die abgeschlossen ist, also Arbeit, die ordnungsgemäß abgeschlossen ist, nicht zu 90% erledigt, keine Überprüfung aussteht, sie ist erledigt. Es ist abgepackt Diese drei Listen nebeneinander geben Ihnen also in Echtzeit ein Bild davon, geben Ihnen also in Echtzeit ein Bild davon wie der Sprint voranschreitet Also, Grenzen für laufende Arbeiten. Dies ist ein wichtiger Tipp, den die meisten Anfänger möglicherweise verpassen. Bedeutet, zu begrenzen, wie viele Karten gleichzeitig gespielt werden können. Heute wird dies als Work-in-Progress-Limit oder WIP-Limit bezeichnet Work-in-Progress-Limit oder WIP-Limit Warum? Weil nichts den Fortschritt so ruiniert wie zu viele Dinge, die halb erledigt sind. Wenn fünf Personen drei Karten in Bearbeitung haben, haben Sie 15 Dinge gleichzeitig im Flug, und mit ziemlicher Sicherheit wird nichts wirklich fertig. Eine gute Faustregel hier ist also pro Teammitglied nicht mehr als eine Karte zu erledigen ist. Einige Teams verwenden N plus eins, sodass ein fünfköpfiges Team über sechs WIP-Slots verfügt Die genaue Anzahl ist weniger wichtig, wenn der Schulleiter die Dinge beendet hat, bevor er neue anfängt. Wenn Sie also alleine an Ihrem Projekt arbeiten, liegt Ihr WIP-Limit bei eins Wählen Sie eine Geschichte aus, arbeiten Sie daran, beenden Sie sie und wählen Sie dann die nächste Widerstehen Sie dem Drang, abzuprallen. Und wenn du einmal eine Tafel zum Laufen hast , lernst du, sie zu lesen Es gibt also drei wichtige Dinge , auf die Sie täglich achten müssen. Eines ist das Ungleichgewicht. Eine prall gefüllte Aufgabenliste bedeutet, dass zu viel Arbeit im Gange ist Eine leere Liste mit erledigten Aufgaben in der Mitte des Sprints bedeutet, dass noch nichts erledigt ist Zwei sind Karten, die sich seit Tagen nicht bewegt haben. Das sind festgeklemmte Karten. Finde heraus, warum sie feststecken. Normalerweise ist es ein Blocker, der nicht in einem täglichen Stand Up angesprochen wurde Drei sind deine Überraschungskarten, Dinge, die dabei auftauchen nicht Teil des ursprünglichen Sprintplans waren Das sind die stillen Killer jedes Sprintziels. Sie sie also ans Licht und entscheiden Sie, ob wir ihre wahren Prioritäten haben oder ob es sich tatsächlich um Ablenkungen handelt , die für später übrig bleiben sollten Oh, drei Spalten. Ein Arbeitsfortschrittslimit, Angewohnheit, die Tafel zu lesen, und das war's. Also danke, dass du an dieser Lektion teilgenommen hast. In der nächsten werden wir uns Umgang mit Veränderungen während des Sprints befassen, was ständig passiert. Das ist etwas, in dem jeder Agile-Projektmanager geübt sein muss. Wir gehen also auf drei Fragen ein , die das Ziel schützen, und das ist als Nächstes an der Reihe. Also wir sehen uns im nächsten Video. 27. Bearbeitung von Änderungen mitten im Sprint: Hallo und willkommen zurück. Nun, um ehrlich zu sein, läuft kein Sprint jemals wirklich nach Plan. Irgendwas ändert sich immer. In dieser Lektion werden wir uns also ansehen, wie Sie Änderungen in der Mitte des Sprints bewältigen können , ohne in Panik zu geraten, ohne den Fokus zu verlieren und vor allem, ohne Ihr ursprüngliches Sprintziel aufzugeben Das ist also etwas, an das man sich mit agilem Projektmanagement gewöhnen muss Veränderung ist kein Scheitern. Das ist völlig normal. jedem Sprint wird etwas auftauchen, das nicht im Plan war. Interessent könnte seine Meinung ändern, ein Benutzer könnte einen kritischen Fehler melden, vielleicht fällt eine Abhängigkeit weg, vielleicht ergibt sich eine neue Gelegenheit Nun begrüßt das Agi-Manifest ausdrücklich Veränderungen. Wenn Sie sich also an den vierten Wert des Manifests erinnern, geht es darum, auf Veränderungen zu reagieren, anstatt einem Plan zu folgen Nun, das heißt nicht, dass Veränderungen in der Mitte des Sprints immer gut oder immer akzeptabel sind Es bedeutet nur, dass Sie einen Prozess haben umgehen können, anstatt so zu tun, als ob es nicht passieren würde Dies ist für Projektmanager von entscheidender Bedeutung. werden wir einen kleinen Entscheidungsrahmen durchgehen. Nun, wenn eine Änderungsanfrage mitten im Sprint landet, ist dies ein einfaches Framework, das Sie verwenden können. Wir haben drei Fragen in der richtigen Reihenfolge. Frage eins ist, hilft uns diese Änderung, das Sprintziel zu erreichen? Falls ja, dann könnte es sich lohnen, es zu tun. Nun, nein, dann geht es in den Produkt-Backlog für einen zukünftigen Sprint. Frage zwei, es hilft, was müssten wir weglassen , um Platz dafür zu schaffen Die Kapazität ist immer begrenzt und man kann nicht einfach Arbeit hinzufügen, also muss man irgendwo einen Kompromiss eingehen Und die dritte Frage ist, ist Team auch der Meinung, dass sich der Tausch lohnt? Wenn das gesamte Team entscheidet, nicht nur der Product Owner, sind es am Ende des Tages sie, die die Arbeit machen. Wenn die Antwort auf alle drei Fragen Ja lautet, können Sie sie austauschen. Sie können es der Aufgabenliste hinzufügen. Wenn nein, sollten Sie es in den Backlog verschieben. Nun, die Disziplin, dieses Framework jedes Mal zu verwenden , ist das, was Ihr Sprintziel schützen wird Nun sind nicht alle Veränderungen gleich. Es gibt drei grobe Kategorien , die wir hier verwenden könnten: Notfälle. Zum Beispiel ist die Website ausgefallen, ein kritischer Bug trifft Benutzer oder ein Rechtsproblem ist gerade eingetroffen, und diese können es kaum erwarten Also lass etwas fallen und tausche es ein. Aber seien Sie ehrlich, echte Notfälle sind ziemlich selten. Wenn alles ein Notfall ist, dann ist nichts ein Notfall Als nächstes haben wir wichtige, aber nicht dringende. Also zum Beispiel eine Idee für ein neues Feature oder eine interessante Marktveränderung oder Anfrage von Stakeholdern, die wichtig aber nichts wirklich kaputt machen Diese können in den Produkt-Backlog aufgenommen werden, eine Karte hinzufügen und sie für den nächsten Sprint priorisieren. Stören Sie nicht und lassen Sie sich nicht ablenken, wenn jemand eine neue Idee hat. Das klingt toll , hat aber nichts mit dem Sprintziel zu tun. Nehmen Sie sie höflich in den Backlog auf und machen Die meisten Anfragen während des Sprints fallen in diese Kategorie. Nun, wie kann man nein sagen, das ist als Projektmanager ziemlich schwierig. Die Leute hassen es, nein zu hören, und Sie werden es hassen, es zu sagen. Hier sind also drei Techniken , die Ihnen helfen, keine Brücke zu verbrennen. Also man steht ja im Backlog. Sag also nicht nein zu der Idee selbst, sondern sage ja, sie festzuhalten. Das ist ein großartiger Punkt. Lassen Sie mich es dem Backlog hinzufügen damit wir es richtig priorisieren können Das wird die Idee bestätigen, ohne sich darauf festzulegen. Zweitens: Beziehen Sie sich auf den Frame ich sicherstellen möchte, dass wir unser Sprint-Ziel erreichen, nämlich X. Diese neue Anfrage unterstützt das nicht direkt Können wir uns das also beim nächsten Prints-Meeting ansehen? Das Ziel wird zum Grund, nicht Ihre persönliche Präferenz, und drittens ist offener Handel. Also, wir können das jetzt machen, aber es bedeutet, Y fallen zu lassen. Bist du damit einverstanden? Also muss der Antragsteller plötzlich die Kosten seiner Anfrage abwägen , nicht nur den Nutzen Und oft entscheiden sie , dass es auf später warten kann. Als Nächstes muss die Entscheidung dokumentiert werden. Was auch immer Sie entscheiden, schreiben Sie es auf, fügen Sie es zu Ihrer Datenbank für Denkentscheidungen hinzu, geben Sie das Datum an, was angefordert wurde, was wir entschieden haben und warum. das in 2 Minuten schreiben, sparen Sie sich Stunden warum wir das in späteren Besprechungen nicht getan haben. Denken Sie daran, dass sich etwas ändern wird. Das Wichtigste ist, das Sprintziel zu schützen und einen Rahmen zu schaffen und die Entscheidung auch zu dokumentieren. Als Nächstes werden wir uns also den Sprint-Bericht ansehen , der die tatsächliche Arbeit zeigt. An diesen Überprüfungen sind Interessengruppen beteiligt. Es beinhaltet Feedback und beinhaltet eine gewisse Ehrlichkeit. Also werden wir uns das im nächsten Video ansehen. 28. Der Sprint Review: Stakeholdern Echte Arbeit zeigen: Willkommen zurück. Der Sprint ist also vorbei. Jetzt ist es Zeit für die Stunde der Wahrheit, die deine Arbeit zeigt. In dieser Lektion werden wir uns mit dem Sprint-Review befassen, das auch als Sprint-Demo bezeichnet wird. Am Ende werden Sie wissen, wie Sie eines dieser Treffen abhalten, das Ihre Stakeholder tatsächlich informiert, anstatt nur für sie aufzutreten. Was ist also ein Sprint Review? Sprint-Review ist ein Treffen , das am Ende jedes Sprints stattfindet. Es ist unglaublich wichtig, da dies die Treffen sind , bei denen das Team den Stakeholdern die geleistete Arbeit zeigt . den Stakeholdern handelt es sich um die Personen, denen das Projekt wichtig ist, aber sie gehören zum Team . Das kann der Manager sein, es könnte ein Kunde Bei den Stakeholdern handelt es sich um die Personen, denen das Projekt wichtig ist, aber sie gehören zum Team. Das kann der Manager sein, es könnte ein Kunde sein, es könnten interne Sponsoren sein oder es könnten die tatsächlichen Nutzer sein. Normalerweise dauert ein zweiwöchiger Sprint eine Stunde , und diese Treffen haben zwei Zwecke. Zum einen soll demonstriert werden, was gebaut wurde um zu überprüfen, ob es den Erwartungen entspricht und ob es funktioniert. Zweitens geht es darum, Feedback zu sammeln, das als Grundlage den nächsten Produkt-Backlog und den nächsten Sprint dient Nun, das ist kein Statusbericht. Es ist ein Gespräch über tatsächliche Arbeitsleistung, die Ihr Team erzielt hat. Es gibt also drei Regeln, an die Sie sich halten sollten , wenn es darum geht, was Sie in diesen Besprechungen vorweisen sollten. Erstens: Sie zeigen die Arbeitsleistung, keine Folien über die Arbeitsleistung. Wenn Sie eine Funktion erstellen, demonstrieren die eigentliche Funktion auf einem echten Gerät oder einem Bildschirm und zeigen Sie, dass sie funktioniert. Erstellen Sie kein Deck mit 30 Folien, in dem Sie es beschreiben. Der Punkt hier ist , dass es tatsächlich funktioniert, also zeigen Sie, dass es funktioniert. zweite Möglichkeit besteht darin, alles mit dem ursprünglichen Sprintziel zu verknüpfen , mit dem Ziel zu beginnen, durchzugehen, wie jede einzelne Arbeit zu diesem Ziel beiträgt, und zum Schluss anzugeben, ob das Ziel erreicht wurde oder nicht. Und drittens: Zeigen Sie nur, was nach Ihrer Definition von erledigt erledigt wurde. Nicht das ist zu 80% behoben. Entschuldigung, das ist zu 80% abgeschlossen, oder wir müssen nur ein paar Dinge reparieren. Es muss eine wirklich abgeschlossene Arbeit sein, die zu 100% erledigt ist. Wenn es nicht fertig ist, lass es weg. Du kannst es im Abschnitt über das, was noch nicht fertig gestellt wurde, erwähnen , aber führe keine Vorführung von Dingen vor , die nicht vollständig sind. Jetzt solltest du eine 60-Minuten-Agenda haben, die du für jeden Sprint wiederverwenden kannst. Minuten null bis fünf sind also willkommen und fassen das Sprintziel zusammen, damit sich alle im Raum orientieren Minuten fünf bis 35 wären deine Demoversion für jede abgeschlossene Geschichte, fünf bis 7 Minuten pro Story. Zeige, wie sie funktioniert, erkläre den Kontext und stelle dann Fragen Minute 35 bis 45 ist das, was nicht fertig geworden ist. Seien Sie ehrlich darüber, was noch im Gange ist und warum das Vertrauen schafft und das Verstecken von Dingen es zerstört. Bei 45 bis 55 Uhr Feedback von Stakeholdern das Wort für Fragen offen Was denkt das Publikum? Was möchten sie als Nächstes, alle Daten erfassen, die Sie hören können, und nichts versprechen. Und dann würden die letzten 5 Minuten darin bestehen, die wichtigsten Rückmeldungen zusammenzufassen, Maßnahmen zu vereinbaren und das Ganze pünktlich zu beenden Gut mit Feedback umzugehen, das ist der Punkt, an dem die meisten Rezensenten falsch liegen Stakeholder geben Feedback. Das Team wird defensiv oder das Team akzeptiert jede Anfrage als Versprechen. Beides ist schlecht. Ein besserer Ansatz ist es, zuerst zuzuhören. Sei nicht defensiv. Verpflichten Sie sich nicht, hören Sie es nicht an, schreiben Sie es nicht auf eine sichtbare Tafel in Notion oder vor den Stakeholdern. Danke, dass du das aufgenommen hast. Das kannst du sagen. Entscheiden Sie nach dem Treffen mit dem Team, was mit den einzelnen Rückmeldungen geschehen soll. Einige Artikel werden zu neuen Backlog-Elementen. Einige verfeinern möglicherweise bestehende Geschichten. Das könnte interessant sein, aber nicht umsetzbar, was in Ordnung ist Mach einfach keine Versprechungen im Zimmer. Wir fügen hinzu, dass es beim nächsten Sprint eine Falle gibt, die Sie vermeiden sollten. Du weißt noch nicht, ob es Priorität haben sollte oder nicht, also versprich es nicht. Erfassen Sie die Anfrage und entscheiden Sie später, wann Sie planen. Wenn Sie also alleine an diesem Kurs arbeiten, benötigen Sie immer noch einen Stakeholder Also finde einen oder sei einer. Kann ein Freund sein, es könnte ein Kollege sein , es könnte ein Partner sein, jeder, der Geduld und Neugier für Sie und Ihr Projekt hat . Planen Sie einen 30-minütigen Termin ein, gehen Sie Ihr Sprintziel durch, Demo Ihrer fertigen Geschichten und stellen Sie die drei Fragen. Sieht das richtig aus? Was hat dich überrascht? Und was würdest du als Nächstes wollen? Selbst eine Person, die nichts miteinander zu tun hat , kann nützliches Feedback erhalten, nur weil sie ein neues Paar Augen Machen Sie sich also Notizen, dies ist eine richtige Agile-Praxis, jedoch auf einen Einzelanwender reduziert wurde Es sind also Sprint-Bewertungen, sie zeigen echte Arbeit Sie machen sich sein Feedback zunutze. Sie sollten niemals vor Ort etwas versprechen. Als Nächstes werden wir uns die Retrospektive ansehen, die dem Team die Chance bietet, nach innen zu schauen und Wir sehen uns beim nächsten Video . 29. Die Sprint-Retrospektive: "Start, Stop, Continue": Willkommen zurück. Der Sprint-Rückblick, den wir uns gerade angesehen haben, befasst sich also nach außen mit dem, was wir gebaut haben, während der Sprint-Rückblick nach innen schaut und In dieser Lektion gehen wir also auf das einfachste und beliebteste Format der Retrospektive ein, nämlich Start , Stopp und Fortfahren das einfachste und beliebteste Format der Retrospektive ein, nämlich Start , Stopp Start , Am Ende werden Sie also wissen, wie Sie eines dieser Besprechungen durchführen , das die Arbeitsweise Ihres Teams tatsächlich verändert Was ist also eine Retrospektive? Dabei handelt es sich um ein Treffen am Ende jedes Sprints, unmittelbar nach dem Review, dem das Team darüber nachdenkt , wie es während des Sprints zusammenarbeitet Sie sprechen nicht darüber, was sie gebaut haben. Sie haben darüber gesprochen, wie sie gearbeitet haben. Das sind also normalerweise 45 bis 60 Minuten wenn es sich um einen zweiwöchigen Sprint handelt. Nur das Team ohne Stakeholder. Dies ist also ein sicherer Ort, an dem das Team ehrlich darüber sprechen kann , was funktioniert und was nicht. Und das Prinzip dahinter stammt aus dem Prinzip 12 des Agilen Manifests, in dem es heißt, dass das Team in regelmäßigen Abständen darüber nachdenkt, wie es effektiver werden kann, dann sein Verhalten entsprechend Die Retrospektive zeigt, wie das in der Praxis passiert. Das einfachste retrospektive Format besteht also drei Säulen an einer Wand oder auf einer Starten, stoppen und weitermachen. Fangen Sie also an. Das sind Dinge, mit denen das Team anfangen sollte , die es jetzt nicht tut. Vielleicht fangen Sie an, Akzeptanzkriterien zu schreiben, bevor Sie die Schätzung oder beginnen Sie mitten im Sprint mit einem fünfminütigen Check-In . Stopp. Sind Dinge, mit denen das Team aufhören sollte, vielleicht aufhören sollte, Änderungen nach der Planung anzunehmen oder aufhören, Stand-ups abzuhalten wenn der Product Owner nicht anwesend sein kann, Dinge wie diese und dann weitermachen oder Dinge, die das Team gut macht und weiterhin tun sollte. Also vielleicht weiterhin mittwochs gemeinsam zu Mittag essen oder das Board weiterhin täglich aktualisieren, was auch immer das Team für gut hält und es ihnen gut geht So kann jede Person jeder Spalte Haftnotizen hinzufügen, und dann wird das Team darüber diskutieren Gruppen können ähnliche Themen auswählen und die wichtigsten auswählen, um sie im nächsten Sprint zu bearbeiten. Also, wie man diese Art von Besprechung durchführt. Hier ist ein fünfteiliges Programm für eine 45-minütige Retrospektive. Schritt eins besteht darin, die Szene auf etwa 5 Minuten einzustellen. Erinnern Sie das Team daran, wofür ein Retro gedacht ist, und richten Sie den Raum ein. Die Vagas-Regel besagt, dass das, was im Retro gesagt wird, im Retro bleibt Schritt zwei, stilles Schreiben. Also 10 Minuten, jeder schreibt seine Start-, Stopp- und Fortsetzungselemente unabhängig voneinander. Keine Diskussion. In dieser ruhigen Schreibsitzung kommen ehrliche Meinungen ohne Gruppe zum Vorschein. Schritt drei ist Teilen und Gruppieren. Das sollte also ungefähr 10 Minuten dauern. Jede Person liest ihre Artikel. Wir gruppieren ähnliche Artikel zusammen. Diskutieren Sie noch nicht darüber. Dies ist Teil des Treffens zur Kategorisierung. Schritt vier besteht darin, die wichtigsten Punkte zu besprechen Nehmen Sie sich dafür etwa 15 Minuten Zeit Sie können, sodass jede Person drei Punkte erhält, diese auf die wichtigsten Punkte kleben, wie bei einem Abstimmungsprozess. Und wenn Sie fertig sind, besprechen Sie die drei wichtigsten Punkte. Fünf bedeutet, Maßnahmen zu vereinbaren. also für jeden der wichtigsten Punkte Vereinbaren Sie also für jeden der wichtigsten Punkte konkrete Maßnahmen und legen Sie fest, wer was bis wann tun wird. Ansonsten wird Retro zu einer Therapie mit viel Gerede und ohne Veränderung. Also einigt euch auf diese Aktionen, wer, was und bis wann. Eine Retrospektive ist also nur dann sinnvoll, wenn die Menschen ehrlich sind, und die Menschen sind nur dann ehrlich, wenn sie sich sicher fühlen Drei Dinge helfen also. Erstens, keine Schuld. Die Kurth-Direktive besagt, dass wir unabhängig davon, was wir entdecken, verstehen und glauben fest daran, dass jeder die beste Arbeit geleistet hat, wenn man bedenkt, was er zu dem Zeitpunkt wusste Lesen Sie dies zu Beginn jeder Retrospektive laut vor , denn wird den Ton für das Team Zweitens sollte es keine Manager im Team geben. Wenn Sie einen direkten Vorgesetzten haben , der nicht im Team selbst ist, er nicht teil, weil Leute nicht ehrlich sein können, wenn das der Fall ist. Also ja, man kann nicht ehrlich sagen, wie Leute auf den Manager reagieren , wenn die Manager im Raum sind. Also keine Manager. Schließlich geht es darum, sich auf das System zu konzentrieren, nicht auf die Menschen. Warum ist das also passiert? Warum hat Sarah das getan? Dieses agile Prinzip besagt , dass gute Menschen in schlechten Systemen gefangen sein können Verbessern Sie also das System. Sie haben einige andere Formate zum Ausprobieren. Wenn sich Ihr Stop-Start also abgestanden anfühlt, können Sie ihn verwechseln. Also werden wir das im dritten und fortgeschritteneren Kurs richtig behandeln das im dritten und fortgeschritteneren Kurs Aber hier ist ein kurzer Vorgeschmack auf drei Alternativen. Wir sind wütend, traurig und froh. Die Leute schreiben also auf, was sie wütend, traurig oder froh gemacht hat , während dieser Sprint-Oberflächen in Bewegung geraten, sodass das Format Start, Stopp, Fortfahren oft flacher Wir haben die Vier gemocht, gelernt, gefehlt, ersehnt und reflektierter gemacht, vor allem bei großen vor allem bei Endlich ein Segelboot. Das Team ist ein Boot Welcher Wind hat uns vorwärts getrieben? Welche Anker haben uns zurückgehalten? Welche Felsen sollten wir meiden? Das ist ziemlich verspielt und visuell und eignet sich gut für verteilte Teams. Aber wir werden uns in Kurs drei eingehender damit befassen. Das ist es also. Rückblicke, kurz, sicherer Raum, handlungsorientiert. Die Teams, die sich am meisten verbessern, sind die Teams, die Retrospektiven gut machen In der nächsten Sitzung werden wir also eine Übungsübung machen, bei der Sie einen fünftägigen Mini-Sprint laufen und den Rhythmus eines Sprints von Ende zu Ende erleben Wir sehen uns beim letzten Video von Abschnitt fünf. 30. Übungsübung: Führen Sie einen Fünftagesprint durch: Willkommen zurück. Damit kommen wir nun zu der bisher ehrgeizigsten Übungsübung. Du wirst einen echten Sprint laufen. Wir werden es auf fünf Tage komprimieren, aber in jeder anderen Hinsicht ist es echt. Also planen, ausführen, überprüfen und nachholen. Am Ende wirst du einen kompletten Sprintzyklus hinter dir haben , und du wirst die Artefakte haben, um das zu beweisen. Lassen Sie uns also darauf eingehen. Zuallererst, warum ein Mini-Sprint. Standard-Sprints dauern normalerweise zwei Wochen. Für diese Übung komprimieren wir sie auf fünf Tage, Montag bis Freitag Wir tun das, weil der Sinn der Übung darin besteht, den Rhythmus einer Sprint-Planung, den täglichen Fortschritt, die Anpassungen in der Mitte des Sprints, die Überprüfung und den Rückblick zu spüren den täglichen Fortschritt, die Anpassungen in der Mitte des Sprints, . Fünf Tage reichen aus , um all das zu erleben , ohne Wochen Ihres Lebens Halten Sie Ihren Umfang also klein und streben Sie insgesamt zwei bis drei Geschichten Das Ziel ist der Zyklus, nicht das Volumen. also am Montag-Montagmorgen 30 Minuten Zeit für die Sprint-Planung. Verwenden Sie die Vorlage aus Abschnitt vier, wenn Sie können, schreiben Sie Ihr Sprintziel, wählen Sie zwei bis drei Geschichten aus Ihrem Backlog aus und fahren Sie dann fort Verschieben Sie sie in Ihre Aufgabenliste, die Beschriftungen hinzu und machen Sie einen ersten Schnappschuss Dann sollten Sie mit der Arbeit beginnen. Am Ende des Montags sollten Sie also etwas in der Spalte „Tun“ haben , idealerweise auch etwas erledigt. Dienstag bis Donnerstag ist dies der Tagesrhythmus, in dem Sie sich die Gewohnheit aneignen. Wir haben drei Arbeitstage. Also ja, Dienstag, Mittwoch, Donnerstag. Jeden Morgen 5 Minuten Solo-Stand Up. Was habe ich gestern gemacht? Was werde ich heute tun? Was blockiert mich? Du kannst die Antworten in eine kurze Notiz schreiben. Stellen Sie sicher, dass Sie jeden Eintrag datieren. Aktualisiere dein Trello-Board jeden Tag. Karten , die von „Zu tun“ zu „ Erledigt“ wechseln , sammeln keine Arbeit beim Tun an Etwas versucht, das Change-Framework , das wir uns in Lektion drei angesehen haben, zu unterbrechen das Change-Framework , das , wenn es hilft, ein Ziel zu erreichen, wenn es nicht im Rückstand Wenn ja, was wird dann weggelassen, um Platz dafür zu schaffen? Ziel ist es, bis Mittwoch mindestens eine Geschichte fertig zu stellen. Wenn Sie bis Mittwoch noch nichts fertiggestellt haben, ist das ein Zeichen dafür, dass Sie zu viel investiert haben Der Umfang wurde jetzt reduziert. Und dann, am Freitagmorgen, haben Sie die Bewertung. Nehmen Sie sich also etwa 20 Minuten Zeit , um Ihr Sprint-Review durchzuführen. Holen Sie sich einen Stakeholder, wenn Sie können, einen Freund, einen Partner, einen ehemaligen Kollegen, Chatten Sie mit ihm, führen Sie ihn durch das, was Sie gebaut haben, zeigen Sie es, aber beschreiben Sie es nicht Wenn niemand verfügbar ist, machen Sie es selbst. Nimm dich selbst bei der Demo auf. Auf einem Telefonvideo. Einfach das Training laut zu beschreiben, schärft dein Denken, erfasse das Feedback in Notion, nimm alles dort Neue Ideen sollten als Karten in Trello in deinen Produkt-Backlog Und dann, am Freitagnachmittag, nachdem Sie die Bewertung abgegeben haben, haben Sie Ihre Retrospektive, die wiederum etwa 30 Minuten dauert Selbst wenn du das alleine machst, sollte es funktionieren. Öffnen Sie Notion, erstellen Sie einen neuen Eintrag in Ihrer Retrospektiven-Datenbank verwenden Sie die von Ihnen erstellte Vorlage Die Spalten „Start“, „ Stopp“ und „Weiter“. Verbringen Sie 10 Minuten damit, Artikel in jede Spalte zu schreiben , und seien Sie ehrlich. Hören Sie auf, mitten in der Aufgabe nach Neuigkeiten zu suchen, z. B. einer anderen, fangen Sie an, 90-minütige intensive Arbeitssitzungen zu blockieren, schließen Sie am Ende des Tages weiterhin Tabs und wählen Sie dann die drei wichtigsten Dinge aus, auf die Sie für den nächsten Sprint reagieren möchten, und schreiben Sie sie als konkrete Aktionen auf. Wer, was und wann? Tagge deinen Retro-Eintrag mit der Sprint-Nummer. Sie möchten sich diese in zwei oder drei Sprints ansehen, um festzustellen, ob Sie tatsächlich Änderungen vorgenommen haben Also einige häufige Fehler, die Sie vermeiden sollten, und drei Dinge, die Sie bei Ihrem ersten Sprint vermeiden sollten Anfänger machen diese ziemlich oft. Die erste ist, sich am ersten Tag zu sehr zu verpflichten, also ist es besser, weniger zu verpflichten und dann viel zu liefern, als zu viel und zu wenig zu liefern . Die zweite Möglichkeit besteht darin, die Stand-Ups zu überspringen, wenn Sie alleine sind. Das bin nur ich. Ich weiß, was ich tue, aber vielleicht bist du nicht diszipliniert deinen Tag zu artikulieren und Dinge zu enthüllen , die du vielleicht verpasst hättest, wenn du es nicht artikuliert hättest Und dann sagt er endlich die Retrospektive ab. Die Retrospektive ist also der springende Punkt der Agile-Methodik springende Punkt der Agile-Methodik Wenn Sie sie nicht verwenden, verbessern Sie sich nicht. Also storniere niemals das Retro. Am Freitagabend, am Ende der Woche, solltest du das alles haben. Du solltest ein Trello haben das die Reise zeigt, mit deinem Sprintziel ganz oben, abgeschlossene Storys und fertig. Alles, was nicht fertig ist, wird in den Backlog geschickt Zwei, fünf tägliche Stand-up-Notizen in Notion. Drittens sollten Sie ein Dokument zur Sprint-Planung für diesen Sprint vollständig ausgefüllt haben. Viertens: In Ihren Bewertungsnotizen wird festgehalten was Sie gezeigt haben und welches Feedback Sie erhalten haben. Fünftens: ein abgeschlossener Rückblick mit drei konkreten Aktionen für den nächsten Sprint und sechs, ein Screenshot deines fertigen Trello-Boards neben dem Start-Screenshot mit drei konkreten Aktionen für den nächsten Sprint und sechs, ein Screenshot deines fertigen Trello-Boards neben dem Zusammen stellen sie eine Demonstration auf Portfolioebene dar , die zeigt , dass du einen Sprint durchführen kannst. Also, das ist es. Wir haben das Ende von Abschnitt fünf erreicht. Wir sehen uns in Abschnitt sechs. 31. Zusammenfassung: Häufige Fallstricke für Anfänger und wie man sie vermeidet: Hallo und willkommen in Abschnitt sechs. Es ist natürlich der letzte Abschnitt von Kurs eins. Bevor wir zum Abschluss kommen, möchte ich einige Zeit mit den Fallstricken verbringen , auf die Anfänger meiner Meinung immer wieder stoßen, wenn es um agiles Projektmanagement und hauptsächlich um die Durchführung von Agile-Sprints geht agiles Projektmanagement und hauptsächlich um die Durchführung von Agile-Sprints Am Ende werden Sie also wissen, worauf Sie achten müssen, und Sie werden sich wahrscheinlich monatelanges Ausprobieren ersparen, wenn Sie sich an diese Regeln halten. Denken Sie an diese häufigen Also Fallstrick eins, Agile zu machen, ohne agil zu sein. Jetzt übernehmen neue Teams die Zeremonien und veranstalten Stand-Ups. Sie haben ein Board Sie nennen Besprechungen Sprintplanung, aber hinter all dem hat sich eigentlich nichts geändert. Der Product Owner gibt immer noch Anforderungen weiter wie der Projektmanager. Das Team wartet immer noch darauf, dass man ihm sagt, was zu tun ist. Änderungen werden immer noch als Fehlschläge behandelt. Die Form ist agil, aber die Substanz ist ein verkleideter Wasserfall Sie nicht darauf rein. Die Lösung besteht nicht in mehr Zeremonien Es liegt in der Denkweise, der Denkweise, Ihrem Team zu vertrauen, Veränderungen willkommen zu heißen und frühzeitig Mehrwert zu bieten Wenn Sie also die Rituale befolgen, aber nicht nach den Werten leben, dann machen Sie Agile nicht wirklich Denn Nummer zwei ist die Überplanung des Sprints. Ich habe das in den vorherigen Videos ziemlich oft erwähnt. Die Sprint-Planung dauert also ungefähr 2 Stunden. Einige Teams machen daraus einen ganztägigen Workshop, was nicht korrekt ist. Sie diskutieren etwa 20 Minuten lang über jede Geschichte . Sie schätzen den nächsten halben Punkt. Sie schreiben Absätze mit Akzeptanzkriterien für Geschichten, mit denen sie noch nicht einmal angefangen haben. Also hör auf mit all dem. Die Planung sollte in Agile leichtgewichtig sein, denn der Sinn von Agile besteht darin, dass Sie im Laufe der Zeit lernen. Also detaillierte Pläne für Dinge , die Sie noch nicht gebaut oder vermutet haben, verkleidet als Gewissheit und gehören in das Wasserfall-Projektmanagement Planen Sie also genug, um zu beginnen, und verfeinern Sie es dann, während Sie lernen. Oder Nummer drei ist das Überspringen der Retrospektive. Das passiert ziemlich oft. Tu es nicht. Teams unter Druck. Vielleicht schneiden sie zuerst das Retro raus, zum Beispiel : Oh, wir haben keine Zeit. Wir machen einen im nächsten Sprint. Zwei Sprints später oder drei, sechs Monate später hat das Team aufgehört, sich vollständig zu verbessern Das Retro ist also das wichtigste Treffen in Agile, weil das Team so mit der Zeit besser wird Und ohne sie lernt man nicht. Ohne zu lernen stagniert man. Also achte bitte darauf, dass du immer das Retro behältst, auch wenn es nur 20 Minuten sind, und auch wenn es nur ein Notizblock ist, achte darauf, dass du es nie Und Pitfm Nummer vier, den Backlog für immer wachsen lässt Jede Idee wird hinzugefügt, und das ist ein Problem. Nichts wird entfernt. Nach sechs Monaten hast du also 400 Artikel. Niemand kann etwas finden. Die Spitze des Backlogs ist nicht mehr nur die wichtigste Arbeit Es ist das, was Sie in letzter Zeit hinzugefügt haben. Es ist also sehr wichtig, dass Sie Ihren Rückstand wie einen Strauch beschneiden Scannen Sie einmal im Monat die untere Hälfte. Alles, was seit drei Monaten oder länger da ist und für niemanden Priorität hat, löschen Sie es. Wenn es wirklich wichtig ist, kommt es zurück. Ein sauberer Backlog ist also ein gesunder Backlog. Mit 45 das Heldenproblem. Das ist also die Idee, dass eine Person im Team den Großteil der schweren Arbeit erledigt. Sie sind brillant. Sie holen sich die schwersten Tickets Sie arbeiten am Wochenende. Alle anderen verlassen sich auf diese Leute. Kurzfristig sieht das gut aus, aber auf lange Sicht ist das eine Katastrophe. Der Held brennt also aus, wenn er das Unternehmen verlässt oder selbst wenn er in den Urlaub fährt. Das Team bricht zusammen, weil das Wissen im Kopf einer Person feststeckt und schlimmer noch, niemand sonst kann wachsen Also verteilen Sie die beiden Leute auf schwierige Geschichten, lassen Sie sie zusammenarbeiten, wechseln Sie die Leute ab, die die schwierigeren aufgreifen, stellen Sie sicher, dass das Team widerstandsfähig ist und nicht von einem Helden abhängig Der nächste Fallstrick ist verwirrend und gleichzeitig produktiv. Die Tafel ist voll. Karten überall. Die Leute sehen gestreckt aus. Sicherlich sieht ein guter Sprint so aus. Nicht unbedingt. Ein Team mit 15 Karten versendet selten etwas. Sie wechseln den Kontext, sie sind halb fertig. Vielleicht werden sie blockiert und sie werden wahrscheinlich ausgebrannt. Ein Team, das zwei Karten in der Tasche hat, könnte stillschweigend mehr Wert liefern. Denken Sie also daran, dass Aktivität nicht immer Fortschritt ist. Achten Sie auf die Liste der Erledigten, nicht auf die Liste der Aufgaben. Die Frage ist nicht, ob die Leute beschäftigt sind? Die Frage sollte lauten, ist Wertefluss? Bei Nummer sieben geht es darum, Blockaden zu ignorieren. Das ist sehr, sehr wichtig. Wenn jemand in einem Stand Up einen Blocker erwähnt und das Team nur nickt, und dann geht das Meeting weiter Drei Tage später ist der Block immer noch da. Die Karte hat sich nicht bewegt und der ganze Sprint ist in Schwierigkeiten. Blocker sind also das dringendste Objekt auf jedem Board. Wenn einer angesprochen wird, gib ihm einen Namen, schreib ihn auf, beauftrage jemanden, ihn zu entsperren oder kümmere dich selbst Mache ihn gut sichtbar auf dem Board als Etikett oder als separate Karte Ein Blocker, den niemand besitzt ist ein Blocker, der nie repariert wird Denken Sie also daran. Also ja, sieben Fallstricke, die alle vermeidbar sind Die Teams, die in Agile gut werden , vermeiden all diese Fehler, und sie sind diejenigen, die sie schneller bemerken Also, das ist das Ende dieser Lektion. In der nächsten Lektion schauen wir uns an, wo Sie sich gerade befinden, und führen eine kurze Selbsteinschätzung durch, um festzustellen wie viel Sie tatsächlich in diesem Kurs aufgenommen haben. Wir sehen uns also im nächsten Video. 32. Selbstbewertung: Wo stehen Sie jetzt?: Willkommen zurück. Inzwischen haben Sie mehrere Stunden damit verbracht, die Grundlagen des agilen Projektmanagements zu erlernen . Und in dieser kurzen Lektion werden Sie eine Bestandsaufnahme darüber machen, wie viel Sie jetzt tatsächlich wissen. Am Ende haben Sie also ein klares Bild von Ihren Stärken und Schwächen und davon, worauf Sie sich als Nächstes konzentrieren sollten. Warum überhaupt eine Selbsteinschätzung? Es gibt drei Hauptgründe, warum es wichtig ist. Erstens macht das Lernen real. Lesen und Zuschauen ist einfach passiv, aber das Nachdenken zwingt dich dazu, dich tatsächlich mit dem auseinanderzusetzen, was du weißt. Zweitens zeigt es dir, worauf du dich als Nächstes konzentrieren musst. Ohne ehrliche Selbsteinschätzung könnten Sie sich den Easy Bit also noch einmal ansehen Und überspringe die schwierigen Teile. Nun, das ist eine schlechte Angewohnheit. Und drittens bereitet es Sie auf Vorstellungsgespräche vor. PM- und Agile-Interviews fragen routinemäßig Erzählen Sie mir von Ihren Erfahrungen mit Scrum also wissen, wo Sie stehen, werden diese Gespräche einfacher Wir überprüfen also zehn Fragen, pausieren das Video und Sie können ehrlich antworten und dann zurückkommen. Hier ist also keine Benotung erforderlich. Achte einfach darauf, wo du dich sicher fühlst und wo nicht. Also erstens, kann ich Agile in zwei Sätzen erklären , ohne Fachjargon zu verwenden Nummer zwei, kann ich die vier Werte des Agile-Manifests nennen die vier Werte des Agile-Manifests Drittens, kann ich eine User Story im richtigen Format mit Akzeptanzkriterien für ein Projekt schreiben Akzeptanzkriterien für ein Projekt ich derzeit nicht arbeite? Viertens: Verstehe ich den Unterschied zwischen Produkt- und Sprint-Backlogs Fünftens, kann ich beschreiben, was jede der drei Scrum Rolls macht und was nicht Sechstens, könnte ich morgen ein 15-minütiges Stand-up-Meeting ohne Vorbereitung veranstalten Nummer sieben, kann ich einem Kollegen, der noch nie davon gehört hat, Moskau und die Nutzen-Nutzen-Leistungs-Matrix erklären hat, Moskau und die Nutzen-Nutzen-Leistungs-Matrix einem Kollegen, der noch nie davon gehört hat, Moskau und die Nutzen-Nutzen-Leistungs-Matrix Nummer acht, könnte ich in einem Satz ein Sprintziel für ein fiktives Projekt in einem Satz schreiben einem Satz ein Sprintziel für ein fiktives Projekt in , der ergebnisorientiert ist Nummer neun, kenne ich den Unterschied zwischen einem Sprint-Review und einer Retrospektive und weiß, wofür sie jeweils gedacht Und Nummer zehn ist, könnte ich ein Trello-Board und einen Notion-Workspace von Grund auf neu einrichten , um meinen eigenen Sprint zu starten? Das sind also die zehn Fragen. Beantworten Sie sie ehrlich und kommen Sie zurück. Als Nächstes, was Sie mit Ihren Ergebnissen machen sollen. Also drei Kategorien, seien ehrlich, in welcher Sie sich befinden. Das ist sehr wichtig. also größtenteils zuversichtlich, dass Sie acht oder mehr Ja haben, was bedeutet, dass Sie den Stoff sehr gut aufgenommen haben. Fahren Sie mit Kurs zwei fort, wenn Sie bereit sind, und fangen Sie an, an echten Projekten zu üben Meist gemischt wären 5 bis 7 Ja. Sie haben also die Grundlagen, aber einige Teile sind immer noch verschwommen Sehen Sie sich die Lektionen noch einmal an, behandeln Sie die Fragen, mit denen Sie zu kämpfen hatten, und wiederholen Sie dann die Übungsübung mit einem neuen Projekt Meist wackelig, weniger als fünf Ja. Das ist in Ordnung. Es bedeutet nur, dass der Kurs noch einmal bestanden werden muss oder dass Sie nur den Wortschatz wiederholen müssen. Mach dich nicht fertig. Agil. Es ist eine Menge zu verarbeiten, also können Sie zu Abschnitt eins zurückkehren und es etwas langsamer durcharbeiten. Notizen zu machen und ein Glossar zu führen, ist beim agilen Projektmanagement äußerst nützlich da viele Begriffe, ja, ein Großteil des Konzepts des agilen Projektmanagements im Wortschatz zu finden sind Also, zum Schluss noch eine ehrliche Frage. Hast du die Übungsübungen tatsächlich gemacht oder hast du sie übersprungen? Also hier ist die Wahrheit. Du kannst nicht wirklich lernen, Sprints zu laufen, indem du dir nur Videos ansiehst Du lernst, wie man einen Sprint läuft, indem du einen Sprint läufst. Wenn du also die Übungen überspringst, dein eigentlicher nächster Schritt nicht mehr Inhalt, sondern du gehst zurück und machst diese Übungen tatsächlich. Selbst ein ganzer Mini-Sprint bringt dir also mehr als 20 Stunden Theorievideos bei. Nun, damit ist Ihre Selbsteinschätzung abgeschlossen. Sei nett zu dir selbst, aber achte darauf, dass du ehrlich bist. In der nächsten Lektion führen wir einen kurzen Projektrückblick durch, um einen kurzen Blick darauf , wie Ihr fertiger Sprint aussehen sollte sehen uns also im nächsten Video. 33. Projektüberprüfung: Wie Ihr fertiger Sprint aussieht: Hallo, willkommen zum vorletzten Video dieses Kurses. Wenn Sie den Kurs inzwischen verfolgt , geplant und gelaufen sind, werden wir in dieser Lektion einen Überblick darüber geben, wie der fertige Sprint aussehen sollte, was gut aussieht, worauf Sie werden wir in dieser Lektion einen Überblick darüber geben, wie der fertige Sprint aussehen sollte, was gut aussieht, worauf stolz sein können und wie Sie in einem Portfolio oder in einem Interview darüber sprechen in einem Portfolio oder in einem Interview darüber Also das Artefakt, das du haben solltest, deine sechs Artefakte, du solltest sie auf Papier oder in deinen Werkzeugen haben auf Papier oder in deinen Werkzeugen Zunächst sollten Sie ein Trello-Board mit einem umfangreichen Produkt-Backlog haben mit einem umfangreichen Produkt-Backlog Dein Sprintziel steht ganz oben, ein abgeschlossener Sprint mit Storys unter „ Fertig “ und Screenshots des Boards davor und danach Zweitens solltest du einen Notion-Arbeitsbereich mit vier Unterseiten haben : Sprint-Planung, Retrospektive, Entscheidungen und Stakeholder-Updates Drittens sollten Sie mindestens ein ausgefülltes Sprint-Planungsdokument haben ausgefülltes Sprint-Planungsdokument Viertens sollten Sie eine vollständige Retrospektive mit drei konkreten Maßnahmen abgeschlossen haben mit drei konkreten Und fünftens sollten Sie Ihre Notizen aus Ihrem Sprint-Review haben , und schließlich, sechstens, sollten Sie Verbindungen zwischen Trello und Notion in beide Richtungen haben zwischen Trello und Notion in Wenn Sie alle sechs haben, haben Sie etwas Echtes gebaut. Herzlichen Glückwunsch. Das ist ein funktionierendes Agile-System. Es ist nicht nur eine Übung. Nun, wie sieht gut aus? Hier sind die fünf wichtigsten Eigenschaften eines guten ersten Sprints. also, abgesehen von den Artefakten, Wie können wir also, abgesehen von den Artefakten, dafür sorgen, dass dieser erste Sprint gut aussieht? Fünf Eigenschaften, auf die Sie achten sollten, dass das Sprintziel klar und ergebnisorientiert ist und Sie auf einen Blick erkennen können, und Sie auf einen Blick erkennen können ob Sie es erreichen können oder nicht. Zweitens haben die User Stories das richtige Format und haben überprüfbare Akzeptanzkriterien Sie sind spezifisch. Sie sind nicht vage Drittens: Die Arbeit in Ihrer Liste „Erledigt“ steht in direktem Zusammenhang mit dem Sprintziel Ihnen fehlt nichts mehr und es fehlt auch nichts. Viertens, dein Retro identifiziert echte Dinge, die geändert werden müssen, nicht nur generische Plattitüden, wie, mehr kommunizieren Beweg dich, steh auf 9:30 Uhr, weil es besser ist, wenn 10:00 Uhr mit X kollidiert. mit X kollidiert Fünftens, die Dokumentation ist leicht, aber nützlich, gerade genug, um hilfreich zu sein, aber nicht so sehr, dass sie niemand liest Das sind also die fünf Dinge. Wenn Sie all diese Punkte überprüfen und die Antwort auf all diese Fragen Ja lautet, dann wissen Sie, dass Ihr Sprint gut aussehen kann. Selbst wenn dein erster Sprint hart war, gibt es einige echte Winde, die es wert sind, erkannt zu werden. Jetzt haben Sie eine neue Denkweise gelernt, nicht nur eine neue Methodik Agile ist eine Art, über Arbeit nachzudenken Die Tatsache, dass Sie jetzt Wasserfalldenken in Ihren eigenen Gewohnheiten erkennen können, ist an sich schon eine große Veränderung Sie haben etwas Greifbares gebaut. Die meisten Leute, die sagen, dass sie Agile verstehen , haben noch nie einen Sprint gefahren, aber Sie schon. Sie haben ein Portfoliostück erstellt. Für welchen Job Sie sich auch immer als Nächstes entscheiden, Sie können auf einen abgeschlossenen Sprint mit Zielen, Geschichten, Rückblicken und Reflexionen hinweisen Geschichten, Rückblicken und Reflexionen Sie beweisen sich auch selbst , dass Sie etwas beenden können Diese Kurse sind einfach zu beginnen, aber schwer zu beenden Du hast die Arbeit gemacht, also herzlichen Glückwunsch. Schauen wir uns nun an, wie wir in Interviews darüber sprechen können . Wenn Sie auf Jobsuche sind, ist der Sprint Gold für Vorstellungsgespräche, wenn Sie ihn richtig gestalten. Sag nicht einfach, dass ich einen Agile-Kurs gemacht habe. Das sagt nicht wirklich über das Interview oder so etwas aus, aber man könnte sagen, ich leite ein praxisnahes Agile-Projekt, bei dem ich ein Backlog aufgebaut, einen Sprint geplant und durchgeführt, eine Retrospektive durchgeführt und X Stories zu einem bestimmten Sprintziel Das ist weitaus beeindruckender und es ist tatsächlich wahr. Bringen Sie die Artefakte mit, zeigen Sie das Trello, gehen Sie durch den Arbeitsbereich von Notion Die meisten Interviewer haben noch nie gesehen ein Kandidat seinen Prozess tatsächlich demonstriert hat Diejenigen, die das tun, werden mehr als alles andere auffallen. Seien Sie also auch ehrlich in Bezug auf das, was Sie gelernt haben. Man könnte sagen, bei meinem ersten Sprint habe ich mich überfordert. Ich musste zwei Geschichten fallen lassen. Im Nachhinein fand ich heraus, dass ich auf der Grundlage von Best-Case-Szenarien geschätzt hatte . Jetzt bezahle ich immer meine Schätzungen. Selbstbewusstsein liest sich also immer als anspruchsvoll und hochprofessionell. Wenn Sie dies nun als Portfoliostück verwenden möchten, sollten Sie Folgendes hinzufügen: eine kurze schriftliche Zusammenfassung, nur einen kurzen Absatz darüber, was Sie erstellt haben und warum? Screenshots von deinem Trello-Board davor und danach, das Sprint-Ziel sichtbar ist. Das ist extrem wichtig Ihr aus Notion exportiertes Sprint-Planungsdokument. Selbst die grobe Version würde beweisen, dass Sie über Kapazität, Risiko und Engagement nachgedacht haben. Ihr Retro mit den Aktionen , die Sie identifiziert haben. Das ist Gold wert , weil es zeigt, dass man sich selbst verbessern kann, man kann ein Team verbessern. Und optional könnten Sie Projekt mit einem fünfminütigen Webstuhl per Video durchgehen lassen Es sind nur 5 Minuten, und die Leute erinnern sich an die Kandidaten, die es ihnen gezeigt haben, anstatt es ihnen gesagt zu haben. Wenn Sie eine eigene Website haben, hosten Sie sie dort oder laden Sie sie ein öffentliches GitHub-Repo hoch oder teilen Sie sie mit der öffentlichen Freigabefunktion von Notion Machen Sie es also verlinkbar und aufgeräumt. Oh, herzlichen Glückwunsch. Du hast das Ende von Kurs eins erreicht. Du hast etwas Echtes gebaut. Du solltest das niemals unterschätzen. Sie haben etwas Reales erreicht, das Sie Ihrem Portfolio hinzufügen und Interviews verwenden Es könnte Sie Ihrem Traumjob einen Schritt näher bringen . Im letzten Video dieses Kurses werden wir uns also ansehen, was als Nächstes kommt, und wir werden uns die Brücke zu Kurs zwei ansehen , der der Zwischenkurs im Projektmanagement sein wird . Wir sehen uns also in der letzten Lektion. 34. Was kommt als Nächstes?: Willkommen zurück zum letzten Mal in Kurs eins. Gut gemacht. Du hast es bis zum Ende geschafft. In diesem letzten Video wir uns nur ansehen, wohin Sie von hier aus gehen. Wir werden uns Kurs zwei ansehen und schauen, was darin und darüber hinaus enthalten ist. Also ja, du wirst genau wissen, was deine nächsten Schritte sind. Lassen Sie uns also zunächst kurz zusammenfassen , was Sie gelernt haben Sie haben die Grundlagen gelernt, und das ist mehr, als die meisten Leute, die behaupten, Agile-Expertise zu haben, von sich sagen können Wir haben das AgI-Manifest und die AgI-Mentalität behandelt. Wir haben Sprints, Inkremente und den empirischen Kreislauf behandelt. Wir haben uns mit Scrum Rolls befasst. Wir haben uns mit Backlogs, Anwenderberichten, Akzeptanzkriterien und der Definition von erledigt befasst Wir haben uns angesehen, wie man in Trello und Notion einen Arbeitsplatz einrichtet in Trello und Notion einen Arbeitsplatz einrichtet Wir haben uns angeschaut, wie man Prioritäten setzt, schätzt und einen Sprint durchführt Wir haben uns angesehen, wie man einen Sprint mit Stand-Ups, mit Anpassungen in der Mitte des Sprints, mit Rückblicken und Rückblicken durchführt Wir haben uns auch die Fallstricke angesehen, auf die es zu achten gilt. All das ist also die Grundlage. Sie wissen also mehr als die meisten Menschen, die behaupten, agiles Fachwissen zu haben. Darauf könntest du also stolz sein. Kurs zwei heißt Sprinten im großen Maßstab. Hier setzt Kurs zwei also dort an, wo Kurs eins aufgehört hat, und geht tiefer in die Fertigkeiten für Fortgeschrittene Sie werden also lernen, wie Sie mehrere Sprints hintereinander bewältigen können. Sie werden lernen, wie Sie die Dynamik aufrechterhalten können. Sie werden lernen, mit Änderungen im Sprint-zu-Sprint umzugehen und auch mit der Geschwindigkeit umzugehen. Sie werden sich mit den fortgeschrittenen Scrum-Zeremonien und den Sitzungen zur Verbesserung des Backlogs befassen Scrum-Zeremonien und den Sitzungen zur Verbesserung des Backlogs und sich mit einer ausgefeilteren Planung mit tieferen Rückblicken und sich mit einer ausgefeilteren Planung mit tieferen Rückblicken befassen. Außerdem werden Sie sich ausführlich mit Kanban befassen, wie es sich von Scrum unterscheidet und wann es eingesetzt wird und wie Sie beide Methoden in einem hybriden Ansatz kombinieren können Sie lernen auch, wie Sie mit Stakeholdern in großem Maßstab umgehen, Führungskräfte verwalten, Kunden verwalten und auch konkurrierende Prioritäten verwalten können Sie werden auch die Tools kennenlernen, die über Trello hinausgehen. Wir werden uns Jira-, Linear- und Github-Projekte ansehen und uns auch ansehen, wann sie sich lohnen und wann sie übertrieben sind Kurs eins ging es also nur darum, einen Teil auszuführen, während es in Kurs zwei darum geht, einen Stream von ihnen auszuführen, was der Realität des agilen Projektmanagements näher kommt des agilen Nun, Kurs drei ist der Kurs für Fortgeschrittene. Es heißt Teams führen und verbessern. Dieser Kurs richtet sich an Personen, die nicht nur Sprints durchführen, sondern auch agile Transformationen in Unternehmen leiten möchten nicht nur Sprints durchführen auch agile Transformationen in Unternehmen leiten agile Transformationen in Dieser Kurs deckt alle sozialen Kompetenzen ab, z. B. das Coachen von Teammitgliedern, Umgang mit Teamkonflikten und den Aufbau psychologischer Sicherheit Es geht auch um die Kennzahlen und darum, wie man die Gesundheit eines Teams messen kann, ohne zur Kennzahlenpolizei zu werden . Es befasst sich auch mit den schwierigeren organisatorischen Dingen, wie z. B. die Zustimmung der Führung zu gewinnen, mit Widerständen umzugehen und Agile über ein einzelnes Team hinaus zu skalieren. Auf dieser Ebene wird Agile nicht mehr zu einer Methode , sondern zu einer Führungskompetenz für Ihre höheren Rollen. Neben diesen drei Kursen gibt es noch andere Orte, an denen Sie weiterlernen können. Wenn Sie weitermachen möchten, haben wir einige Buchempfehlungen. An erster Stelle steht Scrum von Jeff Sutherland. Es ist kurz, zugänglich und Jeff ist einer der Erfinder Das Phoenix-Projekt ist ein Roman über DevOps und Agile , der seltsam lesbar ist, und schließlich, inspiriert von Marty Kagan, ist Zertifizierungen, die Sie sich vielleicht ansehen sollten, sind der CSM Certified Scrum Master und der PSPO Professional Scrum Product und der PSPO Professional Scrum Owner, die angesehensten in der Branche. Diese sind für Jobs nützlich, auch wenn die eigentliche Prüfung Ihnen nicht viel über das hinausgeht , was Sie Toll, das in deinem Lebenslauf zu haben. Communities, die Agile- und Scrum-Unterversionen sind großartig die Agile Alliance-Veranstaltungen und lokalen Scrum-Meetups Eine der besten Möglichkeiten, zu lernen, besteht darin, mit anderen Praktikern zu sprechen Und schließlich deine eigene Arbeit. ist also großartig, das Gelernte auf ein echtes Projekt anzuwenden, auch wenn es nur ein Nebenprojekt ist. Den nächsten Sprint läufst du, der in der realen Welt stattfinden wird. Du lernst mehr als ein anderer Kurs. Eine letzte Sache, bevor wir zum Schluss Agile ist keineswegs eine perfekte Methode. Es gibt Probleme und es wird missbraucht, und es kann zu verkleideter Bürokratie werden Die besten Praktiker sind diejenigen, die es pragmatisch anwenden Sie nehmen, was funktioniert, sie lassen, was nicht funktioniert, und sie hören nie auf, sie hören nie auf Ihre Aufgabe von hier aus ist es also, genau das zu tun. Führen Sie Sprints durch, stellen Sie fest, was funktioniert, stellen Sie fest, was nicht funktioniert, passen Sie es an Das ist die gesamte agile Denkweise, die auf das Erlernen von Agile selbst angewendet wird . vielen Dank, dass Sie an meinem ersten Kurs teilgenommen haben, dem Einsteiger - und Einführungskurs in agiles Projektmanagement Gut gemacht, dass Sie es bis zum Ende geschafft haben. Die meisten Menschen tun das nicht. Ich hoffe wirklich, dass Sie dadurch eine echte Arbeitsgrundlage haben, die Sie sogar bei Vorstellungsgesprächen und Bewerbungen verwenden können. Also nochmal, vielen Dank. Viel Glück mit dem, was auch immer Sie als Nächstes bauen, und wir sehen uns im zweiten Kurs. Auf Wiedersehen. 35. Schulungsprojekt: Erstellen Sie Ihr eigenes agiles Projekt: Jetzt ist es an der Zeit, alles, was Sie gelernt haben, in die Praxis umzusetzen. Für dein Klassenprojekt erstellst und verwaltest du dein eigenes agiles Projekt, entweder mit Trello, Notion oder beidem Wählen Sie zunächst einfach eine der Projektbeschreibungen aus dem Kurs aus oder erstellen Sie Ihre eigene Projektidee, wenn Sie dies bevorzugen Dann erstellen Sie Ihr Projekt Schritt für Schritt. Du erstellst ein Produkt-Backlog, schreibst User Stories, fügst Akzeptanzkriterien hinzu, priorisierst deine Arbeit, schätzt Aufgaben ab und planst deinen ersten Als Nächstes organisieren Sie alles in Ihrem Projektmanagement-Tool und erstellen ein Sprint-Board, auf dem Sie sehen, wie sich die Arbeit von „erledigt“ bis „erledigt“ entwickeln wird Das Ziel ist nicht, ein perfektes Projekt zu erstellen. Ziel ist es zu zeigen , dass Sie den agilen Workflow verstehen und ihn praktisch anwenden können. Sobald dein Projekt abgeschlossen ist, lade Screenshots deines Trello-Boards, deiner Idee, deines Workspace, Sprint-Backlogs oder eines anderen Projektartefakts hoch, das du teilen möchtest Und du kannst auch eine kurze Erklärung deines Projekts und deines Sprintziels Dieses Projekt bietet Ihnen praktische Erfahrungen mit den gleichen Konzepten und Tools, die von Agile-Teams täglich verwendet werden. 36. Wir gratulieren!Was kommt als Nächstes?: H. Herzlichen Glückwunsch zum Abschluss des Kurses. Sie haben jetzt die Grundlagen des agilen Projektmanagements kennengelernt , angefangen beim Verständnis der Agile-Denkweise und des Scrum-Frameworks bis hin zur Erstellung von Verständnis der Agile-Denkweise und Backlogs, Planung von Sprints und der Arbeitsverwaltung mithilfe professioneller Am wichtigsten ist, dass Sie diese Konzepte angewendet haben , indem Sie Ihr eigenes Projekt erstellt Genau so werden Projektmanagementfähigkeiten in der realen Welt entwickelt Denken Sie daran, dass gute Projektmanager nicht durch das Auswendiglernen von Frameworks geschaffen werden Sie werden erfolgreich, indem kontinuierlich Planung, Kommunikation, Priorisierung und Anpassung üben Kommunikation, Priorisierung und Sie, diese Techniken im Laufe des Lernens Versuchen Sie, diese Techniken im Laufe des Lernens auf persönliche Projekte, Teaminitiativen oder sogar auf Aufgaben am Arbeitsplatz anzuwenden Teaminitiativen oder sogar auf Aufgaben am Arbeitsplatz Je mehr Erfahrung Sie sammeln, desto natürlicher wird agiles Projektmanagement. Falls Sie es noch nicht getan haben, stellen Sie sicher , dass Sie Ihre Projekte in die Galerie hochladen. Ich würde gerne sehen, wie Sie die Konzepte aus dem Kurs angewendet haben . Und wenn Ihnen der Kurs gefallen hat, ziehen Sie bitte in Betracht, uns eine Bewertung zu hinterlassen. Das hilft uns, den Kurs zu verbessern und hilft auch anderen Studierenden, ihn zu entdecken. Vielen Dank, dass Sie mich auf dieser Lernreise begleitet haben, und ich hoffe, Sie im nächsten Kurs zu sehen.