Wie überwinde ich einen Engpass im Prozess eines Teams, wenn das, was die Leute mir sagen, nicht mit dem übereinstimmt, was ich sehe?

Ihr Team scheint innerhalb jedes Sprints eine Mini-Wasserfall-Entwicklung durchzuführen, was ein bekanntes Anti-Pattern ist, da Sie nicht die Zusammenarbeit innerhalb des Teams erhalten, die agile Methoden erfolgreich macht.

Außerdem hat Scrum nur 3 „Berufsbezeichnungen“: Product Owner, Scrum Master und Mitglied des Entwicklungsteams. Es gibt keine separaten Entwickler und Tester, sie sind alle gleichermaßen Mitglieder des Entwicklungsteams, obwohl sich einzelne Mitglieder möglicherweise mehr auf die Implementierung oder das Testen konzentrieren.

Das Entwicklungsteam als Ganzes ist dafür verantwortlich, Funktionalität gemäß seinen Qualitätsstandards zu liefern, was typischerweise durch das Erhalten von Tickets zu „Fertig“ dargestellt wird. Wenn es ein Problem gibt, Tickets zu erledigen, dann sollte das gesamte Entwicklungsteam dafür verantwortlich gemacht werden. Wenn beim Testen der Funktionalität ein Rückstand besteht, sind die Personen, die den Code geschrieben haben, ebenso dafür verantwortlich, diesen Rückstand aufzulösen, wie die Personen, die die Tests durchführen.

Als letzten Gedanken gehe ich davon aus, dass am Ende eines Sprints alle unfertigen Arbeiten automatisch in den nächsten Sprint übertragen werden, wobei einige neue Arbeiten hinzugefügt werden, um die verbleibende Kapazität zu füllen. Ich frage mich, wie das Team reagieren würde, wenn der Product Owner mit der Planung eines neuen Sprints beginnen würde

Ich habe meine Prioritäten geändert. Die ganze unvollendete Arbeit, die wir im letzten Sprint nicht liefern konnten, ist mir nicht mehr wichtig genug, also werden wir aufhören, daran zu arbeiten, und diese Geschichten werden zurück in den Rückstand gehen, bis sie wieder relevant werden. Ich möchte, dass wir uns ab heute auf diese neue Arbeit konzentrieren.

Sie könnten mit dem Product Owner besprechen, dies als Experiment auszuprobieren und dem Team einen Ruck geben, dass sich unvollendete Arbeit wirklich wie verschwendete Mühe anfühlen kann (wobei unvollendet bedeutet, dass die Arbeit nicht in der Spalte „Fertig“ steht. Wenn die Implementierung abgeschlossen ist, aber das Testen nicht , dann ist es nicht fertig). Der Punkt, an dem diese unvollendeten Geschichten wieder relevant werden, könnte der Sprint nach dem sein, in dem Sie dieses Experiment durchführen, aber das ist Sache des PO.

Ihr Problem ist nicht, dass Sie Entwickler und Nicht-Entwickler haben (wie Sie die Geschäftsanalyse/den Product Owner, den Designer und die Tester nennen). Ihr Problem ist, dass diese Leute individuelles Eigentum an ihrem Stück vom Kuchen haben und nicht am ganzen Kuchen .

Hier sind ein paar Dinge aus dem Scrum Guide (Hervorhebung von mir):

• Entwicklungsteams sind funktionsübergreifend und verfügen als Team über alle erforderlichen Fähigkeiten, um ein Produktinkrement zu erstellen.
• Scrum kennt keine Unterteams im Entwicklungsteam, unabhängig von Bereichen, die behandelt werden müssen, wie Testen, Architektur, Betrieb oder Geschäftsanalyse ; Und,
• Einzelne Mitglieder des Entwicklungsteams können spezielle Fähigkeiten und Schwerpunkte haben, aber die Verantwortung liegt beim Entwicklungsteam als Ganzes .

Idealerweise könnte jedes Mitglied des Entwicklungsteams in Scrum ein Full-Stack-Entwickler sein, aber wenn Sie in Wirklichkeit Entwickler und Tester haben, dann ist das überhaupt kein Problem. Ich habe mit solchen Teams gearbeitet, in denen Entwickler Code geschrieben und Tester ihn getestet haben, und in einigen Teams hat es funktioniert und in anderen nicht. Was war der Unterschied?

