Wie wir die Entwicklung in Teams aufgeteilt haben (und endlose Sprints und nutzlose Stand-Ups vergessen haben)

Ich bin PM beim UniSender-Mailingdienst . Vor 6 Jahren bin ich als Programmierer gekommen und jetzt bin ich für die Interaktion zwischen den Produktteams verantwortlich. Zuvor bestand unsere Entwicklung aus einem verteilten Team und wir hatten zwei Probleme. Aber keine Narren und Straßen, sondern Verzögerungen bei Sprints und langweiligen Stand-Ups um eine halbe Stunde.

Ich werde Ihnen sagen, wie wir sie gelöst haben.

Wie gesagt, wir hatten zwei Probleme:

1. Sprint könnte aufgrund der Schuld einer Aufgabe verweilen . QA und Dev arbeiteten am selben Sprint, die Aufgabenbereiche wurden zu Beginn der Arbeit festgelegt, und das gesamte Team beeilte sich heldenhaft, sie umzusetzen. Manchmal kamen dringende Fehler an, die zu den "Master" -Hotfixes gingen. Sprint-Aufgaben können sehr umfangreich sein. Als einige Aufgaben zur Veröffentlichung bereit waren, befanden sich andere noch in der Entwicklung. Infolgedessen könnte das Team den Sprint aufgrund einer Aufgabe verzögern.
2. Stand-ups waren zeitaufwändig und von zweifelhaftem Nutzen . Das Team wuchs, Stand-Ups wurden über Skype durchgeführt, und am Anfang gab es keine Probleme. Wir begannen zu vermuten, dass etwas nicht stimmte, als sich die Stand-Ups 20 bis 30 Minuten lang zu dehnen begannen. Die Anwesenden verstanden nicht immer, was andere Teammitglieder taten.

Wir haben einige Zeit mit diesen Problemen gelebt und dann versucht zu kämpfen.

• Sie reduzierten Stand-ups durch die Einführung von Vorschriften für den Menschen.
• Sie reduzierten die Anzahl der Anwesenden - nur der Teamleiter ging in die Stand-Ups.
• Versuchte wöchentliche Sprints.
• Die Anzahl der Aufgaben im Sprint wurde reduziert.

Diese Versuche ergaben nicht das erwartete Ergebnis. Es hat sich herausgestellt, dass auf radikale Veränderungen nicht verzichtet werden kann.

Hier ist es notwendig, ein paar Worte über das Produkt zu sagen.

Wir sind eine SaaS-Lösung, die rund um die Uhr verfügbar ist. Zusätzlich zu dem für Benutzer sichtbaren Teil - der GUI - verfügen wir über eine große Ebene an Systemlogik, die unabhängig von der Tageszeit oder der politischen Situation im Land funktioniert. Das heißt, die Entwicklung und Aktualisierung des Dienstes wird fortgesetzt, ohne anzuhalten.

Nach Kanban gehen

Die erste große Revolution fand statt, als wir feststellten: "Scrum ist nicht für uns geeignet."
Wir beschlossen, nach Kanban zu wechseln. Natürlich waren wir kein Toyota und haben nicht begonnen, die vollständige Implementierung umzusetzen. Daher unterscheidet sich "unser Kanban" von "Ihrem Kanban".

Sprints und Teamarbeit

Kurz gesagt zu unserer Version:

• Wir betrachteten den Sprint (eine abgeschlossene Funktionalität) als Arbeitseinheit.
• Ein Team für die Aufgabe wurde abhängig von der Belastung und den erforderlichen Fähigkeiten zusammengestellt. Ein Team hatte normalerweise bis zu 3 Entwickler und 1 Qualitätssicherung. Es gab keine ständigen Teams.
• Die Anzahl der gleichzeitigen Sprints ist mehr als eins geworden.
• Es gab kein physisches Board und andere Attribute von Kanban, Aufgaben wurden durch die Hinzufügung zu Jira ausgeführt.

In diesem Fall musste das Team von Anfang bis Ende einen Sprint absolvieren. Dies galt auch für die Testphase: Dieselben Personen, die am Sprint gearbeitet haben, haben die Fehler korrigiert.

Ergebnis.

• Mit der Verzögerung großer Aufgaben litten die anderen nicht, deren Entwicklung abgeschlossen war.
• Die Anzahl der Probleme während der Bereitstellung hat abgenommen - in einem Sprint gibt es weniger bunte Aufgaben.

