Ich beabsichtige, Sprints in meinem Unternehmen einzuführen, wofür ich selbst ziemlich neu bin. Ich bin mir nicht sicher, ob es für meine aktuelle Situation geeignet ist, wir haben mehrere laufende Projekte, alle von ihnen sind ERP-groß und die meisten von ihnen, würde ich sagen, stehen kurz vor dem Abschluss (lieferbereit).
Während dieser Zeit gibt es jedoch einige Kunden, denen wir keine andere Wahl haben, als sie als Prioritäten zu setzen, damit Fehler vorhanden sind. Wenn sie also Probleme mit dem System entdecken, werden sie uns kontaktieren und wir werden das Team haben, um es so schnell wie möglich zu lösen . Im Moment ist dies die gängige Praxis. Wenn Agilität eingeführt wird und wir beginnen, Sprint zu verwenden, was kann dann für spontane / dringende / aufdringliche Kunden getan werden, die fast sofortige Aufmerksamkeit erfordern.
Das Problem ist, dass es dem Unternehmen an Arbeitskräften mangelt, insgesamt nur 3 Entwickler und es gibt keine engagierten Tester, daher werden bis heute immer Fehler herumliegen und Kunden werden immer wieder zurückkommen. Ich verstehe, dass nach dem Start eines Sprints keine Änderungen mehr daran vorgenommen werden sollten.
Irgendwelche Ratschläge?
Es gibt verschiedene Möglichkeiten, dem entgegenzuwirken:
Zero-Bug-Policy Wenn Sie Ihren Sprint nur mit neuen Features planen, aber eine Zero-Bug-Policy beibehalten , sinkt Ihre Velocity . Irgendwann werden Sie wissen, wie viele Geschichten das Team erledigen kann, während es zuerst alle offenen und neuen Fehler behebt. Verstehen Sie das Wetter von gestern und planen Sie entsprechend.
Platzhalter PBI Fügen Sie jedem Sprint eine Story hinzu, die als Platzhalter für alle eingehenden Fehler gilt. Sie reservieren einen festen Teil des Sprints, um Wartungsarbeiten zu erledigen. Wenn es viel mehr Zeit in Anspruch nimmt, brechen Sie den Sprint ab und starten Sie einen neuen.
Weisen Sie einen Batman zu : Lesen Sie diese Antwort auf eine andere Frage für Details :)
Kürzere Sprints Wenn Sie einwöchige Sprints haben und Fehler immer in den Rückstand aufnehmen, muss ein Kunde höchstens zwei Wochen auf eine Behebung warten.
Kanban Verwenden Sie Kanban anstelle von Sprints und konzentrieren Sie sich darauf, mit der Arbeit zu beginnen, beginnen Sie mit der Bearbeitung von Fehlern mit hoher Priorität, wenn Sie neue Arbeit aufnehmen. Verwenden Sie INVEST , um Ihre Aufgaben klein zu halten, damit Sie die Arbeit in kleinen Schritten erledigen können. Geben Sie alle erledigten Arbeiten zu einem festgelegten Datum frei oder geben Sie sie frei, wenn Sie einen bestimmten Punkt in Ihrem Backlog erreichen.
Für Wartungsteams würde ich Kanban bevorzugen, ansonsten die Zero-Bug-Variante verwenden, um eine realistische Sicht darauf zu bekommen, wie viel neue Arbeit ein Team erledigen kann.
Denken Sie daran, dass Entwickler sich auf ihre aktuelle Aufgabe konzentrieren sollen. Finden Sie einen Weg, um zu verhindern, dass sie während der eigentlichen Arbeit mit eingehenden Fehlern abgehört werden. Ein tägliches Stand-up wäre eine gute Gelegenheit, um neu eingehende Arbeiten zu besprechen und bei Bedarf einen Sprint neu zu arrangieren.
Dies kann durch einige unternehmerische Kanban- und eine normale Scrum-Bereitstellungsteammethode aktiv verwaltet werden. Einige Agile-Coaches kämpfen mit dem Konzept, dass ein einzelnes Scrum-Team die geschäftliche Veränderung aus einem Portfolio von Programmen mit mehreren Projekten, alle mit eigenem „ Backlog “, durchführen kann. Manchmal müssen agile Methoden unabhängig von den Richtlinien angepasst werden. Ich schlage demütig die folgende Lösung vor.
Es klingt für mich so, als würden Sie in einem Business Intelligence Center/Rolle arbeiten – liege ich falsch?
Teilen Sie Ihren Sprint in zwei separate Komponenten auf.
Entscheiden Sie, wie viel von Ihrem Sprint Sie bereit sind, für BAU-Arbeit zu opfern. Um Ihre Präsentation zu fokussieren, schlage ich vor, das Mantra zu verwenden
"Menschen müssen gezwungen werden, Entscheidungen zu treffen."
Sie können einfach keine neuen Änderungen vornehmen, wenn die Geschäftsbeteiligten ständig möchten, dass die Funktionalität im alten System repariert wird. Zwingen Sie die Leute, Änderungen vorzunehmen.
Für dieses Beispiel schlage ich vor, 20 % Ihrer vierzehntägigen Sprint-Kapazität als BAU-Arbeit zu widmen.
Berechnen Sie Ihre Arbeitskapazität pro Sprint in Stunden.
Für dieses Beispiel verwenden wir 3 x Vollzeitressourcen, die 7 Stunden pro Tag für 8 Tage pro Sprint codieren. Ein ganzer Tag ist der Planung und ein ganzer Tag den Rückblicken und Rückblicken gewidmet.
Das ergibt eine ungefähre Kapazität für 21 Arbeitsstunden * 8 Tage = 168 Stunden Arbeitskapazität.
Erstellen Sie einen Stapel Benutzerkarten in einer separaten Farbe für das Kanban-Board. Das sind Ihre BAU-Karten. Geben Sie jeder dieser Karten einen ungefähren Stundenwert von 34 und legen Sie sie auf den Tafelrohling. Zum Beispiel: 1,1,1,1,1,2,2,2,2,3,3,5,10
Nutzen Sie die Karten, um Ihr BAU-Budget einzuhalten. Alle Aufgaben, die in das Team kommen, erhalten eine grobe Planungsschätzung in Stunden und die entsprechenden Karten werden dann verwendet, um die Aufgabe zu verfolgen.
Wenn Ihnen für diesen Sprint die Karten ausgehen, wissen Sie, dass Sie Ihre BAU-Kapazität erschöpft haben.
Bericht über die BAU-Workstreams als separater Lieferbericht, der die Anzahl der für BAU-Aufgaben geplanten und durchgeführten Stunden einschließlich der Art der Aufgaben und des ROI der abgeschlossenen Arbeit nachverfolgt.
Bei der Scrum-Implementierung haben Sie eine Reihe von Stories mit zugehörigen Aufgaben, die Sie innerhalb eines festen Zeitrahmens von ca. 2-3 Wochen. Wenn sich nun etwas Neues ergibt, an dem das Team arbeiten kann, sollte es für den nächsten Sprint priorisiert werden (vorausgesetzt, es kann bis zu diesem Zeitpunkt warten). Sonst muss jemand prioritär darüber sprechen und ob das Team innerhalb der aktuellen Stories an dem neuen Stück arbeiten soll. Ein Stakeholder (PM) könnte eine Leasinggeber-Prioritätsgeschichte für den nächsten Sprint verschieben, wenn dies möglich ist. Andernfalls sollten alle Geschichten innerhalb des vereinbarten Zeitrahmens fertiggestellt werden.
Alternativ könnten Sie einen Support-Prozess zwischen der Entwicklung und den Kunden einrichten (da es sich nicht um Tausende handelt) und einen Teil der Zeit des Teams dafür einplanen und diese Aufgaben parallel zu den zugewiesenen geplanten Sprint-Storys bearbeiten.
Dinge können sich innerhalb eines Sprints ändern, wenn es einen guten Grund dafür gibt. Bei Agile dreht sich alles um Wertlieferung. Wenn Sie sinnvolle Änderungen innerhalb eines Sprints verhindern, um die Scrum-Richtlinien strikt zu befolgen, sind Sie bei Ihrer Implementierung von Scrum nicht mehr agil und verringern den Wert, den ein Kunde aus Ihren Dienstleistungen zieht, weil er einem Prozess blind folgt.
Die Scrum-Richtlinie zur Verhinderung von Story-/Prioritäts-/Defect-Commitment-Änderungen innerhalb des Sprints dient dazu, das Team vor den meisten Änderungen zu schützen, bei denen es sich um unnötige Änderungen handelt, die durch reflexartige Reaktionen, das Syndrom der lautesten Person im Raum und schlechte Iterationsplanungspraktiken eingeführt werden .
Wenn innerhalb einer Iteration ein Fehler mit hoher Priorität (P0 oder P1) auftritt, ist es völlig akzeptabel, die Story-Arbeit aufzuschieben, wenn die Behebung für den Kunden wertvoller ist als die aufgeschobene Arbeit. Sie sollten immer die Auswirkungen des Aufschiebens von zugesagter Arbeit kommunizieren, um eine neue Priorität anzugehen. Sie haben den PO während des gesamten Iterationszyklus im Scrum-Team, um dem Team zu helfen, sich kontinuierlich an sich ändernde Prioritäten anzupassen und mit externen Stakeholdern zu kommunizieren, wenn Änderungen auftreten. Viele Teams erstellen SLAs um ihre Fehler herum, um automatisch den Zeitrahmen vorzugeben, in dem ein bestimmter Fehlertyp behoben werden sollte, unabhängig davon, wo sich das Team in der Iteration befindet.
PaulDonny
Alex Leonow
Venture2099