Kunde mit konservativer UAT-Politik

Ein bestimmter Kunde hat einen sehr traditionellen, konservativen Ansatz in Bezug auf UAT und Bereitstellung. Wenn das Entwicklungsteam die Elemente im Sprint fertigstellt, wird dies alles in ein Release gepackt, das sich durch eine UAT/Staging-Umgebung schlängeln muss, wo es vollständig auf neue Funktionen getestet, dann vollständig regressionsgetestet und schließlich in der Produktion bereitgestellt wird . Der Grund für diesen Ansatz ist, dass die Staging-Umgebung eine Kopie der Produktionsdaten enthält, die für Entwickler zu sensibel ist, und das Unternehmen an einen Wasserfall-Ansatz gewöhnt ist. Beachten Sie, dass dies nicht geändert werden kann, also schlagen Sie bitte keine Art von organisatorischer Überarbeitung vor. Die UAT-Tester sind auch nicht Teil des Scrum-Teams. Auch dies wird sich nicht ändern.

Auch wenn Unit-Tests, Regressionstests und andere Testformen in den Sprint einfließen und der Product Owner stark involviert ist, führt am Ende kein Weg an diesem langwierigen UAT-Prozess vorbei. Dies führt natürlich zu vielen Fehlern, die von UAT gemeldet werden, und die Elemente werden abgelehnt und an die Entwicklung zurückgesendet. Der typische UAT-Zyklus beträgt etwa 1 Woche.

Ich suche nach guten Ideen, wie man Scrum-Sprints in dieser Art von Klima/Umgebung strukturieren kann. Auch hier schlagen Sie bitte nicht vor, das Unternehmen zu wechseln, da dies den Rahmen dieser Diskussion sprengen würde. Dies ist eher eine Frage "in der realen Welt mit Kunden arbeiten". Sie lieben agile Praktiken, Backlog-Management, Verfeinerung, Sprint-Planung, Release-Planung und all die anderen Scrum-Goodies. Wir müssen nur diese 1 Woche UAT und Ablehnung bis zum Ende anheften, und ich suche nach Möglichkeiten, dies unterzubringen.

Der Wechsel zu einer anderen Methodik ist auch eine Option, wenn Sie einige Vorschläge haben.

Ich bin mir nicht sicher, was genau Sie hier zu verbessern versuchen. Unterbrechungen? Scrum Guide-Konformität? Ich bin mir auch nicht sicher, was die Gründe für Fehler sind, die nach UAT gemeldet werden. Beziehen sie sich auf die Qualität der Inszenierungsumgebung? Wenn Sie weitere Details mitteilen, werde ich meine Antwort aktualisieren.
Danke schön. Das Ziel wäre ein geringeres Lieferrisiko. Idealerweise würde es also den UAT-Zyklus in den Sprint integrieren, aber Dinge finden, die Entwickler tun können, um Schlupf zu vermeiden, wenn die Veröffentlichung eine Low-Defect-Version ist. Der Grund, warum UAT eine Herausforderung darstellt, liegt darin, dass das Projekt eine Erweiterung eines Legacy-Systems ist, das viele gegenseitige Abhängigkeiten aufweist. Dann muss festgestellt werden, ob das Problem bereits existierte, durch neuen Code verursacht wurde oder irgendwo nachgelagert verursacht wurde, weil A B aufgerufen hat, dann A C aufgerufen hat, aber B direkt oder indirekt den Zustand von C geändert hat, in einem Kleiner als offensichtlicher Weg.
Scrum bietet den größten ROI, wenn es keine technischen Schulden gibt, wie z. B. unvorhersehbare Legacy-Systeme. Wenn Scrum in solchen Fällen der beste Ansatz ist, würde ich raten, es zuerst zuverlässiger zu machen. Gleichzeitig haben Sie geschrieben, dass Scrum keine Notwendigkeit ist, also ging es bei meiner Antwort eher um das Lösen eines Problems, nicht um das Lösen eines Problems im Rahmen von Scrum.

Antworten (5)

TL;DR

