Wie wenden Sie Scrum bei der Wartung und Verbesserung von Legacy-Code an?

Question

Wie der Titel schon sagt... Wie kann ich einen Scrum-Prozess auf alles anwenden, was nicht mit neuem Code arbeitet und bis zu einem gewissen Grad geschätzt werden kann?

Wie kann ich einen Scrum-Prozess auf Wartungs- und Notfallbehebungen (die zwischen 5 Minuten und 2 Wochen dauern können) in einer Umgebung anwenden, in der ich immer noch planen möchte, was zu tun ist?

Grundsätzlich stellt sich die Frage, wie ich ungeplante und schwer einschätzbare Aufgaben mit dem Scrum-Prozess bewältigen kann, oder wende ich einfach den falschen Prozess für diese Umgebung an?

Answer 1

Grundsätzlich stellt sich die Frage, wie ich ungeplante und schwer einschätzbare Aufgaben mit dem Scrum-Prozess bewältigen kann, oder wende ich einfach den falschen Prozess für diese Umgebung an?

Sie verwenden das falsche Verfahren für diese Umgebung. Was Sie brauchen, ist ein Stack-/Warteschlangenmanagementprozess, der von Ihrem geplanten/geschätzten SCRUM-Entwicklungsprozess getrennt ist.

Der Grund dafür ist einfach und hat zwei Seiten:

1. Wie Sie in Ihrem Beitrag erwähnen, ist es ist es oft sehr schwierig, die Wartungsaufgaben, insbesondere wenn Altsysteme beteiligt sind. Wartungsaufgaben im Allgemeinen und Altsysteme im Besonderen haben eine dazu neigen, 'verschlungene' Probleme oder haben einen langen "Schweif", wo eine scheinbar einfache Lösung eine etwas schwierigere Änderung Änderung einer anderen Komponente erfordert, die wiederum wiederum eine Überholung des Betrieb eines Teilsystems erfordert, was wiederum wiederum... Sie verstehen schon.

2. Oftmals werden bei der Bearbeitung von Wartungsaufgaben, bis zu dem Zeitpunkt, an dem Sie die Schätzung abgeschlossen haben, haben Sie auch die Lösung des Problems abgeschlossen . Dies macht den Prozess der Schätzung als Planungsinstrument überflüssig. Diejenigen, die darauf bestehen, die Schätzung von der Lösung des Problems zu trennen für Instandhaltungsaufgaben bestehen, fügen fügen einfach unnötigen Overhead hinzu.

Einfach ausgedrückt: Sie brauchen ein Warteschlangensystem. Es wird diese Komponenten haben:

• Ein "Pool" von Aufgaben, die bereits die Aufmerksamkeit erfordern. Neu gestellte Aufgaben sollten immer in den Pool, niemals in die Warteschlange.
• Ein Prozess der Auslagerung dieser Aufgaben aus dem Pool und in die Warteschlange. In der Regel ist eine Kombination aus betriebswirtschaftlichem und technischem Wissen erforderlich.
• Eine Warteschlange von Aufgaben, die klar geordnet sind so dass die Entwickler, die für die die Warteschlange zu bedienen, einfach von der Spitze der Warteschlange auswählen können.
• Eine Methode zum Verschieben von Elementen in der Warteschlange (Neupriorisierung). Ermöglicht das "Überspringen der Warteschlange" für kritische/ dringende Sendungen.
• Eine Methode zur Zustellung der erledigten Sendungen, die die Bedienung der Warteschlange nicht unterbricht. Dies ist wichtig, da der Aufwand für die Zustellung von Wartungsarbeiten in der Regel deutlich geringer ist als für Entwicklungsarbeiten. Sie möchten nicht, dass Ihr Wartungsteam einen Tag lang darauf wartet, dass die Build- und Testteams jedes Mal, wenn sie einen Bugfix liefern, ihr OK geben.

Es gibt noch weitere Nuancen bei der Verwaltung von Warteschlangen, aber wenn Sie diese Punkte beherzigen, sind Sie auf dem richtigen Weg.

Answer 2

