it-swarm.com.de

Wie koordiniere ich die Entwicklerzeit zwischen zwei verschiedenen Projekten in Scrum?

Ich wurde der Scrum Master eines neu gegründeten Teams, das für die Erstellung einer Software UND die Wartung anderer bereitgestellter Anwendungen verantwortlich ist. Grundsätzlich hat jedes Teammitglied Entwicklungs- und Betriebsaufgaben.

Ich habe in den letzten Wochen beobachtet, wie sie funktionieren, und festgestellt, dass das Team Probleme bei der Koordination dieser Aufgaben hat. Wenn sich ein Entwickler auf das Codieren konzentriert, wird er unterbrochen, um ein in der Produktion aufgetretenes Problem zu beheben, und es fällt ihm schwer, sich wieder auf die vorherige Aufgabe zu konzentrieren.

Ich habe versucht,% der Entwicklerzeit für die Betriebsarbeit zuzuweisen, aber anscheinend löst dies das Problem nicht. Ich bin daran interessiert, von Scrum-Meistern zu hören, die zuvor auf diese Situation gestoßen sind. Wie haben Sie damit umgegangen und was sind Ihre Empfehlungen?

40
Shadin

Dieses Problem ist so alt wie Scrum. Es gibt eine Lösung, aber Sie werden es nicht mögen.

  • Stellen Sie neue Aufgaben in den Rückstand.
  • Unterbrechen Sie Entwickler nicht.
  • Warten Sie auf den nächsten Sprint.

Wenn Sie Ihre Entwickler in mehr als ein Scrum stecken, zwei separate Rückstände haben oder nur einen Prozentsatz ihrer Zeit dem Sprint zuweisen, wirkt sich dies auf das aus, was Scrum erreichen möchte, d. H. Auf einen konsistenten Fluss abgeschlossener Aufgaben.

Wenn Sie diese Art von Dingen ausprobieren, kehren Sie im Grunde zu den Entwicklungsmethoden "Chaos" oder "JFDI" mit all den damit verbundenen Problemen zurück, z.

  • Entwickler haben jeweils zehn Aufgaben gleichzeitig unterwegs. Niemand weiß, woran sie arbeiten oder wann es fertig sein wird.
  • Unbekannte Zeit zum Beenden des Projekts, da dies davon abhängt, welche anderen Projekte gleichzeitig ausgeführt werden.
  • Keine einheitliche Sicht auf die Projektpriorität. Andere Manager leiten Entwickler zu ihren Lieblingsprojekten um.

Die übliche Antwort auf diesen Rat lautet natürlich: "Aber das kann ich nicht! Das Unternehmen muss diese Produktionsfehler so schnell wie möglich beheben!"

Das stimmt aber nicht wirklich.

Wenn Sie wirklich so viele tatsächliche Fehler haben, die das Geschäft in diesem Ausmaß betreffen, müssen Sie professionell werden und Ihre Tests verbessern. Arbeiten Sie einfach an Fehlern und automatisierten Tests, bis Sie alle behoben haben. Stellen Sie ein QA-Team ein und testen Sie alle Neuerscheinungen.

Was jedoch wahrscheinlicher ist, ist eine der folgenden:

  • Die Fehler sind Betriebsprobleme, kein Speicherplatz mehr, kein DR, keine Backups, kein Failover usw. Holen Sie sich ein OPS-Team.

  • Die Fehler sind Benutzer, die nicht verstehen, wie das System funktionieren soll. "Dies ist passiert! Ist es ein Fehler?". Holen Sie sich einen Helpdesk und schulen Sie Ihre Benutzer, schreiben Sie Dokumentation.

  • Angst vor Rollback. Sie haben eine neue Funktion gestartet, die etwas kaputt gemacht hat. Versuchen Sie nicht, eine Lösung zu finden. Machen Sie einen Rollback zur vorherigen Version und fügen Sie die Fehler in das Backlog ein.

60
Ewan

Ich versuche hier nur über den Tellerrand hinaus zu denken.

Da es möglicherweise nicht möglich ist, den Produktbesitzer dazu zu bringen, die Dinge auf Ihre Weise zu sehen. Es kann immer noch kritische Fehler geben, die einfach nicht warten können, sich mit Kunden treffen, bei denen Entwicklerunterstützung benötigt wird usw., bei denen Sie einen Entwickler für eine Weile aus dem Sprint nehmen müssen.

Warum nicht versuchen, dies zu antizipieren und zu Ihrem Vorteil zu nutzen?

Sie benötigen ein Team von 5+, damit es vielleicht realistisch ist.

Aber warum nicht einen Entwickler bei jedem Sprint ausschalten (zwischen den Entwicklern wechseln, jeder ist an der Reihe).

Da es höchstwahrscheinlich nicht genügend Fehler gibt, um einen vollständigen Entwickler für Korrekturen zu verwenden, können andere Probleme oder Aufgaben ausgeführt werden.

  • Ausführen von Tests zur Ermittlung von Leistungsengpässen oder Skalierbarkeitsproblemen
  • Wartung des Build-Systems
  • Treffen mit Kunden
  • Erforschung neuer Frameworks/Bibliotheken
  • Erkunden von Sprachfunktionen, die Sie verwenden möchten
  • Informationen zu Sicherheitsfragen
  • Datenbankpflege
  • Serverwartung

Die Teamgeschwindigkeit kann steigen, der Stress kann sinken, Konflikte mit dem Management können sinken, Sie haben tatsächlich Zeit, Ihr Wissen zu verbessern.

25
Bent

Eine effektive Lösung für die Verwaltung des Entwickleraufwands für wirklich wichtige Produktionsprobleme, die ich verwendet habe, ist der "Batman-Ansatz".

Der teure Aspekt der Verantwortung für die Produktionsunterstützung bei der Entwicklung neuer Funktionen ist das Umschalten des Kontexts. Sie sollten daher versuchen, dies zu begrenzen.

Erstellen Sie mit dem Buy-In des Teams eine Liste der Teammitglieder und durchlaufen Sie diese, sodass jeden Tag eine neue Person beim Stand-up-Meeting als "Batman" deklariert wird und an diesem Tag auf wichtige Produktionsprobleme reagiert. Der Rest des Teams kann sich auf die Entwicklung konzentrieren, ohne den Kontext wechseln zu müssen, und jeder hat einen angemessenen Anteil am Schmerz der Unterstützung. Bei einem 5-köpfigen Team ist dies ein Tag in der Woche, an dem ein Entwickler möglicherweise unterbrochen wird, und 4 Tage ununterbrochene, vorhersehbare Entwicklungszeit.

Dies hat den Vorteil, dass Wissen/Erfahrung im Team geteilt werden, sodass Sie nicht eine Person haben, die für die Behebung bestimmter Probleme verantwortlich ist und zu einem einzigen Fehlerpunkt und einer gerechten Aufteilung der Supportprobleme wird.

14
StuperUser