Sie können einem Schwein keinen Lippenstift auftragen und erwarten, dass es die Schönheit des Balls ist. Wenn Sie mit einem Prozesshindernis konfrontiert werden, das nicht geändert werden kann, wie das, das Sie beschreiben, müssen Sie die Prozessprobleme zu sichtbaren Kosten für das Projekt machen. Da Sie fast keine Kontrolle über das Hindernis haben und wenig tun können, um es zu kontrollieren, sollte Ihr Hauptziel Transparenz sein .

Machen Sie Ihren Prozess für das Team, Ihre Stakeholder, das Management und den Kunden sichtbar und transparent. Es liegt dann an ihnen , den Wert (oder dessen Fehlen) in externen Prozessen zu identifizieren. Ihr interner Prozess wird den Wert, der durch das Team hinzugefügt wird, sowie die Vorlaufzeit und den Prozessaufwand, die durch externe Effekte hinzugefügt werden, klar identifizieren.

Es ist die Aufgabe der Geschäftsleitung, Prozessexternalitäten zu kontrollieren (oder zu akzeptieren). Solange das alle im Hinterkopf behalten, läuft alles viel reibungsloser.

Externalisieren Sie die UAT-Rückkopplungsschleife

Dies führt natürlich zu vielen Fehlern, die von UAT gemeldet werden, und die Elemente werden abgelehnt und an die Entwicklung zurückgesendet.

Das ist ein Problem, aber es ist eine Externalität . Sie haben einen externen Prozess, der den Prozessaufwand (und damit die Kosten) zu Ihrem Endergebnis hinzufügt. Der richtige Weg, damit umzugehen, besteht darin, diese Kosten für die Beteiligten sichtbar zu machen.

In Ihrem speziellen Fall würde ich UAT aus der Definition of Done entfernen. Die Arbeit für den Sprint ist abgeschlossen, wenn sie Unit-Tests, kontinuierliche Integration, Peer-Review oder was auch immer in Ihrer Definition of Done steht, bestanden hat. Die geleistete Arbeit wird dann am Ende des Sprints als abgeschlossenes Inkrement dem Kunden präsentiert.

Der Kunde kann dann Ihren nächsten Sprint damit verbringen, so viel oder so wenig UAT durchzuführen, wie er möchte, während Sie am nächsten Inkrement arbeiten, und alle Probleme, die er möglicherweise aufdeckt, werden vom Product Owner als neue Arbeit für einen zukünftigen Sprint in das Product Backlog aufgenommen. Diese zusätzliche Vorlaufzeit wird ein sichtbares Artefakt des von ihnen gewählten Prozesses sein, und Sichtbarkeit hat große Vorteile. Dies ist wirklich der richtige Weg, um mit dieser Situation umzugehen, und passt zu den zentralen Grundsätzen des iterativen Entwicklungsmodells.

Verlängern Sie Sprint für UAT mit sichtbaren Kosten

Alternativ können Sie Ihre aktuelle Sprintlänge einfach um zwei oder mehr Wochen verlängern, um sie an ihren UAT-Zyklus anzupassen. Ein Teil Ihrer Definition of Done besteht darin, das Mid-Sprint-Produkt an UAT zu übergeben und dann darauf zu warten, dass die Ergebnisse zurückkommen.

Die Kosten für ungenutzte Entwicklerzeit werden durch den externen Prozess auferlegt. Ihre Aufgabe ist es nicht, viel Arbeit zu schaffen oder den „Irrtum der 100-prozentigen Auslastung“ aufrechtzuerhalten. Das Team kann diese Woche nutzen, um den CI-Server zu aktualisieren, Workstations zu patchen, Fortbildungen zu absolvieren oder einfach nur ein gutes Buch zu lesen. Der Punkt ist, dass dieser UAT-Zyklus Entwicklungskosten hat (ob in Nicht-Produktarbeit oder in iterativer Arbeit), die Teil des organisatorischen Rahmens sind. Machen Sie diese Kosten einfach vollständig sichtbar.

