This page has been robot translated, sorry for typos if any. Original content here.

Wie erklärt man Oma, was Agile in 15 Minuten mit Bildern ist?

Beweglich in 15 Minuten mit Bildern
Ein großes Bild öffnet sich, wenn Sie in ein neues Fenster klicken!

Agile Softwareentwicklung Agile Methoden (Agile Methods) - Eine Reihe von Softwareentwicklungsansätzen, deren Schwerpunkt auf der Verwendung iterativer Entwicklung liegt, Anforderungen dynamisch formuliert und deren Umsetzung durch ständige Interaktion innerhalb der sich selbst organisierenden Arbeitsgruppen, die aus Spezialisten in verschiedenen Bereichen bestehen, gewährleistet. Es gibt verschiedene Methoden, die sich auf die Klasse der flexiblen Entwicklungsmethoden beziehen, insbesondere Extreme Programming, DSDM, Scrum und FDD.

Es wird als effektive Praxis genutzt, um die Arbeit von kleinen Gruppen (die homogene kreative Arbeit leisten) in Kombination mit ihrer Verwaltung durch die kombinierte (liberale und demokratische) Methode zu organisieren. Die meisten flexiblen Methoden zielen auf die Minimierung von Risiken ab, indem die Entwicklung auf eine Reihe kurzer Zyklen (Iterationen) beschränkt wird, die normalerweise zwei bis drei Wochen dauern. Jede Iteration an sich sieht aus wie ein Softwareprojekt im Miniaturformat und enthält alle Aufgaben, die für die Ausgabe eines Mini-Gains in der Funktionalität erforderlich sind: Planung, Anforderungsanalyse, Entwurf, Programmierung, Testen und Dokumentation. Obwohl eine separate Iteration normalerweise nicht ausreicht, um eine neue Version eines Produkts zu veröffentlichen, wird davon ausgegangen, dass ein flexibles Softwareprojekt am Ende jeder Iteration zur Veröffentlichung bereit ist. Am Ende jeder Iteration überprüft das Team die Entwicklungsprioritäten neu.

Agile Methoden betonen die direkte Kommunikation von Angesicht zu Angesicht. Die meisten agilen Teams befinden sich im selben Büro, manchmal auch Englisch genannt. bullpen. Es umfasst mindestens „Kunden“ (der Produktbesitzer ist der Kunde oder sein Bevollmächtigter, der die Anforderungen an das Produkt definiert; diese Rolle kann vom Projektmanager, vom Business Analyst oder vom Kunden wahrgenommen werden). Das Büro kann auch Tester, Interface-Designer, technische Redakteure und Manager umfassen. Die Hauptmetrik agiler Methoden ist das Arbeitsprodukt. Durch die Bevorzugung der direkten Kommunikation reduzieren agile Methoden den Umfang der schriftlichen Dokumentation im Vergleich zu anderen Methoden. Dies führte zu Kritik an diesen Methoden als undiszipliniert.

Das meistgesehene YouTube-Video zu Agile. 744,625 Ansichten zum Zeitpunkt der Veröffentlichung dieses Artikels. Einfacher Schreibstil, Bilder und nur 15 Minuten - das Beste, was ich je gesehen habe. TED ruht sich aus.

"Jedes Geschäft dauert immer länger als erwartet, auch wenn wir das Gesetz von Hofstadter berücksichtigen." - Das Gesetz von Hofstadter

Rollen

Agile за 15 минут с картинками

Dies ist Pat, der Besitzer des Produkts. Sie kennt die technischen Details nicht, aber sie hat eine Vorstellung vom Gesamtbild, sie weiß, warum wir das Produkt herstellen, welche Probleme es für wen lösen wird.

Agile за 15 минут с картинками

Dies sind interessierte Parteien. Sie verwenden das Produkt, unterstützen es oder werden irgendwie in die Entwicklung einbezogen.

Agile за 15 минут с картинками

Dies sind Benutzergeschichten. Sie äußerten die Wünsche der Stakeholder. Zum Beispiel "der Benutzer muss eine Flugsuche im Ticketbuchungssystem durchführen."

Agile за 15 минут с картинками

Stakeholder haben viele Ideen, und Pat hilft dabei, aus Ideen individuelle Geschichten zu machen.

Agile за 15 минут с картинками

Dies ist das Entwicklungsteam. Diejenigen, die ein funktionierendes System aufbauen werden.

Agile за 15 минут с картинками

Bandbreite

Agile за 15 минут с картинками

