Sprint Puls: Aufbau einer effektiven Arbeit in einem großen Team

Der Sprint-Impuls ist ein zusätzliches Werkzeug, mit dem der Scrum-Befehl den Prozess innerhalb des Sprints organisieren kann. Es hilft, Teamwork aufzubauen und spart Zeit für das Eintauchen neuer Spezialisten. Wie man es anwendet, sagt Eisenprojektleiterin Alyona Shester. Als Bonus finden Sie am Ende des Artikels eine Vorlage für die erste Montage.



Einmal haben wir ein wenig über dieses Tool gesprochen. Seit dem Schreiben des vorherigen Artikels hat er uns viele Male gerettet, deshalb haben wir beschlossen, das Thema ausführlicher zu behandeln.

Sprint Puls und Sprint: Was ist der Unterschied

Die Namen sind ähnlich, aber das Wesentliche ist anders:

• Sprint ist ein Zeitraum, in dem das Scrum-Team einen Teil des Produkts erstellt, der dem Kunden gezeigt werden kann und der ihm nützlich sein wird. Sprint besteht aus fünf Veranstaltungen: Planung, tägliches Scrum, Entwicklung, Sprint-Demo und Retrospektive.
• Sprint-Puls ist ein Werkzeug, mit dem Sie während des Sprints eine effektive Arbeit im Team aufbauen können.

Sprint-Ereignisse bleiben unverändert, und der Sprint-Impuls ist ein Teil, der für ein bestimmtes Projekt angepasst werden kann.

Nutzungsbedingungen

Ein Artefakt ist ein Objekt, das während der Bearbeitung eines Projekts erstellt wird (z. B. Protokoll, Layout, Rückstand usw.).
Zuwachs - Produktwachstum (zum Beispiel das Erscheinen neuer Funktionen oder deren Aktualisierung).
Blocker ist eine Situation, die die Arbeit stört und blockiert.
Meilensteine sind wichtige Phasen des Projekts.

Sprint Puls in Aktion

Das Hauptziel unseres Projekts, das wir als Beispiel genommen haben, war es, eine mobile Anwendung von Grund auf neu zu erstellen. Die Arbeit war in mehrere Phasen unterteilt. Der erste Produktionsschritt war die Erstellung eines Service-Designs. Und als erstes wichtiges Artefakt - die Erstellung von Bildschirmlayouts (Wireframes) für Anwendungsskripte mit hoher Priorität. Diese Skripte waren Teil des Produkts MVP.

Das Start-up-Team bestand aus 6 Personen: einem Product Owner von Kundenseite, einem Projektmanager, einem UX-Researcher, einem Art Director und zwei Designern. Jede für die Bereitstellung neuer Layouts erforderliche Iteration ist ein Indikator dafür, dass sich das Projekt im richtigen Tempo bewegt. Eine Iteration - eine Woche. Scrum war großartig für diese Aufgabe. Nachdem wir uns auf die Tage zu Beginn und am Ende des Sprints sowie auf die Tage und die Zusammensetzung der Teilnehmer an den Sprintveranstaltungen geeinigt hatten, begannen wir mit der Arbeit.

Die nächste Schlüsselaufgabe war die Entwicklung eines Designkonzepts. Danach erwartete uns die Entwicklung. Parallel zu dieser Aufgabe schlossen wir einen Analysten, Architekten, Entwickler und Tester an, um alles vorzubereiten, was für einen vollständigen Start erforderlich ist: Die Anwendungsarchitektur zu überdenken und festzulegen, CI (kontinuierliche Integration) zu konfigurieren und vor allem die Interaktion im Inneren zu vereinbaren vereintes Team.

In diesem Moment wurde uns klar, dass wir eine Lösung finden müssen, die sich mit Design und Entwicklung „anfreundet“, das Arbeitstempo beibehält und systematisch ein Inkrement erzielt.

Bei der Analyse der anstehenden Arbeiten haben wir festgestellt, dass wir nicht nur Scrum-Events benötigen, um effizient zu starten. Wir standen einer Vielzahl von Aktivitäten gegenüber: Analyse und Vorbereitung der primären Geschäftsanforderungen, Szenariodesign, Erstellung von Layouts, Vorbereitung der funktionalen Anforderungen, API-Design, Entwicklung und Testen. Aus diesem Grund gab es (bei der Planung eines Sprints) eine hohe Wahrscheinlichkeit, im Sprint selbst zu verpassen, was, wen und wann Sie möglicherweise während der Arbeit benötigen.