In den Teams, die gut zusammengearbeitet haben, haben die Leute zusammengearbeitet. Sie arbeiteten zusammen, um jede Story durch den Sprint auf „Fertig“ zu bringen. Die Entwickler beendeten ihre Arbeit und übergaben sie an die Tester. Sie erklärten, was vor sich ging, wie das Ding funktionierte, wo man in der Datenbank nach Dingen suchte, wie man Testdaten erstellte usw. Entwickler und Tester hatten nach Interaktionen mit dem Product Owner ein gutes Verständnis dafür, was gebaut werden musste. Tester arbeiteten eng mit Entwicklern zusammen, um ihre Testszenarien vorzubereiten, bevor sie eine Übergabe der Entwicklung erhielten. Wenn jemand Hilfe von jemand anderem brauchte, bekam er sie. Sie besaßen die gesamte Arbeit, obwohl sie sich um verschiedene Phasen der Arbeit kümmerten (Design, Entwicklung, Tests usw.).

Möchten Sie herausfinden, wie sich die Dinge in den Teams entwickelt haben, die nicht zusammengearbeitet haben? Jeder machte sein eigenes Ding. Entwickler entwickelt. Tester getestet. Business Analyst schrieb Anforderungen. Sie kümmerten sich nur um „ihren Teil“, und sobald das vorbei war, warfen sie es über den Zaun, damit andere es als nächstes erledigen konnten. "Ich habe meinen Teil getan, jetzt bist du dran". Anstatt alle an einem Strang zu ziehen, um den Ball von einer Seite des Spielfelds auf die andere zu befördern, ließen sie den Ball einfach hin und her springen, bis schließlich jemand „gut genug“ sagte.

Ihr Problem ist nicht, dass Menschen unterschiedliche Fähigkeiten haben und nicht funktionsübergreifend sind. Ihr Problem ist, dass sich ihre Fähigkeiten nicht ergänzen. Ihre Fähigkeiten vermischen sich nicht, sie bleiben vielschichtig .

Wenn Sie Entwickler dazu bringen, mehr zu testen und Tester mehr zu entwickeln, werden die Leute anfangen, es zu hassen. Finden Sie Wege, wie sie zusammenarbeiten können. Wie genau kann ich nicht sagen. Es kommt auf die Dynamik des Teams an. Möglicherweise müssen Sie mit ein paar Dingen experimentieren. Testen Sie einige andere Dinge. Betrachten Sie das gesamte Bild und finden Sie heraus, was los ist. Möglicherweise müssen Sie jede Story im Sprint einzeln nachverfolgen und daraus bestimmen, wo die Reibungspunkte zwischen den Menschen liegen. Dann überlegen Sie, wie Sie daran arbeiten können.

Und denken Sie daran, dass es einige Zeit dauern kann, bis die Art und Weise, wie Menschen zusammenarbeiten, verbessert wird. Du hast gesagt, dass du vor ein paar Monaten als Scrum Master angefangen hast. Wie lange haben diese Leute so gearbeitet, wie sie es jetzt tun? So machen sie es. Sie sind möglicherweise so vertieft in ihre Art, Dinge zu tun, dass sie nicht bemerken, dass es bessere Ansätze geben könnte. Sie hingegen sind neu und sehen die Probleme. Arbeiten Sie mit ihnen zusammen, um zuerst die Kommunikation und Zusammenarbeit zu verbessern, und später können Sie alle nach Möglichkeiten suchen, den Prozess zu verbessern.

Sie tun bereits viel Gutes, aber ich würde auch Folgendes empfehlen:

• Reduzieren Sie, wie viel Sie in jeden Sprint einbringen
• Reduzieren Sie es weiter, bis der Testengpass verschwindet und das Team die gesamte Arbeit erledigt, die es einem Sprint zuweist
• Bekräftigen Sie kontinuierlich, dass die Aufgabe des Teams darin besteht, fertige Elemente zu liefern und nicht viel zu programmieren.

Konzentrieren Sie sich viel auf die Retrospektiven. Es wird die Versuchung bestehen, Schuldzuweisungen zu machen („es ist die Schuld des Testers“, „es ist die Schuld des Entwicklers“). Vermeiden Sie dies und konzentrieren Sie sich kontinuierlich darauf, das Team dazu zu bringen, kooperativ zu arbeiten.