Da das Team eine flexible Entwicklungsmethodik verwendet, speichert es all diese Geschichten nicht bis zu einer großen Veröffentlichung, im Gegenteil, sie veröffentlicht sie sofort und so oft wie möglich. Normalerweise veröffentlichen sie 4-6 User Storys pro Woche. Das ist ihre Bandbreite. Es ist sehr einfach zu messen - die Anzahl der User Stories in 7 Tagen.

Einige Geschichten sind groß, sie können als zwei gezählt werden, andere sind klein, sie können als die Hälfte gezählt werden.

Um diesen Rhythmus aufrechtzuerhalten und sich nicht im manuellen Regressionstest zu verlieren, arbeitet das Team intensiv am automatischen Testen und der ständigen Integration. Daher müssen für jede Funktion Autotests geschrieben werden, und der größte Teil des Codes verfügt über integrierte Autotests.

Agile за 15 минут с картинками

Das Problem ist, dass es viele Stakeholder gibt und ihre Anfragen nicht mit 4-6 Geschichten pro Woche zufrieden gestellt werden können.

Jedes Mal, wenn wir eine User Story implementieren, haben sie einige weitere Ideen, aus denen noch mehr Abfragen fließen.

Was passiert, wenn wir alles tun, was sie von uns verlangen? Wir werden eine Überlastung haben.

Agile за 15 минут с картинками

Nehmen wir an, das Team wird in dieser Woche 10 neue Storys aufnehmen, bei Eingabe 10 und Ausgabe 4-6 ist das Team überlastet. Es wird sich beeilen, zwischen Aufgaben wechseln, die Motivation verlieren, wodurch die Produktivität und Qualität abnimmt. Dies ist eine Strategie des Verlierens.

Scrum und XP verwenden in diesem Fall die Methode von gestern. Das Team sagt: "Wir haben in der letzten Woche 4-6 Funktionen fertiggestellt. Welche 4-6 Funktionen werden wir nächste Woche durchführen?"

Der Product Owner hat die Aufgabe, die User Storys auszuwählen, die in dieser Woche implementiert werden.

Kanban empfiehlt, es auf mehrere Aufgaben zu beschränken - WIP-Limit. Angenommen, das Team entscheidet, dass 5 eine akzeptable Anzahl von User Storys ist, an denen sie gleichzeitig arbeiten können, ohne zu überladen, ohne von einer zu anderen zu springen.

Agile за 15 минут с картинками

Beide Ansätze funktionieren gut und beide erstellen eine Warteschlange mit Aufgaben, die in Scrum als Backlog oder als priorisierte Liste von Aufgaben bezeichnet wird.

Diese Warteschlange muss ebenfalls verwaltet werden: Wenn interessierte Parteien 10 Geschichten pro Woche anfordern und das Team 4-6 Geschichten implementiert, wird diese Warteschlange immer mehr. Und in Kürze wird Ihr Rückstand sechs Monate im Voraus geplant. Das ist eine Geschichte, die auf die Veröffentlichung von 6 Monaten warten wird.

Es gibt nur eine Möglichkeit, eine Liste von Aufgaben unter Kontrolle zu halten - dies ist das Wort "Nein".

Agile за 15 минут с картинками

Dies ist das wichtigste Wort für den Besitzer des Produkts. Er muss ihn jeden Tag vor dem Spiegel trainieren.

Sagen Sie "Ja" ist einfach. Die wichtigere Aufgabe ist es jedoch, zu entscheiden, was nicht zu tun ist, und die Verantwortung dafür zu tragen. Der Produktbesitzer bestimmt auch die Reihenfolge dessen, was wir jetzt tun und was später. Dies ist eine schwierige Aufgabe und sollte mit dem Entwicklungsteam und mindestens einer interessierten Person erledigt werden.

Agile за 15 минут с картинками

Um richtig Prioritäten zu setzen, muss der Produktbesitzer den Wert jeder Story und ihres Volumens verstehen.

Entscheidungsfindung

Einige Geschichten werden dringend benötigt und andere sind nur Bonusfunktionen. Es dauert ein paar Stunden, um einige Geschichten zu entwickeln, Monate, um andere zu entwickeln.

Wie hängen die Größe der Story und ihr Wert zusammen? Nein

Heißt nicht mehr besser Der Wert und die Komplexität der Aufgabe - dies hilft Pat bei der Priorisierung.

Wie bestimmt der Product Owner den Wert und das Volumen der Story? Nein

Dies ist ein Ratespiel. Und es ist besser, an allem teilzunehmen. Pat kommuniziert ständig mit den Stakeholdern, um den Wert der einzelnen Storys zu kennen, und kommuniziert mit dem Entwicklungsteam, um den Umfang der Arbeit zu kennen. Dies alles sind ungefähre Annahmen, keine genauen Zahlen. Am Anfang wird es immer Fehler geben, und das ist in Ordnung. Kommunikation ist viel wertvoller als hochpräzise Zahlen.

