Wer sollte Fehler in einer Scrum/Agile-Umgebung beheben?

Question

Wer sollte Ihrer Meinung nach einen Fehler beheben? Ein Programmierer, oder? Okay, aber wirklich, wer ... lass es mich erklären.

Ich bin ein Scrum Master über eine Reihe von Scrum-Projekten. Scrum sagt: "Schalte deine Ressourcen ein, wo es möglich ist", ein Gefühl, dem ich von ganzem Herzen zustimme.

Im Allgemeinen integrieren wir ein gewisses Alter jedes Sprints, um Fehler von den vorherigen Sprints zu beheben - alles gut und gut.

Nach jedem Sprint wir Demo und Restrospektive zu unseren Kunden, und fördern unseren Entwicklungscode zu einer UAT-Umgebung (unser Kunde möchte in der Regel nicht ein kleines bisschen von seinem Projekt zu leben, aber das liegt an ihnen - wir Wir behalten unsere Seite, indem wir sicherstellen, dass wir funktionierenden und testbaren Code bereitstellen.

Sobald alle Sprints abgeschlossen sind, haben wir eine UAT-Phase, in der der Client einen gründlichen Test der fertigen Software durchführt, um letzte Fehler zu finden. Im Idealfall wären diese bereits erwischt worden, aber realistisch gesehen gibt es einige, die erst während UAT entdeckt wurden.

Während dieser UAT-Phase werden nicht alle Entwickler für das Projekt in 100% der Zeit benötigt. Daher möchten wir sie für andere Projekte neu zuweisen. Scrum sagt jedoch, "schütze deine Ressourcen wo immer möglich".

Mein Problem ist, ich ordnet Entwickler der UAT-Phase eines Projekts zu, während ich an anderer Stelle ein separates Scrum-Projekt starte. Nicht ideal - im Moment ist dies jedoch eine kommerzielle Realität.

Ich kann entweder:

1) mit ihr leben und haben die Entwickler ihre eigenen Code zu beheben - und einige Zeit zuweisen (etwa 20%) des Entwicklers auf die UAT des früheren Projekt.

2) Stellen Sie sicher, dass eine Übergabe vorhanden ist und dass in 100% der Fälle 1 oder 2 Entwickler für den Fehlerbehebungscode zuständig sind.

Ich mag 1), aber es macht Ressourcenbildung zu einem echten Schmerz in den Arsch.

2) macht mir Angst, ich glaube, Entwickler übernehmen keine Verantwortung für die Qualität ihres eigenen Codes. Ich denke, es gibt eine Menge zu sagen, wenn man sicherstellt, dass die Entwickler den Besitz ihres eigenen Codes übernehmen - und sie zu bitten, ihre eigenen Fehler zu beheben, ist ein guter Weg, die Qualität sicherzustellen. Niemand mag es, Bugs zu beheben, also habe ich festgestellt, dass Entwickler im Allgemeinen versuchen, einen besseren Job zu machen, weil sie wissen, dass sie sowieso auftretende Probleme beheben müssen. 2) ist jedoch einfacher zu planen und zu ressourcenieren. Aber 2) dauert länger, da das Reparieren eines Fehlers in jemandes Code kostspielig in Bezug auf Zeit und Ressource ist. Wenn es sich um ein kompliziertes Update handelt, benötigt es möglicherweise die Hilfe des ursprünglichen Entwicklers, und es wird sicherlich länger dauern, bis es von jemandem repariert wird, der mit diesem Abschnitt der Codebasis nicht so vertraut ist.

Was denken die Leute?

Answer 1

Dies ist ein sehr interessantes Thema, Projektmanagement ist von entscheidender Bedeutung und die angemessene Zuweisung von Ressourcen ist von wesentlicher Bedeutung.

Ein Punkt, den ich ansprechen würde, ist, dass spezielle Bugfixes die Qualität des Codes erhöhen können. Wenn ich Code entwickeln würde, der meinen Namen dagegen hätte, von dem ich wusste, dass andere Leute dafür verantwortlich waren, würde ich alles tun, um sicherzustellen, dass es ein guter Code war.

