Scrum für (eine Art) Application Support Team?

Wenn Sie sagen "Dieses Team funktioniert nicht richtig", befürchte ich, dass Sie die genaue Ursache des Problems nicht identifiziert haben. Liegt es daran, dass die Teammitglieder Probleme beim Multitasking zwischen User Stories und Fehlern haben? Liegt es daran, dass ihr Vorgesetzter nicht oft genug die richtigen Prioritäten setzt? Gibt es explizite Richtlinien, wie sie ihre tägliche Arbeit auswählen sollen? Verstehen sie die Auswirkungen, wenn sie nicht genügend Wertnachfrage (Benutzergeschichten oder neue Funktionen) bedienen, während sie ihre ganze Zeit mit der Fehlernachfrage (Defekte) verbringen?

Ein weiterer Aspekt ist: Warum gibt es überhaupt so viele Mängel? Welche Engineering-Praktiken und Automatisierung müssen eingeführt werden, um die Gesamtzahl der Fehler zu reduzieren und die Codequalität zu verbessern? Wenn Sie keine testgetriebene Entwicklung durchführen und auf der Automatisierung aller Testfälle, einschließlich aller gefundenen Fehler, bestehen, müssen Sie dies vielleicht zuerst implementieren.

Dies sind einige allgemeine Probleme, die angegangen werden müssen, damit das Team richtig arbeiten kann.

Ich bin Mitbegründer eines Softwareunternehmens – und in den letzten 15 Jahren haben wir verschiedene Ansätze ausprobiert, um Teams motiviert zu halten, die Verantwortung für ihre Produkte zu übernehmen und auf einer konsistent vorhersehbaren Basis zu liefern – sowohl in Bezug auf den Zeitplan als auch auf die Qualität. Wir glauben, dass es nicht nur nicht fair ist, ein Team nur an Fehlern arbeiten zu lassen, während ein anderes Team an all den neuen, coolen Sachen arbeitet, es ist auch schlechte Management-/Engineering-Praxis. Ein Team muss das Produkt besitzen (oder einen Teil davon, je nach Gesamtgröße) und vollständig daran arbeiten – sowohl neue Funktionen als auch Fehler. Dadurch erhalten sie das volle Eigentum an dem Produkt – und sie schwimmen oder gehen mit ihm unter. Es gibt ihnen viel bessere Kenntnisse über den Code, um zu verstehen, warum und wo Fehler auftreten und was sie verursachen könnte. Und gut geführt,

Anstatt zu versuchen, „Kanban oder Scrum?“ zu entscheiden, würde ich tatsächlich empfehlen, dass Sie Kanban zusätzlich zu Ihren aktuellen Scrum-Praktiken anwenden. Das ist die grundlegende Definition von Kanban. Es ist kein Ersatz für Scrum, sondern eine Möglichkeit, fast jeden Prozess zu verbessern, den Sie möglicherweise verwenden. Im Fall von Scrum nennen viele Leute die resultierende Mischung Scrumban. Wenden Sie es auf Ihre aktuellen Prozesse an, um Engpässe und Probleme zu identifizieren und diese Probleme zu lösen.

Nur um unseren Ansatz zu teilen, wir haben eine etwas ähnliche Situation wie Ihre. Wir haben 3 verschiedene Produkte, und wir haben Produktteams, die jedes besitzen und die ganze Arbeit – neue Funktionen und Fehlerbehebungen – für ihre Produkte erledigen. Wir sind kein Scrum-Shop, aber wir haben ein ziemlich genau definiertes Zeitfenster von 4-5 Wochen, in dem wir neue Releases erstellen. Wir verwenden unser eigenes Produkt , um unsere Roadmap und Entwicklungsarbeit zu verwalten. Die Roadmap wird in einem 'vorgelagerten' Kanban-Board verwaltet, wo wir unsere Themen --> Epics --> User-Story-Aufschlüsselung durchführen und dann die User-Storys an das "nachgelagerte" Dev-Board übertragen. Alle Fehler, die entweder vom Support/Kunden gemeldet ODER intern bei Codeüberprüfungen, Automatisierungsläufen oder manueller Validierung gefunden wurden, werden direkt in der Spalte „Bereit“ des Dev-Boards protokolliert.

Wenn Teammitglieder das beenden, woran sie gerade arbeiten (Kanban rät von Multitasking ab), holen sie neue Arbeit aus der Warteschlange „Bereit“ basierend auf der Priorität, die jeden Tag im Daily Standup besprochen wird. Natürlich haben kritische oder hochpriore Fehler Vorrang vor allem anderen. Wir versuchen jedoch sicherzustellen, dass auch immer eine gute Mischung aus neuen Funktionen vorhanden ist, an denen gearbeitet wird.

Wir versuchen, ein Gleichgewicht zwischen einem vorhersehbaren Veröffentlichungszeitplan und der Gesamtchargengröße zu finden, um die Dinge überschaubar zu halten. Alle neuen Funktionen und Fehlerbehebungen werden kontinuierlich auf einem internen Staging-Server bereitgestellt – und das ist unser „interner Produktionsserver“, auf dem wir alle unsere anderen Funktionen ausführen, einschließlich Support und Marketing usw. – was eine großartige Möglichkeit ist, eventuelle Fehler zu identifizieren Slip-Thru (fast null) und alle Usability-Probleme. Und wie gesagt, wir stellen alle 4-5 Wochen ein SaaS-Release bereit, wobei alle Arbeiten in dieser Zeit vollständig abgeschlossen sind.