Das Hauptrisiko bei diesem Ansatz besteht darin, dass nach Abschluss der UAT Änderungen oder neue Arbeiten möglicherweise nicht in den Schätzungen des Teams berücksichtigt wurden. Infolgedessen haben Sie möglicherweise oder möglicherweise nicht genügend Zeit, um die Änderungen oder Überarbeitungen innerhalb des Sprints anzugehen. Infolgedessen sind die sichtbaren Kosten für das Projekt mehr gescheiterte Sprints (z. B. Sprints, die das Sprint-Ziel nicht erreichen), unvollständige Arbeit, die dann in das Product Backlog zurückgeführt werden muss, oder vorzeitige Beendigung mit einer Rückkehr zur Sprint-Planung.

Dies sind akzeptable Ergebnisse in dem Sinne, dass sie sicherstellen, dass der Prozess transparent bleibt und dass die Kosten für das Projekt für diese Prozesse für das Team, die Stakeholder und den Kunden sichtbar sind. Denken Sie nur daran, dass Transparenz das Kernziel ist und dass es niemals unsichtbare Arbeit geben sollte.

Ich mag den Punkt, Kosten sichtbar zu machen, das ist möglicherweise das Wichtigste hier.

Fürs Protokoll: Wenn das Entwicklungsteam am Ende des Sprints kein potenziell veröffentlichbares Inkrement liefern kann, ist das eine ernsthafte Scrum-Abweichung. Lassen Sie uns dieses Problem jetzt beiseite legen.

Was Sie tun könnten:

  • So viele Endnutzer wie möglich in einen Sprint einbeziehen . Beschränken Sie sich nicht auf physische Präsenz. Denke mal kreativ. Beispiel: Sie können Videoclips aufnehmen, die neue Funktionen vorstellen, sie so schnell wie möglich teilen und Benutzer fragen, ob sie das erwartet haben

  • Wenn UAT 1 Woche dauern, bis sie abgeschlossen sind, denken Sie darüber nach, die Sprintlänge um 1 Woche zu verlängern und sie in den Sprint aufzunehmen. ABER warten Sie nicht mit UAT, um die letzte Woche des Sprints zu absolvieren. Betrachten Sie dies nicht als Gelegenheit für das Dev-Team, noch mehr neue Funktionen zu entwickeln, da es mit doppelter Kraft zurückschlagen wird. Gewinne? Weniger Work in Progress und Aufgabenwechsel. (Ich gehe davon aus, dass Sprint derzeit häufig durch die Anfragen dieser Endbenutzer unterbrochen wird.)

  • Coachen Sie den Product Owner, um die Sicht der Endbenutzer auf der höchstmöglichen Ebene zu vertreten
Mir gefällt die Erweiterung. Wenn Sie Glück haben und nicht viel zurückgeworfen wird, haben die Debs etwas Zeit, um das Haus in Vorbereitung auf die nächste Iteration zu reinigen.
Das war meine erste Neigung. Die nächste Frage wäre, wie man dem Management die 3. Woche erklärt. Sie möchten sicherstellen, dass diese Entwickler hauptsächlich zugewiesenen Aufgaben zugewiesen werden. Was schlagen Sie vor, wenn die Veröffentlichung fehlerfrei ist? Spikes auf Bugs? Zusätzliche Geschichten wären zu riskant, da sie wahrscheinlich den gesamten UAT-Zyklus (die 3. Sprintwoche) benötigen würden, also müsste es in dieser 3. Woche eine Art WIP-Limit geben, in Bezug darauf, was sie emittieren und durch UAT bekommen könnte .
@PittsburghDBA Ich verdiene eigentlich eine Ohrfeige für das, was ich geschrieben habe :) Ich war nicht klar genug, also lass mich mich korrigieren. Durch die Aufnahme von UAT-Tests in Sprint wollte ich sie nicht alle am Ende, in der letzten Woche, machen. Endbenutzer (oder wer auch immer sie durchführt) sollten so schnell wie möglich in den Prozess einbezogen werden.
@PittsburghDBA Die ungenutzte Zeit Ihrer Entwickler könnte für die Verbesserung Ihrer Staging-Umgebung aufgewendet werden. Hatten sie Zeit, sich intensiv mit diesem Thema zu befassen? Aus dem, was Sie geschrieben haben, habe ich den Eindruck, dass Fehler, die während der UAT aufgedeckt werden, eher ein Symptom der Entwicklungsumgebung sind als Missverständnisse in Bezug auf Product Backlog-Elemente.