Standups

Die Stand-Ups wurden transformiert - sie wurden von einem Vertreter jedes Teams besucht, das an einem separaten Sprint arbeitete.

Ergebnis.

• Standups wurden wie Standups und wir fingen wieder an, in die Standard 10-15 Minuten zu passen.

So konnten wir kritische Probleme lösen.

Aber ... der ganze Eisberg tauchte hinter der Insel auf!

Nach dem Wechsel zu Kanban haben wir ein engagiertes Frontend-Team und mehr Mitarbeiter im Backend- und Produktteam. Die Interaktion zwischen den Abteilungen wurde komplizierter - mehrere Teams konnten an einem Projekt arbeiten.

Wir haben einige Probleme gelöst, aber neue sind in den Vordergrund getreten:

• Nicht jeder nahm an Stand-Ups teil - oft musste das Team Informationen nacherzählen.
• Eine Qualitätssicherung könnte 2-3 parallele Sprints mit verschiedenen Teams haben. Ich musste wechseln: Erinnern Sie sich an die Funktionen des Sprints und stellen Sie den Code in Testumgebungen ständig neu bereit.
• Die Qualitätssicherung war nicht vollständig in den Sprintprozess involviert. Oft erreichte die Aufgabe sie am Ende des Sprints und die Anforderungen wurden nach Abschluss der Entwicklung untersucht.
• Die für das Projekt versammelten Teams und ihre Zusammensetzung änderten sich häufig. Ein Team von zwei Entwicklern könnte gleichzeitig an 3 Sprints arbeiten: 2 Sprints im Test plus 1 aktueller Sprint.
• Es war schwierig, die Entwicklungszeit abzuschätzen. Es ist nicht klar, wie lange der vorherige unvollendete Sprint dauern wird.

Einige Zeit lebten wir nach den neuen Regeln und kämpften mit neuen Herausforderungen. Wir haben verschiedene Ansätze ausprobiert und viele Zapfen gefüllt.

Am Ende hatten wir wieder den Verdacht, dass etwas schief lief. Eine neue Revolution zu sein.

Aufteilung in Teams, neue Stand-Ups, Einführung von Fireteam

Wir haben die Prozesse vom Beginn der Idee bis zur Bereitstellung der fertigen Implementierung in prod analysiert. Wir haben uns angesehen, wie agile Methoden in anderen Unternehmen funktionieren. Wir haben festgestellt, dass unsere Herangehensweisen an den Entwicklungsprozess nicht so schlecht waren.

Sie müssen kein funktionierendes System beschädigen, sondern müssen die Momente beheben, die Schmerzen verursachen.

Dies haben wir während des Entwicklungsprozesses geändert.

Sprints

Wir haben immer noch das Konzept des "Sprints" angewendet. Sprint ist ein „fast zweiwöchiger“ Arbeitsbereich für das Team.

Was ist das Plus? Der Code wird nicht "schlecht" und gelangt ohne nennenswerte Verzögerungen zum Produkt. Wenn das Team in 2 Wochen einen Sprint machen wird, müssen Sie versuchen, ihn auf einen Monat zu beschränken.

Was kann verbessert werden. Oft verfehlen wir die Marke und Sprints sind etwas verzögert. Die Zeit, um an einigen Sprints zu arbeiten, ist anfangs schwer zu bewerten (zum Beispiel viel Refactoring). Wir müssen dieses Problem lösen.

Aufteilung in Teams

Wir haben ein großes Team in mehrere kleinere Teams aufgeteilt. Jeder von ihnen umfasst 2-3 Entwickler und eine dedizierte Qualitätssicherung. Jetzt sind die Teams stabil und wechseln nicht von Projekt zu Projekt. Manchmal wechseln Leute zwischen Teams, um Dienstpläne zu optimieren oder einem Team das erforderliche Fachwissen hinzuzufügen. BA nimmt am Team teil, kann aber gleichzeitig 2-3 Projekte leiten.


Obwohl der Rest immer noch ein Team ist)

Gleichzeitig arbeitet das gesamte Team von Anfang bis Ende an einem Projekt. Ein Projekt kann aus mehreren Sprints bestehen.

Was ist das Plus?