Wenn Sie nur Standard-Scrum-Tools verwenden, können Sie außerdem auf das Problem der Planung von langen Sprints zu Sprints stoßen. Jedes Mal mussten wir mit den Unterbefehlen verhandeln, wann und was gesehen und geschätzt werden kann.

Mit Hilfe der Scrum-Tools wird es auch nicht möglich sein, die Zeit der Spezialisten effektiv zu verteilen. Im Zusammenhang mit einem großen Projekt würde dies zu Blockern führen: Ein Artefakt zum Starten der Arbeit der nächsten Stufe wäre nicht bereit. Beispiel: Damit die Entwickler der Serverseite mit dem Erstellen der API beginnen können, müssen sie wissen, welche Funktionen die Designer entwerfen möchten. Wenn Sie die Zeit für Spezialisten nicht optimal einteilen, besteht die Gefahr, dass die Arbeit nicht rechtzeitig erledigt wird.

Wir haben versucht, im Sprint einen „Bach“ zu bauen. Die Hauptaufgabe besteht darin, den Arbeitsprozess für jedes Mitglied des Unterbefehls verständlich zu machen und Ausfallzeiten zu minimieren. Jeder sollte seinen Verantwortungsbereich und die Momente verstehen, in denen und was bereitgestellt werden muss.

Parallel zur Entwicklung haben wir begonnen, einen Sprintpuls zu sammeln. Wir begannen mit Gesprächen mit führenden Experten in jedem Bereich und mit dem Product Owner seitens des Kunden. Wir haben die Hauptarbeitsschritte festgelegt und festgelegt, was jeder Unterbefehl benötigt, um seinen Teil des Prozesses zu starten. Beispielsweise bilden die funktionalen Anforderungen des Analysten die Basis für die Entwickler. Wenn es zu einer Verzögerung kommt, wird das gesamte Projekt pünktlich „ausgezogen“.

Darüber hinaus sprachen wir mit dem Kunden über wichtige Punkte, die den Sprintpuls beeinflussen könnten. Ein solcher Punkt ist der Time-to-Market-Parameter (Time-to-Market) von 1 Monat und die Erhöhung (Erhöhung der Funktionalität) alle 2 Wochen.

Nachdem wir die Informationen gesammelt hatten, fanden wir die Abhängigkeiten und zeichneten sie auf: Was und was passiert, und auch - in welchem ​​Zeitraum sollte dies geschehen? All dies ist zu einem Workflow geworden.


Die ersten Skizzen

Bei der Erfassung eines Sprintimpulses ist es wichtig, die Momente zu minimieren, in denen es zu Ausfallzeiten kommen kann. In unserem Fall hat es sich beispielsweise gelohnt, dem Analysten mehr Zeit für die Beschreibung der API-Methoden zu lassen. Da auf der Grundlage dieser Informationen Anforderungen an das Front-End-Entwicklungsteam erstellt werden, war es erforderlich, auf eine Verlängerung der Laufzeit vorbereitet zu sein.


Die ersten Versionen der Verbindungsoptionen im Sprint waren in der physischen Version: Skizzen auf Papier, Aufkleber - alles ist in Kraft getreten!

Der letzte Schritt besteht darin, den Sprintimpuls in den Sprint selbst zu integrieren.


Überlegungen zum Aufteilen eines Instruments in Sprints

Wir haben es geschafft, die optimale Sprint-Puls-Variante für uns zu sammeln: Sie berücksichtigte alle Abhängigkeiten und Kontrollpunkte, um das Ergebnis einem anderen Team zur Verfügung zu stellen.

Sprint Puls von Aufklebern und Papierbögen, haben wir in Miro umgebaut. Sie können jedes andere Programm verwenden (und auf einem physischen Datenträger, falls dies zweckmäßig ist). Das Wichtigste ist, dass alle Teilnehmer des Sprints jederzeit auf das Diagramm zugreifen können - Zeit, Aufgaben und Beziehungen mit anderen Unterbefehlen synchronisieren.


Sprint Puls für unser Projekt

So bauen Sie einen Sprint-Puls auf

