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

Wie man Großmutter in 15 Minuten mit Bildern erklärt, was Agile ist

Agil in 15 Minuten mit Bildern
Ein großes Bild wird geöffnet, indem Sie in ein neues Fenster klicken!

Flexible Entwicklungsmethoden (Agile Softwareentwicklung, agile Methoden) sind eine Reihe von Ansätzen für die Softwareentwicklung, die sich auf die Verwendung iterativer Entwicklung, die dynamische Bildung von Anforderungen und deren Sicherstellung aufgrund der ständigen Interaktion in selbstorganisierenden Arbeitsgruppen, die aus Spezialisten verschiedener Profile bestehen, konzentrieren. Es gibt verschiedene Techniken, die zur Klasse der flexiblen Entwicklungsmethoden gehören, insbesondere extreme Programmierung, DSDM, Scrum, FDD.

Es wird als effektive Praxis verwendet, um die Arbeit kleiner Gruppen (die homogene kreative Arbeit leisten) in Kombination mit ihrem Management durch eine kombinierte (liberale und demokratische) Methode zu organisieren. Die meisten flexiblen Methoden zielen darauf ab, Risiken zu minimieren, indem die Entwicklung auf eine Reihe von kurzen Zyklen reduziert wird, die als Iterationen bezeichnet werden und normalerweise zwei bis drei Wochen dauern. Jede Iteration für sich sieht aus wie ein Softwareprojekt in Miniatur und umfasst alle Aufgaben, die erforderlich sind, um die Funktionalität zu erweitern: Planung, Anforderungsanalyse, Design, Programmierung, Test und Dokumentation. Obwohl eine einzelne Iteration normalerweise nicht ausreicht, um eine neue Version eines Produkts freizugeben, wird davon ausgegangen, dass ein flexibles Softwareprojekt am Ende jeder Iteration zur Veröffentlichung bereit ist. Am Ende jeder Iteration bewertet 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. Dazu gehören mindestens auch „Kunden“ (der englische Produktbesitzer ist der Kunde oder sein Bevollmächtigter, der die Anforderungen an das Produkt festlegt; diese Rolle kann vom Projektmanager, Geschäftsanalysten oder Kunden wahrgenommen werden). Das Büro kann auch Tester, Schnittstellendesigner, technische Redakteure und Manager umfassen. Die Hauptmetrik für agile Methoden ist ein funktionierendes Produkt. Agile Methoden bevorzugen die direkte Kommunikation und reduzieren den Umfang der schriftlichen Dokumentation im Vergleich zu anderen Methoden. Dies hat dazu geführt, dass diese Methoden als undiszipliniert kritisiert wurden.

Die meisten haben agile YouTube-Videos gesehen. 744.625 Aufrufe zum Zeitpunkt der Veröffentlichung dieses Artikels. Ein leichter Präsentationsstil, ein Bild und nur 15 Minuten sind das Beste, was ich je gesehen habe. TED ruht sich aus.

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

Rollen

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

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

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

Dies sind Stakeholder. Sie werden das Produkt verwenden, es unterstützen oder irgendwie in die Entwicklung involviert sein.

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

Dies sind User Stories. Sie äußerten die Wünsche der Interessenten. Beispiel: "Der Benutzer muss über ein Flugsuchsystem für ein Flugreservierungssystem verfügen."

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

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

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

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

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

Durchsatz

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

Da das Team eine flexible Entwicklungsmethode verwendet, sammeln sie nicht alle diese Geschichten bis zur großen Veröffentlichung, im Gegenteil, sie veröffentlichen sie sofort und so oft wie möglich. Normalerweise veröffentlichen sie 4-6 User Stories pro Woche. Dies 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 betrachtet werden, andere sind klein, sie können als die Hälfte betrachtet werden.

Um diesen Rhythmus beizubehalten und nicht bei manuellen Regressionstests hängen zu bleiben, arbeitet das Team intensiv an automatischen Tests und kontinuierlicher Integration. Daher müssen Sie für jede Funktion Autotests schreiben, und der größte Teil des Codes verfügt über integrierte Autotests.

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

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

Jedes Mal, wenn wir eine User Story implementieren, erhalten sie einige weitere Ideen, aus denen weitere Anfragen folgen.

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

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

Angenommen, ein Team verpflichtet sich, diese Woche 10 neue Geschichten zu schreiben. Wenn am Eingang 10 und am Ausgang 4-6 vorhanden sind, ist das Team überlastet. Er wird sich beeilen, zwischen Aufgaben wechseln, die Motivation verlieren, wodurch Produktivität und Qualität sinken. Dies ist eine Verluststrategie.

Scrum und XP verwenden in diesem Fall die Methode „Wetter von gestern“. Das Team sagt: "Vor kurzem haben wir 4-6 Features pro Woche gemacht. Welche 4-6 Features werden wir nächste Woche machen?"

Die Aufgabe des Product Owner ist es, richtig auszuwählen, welche User Stories diese Woche implementiert werden.

