Gott segne, ich hatte nie viel mit Wartung zu tun. Aber ich bin neugierig, ist es möglich, Scrum für die Wartung anzupassen?
Wenn ja, wie kann man beispielsweise SLA garantieren (wenn Entwickler feste Sprints haben)? Oder was sollte der Product Owner tun? Sammeln Sie Fehlerberichte oder etwas anderes?
Ich würde mir Scrumban ansehen , es kombiniert das Beste aus beiden Welten, Kanban und Scrum .
Kanban bietet Ihnen eine Just-in-Time-Planung, bei der Sie eingehende Probleme so schnell wie möglich angehen können. Die Kombination mit den Scrum-Rollen und -Meetings führt zu etwas, das sich für Wartungsteams sehr gut anfühlt.
Product Owner sollten wie gewohnt die langfristige Vision und die kurzfristige Prioritätenliste entwickeln. Aber statt fester Termine Planungsmeetings ansetzen. Führen Sie Just-in-Time-Planungssitzungen mit dem Product Owner durch und erstellen Sie eine Top-Liste der Elemente. Wiederholen Sie dies, wann immer der kurzfristige Rückstand fast ausgetrocknet ist.
Es gibt eine gute Frage, wann man veröffentlicht? Geben Sie frei, wann immer die Arbeit, die Sie freigeben müssen, abgeschlossen ist, oder geben Sie alles frei, was an einem festgelegten Datum fertig ist. Konzentrieren Sie sich darauf, Dinge wirklich zu erledigen, und stellen Sie sicher, dass Sie einen Zweig haben , der immer in einem freigabefähigen Zustand ist.
Lesen Sie auch das kostenlose E-Book: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
Überprüfen Sie vielleicht auch diese Frage , wo mögliche Wege zum Umgang mit Ad-hoc-Arbeiten während eines Sprints erläutert werden.
Auch wenn es möglich ist, Scrum zu verwenden, sind warteschlangenbasierte Frameworks im Allgemeinen besser für Supportprozesse geeignet. Warteschlangen sollten eher auf Antwortzeiten als auf Lösungsvorlaufzeiten ausgelegt werden, um optimale Ergebnisse zu erzielen.
Kapazitäts- und Work-in-Progress (WIP)-Grenzen sollten ebenfalls klar artikuliert werden. Sie sollten auch einen klaren Plan haben, wie Sie mit Situationen umgehen, in denen Kapazitäts- oder WIP-Grenzen nicht ausreichen, um Ihre definierten Service Level Agreements (SLAs) zu erfüllen.
Sie können sicherlich agile Praktiken für die Wartung übernehmen, aber SLA-Garantien per se sind (per Definition) nicht iterativ und nicht agil. Bei agilen Frameworks geht es um die Verbesserung von Schätzungen und die kontinuierliche Prozessverbesserung; sie sind nicht darauf ausgelegt, feste Lieferzeiten zu garantieren.
Während Scrum ein Projektmanagement-Framework ist, kann ein agiles Framework wie Scrum oder Kanban sicherlich mit einer Vielzahl von Einschränkungen zur Unterstützung verwendet werden. Insbesondere Scrum konzentriert sich weitgehend auf die Schätzung der Kapazität auf der Grundlage von zeitgesteuerten Iterationen, was nicht besonders förderlich für die Behandlung von Problemen mit hoher Priorität ist, die in der Mitte des Sprints auftreten. Der Umgang mit Support während der Entwicklung eines Produkts ist sicherlich Teil von Scrum, aber ich würde es nicht für einen reinen Support-Prozess empfehlen.
Kanban eignet sich etwas besser für Supportprozesse, da es warteschlangenbasiert ist. Wenn Wartungsprobleme gefunden werden, werden sie in die Warteschlange eingereiht. Mit Kanban haben Sie die Flexibilität, Warteschlangen zu entwerfen, die Ihren Service Level Agreements entsprechen, aber auch hier mit einigen Einschränkungen. Kanban ist insbesondere für Warteschlangen mit vorhersagbarer Variabilität in der Story-Größe optimiert. Support- und Wartungstickets müssten daher aggressiv verwaltet und in mundgerechte Stücke zerlegt werden, um den Fluss aufrechtzuerhalten.
Nach meiner persönlichen Erfahrung sollte ein SLA die Reaktionszeit garantieren, anstatt eine feste Zeitspanne für Ergebnisse zu versprechen. Mit Kanban könnte dies erreicht werden, indem einige Warteschlangen wie „Triage“ und „Respond to Customer“ hinzugefügt und Work-in-Progress (WIP)-Elemente aus anderen Warteschlangen ausgeworfen oder angehalten werden, wenn Ihre Hochgeschwindigkeits-Warteschlangen voll sind.
Es ist wichtig zu verstehen, dass es kein kostenloses Mittagessen gibt. Unabhängig von Ihrer Methodik muss Ihr Team über ausreichende Kapazitäten verfügen, um den maximalen WIP zu verwalten, den Sie im Rahmen Ihrer SLA erwarten. Wenn Sie diese WIP-Limits überschreiten, müssen Sie einen definierten Prozess zur Verwaltung Ihrer WIP-Limits haben. Dies kann über transparente Kommunikation mit Ihrem internen oder externen Kunden erfolgen oder (in einigen Umgebungen) als Geschäftsrisiko mit damit verbundenen Kosten wie Kundenrückerstattungen gehandhabt werden. Unabhängig davon, wie Sie damit umgehen oder wie hoch Ihre geplante Kapazität ist, ist es immer möglich, Ihre Warteschlangengröße oder WIP-Grenzen zu überschreiten, daher müssen Sie im Voraus entscheiden, wie Sie damit umgehen.
Scrum ist nicht für die Softwarewartung geeignet. Kanban ist.
Kanban wurde bei Toyota in Japan entwickelt, um die Automontagelinie zu verbessern.
David Anderson hat buchstäblich das Buch über den Einsatz von Kanban in der Informationstechnologie (IT) geschrieben.
Kanban hat nur wenige Prinzipien:
Visualisieren Sie den Workflow: Sie können nicht verbessern, was Sie nicht sehen. Wissensarbeit braucht eine Möglichkeit, den Status jeder Aufgabe visuell darzustellen. Kanban-Boards sind eine Möglichkeit, diesen Fortschritt anzuzeigen.
Work In Progress (WIP) begrenzen: Die Minimierung von WIP verbessert den Durchsatz.
Messen Sie die Durchlaufzeit: Summenflussdiagramme sind für diesen Zweck sehr nützlich. Und suchen Sie nach Wegen, um kontinuierliche Verbesserungen in kleinen Schritten vorzunehmen.
Obwohl ich ein Jahr, nachdem die Frage gestellt wurde, eine Antwort poste, scheint dies eine häufige Frage zu sein, und ich hoffe, meine Erfahrung würde einigen Menschen helfen, die richtige Entscheidung für ihre jeweiligen Organisationen zu treffen.
Meiner Meinung nach ist hier eine Mischung, die am besten für Wartungsprojekte funktioniert:
1). Definieren Sie einen Sprint-Zyklus – einen Wochen- oder 2-Wochen-Zyklus, abhängig vom Arbeitsvolumen, der Zeit, die zum Beheben/Testen/Freigeben benötigt wird, der Anzahl der Ressourcen, die Sie in Ihrem Team haben, und der Perspektive/Erwartungen des Kunden.
2). Planen Sie Sprints so oft wie möglich und überarbeiten Sie sie neu, um den Überblick über die Schätzungen und den aktuellen Status zu behalten. Sie werden auch die Geschwindigkeit oder Kapazität zur Lieferung in ein paar Wochen erreichen, was Ihnen bei der Planung weiter helfen wird.
3). Ich würde die Verwendung von Story Points für die Wartung nicht empfehlen , da die stündliche Schätzung in diesem Fall besser funktioniert, da Sie genau wissen, was repariert werden muss und wie viel Aufwand erforderlich ist, anstatt sich für relative Schätzungstechniken zu entscheiden.
4). Verwenden Sie das Kanban Board , um den Fortschritt von Tickets/Vorfällen zu verfolgen.
5). Tägliche Stand-up-Meetings würden helfen, kleinere oder dringende Engpässe zu lösen, während die retrospektive Analyse dazu beitragen würde, den Prozess schrittweise zu verbessern.
6). Zu viel Fokus auf den Prozess kann manchmal auch zu Engpässen führen, da Sie dazu neigen, die Flexibilität und Agilität zu verlieren. Ich empfehle, flexibel genug zu sein, um Änderungen im Sprint zu berücksichtigen, solange niemand (außer dem Prozess) verletzt wird.
Kurz gesagt, es stehen viele wunderbare Tools, Techniken und Prozesse zur Verfügung. Sie möchten nur diejenigen auswählen, die Ihnen und Ihrem Unternehmen wirklich helfen würden.
Beste, Nitesh
MCW