• Die Teams befinden sich im selben Raum. Davor saßen alle in Abteilungen.
• Das Team wird von Anfang bis Ende in die Arbeit am Projekt einbezogen, wodurch der Busfaktor reduziert wird.
• Teammitglieder sind bei allen Veranstaltungen anwesend: Retro, Stand-Ups, Plenings. Alle Mitarbeiter sind über aktuelle Aufgaben auf dem Laufenden.
• Das Team arbeitet nicht mehr an den Sprints anderer Leute. Jetzt ist alles einheimisch.

Was kann verbessert werden. Ich möchte BA vollständig in das Team einführen. Dies ist problematisch, da die VA normalerweise früher als der Rest des Teams mit der Arbeit beginnt.

Teamarbeit

Ein Team in Arbeit kann nicht mehr als zwei Sprints haben: "den, der noch auf dem Prüfstand ist" und "den neuen, den wir sehen werden". In der Regel beginnen alle nach dem Ende der Entwicklung mit der Arbeit an einem neuen Sprint, sobald sie veröffentlicht werden.

Was ist das Plus? Die Teamarbeit ist vorhersehbarer geworden, jeder kennt den Code und kann den Sprint beim Testen unterstützen. Es ist weniger wahrscheinlich, dass Teilnehmer zwischen Aufgaben wechseln, und der Wechselprozess ist jetzt schneller.

Was kann verbessert werden. Idealerweise sollte ein Team nur einen Sprint in Arbeit haben. Aber im Moment ist eine ideale Welt nicht unsere Welt.

Fireteam

Jedes Team wird für eine Woche gewählt. Dieser Befehl reagiert auf alle externen Reizstoffe: Anrufe aus anderen Abteilungen, abnormales Verhalten des Dienstes, Hotfixes. Wir nennen dieses Team "Fireteam".

Was ist das Plus? Die Fireteam-Woche zählt in der Sprintzeit nicht für das Team. Zwischen der Brandbekämpfung können sich die Mitarbeiter auf ihre Aufgaben konzentrieren:

• Refactor.
• Schließe die Sprintaufgabe ab.
• Dokumentation schreiben.
• Führen Sie einen Wissenstransfer mit anderen Teams durch.

Nachteil. In der Fireteam-Woche ist das Leben des Teams sehr ereignisreich. Alle Abteilungen lieben und kennen diese Personen persönlich, insbesondere die technische Unterstützung. Sie müssen ständig zwischen verschiedenen Aufgaben wechseln: Abbuchung, Lesen von Protokollen, Sägen dringender Aufgaben und Löschen aller Brände. All dies muss gleichzeitig erfolgen.

Standups

Wir haben zwei Arten von Stand-Ups eingeführt:

1. Team Sie beteiligten ein Team, das an dem Projekt arbeitet.
2. Allgemein Sie finden einmal pro Woche statt, Leads von jedem Team nehmen daran teil.

Was ist das Plus?

• Das Team wird über den Sprintzustand informiert.
• Die Mitarbeiter wissen, was andere Teams tun.
• Stand-Ups werden nicht zu "langweiligen Aktivitäten zum Lesen einiger Zahlenreihen von einem Blatt Papier". Alle Anwesenden verstehen, worum es geht. Es ist einfacher geworden, Problembereiche bei der Arbeit zu erkennen.
• Standups dauern 5-10 Minuten.

Nachteil. Das Team überträgt weiterhin Informationen an das Team.

Zusammenfassung

Indem wir den Prozess schrittweise änderten, lösten wir die meisten dringenden Probleme:

• Wir haben stabile Teams aus 2-3 Entwicklern und QS zusammengestellt. Jedes Team hat jetzt nicht mehr als 2 Sprints, die Teilnehmer arbeiten nicht an den Projekten anderer Leute.
• Es gab ein Team, das Nachrichten aus anderen Abteilungen verarbeitet, auf abnormales Verhalten des Dienstes und Hotfixes reagiert. Andere Teams lassen sich von diesen Aufgaben nicht ablenken.
• Jetzt hat das Unternehmen zwei Arten von Stand-Ups: Team und General. Alle Mitarbeiter werden über den Stand der Sprint-Angelegenheiten informiert, und ein Stand-up dauert normalerweise 5-10 Minuten.

Nun, wir arbeiten daran.