Um einen Sprint-Impuls für Ihr Team zu erzielen, müssen Sie 6 Fragen beantworten. Auf diese Weise können Sie Informationen sammeln, anhand derer Sie Abhängigkeiten und Blocker identifizieren können. Dann müssen sie für das Timing jedes Sprints ausgelegt werden.

1) Was und wer macht das?
Zu Beginn müssen Sie die Richtung der Arbeit bestimmen: Was tun wir, wer tut, was ist das Ziel, was zählen wir für das Ergebnis usw.

2) Was wird die Aktivität sein?
Wir finden alle Aktivitäten, die jeden Unterbefehl betreffen. Wir legen ihre Etappen vom Anfang bis zum Ende des Sprints fest.

3) Was sind die Meilensteine ​​des Sprints?
Definieren Sie Meilensteine ​​(Meilensteine) im Sprint jedes Unterbefehls. Sie zeigen den Abschluss einer Aufgabe im Sprint an.

4) Welche Verbindungen bestehen innerhalb des Teams?
Wir bestimmen den Zeitpunkt für die Herstellung aller „abhängigen“ Artefakte, die für die Arbeit anderer Teams benötigt werden (z. B. Modelle von Designern für Entwickler). Wir finden alle Abhängigkeiten. Dann verbinden wir sie und legen sie auf der Sprint-Timeline aus.

5) Wo kann es zu Ausfallzeiten kommen?
Wir identifizieren Ausfallzeiten - Momente, die sich auf die Geschwindigkeit und das Erreichen von Sprintzielen auswirken können. Wir finden auch Aufgaben, die von Unterbefehlen bei erzwungenen Ausfällen übernommen werden können. Für Spezialisten ist es jedoch nicht einfach, etwas zu tun. Diese Aufgaben sollen dem anderen Team helfen, in Zukunft effizienter zu arbeiten.

Zum Beispiel haben wir den ersten Tag des Sprints der Planung und Auswertung gewidmet. Für uns war ein solches Ereignis der „saubere Tag“ des Designteams, an dem die Layouts aufgeräumt und die Bildschirmkarte aktualisiert werden konnten.

6) Wann müssen Teams synchronisieren?
Hier müssen Sie verstehen, an welchen Kontrollpunkten der Befehl synchronisiert wird. Wir legen all diese Punkte fest: Welches Ergebnis, in welchem ​​Umfang und bis zu welchem ​​Datum soll es fertig sein? Dies ist für alle Unterbefehle erforderlich.

Damit die Designer nach Abschluss des Skriptentwurfs in Wireframes ein für die Entwickler realisierbares Ergebnis erzielen können, haben wir uns als ganzes Team versammelt, um die Entwicklungen vorzustellen und Feedback zu technischen Einschränkungen zu sammeln.

Es ist wichtig zu verstehen, dass der Sprintpuls für einige Zeit die Realität des Projekts beeinflusst. Trotzdem wird der Start immer noch schneller sein als ohne.

Mit dieser Vorlage können Sie einen Sprintimpuls für Ihr Team sammeln. Die wichtigsten Punkte sind hier angegeben, aber etwas kann und sollte an Ihr Projekt angepasst werden.



Sie können es sich hier genauer ansehen und herunterladen

Wann der Sprint-Impuls benötigt wird und wann nicht

Es gibt Fälle, in denen der Sprintpuls überflüssig ist, aber manchmal ist er einfach unersetzlich.
Dieses Schild ist ein Hinweis: Wenn die Anzahl "Ja" größer als "Nein" ist, sollten Sie dieses Werkzeug verwenden.


Sprint Pulse Mini-Test

Probleme, die ein Sprintpuls lösen kann

Es gibt verschiedene Situationen, mit denen wir mit dem Tool umgehen können. Dies ist genau unsere Erfahrung, und dies ist natürlich nicht die ganze Liste. Jeder Sprint-Puls-Benutzer kann seinen eigenen haben.

Langer Start des Projekts

Nach den Regeln von Scrum muss das Team selbst basierend auf seinen Aktivitäten im Sprint arbeiten. Das erste Problem ist jedoch, dass die Teammitglieder unterschiedliche Kommunikations- und Organisationsebenen haben. Zum anderen müssen Teams eine Reihe von Besprechungen abhalten und viel Zeit dafür aufwenden, um Kommunikation und Prozesse zu etablieren.

