Wie haben wir SCRUM gemacht?

Ein schrecklicher Traum eines Entwicklungsteams ist es, in einen unbekannten Themenbereich einzutauchen und eine halbherzige Idee zu „schätzen“, bevor Sie mit der Entwicklung beginnen. In diesem Fall müssen Sie zum festgelegten Zeitpunkt für einen festen Geldbetrag buchstäblich " Blut unterschreiben ".

In der Tat ist es unrealistisch, eine genaue Einschätzung ungenauer Anforderungen vorzunehmen. Ein typischer Weg im Projektmanagement besteht darin, vor Beginn der Entwicklung eine detaillierte TOR zu erstellen. Und dann implementieren Sie alle Funktionen in einem großen Stück. Ein solcher „ Wasserfall “ -Ansatz birgt jedoch andere Risiken: Starten eines Projekts im Stil eines „ Urknalls “ - wenn Sie das erste Ergebnis ganz am Ende des Projekts erhalten. Und es kann sehr weit von den tatsächlichen Geschäftszielen und Benutzeranforderungen entfernt sein.

Warum ein solches Risiko eingehen, wenn Sie einen ganz anderen Weg gehen können?

Warum SCRUM

Wenn wir uns mit dem Projekt vertraut machen, gibt es ein Verständnis: "Wir wissen, dass wir das nicht wissen" und sogar "Wir wissen nicht, wo die Grenzen dessen, was wir nicht wissen", SCRUM helfen



Die Besonderheiten von SCRUM können abschrecken, wenn Sie noch nie mit diesem Framework gearbeitet haben, da zu Beginn die Länge des Weges, den Sie gehen müssen, um ein funktionierendes Projekt zu erhalten, und die 100% ige Zufriedenheit noch nicht bekannt sind.

Es ist schwierig für den Kunden - er kann KEINEN strategischen Plan für die Entwicklung des Projekts mit zuverlässigen Veröffentlichungsterminen erstellen. Das Unbekannte ist beängstigend, besonders wenn Sie jetzt auf diese Weise bezahlen müssen.

Aber es gibt auch Vorteile : Der Kunde sollte zu Beginn nicht alle Funktionen und Merkmale eines riesigen zukünftigen Systems detailliert und gewissenhaft beschreiben. Darüber hinaus kann es jederzeit die Prioritäten ändern und sich an einen wettbewerbsorientierten externen Markt anpassen.

Dies war übrigens auch in diesem Fall der Fall , aber bald werden Sie sehen, wie wir aus einer schwierigen Situation herausgefahren sind, als wir gemeinsam mit dem Kunden herausgefunden haben, was und wie wir bereits unterwegs implementieren sollen.

SCRUM basiert auf dem Konzept kleiner Schritte: regelmäßige Veröffentlichung von Versionen laufender Software, so oft wie möglich und früher. Jede Iteration ist eine Mikrostufe der Entwicklung, die sofort durch die Praxis verifiziert wird.

Dies bedeutet, dass der Kunde nach der ersten Iteration eine recht nützliche, wenn auch kleine, aber funktionierende Funktionalität erhält, diese in der Praxis überprüft und sofort Feedback gibt.



Sehen Sie, wie wir die gesamte Arbeit organisiert haben: Wichtige Schlüsselentscheidungen - was ist der nächste Wert für das Unternehmen - das Team trifft vor jeder neuen Iteration. Daher entwickelt sich das System auf einem kritisch optimalen Weg, bis es für das Unternehmen am besten geeignet ist. Der Kunde hier ist Teil des Teams. Sowohl der Auftragnehmer als auch der Kunde sind für den Erfolg der Entwicklung verantwortlich. Sie befinden sich auf einer Seite der Barrikaden.

Das war bei uns der Fall, mal sehen?

Wir möchten über unsere Art der Anpassung des klassischen SCRUM-Frameworks an ein automatisiertes Steuerungssystem für die A + Academy of Modern Education sprechen. Dies ist ein modernes Bildungszentrum in Kiew, das eine Schule, einen Kindergarten, ein Zentrum für frühe Entwicklung, Musik, Tanz und Sport umfasst Schulen, Kunststudios und ein Zentrum für das Erlernen von Fremdsprachen. Insgesamt besuchen mehr als tausend Kinder fast 150 verschiedene Kurse an der Akademie.

SCRUM ist ein Framework, das bei der Lösung von Aufgaben hilft, die sich während des Arbeitsprozesses ändern, um Kunden Produkte mit dem höchstmöglichen Wert effizient und kreativ zu liefern

Der Vorteil von SCRUM und für einige der Nachteil ist, dass es sich um ein sehr leichtes Framework handelt. Es enthält keine Antworten auf alle Fragen und detaillierte Anweisungen für Teammitglieder. Scrum - "absichtlich unvollständig" und aufgrund dieser universellen.

SCRUM muss an jedes spezifische Projekt angepasst werden

Wie beginnen Kunden und Auftragnehmer mit der Arbeit an SCRUM?

Um in einem unbekannten Paradigma zu arbeiten, muss der Kunde manchmal sein gewohntes Denken ändern. Mit dem Darsteller im selben Kontext sein. Daher haben wir vor der Entwicklung des Systems für die Akademie ein gemeinsames Training mit den Jungs von Scrum Ukraine organisiert . Seine Hauptziele sind: sich kennenzulernen, die Terminologie zu verstehen, alle Techniken in einer Spielform zu erarbeiten, die Hauptaktivitäten zu simulieren, zu verstehen, wo man anfangen soll, Rollen zu verteilen und Verantwortlichkeiten zu registrieren.