Vielleicht ist eine Kombination Ansatz erforderlich .. Sie könnten ein paar Entwickler für jedes Projekt - ein anderes Paar für jedes Projekt - und machen sie verantwortlich für die Bug-Fixing-Phase, um diese Verantwortung im Vorfeld zu skizzieren.Auf diese Weise können sie sicherstellen, dass sie im Verlauf des Projekts auf dem neuesten Stand sind und dass sie am Ende übergeben werden. Ihre Ressourcenverteilung ist einfacher und der Client erhält erstklassige Unterstützung.

Nur eine etwas andere Sichtweise.

Prost Nathan

Answer 2

Menschen sollten ihren eigenen Code beheben. Nutzen Sie die Tatsache, dass niemand gerne zurückgeht und alte Sachen repariert, wenn sie neue Sachen schreiben könnten. Wenn der für den Fehler verantwortliche Entwickler identifiziert werden kann, stellen Sie sicher, dass er für die Behebung des Problems verantwortlich ist. Dies wird Entwickler dazu ermutigen, beim ersten Schreiben sauberer Code fleißiger zu sein, da niemand als die Person gesehen werden will, die Dinge reparieren muss, die sie kaputt gemacht haben. Dies gilt auch während der Entwicklung, wenn jemand den aktuellen Build durchbricht.

Update: Nachdem ich das gesagt habe, wäre ich nicht unbedingt dogmatisch darüber. Die Bedürfnisse des Kunden stehen an erster Stelle und wenn die Person, die den Fehler erstellt hat, nicht neu zugewiesen werden kann, müssen Sie den Fix möglicherweise jemand anderem zuweisen.

Answer 3

Ich denke, dass Leute ihren eigenen Code auch reparieren sollten. Warum die ganze Zeit mit Übergaben verschwenden?

Es könnte sich lohnen, UATs zu verwenden, wenn alle Funktionen abgeschlossen sind. So arbeiten die "Tester" mit den "Entwicklern" zusammen und testen die Funktionalität. Die Tester sollten in der Lage sein, die UAT-Kriterien zu durchlaufen.

Wenn es innerhalb der UAT mehr Probleme mit den Stakeholdern gibt, handelt es sich um Änderungsanträge, oder die Abnahmekriterien sind wahrscheinlich mehrdeutig!

Answer 4

Ich denke, Fehler sollten vom ursprünglichen Entwickler behoben werden. Entwickler dazu zu bringen, Bugs in Code zu korrigieren, der von jemand anderem geschrieben wurde, könnte viel mehr Zeit in Anspruch nehmen und außerdem dazu führen, dass sie demotiviert werden, da das Beheben von Bugs nicht sehr aufregend ist.

Answer 5

Ich mag nicht Option 2), weil:

• Es Menschen das Gefühl gibt, dass die Arbeit geleistet wurde, während es nicht (es ist nicht getan hat, gibt es Fehler),
• Ich denke, dass Leute für den Code verantwortlich sein sollten, den sie schrieben, nicht andere,
• Ich denke nicht, dass "Bugfixer" ein Job ist, respektieren Sie Leute nicht, wenn Sie dies tun.

Also Option 1) hat meine Vorliebe (aber bitte aufhören zu reden über Ressourcen und Ressourcen).

schließlich ein kleines Zitat:

Wenn Sie separaten Test haben und beheben Zyklen, sind Sie zu spät zu testen. --M. Poppendieck

Ja, ich weiß, es ist einfacher zu sagen als zu tun ... aber trotzdem hat sie verdammt Recht.

Answer 6

Ich bin ein führender Entwickler in einem Scrum-Team. Die Art, wie wir in meiner Organisation arbeiten, ist folgende:

Vor dem Start eines Sprints wird jedem Entwickler ein Prozentsatz der Produktivität zugewiesen, die er während des Sprints zu haben glaubt.Zum Beispiel wird ein erfahrener Entwickler wahrscheinlich 70-80% seiner gesamten Zeit im Sprint produktiv sein können. Dies gibt Zeit für unerwartete Meetings, Bugfixes. Ich werde gleich zu den Bugfixes kommen. Wir erhalten die Schätzungen für alle abgemeldeten Aufgaben und planen dann die Arbeit der Entwickler.

In den Sprint wird der Entwickler seine geplante Arbeit ausführen und seine eigenen Tests abschließen. Wenn möglich, wird nach Abschluss jedes Arbeitsblocks eine weitere Testphase entweder vom Scrum-Leiter oder vom Produkteigentümer (Projektleiter) durchgeführt, um sicherzustellen, dass es keine besonders offensichtlichen Dinge gibt, die betrachtet werden müssen. Alles, was in dieser Testphase auftaucht, geht direkt an den Entwickler zurück, der es geschrieben hat, um es im Sprint fertigzustellen. Die Art und Weise, wie wir es sehen, ist, dass sich das Team effektiv dazu verpflichtet hat, die Aufgaben, die uns zu Beginn eines Sprints gegeben wurden, zu erledigen, so dass wir sie auf die eine oder andere Weise vervollständigen müssen.

Wenn ein dringender Fehler in das Team kommt und es in dieser Minute richtig gemacht werden muss, dann werden ich und der Scrum-Leiter darüber nachdenken, ob es möglich ist, es ohne die geplante Arbeit auszuführen wie gut wir es tun. I.E. Wenn wir einen halben Tag vor dem Zeitplan sind und die Schätzung für den Fehler einen halben Tag dauert, werden wir es tun, ohne die geplante Arbeit zu ändern. Wenn das nicht möglich ist, gehen wir zurück zum Product Owner, der entscheidet, was aus dem Sprint herauszuholen ist.

Wenn dem Team-Teil während eines Sprints ein nicht dringender Fehler zugewiesen wird, gibt der Product Owner ihm eine Priorität und er bleibt in unserem Pot. Wenn der Product Owner dann mit unseren nächsten Zielen konfrontiert wird, wird er die Bugs priorisieren und das Projekt zusammenarbeiten, und diese werden unsere geplanten Elemente für den nächsten Sprint.

Die Sache zu beachten ist, dass es egal ist, von welchem ​​Projekt der Fehler kam. Alles hat eine Priorität und das muss man verwalten. Schließlich haben Sie nur eine bestimmte Entwicklungsressource. Wenn es darum geht, welcher Entwickler das macht, hängt das von mehreren Dingen ab. Sie wissen nicht immer genau, wessen Code den Fehler eingeführt hat. Vor allem, wenn es sich um ein sehr altes Projekt handelt. Wenn derselbe Entwickler es reparieren kann, gibt es offensichtlich einen Zeitvorteil, aber dieser genaue Entwickler ist möglicherweise nicht verfügbar. Die Art, wie wir es versuchen und arbeiten, ist, dass jeder Entwickler in der Lage sein sollte, an einer bestimmten Aufgabe zu arbeiten. In der realen Welt ist das nicht immer möglich, aber das ist immer unser Endziel.

Ich weiß, dass ich um den heißen Brei hier aber in der Antwort auf Ihre Frage zu schlagen haben, die kurz den Bug fix tun sollte dieses ist, was ich würde sagen:

• Wenn der Fehler während der identifiziert Derselbe Sprint, mit dem die Arbeit gemacht wurde, sendet sie dann an den ursprünglichen Entwickler zurück.
• Wenn es dringend ist dann muss es an die beste Person gehen, um die Aufgabe zu erledigen, weil es so schnell wie möglich erledigt werden muss. Das könnte nicht die Person sein, die den Code ursprünglich geschrieben hat, sondern jemand mit mehr Erfahrung.
• Wenn Sie den Fehler priorisiert und geplant haben, sollten Sie auch Zeit haben, herauszufinden, wer der beste Mann für diese Aufgabe ist. Dies würde auf der anderen Arbeit, die getan werden musste, der Verfügbarkeit von Entwicklern und Ihrer allgemeinen Beurteilung basieren.

