Scrum: Agiles Projektmanagement und Anforderungen, sammeln

1. Willkommen: Willkommen zu diesem Kurs über Scrum. ob Sie ein ScrumMaster, ein Projektmanager, ein Entwickler und ein Ingenieur sind , Egal, ob Sie ein ScrumMaster, ein Projektmanager, ein Entwickler und ein Ingenieur sind, testen Sie es, indem Sie sich nur Agile ansehen, ich werde dann der Kurs für Sie sein. Scrum ist ein Projektmanagement-Framework. Es wurde ursprünglich für die Softwareentwicklung entwickelt, kann aber eigentlich für alles verwendet werden. Also die Fähigkeiten werde ich diesem Kurs so viel wie möglich vermitteln. Ich werde versuchen, es auf alle Umgebungen anzuwenden. Aber wir werden eine echte Fallstudie durchführen. Wir werden uns also mit dem Aufbau einer E-Commerce-Plattform als Softwareanwendung befassen. Und wir werden sehen, wie Squirm darauf zutrifft. Sie lernen also die Theorie und die Praxis, und wir werden sie auch auf diese Situation anwenden. Also, wenn das alles gut klingt, dann lass uns anfangen. 2. Scrum Grundlagen: Fangen wir mit den Grundlagen an. Also, was wird angebaut? Nun, es ist ein Projektmanagement-Framework. Es hilft Ihnen, Projekte durchzuführen und sie so zu strukturieren, dass sie funktionieren. Es wurde also ursprünglich für die Entwicklung von Software, für die Entwicklung technischer Projekte entwickelt , wurde aber seitdem auf eine ganze Reihe von Themen angewendet. Softwareentwicklung ist also sein Zuhause. Aber eigentlich kann man Squirm auf alles anwenden und es funktioniert wirklich gut. Ich habe es in meinem Privatleben verwendet, ich habe es nicht für Projekte verwendet. Und diese Ventile sind wirklich gut. Scrum ist Teil der Agile-Familie. Agil ist also eine Bewegung. Es ist keine einzige Sache. Agile ist, ist eine Art zu sein und zu arbeiten. Und du hast die coole Philosophie von Agile. Aber dann gibt es spezifische Implementierungen, Dinge wie Scrum, Dinge wie Kanban, diese Art von Handbuch von okay, nun, so setzt man diese agilen Prinzipien in die Tat um. Also ein riesiger Teil der gesamten Agile-Bewegung, und es ist eine spezifische Implementierung davon. Gedränge. Und Agile ist im Allgemeinen darauf ausgelegt, Projektfehler zu reduzieren Projekte zuverlässiger zu machen. Auf die alte Art scheiterten Projekte also häufig. Und dann kamen alle vorbei und sagten: Wie können wir das besser machen? Wie können wir das reduzieren? Und wir werden im weiteren Verlauf mehr darüber erfahren , wie das funktioniert. Also, wie funktioniert Scrum? Wie erreicht es all diese Dinge? Lassen Sie uns das in den nächsten Lektionen untersuchen. 3. Agile vs Wasserfall: Lassen Sie uns eine alte Wasserfallmethode mit einer agileren Scrum-Methode vergleichen . Das alte System, wir hätten alles in großen Schritten. Es wäre eine große Spezifikationsphase. Dann konnte die gesamte Entwicklungsarbeit erledigt werden, gefolgt von den Tests und der Benutzerakzeptanz. Nun , hier geht das schief. Wir könnten, es könnte viel länger dauern als erwartet und uns geht irgendwann das Geld aus, wir kommen in die Testphase und wir stellen fest, dass wir die Anforderungen ändern müssen, aber wir haben bereits die gesamte Entwicklungsarbeit geleistet. Oder wir kommen in die Phase der Benutzerakzeptanz und stellen es dem Kunden oder dem Kunden vor und sie mögen es nicht und sie brauchen Änderungen. Und was sollen wir dann tun, weil wir uns bereits in der Phase der Benutzerakzeptanz befinden. Stattdessen schlägt Agile vor, dass wir einen iterativen Prozess verwenden , in dem wir viele kleine Schritte ausführen. Also machen wir einen kleinen Fleck, kleinen Build, kleine Aufgaben, geringe Benutzerakzeptanz, und dann beginnen wir den Zyklus von vorne. Anstatt also diese vier großen Blöcke in denen alles auf einmal erledigt wird, haben wir diese kleinen schnellen Zyklen. Und die Vorteile dabei sind Dinge wie, nun ja, wir können nach dem ersten Zyklus eine Veröffentlichung machen. Wenn es sich um eine alte Wasserfall-Methode handelt, könntest du sie erst am Ende veröffentlichen. Aber hier bauen wir etwas sehr Grundlegendes und können es nach dem ersten Zyklus veröffentlichen. Wir können es auch dem Kunden präsentieren , damit er es sehen kann. Und sie können bei Bedarf Änderungen vornehmen, wenn es nicht ihren Wünschen entspricht. Und diese Änderungen sind in Ordnung, denn nachdem wir fertig waren, war die Benutzerakzeptanz die erste Runde. Wir kehren zum Training der Spezifikationsphase zurück. Als Nächstes müssen wir es bauen und dann bauen und testen es und geben es dem Kunden zurück. Und wir machen weiter in diesen schnellen Zyklen, in denen wir jede Menge Feedback sammeln und Dinge frühzeitig veröffentlichen, was die Wahrscheinlichkeit von Fehlern verringert und bedeutet, dass sie den Bedürfnissen des Kunden entsprechen . 4. Stärken und Einschränkungen: Sehen wir uns einige der Stärken und Grenzen von Scroll an. Einer der großen Vorteile besteht darin, dass Projekte nicht scheitern. Also haben wir über diese Idee gesprochen Wasserfallprojekte ewig gedauert haben und bis zum Ende kamen. Und vielleicht kommen sie am Ende nicht an, weil die Kosten übersteigen, oder sie tun es und der Benutzer mag es nicht. Und das Ganze ist ein Misserfolg: Werden Scrum und Agile im Allgemeinen das wirklich vermeiden? Kunden können es früher sehen , sodass sie zufriedener sind, weil sie den Fortschritt sehen und sehen können , dass er mit dem übereinstimmt , was sie wollen, anstatt am Ende etwas zu bekommen , das vielleicht ihren Wünschen entspricht oder auch nicht. Es ist eine sehr gute Berichterstattung, die sich ändernden Benutzeranforderungen. Also, wenn der Kunde es bekommt und sagt, Oh, ich muss das ändern oder das funktioniert nicht ganz. Es ist viel einfacher, Änderungen vorzunehmen , wenn Sie nicht alles gebaut haben. Und wenn Sie mit einer Methodik arbeiten, die Änderungen vorsieht ist eine feine Änderung Teil des Prozesses , den sie sind . Das Problem bei Waterfall ist, dass der Kunde im Laufe des Projekts Änderungen vornimmt. Und du brauchst eine Möglichkeit, damit umzugehen. Und die iterative Methodik hilft dabei wirklich. Das bedeutet, dass Sie die erste Version früher herausbringen können da Sie nicht das Ganze beenden müssen , um sie versenden zu können. Sie können die grundlegenden Funktionen erstellen, ausliefern und dann weiter ausbauen, und dann weiter ausbauen nachdem Sie die Projekte bereits veröffentlicht haben. Nun, das sind alle Einschränkungen von Scrum und Agile. Eines der großen Probleme ist also , dass es etwas länger dauert. Manchmal denken die Leute, dass Agile etwas schneller klingt, aber das ist es nicht. Es wurde entwickelt, um die Ausfallraten zu reduzieren. Waterfall, Waterfall ist also ziemlich effizient, wenn Sie alles zu 100% richtig machen. Also, wenn Sie es zu 100% geplant und gebaut haben und es dann testen und dann geliefert haben, und alles funktioniert perfekt. Und es gibt keine sich ändernden Benutzeranforderungen, die schneller wären als dieser iterative Zyklus, in dem Sie ein bisschen erstellen, Sie überprüfen es, Sie überprüfen es, es wäre schneller. Nun, ich habe noch nie ein Projekt gesehen, bei dem es zu 100% geplant war und dann wissen wir, dass sich die Benutzeranforderungen ändern. Ich denke also, dass Agile viel besser funktioniert. Aber hypothetisch gesehen, wenn Sie das alles unter einen Hut bringen könnten, wäre Waterfall schneller, weil Scrum in diesem iterativen Zyklus funktioniert, es dauert etwas länger. Stakeholder mögen es nicht immer. Wenn sie also aus dem Wasserfall-Stil der alten Schule kommen, sind sie wahrscheinlich etwas nervös, wenn es darum geht, diese neue agile Methode zu übernehmen. Und manchmal machen sie sich Sorgen , dass sie in Panik geraten, wenn wir diesen iterativen Zyklus entwickeln dem wir dem Kunden ein halbfertiges Stück Software zeigen , in dem wir dem Kunden ein halbfertiges Stück Software zeigen. Meine Erfahrung, Kunden lieben es. Sie haben sich wirklich verlobt. Sie wollen Fortschritte sehen und verstehen , dass sie sich nicht das fertige Projekt ansehen. Aber viele Manager der alten Schule machen sich wirklich Sorgen, dass wir ihnen einen Button zeigen, der noch nicht vollständig fertig ist , und der Kunde geht davon aus , dass er fertig ist, und erwartet ihn morgen. Und es kann manchmal schwierig sein , mit diesen Erwartungen umzugehen. Scrum ist sehr flexibel, aber in gewisser Weise unflexibel. Es funktioniert also in diesen Sprints von normalerweise zwei Wochen, in denen du sagst, was du zu Beginn der zwei Wochen tun wirst, dann tust du es und du änderst das nicht. In gewisser Hinsicht ist das gut, denn wenn Sie Änderungen innerhalb des Sprints zulassen, Manager oft versuchen Manager oft, mehr Arbeit zu verdrängen, die Ingenieure abzulenken und sie von der Arbeit abzulenken. Und es ist nicht großartig. Aber es gibt einige Umgebungen in denen dringende Dinge auftauchen ist nicht so gut darin damit umzugehen wie etwas wie Kanban, weiteres agiles Framework, das eher als eine Art von Business as usual konzipiert ist , sobald Sie am Leben sind, Korrekturen hochzudrücken, es ist besser geeignet für das mit Scrum ist besser geeignet Scrum ist besser geeignet, wenn Sie eine Projekt zum ersten Mal. Und, weißt du, du kannst sagen, wir haben hier einen zweiwöchigen Block. Das werden wir tun und es allen ermöglichen, sich darauf zu konzentrieren. 5. Der Sprint: Eines der wichtigsten Konzepte in Scrum, das sich von einigen anderen agilen Frameworks unterscheidet , ist die Idee des Sprints. Dies ist ein fester Zeitraum, in dem sich das Team bereit erklärt, bestimmte Funktionen bereitzustellen . Es sind also oft zwei Wochen und wir sagen, okay, in den nächsten zwei Wochen werden wir dieses Feature, dieses Feature und dieses Feature entwickeln . einem Sprint haben wir also ein Ziel, z. B. vielleicht ist das Ziel, die Checkout-Seite für unsere E-Commerce-Plattform bereitzustellen . Und das besteht aus mehreren Tickets , die jede der dafür erforderlichen Funktionen enthalten. Und dann starten wir einen Sprint und das gesamte Team arbeitet zusammen, um diese Funktionalität bereitzustellen. Lieferung, das Erreichen des Sprintziels ist also nicht die Aufgabe einer einzelnen Person. Es liegt in der kollektiven Verantwortung des gesamten Teams. In einem Prozess sieht das also so aus, dass wir mit Sprint Planning beginnen. In der Sprintplanung wird das Sprintziel vereinbart und wir wählen die Aufgaben aus, die erledigt werden sollen. Also wählen wir die Probleme oder Tickets aus, die wir einbringen werden , und sie werden zum Sprint-Backlog, der im Wesentlichen die To-do-Liste für diese zwei Wochen darstellt. Wir kommen dann zum Sprint selbst. Das Team arbeitet also daran, die vereinbarten Funktionen bereitzustellen und es wird nichts Neues in den Sprint eingebracht. Wenn wir also Sprintplanung machen, beginnen wir mit dem Wann und dann wird dieser Sprint, dieser Zeitraum, festgelegt, um zu sagen, dass wir das tun werden und dass wir zusammenarbeiten werden , um es zu tun. Am Ende des Sprints. Wir haben dann den Rückblick und den Rückblick. Die abgeschlossene Arbeit wird also bei einer Überprüfung vorgestellt und das Team reflektiert, wie sie gelaufen ist, was die Retrospektive ist. Also die beiden getrennten Ereignisse, und wir werden in einer späteren Lektion mehr darüber sprechen. Und alle Probleme, die nicht abgeschlossen sind in den nächsten Sprint übernommen oder sie in den Produkt-Backlog zurückgeführt. 6. Sprint: Die Länge eines Sprints kann beliebig sein. In der Regel werden Sprints in zweiwöchigen Abständen durchgeführt , da das für die meisten Projekte gut zu funktionieren scheint, aber das ist keine Regel. Manchmal habe ich einwöchige Sprints gemacht, manchmal dreiwöchige Sprints. Was Sie wirklich tun möchten ist herauszufinden, wie lange Sie brauchen werden, um bestimmte Funktionen bereitzustellen, einen bestimmten Teil des Entwicklungsprozesses, und das zu Ihrer Sprintlänge zu machen. Also, wenn Sie eine wirklich große und knifflige Funktion haben um einen Teil des Projekts zu liefern. Wenn du dann, sagen wir, einen Monat dafür brauchst, dann solltest du deinen Sprint einen Monat lang machen wenn wir wortwörtlich nicht aufgeschlüsselt werden können. Und das ist eine gute Frage, die Sie sich stellen sollten, wenn Sie denken, okay, ich brauche einen Sprint von fast vier Wochen oder sechs Wochen oder so. Prüfen Sie erneut, ob Sie das weiter aufschlüsseln können , da Sie das wahrscheinlich können. Aber wenn es buchstäblich unmöglich ist, ist es in Ordnung, Ihren Sprint zu verlängern, da Sie die Länge der Schiene an unsere Bedürfnisse anpassen können . Normalerweise sind zwei Wochen ein guter Zeitraum. Jeder kann seinen Kopf senken. Sie verbringen nicht zu viel Zeit den Sprintzyklus zu durchlaufen, und Sie haben einen guten Zeitraum von zehn Arbeitstagen, um Dinge zu erledigen, aber Sie können ihn je nach Bedarf kürzer oder länger gestalten. 7. Was sind Artefakte?: Artefakte sind Informationen , die ein Scrum-Team verwendet, um seine Arbeit zu planen und durchzuführen. So wäre z. B. eine Liste der zu erstellenden Funktionen ein Artefakt. Jetzt könnte dies in einer Tabelle geführt werden. Es könnte in einem Tool wie JIRA gespeichert werden, oder es könnte sogar in unseren Köpfen gespeichert werden. Aber das würde ich nicht empfehlen , da das offensichtlich zu einer einzigen Fehlerquelle führt. In diesem Modul werden wir die verschiedenen Arten von Artefakten untersuchen , die von Scrum-Teams häufig verwendet werden. 8. Produkt-Backlog: Das Produkt ist das , was Sie liefern, und der Produkt-Backlog umfasst all die Dinge, die erledigt werden müssen. Also alle Aufgaben, die mit dem Projekt verbunden sind. Jedes Ticket steht für eine einzelne Funktion. Also ein Ticket, eine auslieferbare Funktion, z. B. wenn wir unser E-Commerce-Shop-Beispiel nehmen, dann benötigen wir wahrscheinlich eine Produktseite anzeigen, auf der Sie auf das Produkt klicken und alle Details sehen können . Und das hat verschiedene Komponenten, da es wahrscheinlich wie ein Titel und eine Beschreibung des Produktfotos sowie einige Bewertungen und technische Spezifikationen sind. Nun könnte jedes dieser Dinge sein eigenes Ticket sein, das in einem Produkt-Backlog steht. Also das Erstellen der leeren Seite, Hinzufügen des Titels, das Hinzufügen des Produktbilds, ich habe keine Spezifikationen und die Bewertungen hinzugefügt. Dies könnten alles einzelne Tickets sein , da Sie diese einzeln liefern könnten. Sie könnten eine Seite bereitstellen , auf der nur ein Produkttitel steht. Und dann könnten Sie später wiederkommen und ein Produktfoto oder einige Produktrezensionen hinzufügen , die einzelne Funktionen aufschlüsseln, sodass sie ihr eigenes Ticket erhalten. Jetzt können Tickets für eine größere Arbeit verwendet werden. In diesem Fall haben wir also unsere Produktseite, oder Produktseite, die vielleicht ein sogenanntes Epos sein könnte. Das ist also eine Sammlung von Tickets, die auf eine größere Funktionalität hinarbeiten. Unsere gesamte Produktseite könnte also in einem Epos sein. Und dann haben wir Einzeltickets da drin. Wir haben also unsere Produktbeschreibung, Produktfoto, unsere Produktrezension und all das ist Teil des Produktseiten-Epos, das wir dann irgendwann herausbringen können. Der Sinn des Produkt-Backlogs besteht also darin, alle Aufgaben zu verwalten , die erledigt werden müssen. Sie würden also alles für die Produktseite, alles für die Suchseite, alles für die Checkout-Seite speichern alles für die Suchseite, , alles in einzelne Tickets aufgeteilt und in diese Epen unterteilt . Wir wissen also, zu welchem Ticket gehört, zu welcher Art von Abschnitt. 9. Example: Hier haben wir ein Beispiel für ein Produkt-Backlog. Das ist also für unseren Beispiel-E-Commerce-Shop. Und wir haben hier unsere Benutzergeschichten geschrieben. Also das im User Story-Format geschriebene , über das wir später sprechen werden. Aber Dinge wie, als Besucher werde ich den Namen des Produkts, das Produktbild nicht sehen. Und dann möchte ich als Manager eine Liste der Bestellungen sehen. Und in dieser Kolumne haben wir es nach Epochen gruppiert. sind also alles Epic auf der Produktseite, ihr Checkout apical Order Management Epic. Und wir haben hier und in der Statusspalte einen vorläufigen Sprint veröffentlicht, um zu sagen, ob sie fertig sind der Statusspalte einen vorläufigen Sprint veröffentlicht, um zu sagen, ob sie , wann immer wir es jetzt tun, oder ob sie bereit sind. Und es wird einige geben , die noch nicht fertig waren , weil wir sie hier unten nicht verfeinert haben. Jetzt gibt es jede Menge großartiger Tools, mit denen Sie Ihr Produkt-Backlog verwalten können . Aber ich wollte es Ihnen in dieser Tabelle zeigen weil ich denke, dass es eine großartige Möglichkeit ist, Grundlagen zu lernen. Sie können es in einer Tabelle tun, Sie können es auf einem Blatt Papier tun, Sie können tun, was Sie möchten. Wir werden uns mit den Tools befassen , weil sie auch sehr wichtig sind. Das ist wahrscheinlich das, was Sie in einer realen Geschäftsumgebung verwenden werden . Dies ist jedoch ein guter Weg, um die Grundlagen zu berücksichtigen. 10. Sprint-Backlog: Zu Beginn jedes Sprints wählst du aus, welche Tickets du in diesem Sprint machen möchtest. Nehmen wir an, Sie arbeiten in einem zweiwöchigen Sprint. Du gehst den Produkt-Backlog durch und sagst: Okay, a, B, C, D, Das sind die Tickets, die wir in diesem Sprint einbringen und erledigen werden. Sobald Sie also den Sprint gestartet haben, bilden diese Tickets, die Sie ausgewählt haben Ihr sogenanntes Sprint-Backlog. Die Produkt-Backlog-Liste, alles, was Sie für das Projekt tun müssen, die Sprint-Backlog-Liste der Tickets, die Sie für diesen bestimmten Sprint erledigen werden. Wenn also jemand bereit ist, an etwas zu arbeiten, geht er zum Sprint Backlog und holt sich eines der Tickets, jedes der Tickets, die Sie priorisieren können. Aber in der Regel gibt es innerhalb eines Sprints nicht viel Priorisierung, gibt es innerhalb eines Sprints nicht viel Priorisierung es sei denn, etwas blockiert etwas. Wenn Sie jedoch einen Blocker haben, ist es am besten, das einem separaten Sprint zu überlassen , damit die Tickets in beliebiger Reihenfolge abgeholt werden können. Und dann beginnen sie mit der To-do-Spalte , bei der es sich um den gesamten Sprint-Backlog handelt, während sie die Entwicklung, Implementierung und Bereitstellung durchlaufen . 11. Beispiel Sprint-Backlog: Hier haben wir ein Beispiel, Sprint Backlog. Also haben wir hier unsere Kolumnen mit der To-do-Liste, den Backlog hier. Und wenn wir dann diese Tickets machen, also wenn ich sage, dass ich dieses als Kunde ausgewählt habe, möchte ich den Produktnamen sehen. Ich kann das in Bearbeitung setzen und es dann zur Codeüberprüfung senden. Und führe es einfach weiter durch den Prozess. Und nehmen wir an, es wird zum Testen bereit. Tests zeigen es. Es funktioniert nicht. Sie könnten es zurück zu In Bearbeitung verschieben und es mir neu zuweisen. Und es könnte diesen Zyklus noch einmal durchlaufen und dann hoffentlich irgendwann in der Spalte Erledigt landen. Jetzt können diese Spalten so flexibel sein, wie Sie möchten. Also könnten wir, anstatt der Encoder-Ansicht in Bearbeitung, das vielleicht aufteilen. Füge hier unten eine neue Spalte hinzu. Da haben wir es. Ich würde ihn anrufen, bevor wir sagen, bereit für die Code-Überprüfung. Und beim Code-Review. Und wenn ich mit dem Schreiben des Codes fertig bin, könnte ich ihn hier einfügen. Und dann könnte es jemand anderes abholen. Wenn sie es abholen. Es könnte hier rein gehen, also diese Spalten, es gibt keine Regeln, aber es gibt einige allgemeine Prinzipien, nach denen du wahrscheinlich eine Art Backlog willst , während er Backlog brauchte, und den brauchte er nicht. Und bei einigen Codeüberprüfungen und -tests im Gange. Dann wollen sie letztendlich in der Spalte Fertig landen. Nun wieder jede Menge großartiger Tools dafür, aber es ist schön, es auf einer sehr einfachen Ebene zu sehen. Viele Leute benutzen physische Tafeln mit Post-its, an denen sie sich orientieren würden. Das war sehr beliebt, als in den letzten Tausenden von Pandemien alle im Büro gearbeitet haben und Remote-Teams weitaus einflussreicher sind. Aber du kannst, wenn du es in einem Ein-Personen-Projekt machst, es ist trotzdem eine großartige Möglichkeit, es zu tun, weil du eine wirklich taktile Erfahrung hast eine wirklich taktile Erfahrung die Karten auf dem Brett bewegst. 12. Definition von done: Woher weißt du, wann ein Ticket in die Spalte Erledigt verschoben werden kann ? Will ein wichtiges Dokument hier ist die Definition von erledigt. In diesem Dokument wird genau beschrieben, was erforderlich ist , damit ein Ticket als erledigt gilt. Wenn wir uns also z. B. noch einmal Software ansehen, kann ein Ingenieur die Funktion erstellen. Aber das würde den meisten Definitionen von erledigt nicht entsprechen , weil es nicht so ist, es ist nirgendwohin gegangen, es wird nicht getestet. Die Definition von erledigt listet also alle Schritte auf, z. B. wurde es erstellt und getestet. Es wurde eingesetzt. Da gibt es genug Testberichte. Möglicherweise gibt es eine Überwachung und eine gewisse Protokollierung, sodass Sie speichern können, dass diese Funktion später schief geht oder nicht mehr funktioniert. Es wurde auf Leistung und Sicherheit getestet, um sicherzustellen , dass es keine Lücken oder solche Dinge gegeben hat. Bei all den zusätzlichen Schritten, bei denen Sie sagen können , dass dieses Ticket fertig ist müssen wir nichts weiter hinzufügen. Wir müssen nicht zurückgehen und es uns ansehen. Wir freuen uns, dass es da draußen in freier Wildbahn ist. In der nächsten Lektion schauen wir uns ein Beispiel Definition von Fertig an, damit Sie sehen können , wie es in der Praxis aussieht. 13. Was sind Zeremonien?: Zeremonien sind Veranstaltungen , die bei der Planung, Durchführung und Durchführung des Sprints halfen . Regel beziehen sie die Mitglieder des Scrum-Teams mit ein, aber bei einigen Zeremonien können wir uns dafür entscheiden, auch externe Stakeholder einzuladen. In diesem Modul werden wir nacheinander jede der wichtigsten Zeremonien untersuchen . 14. Tägliches Scrum: Das Daily Scrum ist ein tägliches Meeting. Normalerweise passiert das morgens, muss aber nicht und es ist wie ein Check-In für alle Mitglieder des Scrum-Teams. Es wird normalerweise im Stehen ausgeführt, daher es auf dem PC normalerweise als Stand-up bezeichnet. Cross-Agile-Begriff mehreren agilen Frameworks wird der Begriff Stand-up speziell in Scrum verwendet Er wird technisch The Daily Scrum genannt, aber es ist dasselbe. Und das Format ist jedes Mitglied sagt, was es gestern gemacht hat , woran es gerade arbeitet und welche Blockierer es gibt, also wenn etwas seiner Arbeit im Weg steht, können sie es ansprechen. Dann. Der Zweck besteht darin , allen zu helfen, einander gegenüber rechenschaftspflichtig zu sein. Und es ist auch eine gute Gelegenheit, um Hilfe zu bitten , die wir benötigen. Es ist nicht darauf ausgelegt, ein langes Meeting zu werden. Normalerweise dauert es eine Timebox von maximal 15 Minuten und es ist im Stehen fertig. Deshalb ist jeder ermutigt , es kurz und auf den Punkt zu bringen. Wenn es also etwas gibt, das weiter erörtert werden muss, hatten Sie das sogenannte Take That offline. Vereinbaren Sie also ein separates Treffen. Wir können es mit den relevanten Parteien besprechen , da die Chancen gut sind, dass nicht jeder beim Daily Scrum involviert sein muss. Deshalb beschränken wir uns wirklich auf diese kurzen Updates. Es ist nützlich, währenddessen Ihr Sprintboard geöffnet zu haben damit sich die Leute daran erinnern können, woran sie gerade arbeiten, die Tickets durchgehen und dem Rest des Teams zeigen wo sich die Tickets befinden und wie es weitergeht. 15. Backlog Verfeinerung: einem Meeting zur Verbesserung des Backlogs werden die Tickets für den Sprint vorbereitet. Wenn Sie also zum ersten Mal Ihr Produkt-Backlog erstellen, werden Sie wahrscheinlich nicht so viele Details geben, wie Sie denken, okay, Produktseite, Produktbild, Produkt, Filme. Es in diesem Ticket ziemlich einfach zu halten , ist wirklich nicht bereit , zu einem Techniker zu gehen, um zur Implementierung abgeholt zu werden. Und genau dabei hilft Backlog Refinement. Es kann also das gesamte Scrum-Team einbeziehen oder es könnte beispielsweise den Product Owner und vielleicht den Lead Engineer einbeziehen, den Product Owner und vielleicht den die zusammenarbeiten. Und die Aufgaben der Backlog-Verfeinerung R21, zerlegen das Ticket in seine kleinsten Teile. Wenn es sich bei dem Ticket also um die Produktseite handelt, kann diese weiter unterteilt werden in Bewertungen und Produktbild und die Seite selbst in nette kleine Teile. Dann müssen wir sicherstellen, dass das Ticket bereit ist , ausgegeben zu werden. Also hier sprechen wir über die Ausarbeitung der Tickets. Was genau will der Product Owner des Unternehmens? Sind die Spezifikation wirklich klar. Gibt es technische Hinweise oder Implementierungen , die dem Ticket hinzugefügt werden müssen , damit der Techniker versteht, was getan werden muss? Gibt es Hinweise zu den Testertests, um zu verstehen, was getan werden muss? Gibt es genügend Informationen damit dieses Ticket in einen Sprint aufgenommen und Bearbeitung begonnen werden kann, ohne zusätzliche Fragen stellen zu müssen. Und dann überprüfen wir alle Blocker. beispielsweise Wenn das Ticket beispielsweise lautet, die Produktrezensionen zur Produktseite hinzufügen , würde dieses Ticket durch den Aufbau einer Shell-View-Produktseite blockiert . Denn wenn diese Produktseite nicht existiert, können Sie ihr keine Bewertungen hinzufügen. Das wäre also ein Blocker und das müssten wir berücksichtigen. Damit ein Ticket die Backlog-Verfeinerung besteht, sollte es also bereit sein, in einen Sprint aufgenommen zu werden. Das heißt, es gibt keine Hindernisse, es ist einsatzbereit und es hat eine klare Definition dessen, was getan werden muss. 16. Estimating: Eines der Dinge, die Sie wissen müssen, bevor Sie ein Ticket in einen Sprint einbringen, ist , nun, wie lange wird es dauern? Ist das ein kleines Ticket und ein mittleres Ticket? Ein großes Ticket. Wir benötigen eine ungefähre Vorstellung davon wie lange das Ticket dauern wird , damit wir versuchen können, abzuschätzen, wie viel Arbeit wir in dem Sprint, den wir gerade zu planen versuchen, erledigen können . In Scope verwenden wir jetzt Punkte, anstatt Zeit zu verwenden. Und Punkte sind willkürlich, also gibt es nicht unbedingt eine Nullpunktkorrelation, die so viel Zeit in Anspruch nimmt. Sie sehen, schätzen die Punkte ab und sehen dann, wie viele Punkte Sie in einem Sprint erreichen können. Und von da an, weißt du, okay, nun, ich kann das tun, wir glauben, dass wir als Team zwei Punkte holen können . Also müssen wir beim nächsten Mal zwei Punkte holen. Nun, wie funktioniert das? Wenn Sie bereits ein paar Sprints hinter sich haben und herausfinden müssen , wie hoch Ihre Punktewerte sind. Wie. Wie fängst du damit an? Nun, da müssen Sie sich zunächst einen kleinen Zusammenhang zwischen Zeit und Punkten einfallen lassen. Also vielleicht sagst du, naja, ich würde nicht darauf hinweisen, dass ein Tag für eine Person oder ein halber Tag für eine Person ist. Wenn Sie also denken, dass Tickets der Techniker zwei Tage für den Test oder einen Tag und an einem anderen Tag Zeit für die Bereitstellung benötigt, dann sagen Sie, okay, nun, es sind vier Tage, also werden wir vorerst vier Punkte abrufen. Und bei allen Tickets auf ähnliche Weise. Und dann, wenn du die Augen zusammenkneifst und weitermachst und mehrere Sprints zu essen bekommst, fängst du an, eine Vorstellung davon zu bekommen, okay , nun, dieses Ticket beinhaltet ungefähr so viele Punkte. Implementierung wird also so lange dauern. Wir wissen, dass wir etwa 30 Punkte bis zum Sprint überstehen können. Wir können also 30 Punkte in den Spin einbringen. Ticketpunkte. 17. Agiles Poker: Eine gute Möglichkeit, Punkte zu schätzen, ist Agile Poker. Mit einigen dieser Karten kannst du sie bekommen, überall hin bekommen. Und so würde jedes Teammitglied einen Satz dieser Karten bekommen. Und die Karten haben Punktewerte , die der Fibonacci-Sequenz folgen. Du hast also etwa die Hälfte von 0,123, 581320. Diese werden 25, also kaufen sie nur sehr wenig Karten. Sie würden niemals 100-Punkte-Tickets haben. Du hast eine Unendlichkeit, die unbekannt ist. Die Idee ist also, dass jeder ein Set davon bekommt. Jeder würde sie wie ein Pokerspiel halten und du würdest schätzen, also sagst du, Okay, wir schätzen dieses Ticket jetzt. Und vielleicht, vielleicht nehme ich diesen auf. Vielleicht holt ein anderes Teammitglied das ab. Und wenn wir alle gepflückt haben, geben wir sie ab. Ich bin umsonst gegangen, jemand anderes kommt für acht. Also ein großer Unterschied, wir sprechen über diesen Unterschied und dann würden wir uns auf einen Punktewert einigen, aber er ermöglicht es jedem, eine unabhängige Schätzung abzugeben. Dann kannst du herausfinden, ob bis auf eine Person alle drei ausgewählt haben. Ich möchte wahrscheinlich nach einer kurzen Diskussion kostenlos gehen . Aber es ist eine gute Möglichkeit, die unabhängige Meinung aller einzuholen , bevor Sie wieder zusammenkommen , die Probleme besprechen und versuchen, den Punktewert zu ermitteln. 18. Geschwindigkeit: Wir haben über die Idee gesprochen die Punkte nicht unbedingt mit Spielzeiten übereinstimmen müssen. Sie können auf offene Komplexität hinweisen. Etwas wirklich Einfaches könnte also ein Punkt sein. Etwas wirklich Kompliziertes könnte man sagen, 13 Punkte. Und dann, nachdem du ein paar Sprints gemacht hast, bekommst du eine Vorstellung davon wie viele Punkte du in einem Sprint erreichst. Tatsächlich messen wir das normalerweise. Wir sehen also, wie viele Punkte wir in einem bestimmten Sprint in die Dunk-Spalte verschoben haben in die Dunk-Spalte , und das könnte alles sein. Nehmen wir an, die Dose hat 35 oder 42 oder 47 Punkte überstanden , was auch immer es ist. Nun, wenn du diese Sprinthistorie hast, also einen Sprint, hast du 55 gemacht, wenn du 42 gemacht hast, wenn es dafür nötig war, bis sieben. Nun, dann weißt du, dass du im Durchschnitt etwa 38 Punkte pro Sprint schaffst. Dieser Durchschnitt wird also zu dem , was wir die Geschwindigkeit nennen. So schnell bewegen wir uns und wie schnell wir uns bewegen liegt in diesem Fall in der Regel etwa 38 Punkten pro Sprint. Sobald Sie diese Geschwindigkeit berechnet haben, dann, Sie wissen schon, okay, naja, im nächsten Sprint können wir Dinge im Wert von ungefähr 38 Punkten einbringen, denn so viel schaffen wir normalerweise in einem Sprint. 19. Sprintplanung: Sprintplanung erfolgt zu Beginn jedes Sprints. Sie vereinbaren eine Sprintdauer und ermitteln dann, wie viele Punkte Sie Ihrer Meinung nach in dieser Zeit erreichen können. Wenn Sie also, sagen wir, in einem zweiwöchigen Sprint arbeiten und eine Geschwindigkeit von 38 Punkten haben, dann bringen Sie mit den Tickets wahrscheinlich 38 Punkte ein. Wenn du es aus irgendeinem Grund kürzen würdest. Also vielleicht, wenn du einen einwöchigen Sprint machst, dann wird dir Maps sagen, dass du in der Hälfte der Zeit etwa 19 Punkte erreichen kannst . Du berechnest, mit wie vielen Punkten du spielen musst. Und dann bringen Sie eine angemessene Anzahl von Tickets mit, um diesen Punktewert aufzufüllen. Wenn Sie also 38 Punkte zum Spielen haben, gehen Sie zu Ihrem Produkt-Backlog und wählen Tickets im Wert von 38 Punkten aus, und diese werden zu Ihrem Sprint-Backlog. ist also die To-Do-Liste für den Sprint, an dem Sie gerade arbeiten. An diesem Punkt kann die Schätzung bei Verfeinerung oder bei der Sprintplanung geschehen , wenn sie nicht in der Verfeinerung, Verfeinerungen, einer guten Idee passiert ist. Wenn sie bereits erledigt sind und Sie die Sprintplanung durchführen, paar Personen an der Verfeinerung und Sprintplanung beteiligt ist es vielleicht ein guter Zeitpunkt, um zu überprüfen , ob alle mit den Punkten einverstanden sind, wenn ein an der Verfeinerung und Sprintplanung beteiligt sind. Und daher ist das eine vernünftige Arbeit , die Sie in diesem Sprint erledigen können. Sobald Sie fertig sind, können Sie Ihren Sprint starten und sich an die Arbeit an all diesen Tickets machen. 20. Retrospektive: Die Retrospektive, kurz auch Retro-Road genannt, findet am Ende eines Sprints statt. Hier siehst du, was gut funktioniert hat und was nicht so gut funktioniert hat, damit wir herausfinden können , was wir in Zukunft verbessern wollen. Es ist wichtig zu beachten, dass es sich hier eher um ein Prozesstreffen als um ein Treffen über die Arbeit selbst handelt. Nehmen wir an, wir hatten ein Ticket, das wir für Sprint gekauft haben , und dann stellte sich heraus, dass es einen Blocker hat. Und so konnten wir nichts tun. In diesem Sprint wurde es nicht geschafft. Im Retro-Stil würden wir nicht darüber sprechen, wie man das Ticket entsperrt, damit wir es erledigen können. Aber wir könnten über Dinge sprechen wie, nun ja, warum wir nicht bemerkt haben, dass es einen Blocker hat und deshalb ins Stocken geraten ist. Und was können wir in Zukunft tun , um sicherzustellen, dass wir keine Tickets einbringen , die nicht in einem Sprint abgeschlossen werden können. Sie kommentieren also wahrscheinlich einige der Tickets, an denen Sie gearbeitet haben, und zu den Problemen, die diese gekauft haben. Aber wir kommentieren die Arbeit nicht direkt, sondern mehr darüber, wie wir als Team in Zukunft besser zusammenarbeiten können , um das amerikanische Team noch schneller und effizienter zu gestalten. Du kannst Retro machen , wie du willst. Aber in der nächsten Lektion habe ich ein paar Ideen für dich. 21. Ideen für Retrospektiven: In dieser Lektion werden wir uns einige Ideen für die Durchführung Ihrer Retrospektiven ansehen. Das ist also wirklich ein Ausgangspunkt und du denkst dir deine eigenen Ideen aus, machst Dinge kreativ, hast Spaß damit. Einer der Klassiker ist Start, Stop, Continue. Geben Sie also jedem in Ihrem Team einen Markierungsstift und einige Post-its und hängen Sie sie an die Wand oder hören Sie auf, beginnen Sie und fahren Sie fort. Und die Leute können ihre Vorschläge für Dinge schreiben , mit denen wir aufhören sollten, Dinge, mit denen wir beginnen sollten, und Dinge, die wir weiterhin tun sollten. In diesem Beispiel, z. B. den Vorschlägen, werden wir aufhören, zu spät zu Besprechungen zu erscheinen und lange Diskussionen im Stand-up zu führen. Vielleicht stehen sie im Weg. Also konzentriert sich das Team im nächsten Sprint bewusst darauf, diese Verhaltensweisen zu beenden als die Milben, Dinge, mit denen wir beginnen wollen, vielleicht werden Retrospektiven immer in letzter Minute organisiert und daher wäre es hilfreich, einen Besprechungsraum zu buchen , und dann geht es weiter. Also haben wir vor Wochen angefangen, einen neuen Testserver zu verwenden einen neuen Testserver zu , als das wirklich gut funktioniert. Lass uns, lass uns das weitermachen. Eine andere Möglichkeit, dies zu tun, besteht darin, Punktzahlen zu verwenden. Sie könnten also Überschriften haben wie Wie selbstbewusst werden Sie dieses Projekt umsetzen? Wie viel Energie haben wir Ihrer Meinung nach als Team und wie psychologisch können Sicherheitsfeld und jedes Teammitglied eine Punktezahl angeben. Es kann dort anonym veröffentlicht werden. Und dann können Sie sich diese Zahlen ansehen und Ihren Fortschritt im Laufe der Zeit verfolgen. Also mach das vielleicht alle paar Monate und schau, wie es sich ändert. Aber auch wenn Sie es bemerken, unser Selbstvertrauen wirklich gesunken oder die Sicherheit ist wirklich gesunken. Was machen wir als Team , das wir verbessern können? Vielleicht werden wir mehr über dieses Thema sprechen. Lean Coffee ist ein Meeting-Typ, gut im Retro-Stil eignet, aber auch außerhalb der U-Bahnen. Und das passiert so, dass es keine vorher festgelegte Agenda gibt. Die erste Aufgabe besteht also darin, eine Agenda zu erstellen. Und nochmal, vielleicht, gib es vielleicht allen, es zu posten. Manche Leute schreiben das, was sie besprechen möchten , auf ein Post-it , hängen es an eine Wand, und dann kann das gesamte Team über eine Reihenfolge für die Diskussion abstimmen. Du redest also so, als würdest du die fünf wichtigsten Dinge auswählen, über die du sprechen möchtest, neue Timebox, jedes davon. Nehmen wir an, das Team möchte darüber sprechen, wie wir Stand-ups machen. Als Erstes stellst du einen Timer 5 Minuten ein und du führst eine Diskussion für fünf Minuten. Und wenn der Alarm losgeht, kann das Team entweder sagen, wir wollen mehr darüber sprechen, lasst uns weiter über Stand-ups sprechen. Oder wir wollen zum nächsten Thema übergehen. Und wenn das Team dafür stimmt, weiterzumachen, nimmst du den zweiten Beitrag und sprichst das durch. Und wieder machst du dasselbe. Er unterrichtete 5 Minuten. Am Ende dieser fünf Minuten entscheiden Sie, wo mehr Zeit benötigt wird oder ob Sie weitermachen möchten. Und dann endlich Teambuilding. Nicht an jeder Retrospektive muss gearbeitet werden , damit ein Team zusammenarbeitet. Dinge wie Smalltalk, Dinge wie Spiele, Dinge wie Teambuilding-Aktivitäten können wirklich wichtig sein , um dieses Team zusammenzusperren. Wenn das Team also müde ist oder nicht, es eine ziemliche Herausforderung, wie du es dir wünschst, dann können auch unterhaltsame Teambuilding und Spiele sehr gut sein. 22. Arbeitsweisen: Äh, bei einem Arbeitstreffen einigt sich das Team darauf, wie es zusammenarbeiten wird. Jedes Team ist also anders und die Mitglieder möchten möglicherweise für verschiedene Teams auf unterschiedliche Weise arbeiten. Also Fragen wie, Nun, kannst du jedes Ticket aus dem Backlog abholen oder muss es das oberste sein? Ordnen Sie es der nächsten Person zu oder lassen Sie es leer und lassen Sie es der Person überlassen zu übernehmen, was in unserer Definition von erledigt ist. Wann finden die Zeremonien statt und wen werden wir einladen? Wie lang wird Sprint dauern? All dies sind Prozessfragen , auf die sich das Team einigen muss. Und Sie würden das alles in einem Arbeitstreffen besprechen . Normalerweise müssten Sie sich treffen, wenn Sie ein neues Team bilden und loslegen. Aber auch, wenn viele Teammitglieder gehen und neue Mitglieder hinzukommen, oder es ist einfach eine Teammitglieder gehen und neue Mitglieder hinzukommen, Weile her , dass Sie eine Verletzung hatten und Sie einige der Regeln des Teams neu aushandeln möchten , dann ist die Einberufung eines Ways of Working Meeting eine wirklich gute Möglichkeit, dies zu tun. Schlüssel zum Erfolg liegt darin, sicherzustellen, dass jeder eine Stimme hat und jeder seine Meinung darüber hat, was funktioniert und was nicht, wie er die Dinge gerne machen würde. Und dann alle dazu zu bringen, sich darauf zu einigen, damit jeder im Team diese Arbeitsweise wirklich akzeptiert und alle zusammenarbeiten, um sich gegenseitig zu unterstützen. 23. Sprint: Eine Überprüfung findet am Ende eines Sprints oder nach dessen Abschluss statt. Der Zweck der Überprüfung besteht darin , die geleistete Arbeit zu überprüfen und zu demonstrieren. Also sind alle eingeladen, jeder aus dem Scrum-Team und auch externe Stakeholder wollen herausfinden, was das Team ebenfalls gemacht hat. Das Team demonstriert abwechselnd die einzelnen Funktionen. Und es kann Fragen von externen Stakeholdern geben. In der Regel behalten wir diese bis zum Ende der Bewertungen, in denen alles aufgeführt ist, und geben dann Feedback. Zu diesem Zeitpunkt sind alle Tickets fertig. Wenn es also Änderungen gibt, wenn zusätzliche Arbeit anfällt , sollten diese als neue Tickets gesammelt werden. 24. Scrum Team: Bei Scrum dreht sich alles Teamarbeit und Scrum-Teams sind funktionsübergreifend. Was heißt das? Nun, früher waren die Teams vielleicht nach Berufsbezeichnungen organisiert. Sie hätten also ein Team von Designern hier, ein Team von Ingenieuren hier, ein Team von Testern hier. Und wenn Sie etwas entwerfen möchten, schicken Sie es an den Designpool. Und der Designpool würde an allem arbeiten und es dann zurückgeben. alles, was Design für das gesamte Unternehmen benötigte, wenden wir uns an ein bestimmtes Designteam. Scrum-Teams funktionieren so überhaupt nicht. Sie sind funktionsübergreifend im Scrum-Team und sollten alles haben, was es braucht. Ein Scrum-Team würde sagen, einen Designer und Ingenieur, einen Tester, welche Ziele auch immer ein Business Analyst sein mag , das alles ist im Team enthalten. Also, anstatt zu den Designern, zu den Ingenieuren oder zum Text gehen zu müssen, ist alles, was Sie brauchen, in einem Team zusammengefasst. Teams sind also quasi eine mobile Einheit im Militär, die unabhängig operieren kann, ohne von anderen Teams blockiert zu werden , ohne gehen zu müssen. Wir benötigen dafür einen Tester, aber es ist kein Test verfügbar. Alles ist im Team enthalten. Wenn wir also versuchen, unseren Sprint-Backlog zu überstehen , versuchen wir, unsere Tickets zu liefern, die nicht von anderen Personen blockiert wurden . 25. Produkteigentümer: Der Product Owner ist letztendlich für das Produkt oder Projekt verantwortlich. Es geht also darum, Entscheidungen und Prioritäten zu treffen, wie das Projekt aussehen wird und wie es funktionieren wird. Also, wenn wir zum Beispiel an unsere E-Commerce-Produktseite denken, wird sie genau aussehen? Wohin geht, wo, wie wird die Benutzererfahrung anfühlen? Und auch Prioritäten, z. B. welcher Teil des Systems sollte zuerst erstellt werden? Sollte es die Produktseite sein, die das Surfen überprüft? Welcher Teil? Was es nun nicht ist , sind technische Rollen. Wenn ich also sage, wie es funktionieren wird, ist das in erster Linie eine Sache der Benutzererfahrung. Vorstellung, der Kunde zu sein, der dieses Ding benutzt, und nicht irgendein technisches Wissen. Das gesamte technische Wissen bei den Ingenieuren und der Product Owner muss nicht wirklich wissen, wie es umgesetzt wird. Sie sagen, was sie umsetzen wollen. Jetzt sollte jedes Produkt einen Product Owner haben. Wenn ja, denken Sie darüber nach, zwei Product Owner für dasselbe Produkt zu engagieren. Sie müssen das Produkt wahrscheinlich aufteilen. Ein Product Owner könnte sich jedoch um mehrere Produkte kümmern. Wenn Sie also viele kleine Produkte haben kann sich ein Product Owner um mehrere davon kümmern. Was einen guten Product Owner ausmacht jemand, der weiß, was er will, aber auch flexibel ist, wenn etwas nicht machbar ist. wir zum Beispiel Nehmen wir zum Beispiel an, Sie bauen ein Haus. Der Product Owner ist die Person, die sagt: Okay, nun, ich würde gerne Schlafzimmer und Badezimmer und Garage besuchen. Aber wenn die Planungskommission zurückkommt und sagt, nun , Sie können keine Garage haben, wollen Sie den Product Owner , der bereit ist zu sagen, okay, lassen Sie uns das ändern und ich spezifiziere etwas anderes. Aber hat eine klare Vision, die er dem Team geben kann, um den Ingenieuren mitzuteilen, wonach sie suchen. 26. Scrum-Master: Der Scrum Master hilft dem Scrum-Team, reibungslos zu arbeiten. Trotz des Namens Master sind sie also tatsächlich ein weiteres Mitglied des Teams und sie sind auf dem gleichen Level. Sie sind nicht der Chef des Teams. Sie organisieren und moderieren Zeremonien, jedoch auf Wunsch des Teams. Es muss also nicht unbedingt vom Scrum Master gemacht werden. Jeder kann eine der Zeremonien leiten , jedes Teammitglied kann vortreten und sagen: Nun, ich werde das Retro verlassen, ich werde das tägliche Scrum verlassen oder wenn sie es vorziehen, kann der ScrumMaster das tun. Typische Aufgaben für einen ScrumMaster könnten darin bestehen, Besprechungsräume zu buchen und die Zeremonien zu moderieren und mit anderen Leuten über Blockierer zu sprechen. Wenn das Team also mit einem anderen Team kommunizieren muss , um etwas mit den Schulleitern zu lösen, ist es eine gute Person, die das Team dorthin schicken kann, um das Team bei größeren Unternehmenssitzungen zu vertreten. Wir werden in Scaling Squirm etwas mehr darüber sprechen. Aber wirklich immer dann, wenn das Team mit dem Management sprechen muss, muss es mit einer anderen Gruppe sprechen . Der Squamous ist eine wirklich gute Person, um sie zu vertreten und sicherzustellen, dass die Regeln eingehalten werden. Wenn wir uns also in einem Arbeitstreffen auf etwas einigen, zum Beispiel, dass wir alle pünktlich zu unserem Daily Scrum um die Hälfte kommen und die Leute nicht pünktlich erscheinen, dann ist es in der Regel Sache des Schulmeisters, sie nicht abzuweisen Arbeitstreffen auf etwas einigen, zum Beispiel, dass wir alle pünktlich zu unserem Daily Scrum um die Hälfte kommen und die Leute nicht pünktlich erscheinen, dann ist es in der Regel , sondern zu sagen: Hey, nur zur Erinnerung. Wir waren uns einig, dass wir alle um halb neun da sein würden und keiner von Ihnen coacht und motiviert auch das Team. Der Scrum Master verfügt in der Regel über gute Kenntnisse und ein Team für die geleistete Arbeit zu begeistern , einbringen von Agile und Scrum und kann diese Empfehlungen als großartige Art, in das Team zu arbeiten und ein Team . 27. Geschäftsanalysten: Business Analysten, auch kurz BA genannt, sind an der Erfassung von Anforderungen beteiligt. Welches Team hätte normalerweise ein oder zwei BAs. Und ihre Aufgabe ist es, die Benutzeranforderungen zu verstehen und eine Brücke zwischen den Wünschen des Product Owners und dem, was die Ingenieure wissen müssen, zu schlagen. Der Product Owner könnte etwas sagen wie: Ich möchte, dass Kunden ihre Lieferungen verfolgen und sehen können, wo sich ihre Lieferungen befinden. Die BA würde weggehen und das in eine Kundenreise unterteilen . Also z.B. der Kunde, als Kunde möchte ich meine Bestellungen als Kunde einsehen können . Ich möchte als Kunde die Details einer bestimmten Bestellung sehen , ich möchte die Tracking-Informationen für die Karriere sehen , an die die Bestellung gesendet wurde. Deshalb würden sie die allgemeine Anfrage des Produktinhabers in Tickets aufteilen und Akzeptanzkriterien entwickeln. Wie werden wir also wissen, wann es fertig ist, z. B. wenn wir uns als Kunde ein Ticket ansehen ich die Tracking-Informationen sehen möchte. Die Akzeptanzkriterien wären beispielsweise, dass der Kunde die Sendungsverfolgungsnummer lesen kann. Der Kunde kann auf einen Link klicken, um zur Karriere-Website zu gelangen und weitere Informationen zu erhalten. Und vielleicht sind das die Akzeptanzkriterien für dieses Ticket. Die BA ist also dafür verantwortlich, diese Gesamtanforderungen in spezifischere Anforderungen umzusetzen diese Gesamtanforderungen in , mit denen die Ingenieure arbeiten können. 28. Ingenieure: Die Ingenieure oder die Leute , die an dem Ding arbeiten, was auch immer das Ding ist, an welchem Projekt Sie arbeiten. Daher wird es oft als Entwicklungsteam bezeichnet , aber es umfasst ein breiteres Feld als dieses. Also Dinge wie Tester, Automatisierungstechniker, Qualitätssicherungsingenieure, all diese Leute würden darin enthalten sein. Und es hängt wirklich davon ab, an welcher Art von Projekt Sie arbeiten , was das beinhalten würde. In einem Softwareprojekt hätten Sie Ihre eigentlichen Softwareingenieure und wahrscheinlich einige Ingenieure für Testautomatisierung. Und dann sind die Tests sie selbst. Aber wenn Sie beispielsweise an einem Forschungsprojekt arbeiten, dann sind Sie Ingenieure. Das Entwicklungsteam wäre eigentlich das Forschungsteam oder die Forscher. Wenn Ihr Projekt darin besteht, ein Haus zu bauen , dann sind es vielleicht Bauarbeiter , Arbeiter für Männer , solche Dinge. In gewisser Hinsicht neu, spielt es keine Rolle, da in Scrum ein echter Fokus darauf liegt, als Team zusammenzuarbeiten , um Tickets zu liefern. Sie mögen also Ihre individuellen Rollen haben , ich bin Designer, ich bin Software-Ingenieur, ich bin ein Test oder was auch immer es ist, aber was wirklich zählt, ist der Output des Teams. Also überall dort, wo alle an ihren Rollen festhalten , verschiedene Dinge tun sich gegenseitig helfen. Was wichtig ist, ist, dass alle zusammenarbeiten , um dieses Sprintziel zu erreichen, um diese Tickets zu liefern , und sich nicht so sehr darauf zu konzentrieren , alle in dieses Designteam zu unterteilen. Das ist das Implementierungsteam, das ist das Testteam. Es gibt nur ein Scrum-Team von allen , die zum Erfolg des Projekts beitragen. 29. Stakeholder: Stakeholder sind Personen außerhalb des Teams, jedoch Interesse an der Arbeit des Teams haben. Also, was für Leute könnten das nicht sein? Nun, einige Beispiele: unsere Unternehmensleiter, Mitglieder anderer Teams, die an verwandten Projektlösungen arbeiten , Architekten und technische Architekten die im gesamten Unternehmen arbeiten. Marketing- und Vertriebsteams. Juristische Angelegenheiten könnten ebenfalls einbezogen werden, und möglicherweise wären auch Kunden, Lieferanten und Aufsichtsbehörden beteiligt. Product Owner luden oft Stakeholder zu den Sprint Reviews ein, und sie sind auch herzlich eingeladen , am Daily Scrum teilzunehmen. Aber sie hätten keinen Input zu The Daily Scrum, also könnten sie kommen und zuhören, aber es werden die Mitglieder des Scrum-Teams sein, die das Gespräch geführt haben. Stakeholder würden in der Regel nicht zur Sprintplanung oder Retrospektive eingeladen , da dies eine sichere Zone für das Team ist , um ihre Arbeit intern zu besprechen. 30. Ein typisches Scrum-Team: Schauen wir uns ein typisches Scrum-Team an. Im Team haben wir also wahrscheinlich einen Product Owner, einen Scrum Master und abgenutzte oder mehr Business-Analysten. Also ein Product Owner, Scrum Master, in der Regel ein oder zwei Business Analysten. Und dann haben wir Ingenieure. Ingenieure decken wirklich jeden der Macher ab. Also Entwickler, Designer, QA-Tester, Forscher, wenn Sie an einem Forschungsprojekt arbeiten, und Arbeiter, wenn Sie ein Haus bauen, was auch immer es ist, das sind die Leute, die die eigentlichen Tickets machen. Und dann gibt es außerhalb des Teams Stakeholder. Dazu könnten also Unternehmensleiter, Mitglieder anderer Teams, Marketing- und Vertriebsrecht, Kunden und Lieferanten sowie Aufsichtsbehörden gehören. 31. Hinzufügen von Teammitgliedern: Wenn Sie Ihrem Team Mitglieder hinzufügen, wie berücksichtigen Sie das dann? Der Arbeitsaufwand , den sie bei der Planung zukünftiger Sprints erledigen können . Nun, das erste, was wir tun wollen, ist unsere Geschwindigkeit und unsere Punkte pro Teammitglied zu berechnen . Nehmen wir an, unsere Geschwindigkeit ist 48 und das Team besteht derzeit aus sechs Mitgliedern. Dann können wir 48 durch sechs teilen und wir können sehen, dass jedes Teammitglied ungefähr acht Punkte erzielt. Wenn wir dann ein neues Teammitglied hinzufügen, wissen wir, dass wir weitere acht Punkte haben werden , mit denen wir spielen können. Das bedeutet, dass wir beim ersten Sprint normalerweise einen Multiplikator von Nullen verwenden. Wir gehen also davon aus, dass sie für den ersten Sprint keine Punkte sammeln werden. Zweiter Sprint, wir werden fit sein, wenn es acht Punkte wären, wird die Zeit um 0,5 steigen und das gibt uns vier Punkte. Und beim dritten Sprint gehen wir davon aus, dass sie auf dem Laufenden sind und ihren Beitrag leisten, was bedeutet, dass sie dem Team alle acht Punkte geben können. 32. Ausgabearten: In dieser Lektion werden wir uns Problemtypen oder Tickettypen befassen. Und es gibt drei primäre. Die erste ist also eine User Story. Das ist also eine neue Funktion die aus der Sicht eines Benutzers oder eines Produkts geschrieben wurde , die aus der Sicht eines Benutzers oder eines Produkts geschrieben wurde. Als Benutzer möchte ich beispielsweise Produktbewertungen für das Produkt sehen können , das ich mir gerade ansehe. Es fügt dem System etwas Neues hinzu. Dann haben wir einen Fehler oder ein Buch, ein Buch mit einer vorhandenen Funktion, die behoben werden muss. Wir haben es bereits verschickt und es muss repariert werden. Also müssen wir ein Ticket besorgen. Nun wichtig hier, es ist nur ein Bug, wenn es nicht so funktioniert , wie es beabsichtigt war. Also, wenn wir etwas auf eine bestimmte Art und Weise bauen und der Manager sagt, ich möchte, dass es anders funktioniert . Das ist kein Fehler, das ist eine neue Benutzergeschichte die die Funktionsweise des Systems verändert. Wenn das Originalticket die Akzeptanzkriterien erfüllt, handelt es sich nicht um einen Defekt. Wenn es nicht das tut, was auf dem Originalticket steht, dann ist es und erhöhen Sie es als Bulk. Und dann haben wir technische Schulden. Das sind also Probleme mit dem Code, die keine beobachtbaren Auswirkungen auf das System haben. Also etwas darunter , von dem der Entwickler weiß, dass wir es reparieren müssen, aber ein Benutzer würde es eigentlich nicht unbedingt bemerken. 33. Benutzergeschichten: In Agile schreiben wir Tickets als User Stories. Das heißt, anstatt ein Ticket zu haben , auf dem so etwas wie Anmeldeformular steht, schreiben wir so etwas wie „Als Kunde möchte ich meinen Bestellstatus überprüfen“. Nun, das würde oft ein Anmeldeformular beinhalten damit sie sich anmelden und ihre Bestellungen sehen können , aber vielleicht nicht. Warum schreiben wir es also in diesem seltsamen User Story-Format? Welche Geschichten sorgen dafür, dass der Benutzer im Mittelpunkt steht. uns dreht sich also alles um die Customer Journey, bei der wir alles, was wir erstellen, durchgehen und auf diese Weise schreiben , sodass der Endnutzer wirklich im Mittelpunkt steht. Zweitens verhindert es unnötige Arbeit. Also, wenn du so etwas hast wie, ich möchte meine vorherigen Rechnungen sehen, die ein Login-Formular erfordern. In der nächsten Lektion schauen wir uns eine gute Fallstudie an , die zeigt , dass das vielleicht nicht immer der Fall ist. Und deshalb können wir uns etwas Arbeit sparen , wenn wir diese User Stories verwenden. Es schafft sehr klare Akzeptanzkriterien. Auf deinem Ticket steht Login-Formular. Nun, woher wissen Sie, ob der Benutzer in der Lage ist, das zu erreichen, was er erreichen möchte? Wollen sie sich anmelden? Welchen Zweck haben sie damit? Wenn es dagegen so ist, wie ich es als Kunde möchte, möchte ich meinen Bestellstatus überprüfen. Es ist sehr klar, wo das V0-System das macht oder nicht. Kann der Kunde seinen Bestellstatus sehen? Ja oder nein? Sie haben da einige wirklich klare Akzeptanzkriterien. Und deshalb verwenden wir User Stories. 34. Verhaltensorientierte development: Worüber wir hier sprechen, wenn wir auf diese Weise Geschichten schreiben , ist verhaltensorientierte Entwicklung. Dies ist eine Methode , die besagt, dass wir in einfachem Englisch schreiben, was die Benutzer tun können sollten. Und das wird dann zu unseren Akzeptanzkriterien. Wir schreiben automatisierte Tests dagegen , um zu sehen, ob das System das tut. Und nehmen wir an, es gibt eine Menge Arbeit und ich habe eine Fallstudie für Sie. Es gab also eine Wirtschaftsprüfungsgesellschaft und was sie wollten , dass Kunden frühere Rechnungen einsehen konnten. Wenn wir uns einfach darauf eingelassen und es auf die normale Weise aufgebaut hätten, hätten wir gesagt: Nun, okay, wir brauchen ein Anmeldeformular und jeder Kunde benötigt ein Login, also müssen sie ihre E-Mail-Adresse eingeben und dann benötigen sie ein Passwort. Also der Kunde, wir hätten in diesem Meer von Tausenden von Passwörtern noch ein Passwort , das wir uns merken müssten, und er vergisst es wahrscheinlich. Dann müssten wir also einen Link für ein vergessenes Passwort erstellen Link für ein vergessenes Passwort , der ihnen ein neues Passwort per E-Mail sendet. Wenn sie also unweigerlich ihr Passwort vergessen hatten, konnten sie ein neues anfordern. Sie könnten ihr Passwort zurücksetzen und sich dann anmelden und die alten Rechnungen sehen. Stattdessen verwendet dieses Produkt diese Benutzerberichte und die verhaltensorientierte Entwicklung. Die Annahmekriterien waren also, dass ich als Kunde frühere Rechnungen einsehen möchte. Als das Projekt dann so betrachtet wurde, wurde ihnen klar, dass es am einfachsten war, dem Kunden die Eingabe seiner E-Mail-Adresse zu ermöglichen. Und es würde ihnen per E-Mail einen magischen Link senden, über den sie alle ihre vorherigen Rechnungen sehen könnten . Anstatt also das gesamte Anmeldeformular und das Formular „Passwort vergessen“ erstellen zu müssen, anstatt dass sich der Benutzer ein anderes Passwort merken muss, indem er es aus der Sicht der Benutzergeschichte betrachtet, wurde allen klar, dass der schnellste Weg, dies zu tun, darin besteht ihnen einfach per E-Mail einen Link zu senden, über den sie darauf zugreifen können. Und es ist genauso sicher wie ein Login, weil Sie den E-Mail-Zugang haben und sie dann alle ihre vorherigen Rechnungen einsehen können , ohne dass viel Entwicklungsarbeit erforderlich ist und ohne dass der Benutzer ein Entwicklungsarbeit erforderlich ist und ohne dass der Benutzer weiteres Passwort speichern muss. Verwendung dieser Benutzerberichte dieser verhaltensorientierte Entwicklungsansatz kann dieser verhaltensorientierte Entwicklungsansatz eine Menge Zeit sparen und auch zu einem besseren Erlebnis für den Kunden führen . 35. „gut genug“ sein: Ein Schlüsselkonzept dabei ist die Idee dass etwas gut genug ist. Wir müssen das Feature erstellen, bis es den Benutzeranforderungen, den Akzeptanzkriterien, entspricht. Und dann müssen wir anhalten und das Ticket schließen. Und wenn wir später noch mehr arbeiten müssen, können wir ein neues Ticket beantragen. Aber im Grunde genommen, was wir zu erfüllen versuchen, was muss erfüllt werden, vorausgesetzt, wir benötigen all diese zusätzlichen Dinge. Nehmen wir zum Beispiel an, wir sprechen darüber, dass wir unseren E-Commerce-Shop haben und Sie können die Produktseite aufrufen und wir möchten ähnliche Produkte zeigen. Und vielleicht ist die Benutzergeschichte, dass ich als Benutzer ähnliche Produkte sehen möchte. Nun, wir könnten loslegen und ein äußerst komplexes KI-System entwickeln , das Produkte empfiehlt. Wir könnten dort aber auch einfach Produkte anbieten, die zur gleichen Kategorie gehören dort aber auch einfach Produkte anbieten, die zur gleichen Kategorie die die Benutzeranforderungen erfüllen würden. Und wir würden nicht mit einer riesigen Entwicklungsaufgabe enden, denn vielleicht nur die ähnlichen Produkte und dieselbe Kategorie zu zeigen wäre es wirklich großartig, nur die ähnlichen Produkte und dieselbe Kategorie zu zeigen. Und das können wir sehr schnell versenden und das würde funktionieren. Wir würden nicht wirklich davon profitieren , ein riesiges KI-System zur Produktempfehlung aufzubauen . Oder vielleicht versenden wir das Einfache. Und dann stellen wir fest, dass wir tatsächlich einen großen Nutzen daraus ziehen würden , bessere Produktempfehlungen zu haben. An welchem Punkt können wir das Bessere bauen, weil wir dann wissen, dass es sich lohnt, die Zeit zu investieren. Dies ist die sogenannte Lean-Methode. Sie erhalten also etwas in unserer Grundform. Man sieht für solche Benutzer, man sieht, worauf sie reagieren, und dann evaluiert man und geht wieder los, genau wie wir über diese agilen Methoden gesprochen haben, iteriert, liefert etwas, sagt, wie es funktioniert, verbessert es, anstatt dieses riesige Urknall-Produkt zu entwickeln dieses riesige Urknall-Produkt das von Anfang an scheitern könnte. 36. Investieren: In dieser Lektion schauen wir uns das Akronym invest an , das für gute User Stories verwendet werden kann . Also ich bin für jedes unabhängige, jedes Geschäft sollte für sich stehen und ist verhandelbar. Geschichten sind nicht festgelegt, können aber bei Bedarf aktualisiert werden. also frustrierend, diesen Input und Dinge wie selbst zu Beginn der Implementierung einzubringen , werden kann wenn etwas aufgrund technischer Anforderungen nicht getan Es ist also frustrierend, diesen Input und Dinge wie selbst zu Beginn der Implementierung einzubringen, wenn etwas aufgrund technischer Anforderungen nicht getan werden kann, aber vielleicht müssen Sie sich ansehen, wie Sie die Geschichte überarbeiten. Wenn das der Fall ist, steht V für wertvoll, es muss einen echten Mehrwert für den Benutzer bieten. Wie wird der Benutzer aufgrund dieser Änderung ein besseres Erlebnis erhalten ? E steht für Schätzbar. Sie müssen also eine ungefähre Vorstellung davon haben , wie lange es dauern wird. Wenn Sie es nicht abschätzen können, müssen Sie wahrscheinlich ein Ermittlungsticket ausstellen. Ein Ticket, das ist wie als Entwickler, ich möchte untersuchen, wie lange es dauern würde, diese Funktion zu implementieren. Und dann planen Sie das, sagen wir, einen halben Tag und schauen Sie, ob Sie einen groben Zeitplan ausarbeiten können. Anhand dieses Zeitrahmens wissen Sie dann, ob Sie mit dem Ticket fortfahren möchten oder nicht. S steht für klein, sodass es innerhalb eines einzigen Sprints geliefert werden kann. Alles, was mehrere Sprints erfordert, muss weiter aufgeschlüsselt werden. Und T ist testbar. Klare Akzeptanzkriterien, wie würde ein Benutzer wissen, ob dieses Ticket vollständig ist? Und im Idealfall haben wir auch Tests automatisiert. Also denke ich wirklich darüber nach, wie wir es von Anfang an in automatischer Testabdeckung testen können . 37. Prototyping und Prototyping: Eine kooperative Mischung aus Agile und Lean besteht darin, es schnell erstellen, etwas zu erstellen, es dem Benutzer vorzustellen und zu sehen, wie das funktioniert. Ein guter Weg, dies zu tun, ist das Prototyping. Sie können also etwas wie Adobe XD verwenden , um Scheinbenutzeroberflächen zu erstellen. Und dann können Sie das einem Benutzer geben. Sehen Sie, wie sie das System verwenden, sehen Sie, wie sie damit umgehen, nehmen Sie einige Änderungen vor, bevor Sie die komplizierte Software selbst erstellen . Wie machst du das? Nun, du simulierst es in so etwas wie Adobe XD. Und dann würdest du einen Beispielbenutzer bitten , vielleicht in ein Labor zu kommen. Du würdest sie filmen, die Leinwand filmen. Schau ihnen dabei zu und mach dir Notizen, okay, was für sie funktioniert. Nehmen Sie einen Dialog mit ihnen auf und sagen Sie: Okay, nun, okay, ich möchte, dass Sie dieses Produkt finden. Wie würdest du das angehen? Gehen sie stöbern und suchen und sehen sich die Bestellhistorie an, um zu sehen, ob sie sie zuvor gekauft haben, und sie können den Link auf diese Weise finden. Welche Methode wird für sie am besten sein. Du gibst ihnen die Demo und bittest sie, die Aufgabe zu erledigen. Du sprichst mit ihnen darüber, was sie sich vorstellen sie dazu zu bringen, mit dir zu reden, okay? Ich habe gesagt, versuche dieses Produkt zu finden. Woran denkst du jetzt? Und der Benutzer könnte sagen: Oh, nun, ich verwende wahrscheinlich eine Suche, und die Suche ist meine bevorzugte Methode, dies zu tun. Und dann könnten sie suchen und hochkommen. Auf diese Weise wissen wir genau, wie ein Benutzer möchte, dass das System funktioniert, und ob wir es an einem Ort finden, an dem wir das System erstellen können und ob wir es an seine Bedürfnisse anpassen können. Vieles davon ist zeitaufwändig, aber jemanden zu bitten, in Ihr Büro zu kommen, ein Labor einzurichten, in dem Sie eintragen können, was vor sich geht oder schauen und ihm eine Reihe von Aufgaben geben können. Das alles braucht Zeit, aber diese Zeit zahlt sich wirklich aus, wenn Sie etwas liefern , das genau den Wünschen des Kunden entspricht. Wenn du sehen kannst, wie sie das System verwenden, optimiere es um sie herum und hol dir dieses Feedback vom ersten Tag an. Anfangs nimmt es viel Zeit in Anspruch, aber dann ist Ihre Entwicklungszeit viel kürzer weil Sie genau das bauen, was sie wollen. Gegensatz zu herkömmlichen Systemen würden Sie den großen Entwicklungsblock erledigen. Dann stellte sich heraus, dass es nicht das war, was sie wollten, und wir müssen das Ganze neu gestalten, indem wir diese Zeit frühzeitig investieren. Wir können dann genau das erstellen, was der Benutzer möchte, und diese Funktionalität schneller bereitstellen. Das ist richtig, genau das, was sie tun müssen. Und das können wir durch Dinge wie Rapid Prototyping und User Labs tun. 38. Funktionelle Anforderungen: Funktionale Anforderungen sagen Ihnen, was das System können sollte. Wenn wir beispielsweise sagen, dass wir versuchen, unseren Bestellstatus zu überprüfen, könnte die funktionale Anforderung darin bestehen, dass der Benutzer den Status sehen kann und die anderen Kunden die Bestellung des bestimmten Kunden nicht sehen können. Oder wenn wir ein Anmeldesystem erstellen, z. B. per Passwort, per E-Mail, erfolgt es über eine Zwei-Faktor-Authentifizierung? Und wie sind die Passwörter? Zurücksetzen? Gibt es also einen Reset-Mechanismus? Vielleicht sollten die Benutzer in der Lage sein, sollten aufgefordert werden, ihr Passwort alle 90 Tage zu ändern . All diese Dinge sind funktionale Anforderungen, da funktionale Anforderungen die Funktionen des Systems dokumentieren. Sie dokumentieren, wie das System funktioniert. Nicht geringfügig anders als bei nicht funktionalen Anforderungen. Und wenn ich weiter darüber spreche, denke ich, werden Sie den Unterschied erkennen können , welcher welcher ist. 39. Nichtfunktionale Anforderungen: Nichtfunktionale Anforderungen sind Dinge , die wichtig oder wesentlich sind, aber nicht direkt auf die Funktionsweise des Systems auswirken. Also, was für Dinge könnten das sein? Nun, Dinge wie Leistung, wie schnell reagiert das System? Verfügbarkeit und Skalierung bei hoher Auslastung? Wird der Service immer als Sicherheitsüberwachung verfügbar sein ? Wie werden Sie also wissen, ob etwas die Berichterstattung beeinträchtigt? Können wir das Backend fragen? Können wir sehen, was los ist? Barrierefreiheit und Benutzerfreundlichkeit? Diese sind jetzt wahrscheinlich eher funktionale Anforderungen, für diese und dann für die Dokumentation ist es wirklich wichtig. Wie werden zukünftige Entwickler oder Systembenutzer wissen, wie es funktioniert? Beachten Sie also, dass diese Dinge nicht optional sind, oder? Sicherheit und Barrierefreiheit sind zum Beispiel gesetzliche Anforderungen , da unsere Projekte zugänglich sein müssen. Und wenn wir nicht genug Sicherheit haben, werden wir gegen das DSGVO-Gesetz verstoßen. Die Dinge, diese Dinge sind also keine optionalen Extras, die sie alle benötigen, aber sie sind nicht wirklich Teil der Funktionsweise des Systems. Wenn Sie also beispielsweise eine Bestellstatusseite haben , die einem Kunden zeigt, wo sich seine Lieferung befindet, ist dies die funktionale Anforderung dass die Seite ihm mitteilt, wo sich seine Lieferung befindet. Aber es gibt auch eine Reihe von nicht funktionalen Anforderungen. Also z. B. wie schnell dauert das Laden einer Seite? Nun, es könnte dauern, würde nicht eine Sekunde oder eine Minute dauern. Wenn es jetzt 1 Minute dauert, werden sich die Benutzer wirklich ärgern und sie werden wahrscheinlich gehen und woanders einkaufen gehen. Technisch gesehen kann der Benutzer jedoch den Bestellstatus sehen, wenn es angezeigt wird, dass es die Akzeptanzkriterien erfüllt . Es ist also technisch gesehen keine funktionale Anforderung, aber es ist wirklich wichtig. Ebenso die Sicherheit, wenn jemand anderes seinen Bestellstatus sehen kann, das nicht unbedingt verstößt das nicht unbedingt gegen die funktionalen Anforderungen. Aber es wäre wirklich wichtig , weil wir private Daten an jemanden weitergeben müssten , der keinen Zugriff darauf haben sollte. Daher ist es wirklich wichtig , dass wir sowohl über nichtfunktionale als auch über funktionale Anforderungen nachdenken nichtfunktionale . Aber sie sind leicht zu vergessen. Ich habe vergessen, dass du ein Feature erstellt hast und du vergisst, es den Sicherheitstests oder den Barrierefreiheitstest zu den Sicherheitstests oder unterziehen und F oder so etwas kommt durcheinander. Deshalb ist es wirklich wichtig, diese nicht funktionalen Anforderungen in die erstellte Definition aufzunehmen . Lassen Sie also nicht zu, dass ein Ticket in die Spalte „Erledigt“ verschoben wird , es sei denn, es wurde auf Benutzerfreundlichkeit getestet, es sei denn, die Leistung wurde getestet. Aber all diese Dinge in deiner Definition von erledigt und dann, weißt du, sie zu testen, damit du weißt, dass alles, was da drin ist, sie nicht nennt, den funktionalen und nichtfunktionalen Anforderungen entspricht . 40. Tech: Es gibt eine Art von Ticket , das ein Ingenieur aufbringen könnte , und das sind technische Schulden oder technische Schulden. Das passiert also, wenn wir etwas tun, um die Lieferung zu beschleunigen, weil wir wissen, dass wir uns später darum kümmern müssen. Nehmen wir zum Beispiel an, wir entwickeln Software, die vielleicht wie eine Wetter-App ist. Was ist das Abrufen Wetterdaten aus einer externen Quelle. Und wir haben Bibliothek a verwendet. Aber jetzt müssen wir Library be verwenden, weil es besser ist oder uns erlaubt, etwas zu tun , und wir wollen einfach zu Bibliothek B wechseln Eine wirklich schnelle Möglichkeit, das zu tun, wäre , Bibliothek B in unsere Anwendung zu bringen ohne Bibliothek A zu entfernen, so wie sie immer noch die Anforderungen erfüllt wenn wir jetzt Bibliothek B verwenden, obwohl Bibliothek a war immer noch eingebettet oder irgendwie in die Codebasis gebracht. Wenn wir das tun würden, würde das zu einer gewissen Technologieverschuldung führen. Weil Library a irgendwann immer noch entfernt werden muss, wir es einfach noch nicht getan. Warum ist es nun wichtig, die Technologieverschuldung in den Griff zu bekommen? Nun, erstens, es macht den Code viel einfacher zu lesen, wenn Sie neu im Projekt sind und denken, Oh, warum verwenden wir Library be, aber wir haben auch Library a drin. Was ist da los? Das kann sehr verwirrend sein und daher ist es schwieriger, Leute an Bord zu bringen. Es ist schwieriger, zukünftige Entwicklungsarbeit zu leisten. Es kann Dinge wie den Build-Prozess verlangsamen. Wenn wir also die Software kompilieren, wenn wir zwei Bibliotheken einbauen , wird sie dadurch größer, als sie sein muss, um sie dort zu verlangsamen. Oder es könnte die Leistung beeinträchtigen, z. B. wenn es sich um eine clientseitige JavaScript-Bibliothek handelt. Und wir bringen Bibliothek A, Bibliothek B ein, benutzen aber nur Bibliothek be. Dann würden wir die Bibliothek a in den Browser des Benutzers laden , ohne dass dies erforderlich ist. Es hat also viele nichtfunktionale Auswirkungen, auch wenn es die Funktion der Software nicht unbedingt beeinträchtigt. Und das sind technische Schulden und deshalb ist es wichtig, sie in Angriff zu nehmen. 41. Einen Sprint kündigen: In seltenen Fällen können sich die Anforderungen für das Projekt mitten im Sprint ändern. Wir haben das Prinzip von Scrum, bei dem in einem Sprint nichts Neues passiert. Also definieren wir die Aufgaben, die wir zu Beginn des Sprints erledigen wollen , und dann starten wir den Sprint und wir erledigen sie. Und wir bringen erst beim nächsten Sprint mehr Tickets ein. Was tun wir also, wenn das, woran wir gerade arbeiten, irrelevant wird und wir die Sprintziele nicht mehr erfüllen müssen . Nun, in solchen Fällen können wir einen Sprint absagen und der Product Owner hat die Befugnis, den Sprint abzusagen. Sie glauben, dass sich die Anforderungen geändert haben und es keinen Sinn macht, weiter an dem zu arbeiten, woran wir arbeiten. Sie können weitermachen und den Sprint absagen. Alle Tickets, an denen wir gearbeitet haben, gehen dann zurück in den Produkt-Backlog und wir bilden einen neuen Sprint. Also haben wir ein neues Sprint-Planungstreffen. Wir legen fest, wann unser Zeitungspapier erscheinen wird , und wir bringen Datentickets für neue Tickets ein, um den neuen Anforderungen gerecht zu werden. 42. Was ist ein agiles Release-Management?: Wenn wir über Agile sprechen, sprechen wir von kleinen Iterationen, kleinen Funktionen, die wir entwickeln, die wir vorbereiten und dann verbessern. Inzwischen machen sich einige Unternehmen diese Idee des agilen Arbeitens zu eigen, aber tatsächlich werden Implementierungen immer noch im Urknallverfahren durchgeführt. Es gibt also all diese Agile-Teams , die an Funktionen für eine Software arbeiten, aber dann wird die Software nur alle zwei Monate ausgeliefert und alle Funktionen werden gleichzeitig veröffentlicht. Wenn wir also über Agile Release Management sprechen, sprechen wir davon, dieses Urknall-Release loszuwerden. Ich ersetze ihn durch einen iterativeren Zyklus, einige eher der Entwicklungsarbeit entsprechen, die wir im Sprint, in Sprints und in den Scrum-Teams leisten . Die Idee ist also , dass Sie möglicherweise eine Reihe von Funktionen erhalten und diese unabhängig von Funktionen veröffentlichen , an denen andere Teams arbeiten. Sagen wir Team A, erstellt einige Funktionen und stellt sie bereit, und teambasiert erstellen Sie einige Funktionen und sie werden separat bereitgestellt. Wir könnten sogar über einzelne Tickets sprechen. TMA schließt also ein Häkchen im Rahmen dieser Endbearbeitung ab, es verschmilzt mit der Hauptcodebasis und stellt sie bereit, und diese Probleme werden nacheinander bereitgestellt. Wie auch immer die genaue Methode des agilen Release-Managements aussehen mag, sie wird letztendlich implementiert. Es geht darum, diesen Entwicklungszyklus, diesen Lebenszyklus von Software zu verkürzen , sodass wir kleine Teile der Funktionalität herausbringen können , ohne diese Urknall-Releases denen wir viele Funktionen gleichzeitig herausbringen und nicht viele Releases herausbringen und sagen, dass wir regelmäßige kleine Releases wollen , die dem Agile-Prozess entsprechen. 43. Release: Jede Entwicklung durchläuft einen Zyklus. Und in diesem Fall werden wir uns den Release-Management-Zyklus ansehen . Du kannst also wirklich an jedem Punkt beginnen, aber wir beginnen ganz oben mit Änderungswünschen. Der Product Owner möchte, dass etwas geändert wird. Deshalb entwerfen wir eine Lösung und erstellen einige Akzeptanzkriterien , die diese Änderung umsetzen würden. Dann bauen wir es und wir schreiben den Code und dann schicken wir ihn an eine andere Person zur Überprüfung, damit sie überprüfen können , ob der Code Sinn macht und eine gute Idee ist. Wir testen es dann, um sicherzustellen, dass es funktioniert, und wenn es , wird der Code bereitgestellt. Wir werden dann einige Kennzahlen haben, also Berichte über die Leistung. Und wenn es irgendwelche Probleme gibt, dann tun wir das, wir werden einige Probleme melden. Wir werden als Team zusammenarbeiten, um einen Fehler zu melden oder eine weitere User Story zu veröffentlichen, um ihn zu ändern. Und das fließt dann in die Anfrage nach Änderungen ein. 44. Vorteile eines agilen of: Warum sollten wir agile Releases machen wollen? Nun, hier sind die echten Vorteile des agilen Release-Prozesses. Nummer eins ist, dass es die Dinge schneller herausbringt. uns also darum , diesen Entwicklungszyklus zu verkürzen. Sie erstellen also ein Feature, veröffentlichen es sofort, Sie können sofort Feedback dazu erhalten. Wenn es eine wichtige Änderung ist, wird sie schneller veröffentlicht, die Bündelung zu einem späteren Zeitpunkt in einer größeren Version. Zweitens funktioniert es im Einklang mit Agile. Wenn Sie also all diese Scrum-Teams haben auf diese sehr agile Weise arbeiten, warum sollte Ihr Release-Prozess das nicht unterstützen? Warum sollten wir plötzlich zum Urknall-Ansatz zurückkehren , der alle Risiken des Scheiterns birgt. Drittens ermöglicht es dem Scrum-Team , die Verantwortung für das Release zu übernehmen. Auf die alte Art mussten also alle Teams Dinge entwickeln und dann musste ein Teil des Teams die Verantwortung dafür übernehmen, sie zu veröffentlichen, Bugs zu untersuchen und die Auswirkungen der Veröffentlichung von Obst zu überwachen . Wenn Sie es einem agilen Prozess zurückgeben in dem jedes Team die Funktionen veröffentlichen kann , an denen es gearbeitet hat. Dann kann das Scrum-Team die Verantwortung für all das übernehmen. Sie können die Funktionen verschieben, sie können überwachen, was passiert. Sie können bei Bedarf einen Rollback durchführen. Wenn es ein Worst-Case-Szenario gibt, gibt es einige Probleme und das müssen sie tun. Aber es passt zu dieser Idee, dass Scrum-Teams unabhängige, funktionsübergreifende Einheiten sind. Sie übernehmen von Anfang bis Ende die Verantwortung für das Ticket und können den gesamten Prozess leiten, und können den gesamten Prozess leiten ohne von anderen Teams blockiert zu werden. Und Nummer vier, es kann sicherer sein. Es gibt also diese Art von Old-School-Mentalität der Idee. Sie all diese Funktionen erstellen, Wenn Sie all diese Funktionen erstellen, geben Sie sie Ihren Testern und Ihr Text enthält all diese Szenarien, um sicherzustellen , dass alles zusammenpasst. Aber die Realität ist, wenn Sie 100 Funktionen von zehn verschiedenen Teams gleichzeitig veröffentlichen , werden diese wahrscheinlich auf Weise interagieren, die Sie sich nicht vorgestellt haben, und es ist sehr wahrscheinlich , dass etwas schief geht. Und wenn etwas schief geht, ist es ein echtes Problem, ein Rollback vorzunehmen, weil Sie 100 Funktionen von zehn Teams rückgängig machen. Wenn Sie diese wirklich kleinen iterativen Releases zulassen. Wenn dann ein Release schief geht, ist es wirklich einfach, einen Rollback rückgängig zu , da Sie nur eine Sache ändern. Und das Team, das es geändert hat, verwaltet die Version, sodass sie sehr schnell einen Rollback durchführen können. Ich würde argumentieren, dass Agile Release Management nicht nur schneller und besser, sondern auch sicherer ist. 45. Gemeinsame release: Schauen wir uns einige gängige Veröffentlichungszeitpläne an. Sie alle. älteste Stil wäre das, was wir eine Urknall-Veröffentlichung nennen. Es ist also eine große Version für mehrere Teams und ein großes Testteam , um alle Funktionen zu überprüfen. an, Nehmen wir an, Sie haben drei verschiedene Teams an einem Produkt arbeiten. Du arbeitest, du arbeitest an Microsoft Windows 9 und du willst Microsoft Windows 10 veröffentlichen. Also haben alle Teams, die daran arbeiten, all ihre Änderungen vorgenommen und Sie veröffentlichen sie. Das Urknall-Ding, das Windows Ten ist, enthält alle Änderungen auf einmal. Und Sie benötigen ein riesiges Testteam, das alle Funktionen überprüft , weil jeder diese Änderungen einführt und es nicht klar ist , wie sie interagieren oder wie die Dinge kaputt gehen werden , weil Sie alles erneut testen müssen. Und es ist also wirklich langsam. Dann haben wir so etwas wie einen Sprint. Hier beginnen wir also unserem agileren Release-Prozess. Also eine Veröffentlichung am Ende jedes Sprints. Es ist nett, weil es einen sehr vorhersehbaren Veröffentlichungszeitplan hat . Und was ist der Sinn? Du hast vielleicht einige Schienen, bei denen du viel loslassen musst , und du hast einige Sprints, bei denen du nicht viel loslassen musst. Also willst du dieses Zeug wahrscheinlich haben wenn du jede Menge Sachen produzierst, die rauskommen können, du willst es wahrscheinlich schneller rausbringen. Und wenn du nicht so viel Zeug produzierst , das verschickt werden muss, warum solltest du, warum würdest du dann veröffentlichen? Es schafft dort also ein bisschen Flexibilität. Wenn wir nach unten gehen, haben wir diese Idee von der Feature-Veröffentlichung. Also manuell veröffentlicht, jedes Feature ist bereit. Das Scrum-Team wird also ein Feature vorbereiten. Dann werden Sie das manuell in die Codebasis einfügen und es veröffentlichen. Schnell. Kleine Änderungen. Es ist nett und einfach, das rückgängig zu machen. Es ist ein gewisses Management erforderlich, es sich um einen manuellen Freigabeprozess handelt. Aber selbst in der agilen Welt gibt es Unternehmen, die sich wirklich für das agile Feature-Releasing entschieden haben sich wirklich für das agile Feature-Releasing weil es Ihnen so schnelle, kleine Änderungen ermöglicht, ohne das Risiko einer kontinuierlichen Veröffentlichung einzugehen, worüber wir als Nächstes sprechen werden. Kontinuierlich ist also jede Änderung, sobald Sie etwas zusammenführen, einfach auf Ihren Produktionsserver übertragen wird. Ähm, es ist also superschnell und sehr einfach, einen Rollback rückgängig zu machen, weil du einen einzigen Commit verschiebst. Wenn du also Dinge rückgängig machst, musst du nur beachten, dass der letzte Commit etwas knifflig wird, wenn du nur feststellst, dass er kaputt ist. Und dann musst du vielleicht mehrere Commits zurückhaben. Aber wenn Sie nur eines veröffentlichen, testen, ob es in der Produktion funktioniert, und dann weitermachen und sehr schnell vorankommen. Aber dafür ist ein sehr hohes Maß an Testabdeckung erforderlich , da buchstäblich alles verschoben wird und es daher jederzeit kaputt gehen kann. Und Sie benötigen wirklich eine hohe Testabdeckung, um sicherzustellen , dass alles funktioniert. 46. Schlüssel zum Erfolg: Hier sind einige Schlüssel zum Erfolg von Agile Release Management. Die erste besteht darin, die Zustimmung des Managements zu erhalten. Das gilt im Grunde für alles, was Sie jemals tun. Wenn Sie das Management mit ins Boot holen können, werden Sie es viel einfacher haben. Und wie wir bereits besprochen haben, gibt es ein Management der alten Schule, das Urknallveröffentlichungen bevorzugt weil sie denken, dass sie sicherer sind. Deshalb konzentriere ich mich darauf sie wirklich zu verkaufen, basierend auf der Idee wir, wenn wir diese wirklich kleinen Veröffentlichungen machen diese wirklich kleinen Veröffentlichungen dass wir, wenn wir diese wirklich kleinen Veröffentlichungen machen, wirklich leicht rückgängig machen können. Und das würde nur eine Sache nach der einführen, damit wir wissen, wie sie mit allem anderen interagiert. Es ist sicherer. Wir werden Ihre Funktionen also nicht nur schneller zur Verfügung stellen, sondern auch dafür sorgen, dass weniger oft etwas schief geht. Nummer zwei besteht darin, Funktionen unter Berücksichtigung der Bereitstellung zu entwerfen. Also, wenn du ein Feature entwickelst, wie wirst du es rausbringen? Ein gutes Beispiel sind Dinge wie Feature-Switches. Sie können den Code also bereitstellen, wenn Sie ihn hinter dem Feature-Switch platzieren und ihn dann zu einem späteren Zeitpunkt einschalten. Stellen Sie also den Code bereit und schalten Sie die Funktion ein. Wenn es nicht funktioniert, schalten Sie es einfach sofort aus und Sie müssen nicht in Panik geraten. Und wenn Sie im Voraus darüber nachdenken können, welche Schritte ich für die Bereitstellung dieses Tickets benötigen würde, wird es für Sie viel einfacher sein , diese Releases zu erstellen. Nummer drei ist, einen guten Rollback-Plan zu haben. Wenn etwas schief geht, kannst du das wirklich schnell rückgängig machen? Traditionell hatten wir in der Wasserfall-Methodik dafür keine gute Methode, aber es ist viel einfacher, wenn wir diese wirklich kleinen Releases machen , und schafft viel Selbstvertrauen, wenn man, selbst wenn etwas schief geht, einfach diesen kleinen Befehl eingibt. Es rollt automatisch am ganzen Rücken und alles ist in Ordnung. Nummer vier, haben eine hohe automatisierte Testabdeckung. Sie sollten also sicherstellen, dass nachdem Sie die Änderung vorgenommen haben, die gesamte Customer Journey und alle Szenarien, die Sie benötigen, automatisch ausführen können die gesamte Customer Journey und alle Szenarien, die Sie benötigen , indem Sie alle verfügbaren automatisierten Testtools verwenden . Denn wenn Sie wirklich kleine Releases machen, sollten Sie ständig testen. Man nimmt eine Änderung vor, man testet alles und nimmt eine Änderung vor, testet alles. Die einzige Möglichkeit, dies abzudecken, sind automatisierte Tests da Sie nicht genügend Tester haben könnten , um all diese Szenarien durchzuführen. Wenn Sie also diese Testabdeckung erhalten, gibt das Ihnen und dem Management viel Selbstvertrauen , dass die Dinge funktionieren werden. Und Nummer fünf, koordiniere dich mit anderen Teams. Stellen Sie sicher, dass Sie wissen, was andere Teams tun und wie sie mit Ihnen interagieren könnten. Und auch was die Planung eines Ukrainers angeht , der heute Morgen veröffentlicht , geht es ihnen und Veröffentlichungen am Morgen, wird, geht es ihnen und Veröffentlichungen am Morgen, wie werden Sie fragen, wann er abwechselnd diese Veröffentlichungen machen kann, damit Sie die Dinge schnell und effizient herausbringen können. Also werdet ihr euch nicht gegenseitig auf die Zehen treten. 47. Kontinuierliche Integration: kontinuierliche Integration führt die automatisierten Tests nach jedem Commit durch. Es könnte also jedes Mal sein ein Entwickler Code hochlädt, er ihn ausführt, oder es könnte sein, dass Sie jedes Mal, wenn ein Ticket einem Master zusammengeführt wird, mit einem Master zusammengeführt wird, es auf diesen Branches ausführen möchten , je nachdem , wie viel Sie für Ihre Continuous-Integration-Tools ausgeben möchten . Jetzt zeige ich Ihnen hier ein Beispiel mit Travis, was nur eine der verfügbaren Optionen ist. Und ich habe dieses Projekt hier , eine Open-Source-Lernumgebung. Und ich habe hier eine Konfigurationsdatei definiert, nur um dem Continuous Integration Server mitzuteilen , dass sie in PHP geschrieben ist. Und ich wollte es noch einmal testen, plötzlich Punkt 4.8, 0.0. Und hier sind alle Schritte, die Sie benötigen, um es einzurichten. Das heißt also, wenn ich einen Commit hochlade , werden die Aufgaben sowohl für PHP als auch für PHP 7.01 ausgeführt . Wir können darauf eingehen und sehen, was passiert ist. Travis hat alles festgestellt. Es führt die Installation wie angefordert aus und dann wird die PHP-Unit ausgeführt, um die Tests auszuführen, und es ist bestanden. Das ist also großartig. Und dann wird hier genau das Gleiche gemacht, aber es läuft wieder, 7.4. Wenn Sie also mehrere verschiedene Produktionseinstellungen haben, können Sie den Continuous Integration Server gegen all diese Setups testen lassen. Und ich kann auch eine vollständige Geschichte sehen. Wenn ich also zur Build-Historie gehe, wird jedes Mal, wenn ich einen Commit hochgefahren habe, angezeigt, dass der Build abgeschlossen ist. Und z. B. hier hatten wir einen, der nicht erstellt werden konnte. Wir können also reingehen und wir können die Logs leider nicht mehr sehen, aber wir wissen, dass da etwas schief gelaufen ist. Und dann repariere ich hier noch etwas anderes. In diesem Fall wurde also die PHP-Version an den Server angepasst. Und wir können sehen, dass der Build wieder funktioniert. Es ist also wirklich einfach, es ausfindig zu machen. Sie können die automatisierten Tests in einer Vielzahl von Umgebungen ausführen und können sehr leicht erkennen, was schief gelaufen ist, da Sie genau sehen können , wo der Build nicht mehr funktioniert. 48. Kontinuierliche Belieferung: Ein weiterer Schritt zur kontinuierlichen Integration ist Continuous Delivery. Hier besteht der Code also automatisch alle automatisierten Tests und wird automatisch Ihrer Produktionsumgebung bereitgestellt. Das heißt jetzt nicht, dass Sie jeden einzelnen Commit einsetzen. Es gibt also mehrere Verzweigungsstrategien. Du könntest es benutzen, du könntest es haben , sodass du eine Produktionsfiliale hast. Und jedes Mal, wenn Sie etwas vom Master mit der Produktion zusammenführen , werden alle Automatisierungsaufgaben ausgeführt. Und wenn das funktioniert, steigen sie ohne weiteres menschliches Eingreifen. Oder Sie können es dort haben, wo der Master in Ihrer Produktionsumgebung sitzt. Und jedes Mal, wenn ein Team ein einzelnes Ticket mit dem Master zusammenführt, führt es alle Tests durch und es wird automatisch bereitgestellt. Was es ist, ist eine Abkehr von der Idee der manuellen Bereitstellung. Ein Ticket kann also ein Feature zusammenführen . Alle Tests werden automatisch ausgeführt und, falls es in Ordnung ist , an die Produktionsumgebung weitergeleitet. 49. Kontinuierliche delivery: Es gibt eine große Auswahl an verschiedenen Build-Servern und Tools für die kontinuierliche Integration. In dieser Lektion werden wir einige davon besprechen. Der erste, der erwähnt wird, ist wahrscheinlich Jenkins. Das ist also ein Open-Source-Automatisierungsserver. Du musst das also selbst hosten . Sie benötigen einen Server in Ihrer Organisation und müssen Jenkins selbst ausführen. Aber es ist Open Source, es ist kostenlos und Sie können es intern ausführen. Dann haben wir die gehosteten Umgebungen , die normalerweise angeschlossen werden. Wenn du so etwas wie ein GitHub-Repo hast, wird es in dieses eingebunden und dein Code wird von dort abgerufen. Wir haben also Travis CI, von dem ich Ihnen das Beispiel gezeigt habe. Und dann haben wir auch einen CircleCI. Und wenn du die Dinge lieber auf GitHub behalten möchtest, dann hat GitHub tatsächlich ein Ding namens GitHub Actions, dem du CI- und CD-Prozesse ausführen und dich natürlich sehr gut einklinken kannst, wenn dein Repository da ist oder du eine Plattform wie Get Lamp verwenden kannst. Das ist so etwas wie ein Continuous Integration Server und ein integrierter Hub. Es ist also sowohl für den Git-Server als auch für die Erstellung Ihrer Software für Sie. Und dann ist Team City ein weiterer Continuous Integration Server , der ebenfalls sehr beliebt ist. 50. Agile Software: Bisher haben wir hauptsächlich Dinge mit Tabellen gemacht und sie veröffentlicht. Und dies ist eine großartige Möglichkeit, die Grundlagen zu erlernen und zu verstehen, wie die Systeme funktionieren. Aber im Geschäftskontext viele dieser Dinge normalerweise mit Projektmanagement-Software erledigt . Und das ist wirklich gut, vor allem, wenn Sie ein Remote-Team haben in dem die Leute überall sind und sie alle in der Lage sein müssen, den Vorstand und Sohn zu sehen , wo die Tickets sind. Und du hast alle, die zusammenarbeiten. Hier kommt die Projektmanagement-Software erst richtig zur Geltung. Deshalb werden wir in diesem Modul untersuchen, dass einige dieser Lösungen bereits für Sie verfügbar sind . 51. Jira: Jira ist möglicherweise das beliebteste Tool für Scrum online. Lassen Sie uns also weitermachen und hier ein Projekt erstellen. Wir nennen es E-Commerce-Shop. Und wir werden unsere Vorlage hier auf Scrub ändern . Perfekt. Ja, sieht gut aus. Wir werden weitermachen und das erstellen. Ich werde vorerst auf irgendwelche Tools verzichten . Okay, großartig. Wir haben also unseren Rückstand hier. Also hier haben wir unsere Roadmap. Hier haben wir ein Backlog, sodass wir damit beginnen können dem Backlog Probleme hinzuzufügen, wenn wir möchten. Oder wir könnten auch anfangen, Dinge hinzuzufügen. Also hier ist diese Produktseite wie ein Epos. Und ich sage, als Besucher möchte ich den Produkttitel sehen. Als Besucher möchte ich ein Bild des Produkts sehen. Als Besuch. Ich möchte die Produktbewertungen lesen. Dann könnten wir hier eine weitere Epoche hinzufügen. Wir könnten also Management Portal sagen. Und dann möchte ich als Manager die Liste der Bestellungen sehen. Und als Manager möchte ich versenden und bestellen. Dieser Roadmap-Tab ermöglicht Ups. Ich habe stattdessen diese Epen erstellt. Und es würde helfen, wenn ich buchstabieren könnte. Wir gehen versenden und bestellen. Großartig. Dann werden wir diese wahrscheinlich nicht löschen können, aber lass es uns versuchen. Da haben wir es. Wir können also auf jeden von ihnen eingehen und eine Beschreibung hinzufügen. Und dann können wir hier einige Story-Points hinzufügen. Also vielleicht viele. Nehmen wir an, das sind drei. Und dieser ist fünf. Das wird eine Zwei sein. Und dieser wird auch eine Fünf sein. Toll, wir haben da also einige Punktewerte. Und wenn wir einen Rückstand haben, können wir damit beginnen, diesen in Sprints zu organisieren. Also hier haben wir unseren ersten Sprint. Und wir können einige dieser Tickets n ziehen . Wir haben also unsere Produktseite Tickets n, die haben wir im Backlog belassen. Und wenn wir dann auf Sprint starten klicken, befinden wir uns jetzt im Board-Tab. Und hier haben wir unser Board. Also könnten wir hier einige Spalten hinzufügen, wenn wir wollen. Wir könnten das Code-Review nennen. Ich lege das da hin. Und wir werden auch eine zum Testen hinzufügen. Steck das da rein. Wenn ich dann mit einem Ticket beginnen möchte, kann ich es mir selbst zuweisen. Ich kann es in Bearbeitung schicken. Und hier haben wir unser Board während wir all diese Tickets aktualisieren, werdet ihr für alle aktualisieren. Und wenn wir unsere Teammitglieder einladen, können sie natürlich sehen, wie sich die Tickets auf der ganzen Linie bewegen, während wir sie auch verschieben. 52. Burndown-Chart: Eine wichtige Kennzahl, die Sie sich in Ihrem Sprint ansehen sollten, ist also das Burndown-Diagramm. Wenn wir also hier auf diese Insights-Schaltfläche klicken, können wir sehen, dass wir diesen Sprintfortschritt haben, der uns mitteilt, wie viel Prozent bereits erledigt sind oder noch nicht gestartet wurden. Und wir haben hier auch dieses Sprint Burndown Chart. Also habe ich es als zweiwöchigen Sprint definiert. Und wir können theoretisch sehen, wir diese Anzahl von Punkten abschließen sollten. Hälfte sollten wir also die Hälfte der Punkte hinter uns haben. Während wir also diese Tickets einziehen, aktualisieren wir einfach, dass wir jetzt sagen können, dass sie zu 100% in Bearbeitung sind, aber es wurde noch nichts getan. Aber wenn ich dann eines dieser Tickets nehme und es auf Fertig verschiebe. Und wieder werden wir uns erfrischen. Jetzt sind wir bei 56 Prozent fertig, 44 Prozent unvollständig. Und wir können sehen, dass unser Burndown-Diagramm wirklich gut aussieht weil wir diese blaue Linie wollen. Das ist die Arbeit, die getan wurde, um auf Null zu kommen , bevor wir hier sind. Also müssten wir diese Grenze erreichen , um sie zu erreichen. Wenn es hier oben ist, werden wir die Arbeit nicht so schnell erledigen, wie wir dachten. Wenn es hier unten ist, erledigen wir die Arbeit schneller, als wir dachten. 53. Trello: Trello ist ein wirklich einfaches Tool zum Erstellen von Boards und Aufgabenlisten. Ich habe hier also ein brandneues Board und wir können diesem jede gewünschte Spalte hinzufügen und vielleicht fügen wir eine in Bearbeitung befindliche hinzu. Wenn ich buchstabieren kann. Und dann ein Code-Review, Testen und fertig. Und dann kann ich anfangen, hier Dinge hinzuzufügen. Also möchte ich den Produktnamen sehen. Als Besucher möchte ich ein Bild des Produkts sehen. Sag Besucher. Ich möchte die Produktbewertungen lesen. Und dann können wir sie anklicken. Ich kann sie mir zuweisen, z. B. ich kann eine Beschreibung hinzufügen, also speichere das. Und dann meine kleinen Bilder, weil ich es signiert habe, das kann ich in Bearbeitung machen. Nun, was Trello nicht tun , weil der Einstieg mit Trello sehr einfach ist . Das war's. Wir sind jetzt auf dem richtigen Weg. Es wird uns nicht alle Berichte geben , die einige der fortschrittlicheren Tools bieten werden. Aber es eignet sich hervorragend für kleine Projekte, einfache Projekte oder Projekte bei denen Sie einfach weitermachen, loslegen und nicht zu viel Zeit damit verbringen möchten , herumzuspielen , weil Sie diese kleinen Boards einfach erstellen, mit Ihrem Team teilen und alle sehr schnell zum Arbeiten bringen können mit Ihrem Team teilen . 54. Wandbild: Hier ist ein weiteres Tool namens Miro, und das hat viele Vorlagen. Also, wenn du es zum ersten Mal auflädst und wir haben es einfach, kannst du diese Bonds als Freund zum Aufhängen verwenden. Aber wenn Sie zu Agile wechseln, gibt es viele coole Dinge. So hat es z. B. eine Vorlage für eine Retrospektive, Start, Stop, Retrospektive fortsetzen. Ein paar der Dinge, über die wir gesprochen haben. Oder wir können uns auf das Arbeitsblatt „ Fünf Warum“ beschränken , das sich hervorragend für Kriegsschiffe, Teamrückblicke und tägliche Windungen eignet. Und es wird eine Ansicht des Vorstands erstellen . Und dann wieder wahrscheinlich Orbitale. Sie können es mit all Ihren Teammitgliedern teilen und dann einfach beginnen, es zu verwenden. 55. Aufbau psychologischer Sicherheit: Bei psychologischer Sicherheit geht es darum, ob Teammitglieder das Gefühl haben, das nötige Selbstvertrauen zu haben, um ihre Gedanken und Ideen zum Ausdruck zu bringen. Und es liegt wirklich in der Verantwortung eines Teams, dies aufzubauen. Denn leider haben viele von uns die Erfahrung gemacht, dass wir uns nicht äußern wollen. Wir wollen keine Ideen teilen, weil wir uns Sorgen machen. Wir werden verurteilt, wir werden ausgerufen, wir werden gefeuert, was auch immer es ist. Das sind keine psychologisch sicheren Umgebungen. Und in Scrum erkennen wir an, dass jedes Teammitglied etwas wirklich Wertvolles hat , um es vorzustellen und zu kommentieren. Wenn wir also psychologische Sicherheit schaffen können , sodass schüchterne Teammitglieder oder auch andere Teammitglieder wirklich ehrlich mit ihren Gefühlen oder Meinungen umgehen können , dann ist das wirklich von Vorteil. Wie schaffen wir also psychologische Sicherheit? Nun, es mündlich und in der Arbeitsweise festzulegen , ist eine wirklich gute Art, einfach darauf hinzuweisen, dass die Meinung aller gültig ist. Also, das aufgeschrieben zu haben und dass sich alle als Team einig sind, dass wir diesen Input wirklich wollen und dass wir nicht voreingenommen sein werden. Wir werden zuhören und die Meinung aller respektieren, das trägt wesentlich dazu bei, diese Sicherheit zu erhöhen. den guten Regeln gehört vielleicht, dass es in Ordnung ist, Fehler zu machen. Wenn wir eine Kultur des Urteils und der Schuldzuweisung haben , werden die Menschen ihre Fehler nicht zugeben und daher werden wir nichts lernen. Wenn wir dagegen eine Kultur etablieren in der wir Menschen nicht für Fehler verantwortlich machen, sondern uns nur ansehen, was schief gelaufen ist und wie wir sicherstellen können, dass es nicht noch einmal passiert, dann sind die Leute eher ehrlich. Und deshalb können wir diese Probleme beheben. Es ist wertvoll, den Input aller zu haben, ist nur, dass das als Regel gilt, viele Menschen das Gefühl ihre Meinung nicht wichtig ist. Wenn sich also alle im Team einig sind , dass die Meinung aller wichtig ist, kann das einige Leute wirklich dazu ermutigen, offener zu sein. Eine Kultur des Respekts zu haben, die Idee von Tampons zu respektieren und nicht unterbrochen zu werden. Wir waren wahrscheinlich alle in diesen Besprechungen denen eine Person immer wieder unterbricht und es ist wirklich nervig, unhöflich und respektlos. Und die Person, die unterbrochen wird, wird irgendwann einfach aufgeben und ihre Ideen nicht teilen. Wenn wir also die Idee haben, dass wir, wenn jemand spricht, ihn nicht unterbrechen, was grundlegende Manieren sein sollte, aber oft brauchen wir eine kleine Erinnerung. Dann kann das ein wirklich nützliches Instrument sein um das unter anderem zu gestalten, indem wir sicherstellen dass es regelmäßige Rückblicke gibt um sicherzustellen, dass die Leute zu Wort kommen und dass die Leute darüber sprechen können, wie sie denken, dass es läuft und wie sicher sie sich im Team fühlen. Und es kann wirklich gut sein, diese von der Baustelle zu entfernen. Also, wenn Sie hier ein Büro haben, haben Sie hier vielleicht ein Café. Es kann wirklich gut sein, in dieses Café zu gehen oder woanders hinzugehen. Nehmen Sie es einfach aus dem Büro, damit sich die Leute wie im Büro fühlen , das ist eindeutig Domäne des Managers. Und wir sind vielleicht etwas nervöser , wenn Sie das in eine entspanntere Umgebung mitnehmen , wie ein Café den Leuten auch wirklich helfen kann, sich zu öffnen. 56. Wash-up: Gottesdiensttreffen finden statt, nachdem ein Projekt abgeschlossen ist, aber wahrscheinlich noch wichtiger wenn etwas schief geht. Dies ist eine Zeit, in der sich die Menschen Sorgen über Schuldzuweisungen machen. Der Sinn des Treffens besteht also darin, herauszufinden, was passiert ist und was wir beim nächsten Mal besser machen können. wirklich wichtig zu betonen, dass es sich nicht eine Untersuchung handelt, sondern darum, einige Leute zu finden , die ihnen die Schuld geben und sie dafür bestrafen können, sondern einfach zu verstehen, was passiert ist und wo wir das beheben können. Also das nächste Mal können wir es besser machen. Ein wirklich gutes Werkzeug in Gottesdienstversammlungen ist es, die sogenannten Five Whys zu verwenden . Also fragen wir nur fünfmal nach dem Warum. Und je mehr wir das tun, desto mehr gehen wir der Ursache des Problems auf den Grund. Nehmen wir an, wir hatten einen Serverausfall und die Teams haben einen Serverausfall und sich zu einem Abwasch getroffen. Und wir könnten sagen, warum ist der Server ausgefallen? Wann, warum? Nun, der Festplattenspeicher ging aus. Okay. Warum ging der Speicherplatz aus? Nun, die Lunge hat es gefüllt und es gab so viele Protokolle, dass es die gesamte Festplatte füllte. Warum wurde der Server mit Protokollen gefüllt? Nun, es gab kein Monitor-Setup auf dem Server das uns alarmierte, wenn die Festplatte zu 80 Prozent voll war. Warum gab es kein Monitor-Setup? Nun, es entsprach nicht unserer Definition von erledigt, als wir den Server erstellt haben, also haben wir vergessen, es zu tun. Warum stand in unserer Definition von erledigt nicht? Nun, wir hatten nie ein Arbeitstreffen für das Team, um das zu klären. Wir können also sehen, wenn wir all diese Warum-Fragen stellen und weiter graben, wir suchen weiter nach einem Problem, das zunächst so aussehen könnte, als wäre es der Sturz einer Person gewesen. Es war jemand, der den Server ausfallen ließ. Eigentlich an der Grundursache. Es ist ein Teamproblem und etwas, das wir beim nächsten Mal besser machen können. Wir können die Arbeitsweisen haben. Wir können unsere Definition von erledigt verbessern. Wir können zurückgehen und es uns ansehen, verbesserte Überwachung. All diese Dinge kamen zur Sprache , weil wir uns immer wieder fragten , warum wir dem Problem auf den Grund gehen sollten, anstatt über Schuldzuweisungen nachzudenken. Der entscheidende Punkt bei Gottesdiensttreffen ist das eigentliche Reden. Wir haben über psychologische Sicherheit und den Aufbau dieses Umfelds gesprochen . Nun, wir geben keine Schuld, wir schauen uns nur an, was schief gelaufen ist, damit wir wissen, was wir in Zukunft ändern können. 57. agil an Management verkaufen: Agile klingt vielleicht großartig, zu viele von uns, aber Management ist nicht immer damit einverstanden. Wie können wir sie also davon überzeugen , dass es eine bessere Art ist, Dinge zu tun? Nun, zuerst sollten wir uns überlegen, welche Sorgen, welche Bedenken das Management haben könnte. Erstens, es ist eine Veränderung. Veränderung kann beängstigend sein. Es ist eine andere Art, wie sie die Dinge zuvor gemacht haben. Wenn also ein Unternehmen erfolgreich war oder es zumindest bisher zurechtgekommen ist, dann ändert sich das. Da steckt immer ein gewisses Risiko drin. Es mag den Anschein haben, als ob es ewig dauert, etwas zu tun , anstatt die alte Wasserfallmethode zu verwenden, die effizient ist, wenn sie perfekt funktioniert. Nephron funktioniert natürlich perfekt, könnte es aber hypothetisch, wohingegen wir Management und Ideen verkaufen. Okay, nun, wir werden eine leere Produktseite erstellen. Dann werden wir es mit einem Titel versehen. Dann werden wir ein Bild darauf kleben und wir werden all diese Dinge in diesem Schritt veröffentlichen und präsentieren und überprüfen . Es klingt vielleicht so, als würde es eine Ewigkeit dauern. Und es befähigt auch Teams und nicht Manager. Und das ist beängstigend, wenn Sie ein Manager sind und es gewohnt sind , Mikromanagement zu verwalten und die Kontrolle über alles zu haben. Und dann kommt jemand und sagt, wir haben diese Scrum-Methode und es ist wirklich gut, das Team zu befähigen, die Arbeit zu erledigen, dann können sie deswegen nervös sein , weil sie es mögen, kontrolliert zu werden. Wie gehen wir also mit diesen Ängsten, diesen Bedenken um? Nummer eins ist ein Dokument teurer Misserfolge und langsame Genehmigungsprozesse. Also, wenn es einen gibt, sagen wir, der Urknall wird ausgelöst und es dauert Stunden, ihn rückgängig zu machen. Und es gibt alle möglichen Beschwerden, dann ist es eine tolle Sache, das zu dokumentieren. Oder wenn dies die Genehmigungsprozesse verlangsamt, wo Sie möchten, führen Sie eine Funktion ein und es dauert zwei Wochen. Und die Produktbedingungen fragen, wo ist es, wo ist es? Und du sagst, naja, es wird in der nächsten Version erscheinen, aber wir machen unternehmensweite Releases, also können wir nichts tun, was du vorstellen wirst, um spät zu essen. Und dann verpassen wir ein Termindokument, all das. Denn wenn Sie zum Management gehen und sagen könnten: Schau, hier gab es einen massiven Misserfolg weil wir die Urknall-Veröffentlichungen gemacht haben. Hier haben wir eine wichtige Frist verpasst, um etwas ändern, da wir bis zur nächsten Veröffentlichung warten mussten. Das ist ein guter Beweis dafür, dass der derzeit geltende Prozess nicht funktioniert. Um sich auf die Vorteile einer schnelleren Lieferung zu konzentrieren, möchten Manager die Dinge im Allgemeinen so schnell wie möglich veröffentlichen. Also, wenn wir ihnen sagen können, schauen Sie, diese Funktion, nach der Sie gefragt haben, hat es acht Wochen gedauert. Dann wurden weitere zwei Wochen auf eine Erleichterung gewartet. Und tatsächlich denken wir, dass wir in dieser Hälfte der Zeit eine Basisversion herausholen können , einschließlich des Releases. Wir müssen nicht einmal bis zur nächsten Veröffentlichung warten. Das wird ein großes Verkaufsargument sein. Und wir haben bereits darüber gesprochen auch diese Idee der Sicherheit mit einzubringen. Diese Idee: Wenn wir kleine Releases machen, die leichter rückgängig zu machen sind, werden wir weniger dieser katastrophalen Ausfälle haben. Nummer drei ist die Rede von glücklicheren Teams. Im Allgemeinen ziehen Teams es vor, agil zu arbeiten, anstatt nach dem Wasserfallverfahren zu arbeiten. Im Sinne eines Wasserfalls hat das Team nicht wirklich die Kontrolle. Es funktioniert auf einem Teil des Systems. Es übernimmt keine Verantwortung dafür. Es durchsetzt es nicht, stärkt das Team nicht. Vergeudet das ganze Gegenteil davon. Es befähigt das Team vollständig, Verantwortung für das zu übernehmen , was es baut und wie es es umsetzen wird. Und die Leute lieben es, dass Teams das geliebt haben, sie lieben das. Das Unternehmen vertraut ihnen diese Verantwortung an. Und dann sind sie in der Lage , diesen Job zu machen und sie können ihn gut machen. Und das bedeutet glücklichere Teams. Und aus Sicht des Managements bedeutet das einen geringeren Umsatz. Die Leute werden nicht gehen, weil sie mehr Spaß an ihrer Arbeit haben werden und deshalb im Unternehmen bleiben . Nummer vier besteht darin, anzuerkennen , dass Veränderungen beängstigend sind. Sie könnten sich über all diese Dinge Sorgen machen und wir können sagen: Nun, ja, das sind Bedenken. Wir sind uns zu 99% sicher, dass Windung besser ist als Wasserfall, weil heutzutage jeder auf die Beine kommt. Aber warum machen wir das nicht als Probe. Und eine Studie ist eine großartige Möglichkeit, Einwände zu umgehen, denn wenn Sie sagen, Okay, lassen Sie uns das für drei Monate oder sechs Monate versuchen und sehen, wie es funktioniert. Und wenn alles explodiert, wir zum Wasserfall zurück. Aber wenn es funktioniert und wir es erweitern und auf alle Teams ausweiten können , viel wahrscheinlicher, dass Sie Unterstützung erhalten, weil das wird es versuchen. Und es ist weniger riskant, weil es nur eine vorübergehende Sache ist. Aber dann versuchen wir es natürlich. Die wirklich gut arbeiten. Sie werden es lieben und wir werden es in der gesamten Organisation einführen können . 58. Coaching in guter Praxis: Wir haben diese Idee erwähnt, dass wir manchmal bewährte Verfahren coachen und Ihr Team ermutigen müssen , das gesamte Framework, das in Scrubs verfügbar ist, wirklich zu nutzen . Also, wie machen wir das? Wie coachen wir effektiv? Nun, Nummer eins ist, dort anzufangen, wo das Team jetzt ist, und zu sehen, was für sie funktioniert. Es besteht also manchmal die Tendenz, reinzugehen und einfach zu versuchen, Änderungen vorzunehmen. Aber wenn wir das tun, wäre das Team wahrscheinlich ziemlich oppositionell. Und sie sind zufrieden damit, wie die Dinge sind. Wenn wir reingehen, schauen wir, was funktioniert, schauen wir, was nicht funktioniert. Und wir können beobachten, wir können Fragen stellen und dann können wir sehen, was bei ihnen nicht ganz funktioniert. Und an diesem Punkt können wir anfangen, Änderungen vorzuschlagen und sagen, ich habe gemerkt, dass das bei dir nicht funktioniert. Wie wäre es, wenn wir es auf diese Weise versuchen, vielleicht würde das helfen, das Problem zu lösen. Machen Sie Vorschläge, keine Befehle. Die Leute mögen es im Allgemeinen nicht , wenn ihnen gesagt wird, was sie tun sollen. Wie wir gerade besprochen Wenn wir Vorschläge machen und sie dem Team anbieten können, können sie sich dafür entscheiden, sie anzunehmen. Sie können sich dafür entscheiden, es nicht anzunehmen. Wenn sie das Gefühl haben, die Kontrolle über die Änderungen zu haben, werden sie viel mehr damit einverstanden sie vorzunehmen, als wenn wir versuchen, ihnen etwas aufzuzwingen. Benutze wie oder welche Fragen, anstatt warum wir jemanden fragen Warum machst du das so? Das klingt ziemlich anklagend. Und das bringt die Leute in die Defensive. Wenn wir Fragen wie oder was verwenden wie, okay, nun, wie macht man das und wie ist das? Wie funktioniert das für dich? Dann bringen Sie die Leute dazu, die Situation etwas genauer zu untersuchen , anstatt in die Defensive zu wie sie es bei Warum-Fragen tun können. Denken Sie daran, dass es keine Religion ist, sich in ArcGIS zu winden. Konzentrieren Sie sich also darauf, was funktioniert, nehmen Sie ihm, was funktioniert, und Sie müssen nicht verwenden, was nicht funktioniert. Wenn etwas innerhalb des Scrum-Frameworks für Sie nicht ganz funktioniert , verwenden Sie dieses Bit nicht, verwenden Sie die Teile, die für Sie in Ihrer Organisation, in Ihrem Team, was auch immer es ist, nehmen Sie die guten Dinge und seien Sie nicht zu dogmatisch, was die Regeln angeht. Sei ein Vorbild. Das Wichtigste, was wir tun können , ist, selbst bewährte Verfahren zu befolgen. Wenn wir es nicht verfolgen, können wir nicht erwarten, dass andere Leute es befolgen. Wenn es also Bereiche gibt, in denen wir der Meinung sind, dass wir vielleicht nicht ganz mit unserer Vorstellung von Best Practice übereinstimmen , dann versuchen wir, uns auf diesen Kurs zu konzentrieren, damit wir vorleben, wie dann versuchen wir, uns auf diesen Kurs zu konzentrieren, damit gute Praxis aussieht. Und wenn die Leute sehen, dass es für uns funktioniert, dann glaube ich nicht, dass es für Chris funktioniert, vielleicht übernehme ich das auch. Sehen Sie sich das Gesamtbild an, das Teams innerhalb von Organisationen darstellen. Manchmal macht das Team etwas auf eine bestimmte Art und es gibt einen besseren Weg, es zu tun. Aber manchmal ist das der beste Weg, dies innerhalb der Organisationsstruktur zu tun , in der sie enthalten sind. Daher ist es wichtig , darüber nachzudenken, wie die allgemeinen Unternehmenswerte auf das Team auswirken und es dazu bringen könnten , Dinge auf eine bestimmte Art und Weise zu tun. Und dann probiere Änderungen als Experiment aus. Veränderung kann also beängstigend sein, aber wenn wir sie als Experiment verkaufen, warum versuchen wir das nicht einfach für die nächsten beiden Sprints und sehen, wie es funktioniert. Es ist viel wahrscheinlicher, dass Menschen sich darauf einlassen, weil sie nicht glauben, dass sie sich zu einer dauerhaften Änderung der Ziffern verpflichten. Okay, wir werden es für Sprint versuchen. Zwei Sprints sind ein paar Monate, was auch immer es ist Wenn Sie versuchen zu schwimmen, möchten Sie sich wahrscheinlich auf einen längeren Zeitraum festlegen, vielleicht mindestens drei bis sechs Monate, so etwas. Aber wenn Sie es als Experiment formulieren, versuchen wir es und wir können zum alten Weg zurückkehren. Wenn es nicht funktioniert, werden die Leute viel entspannter Dinge ausprobieren, als wenn Sie sagen, richtig, wir müssen jetzt umstellen. Das klingt sehr dauerhaft und sehr beängstigend, wenn wir sagen, versuchen wir es als Experiment und sehen, ob es funktioniert oder nicht. Wahrscheinlichkeit, dass sich die Leute engagieren, ist viel höher. 59. So skalieren Sie Scrum: Scrum ist für ein Team von etwa zehn Personen im Team konzipiert etwa zehn Personen und es wird langsam unüberschaubar. In einem täglichen Gedränge kann man nicht alles erledigen. Und das heißt, die Updates sind weniger aussagekräftig weil die Leute hier und die Leute hier, ich werde wahrscheinlich an verschiedenen Dingen arbeiten. Die Updates funktionieren also nicht wirklich und es ist keine so sehr Teamumgebung. Aber was passiert, wenn Sie ein Projekt haben, an dem mehr als zehn Personen arbeiten müssen , wie wir es oft in der Wirtschaft tun. Nun, in diesem Fall benötigen Sie mehrere Scrum-Teams. Aber das Problem ist, was passiert, wenn das Scrum-Team anfängt, sich gegenseitig auf die Zehen zu treten und sich gegenseitig in die Quere zu kommen. Wie skalieren wir von einem einzelnen Scrum-Team auf mehrere Scrum-Teams? Nun, das werden wir uns in diesem Modul ansehen. 60. Scrum of Scrums: Wenn wir mehrere Scrum-Teams haben und diese in der Lage sein müssen, miteinander zu kommunizieren, damit sie sich nicht gegenseitig auf die Füße treten. Also, wie erreichen wir das? Nun, eine Lösung ist Scrum of Scrums. Das ist also im Wesentlichen ein tägliches Gedränge. Also das Gleiche wie beim Daily Scrum. Aber jedes Scrum-Team schickt eine Delikatesse und das bildet ein bisschen mehr Scrum of Scrums. Es könnte also täglich durchgeführt werden, könnte auch wöchentlich durchgeführt werden, wenn das in Ihrer Organisation funktioniert oder welche Frequenz auch immer für Sie geeignet ist. Aber es ist dasselbe Format wie ein Daily Scrum. Jedes Schwimmen wird von einer Person repräsentiert, und das kann jeder sein. Es könnte also der Scrum Master sein, wenn das Sinn macht, könnte er beispielsweise ein Lead Engineer sein, aber es könnte wirklich jeder sein. Sie könnten das Team abwechseln, sodass jeder an der Reihe ist, zum Scrum of Scrums zu gehen und zu sehen, wie es funktioniert. Wenn Sie sich im Scrum of Scrum selbst befinden, funktioniert es wie das tägliche Scrum. Die zu stellende Frage ist also: Was haben wir getan? Vor allem Dinge, die sich auf andere Teams auswirken könnten? Was tun wir gerade, was sich auf Teams auswirken könnte und mit welchen Blockern könnten uns andere Teams helfen? So wie wir bei unserem täglichen Scrum darüber sprechen, was wir individuell zuvor gemacht haben, gerade gemacht haben und welche Hindernisse wir haben, kommen wir zum Scrum of Scrums und sagen für unser Team Das haben wir getan, daran arbeiten wir. Das sind Blockaden, bei denen wir Hilfe benötigen. Jedes Team beteiligt sich, damit die Teams wissen, woran jeder von uns arbeitet. Und dann kehrt der Delegierte zu seinem individuellen Scrum-Team zurück und gibt dem Rest des Teams Feedback und irrelevante Informationen. 61. Splitting Produkte: Ein Schlüsselkonzept in Scrum ist, dass ein Produkt einen Product Owner hat. Du kannst kein einziges Produkt haben. Wir haben mehrere Product Owner. Was passiert, wenn Sie Scrum-Teams haben , die am selben Projekt arbeiten müssen. Klingt so, als ob Sie in jedem Team zwei verschiedene Product Owner haben möchten, die an demselben Produkt arbeiten möchten. Wie gehst du damit um? Nun, in diesem Fall müssen wir die Produkte irgendwie in separate Abschnitte aufteilen . Lassen Sie uns als Beispiel noch einmal unsere E-Commerce-Website aufrufen. Es ist ein großer Kampf und wir möchten, dass zwei verschiedene Scrum-Teams daran arbeiten. Wir können jedoch nicht zwei Produkteigentümer haben , die die E-Commerce-Website besitzen. Was wir z.B. tun könnten, ist es in Frontend und Backend aufzuteilen. Also nach Frontend-Domain die Dinge, die der Kunde sieht, wenn er auf die Website kommt, um zu stöbern. Und dann ist das Backend-System die Dinge, mit denen das Lagerpersonal und das Verkaufsteam das für die E-Commerce-Website arbeitet alle Bestellungen verwalten und versenden. diese trennen, können Sie ein Scrum-Team haben für jedes die Verantwortung übernimmt. So können Sie Scrum-Team auf der kundenseitigen Seite arbeiten lassen. Scrum-Team arbeitet am Backend des Produkts und Sie haben für jeden einen Product Owner, der diese verwaltet. Eine weitere Lösung, die Sie tun könnten, ist, einen Product Owner in mehreren Scrum-Teams arbeiten zu lassen. Team A arbeitet also am Frontend, Team B arbeitet am Backend. Und es gibt einen Product Owner, der leitet und in beiden Teams arbeitet, was zu einem ziemlich vielbeschäftigten Product Owner führt. Aber je nachdem, wie viele Entscheidungen und wie viel Autonomie das Team hat, kann das auch ganz gut funktionieren. 62. Sprint: Wenn Sie mehrere Scrum-Teams haben, sollten Sie vielleicht anfangen über die Ausrichtung von Sprints nachzudenken. Also, wenn Sie Team A und Team B haben oder deren Sprints gleichzeitig beginnen? Werden sie anders sein? Die Zeit, sie gleichzeitig arbeiten zu lassen, funktioniert ganz gut denn wenn Sie einige Blocker wie TMA haben , wird durch etwas blockiert, an dem Team B arbeitet. Das Team fing an, daran zu arbeiten und sagte, sprinten Sie frei und das Team hat eine Nase, dass sie es im vierten Sprint aufnehmen können , schimmert, es ist fertig. Und so ist alles aufeinander abgestimmt. Sie können Ihre Produkt-Roadmaps aufeinander abstimmen. Man kann also sagen, grob gesagt, wir werden TMA in diesem Team arbeiten lassen, daran arbeiten lassen. Und dann, in zwei Wochen, wenn der Sprint und wir das ändern. kann also sehr nützlich sein, sie aufeinander abzustimmen. Für einige Organisationen funktioniert es besser, sie nicht nur aus logistischen Gründen aufeinander abzustimmen. So sicher, dass Sie nur einen Besprechungsraum haben. Wenn Sie dann alle Ihre Scrum-Teams haben , die Aspirin beginnen und beenden, werden sie am selben Tag verbracht. Sie werden beide den Besprechungsraum für Sprint Planning und für Retrospektiven am selben Tag wollen . In diesen Fällen sollten Sie also vielleicht sogar einen Stern für das Sprintteam haben und einen zweiwöchigen Sprint machen und das Sprintteam B etwa eine Woche später hier starten. Also der Offset, damit sie nicht auf diese Treffen mit Konflikten stoßen. In Bezug auf die Abstimmung Abstimmung der verschiedenen ausgegebenen Teams. Hier kann es sehr nützlich sein, die Sprintlänge zu variieren . Nehmen wir an, Sie hatten TMA und dann haben Sie eine Woche später Team Be On gekauft. Aber du willst eigentlich ihre Sprints aufeinander abstimmen und du könntest Team A einen dreiwöchigen Sprint machen lassen, sodass beide gleichzeitig enden. Oder Sie könnten TB auf einen einwöchigen Sprint reduzieren lassen. Und danach gehen sie zurück zu, wenn Sie standardmäßig zweiwöchige Sprints verwenden, sie gehen zurück zu den beiden Ausgaben und stimmen dann ab. Sie können es also einfach so machen , wie Sie möchten, aber es kann sehr nützlich sein, vorher ein wenig darüber zu ob Sie sie ausgerichtet haben möchten oder nicht und wie Sie sie anhand von Sprintlängen ausrichten sprechen, ob Sie sie ausgerichtet haben möchten oder nicht und wie Sie sie anhand von Sprintlängen ausrichten werden. 63. Andere Methodiken: Dieser Kurs hat sich auf Scrum konzentriert, aber es gibt auch andere agile Methoden Sie vielleicht von Zeit zu Zeit verwenden möchten und über Frameworks, die Sie vielleicht zusätzlich zu SCRUM einsetzen möchten , die wirklich zu Grown passen. In diesem Modul werden wir sie über agile Methoden und Frameworks besprechen , über die Sie bei der Arbeit innerhalb von Scrum wirklich Bescheid wissen sollten . 64. Kanban: Scrum und Kanban sind wahrscheinlich die beliebtesten agilen Frameworks für das Management von Projekten. Also, wann würdest du Squirm verwenden und wann würdest du Agile verwenden, was wirklich gut für die Umsetzung neuer Projekte geeignet ist, bei denen du etwas baust, eine Greenfield-Sache, du hast ein Stück Arbeit zu erledigen. Weißt du, du hast, sagen wir, sechs Monate, um das zu tun. Und du musst nur all die Dinge durchstehen. Kanban ist in der Regel eher für eine Art Business-as-usual-Umgebung geeignet . Vielleicht haben Sie Ihre E-Commerce-Plattform bereits aufgebaut. Es ist live und du musst nur sehen, was passiert. Kleine Verbesserungen, kleine Korrekturen. Sie haben nicht die Art von großer Produkt-Roadmap, die Sie sich erarbeitet haben. Sie müssen jedoch viel schneller auf Dinge reagieren da Sie es mit aktuellen Problemen auf der Website zu tun haben. Kanban funktioniert also ein bisschen anders, da es kein Sprint Scrum gibt. Wir haben diese Vorstellung von Sprints und wir haben, sagen wir, einen zweiwöchigen Block. Wir entscheiden, was wir machen werden und beginnen mit zwei Wochen und wir machen es zwei Wochen lang und wir werden überprüfen, was wir tun werden. In Kanban. Es gibt einen kontinuierlichen Vorstand und den Produktbestand. Und die Art von dem, was wir vom Sprint Backlog halten, der To-do-Liste, ist alles dasselbe. Der Produkt-Backlog ist also alles, alles bereits in der To-do-Spalte auf dem Board und in der Reihenfolge ihrer Priorität, sodass Sie die oberste Spalte auswählen. Nehmen wir also noch einmal unsere E-Commerce-Plattform. Wir haben es live. Und wir haben festgestellt, dass das Währungssymbol nicht ganz angezeigt wird, oder? Für einige Benutzer. Und das ist ein wirklich großes Problem , weil es um Zahlungen geht. Der Product Owner würde also ein Ticket ausstellen und sagen, das Währungssymbol nicht richtig angezeigt wird, dass das Währungssymbol nicht richtig angezeigt wird, es wahrscheinlich direkt an den Anfang des Backlogs schicken. Also der nächste Ingenieur , der etwas abholt, können wir das abholen. Anstatt also diese Sprints zu haben, ist alles nur in einer Liste. Du nimmst das Wichtigste und wenn etwas dringend erledigt werden muss, bringst du es einfach rein und stellst es direkt an die Spitze des Backlogs, damit du daran arbeiten kannst. Das bedeutet nun, dass wir in Scrum die Geschwindigkeit messen. Wie gut wir abschneiden, ist mehr Punkte wir pro Sprint bekommen können, desto besser geht es uns. In Kanban sprechen wir von Zykluszeit. Also, von dem Punkt an, an dem das Ticket ausgestellt ist, wie schnell können wir es auf die allgemeine Ebene bringen und veröffentlichen und erledigen. Kurz zusammengefasst: Scrum eignet sich hervorragend, wenn Sie feste Aufgaben haben und gerne in diesen zweiwöchigen Sprints arbeiten, sobald Sie etwas da draußen haben und nur noch kleine Änderungen vornehmen müssen. Und du machst dir weniger Sorgen, eine große Arbeit zu erledigen. Sie müssen diese Korrekturen nur schnell erledigen. Kanban kann nützlicher sein. Da. 65. Extreme Programmierung: Extreme Programming ist ein agiler Ansatz zum Schreiben von Code. Agile selbst ist zwar kein klares Regelwerk, aber es gab einmal eine Reihe von Prinzipien und eine Reihe von Techniken, die sich zu dem zusammenfügen , was wir als extreme Programmierung bezeichnen würden. Oft arbeiten mehrere Personen an demselben Code. Das könnte also paarweise geschriebener Code sein, Pair Programming, bei dem eine Person der Pilot ist und die Dinge tatsächlich tippt, aber sie arbeitet mit jemandem neben ihnen sitzt und die Entscheidungen durchspricht , sodass beide erkennen können , was funktioniert und wie es gestaltet werden muss. Sie können sogar auf Mob-Programmierung hochskalieren. Also vier oder fünf Leute die sich ein Stück Code ansehen, entweder auf ihren eigenen Computern, die in Echtzeit zusammenarbeiten, oder alle sitzen rund um den Computer, falls das für Sie funktioniert. diese Weise wird wirklich qualitativ hochwertiger Code gewährleistet. Aber das dauert natürlich länger. Wenn Sie zu zweit sind, schreibt nur die Hälfte Ihrer Ingenieure Code und noch mehr Mob-Programmierung. Also. Der Code sollte von einer anderen Person gründlich geprüft und genehmigt werden. Das sollte also in allem enthalten sein, was du schreibst. Wenn Sie einen Code schreiben, senden Sie eine Pull-Anfrage oder einen Code-Review an eine andere Person. Und jemand anderes sollte diesen Code durchsehen und sicherstellen, dass er Sinn macht. Geben Sie Kommentare ab und geben Sie sie an die Person zurück. Wenn eine Passage sofort oder wenn Änderungen erforderlich oder vorgeschlagen werden, geben Sie sie an den Autor zurück, um zu prüfen, ob er diese Änderungen vornehmen möchte. Automatisierte Aufgaben sollten für alles geschrieben werden. dieser Idee der kontinuierlichen Integration und kontinuierlichen Bereitstellung näher zu kommen , sollten für jede Funktion, die wir schreiben, automatisierte Tests durchführen , da es für menschliche Tester unmöglich ist , alles zu es so einfach wie möglich zu halten. Wir wollen also wirklich immer so wenig Code wie möglich schreiben und ihn wiederverwendbar machen. Und wenn wir einen Code schreiben können, den wir an drei verschiedenen Stellen verwenden können , und den alten sperrigen Code löschen können, dann ist das großartig, denn weniger Codezeilen bedeuten weniger Stellen, an denen Dinge schief gehen können. Dann testgetriebene Entwicklung, über die wir in der nächsten Lektion sprechen werden. 66. Test-driven Entwicklung (TDD): Testgetriebene Entwicklung, auch kurz TDD genannt, ist eine Art, Code zu schreiben, bei der wir den Komponententest schreiben, bevor wir den eigentlichen Code selbst schreiben. Warum machen wir das? Nun, es verhindert, dass wir Code hinzufügen, den wir nicht benötigen. Wir haben also vorhin über die Idee gesprochen eine User Story zu schreiben und zu sagen, als Benutzer möchte ich das tun. Und dann können wir den Code schreiben und wissen, dass wir den Job erfüllt haben, sobald wir die Akzeptanzkriterien erfüllen. Nun, das ist im Grunde dasselbe , da wir zuerst den Test schreiben, um zu sagen, was dieser Code tun muss, um in der Lage zu sein. Und dann schreiben wir den Code , um diesen Text zu erfüllen. Sobald der Komponententest bestanden ist, können wir jetzt mit dem Schreiben von Code beginnen. Wir müssen keinen weiteren Auftrieb hinzufügen , weil wir den Komponententest bestanden haben und er daher alles tut, was wir brauchen. also zuerst den Test und danach den Funktionscode schreiben , können wir sicherstellen , dass alles Testabdeckung hat. Und zweitens werden wir den Code nicht überladen weil wir aufhören können, sobald der Test erfolgreich ist. 67. Verhaltensorientierte Entwicklung (BDD): Verhaltensgesteuerte Entwicklung ist eine Erweiterung der testgetriebenen Entwicklung, bei der wir unsere Tests in User Stories schreiben und dann den Code schreiben, um diese User Stories zu erfüllen. Also, was heißt das wirklich? Nehmen wir an, wir programmieren das Checkout-System für unsere E-Commerce-Plattform. Wir könnten eine Geschichte schreiben wie, als Kunde möchte ich den Gesamtbetrag meines Warenkorbs sehen können. Oder als Kunde möchte ich meine Bestellung bezahlen können. Und das wäre die Sprache , in der wir den Test schreiben. Das wäre unser Testbeispiel, und es ist sehr verständlich. Jeder kann kommen und sich das ansehen, der Product Owner könnte selbst schreiben. Jeder, der sich den Test ansieht, auch ein Laie, versteht, was dort vor sich geht. Wir haben dann eine Code-Ebene in der Mitte, die das in einen tatsächlichen Test umsetzt, bei dem gesagt wird, dass ich für meine Bestellung bezahlen möchte. Was sind die automatisierten Schritte, um das tatsächlich zu testen? Also die natürliche Sprache in einen Test übersetzen lassen. Und dann haben wir natürlich unseren Funktionscode, die eigentliche E-Commerce-Plattform selbst. Und es sind also ungefähr 33 Teile da drin. Was ist, was ist der Vorteil, das zu tun? Wenn wir den Code in natürlicher Sprache schreiben. Jeder kann es verstehen, der Product Owner, nichttechnische Dinge und kommen Sie rein und sehen Sie sich genau an, was wir testen. Zweitens konzentriert es sich wirklich darauf , diese Benutzeranforderungen zu erfüllen. Also können wir zuerst unseren Test schreiben. Ich benötige den Benutzer, um diese Zahlung abschließen zu können. Dann schreiben wir unseren Test und unseren Funktionscode , um das zu erfüllen. Und sobald wir das erfüllt haben, können wir aufhören. Wir fügen keinen zusätzlichen Aufwand hinzu, da wir wissen, dass die User Story definiert ist und wir bereits eine vollständige Testabdeckung dazu haben . Wir wissen also, dass wir es durch eine kontinuierliche Integrationspipeline laufen lassen können und alles wird hervorragend funktionieren , weil der Test alles abdeckt , wir nichts extra benötigen und jeder kann verstehen, was vor sich geht. Mittlerweile gibt es eine Reihe beliebter BDD-Frameworks für verhaltensorientierte Entwicklung . Wir haben Gurke in Ruby, wir haben B Hat in PHP, wir haben J Behave in Java, aber in welcher Sprache Sie auch arbeiten, es gibt wahrscheinlich ein BDD-Framework da draußen. Also ich würde empfehlen, raufzugehen , sich umzusehen und zu schauen, was da ist und es auszuprobieren und zu schauen, wie man damit zurecht kommt.