Lösung: Sprint Puls - ein Start-Kit, das die Arbeit beschleunigt. Nachdem Sie es vor Produktionsbeginn gebildet haben (bis zu dem Zeitpunkt, an dem die Teams Aufgaben erhalten), können Sie schnell und reibungslos loslegen.

Blocker im Prozess

Während der Arbeit konzentrieren sich die Spezialisten auf die Erfüllung ihrer Aufgaben. Sie sind sich möglicherweise der Risiken und Beziehungen zu anderen Fachleuten nicht bewusst. Ohne einen festen Plan im Sprint ist es für das Team schwierig, das ganze Bild zu sehen. Infolgedessen treten Blocker auf: Die folgenden Spezialisten in der Kette können nicht mit der Arbeit beginnen. Das Ergebnis dieses „Schneeballs“ ist das Nichterreichen der Sprintziele und im Extremfall das Scheitern des Projekts.

Beispiel: In einem anschaulichen Beispiel wird eine mobile Anwendung für eine Bank getestet. Wenn Sie keine Zeit zum Testen und Stabilisieren darauf verwenden, wird am Ende des Sprints eine Codebasis vorhanden sein, aber es bleibt keine Zeit mehr, nach Fehlern zu suchen. Und ohne dies kann der entwickelte Code nicht als "vollständiges Inkrement" bezeichnet werden. Es wird nicht möglich sein, ein solches Produkt den Kunden der Bank zu geben. Abgesehen von der Tatsache, dass es nicht funktioniert, kann dies zu Problemen für die Bank führen. Zum Beispiel kann es zu Datenverlust, Account-Hacking, Diebstahl von Geldern usw. kommen.

Lösung: Während der gesamten Arbeit sieht das Team einen einzelnen Sprintimpuls. Jeder weiß, wer und was an einem bestimmten Tag des Sprints von ihm erwartet, und baut seine Arbeit auf diesen Abhängigkeiten auf. Darüber hinaus ist der Sprint-Impuls eine Art „Vertrag“ zwischen Unterbefehlen. Und wenn Artefakte nicht rechtzeitig zur Verfügung gestellt wurden, hat der Spezialist das Recht, das Problem zu eskalieren, da alle Schlüsseldaten im Sprintimpuls festgelegt sind.

Eintauchen eines neuen Spezialisten in das Projekt

Normalerweise nimmt der Onboarding-Spezialist ziemlich viel Zeit in Anspruch. Um mit der vollen Kapazität arbeiten zu können, muss er verstehen, was gerade passiert, und sich in die Prozesse einarbeiten.

Beispiel: Ein anderer Designer ist mit dem Projekt verbunden. Er wird über das Projekt und die Aufgaben informiert: teamweit sowie direkt von seinem Subteam. Dann muss er mit anderen Designern und Entwicklern sprechen. Es ist wichtig, alle Feinheiten zu kennen, um beispielsweise Entwickler für die Beurteilung der technischen Komplexität der von ihm entworfenen Implementierung zu gewinnen. Dies kostet Zeit und lenkt das Team von Aufgaben ab, was in der Regel die Effektivität verringert.

Lösung: Der für das Projekt vorbereitete Sprintpuls vereinfacht und beschleunigt das Eintauchen eines Spezialisten erheblich. Es zeigt bereits deutlich die Abhängigkeiten im Team - für wen, zu welchem ​​Zeitpunkt und was bereitgestellt werden muss. Mit ihrer Hilfe können Sie schnell und effizient neue Spezialisten in ein Projekt einbinden.

Fazit

Es stellt sich heraus, dass ein effektiver Prozess eingerichtet wird, wenn jeder Mitarbeiter versteht, was, wann und warum er tut. Dazu muss das Team synchronisiert sein und der Sprintpuls muss diese Aufgabe gut bewältigen. Dies ist nur ein zusätzliches Tool für Scrum-Befehle, aber sicherlich nützlich. Es ermöglicht Ihnen, schnell einen Produktionsprozess einzurichten und eine Verantwortungszone für alle zu bestimmen. Der Sprintimpuls hilft dabei, sich im Sprint-Timing zu bewegen, und rechtzeitig abgeschlossene Sprints garantieren wiederum die pünktliche Fertigstellung des Produkts.