In Bezug auf Übergaben sollten diese ziemlich minimal sein. Am Ende des Tages sollten Ihre Entwickler Code so schreiben, dass er für jeden Entwickler, der eine Aufgabe hat, ihn zu überarbeiten, klar, sauber und offensichtlich ist. Es gehört zu meiner Aufgabe, dafür zu sorgen, dass die Entwickler im Team das tun.

Ich hoffe, dass dies hilft :)

Answer 7

ScrumMastern keine Einstufung der Entwickler-Ressourcen.ScrumMaster ist eine Rolle, die von jemandem im Team erfüllt wird.

Davon abgesehen ist der Product Owner der "auf dem Team Projektmanager" und sollte kämpfen, um die Ressourcen zu sichern, die benötigt werden, um das Produkt in die Produktion zu stabilisieren.

Die Entwicklungspraktiken müssen verbessert werden, damit sich die Teams null Bugs nähern. "Bugs", die über das Ende eines Sprints hinausgehen, müssen auf das Product Backlog gesetzt werden, um vom Product Owner priorisiert zu werden.

Answer 8

Ich stimme für # 2. Als Entwickler hasse ich Kontextwechsel und das ist es, was Sie im Wesentlichen mit # 1 erzwingen. Was das Problem des Eigentums an Code betrifft, ist es ein Anti-Pattern, wenn Entwickler eigene Code-Teile haben. Bemühen um gemeinsame Eigentümer: Einführung Paarung, Rotation usw.

Zum zweiten @ Kevindtimms Kommentar ist UAT nur ein weiterer Sprint. Vielleicht mit weniger Entwicklern.

Auf der anderen Seite besteht der Kern des Agile Software-Manifests darin, den Geschäftswert inkrementell zu liefern, also sollten Sie idealerweise am Ende jedes Sprints zu PROD wechseln. Wenn ja, dann sollte nicht Teil von jedem einzelnen Sprint sein. Ist das nicht das, wofür die Demo ist?

Answer 9

Ein Teil davon fällt auf den Product Owner, um zu priorisieren, wenn einige Fehler wichtiger sind als einige Karten für mich. Wenn die PO lautet: "Beheben Sie diese Fehler JETZT", sollten Fehlerkorrekturen an den Anfang der Liste verschoben werden. Wenn es viele Bugs mit hoher Priorität gibt, kann es sich lohnen, einen Stabilisierungs-Sprint zu haben, bei dem Bugs behoben sind und keine neuen Funktionen ausgeführt werden. Ich wäre versucht, die PO zu fragen, wie viel Zeit sie mit Fehlern verbringen wollen, obwohl ich mir nicht sicher bin, wie praktisch das ist.

Die Idee, Wartungsentwickler zu haben, ist nett, aber haben Sie in Betracht gezogen, wo es einige Schmerzen geben kann, Codeänderungen zusammenzufassen, was die Wartung macht und was die Entwickler neuer Funktionen tun? Ja, das ist nur ein Tritt auf die Zehen, aber ich hatte einige schmerzhafte Zusammenführungen, bei denen ein Tag mit zwei Entwicklern verbracht wurde, die versuchten Code zu promoten, aufgrund so vieler Änderungen zwischen einer Test- und Entwicklungsumgebung.

Darf ich die Idee eines anderen Entwicklers vorbringen, der den Fehler behebt, so dass jemand anderes aufgreift, wie etwas codiert wurde? Wenn mehrere Personen an einer Funktion arbeiten, kann dies eher dazu beitragen, die kollektive Eigentümerschaft als die individuelle Eigentümerschaft des Codes zu fördern. Ein anderer Teil ist, dass manchmal jemand anderes eine leichtere Zeit mit einem Fehler hat, weil sie diese Art von Fehler zuvor behoben haben, obwohl dies auch zu einer Abhängigkeit führen kann, die regelmäßig überprüft werden sollte.