Während eines dreitägigen gemeinsamen Trainings haben wir unter Verwendung der sogenannten Hubschrauberansicht das zukünftige System mit großen Strichen geformt und es in Form einer Projekt-RoadMap auf einer temporären Linie fixiert.

Hubschrauberansicht - eine allgemeine Beschreibung oder Meinung einer Situation, nicht eine detaillierte


Globale Produkt-RoadMap

Was sind unsere Schlussfolgerungen nach dieser Phase?

1. Gemeinsames Training hilft, das Denken des Kunden und des Teams zu ändern.
2. Mit Product RoadMap können Sie einen allgemeinen Entwicklungsplan visualisieren und Releases grob planen. Es ist wichtig zu verstehen, dass dies eine „Live-Roadmap“ ist, die sich mit der Entdeckung neuer Entwicklungsdetails ändern wird
3. Die Einigung über die globalen Spielregeln ist „am Ufer“ notwendig: Der Product Owner erhält nach jedem Sprint einen Wert - ein funktionierendes System, das sofort verwendet werden sollte und dann Feedback gibt.

Der dritte Absatz ist obligatorisch, ohne ihn wird nichts funktionieren. Da die Hoffnungen, nach abstrakter voller Bereitschaft im Finale zu starten, auf beiden Seiten zu Enttäuschungen führen:

• Seitens des Kunden: „Das haben wir angefordert, aber das brauchen wir nicht.“
• Seitens des Darstellers: „Wir haben klar getan, was Sie gefragt haben. Und jetzt klingen Ihre Anforderungen für uns ganz anders. Wir sind damit einverstanden, alles zu wiederholen, aber auf Ihre Kosten. Im Allgemeinen gibt es so viele Änderungen, dass die Fertigstellung weitere sechs Monate dauern wird. “

Product Owner - Der Eigentümer des Produkts ist dafür verantwortlich, den maximalen Wert des Produkts als Ergebnis der vom Entwicklungsteam durchgeführten Arbeit zu erreichen. Die einzige Person, die für die Produktentwicklung verantwortlich ist

Alle unsere Arrangements in einer kurzen Liste.

Schritt 1: Geschäftsanalyse und Anpassung der Methodik

Wir beginnen die Entwicklung eines Projekts mit einer Geschäftsanalyse: Sie müssen die Einzelheiten verstehen. In jedem Unternehmen gibt es immer viele Prozesse. Unsere Aufgabe in der Studie ist es, herauszufinden, wie die Teilnehmer des Systems miteinander interagieren, bevor Sie das System erstellen.

Nach einer Runde problematischer Interviews und der Verarbeitung der erhaltenen Informationen erhielten wir eine Beschreibung des Themenbereichs in Form von Anwendungsbeispielen.



Obwohl für SCRUM keine Entwicklungsspezifikation erforderlich ist, war die Tatsache, dass wir eine Beschreibung des Themenbereichs parat hatten, ein großes Plus. Dieses Dokument bildete die Grundlage für den Product Backlog - die Basis für die Einführung von SCRUM. Product Backlog - eine Liste von Anforderungen, Storys und Funktionen, die nach Wichtigkeit geordnet sind. Mit einer solchen Liste beginnt alles. Darüber hinaus werden alle Anforderungen in einer für den Kunden verständlichen Sprache beschrieben. Elemente dieser Liste sind User Story , "User Stories".

User Story ist eine Beschreibung der einfachsten Benutzerszenarien für die Verwendung des Systems, deren Kern wie folgt formuliert werden kann: "Wer, was, wofür, was sind die Funktionen und Einschränkungen."









Unser Produktbestand von 203 Storys, bequem nach Segmenten gruppiert


Beispiel für eine User Story

Was sind unsere Schlussfolgerungen nach dieser Phase?

1. Unsere Sprints dauern 2 Wochen. Warum ? Kurze Sprints sind angenehm. Sie ermöglichen es dem Team, so „flexibel“ wie möglich zu sein: bereit, ihre Pläne häufig anzupassen. Ein kurzer Sprint bedeutet eine kurze Rückkopplungsschleife, die zu häufigen Freisetzungen führt. Häufige Veröffentlichungen = schnelle Kundenbewertungen = weniger Zeit, um in die falsche Richtung zu arbeiten = schnelles Training, Verbesserung usw.
2. Lange Sprints haben ihre Vorteile - weniger Overhead wie Sprintplanung, Demos usw. Wir haben uns jedoch für kurze entschieden, um flexibel zu sein und weniger Risiken einzugehen.

Sprint - der Zeitraum, in dem "Ready" erstellt wird, dh ein Produkt, das zur Verwendung und Freigabe geeignet ist

Schritt 2: Sprintplanung. Wie wir die Sprint-Planung angepasst haben

Unser erster Geschäftswert war ein elektronisches Magazin. Für die meisten erfahrenen Entwickler wird dies utopisch erscheinen: Wir haben ein leeres Blatt, es gibt kein einziges Verzeichnis, keine einzige Benutzeroberfläche, kein einziges Autorisierungssystem oder keine einzige Geschäftseinheit, und wir sind bestrebt, eine der komplexesten Funktionen des Systems bereitzustellen.



