Hallo allerseits, mein Name ist Alexei Fedorov, ich bin Teamleiter des Finanzteams von Citimobil. In diesem Artikel möchte ich erläutern, wie der agile Entwicklungsprozess in unserem Team funktioniert.
CityMobil ist der zweitgrößte Taxi-Aggregator in Russland. Im Laufe des Jahres sind wir etwa zehnmal gewachsen und werden nicht langsamer. Solch ein schnelles Wachstum bringt einige Einschränkungen mit sich: Wir benötigen eine sehr kurze Time-to-Market (TTM), die Zeit von der Idee bis zur Verwendung durch echte Kunden sollte so kurz wie möglich sein. Aufgrund der Tatsache, dass wir TTM minimieren, sammeln wir die Freigabe nicht, sondern rollen jede Aufgabe / Funktion separat. Dieser Ansatz hat auch ein wichtiges Plus - bei Problemen im Produkt wird sofort klar, warum sie aufgetreten sind. Auf diese Weise können Sie die Aufgabe zurücksetzen, nicht die gesamte Version.
Warum nicht Scrum?
Seit einigen Jahren sind die Agile-Methode und ihre Scrum-Variante (im Folgenden als Scrum bezeichnet) in der IT-Branche beliebt. Scrum versucht es irgendwie in jedem Unternehmen umzusetzen. Und jeder hat seine eigene Implementierungserfahrung, ist aber in der Regel selten positiv. Häufig kommt es zu Ernüchterung und einem Rollback zu früheren Prozessen.
Meiner Meinung nach sind die Hauptprobleme von Scrum:
- Fixe Sprints.
Es stellt sich selten heraus, dass der Sprint pünktlich beendet wird, damit alles erledigt ist. In der Regel bleibt eine Kleinigkeit übrig, die nicht feststeht oder nicht überprüft wurde. Verbesserungen werden auf einen anderen Sprint übertragen, und um pünktlich zu sein, übernimmt das Team weniger Aufgaben. Es ist schwierig, den Sprint auf Aufgaben abzustimmen, damit jeder einen Job hat. RnD-Aufgaben passen im Allgemeinen nicht in einen festen Rahmen. Und am wichtigsten ist, dass feste Sprints vom Unternehmen selbst nur selten angefordert werden. - Eine Vielzahl von Rallyes.
Scrum bietet eine Vielzahl von Aktivitäten: tägliche Rallyes, Planung und Rückblick auf jeden Sprint. Oft werden diese Treffen zur Vorführung abgehalten und sind eher anstrengend als nützlich.
Im Allgemeinen erinnert mich das Gedränge an einen bestimmten Frachtkult, der eingeführt wird, in der Hoffnung, dass er gut wird. Unser Ansatz ist es, die Techniken und Prozesse zu verwenden, die dazu beitragen, das Ergebnis zu erzielen, und das zu verwerfen, was stört.
Das team
Die Schlüsselrolle bei der Gestaltung des Prozesses spielt das Team und seine Struktur. Unser Team besteht aus Entwicklern und Teamleitern. Optional PM, QA, Analysten, Designer. Das Team muss als einzelne Kampfeinheit wahrgenommen werden. Dies ist eine graue Kiste, an deren Eingang Anforderungen gestellt werden, und am Ausgang das Produkt. Die interne Organisation ist vollständig dem Team überlassen und kann in sich jeden Prozess bearbeiten, der dazu passt.
Wie bei uns
Unser Team hat einen Prozess gewählt, der Kanban sehr ähnlich ist. Wir haben viele Aufgabenquellen: Vom Bug-Support-Service gefundene, neue Funktionen aus Produkten, technische Schulden, Funktionen eines benachbarten Teams usw. Es spielt keine Rolle, woher die Aufgabe stammt, sie sollte im Aufgaben-Tracker angezeigt werden, vorzugsweise vom Autor selbst. Jede eingehende Aufgabe durchläuft verschiedene obligatorische Status: "Neu", "In Arbeit", "In Bearbeitung", "Getestet", "Bereit zur Bereitstellung".
Aufgaben bewegen sich auf dem Brett von links nach rechts und kehren selten zurück. Die Priorität erstreckt sich von oben nach unten und von rechts nach links. Beispielsweise ist die Einführung einer Aufgabe in der Produktion wichtiger als das Testen, und das Testen ist wichtiger als die Neuentwicklung. Die Spalte "To Work" bildet im Wesentlichen den Rückstand des Teams - eine priorisierte lineare Liste von Aufgaben für einige Wochen im Voraus. Sobald der Entwickler seine aktuelle Aufgabe verstanden hat, nimmt er die nächste Spalte von oben auf.
Aufgaben werden nicht im Voraus für einen bestimmten Entwickler festgelegt. Dieser Ansatz ermöglicht es, die Ausführung von Aufgaben auszugleichen, das allgemeine Wissen über den Code für alle Entwickler zu verbessern und den Busfaktor zu erhöhen. Wir bemühen uns um eine enge Spezialisierung innerhalb des Teams. Jedes Teammitglied muss in der Lage sein, Aufgaben aus dem Backlog auszuführen. Wenn der Entwickler die Aufgabe für sich selbst übernommen hat, steuert er die Bewegung auf dem Board vollständig, bis sie im Produkt angezeigt wird. Er prüft auch, wie sich die Aufgabe unter realen Bedingungen verhält.
Von den Treffen, die wir täglich abhalten, besprechen wir bei dieser Rallye nicht nur Pläne, Probleme und erledigte Aufgaben, sondern auch Lösungsansätze, Vorschläge und im Allgemeinen alles, was die Teammitglieder beunruhigt. Das Meeting dauert selten länger als 30 Minuten für 4 Personen. Jeden Monat führen wir eine Retrospektive zu einer Scram-Probe durch: Was war gut / schlecht, was können wir damit machen, einen Plan zur Steigerung der Effizienz für den nächsten Monat. Wir haben keine spezielle Planung, wir arrangieren bei Bedarf die Planung, wenn wir anfangen, eine große Aufgabe zu entwickeln.
Wir versuchen, für jede Aufgabe mindestens 75% der Arbeitszeit zu protokollieren. Damit erreichen wir zwei Ziele:
- Wir suchen und eliminieren Zeitkiller: Aufgaben, die zeitaufwändig waren, aber nicht den erwarteten Nutzen brachten.
- Wir bewerten die Aufgaben auf der Grundlage bereits erledigter Aufgaben und erhöhen dadurch die Genauigkeit der Bewertung.
Wir haben auch wöchentliche Schichten: Einer der Entwickler beantwortet Fragen aus der zweiten Support-Zeile, sucht nach neuen Problemen in den Protokollen / der Überwachung, löst dringende Aufgaben und unternimmt etwas, das nicht in den geplanten Rückstand passt. Dies ermöglicht anderen Entwicklern, sich mehr auf ihre Aufgaben zu konzentrieren, ohne von Boten usw. abgelenkt zu werden.
Zusammenfassung
Das beschriebene Verfahren habe ich mit geringfügigen Abweichungen in mehreren Teams und Firmen angewendet. Er etablierte sich als der flexibelste und transparenteste für alle.
Wir ruhen uns nicht auf unseren Lorbeeren aus, sondern gestalten mit jedem neuen Rückblick unseren Arbeitsprozess besser und effizienter. Jedes Mal, wenn wir die angewandten Praktiken überprüfen. Wir haben keine „heiligen Kühe“ - was früher funktionierte, hört möglicherweise auf zu arbeiten, und viele gute Ideen in der Theorie zeigen sich in der Praxis nicht auf die beste Weise. Wir lassen sie ohne Reue fallen.
Der Prozess der kontinuierlichen Verbesserung ist das Fundament unseres Teams.