Answer 10

Ich habe in der Regel Option 1 gefolgt. Oft, weil Ressourcen zu anderen Projekten gehen. Wenn Sie eine Ursachenanalyse durchführen, indem Sie diskutieren, wie Fehler erstellt wurden, gibt es einen kleinen Nebeneffekt der öffentlichen Verlegenheit. Wenn Sie ein Gefühl für das Eigentum an einem Projekt entwickelt haben, sollten Ihre Entwickler mehr als nur ein bisschen peinlich sein, wenn ihr Code einen höheren Prozentsatz an Fehlern aufweist als andere oder was vernünftig ist.

Normalerweise finde ich, dass in diesen Fällen die meisten Entwickler tatsächlich frustriert sind, wenn sie zu beschäftigt sind, um ihre alten Fehler zu beheben. Sie mögen es nicht, wenn jemand anders ihre Fehler bereinigen muss.

Ein Gefühl von Besitz und Stolz ist wichtig. Wenn du das nicht getan hast, zählst du immer auf die Drohung der Bestrafung, um sie dazu zu bringen, die richtigen Dinge zu tun.

Answer 11

Ihr Team sollte KEIN neues Projekt beginnen, bis das aktuelle Schiff geliefert wird. Ich denke, die meisten Scrum-Praktiker würden argumentieren, dass es keinen Platz in Scrum für UAT gibt (wie es im Wasserfall gemacht wurde). Was Sie suchen, heißt Stabilisierungssprint und ist Ihr letzter Sprint kurz vor dem Go-Live. Das GANZE Team arbeitet daran.Zu den Dingen, die in dieser Zeit erledigt werden, gehören Fehler in letzter Minute, Optimierungen der GUI-Verschönerung, Roll-out-Dokumentation, Hilfe-Anleitungen, Betriebsschulungen und lange Mittagessen. Es ist auch eine gute Zeit für das Team, um etwas Neues zu lernen, ohne den "Druck", Backlog-Artikel zu liefern oder sich etwas zu entspannen, bevor man etwas Neues beginnt. Basierend auf den UAT-Zeitrahmenerwartungen Ihrer Kunden; wenn es dazu neigt, auf der längeren Seite zu sein; Sie können auch Aufgaben, die nicht auf den Kunden ausgerichtet sind, auf diesen Sprint verschieben, z. B. Protokollüberwachung, Server-Setup-Skripts, Wartungsbildschirme oder andere verschiedene Tools.

Was auch immer Sie tun, tun Sie keine Arbeit außerhalb der Sprint-Grenzen. Es ist ein rutschiger Abhang in eine wasserfallähnliche Planung Vergessenheit.

Answer 12

Warum nicht ein Backlog-Objekt namens "Bug Debt" erfassen, und das Team muss es bei jeder Iteration abschätzen. Dieser Gegenstand wird benutzt, um etwas Zeit für Entwickler zu haben, um ihn zu reparieren (wie in # 1).

Ich bin auch etwas besorgt über die Fehler, die in UAT erscheinen. Wäre es möglich, einige dieser Testpersonen in den Teams zu haben, um sie früher zu fangen? Diese Art der Sache ist sehr häufig in Projekten, wo es von Gruppe zu Gruppe über den Zaun geworfen wird. Der einzige Weg, den ich gesehen habe, ist, diese anderen Gruppen in die Teams zu integrieren und die Teststrategien zu überdenken. Dann macht UAT, was Sie wollen, um Usability-Probleme und Anforderungen zu erfassen. Du hast recht, sie werden nicht komplett verschwinden, aber sie werden minimiert.

Answer 13

Immer versuchen, den ursprünglichen Entwickler ihre eigenen Fehler zu beheben, IMHO. Dieser Teil ist einfach. Wenn Sie ein paar Entwickler haben, die sich unprofessionell verhalten und sich ihrer Pflicht, qualitativ hochwertige Software zu produzieren, entziehen, geben Sie ihnen den Kofferraum. Wenn das Problem kulturell ist, lesen Sie "Furchtlose Veränderung" von Linda Rising und arbeiten Sie in Ihrer Rolle als Change Agent. Ich bin direkt bei dir, also bin ich es, der dich nicht über den Kopf schlägt; Ich mache dasselbe bei meinem Job :).