Wie war das? Für uns war es notwendig, zwei Dinge zu erreichen: das erklärte Ziel des Sprints und den genehmigten Sprint-Rückstand.

Unser Product Owner begann immer mit der Sprintplanung mit einer Beschreibung dessen, was zuerst getan werden muss, den wichtigsten Geschichten. Danach bewertete das Team die Arbeitskosten für alle User Stories, beginnend mit der wichtigsten. Dabei hatte das Team viele Fragen, wie dies funktionieren sollte.

Die Sprintplanung ist eine sehr wichtige SCRUM-Aktivität. Jeder ist sich der Verantwortung für eine korrekte Beurteilung bewusst, weil:

• Auf diese Weise kann das Unternehmen verstehen, welche Funktionen es am Ende des Sprints erwarten kann. Seien wir ein vorhersehbares Team und mit dem Kunden „auf der gleichen Seite“
• Der Wert einer realisierten halben Geschichte ist Null, daher müssen alle im Rahmen eines Sprints geplanten Geschichten entschieden werden.
• Jede Änderung der Punktzahl während des Sprints wird ignoriert.

Der Zweck des Sprints ist, wofür der Sprint ist. Am wichtigsten ist, dass das Ziel nicht geschäftlich, sondern geschäftlich angegeben wird. Das heißt, in einer Sprache, die auch für Personen außerhalb des Teams verständlich ist, und das Sprint-Backlog ist eine Auswahl von Geschichten aus dem Produkt-Backlog . Es ist eine Liste von Geschichten, die das Team zu diesem Zeitpunkt als die wichtigsten identifiziert und während des Sprints abgeschlossen hat.


Beispiel für ein Sprint-Backlog

E-Magazin nach dem ersten Sprint

Vereinfachungen und Annahmen für den ersten Sprint . Im System - 2 Benutzer: Lehrer und Eltern; eine Klasse - 5 "A"; die tatsächliche Zusammensetzung der Klasse, die manuell direkt über SQL-Abfragen eingegeben wird; der aktuelle Zeitplan für 5 "A", ebenfalls direkt durch den Eintrag in der Tabelle gebildet.

User Story Nr. 1 : Der Lehrer meldet sich beim System an und gibt Bewertungen für jedes Fach aus dem Stundenplan des Tages. Ein System mit einer einfachen, aber bereits funktionierenden Funktion. Bereits bei der Sprint-Demo sagte der Lehrer, was bequem zu verwenden ist und was nicht, damit das Team in den nächsten Sprints die Korrekturen planen und ein aktualisiertes Tool bereitstellen kann.

Was der reale Wert ergibt: digitalisierte Leistung der realen Klasse, aktuelle Bewertungen, die Aussicht auf die automatische Erstellung von Monats-, Semester- und Quartalsberichten.

User Story # 2 : Ein wöchentlicher Bericht an die Eltern über die Leistung in der Mail.

Welchen Mehrwert bietet es: Eltern über die aktuelle Leistung zu informieren; Lehrerkommentare zu Hausaufgaben; minimale aber echte Analyse.

Nach mehreren Sprints entschied ich, dass es genügend Funktionen für Lehrer gab, um mit einem elektronischen Tagebuch zu arbeiten. Aus diesem Grund haben wir die Entwicklung dieses Tools unterbrochen und den Fokus auf den Zeitplan-Designer verlagert. Dies ist normal für SCRUM. Nach einem Dutzend Sprints kehrte ich zum elektronischen Magazin zurück und konzentrierte mich auf die Entwicklung. Nachdem wir die vereinfachte Funktionalität teilweise verworfen hatten, brachten wir das elektronische Journal in den Zustand, der für die Analyse der Jahresleistung erforderlich war. Wir brauchten diese Funktionalität zu dieser Zeit. Wir haben genügend Wert gewonnen und die aktive Entwicklung auf Teile des Systems mit höherer Priorität umgestellt.

Svyatoslav, Produktbesitzer

Als Referenz : Um die endgültige (ideale) Version zu korrigieren, mussten wir für mehrere Sprints zum elektronischen Journal zurückkehren.


So sah das Magazin nach dem ersten Sprint aus, aber es war bereits möglich, damit zu arbeiten.


Diese Version des elektronischen Magazins wurde nach 12 Sprints erhalten und konnte den Eltern gezeigt werden.

Ein weiteres anschauliches Beispiel für einen iterativen SCRUM-Ansatz ist der Zeitplankonstruktor.

Der Kunde erhielt den ersten Schedule Designer 2 Monate nach Projektbeginn. Es war ein "brutaler Editor" für einen sehr fortgeschrittenen Benutzer. Aber er erlaubte uns, einen Zeitplan für alle fünften Klassen einzuführen und das System nach einem echten Live-Zeitplan zu testen.

Es dauerte drei Sprints, um es zum „visuellen Editor“ zu verfeinern. Der Entwicklungsschwerpunkt wurde mehrmals gewechselt, aber zu Beginn des Schuljahres erhielt der Kunde einen voll funktionsfähigen Stundenplaner, mit dessen Hilfe er den Stundenplan von der ersten Klasse (A, B, C, D) bis zur achten Klasse in nur einer Stunde einführte.