Kanban empfiehlt, sich auf einige Aufgaben zu beschränken - das WIP-Limit. Angenommen, das Team entscheidet, dass 5 eine akzeptable Anzahl von User Stories ist, an denen gleichzeitig ohne Überlastung gearbeitet werden kann, ohne von einem zum anderen zu springen.

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

Beide Ansätze funktionieren gut und beide erstellen eine Aufgabenwarteschlange, die Scrum als Backlog bezeichnet, oder eine priorisierte Aufgabenliste.

Diese Warteschlange muss ebenfalls verwaltet werden. Wenn Interessenten 10 Storys pro Woche anfordern und das Team 4-6 Storys implementiert, wird diese Warteschlange immer mehr. Und bald wird Ihr Backlog sechs Monate im Voraus geplant. Das heißt, eine Geschichte wird auf die Veröffentlichung von 6 Monaten warten.

Es gibt nur einen Weg, eine Liste von Aufgaben unter Kontrolle zu halten - das Wort „Nein“.

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

Dies ist das wichtigste Wort für den Product Owner. Er muss ihn jeden Tag vor dem Spiegel trainieren.

Ja zu sagen ist einfach. Die wichtigere Aufgabe ist jedoch, zu entscheiden, was nicht getan werden soll, und die Verantwortung dafür zu tragen. Der Eigentümer des Produkts bestimmt auch die Reihenfolge dessen, was wir jetzt und was später tun. Dies ist eine komplexe Arbeit und sollte zusammen mit dem Entwicklungsteam und mindestens einer interessierten Person durchgeführt werden.

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

Um die richtigen Prioritäten zu setzen, muss der Product Owner den Wert jeder Story und ihr Volumen verstehen.

Entscheidungsfindung

Einige Geschichten sind äußerst notwendig, andere sind nur Bonusfunktionen. Es wird ein paar Stunden dauern, um einige Geschichten zu entwickeln, und Monate, um andere zu entwickeln.

Wie ist die Größe der Geschichte mit ihrem Wert zu vergleichen? Auf keinen Fall.

Mehr heißt nicht besser. Der Wert und die Komplexität der Aufgabe helfen Pat, Prioritäten zu setzen.

Wie bestimmt der Product Owner den Wert und den Umfang der Geschichte? Auf keinen Fall.

Dies ist ein Ratespiel. Und es ist besser, an allem teilzunehmen. Pat kommuniziert ständig mit Interessenten, um den Wert jeder Geschichte zu erfahren, kommuniziert mit dem Entwicklungsteam, um den Arbeitsaufwand zu ermitteln, aber all dies sind ungefähre Vermutungen, keine genauen Zahlen. Am Anfang wird es immer Fehler geben und das ist normal. Kommunikation ist viel wertvoller als ultrapräzise Zahlen.

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

Priorisierung allein reicht nicht aus. Um Geschichten schnell und häufig zu veröffentlichen, müssen Sie sie in Teile zerlegen, die in ein paar Tagen fertig sind. Wir wollen kleine und klare Geschichten am Anfang des Trichters und große und unsichere am Ende. Pünktlich zu einer solchen Aufschlüsselung können wir unsere neuesten Entdeckungen in Bezug auf das Produkt und die Bedürfnisse des Benutzers nutzen. Dies wird alles als Backlog-Bereinigung bezeichnet.

Pat hält jeden Mittwoch von 11 bis 12 Uhr ein Meeting ab, um das Backlog zu bereinigen. Normalerweise versammeln sich das gesamte Team und manchmal mehrere interessierte Personen. Der Inhalt der Sitzungen ist unterschiedlich. Fokus auf Bewertung, Aufschlüsselung von Geschichten, Akzeptanzkriterien.

Der Eigentümer des IT-Produkts muss ständig mit allen kommunizieren

Unerfahrene Produktbesitzer unterscheiden zwei Erfolgskomponenten: Leidenschaft für Arbeit und Kommunikation. Welche Aufgaben entscheidet der Product Owner vor Ort mit dem Team?

Balance zwischen Entwicklungskomplexität und User Story-Wert

Das Gleichgewicht ist frühzeitig durch Unsicherheit und mehrere Risiken gleichzeitig bedroht.

Die 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 mit Kosten und Implementierungsbedingungen: „Werden wir erfolgreich sein und wird es genug Geld geben?“

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

Der Kompromiss zwischen Wissenswerten und Werten für den Kunden

Aus Sicht des Kunden sieht die Kurve folgendermaßen aus:

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

In Bezug auf den Kundennutzen sieht diese Kurve so aus.

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

Mit abnehmenden Unsicherheiten können wir uns auf die Kundenwerte konzentrieren. Wir wissen was und wie zu tun ist. Es bleibt nur zu tun. Nachdem wir die Hauptgeschichten implementiert haben, werden wir Bonusfunktionen ausführen oder ein neues Projekt starten.

Der Kompromiss zwischen kurzfristigem und langfristigem Denken

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