Die Realität Ihrer Situation ist ziemlich alltäglich und hat beides, was jetzt zu tun ist, und Dinge für die vielleicht ferne Zukunft.

Jetzt tun

Konzentrieren Sie sich darauf, dass die Ergebnisse des Entwicklungsteams potenziell lieferbar sind. Das ist das neue Softwareinkrement, das sie bei jedem Sprint zu UAT produzieren und immer passieren sollten. (Wenn es immer bestanden wird, wird das Unternehmen in UAT einen geringeren Wert sehen.)

1) Erstellen Sie eine Definition of Done, die das Qualitätsniveau darstellt, das Sie zur potenziellen Freigabe bringt.

2) Ermächtigen Sie Ihr Entwicklungsteam, die Annahme von Backlog-Elementen abzulehnen, die keine angemessenen Annahmekriterien haben.

Dadurch nähern Sie sich den Werten und Prinzipien von Scrum an, ohne sich in die breitere Organisation einzumischen.

Die mittelfristige

Sobald Sie Qualität und Konsistenz haben, können Sie damit beginnen, das UAT-Senario eher auf eine Feedback-Sitzung zu konzentrieren. Vielleicht müssen Sie den Rest der Kette umgehen und echte Benutzer in Ihre Sprint-Überprüfung einbeziehen, aber hier werden Sie anfangen, zu beschleunigen. Wenn Sie überhaupt nichts bauen können, ist das falsch, und bauen Sie mehr von dem, was die Benutzer brauchen, werden Sie mehr Vertrauen aufbauen.

3) Bringen Sie Endnutzer und Stakeholder in Ihr Sprint Review ein und passen Sie das Backlog entsprechend an.

4) Laden Sie UAT zu Ihrem Sprint-Review ein.

5) Fügen Sie Tools zum Sammeln von Telemetriedaten wie Application Insights in Ihren Code ein, um das Verhalten Ihrer Benutzer wirklich zu verstehen.

Das lange Ziel

Wenn Sie als Entwicklungsteam die Fähigkeit unter Beweis stellen, funktionierende Software zu liefern, die den Anforderungen des Unternehmens entspricht, werden die UAT- und Staging-Prozesse zunehmend als Verschwendung angesehen. Sie werden die. Lassen Sie Ihre Kunden/Stakeholder in Ihrer Ecke kämpfen, um den Entwicklungsteams mehr Kontrolle und Verantwortung zu geben.

Das ist aufschlussreich. Ich weiß nicht warum, aber ich bin immer wieder überrascht, zumindest ein wenig, von der Geschwindigkeit des organisatorischen Wandels.
Die Definition of Done trifft das, was ich in einer separaten Antwort sagen wollte: Wenn es ein erwartetes Hindernis gibt, das bei jedem einzelnen Sprint vorhanden sein wird, könnte es sich lohnen, Ihre Definition of Done an diese Realität anzupassen. Scrum erfordert nicht, dass Ihr potenziell lieferbares Inkrement tatsächlich versendet wird! Ihre Definition von Done könnte sagen, dass es entwickelt, getestet und für UAT bereit befunden werden muss, und das könnte der Punkt sein, an dem Ihr Prozess endet. Das Feedback von der UAT geht dann in den Rückstand für den nächsten Sprint und wenn ein Inkrement die UAT erfolgreich besteht, nehmen Sie sich die Zeit, es freizugeben.
„Definition of Done“ Wahrscheinlich nicht praktikabel, konservative Stakeholder werden keine Definition of Done akzeptieren. Es ist einen Versuch wert, aber es wird fehlschlagen, wenn sie später darauf bestehen, dass etwas nicht getan wird.