Folgen wir der Route "brutaler Editor für einen echten Administrator" - "visueller Editor" - "Planungsdesigner"

Und wie haben Sie den Zeitplan zuvor erstellt?

Der Zeitplan wurde manuell auf geklebte Blätter aus Whatman A1-Papier erstellt: bemalt, mit farbigen Markierungen hervorgehoben, geklebt. Der Schulleiter brauchte Wochen und Monate, um dies zu tun.


Die allererste Version des Editors: „Brutaler Editor für den Administrator“ - der den Zeitplan für 2018 festlegte


Die zweite, verbesserte Version, mit deren Hilfe der Zeitplan 2018/2019 erstellt wurde


Schedule Designer - Endgültige Version

Was sind unsere Schlussfolgerungen nach dieser Phase?

1. Jeder Sprint muss ein klar definiertes Ziel haben.
2. Es ist normal, die Funktionalität zu vereinfachen und dann weiterzuentwickeln. Warum SCRUM so gut ist: Es gibt keinen richtigen Weg in der Produktentwicklung. Dies ist kein Tutorial mit Aufgaben und richtigen Antworten am Ende. Sie können immer viele alternative Optionen in Betracht ziehen und diese in verschiedenen Sequenzen ausführen. Wenn der Kunde am Ende des Sprints einen vollständigen Wert erhält, mit dem er arbeiten, testen und neue Daten eingeben kann, und dies zur globalen Endaufgabe führt, ist dies der richtige Weg.
3. Die Hauptphilosophie von SCRUM: Nicht zu Beginn einen schönen Code zu verfolgen, sondern sich darauf zu konzentrieren, dem Kunden ein funktionierendes Werkzeug zu geben. Daher können Sie sich im Laufe der Arbeit mit Fehlern abfinden, aber Sie müssen verstehen: Der beste Weg, diese Fehler zu identifizieren, besteht darin, nicht mehr über den idealen Code auf der Ebene von Architektur und Design nachzudenken und dem Unternehmen zunächst einen funktionierenden Prototyp zu geben.
4. Während der Diskussion ist es wichtig, Änderungen an der User Story vorzunehmen und alle Artefakte zu speichern und an die Karten anzuhängen.

Wie man ein Team dazu bringt, User Story realistisch zu bewerten

Das Team wird die User Story immer angemessen bewerten, wenn die Bedingungen erfüllt sind: Das Verhalten des realen Benutzers wird detailliert beschrieben, die Nutzungsgrenzen und Annahmen werden angegeben, Akzeptanzkriterien werden aufgelistet. Das heißt, das Team versteht, was zu tun ist, und schlägt grob das Wie vor.

Warum es wichtig ist, „Akzeptanzkriterien“ und „Nutzungsgrenzen“ zu formulieren - dies gibt das gleiche Verständnis für den Arbeitsumfang von Geschichten sowohl des Produktbesitzers als auch des Teams.

Bewertungsskala oder SCRUM-Poker

In SCRUM erfolgt die Auswertung der Story nicht in Stunden oder Tagen, sondern in Story-Punkten. Dies ist eine Mischung aus Komplexität, Risiko und Aufwand, die ein Team aufwenden muss, um eine Geschichte fertigzustellen. Für jedes Team ist 1 Story Point ein individueller empirischer Wert, aber jedes Teammitglied spürt ihn.

Beachten Sie, dass die Reihenfolge der Werte auf den Karten nicht linear ist. Zum Beispiel gibt es nichts zwischen 13 und 21. Warum so?



Erstens ist dies erforderlich, um das Auftreten eines falschen Genauigkeitsgefühls bei großen Bewertungen zu vermeiden. Wenn die Geschichte auf ungefähr 17 Punkte geschätzt wird, macht es keinen Sinn zu diskutieren, ob es 15, 18 oder 21 sein soll. Alles, was wir wissen müssen, ist Geschichte, es ist schwer zu bewerten. Deshalb vergeben wir ihr eine Bewertung von 21. Ungefähr.

Zweitens neigen die Menschen dazu, ihre Fähigkeiten zu übertreiben, und die Skala lässt nicht zu, dass bei der Bewertung von Zeit und Ressourcen viel falsch ist. Zum Beispiel stimmte das Team zu, dass 6 Story Points für eine der Aufgaben ausreichen. Wenn Sie jedoch nicht sicher sind, ob 5 ausreicht, wählen Sie besser 8. Auf diese Weise können Sie echte Bedingungen festlegen, in die das Team genau passt. Außerdem hilft es, einen Dialog zwischen den Teilnehmern zu beginnen, Ihre Vision der Story- Implementierung zu teilen, die Risiken auszusprechen und zu einem Konsens zu gelangen.

Sehr wichtig : Jedes Teammitglied sollte eine Bewertung abgeben. Warum?

• Für eine begründete Beurteilung muss jeder Teilnehmer genau verstehen, was das Wesentliche dieser Geschichte ist. Indem wir von jedem Mitglied des Teams eine Bewertung erhalten, stellen wir sicher, dass jeder weiß, worum es geht. Dies erhöht die Wahrscheinlichkeit der gegenseitigen Unterstützung während des Sprints. Und vor allem: Die wichtigsten Fragen zu dieser Geschichte werden so früh wie möglich gestellt.
• Eine umfassende Betrachtung des Problems führt zu einer breiten Palette von Bewertungen. Solche Meinungsverschiedenheiten lassen sich am besten so früh wie möglich erkennen und diskutieren. Nach Erörterung von Meinungsverschiedenheiten - Neubewertung, Abstimmung. In der Regel reichen ein paar Bewertungszyklen aus, um die wichtigsten Punkte zu klären und ein gemeinsames Verständnis zu schaffen.