Wenn Sie so viele Veränderungen in Ihrer Umgebung haben, werden kürzere Iterationen der Schlüssel sein. Ich habe schon von Teams gehört, die tägliche Iterationen durchführen. Sie können auch zu einem Kanban-Stil übergehen, bei dem Sie eine Warteschlange mit einem festen Limit haben (in der Regel sehr niedrig, etwa 2 oder 3 Elemente) und keine weiteren Elemente hinzugefügt werden können, bis diese erledigt sind.

Ich würde es mit einwöchigen Iterationen mit täglichen Stand-ups, Backlog-Priorisierung und "fertig, fertig" versuchen. Dann nach 5 oder 6 Wochen neu bewerten, um zu sehen, was verbessert werden kann. Scheuen Sie sich nicht, den Prozess so auszuprobieren, wie er ist - und scheuen Sie sich nicht, ihn an Ihre Umgebung anzupassen, sobald Sie ihn ausprobiert haben.

Außerdem gab es eine PDF-Datei mit dem Titel Agilität für Support und Betrieb in 5 Minuten die kürzlich auf der Website der Scrum-Entwicklungsliste auf Yahoo!

Answer 3

Niemand hat gesagt, dass es sich bei den Rückständen um neuen Code handeln muss. Wartungsarbeiten, ob Fehlerbehebungen, Erweiterungen oder Datenkorrekturen, können in das Product Backlog aufgenommen, geschätzt und priorisiert werden. Dies ist tatsächlich einer der größten Vorteile von Scrum - keine Diskussionen mehr mit den Benutzern darüber, ob etwas eine Fehlerbehebung oder eine Verbesserung ist.

Bei Waterfall besteht die stillschweigende Übereinkunft, dass Fehler in der Verantwortung der Entwickler liegen. Sie müssen sie irgendwie beheben, ohne die Entwicklung von neuem Code und neuen Funktionen zu beeinträchtigen. Für die Benutzer sind sie also "kostenlos", aber für die Entwickler sind sie eine große Unannehmlichkeit.

In Scrum erkennen Sie, dass jede Arbeit Zeit braucht. Es gibt nichts "umsonst". Also akzeptieren die Entwickler freiwillig, dass etwas ein Fehler ist, aber es kommt trotzdem ins Product Backlog. Dann liegt es am Kunden zu entscheiden, ob die Behebung des Fehlers wichtiger ist als das Hinzufügen neuer Funktionen. Es gibt einige Fehler, mit denen man leben kann.

Answer 4

Wie der Titel schon sagt... Wie kann ich einen Scrum-Prozess auf alles anwenden, was die nicht an neuem Code arbeiten und bis zu einem gewissen Grad abschätzen kann?

Im Gegenteil, ich habe gehört, dass Teams die Einführung von Scrum in der Wartungsphase als einfacher empfinden, weil die Änderungen kleiner sind (keine großen Designänderungen) und daher leichter abzuschätzen sind. Jede neue Änderungsanforderung wird in das Product Backlog aufgenommen, von den Entwicklern geschätzt und dann vom Product Owner priorisiert.

Wie kann ich einen Scrum-Prozess anwenden auf Wartung und Notfallbehebungen (die zwischen 5 Minuten und 2 Wochen dauern können beheben) anwenden, wenn ich trotzdem Dinge planen möchte?

Wenn Sie auf Aktivitäten zur Brandbekämpfung hinweisen, sollten Sie einen Teil der Iterationsarbeitsquote für solche Aktivitäten reservieren. Auf der Grundlage historischer Trends/Aktivitäten sollten Sie z.B. sagen können, dass wir eine Geschwindigkeit von 10 Story Points pro Iteration haben (4-Personen-Team, 5-Tage-Iteration). Jeder von uns verbringt etwa einen Tag pro Woche damit, auf Notfälle zu reagieren. Um realistisch zu sein, sollten wir also für die nächste Iteration nur 8 Punkte aus dem Backlog auswählen. Wenn wir keine dringenden Probleme haben, nehmen wir den nächst höheren Punkt aus dem priorisierten Backlog.
CoryFoy erwähnt in seiner Antwort einen dynamischeren/Echtzeit-Ansatz mit Kanban-Post-its.

Grundsätzlich: Wie überwinde ich ungeplante Aufgaben und Aufgaben, die sehr schwer einschätzbare Aufgaben mit dem Scrum Prozess? oder wende ich einfach die falschen Prozess für diese Umgebung an?