Jedes Mal, wenn Entwickler etwas Neues veröffentlichen, erfahren wir mehr Informationen und können besser navigieren.

Eine Priorisierung reicht nicht aus. Um Geschichten schnell und häufig zu veröffentlichen, müssen Sie in Stücke zerlegen, die in wenigen Tagen fertiggestellt werden können. Wir wollen kleine und klare Geschichten am Anfang des Trichters und groß und unbestimmt am Ende. Bei einer solchen Panne können wir unsere neuesten Erkenntnisse bezüglich des Produkts und der Bedürfnisse des Benutzers nutzen. Dies wird als Rückstandsbereinigung bezeichnet.

Pat veranstaltet jeden Mittwoch von 11 bis 12 Uhr ein Meeting, um den Rückstand aufzuräumen. Normalerweise versammeln sich das gesamte Team und manchmal auch mehrere interessierte Personen. Der Inhalt der Meetings ist unterschiedlich. Konzentrieren Sie sich auf die Bewertung, die Aufschlüsselung der Geschichten, auf die Akzeptanzkriterien.

Der Besitzer des IT-Produkts muss ständig mit allen kommunizieren

Solide Produktbesitzer identifizieren zwei Komponenten des Erfolgs: Leidenschaft für Arbeit und Kommunikation. Welche Aufgaben löst der Besitzer des Produkts mit dem Team ab.

Balance zwischen Design-Komplexität und User Story-Wert

In einem frühen Stadium ist das Gleichgewicht durch Unsicherheit und mehrere Risiken gleichzeitig gefährdet.

Risiken

Agile за 15 минут с картинками

  • Geschäftsrisiko: "Tun wir das Richtige?"
  • Soziales Risiko: "Können wir tun, was wir brauchen?"
  • Technisches Risiko: "Funktioniert das Projekt auf dieser Plattform?"
  • Risiken bei den Kosten und dem Zeitpunkt der Implementierung: "Haben wir Zeit und wird es genug Geld geben?"

Wissen kann als das Gegenteil von Risiko betrachtet werden. Wenn die Unsicherheit groß ist, konzentrieren wir uns auf den Erwerb von Wissen - Schnittstellenprototypen, technische Experimente.

Der Kompromiss zwischen Wissenswerten und Kundenwerten

Aus der Sicht des Kunden sieht die Kurve so aus:

Agile за 15 минут с картинками

In Bezug auf den Kundennutzen sieht diese Kurve so aus.

Agile за 15 минут с картинками

Bei abnehmenden Unsicherheiten können wir uns auf die Kundenwerte konzentrieren. Wir wissen was zu tun ist und wie. Es bleibt nur noch zu tun. Nachdem die Hauptgeschichten implementiert wurden, werden wir Bonusfunktionen erstellen oder ein neues Projekt starten.

Der Kompromiss zwischen kurzfristigem und langfristigem Denken

Agile за 15 минут с картинками

Was muss zuerst implementiert werden? Beheben Sie dringend Fehler oder beginnen Sie mit der Entwicklung einer beeindruckenden Funktion, die Benutzer in Erstaunen versetzen wird. Oder führen Sie ein komplexes Plattform-Upgrade durch, das die Arbeit in der Zukunft beschleunigen wird. Es ist notwendig, ständig ein Gleichgewicht zwischen reaktiver und proaktiver Arbeit zu halten.

Das Richtige tun, das Richtige tun, oder schnell?

Agile за 15 минут с картинками

Im Idealfall sind alle drei gleichzeitig, aber in Wirklichkeit müssen Sie wählen.

Agile за 15 минут с картинками

Angenommen, wir sind hier. Wir versuchen, das perfekte Produkt mit der perfekten Architektur zu schaffen. Wenn wir viel Zeit verbringen, können wir nicht in das "Marketingfenster" gelangen und haben Probleme mit dem Geld. Oder:

Agile за 15 минут с картинками

Wir machen einen schnellen Produktprototyp. Kurzfristig ist das nicht schlecht. Langfristig bekommen wir ein technisches Risiko. Und die Entwicklungsgeschwindigkeit wird auf null sinken. Oder:

Agile за 15 минут с картинками

Wir sind hier und schaffen in Rekordzeit einen schönen Tempel. Aber der Benutzer brauchte keinen Tempel, er brauchte eine Karawane.

Es gibt eine gesunde Konfrontation zwischen den Rollen in Scrum.

Agile за 15 минут с картинками

Der Product Owner konzentriert sich darauf, die richtigen Dinge zu bauen. Das Team konzentriert sich auf den richtigen Aufbau. Ein Scrum Master oder ein agiler Trainer konzentriert sich auf die Reduzierung des Feedback-Zyklus.