Wir zeigen dies am Beispiel einer großen Variation in der Schätzung für eine der Geschichten. Die Geschichte hieß Buzz .

Wichtig : Während der Planung wissen wir normalerweise nicht, wer diesen oder jenen Teil ausführen wird. Die Implementierung der User Story erfordert die Teilnahme von Spezialisten für verschiedene Arten von Arbeiten: Architektur, Front-End, Back-End, Testen, Aufbereitung realer Daten. Unabhängig davon gibt es eine Gruppe von Arbeiten wie Design und Design von Benutzeroberflächen.

Heller Fall: Buzz

Im Schulverwaltungssystem treten viele Ereignisse von unterschiedlicher Bedeutung auf. Zum Beispiel erhielt ein Schüler eine Note; es ist ein Ersatz aufgetreten, und anstelle von Mathematik wird es Biologie mit einem anderen Lehrer geben; Es ist ein ärgerlicher Vorfall mit dem Schüler aufgetreten, und die Eltern sollten unverzüglich informiert werden. Der Lehrer schrieb einen wichtigen Kommentar zur DZ.

Es ist für Benutzer unpraktisch, diese Daten mit Standardmethoden an Instant Messenger oder per Post zu senden, und zwar gestern. Außerdem können sich Nachrichten auf mehrere Personen gleichzeitig beziehen: Der Lehrer muss dem Elternteil mitteilen, dass der Schüler die Schule während des Unterrichts verlassen hat. Im Originaldokument sind diese Regeln auf 10 Seiten zusammengefasst


Buzz in der endgültigen Implementierung

Heller Fall: Buzz

Wir diskutieren unter Entwicklern, wie viel wir den Arbeitsaufwand für die Geschichte von Buzz schätzen.



Jeder spricht aus, wie viele Story Points benötigt werden. Es stellte sich heraus, dass wir große Meinungsverschiedenheiten haben, und machte auf extreme Meinungen aufmerksam: Warum jemand mit 50 bewertet wurde und sein Kollege in 5 Story Points zuversichtlich ist. So entdeckten wir sofort unentdeckte Anforderungen, die von einem vorsichtigen Entwickler bemerkt wurden. Darüber hinaus wurden globale Aufgaben im Zusammenhang mit der Personalisierung aufgedeckt. Dies ist ein großartiges Beispiel dafür, wie ein Team Schwierigkeiten antizipieren kann.

Welche Schlussfolgerungen haben wir hinsichtlich der Bewertungsmethode gezogen?

1. Ja, es ist normal, dass QA- und UX-Designer eine Bewertung der technischen Historie abgeben.
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

Das tägliche SCRUM-Meeting oder Stand-up und das gesamte SCRUM sind eine Geschichte über effektive Kommunikation, die dazu beiträgt, Zeit und Mühe des Teams zu sparen. Dies sind nicht nur „Besprechungen“ und „Gespräche“. Sie nehmen keine Zeit in Anspruch, die für die Arbeit aufgewendet werden könnte, sondern helfen, die Anstrengungen zu optimieren. Eines der Prinzipien von SCRUM lautet: „Menschen und Interaktion sind wichtiger als Prozesse und Werkzeuge.“



Jedes Teammitglied berichtet anhand einer speziell erstellten Checkliste kurz, was es getan hat, mit welchen Problemen er konfrontiert war und was es als Nächstes tun wird. Eine Person wird nicht mit einem Problem allein gelassen, sondern es wird ihnen schnell geholfen, es auf die effektivste Weise zu lösen. Ein Ingenieur verbringt also keine Zeit mit erfolglosen Versuchen. Danach müssen Sie ihn möglicherweise von Grund auf neu erstellen, um die Ressourcen des gesamten Teams zu schonen.

Funktionsübergreifend: Das Team ist bereit, alle Aufgaben der Produkteinführung auszuführen.

Bei der Bildung des Teams haben wir T-Spezialisten ausgewählt, die sich in vielen Bereichen auskennen und von denen mindestens einer ein Experte ist. Dank dieser Vielseitigkeit kennen alle Ingenieure das System sehr gut.

Die Erfahrung eines jeden ist wertvoll, um die effektivste Lösung zu finden.

In einem Team verfügt eine Person möglicherweise nicht über die für eine bestimmte Aufgabe erforderliche Erfahrung, hat jedoch mit hoher Wahrscheinlichkeit ihre Kollegen. Das Gleiche seitens des Kunden: Eine Person kennt möglicherweise einige Details nicht, eine andere Person kennt sie jedoch.

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. Es ist notwendig, den Schwerpunkt zu verschieben und zu verstehen, dass ein tägliches SCRUM für die Kommunikation und nicht für die Verwaltung erforderlich ist.
3. Jeder nachfolgende Sprint sollte die Erfahrungen der vorherigen berücksichtigen.

So führen Sie ein tägliches SCRUM-Meeting durch