Sie müssen dieses Problem nicht lösen, aber Sie müssen dem Team helfen, es zu lösen. Sie werden das nicht tun, bis sie anfangen, als einheitliches Team zu denken und zu handeln.

Wenn das Team zögert, Änderungen vorzunehmen, schlagen Sie vor, dass sie Dinge als Experimente durchführen:

„Warum versuchen wir nicht, X für den nächsten Sprint zu machen? Wenn es nicht klappt, können wir zu unserer alten Arbeitsweise zurückkehren.“

Andere Kommentare hier klingen alle wahr: zu Wasserfall-y, nicht genug Teamverantwortung usw., aber ich möchte einen Punkt hervorheben, der nur einmal in anderen Antworten gemacht wurde: Sie setzen sich absolut zu hohe Ziele. Sie MÜSSEN sich mundgerechte Ziele setzen, die erreichbar sind, egal wie langsam das geht. Wenn das nicht in den Geschäftsplan passt, kann der Geschäftsplan nicht mit dem vorhandenen Personal eingehalten werden, und je früher das realisiert wird, desto besser. Planmäßig Tore zu schießen macht Spaß und macht süchtig und baut Kameradschaft und Esprit de Corps auf. Ziele immer wieder zu verfehlen, macht jeden unnötigerweise zu Verlierern, und Verlierer sind nicht motiviert, produktiv oder kooperativ. Nehmen Sie den besten Entwickler oder das beste Team der Welt, geben Sie ihnen Ziele, die sie nicht erreichen können, und Sie werden sie zu Verlierern gemacht haben.

Nun ein neuer Punkt: Das Testen einiger Codes dauert doppelt so lange (oder länger) wie das Schreiben. Besteht die Möglichkeit, dass das hier der Fall ist? Haben die Tester Recht, dass das Testen der Arbeit so lange dauert? Sind Sie in der Lage, sich buchstäblich einzubetten und selbst zu testen und es von innen zu sehen?

Wenn ja, könnten Sie Ihre Tester vielleicht alles Mögliche entlasten lassen. Als Entwickler schreibe ich zum Beispiel die Unit-Tests und fülle sie mit allen Tests, die mir einfallen. Da der ursprüngliche Autor immer blinde Flecken hat, wäre es dann sinnvoll, die Unit-Tests an neue Mitarbeiter zu übergeben, die neue Probleme finden können, aber an diesem Punkt fügen sie nur Testfälle zu einem vorhandenen Skript hinzu.

Wenn der Kunde der Projektanfrage technisch versiert ist („Ich brauche eine API, die XYZ macht“), könnte der Kunde wohl den anfänglichen Testrahmen und die Testfälle als konkreten Ausdruck dessen schreiben, was er benötigt. Entwickler arbeiten am Code, bis er dieses Testskript besteht, und übergeben ihn erst dann an die QA, um nach Dingen zu suchen, die übersehen wurden. Wie mein vorheriger Punkt führt dies dazu, dass die Tester viel weniger Arbeit haben, gibt den Entwicklern aber zusätzlich ein konkretes anfängliches Ziel vor, bevor sie Kandidatencode zum unabhängigen Testen einreichen.

(Als Variante entlastet dies die Arbeit der Tester nicht, hindert die Entwickler jedoch daran, offensichtlich unbrauchbaren Code einzureichen: Lassen Sie die Tester zuerst die Testskripte schreiben und verlangen Sie, dass die Entwickler diese übergeben, bevor sie sie an den Test zurückgeben ...)

Die erste Frage, die ich an Ihrer Stelle stellen möchte, lautet:

Werden die Probleme im Test festgestellt, weil der Code unzuverlässig ist oder weil die Anforderungen nicht verstanden wurden?

Die Entwickler verzetteln sich vermutlich darin, die Korrektheit des Codes sicherzustellen, aber in den folgenden zwei Szenarien:

• Der Entwickler schreibt, was seiner Meinung nach funktionieren sollte, findet aber beim Testen immer wieder "offensichtliche" technische Mängel, dh das Problem ist offensichtlich, wenn er durch das Auslösen einer Ausnahme darauf aufmerksam gemacht wird
• Der Entwickler schreibt, was seiner Meinung nach die richtige Umsetzung für die Geschichte ist, entscheidet aber beim Testen, dass die Geschichte nicht wirklich erfüllt ist oder der Wortlaut und die Absicht der Geschichte nicht eng genug aufeinander abgestimmt sind, um ein tatsächlich nutzbares Feature zu produzieren

...es gibt ganz unterschiedliche Ursachen und Abhilfen.

Wenn Sie sehr viel Pech haben, können Sie natürlich beides im Überfluss haben.

Für den ersten Punkt können die Hauptursachen Probleme sein wie:

• Entwickler, die mit dem verwendeten Framework oder den verwendeten Mustern nicht vertraut genug sind
• Nicht genügend automatische Tools (z. B. Linting, Unit-Tests), um die manuelle Arbeit zu reduzieren – oder nicht verstanden, wie die automatischen Tools verwendet werden sollen
• Eile durch vermeintlichen Zeitdruck und Flüchtigkeitsfehler
• Schlechte Quellkontrolldisziplin, die Konflikte einführt ("er hat meinen Code überschrieben!")
• Schlechte oder inkonsistente Architektur, die es schwierig macht, den Fluss der Anwendungslogik zu verstehen. Dies könnte daran liegen, dass Ihre aktuellen Teammitglieder, die wie Sie erwähnt aus anderen Bereichen zusammengezogen wurden, die Absicht des ursprünglichen Entwicklers beim Schreiben bestimmter Teile der Lösung nicht verstehen können und es schwierig finden, neue Funktionen wie erwartet zum Laufen zu bringen.

Während die zweite sein könnte:

• Product Owner ist bei der Beschreibung der Geschichte nicht spezifisch genug oder macht Geschichten zu allgemein und geht davon aus, dass ihre Absicht verstanden wird
• Nicht genügend Ausarbeitung in der Verfeinerung, um sicherzustellen, dass die Entwickler die Absicht verstehen
• Man einigt sich nicht auf einen eindeutig ausreichenden Ansatz zur Erfüllung der Geschichte, sodass die Entwickler sich dann darüber streiten, wie die Geschichte implementiert werden soll

Ein Team, das keine Vorstellung davon hat, wie diese Probleme gelöst werden können, wird Ihnen diese Antworten wahrscheinlich nicht geben – da sie größtenteils eine Frage des Grades sind. Bei den technischen Punkten sind Sie vielleicht in einer Situation, in der die Teammitglieder es aufgegeben haben, sich gegenseitig oder möglicherweise einer bestimmten Person ihren Standpunkt zu erklären. Dies würde ein Umfeld fördern, in dem sich technische Schulden ansammeln, weil das Team nicht einer Meinung ist, wie eine gute Codequalität aufrechterhalten werden kann.

In ähnlicher Weise klingt Ihre Beschreibung für die Punkte, die sich auf Anforderungen beziehen, so, als hätten Sie möglicherweise einen Product Owner, der sich weigert, seine Arbeitsweise an die Bedürfnisse des Teams anzupassen. Sie könnten auf jeden Fall den Wortlaut, die Granularität und die Spezifität der Geschichten, die Ihr Product Owner erstellt, hinterfragen, und Ihre Rolle als Scrum Master gibt Ihnen eine starke Position, um darauf zu bestehen, dass diese verbessert werden, wenn sie fehlen.

Aus Entwicklersicht konzentrieren sich andere Antworten zu sehr auf theoretische Praktiken. Um konkrete Antworten zu erhalten, ist es wichtig zu wissen, mit welchen Aufgaben die Entwickler zu tun haben.

Außerdem ist das Problem meistens nicht die zurückgeprallte Aufgabe, sondern eine andere Aufgabe in der Testwarteschlange.

Dieser Satz deutet darauf hin, dass es eine Diskrepanz zwischen dem gibt, was Entwickler denken, was sie tun sollten, und dem, was der Sprint denkt, welche Aufgaben in diesem Sprint enthalten sein sollten.

Ich arbeite zum Beispiel gerade an einem Projekt, das größtenteils Refactoring ist. Meine Aufgaben liegen alle auf architektonischem Niveau. Alle meine Änderungen sind enorm und betreffen fast 100 Dateien pro Funktion. Die Fehler, die der Tester erstellt, sind entweder sehr klein oder einige obskure Anwendungsfälle oder plattformübergreifende Inkonsistenzen.

