Manchmal geraten junge Entwicklungsteams in Unordnung.
Dies geschieht zu einem Zeitpunkt, an dem sie noch nicht vollständig verstanden haben, was eine Kante ist. Das Projekt und das Produkt streiten darüber, wer von ihnen wer ist, und jeder führt seine Aufgaben für sich aus. Oder jeder weiß bereits alles, aber Sprints können nicht geplant werden - Aufgaben werden nicht ausgearbeitet, Demos und Retro sind nicht regelmäßig.
Wir hatten auch eine ähnliche Geschichte, aber wir fanden unseren Weg.
Dies ist eine Geschichte aus dem persönlichen Account-Team von Yandex.Kassa und eine detaillierte Anleitung für diejenigen, die ihre Planung verbessern möchten.
Wie war es
Das persönliche Kontoteam von Yandex.Kassa ist für die bequeme Verbindung neuer Händler mit der Kasse verantwortlich und führt einen Abrechnungsservice durch. Nach den Maßstäben von Yandex ist das Team jung - 4 von 6 Entwicklern arbeiten sechs Monate oder weniger, und ich, der Projektmanager, bin vor drei Monaten dem Team beigetreten.
Am ersten Tag des neuen Sprints versammelte sich das Team mit dem Produktbesitzer (im Folgenden: PO) und plante den Sprint für etwa zwei Stunden. Dieser Ansatz hat offensichtliche Nachteile:
- Geringe Ausarbeitung der Anforderungen. PO hatte nicht genug Zeit, um alle Fragen zu beantworten. Wir haben solche Aufgaben entweder in den Sprint aufgenommen oder Analysten gebeten, die Aufgabe zu bewerten, und ihre Implementierung auf den Start des nächsten Sprints verschoben.
- Es gab Situationen, in denen sich die Stakeholder erinnerten, als der Sprint in vollem Gange war und wir dringend einige Verbesserungen oder Lösungen von verwandten Teams benötigten.
- Mangel an Risikomanagement.
Mit ihrer Überlegung ergaben sich Anforderungen für einen neuen Prozess:
- Die Anforderungen für Aufgaben sollten sowohl vom Eigentümer des Produkts als auch von allen interessierten Parteien ausgearbeitet werden.
- Implementiertes Dod (Definition von erledigt ist eine Reihe von Kriterien, anhand derer Sie verstehen können, ob der Zweck der Entwicklung erfüllt wurde) für jede Aktivität. Sie begannen, Stakeholder zu identifizieren, um sie eine Woche vor Beginn eines neuen Sprints über den Fortschritt der Arbeit zu informieren und Feedback zu sammeln.
- Mindestbesprechungen, um sich auf den aktuellen Sprint zu konzentrieren. Begrenzt auf zwei Sitzungen in zwei Wochen für jeweils eine Stunde.
- Sie begannen als Team regelmäßige interne Produktschulungen durchzuführen, da heute eines der Hauptrisiken ein Mangel an Wissen über das Produkt ist.
Neue Konzepte
Wir haben neue Container (Listen) mit Befehlen eingeführt:
Die Priorität der Aufgaben in allen Listen mit Ausnahme der ersten wird durch die Bestellung bestimmt.
Wenn die Aufgaben im Sprint erledigt sind, kann ein Teammitglied Aufgaben von Estimated in die Arbeit übernehmen und wird verstehen, dass sie vollständig arbeitsbereit sind - nehmen Sie es und erledigen Sie es.
Erste Woche
Per Klick - Vollversion.
Montag
Der Product Owner verschiebt Aktivitäten aus dem Aufgabenlisten-Container in die Pflege, priorisiert und beschreibt die Definition von Fertig so klar wie möglich.
PM vergleicht die Aktivität im Pflegecontainer anhand der Checkliste:
- Werden Layouts für neue Aktivitäten benötigt und wenn ja,?
- Wurden alle Aktivitäten für das wichtigste Projekt aufgenommen?
- Werden Verknüpfungen zwischen Aufgaben angezeigt?
Wenn etwas nicht stimmt, kommuniziert PM mit der Bestellung, um die Details zu klären, und benachrichtigt das Team, dass die Pflegeliste auf dem neuesten Stand ist.
Ein Beispiel:
- Nehmen Sie die Aufgabe "Briefe über nachts ausgestellte Rechnungen werden mit Verspätung verschickt." Es wurde vom Tester am Ende der Pflegeliste hinzugefügt.
- PO hat diese Aufgabe in die Liste aufgenommen.
- PM überprüfte, ob die Aktivität zur Arbeit mit dem Container seitens PO ausgeführt wurde, und informierte das Team darüber.
Dienstag
Das Team macht sich mit neuen Aktivitäten vertraut und schreibt Kommentare, Fragen und macht Vorschläge. PO erhält automatisch alle neuen Kommentare (wir verwenden Jira, dies ist also einfach) und hat bis morgen Zeit, Antworten vorzubereiten.
Ein Teammitglied hat angegeben, ob die Aufgabe relevant ist. Es stellte sich heraus, dass die Aufgabe relevant ist. Der Tester fand die Ursache des Problems und meldete sie. Aus Sicht der Geschäftslogik blieb die Frage jedoch offen.
Mittwoch
Wir haben ein Treffen mit der PO, die die Fragen des Teams beantwortet. Der Zweck des Meetings: DoD zu beheben. Nach dem Meeting wird ein Teil der Aktivitäten in den Container "Definiert" und ein Teil - sofort in den Bereich "Geschätzt" verschoben, wenn sofort ersichtlich ist, wie lange diese Aktivität dauern wird. Definieren Sie Abhängigkeiten und Stakeholder.
Ein Dialog zwischen PM und PO, in dem klar wurde, was zu tun ist. Normalerweise ist dieser Dialog nicht festgelegt, aber aufgrund dieser Aktivität war die Bestellung während des Meetings nicht verfügbar, weshalb die Kommunikation schriftlich aufgezeichnet wurde.
Donnerstag
PM sendet eine Liste der Aktivitäten in der Nähe aus der Liste "Geschätzt" und "Definiert" an interessierte Parteien mit der Bitte, diese anzuzeigen und zu kommentieren.
Freitag
PM beantwortet Fragen von Stakeholdern und bezieht bei Bedarf ein Team oder eine PO mit ein.
Es sind keine Kommentare zu der Aufgabe eingegangen, die wir als Beispiel zeigen, aber im Allgemeinen sieht es so aus:
Feedback kann über den Messenger kommen.
Das Ergebnis der ersten Woche ist eine Aktivität, nach der klar ist, was zu tun ist (dod wird festgelegt), wobei die Wünsche der interessierten Parteien berücksichtigt werden.
Zweite Woche
Montag
Das Team bewertet unabhängig die Aktivitäten in der Liste "Definiert" und die Zerlegung der Aktivitäten in der Liste "Geschätzt". PO ist hier nicht beteiligt, da er für die Festlegung von Aufgaben seitens des Unternehmens verantwortlich ist und es nicht in seiner Verantwortung liegt, zu bewerten, wie die geplanten Aufgaben ausgeführt werden.
Dienstag
Es gibt ein zweites Treffen mit PO, bei dem das Team die Details klären und ihre Bewertungen mitteilen kann. PO kann Sie über neue Einführungsereignisse informieren, die möglicherweise in der letzten Woche aufgetreten sind, und klarstellen, warum die Aktivitäten genau solche Schätzungen sind und nicht weniger.
Mittwoch
Es gibt eine Demo zum aktuellen Sprint. Als Ergebnis der Demo werden normalerweise neue Aktivitäten gebildet, von denen einige vor Ende der Woche abgeschlossen sein müssen, der Rest im nächsten Sprint. Der Zweck der Demo ist es, Feedback zu sammeln. Das Team präsentiert das Ergebnis seiner Arbeit und erhält frühzeitig Feedback zur Arbeit der neuen Funktionalität.
Die Demo ist intern und extern .
Die interne Demo ist für PO, wo er bewertet, ob das Team das erwartete Ergebnis erzielt hat oder ob Verbesserungen erforderlich sind. Es wird von einem Tester in einer Testumgebung durchgeführt.
Die externe Demo richtet sich an Interessenten. Tritt nach der Berechnung der neuen Funktionalität "zum Kampf" auf, führt es PO.
Nach der Demo werden dem Backlog neue Aktivitäten hinzugefügt, die je nach Priorität und Bewertung zum aktuellen Sprint hinzugefügt werden können. Wir führen speziell Mitte der zweiten Woche eine Demo durch, um bis zum Ende des Sprints Zeit für Verbesserungen zu haben.
Donnerstag
PO priorisiert die definierten Listen (wenn die Aktivitäten während des Sprints vor Ablauf der erwarteten Frist abgeschlossen werden, können neue Aktivitäten aus dieser Liste in Arbeit genommen werden) und geschätzt (die Aktivitäten aus dieser Liste werden in einen neuen Sprint übertragen).
Freitag
Es findet eine Sprintplanung statt, an der das PM- und PO-Entwicklungsteam teilnimmt.
In einem Retro diskutieren wir, wie wir im aktuellen Sprint gearbeitet haben und ob wir für den nächsten gut vorbereitet waren: Meinungen austauschen, ob beim bevorstehenden Sprint alles klar ist, ob wir noch genügend Ressourcen in der Ressource haben, um unerwartete Fehler zu beheben.
Ein Risikomanagement-Meeting findet statt. Im Moment widmen wir uns diesmal der Untersuchung des Produkts, da sein hervorragendes Verständnis die Risiken erheblich reduziert. PM gibt zusammen mit Testern während der Woche Zeit, um das Produkt zu untersuchen, und teilt das Ergebnis dem Team mit. Vertreter der Einheiten werden zu dem Treffen eingeladen, um das Bild zu ergänzen.
Jeder zweite Freitag ist nicht nur das Ende der Arbeitswoche, sondern auch des Sprints. Dies ist ein Tag der Kommunikation und des Feedbacks. So beginnt der Montag der neuen Arbeitswoche mit klaren und geschätzten Aufgaben, was auch für das Team logisch und angenehm ist.
Schlussfolgerungen und nächste Schritte
Mit Hilfe dieses Prozesses konnte eine qualitativ hochwertige Interaktion zwischen der PO und dem Team hergestellt werden, Konflikte und Missverständnisse waren in der Vergangenheit. Das Klima im Team verbesserte sich und es entstand ein Gefühl harmonischer rhythmischer Arbeit. Natürlich gibt es immer noch viele Probleme, aber es gibt viel weniger Notfälle und unvorhergesehene Situationen, in denen das Team oder der PM das Projekt retten mussten.
Wie alle Lebewesen muss unser Prozess von Zeit zu Zeit aktualisiert werden. Jetzt sehen wir, dass es sich lohnt, in den folgenden Bereichen abzuschließen:
- Bugs. Die Arbeit mit Fehlern muss ebenfalls geplant werden. Wir können die aufkommenden Fehler im Sprintplanungsprozess nicht ausführen, hier sind weitere operative Arbeiten erforderlich. Wir überlegen, wie es geht.
- Wir möchten eine Tabelle mit typischen Risiken erstellen, um diese zu berücksichtigen und die Wahrscheinlichkeit von Fehlern bei der Durchführung des Sprints zu verringern.
- Bei der Planung eines Sprints möchten wir auf dem Ziel des Sprints aufbauen, um den Fokus der Arbeit zu behalten. Das Team ist jung, daher gibt es Schwierigkeiten damit.
Wir hoffen, dass unsere Erfahrung Ihrem Team hilft. Wir sind bereit, unseren Ansatz in den Kommentaren zu diskutieren, Fragen zu beantworten oder Ratschläge zu geben.