AFAIR Scrum schreibt keine Schätzungstechnik vor. Verwenden Sie die Methode, mit der das Team am besten zurechtkommt: Manntage / Story Points / etc. Der einzige Weg, um besser in der Schätzung zu werden, ist Übung und Erfahrung, glaube ich. Je öfter dieselbe Gruppe von Leuten zusammensitzt, um neue Aufgaben zu schätzen, desto besser werden ihre Schätzungen. In einer Wartungsumgebung würde ich davon ausgehen, dass es einfacher ist, Schätzungen vorzunehmen, weil das System der Gruppe mehr oder weniger gut bekannt ist. Wenn nicht, sollten Sie Spikes einplanen/verwenden, um mehr Klarheit zu schaffen.

Ich spüre, dass Sie hier versuchen, einen Elefanten zu essen Ich würde die folgenden Bissen vorschlagen

• Effizientes Arbeiten mit altem Code
• Agile Schätzung und Planung
• Agile Projektentwicklung mit Scrum

Answer 5

Meiner Meinung nach hängt es davon ab, wie oft Sie eine "echte" Veröffentlichung haben. In unserem speziellen Fall haben wir jedes Jahr eine Hauptversion und einige kleinere Versionen im Laufe des Jahres.

Das bedeutet, dass ein abgeschlossener Sprint nicht sofort auf unserem Produktionsserver bereitgestellt wird. Meistens werden einige Sprints stattfinden, bevor wir unser komplettes "Projekt" fertig haben. Natürlich demonstrieren wir unsere Sprints und stellen sie auf unserem Testserver bereit. Das "Projekt" in seiner Gesamtheit wird einigen End-to-End-Tests unterzogen und schließlich auf unseren Produktionsservern bereitgestellt -> dies ist eine kleinere Version. Wir können entscheiden, dass wir es nicht sofort auf unseren Produktionsservern bereitstellen, wenn es zum Beispiel von anderen Produkten/Projekten abhängt, die zuerst aktualisiert werden müssen. Wir stellen es dann in unserer Hauptversion bereit.

Wenn jedoch Probleme auf unserem Produktionsserver auftreten, kann ein sofortiges Handeln erforderlich sein. Wir haben also keine Zeit, einen Product Owner nach dem Ziel oder der Wichtigkeit zu fragen (wenn wir überhaupt einen haben, um ein Problem zu lösen), weil unsere Kunden dadurch an der Arbeit mit unserer Anwendung gehindert werden. In solch dringenden Fällen werden diese Art von Problemen nicht in ein Product Backlog oder einen Sprint aufgenommen, sondern sind reine Wartungsaufgaben, die so schnell wie möglich und als einzelnes Element gelöst, getestet und implementiert werden müssen.

Wie kombinieren wir das mit unserem Sprint? Damit sich unsere Teammitglieder auf den Sprint konzentrieren können, entscheiden wir uns für ein "Opt-in - Opt-out" unserer Teammitglieder. Das bedeutet, dass eine oder mehrere Personen für einen bestimmten Sprint nicht Teil des Teams sind und sich auf andere Aufgaben wie diese dringenden Korrekturen konzentrieren können. Im nächsten Sprint ist diese Person wieder Teil des Teams und jemand anderes ist für die Notrufe zuständig.

Eine andere Möglichkeit wäre, dass wir etwa 20 % der Zeit in einem Sprint für "ungeplante Aufgaben" vorsehen, aber das würde einen falschen Eindruck von der Menge an Arbeit vermitteln, die wir in einem Sprint erledigen können (wir werden nicht in jedem Sprint die gleiche Menge an dringenden Korrekturen haben). Außerdem wollen wir, dass sich unsere Teammitglieder auf den Sprint konzentrieren, und die Erledigung dieser dringenden Korrekturen in einem Sprint wird unsere Teammitglieder ablenken. Ein 'Kontextwechsel' bedeutet auch Zeitverlust, und das versuchen wir zu vermeiden.

Es hängt alles von Ihrer "Umgebung" ab und davon, wie schnell dringende Probleme behoben werden sollen.