Allerdings haben Sie größere Probleme.

Sie sind ein Scrum Master Ressourcen zuweisen? Huch. Die Scrum guide ruft die SM

... [dienen], um das Entwicklungsteam auf verschiedene Arten, darunter:

das Entwicklungsteam Coaching in Selbstorganisation ...

Ich verstehe, dass wir alle nicht die ideale Organisation haben, um Scrum zu praktizieren; Dies sollte jedoch täglich an Ihnen nagen, bis es verbessert ist. Der Scrum gude setzt es einfach:

Entwicklungsteams strukturiert sind und von der Organisation zu ermächtigt, organisieren und ihre eigenen Arbeit verwalten.

** Zweitens, hör auf zu sagen Ressourcen. Hör einfach auf. Ressourcen sind Kohle, Holz und Erdgas. Menschen sind keine Ressourcen. **

Drittens ist diese UAT ein großes Hindernis für das Scrum-Team. Wenn ich Sie richtig verstehe, hat der Kunde einen riesigen, roten Knopf, den er drücken kann, um die Arbeit "Fertig" komplett zu sprengen, indem er sagt: "Sie müssen das reparieren, bevor es fertig ist." Alle Scrum Teams, die dem unterworfen sind, haben keine Geschwindigkeit, Vorhersagen usw. Diese Dinge messen alle "erledigt" und potentiell "erledigt"; Sie hängen von "Done" -Software ab, die möglicherweise versandt werden kann.Hier ist, wie die Scrum Leitfaden beschreibt die Produkterhöhungsschritte:

Das Erhöhen Sie die Summe aller Product Backlog Elemente ist abgeschlossen während eines Sprint und dem Wert der Inkremente aller bisherigen Sprints. Am Ende eines Sprints muss das neue Inkrement sein, was bedeutet, dass es in einem brauchbaren Zustand sein muss und die Definition des Scrum-Teams "Done" erfüllt. Es muss in einem brauchbaren Zustand sein, unabhängig von ob der Product Owner beschließt, es tatsächlich zu veröffentlichen.

Sie können diese UAT Situation auf verschiedene Weise verbessern:

• den UAT Client Konvertieren eine einfache Rückkopplungsschleife das heißt Feature-Anfragen aus dem UAT kommen, keine Benachrichtigungen von unvollständiger Software.
• Lassen Sie ihre UAT-Tester während des Sprints gemeinsam mit den Entwicklern arbeiten und stellen Sie sicher, dass die Arbeit "Fertig" ist.
• Nehmen Sie keine Arbeit in einen Sprint, es sei denn, eine UAT-Person ist verfügbar, um die Arbeit zu validieren.

Ich weiß, keiner von diesen wird "kommerziell" plausible scheinen, aber du bist der SM. Wenn niemand sonst in der ganzen Organisation diese Dinge sagt, muss man immer dazu bereit sein.

Ich realisiere das klingt wie ein Tritt in die Hose, aber Sie müssen es von jemandem Jahr. Das ist ein bisschen wie das old shoe/glass bottle Szenario von (wow) vor 10 Jahren.

Bitte zögern Sie nicht mich zu erreichen, wenn Sie dies weiter erkunden möchten. Ich bin ein Scrum-Master-Kollege und würde mich freuen, dir bei der Bewältigung dieses schwierigen Szenarios zu helfen.