Die Sache ist, aus meiner Sicht befindet sich das Projekt nicht in der Phase, in der ich es mir leisten kann, stundenlang an einem zufälligen Problem zu knabbern. Der Code ist so spaghettiartig, dass ich, wenn ich anfange, nachzuverfolgen, wo sich der Fehler befindet, feststellen werde, dass ein bestimmtes Datenelement Teil eines Objekts ist, das ein anderes Objekt erstellt und die Daten zusammen mit einem anderen Namen weitergibt, der das modifiziert Daten und übergibt sie an ein anderes Objekt mit einem dritten anderen Namen, das sie modifiziert weitergibt, das sie weitergibt ... Es wird Stunden um Stunden dauern, kleine Fehler auf diese Weise zu beheben. Ich muss zuerst die architektonische Arbeit machen.

Unsere Ticketpraktiken sind sehr flexibel, also haben wir es herausgefunden. 1) Wenn es irgendwelche kleinen Fehler gibt, die ich neben meinen großen Aufgaben in einer Stunde oder so erledigen kann, werde ich diese erledigen. 2) Wenn das Problem in dem Code liegt, den ich noch nicht umgestaltet habe, verschiebe ich den Fehler in den Rückstand. 3) Ein anderer Entwickler, der nicht für die Architektur verantwortlich ist, nimmt alle Fehler, die machbar sind, aber nicht über architektonische Änderungen priorisiert werden können.

Wenn Ihr Projekt unserem ähnlich ist, liegt der Fehler meiner Meinung nach weder bei den Entwicklern noch bei den Testern. Tester leisten großartige Arbeit beim Auffinden der Fehler, aber nicht alle davon sind für Entwickler relevant. Die Entwickler leisten großartige Arbeit mit dem Code, aber sie können es nicht vermeiden, Details zu übersehen. In diesem Fall scheint das Problem darin zu liegen, dass der Prozess zu unflexibel ist und der Sprint Aufgaben hat, die dort nicht hingehören.

Einige der anderen Antworten gefallen mir sehr gut, aber ich wollte Sie nur an ein weiteres Tool in der Toolbox erinnern: das Work In Progress-Limit.

Legen Sie eine Obergrenze für die Spalte „Bereit zum Testen“ sowie für die Spalten „Testen“ und „Entwicklung“ fest. Dies bedeutet, dass einige Entwickler keine neuen Aufgaben übernehmen können und daher möglicherweise motivierter sind, den Testern bei der Erledigung ihrer aktuellen Aufgaben zu helfen. Oder sie nutzen die zusätzliche Zeit, um die Unit-Tests usw. für ihre Aufgaben, die auf Tester warten, aufzupeppen.

Kombinieren Sie dies damit, dem Sprint nicht mehr Aufgaben hinzuzufügen, als das Team zuverlässig erledigen kann, und regelmäßige Retrospektive, um andere Blocker herauszufinden.

Eine Entwicklerperspektive

Sehr einfach...

Arbeiten Sie voraus!

Das Bereitstellen und Bereitstellen von Funktionen während des gesamten Sprintzyklus bedeutet, dass QA-Tests während des gesamten Sprintzyklus durchgeführt werden und Entwickler frühzeitig auf QA-Feedback reagieren und Zeit haben, an Elementen aus dem nächsten Sprint zu arbeiten, und so weiter!

ABER WIE!?

Dies ist tatsächlich eine Agile-Scrum-Regel, die unter Semi-Pro-Scrum-Mastern am meisten ignoriert wird! Die Regel ist zu unterschätzen und

warte darauf!

Übernehmen Sie immer eine Menge Arbeit pro Entwickler, die in WENIGER ALS Sprint-Zyklus-Tagen erledigt wird, um sicherzustellen, dass die Arbeit abgeschlossen wird, während Sie Raum für Tests geben!

Hier ist ein vollständiger Artikel darüber, wie ich die Probleme beim agilen Testen überwinden konnte. Ich habe das Engpassproblem beim agilen Testen gelöst!

https://medium.com/@salibsamer/i-solved-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1