Ich würde Ihnen empfehlen, dies auszuprobieren, um Ihre Gesamtsituation zu analysieren und Kanban effektiv zu nutzen, um alle Ihre Prozessengpässe für eine schrittweise Gesamtverbesserung Ihres Betriebs zu entdecken. Es wäre großartig für die Moral und Produktivität Ihres Teams. Es könnte bedeuten, Folgendes zu tun -

1. Studieren Sie das allgemeine Anforderungsmuster in Ihrem Team und entscheiden Sie, ob Sie mit einem Dev-Board arbeiten oder auch ein Upstream-Board verwenden, um die eingehende Arbeit besser mit Ihren Stakeholdern zu bewältigen.
2. Definieren Sie einen Workflow, der die Arbeitsweise Ihres Teams widerspiegelt, und ordnen Sie alle Schritte im Wertstrom zu, damit Sie vollständig untersuchen können, welche davon Engpässe sein könnten und warum Ihr Team so viel Zeit mit Fehlern verbringt. Kanbans Flow-Effizienz-Metrik zeigt, wie viele Wartezeiten in all unseren Arbeitsabläufen eingebaut sind – ob zwischen Übergaben oder Warten auf externe Eingaben oder ähnliche Probleme!
3. Definieren von WIP-Limits in Ihrer Ready-Warteschlange für verschiedene Arten von Arbeit (User Stories vs. Defects), sodass immer eine bestimmte Kapazität für neue Funktionen reserviert ist.
4. Sehen Sie sich Ihre Entwicklungsprozesse und Automatisierungsoptionen an, um die Fehlerquote insgesamt zu reduzieren.

Dies sind nur Ansatzpunkte – Sie haben natürlich ein viel detaillierteres Bild Ihrer Situation! Wenn das Team beginnt, seinen Prozess regelmäßig zu analysieren, ergeben sich verschiedene Lösungen, die Sie ausprobieren müssen.

Ich hoffe das hilft; alles Gute!

Es gibt einige Vorteile von Teams, die zusätzlich zur Produktentwicklung an der Produktionsunterstützung arbeiten, sowie Vorteile durch die Trennung von Verantwortlichkeiten.

Fall für ein Team, das beides tut

Im Mittelpunkt steht dabei die Idee der Eigenverantwortung des Teams. Wenn ein Team gebeten wird, Probleme der Produktionsunterstützung in dem von ihm erstellten Code zu behandeln, fördert dies ein höheres Qualitätsniveau. Darüber hinaus ist dieses Team theoretisch am besten qualifiziert, um das Supportproblem schnell zu lösen, was weniger Ausfallzeiten für den Kunden bedeutet.

Fall für die Trennung der Verantwortlichkeiten

Indem wir die Anwendungsentwicklungsarbeit durch den Produktionssupport unterbrechen lassen, schaffen wir das, was Lean Mura nennen würde – eine Form der Verschwendung. Dies liegt daran, dass sie in ihrem Prozess Pufferzeit schaffen müssen, um Platz für Unterbrechungen und Overhead bei der Verwaltung und dem Kontextwechsel zu schaffen.

Persönliche Meinung

In den meisten Fällen würde ich auf die Seite besserer Qualität und schnellerer Korrekturen statt der Prozesseffizienz fallen. Die Wertschöpfung bei Ersterem ist in der Regel größer als die Kosteneinsparungen bei Letzterem. Sie kennen Ihre Umstände jedoch am besten.

Wenn Sie das Bugfixing von der Entwicklung trennen, stellt sich die Frage: Wird es immer genau die richtige Arbeitsverteilung für beide Teams geben?

Was passiert, wenn es eine Zeit lang keine Fehler gibt? Wird das Team Idol sitzen? Wie wäre es, wenn es wirklich kritische Projektarbeiten gibt und das Entwicklungsteam Vollgas gibt, während das Bugfix-Team auf Hochtouren läuft?

Meine persönliche Meinung ist, dass man sich besser an den gemischten Rückstand hält.

Ein Ansatz, den ich in dieser Situation gesehen habe, besteht darin, in jedem Sprint ein oder zwei Scrum-Teammitglieder als „an Ort und Stelle“ für die Fehlerbehebung zu ernennen. Das bedeutet, dass sie niedrigere Priorität und kleinere Entwicklungsaufgaben erhalten, an denen sie arbeiten müssen, damit sie leicht zur Behebung eines kritischen Fehlers wechseln können. Rotieren Sie, wer in dieser Punktrolle ist (z. B. bei jedem Sprint oder alle paar Sprints).

Es lohnt sich auch zu überlegen, wie schnell Sie dringende Fehler beheben müssen. Wenn sie eine Woche warten können, warum nicht zu einem einwöchigen Sprintzyklus wechseln? Auf diese Weise können Sie die gesamte Arbeit im Sprint-Planning abdecken.