Schritt 4: Wie wir eine Demonstration der Ergebnisse durchgeführt haben. Unsere Anpassung der Sprint-Demo

Entwickler demonstrieren abwechselnd neue Funktionen live anhand realer Daten. Der Fokus liegt auf dem, was wir getan haben und nicht darauf, wie wir es getan haben. Im Allgemeinen sind wir ständig bemüht, unsere Demo geschäftsorientiert zu gestalten, ohne die technischen Details zu erwähnen.

So finden Sie heraus, ob eine Lösung zum Kunden passt

Hier kommt wieder in den Vordergrund , den Zweck des Sprints . Unsere Demos wurden oft von speziell eingeladenen Lehrern und Schulleitern besucht, die nicht planten. Sie wussten nur allgemein über das Produkt Bescheid. Wir haben es immer begrüßt, dass die Kunden nach jeder Demonstration selbst versucht haben, etwas im System zu tun. Anschließend überprüft der Endbenutzer jeden Punkt des Akzeptanzkriteriums. Er sagt, was passt und was nicht, welche Aspekte können verbessert werden. Und so - für jede User Story, die für diesen Sprint geplant war.





Welche Schlussfolgerungen haben wir aus der Methodik zur Demonstration der Ergebnisse gezogen?

1. Obligatorische Zusammensetzung für die Demo: Product Owner, Scrum Master, Kundenvertreter und Endbenutzer, die mit dem Tool arbeiten, Team.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

Retrospektive ist für uns ein wichtiges Ereignis direkt nach der Sprint-Demo. Rückblicke sind nützlich, besonders wenn etwas schief geht. Ohne Rückblicke kann sich herausstellen, dass das Team immer wieder auf denselben Rechen tritt.



So versichern Sie sich gegen wiederholte Fehler

Der häufigste Rechen ist, wenn sich die tatsächliche Teamleistung stark von der vorhergesagten unterscheidet. Die tatsächliche Leistung wird basierend auf einer ersten Bewertung jeder Geschichte berechnet. Und wenn wir mitten im Sprint verstehen, dass die Geschichte, die auf 5 Story-Punkte geschätzt wird, so viel erledigt wird, wie die Aufgabe normalerweise 13 Story-Punkte benötigt und bei weitem nicht abgeschlossen ist, und wenn es sich auch um eine blockierende Story handelt, können andere nicht gestartet werden, weil Unbereitschaft problematisch. Wenn Sprintziele auf dem Spiel stehen, ist eine Rückschau unvermeidlich.

Unsere Rückblicke haben eine absolut klare Struktur und Ziele: Das Team kommt zusammen. Scrum Master liest den Sprint-Rückstand und bittet jedes Mitglied des Teams, die Ergebnisse des Sprints aus seiner Sicht zu sprechen und zu bewerten. Jedes Mitglied des Teams äußert seine Meinung, dass es möglich war, gut zu machen, was schief gelaufen ist und - was am wichtigsten ist - warum. Was soll ich weiter tun und was soll ich ablehnen? Niemand unterbricht ihn jedoch. Er platziert seine Schlussfolgerungen auf dem Aufkleber in einer der Spalten:

• okay
• könnte besser sein
• müssen reparieren

Ein Beispiel für unsere Verbesserungen anhand einer Retrospektive

• Wenn ein Entwickler ein Front-End erstellt und wir mit der Implementierung beginnen, müssen die Designer zu 100% erreichbar sein.
• Besprechen Sie mit PO die Einbeziehung methodischer Stunden.
• In der Ergonomie ist es wichtig, die bestmögliche Dokumentation zu erhalten.
• Technische Schulden sollten nicht akkumuliert werden. Richten Sie 10% für technische Geschichten mit PO aus.
• Es sollte einen Spezialisten geben, der technische Probleme löst, sobald sie auftreten.
• Vor jeder Sprintplanung muss unbedingt eine Sprintpflege durchgeführt werden.

„Nach dem Brainstorming des Teams über alle problematischen Aufkleber werde ich eine„ Punktabstimmung “durchführen: Jedes Mitglied des Teams hat drei Stimmen (drei Markierungspunkte auf den Aufklebern). Er kann alle seine Stimmen auf einmal für ein Problem abgeben oder anders verteilen. Basierend auf dieser Teamabstimmung wählen wir 2-3 Verbesserungen aus, auf die wir uns im nächsten Sprint konzentrieren. Und zu Beginn der nächsten Retrospektive werden wir überprüfen, was passiert ist. Sozusagen "Hausaufgaben überprüfen" :) "

Pavel Kamyshov , agiler Trainer

Ja, SCRUM erfordert die aktive Einbeziehung aller Teammitglieder. Für Aktivitäten wie Pflege, Planung und tägliches SCRUM haben wir ungefähr 12% der bezahlten Zeit benötigt - dies ist eine Art Preis für Transparenz, Vorhersehbarkeit und Risikominderung.

Eine Woche Arbeit kann eine Stunde Planung sparen.

Pavel Kamyshov , Agiler Trainer von Scrum Ukraine

12% sind viel, aber es lohnt sich, da im klassischen „Wasserfall“ der Preis für die Verwendung der Methodik für den Projektmanager eine separate Rolle spielt. In unserem Marktsegment werden durchschnittlich 15% der Entwicklungskosten für das Management aufgewendet.

Welche Schlussfolgerungen haben wir aus der retrospektiven Methodik gezogen?

