Ist Scrum oder Kanban für SRE-Teams wirklich nützlich?

Agile Praktiken wie Scrum und Kanban wurden hauptsächlich für die Softwareentwicklung entwickelt.

Unterbrochene und ungeplante Arbeiten sind ein wesentlicher Bestandteil dessen, was die meisten SRE- ( Site Reliability Engineering ) oder DevOps-Teams tun. Während es immer nützlich ist, ein Tracking-System wie Jira zu verwenden, um die Arbeit zu verwalten, funktionieren Sprint oder Kanban wirklich für SRE-Teams?

Die Einschränkungen, die ich sehe, sind:

• Die Arbeit ist sehr dynamisch und die Prioritäten ändern sich täglich. Aus diesem Grund wirkt die Sprintdauer von zwei Wochen sehr aggressiv und führt zu unnötigem Overhead.
• Bereitschaftsleute fügen dem Problem eine weitere Dimension hinzu. Manchmal kann mehr als ein Teammitglied an Bereitschafts- / Obduktionsaufgaben beteiligt sein.
• Das Team hat kein einziges "Produkt" und gibt sich daher keinem gemeinsamen Planungsprozess hin
• Tägliche Standup-Meetings sind möglicherweise nicht sehr sinnvoll, da sich die Aufgaben nicht überschneiden
• Das Team arbeitet möglicherweise an Aufgaben, die sich auf mehr als ein Partnerteam beziehen und sich daher über mehrere Jira-Projekte erstrecken. Da ein Sprint- oder Kanban-Board nur ein Jira-Projekt zulässt, kann es möglicherweise nicht in alle Arbeiten passen.

Nach dem, was ich von vielen SREs höre, mit denen ich gesprochen habe, hat die Sprintplanung für sie überhaupt nicht funktioniert. Ich würde gerne von der Community hier hören, was ihre Erfahrungen mit Sprint und Kanban sind.

Ich habe diese Frage auch auf scrum.org gestellt:

Kann Scrum von SRE-Teams effektiv genutzt werden?

Wir verwenden Agile nicht selbst für die DevOps-Gruppe, sondern integrieren uns in die normalen Scrum-Teams. Wenn das Team von DevOps etwas benötigt, z. B. die Optimierung des Build-Servers, fügt das zugehörige Team einen PBI mit dem Label "DevOps" in sein Backlog ein. Unser Lead verfügt über ein benutzerdefiniertes Dashboard in Jira mit allen Problemen mit der Bezeichnung "DevOps". Sie arbeiten mit dem Scrum Master zusammen, um Prioritäten zu setzen, und dann wird einer der DevOps-Ingenieure beauftragt, für die Dauer dieses Problems ein Ad-hoc-Mitglied dieses Scrum-Teams zu sein. Dies hilft uns, die Arbeit anhand der Prioritäten unserer "Kunden" zu priorisieren, bindet unsere Anstrengungen an den Sprint und ermöglicht es uns, "Anerkennung" für die von uns geleistete Arbeit zu erhalten.

Zuvor haben wir Kanban auf Jira nur für eine Aufgabenliste verwendet. Leider mussten wir manchmal aufhören, an etwas zu arbeiten, an dem wir arbeiten wollten, weil eines der Teams etwas brauchte. Sofern es sich nicht um einen Notfall handelt, fordern sie DevOps-Ressourcen (Personen / Zeit) grundsätzlich über ihren Rückstand an und der Scrum Master teilt dies unserem Lead mit.

Agile eignet sich sehr gut für diese Art von chaotischer Umgebung. Aus den von Ihnen hervorgehobenen Gründen passt das reine Lehrbuch Scrum jedoch möglicherweise nicht besonders gut. Als Scrum Master, der eine ganze Menge DevOps macht, habe ich Kanban-Boards in Jira verwendet, um die Arbeit zu verfolgen.

Kanban Vorteile

• Visualisierung der Arbeit des Teams.
• Identifiziert Engpässe für das Team.
• Hilft dabei, das Team darauf zu konzentrieren, die Arbeit voranzutreiben.
• Ermöglicht das Hinzufügen von Arbeiten zu jedem Zeitpunkt.
• Ermöglicht die Sichtbarkeit der Arbeit für andere Teams, die sich auf die SREs verlassen.
• Kann generisch sein, um mehrere Arten von Jobs abzudecken.

Während ein traditionelles Aufstehen möglicherweise nicht vorteilhaft ist, sollten Sie es ändern. Ein gutes Stand-up-Meeting hebt Blocker hervor, mit denen ein Teammitglied möglicherweise konfrontiert ist und die ein anderes Teammitglied zu lösen weiß.

IMO: Ja, Scrum kann von SRE-Teams effektiv eingesetzt werden. Ich habe noch nie gehört oder gelesen, dass Teammitglieder nur an Sprint-Workitems arbeiten können. Daher ist es ein Missverständnis, dass Sie Ihre gesamte Zeit und Mühe im Rahmen eines Sprints berücksichtigen müssen. Ich habe auch das Gefühl, dass es ein Missverständnis gibt, dass all Ihre Arbeit auf Sprints anwendbar ist. Konvergierend sollten Sie also einige Arbeiten mit Scrum und einige außerhalb von Scrum verwalten.

Scrum ist im Kern ein Framework (mit Artefakten und Ereignissen), das flexibel ist und zur kontinuierlichen Verbesserung der Art der Arbeit verwendet wird, die vom Team akzeptiert wird (oder auf solche Arbeiten anwendbar ist).

Was Sie tun müssen, ist ein Gleichgewicht zwischen der Zeit und dem Aufwand, den Sie für geplante, akzeptierte Sprintarbeiten bereitstellen können, die Sie und Ihr Team leisten können, und der Zeit und dem Aufwand, um ungeplante Arbeiten außerhalb des Sprints in Angriff zu nehmen.

Alle Workitems haben ein Maß für den Schweregrad und die Priorität. Wenn Sie Scrum in Betracht ziehen, sollten Sie Arbeiten bis zu einem bestimmten Schweregrad akzeptieren. Sie sollten auch Arbeiten in Betracht ziehen, die den Schweregrad anstehender Arbeiten verringern können (sofern dies überhaupt möglich ist). Ich würde Ihnen auch empfehlen, Ihre Sprints mit etwa der halben Kapazität zu starten (was schwer zu bestimmen wäre, da Zeit und Aufwand am Anfang in Bezug auf die Kapazität in Beziehung gesetzt werden) - gehen Sie leicht. Das Ziel Ihres Teams sollte immer sein, die Arbeit zu liefern, die Ihr Team akzeptiert. Seien Sie also wählerisch und überfordern Sie nicht.

Ich denke, die Art Ihrer Arbeit ist tatsächlich vergleichbar mit der Arbeit mit Produktions-Bugfixes für Entwicklungsteams. Daher möchten Sie möglicherweise die Wartungsteams der Produktion zu deren Einführung und Erfolg bei Scrum konsultieren und sich nicht unbedingt auf die Erfahrung von DevOps Engineers im Programm- und Projektmanagement beschränken.