Ich arbeite in einer Softwareentwicklungsfirma, wo wir etwas verwenden, das Scrum ähnelt.
Wir stoßen auf das Problem, dass wir, wenn wir an unseren Entwicklungen arbeiten und die Fehler kommen, unsere Entwicklungsarbeit einstellen und uns auf das Debuggen konzentrieren müssen. Wenn die Höchstwerte erreicht sind, veröffentlichen wir unsere Software nicht mehr und müssen zuerst Fehler beheben, bevor wir neue Builds für unsere Kunden erstellen.
Das alles scheint vollkommen vernünftig, da wir nur halbjährlich veröffentlichen und wir Kunden haben, die darauf warten, dass die Fehler behoben werden.
Dies führt jedoch dazu, dass wir manchmal nicht die Zeit finden, an unseren Entwicklungen zu arbeiten, weil wir manchmal wochenlang debuggen müssen.
Wie können wir Fehler richtig planen? Ein paar Dinge, über die ich nachgedacht habe, aber ich bin neugierig, was Ihre Meinung ist
Es gibt mehrere Möglichkeiten, dies anzugehen, ich habe die meisten ausprobiert, und keine davon ist ideal, nur weil Sie es mit dem zu tun haben, was Scrum "ungeplante Arbeit" nennt.
Eines der wichtigsten Dinge ist meiner Erfahrung nach, ein gutes Bug-Triage-System zu haben. Wenn ein Fehler gemeldet wird, sollte jemand auf der Grundlage einer unternehmensweit bekannten Richtlinie eine fundierte Entscheidung darüber treffen, wie schwerwiegend der Fehler ist und ob er sofort behoben werden muss oder auf den nächsten Sprint verschoben werden kann. Dinge, die Sie hier berücksichtigen sollten, sind die Reproduktionsrate, der Prozentsatz der betroffenen Benutzerbasis, das Risiko einer Datenbeschädigung usw.
Sobald Sie wissen, wie schwerwiegend Ihr Fehler ist, können Sie entscheiden, was Sie damit tun und wie Sie damit umgehen. Wenn der Schweregrad hoch genug ist, um es in den Sprint zu ziehen, behandeln Sie es als ungeplante Arbeit mit der höchsten Priorität im Sprint Backlog.
Wie Sie mit ungeplanter Arbeit umgehen, ist etwas völlig anderes; Es gibt mehrere Möglichkeiten, dies zu tun. Unten sind die beiden Techniken, die ich in der Vergangenheit verwendet habe; beide funktionieren gleich gut, sind aber nicht für alle Teams geeignet.
Verwenden Sie eine „Überholspur“ . Alle Fehler, die im Sprint Backlog auftauchen und sofortige Aufmerksamkeit erfordern, werden auf die „Überholspur“ gesetzt und müssen behoben werden, bevor mit anderen neuen Arbeiten begonnen wird. Die Überholspur ist eine separate „Schwimmspur“ oder „Beschleunigungsspur“, die über allen anderen Schwimmspuren steht.
Verwenden Sie ein "Flaggenteam", wenn Ihr Team groß genug ist. Führen Sie ein Rotationssystem im Team ein, bei dem bei jedem Sprint ein oder zwei Personen das „Swat-Team“ bilden, das sich sofort um jede ungeplante Arbeit kümmert, die im Sprint auftaucht. Die geringere Verfügbarkeit dieser Entwickler sollte in der Teamgeschwindigkeit für den Sprint berücksichtigt werden. Im Allgemeinen möchten Sie, dass das Swat-Team an Sprint-Geschichten mit niedrigerer Priorität arbeitet, da sie jederzeit von den Aufgaben abgezogen werden können. Das funktioniert natürlich nur in ausreichend großen Teams.
Wir verwenden etwas, das Scrum ähnelt
Mein Vorschlag an Sie wäre, sich Scrum anzunähern, indem Sie am Ende jedes Sprints nach einem potenziell auslieferbaren Inkrement suchen.
Beachten Sie, dass das Schlüsselwort für Sie hier „potenziell“ ist. Sie können immer noch alle sechs Monate veröffentlichen, wenn Ihr Product Owner dies möchte, aber Sie sollten dennoch darauf abzielen, in jedem Sprint etwas bereit zu haben, das ausgeliefert werden kann.
Dazu müssen Sie daran denken, dass Funktionen nur ausgeführt werden, wenn sie fehlerfrei sind. Die Arbeit, die Sie in jedem Sprint auf sich nehmen, ist die Kapazität Ihres Teams, um neue Arbeit zu entwickeln und alle Fehler zu korrigieren, die durch die neue Entwicklung aufgeworfen werden.
Auf diese Weise zu arbeiten erleichtert die Planung, da Ihr Team sich seiner tatsächlichen Leistungsfähigkeit bewusst wird.
Es ist auch von großem Vorteil, die Wahrscheinlichkeit zu verringern, dass Fehler überhaupt auftreten, indem technische Techniken wie automatisierte Regressionstests, kontinuierliche Integration und verhaltensgesteuerte Entwicklung (BDD) verwendet werden.
Es gibt mehrere Möglichkeiten, wie Sie mit Fehlern umgehen können. Aber unabhängig von Ihrer Fehlerrichtlinie gibt es eine Sache, die Sie wirklich tun sollten.
Wenn Ihre Entwickler einen erheblichen Teil ihrer Zeit mit der Behebung von Fehlern verbringen, sollten Sie der Suche nach der Ursache dieser Fehler und der Möglichkeit (auf technischer Ebene oder auf Prozessebene) zur Vermeidung dieser Fehler hohe Priorität einräumen Arten von Fehlern in der Zukunft.
Wenn Ihre Kunden beispielsweise die neuen Funktionen erst sehen, wenn Sie sie veröffentlichen, und sich dann darüber beschweren, dass diese Funktionen nicht so funktionieren, wie sie es erwartet haben, sollten Sie nach Möglichkeiten suchen, wie Sie diese Kunden früher in die Validierung der neuen Funktionen einbeziehen können .
Was die Fehlerrichtlinien betrifft, so sind die beiden wichtigsten, die ich kenne
„Null Fehler“: Jeder Fehler ist einer zu viel und sollte vorrangig behoben werden, anstatt neue Entwicklungen aufzugreifen. Dies erfordert einen robusten Klassifizierungsprozess, um zu vermeiden, dass Änderungen an korrekt funktionierenden Funktionen als Fehler klassifiziert werden. Wenn viele Fehler gemeldet werden, kann dies bedeuten, dass für längere Zeit keine neue Entwicklung durchgeführt wird.
Bugs zusammen mit Neuentwicklungen priorisieren: Für jedes Workitem wird die Priorität in Bezug auf die andere Arbeit bestimmt, unabhängig davon, ob es sich bei dem Workitem um einen Bug oder eine Neuentwicklung handelt. Während der Planung werden die Top-N-Elemente in den Sprint aufgenommen, wobei N von der Kapazität des Teams abhängt. Zumindest für Planungszwecke ist es hilfreich, einen Hinweis zu haben, wie viel Aufwand in die Lösung jedes Fehlers gesteckt werden würde.
Mir persönlich gefällt der zweite Ansatz, weil er dem Product Owner die Möglichkeit gibt, von Fall zu Fall zu entscheiden, ob das stark nachgefragte neue Feature wichtiger ist, als den Fehler zu beheben, den kaum jemand bemerkt.
Während Sie das Problem lösen, wie Sie Zeit für Fehler zuordnen können, sollten Sie auch nach Wegen suchen, wie Sie die Anzahl der gefundenen Fehler reduzieren können. Sie können sie möglicherweise früher im Prozess abfangen, was später zu weniger Nacharbeit führt.
Es gibt eine Reihe von Methoden/Werkzeugen, die dabei helfen: Peer-Programmierung; Codeüberprüfungen; statische Code-Analyse-Tools; automatisiertes Testen; Sicherstellen, dass User Stories gute Akzeptanzkriterien haben, die zwischen Product Owner, Tester und Entwickler vereinbart wurden, bevor die Arbeit beginnt; Enge Kommunikation zwischen Testern und Entwicklern zu Beginn des Entwicklungsprozesses.
Viel Glück
Das Hauptproblem, das ich sehe, ist, dass Sie alle 6 Monate veröffentlichen, was zu selten ist. Es gibt einen Grund, warum Scrum maximal 4 Wochen pro Sprint vorschreibt. Denn am Ende der 4 Wochen muss das Inkrement potenziell lösbar sein. Sie müssen es nicht tun, aber es muss in diesem Zustand sein.
Da der Veröffentlichungszyklus zu lang ist, melden Ihre Kunden ihre Probleme als Fehler, die Sie vor der neuen Version beheben müssen. Sie können sie nicht davon überzeugen, auf die Veröffentlichung zu warten, da dies 6 Monate dauert, was eindeutig zu lange ist.
Was sollten Sie als Unternehmen tun?
Sie sollten eine Sprintlänge wählen, die Ihre Kunden akzeptieren, um die Fehler behoben zu bekommen. Offensichtlich wird es einige kritische Fehler geben, die so schnell wie möglich behoben werden müssen. Weisen Sie diesen 10 % des Sprints zu. Denken Sie daran, dass es sich um eine Teammetrik handelt.
Die restlichen Bugs gehen in das Product Backlog und werden zusammen mit den Features, die Sie entwickeln, priorisiert.
Nehmen wir an, Sie tun dies und starten einen neuen Sprint mit einigen Funktionen und Fehlern darin. Jetzt haben Sie drei Arten von Fehlern:
Am Ende des Sprints liefern Sie eine neue Version mit:
Der Kunde kann dies akzeptieren, da es vernünftig ist, 2-4 Wochen auf einige kleinere Fehler zu warten, während die kritischen Fehler so schnell wie möglich behoben werden.
Wenn nun 10 % der Sprintlänge nicht ausreichen, dann haben Sie technische Schulden. Sie können auf 15 % oder maximal 20 % erhöhen.
Sie müssen diese Fehler antizipieren. Sie müssen einen Teil Ihres Codes umgestalten oder wiederholen, wenn Sie wissen, dass er kritische Fehler enthält, die Ihr Kunde entdecken wird. Erstellen Sie einige Einträge im Product Backlog, um diese Fehler zu antizipieren, und überzeugen Sie Ihren Product Owner davon, ihnen eine hohe Priorität einzuräumen. Antizipieren Sie die Fehler Ihrer Kunden und Sie haben eine bessere Sprint-Planung und ein besseres Zeitmanagement.
Schließlich haben Sie vielleicht einen Kunden, der behauptet, dass jeder Fehler kritisch ist. Wenn Sie es erhalten, schauen Sie es sich an. Wenn es nicht kritisch ist (z. B. eine Schaltfläche in der Benutzeroberfläche, die nie funktioniert hat), bitten Sie den Product Owner, mit dem Kunden zu diskutieren, oder tun Sie es selbst, wenn Sie die Nachricht übermitteln können.
Versetzen Sie sich bei der Bewertung der Priorität/Kritik in die Lage des Kunden. Es mag ein kleiner technischer Fehler sein, aber wenn der Kunde damit Geld verliert, dann hat er hohe Priorität. Wie hoch? Fragen Sie den Product Owner.
Wenn Sie 10 % Ihrer Zeit für die Behebung kritischer Fehler aufwenden und tatsächlich mehr davon verwenden, sollte Ihr Product Owner entscheiden, welche der Sprint-Backlog-Elemente nicht geliefert werden sollen. Es ist ganz einfach: Du steckst etwas hinein, nimmst etwas heraus.
João Silva