1. Für uns ist die Retrospektive nach der Sprintplanung das zweitwichtigste Ereignis in SCRUM.
2. Jedes Teammitglied spricht so, dass sich alle im selben Infofeld befinden.
3. Jede Änderung hat einen Preis. Sie müssen mit PO einverstanden sein, um technische Geschichten und methodische Stunden in den Sprint-Rückstand aufzunehmen.
4. Methodische Stunden werden vom Kunden bezahlt.

Die Sprint-Retrospektive bietet einem Team die Möglichkeit, eine auf sich selbst gerichtete Inspektion durchzuführen und einen Plan zur Verbesserung der Teamarbeit im nächsten Sprint zu erstellen.

Schritt Nummer 6: Wie wir die Verfeinerung des Product Backlogs oder Grooming angepasst haben

Viele Kollegen, die mit den Besonderheiten der IT vertraut sind, bezweifeln, dass es einem Team bei der Sprintplanung so klar sein kann, dass es bereit ist, alle User Stories zu bewerten.



Ja, in der Tat wird ohne die Vorbereitung einer solchen Kohärenz nicht funktionieren. Damit dies so funktioniert, gibt es eine spezielle SCRUM-Aktivität: die Verfeinerung des Produktrückstands. Um dies auszuführen, müssen Sie den Product Owner bitten, einen Planungshorizont anzugeben: Umreißen Sie, welche Storys Kandidaten für den nächsten Sprint sein können. Wenn es unter ihnen Geschichten gibt, die ein gründliches Studium oder spezielle Kompetenzen erfordern, über die das Team nicht verfügt, wird ein Meeting einberufen - Pflege / Vorplanung.


Pflegeergebnisse

Unser Product Owner war sehr kompetent, so dass wir immer einen ausreichenden Einblick in die Entwicklung des Systems hatten und regelmäßig Verbesserungen vornahmen. Transparenz ist in der Tat eines der Grundprinzipien von SCRUM.


Es sieht aus wie ein Pflegeplan

Welche Schlussfolgerungen haben wir zur Verfeinerungsmethode gezogen?

1. Dies ist ein wichtiges Ereignis, mit dem wir klären können, was wir nicht wissen und welche Kompetenzen uns fehlen. Sobald entschieden wurde, einen externen Entwickler-Berater für bestimmte Themen zu gewinnen, deren Lösung wir zu diesem Zeitpunkt noch nicht hatten.
2. Diese Diskussionen waren bei uns sehr effektiv, wir haben viele Alternativen und Optionen in Betracht gezogen, die es uns ermöglichten, das Problem im Auge zu behalten, und für die Sprintplanung wurde die komplizierteste Geschichte bereits „angelegt“.
3. Komplexe, scheinbar unlösbare Probleme finden klare Lösungen. Manchmal reicht es aus, nur eine Bibliothek zu kaufen, als selbst eine komplexe Site zu entwickeln.

Die Verfeinerung ist die Grundlage für die Bereitschaft, die Komplexität von Storys unter verschiedenen Implementierungsbedingungen während der Sprintplanung zu bewerten, da wir deren Umfang und Komplexität verstehen müssen.

Schlägt fehl

Ja, wir sind ehrlich gesagt sehr zufrieden mit der Entwicklung der SCRUM-Methodik, aber dies bedeutet nicht, dass alles reibungslos verlief. Hier sind drei Punkte, an denen wir Strohhalme legen würden, wenn wir im Voraus wüssten, dass es so weitergehen würde.

Arbeiten Sie an bekannten Mustern

In einer der Retrospektiven haben wir den Grund für die abnormale Abweichung der "realen Produktivität" des Teams in allen Geschichten, an denen Designer beteiligt waren, detailliert analysiert. Die tatsächliche Leistung wird normalerweise anhand der Formel berechnet: projizierte Leistung / tatsächliche Leistung.

Wir fanden aus Gewohnheit heraus, dass sie sich in dem bekannten sequentiellen Wasserfall organisierten.

Infolgedessen: Die Aufgaben wurden nacheinander ausgeführt, und die Entwickler verbrachten Zeit mit dem sequentiellen Einschalten in verschiedenen Phasen mit Verzögerungen, die durch die Notwendigkeit verursacht wurden, die bereits gestarteten Aufgaben zu erledigen.

Fazit: Vielleicht die schmerzhafteste Geschichte für uns, die am meisten Schaden angerichtet hat und nicht sofort enthüllt wurde. Es muss regelmäßig überprüft werden, ob alle Teammitglieder nach neuen Standards zur Arbeit gewechselt sind.

Zusätzliche Arbeit an unnötigen Funktionen

Beim zweiten Sprint erlag der Produktbesitzer der Meinung eines der Schulleiter, der der Ansicht war, dass das „Kuratorenjournal“ eine äußerst wichtige Funktion sei. Wir haben diese Geschichte im Sprint aufgenommen und uns die Mühe gemacht.

Warum ein Fehler: Dieses Tool konnte erst in späteren Phasen getestet werden, da es akkumulierte Daten benötigte, die zu diesem Zeitpunkt nicht vorhanden waren.

Als Ergebnis: Es wurde nicht getestet, nicht verwendet, nicht entwickelt. Die notwendigen Funktionen wurden anders und überhaupt nicht so gelöst, wie es der Schulleiter dachte, durch völlig andere Werkzeuge. Fazit: Nehmen Sie nur das in Arbeit, was Sie sofort verwenden werden.