Unabhängig davon ist es wichtig, die Wichtigkeit der Geschwindigkeit hervorzuheben, da eine kurze Feedbackschleife das Lernen beschleunigt. So können wir schnell herausfinden, was richtig ist und wie man sie richtig baut.

Der Kompromiss zwischen der Entwicklung eines neuen Produkts und der Verbesserung des alten

Agile за 15 минут с картинками

Ein Produkt kann niemals vollständig fertiggestellt werden, da ständig Änderungen erforderlich sind. Wenn ein Team mit der Arbeit an einem neuen Produkt beginnt, was passiert mit dem alten? Die Übertragung eines Produkts von einem Team auf ein anderes ist sehr teuer und riskant. Normalerweise unterstützt das Team das alte Produkt, indem es ein neues entwickelt. Der Begriff „Backlog“ bezieht sich daher nicht auf das Produkt, sondern auf das Team. Backlog ist eine Liste von Dingen, die der Produktbesitzer vom Team wünscht. Und eine Reihe von Geschichten für verschiedene Produkte. Der Besitzer des Produkts muss ständig für die Implementierung relevante Auswahl treffen.

Zeitplan für die Zerstörung der Geschichte

Von Zeit zu Zeit werden interessierte Parteien Pat fragen: "Wann werden sie mein Feature veröffentlichen?" Oder "Wie viele Features werden sie bis Weihnachten veröffentlichen?". Der Produktbesitzer muss in der Lage sein, die Erwartungen der Benutzer zu verwalten. Und mit Erwartungen realistisch umgehen.

Agile за 15 минут с картинками

Zwei Trends - optimistisch und pessimistisch (mit dem Auge). Der Abstand zwischen den Trends zeigt, wie instabil die Geschwindigkeit des Teams ist. Im Laufe der Zeit werden sich diese Trends stabilisieren und der Unsicherheitskegel wird abnehmen.

Angenommen, eine interessierte Person fragt, wann diese Funktion ausgeführt wird.

Agile за 15 минут с картинками

Dies ist ein fester Inhalt und ein unbestimmtes Problem. Pat verwendet zwei Trendlinien, um zu antworten. Die Antwort ist im April oder Mai.

Agile за 15 минут с картинками

Die interessierte Partei fragt Pat: "Wie viel wird bis Weihnachten gemacht?" Dies ist eine befristete Frage mit unsicherem Inhalt. Die Trendlinien schneiden auf der vertikalen Skala das wahrscheinliche Segment der Zeit ab, die sie implementieren müssen.

Agile за 15 минут с картинками

Der Interessent fragt: „Haben wir Zeit, um diese Features bis Weihnachten zu gestalten?“ Dies ist eine Frage mit festen Zeitrahmen und festem Inhalt. Auf Trends fokussierend, antwortet Pat: „Nein.“ Ich füge hinzu: "Bis Weihnachten werden wir Zeit haben, so viel zu tun, aber es wird so viel Zeit brauchen, um diese Arbeit vollständig abzuschließen."

Es ist normalerweise besser, den Inhalt des Projekts zu reduzieren, als die Zeit zu erhöhen. Wenn wir den Inhalt reduzieren, haben wir die Möglichkeit, die Fristen zu verschieben. Wir können hier etwas veröffentlichen und den Rest später.

Der Besitzer des Produkts führt die Berechnungen wöchentlich durch und verwendet nur empirische Daten und gibt nicht die gewünschten Werte für die Realität aus. Er spricht ehrlich von Unsicherheit. Das Team hält das Tempo der Arbeit aufrecht, und Pat drängt nicht auf sie und zwingt sie zum Beschleunigen.

Mehrere Teams

Agile за 15 минут с картинками

Lassen Sie uns mehrere Produktbesitzer und mehrere Teams haben. Das Modell ist dasselbe: Bandbreitenmanagement, Kommunikation mit den Stakeholdern, Entscheidungen über die Ablehnung von User Storys. Die Geschwindigkeit entspricht der Summe der Geschwindigkeiten aller Teams. Die Vorhersage kann allgemein oder pro Team sein. Produktbesitzer haben eine zusätzliche Herausforderung - die Kommunikation mit anderen Produktbesitzern. Wir müssen die Arbeit an Backlogs so organisieren, dass Abhängigkeiten minimiert und die Synchronisation sichergestellt wird. In großen Projekten ist der Main Product Owner (CPO) erforderlich, um alle anderen zu synchronisieren.

Video auf Englisch

Video auf Russisch

Über Agile Product Ownership in aller Kürze & Wiki