Hier ist, was ich vorschlagen würde. Wenn der UAT-Zyklus abgeschlossen ist, wird das Ergebnis dem Produktrückstandsprotokoll hinzugefügt. Vor der nächsten Planungssitzung im Frühjahr kümmert sich der Product Owner um das Product Back Log und (neu) priorisiert es. Während der nächsten Frühjahrsplanungssitzung wählt das Entwicklerteam zusammen mit dem Product Owner aus, welche Product-Backlog-Einträge in das nächste Frühjahr übernommen werden. Einige Probleme könnten für die Behebung der Bestellung von entscheidender Bedeutung sein, andere könnten länger im Produktrückstand verbleiben.

Dies wäre der natürlichste Weg, aber meistens erfordert die Richtlinie eine sofortige Korrektur der Release Candidate-Story, sodass wir in Bezug auf die Sprint-Planung überlastet sind. Die Veröffentlichung würde dann so schnell wie möglich mit neuen Korrekturen beginnen, nachdem sie die UAT erneut bestanden haben. Es stört das normale Scrum-Muster.
@PittsburghDBA, " Die Richtlinie erfordert eine sofortige Korrektur der Release Candidate-Story ", was soll eine solche Richtlinie erreichen? Dh was ist die Begründung dafür? Offensichtlich stört es Ihren Prozess/Erfolg, also muss es einen Vorteil geben? Genau wie Sie lebe ich in der realen Welt, mit echten Kunden und ihren Anforderungen. Obwohl wir meistens akzeptieren müssen, was sie von uns verlangen, sollten wir uns dennoch bemühen, ihre Motivationen und Probleme mit ihnen so gründlich wie möglich zu untersuchen, damit wir eine Lösung vorschlagen können. Wenn Sie also nicht wissen, warum diese Richtlinie gilt, sollten Sie nachfragen.

Wenn die Produktivität des Teams stark beeinträchtigt wird, weil die Arbeit eine Woche später aufgrund eines fehlgeschlagenen UAT abgelehnt wird, kann es hilfreich sein, dies in der Storyplanung zu berücksichtigen. Versuchen Sie, Ihre Geschichten neu zu strukturieren, um dieses reale Problem einzubeziehen, sodass Sie dem Kunden immer noch wertvolle Fortschritte demonstrieren können, wenn Sie UAT nicht bestehen. Unter der Annahme, dass Sie von Zeit zu Zeit beim UAT erfolgreich sind, können Sie Ihrem Kunden zeigen , dass die Arbeit erledigt wird, es kann nur eine zusätzliche Hin- und Rückfahrt erforderlich sein?

Wenn der Kunde von diesen Verzögerungen betroffen ist, müssen Sie sich mit dem Problem befassen, dass Ihr Team kein Produkt herstellen kann, das den Anforderungen des Kunden entspricht. Mein nächster Schritt wäre, die UAT-Tester als Kunden zu behandeln. Sie sagten, sie gehören nicht zum SCRUM-Team, aber es ist möglich, dass sie Kunden sind. Kein Testteam mag fehlerhafte Software, vielleicht können Sie mit ihnen zusammenarbeiten, um Wege zu finden, die Dinge, die ihnen wichtig sind, früher im Prozess aufzugreifen. Wenn sie ein Kunde sind, der in den Prozess involviert ist, können sie sich daraus Anregungen holen. Sie könnten sagen: „Weißt du, dieses Tool, mit dem du sichergestellt hast, dass deine Software funktioniert, bevor wir sie getestet haben … denkst du, wir könnten das verwenden?“ Dann haben Sie einen Wert geschaffen, den sie nie erwartet hätten.

Es kommt immer darauf an, was der Kunde wirklich will. Vielleicht kann das Problem mit der Versionskontrolle behandelt werden. Vielleicht haben Sie zwei Tracks, einen Track, der neue Features hinzufügt, und der andere Track, der sicherstellt, dass Sie etwas produzieren können, das UAT mit dem vorherigen Satz von Features besteht.

Danke dafür. Ich habe auch daran gedacht, die Veröffentlichungshäufigkeit zu erhöhen, damit sie so schnell wie möglich UAT an abgeschlossenen Stories durchführen können, und dann gegen Ende des Sprints würde sich die UAT mehr auf die Integrationstests und Systemtests konzentrieren.
Kunde mit konservativer UAT-Politik
AntwortenHierDatenschutz-Bestimmungen1y, 0v