Gleich fortgeschrittenen Benutzern

Irgendwann haben wir die Geschichte mit dem „Ersatzeditor“ in die Entwicklung aufgenommen, an deren Entwicklung ein Lehrer, ein sehr erfahrener Computerbenutzer, beteiligt war. Als Ergebnis haben wir ein großartiges Werkzeug bekommen, aber es konnte nicht von gewöhnlichen Schullehrern verwendet werden, die nicht so fortgeschritten waren.

Fazit: Bestätigen Sie die Geschichte bei Stammkunden.

Allgemeine Schlussfolgerungen

Schlussfolgerung Nummer 1

Pro Flexibilität: Mit SCRUM können Sie ein effektives Team sein

Die Ergebnisse jedes Sprints hängen von den Einführungsaufgaben, der Effizienz, der Koordination, der Teamverantwortung und dem Qualitätsfeedback ab.

Die Eingabe erfolgt durch den Product Owner. Er ist auch verantwortlich für den Kontext, in dem die Funktionalität genutzt wird, die Qualität der Anforderungsformulierung sorgt für eine ausreichende Detailtiefe.

SCRUM verlangt vom Team, dass es eine vollständig greifbare Arbeit erledigt, die es ihm ermöglicht, einen Mehrwert zu erzielen, dh ein Werkzeug, das dem Benutzer am Ende jeder Iteration zur Verfügung gestellt werden kann. Dies hilft, die Lösung bei der Arbeit zu sehen und in der Anfangsphase zu verstehen, was geändert werden muss, um fortzufahren.

Schlussfolgerung Nummer 2

Über den effizientesten Einsatz von Ressourcen

SCRUM - eine Form der Arbeitsorganisation, die für den Kunden und den Auftragnehmer von Vorteil ist. Was?
Wenn Sie bereits in einem frühen Stadium mit Iterationen arbeiten, können Sie verstehen, was falsch läuft, was bedeutet, dass Sie rechtzeitig Anpassungen vornehmen müssen. Die Vorbereitung für jeden Sprint und die Besonderheiten seiner Organisation helfen jedes Mal, nur das zu tun, was der Kunde braucht, und nicht beiseite zu gehen. Und es gibt enorme EFFIZIENZ der verbrauchten Ressourcen, Zeit und Anstrengungen.
In der Anfangsphase erhält der Kunde einen Arbeitsbereich des Systems: Nach den ersten Sprints nimmt er die von ihm geleistete Funktionalität in die Arbeit auf und testet sie in der Praxis.

SCRUM - wenn beide Parteien gegen Risiken versichert sind

Sehen Sie, wie die Verantwortung zwischen dem Kunden und dem Auftragnehmer aufgeteilt wird
Die Barrikade verschwindet, auf beiden Seiten befinden sich der Auftragnehmer und der Kunde im klassischen Projektmanagement. Grundsätzlich verschwinden die Kunden- und Auftragnehmerpositionen, das Team bleibt. Und es gibt keine Bedingungen für eine mögliche Konfrontation.

KUNDE

Der Kunde zahlt nur, wenn alle Sprintziele erreicht wurden. Wenn kein Tool entwickelt wurde, das der Kunde morgen in der Praxis ausführen kann, zählt der Sprint nicht.

Der Kunde zahlt für jeden Sprint einen festen Betrag und macht sein Geschäft einen Schritt effizienter

Darsteller

Der Auftragnehmer ist daran interessiert, bei jedem Sprint ein neues Werkzeug vorzubereiten, einen neuen Wert für den Kunden, da dies eine neue Runde von Rückmeldungen und Informationen / Erfahrungen bietet. Welches für die weitere Produktentwicklung verwendet werden kann.

Jeder Sprint erhöht das Kompetenzniveau des Darstellers und beschleunigt es bei der Umsetzung des Projekts.

Insgesamt haben wir in nur 7 Monaten ein System entwickelt, das funktioniert und für den Kunden völlig zufriedenstellend ist, das von ihm in der Praxis getestet wurde und alle Wünsche widerspiegelte, und kein System herausgegeben, das theoretisch nach dem TOR entworfen wurde und das noch einige Monate fertiggestellt werden müsste, da die Praxis zwangsläufig ihre eigenen Korrekturen vornehmen würde.

In diesem Fall handelt es sich weltweit um eine korrekt ausgewählte Projektmanagementtechnik unter Bedingungen hoher Unsicherheit und einer begrenzten Zeit vor dem Start.

Bei einem so anspruchsvollen Kunden mit hohen Qualitätsstandards war es für uns manchmal sehr schwierig, aber gleichzeitig sehr interessant. Diese Herausforderungen, die wir gemeistert haben, die Fehler, die wir rechtzeitig gemacht haben, bewusst und korrigiert, die Schlussfolgerungen, die wir gemacht haben, haben die Kultur in unserem Team für immer verändert

Wahrscheinlich war lange Zeit jeder daran interessiert, etwas über das Produkt selbst zu erfahren, was sich herausstellte.

Der Kunde erhielt ein ausgezeichnetes Produkt: eine Reihe von Werkzeugen für eine moderne Schule, die sie schnell in eine Schule der Zukunft verwandeln können