Was ist zuerst zu implementieren? Beheben Sie dringend Fehler oder entwickeln Sie eine beeindruckende Funktion, die die Benutzer in Erstaunen versetzen wird. Oder führen Sie ein komplexes Upgrade der Plattform durch, das die Arbeit in Zukunft beschleunigen wird. Es muss ständig ein Gleichgewicht zwischen reaktiver und proaktiver Arbeit gehalten werden.

Das Richtige tun, das Richtige tun oder es schnell tun?

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

Im Idealfall sind alle drei gleichzeitig, aber in Wirklichkeit muss man sich entscheiden.

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

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

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

Wir machen einen schnellen Prototyp des Produkts. Kurzfristig ist das nicht schlecht. Langfristig gehen wir technische Risiken ein. Und die Entwicklungsgeschwindigkeit wird auf Null fallen. Oder:

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

Wir sind hier und schaffen in Rekordzeit einen wunderschönen Tempel. Aber der Benutzer brauchte keinen Tempel, er brauchte einen Wohnwagen.

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 darauf, die Dinge richtig zu bauen. Ein Scrum Master oder Agile Trainer konzentriert sich auf die Verkürzung der Rückkopplungsschleife.

Unabhängig davon ist es wichtig, die Bedeutung der Geschwindigkeit hervorzuheben, da eine kurze Rückkopplungsschleife das Lernen beschleunigt. So können wir schnell herausfinden, welche Dinge richtig sind und wie man sie richtig baut.

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

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

Ein Produkt kann niemals vollständig fertiggestellt werden, da es ständig geändert werden muss. Was passiert mit dem alten, wenn ein Team mit der Arbeit an einem neuen Produkt beginnt? Die Übertragung eines Produkts von einem Team auf ein anderes ist sehr kostspielig und riskant. In der Regel wartet ein Team ein altes Produkt, während es ein neues entwickelt. Daher bezieht sich das Konzept des „Backlog“ nicht auf das Produkt, sondern auf das Team. Backlog ist eine Liste von Dingen, die ein Product Owner von einem Team wünscht. Und eine Reihe von Geschichten für verschiedene Produkte. Der Eigentümer des Produkts muss ständig die für die Implementierung relevanten auswählen.

Zeitplan für die Zerstörung des Verlaufs

Von Zeit zu Zeit werden Interessenten Pat fragen: "Wann wird mein Feature veröffentlicht?" oder "Wie viele Funktionen werden bis Weihnachten veröffentlicht?" Der Product Owner muss in der Lage sein, die Benutzererwartungen zu verwalten. Und realistisch mit Erwartungen umgehen.

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

Zwei Trends - optimistisch und pessimistisch (mit dem Auge möglich). Der Abstand zwischen den Trends zeigt, wie instabil die Geschwindigkeit des Teams ist. Mit 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 festes Inhaltsproblem mit einer unbestimmten Laufzeit. Pat verwendet zwei Trendlinien, um zu antworten. Die Antwort ist im April oder Mai.

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

Eine interessierte Person fragt Pat: "Wie viel wird bis Weihnachten getan?" Dies ist ein befristetes Problem mit unsicherem Inhalt. Trendlinien schneiden auf vertikaler Skala ein wahrscheinliches Segment dessen ab, was sie implementieren müssen.

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

Eine interessierte Person fragt: "Werden wir es schaffen, diese Funktionen für Weihnachten zu erstellen?" Dies ist eine Frage mit festen Zeitrahmen und festen Inhalten. Pat konzentriert sich auf Trends und antwortet: „Nein.“ Fügte hinzu: „Bis Weihnachten werden wir Zeit haben, so viel zu tun, aber wir werden so viel Zeit benötigen, um all diese Arbeiten vollständig abzuschließen.“

In der Regel ist es besser, den Inhalt eines Projekts zu reduzieren, als die Zeit zu verlängern. 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 Eigentümer des Produkts führt wöchentlich Berechnungen durch, verwendet nur empirische Daten und gibt nicht an, was für die Realität erwünscht ist. Er spricht ehrlich über Unsicherheit. Das Team hält das Arbeitstempo aufrecht, und Pat übt keinen Druck auf sie aus und zwingt zur Beschleunigung.

Mehrere Teams

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

Lassen Sie uns mehrere Produktbesitzer und mehrere Teams haben. Das Modell ist das gleiche - Bandbreitenmanagement, Kommunikation mit interessierten Parteien, Entscheidungen über die Ablehnung von User Stories. Geschwindigkeit ist die Summe der Geschwindigkeiten aller Teams. Die Vorhersage kann allgemein oder für jedes Team erfolgen. Produktbesitzer haben eine zusätzliche Aufgabe - die Kommunikation mit anderen Produktbesitzern. Wir müssen die Arbeit an Backlogs organisieren, um Abhängigkeiten zu minimieren und die Synchronisation sicherzustellen. Für große Projekte ist ein Master Product Owner (CPO) erforderlich, um alle anderen zu synchronisieren.

Englisches Video

Video auf Russisch

Über Agile Product Ownership auf den Punkt gebracht & habrahabr.ru & wiki