Was wird von den Entwicklern während des Testens in der zweiten Hälfte jedes Sprints erwartet?

Wenn Sie das Scrum-Framework verwenden, umfasst ein Sprint-Zyklus Entwicklung und Qualitätssicherung. Am Ende des Sprints werden die bearbeiteten und getesteten Aufgaben präsentiert und freigegeben.

Normalerweise gibt es für ein Team von 3 bis 4 Entwicklern 1 QA-Ressource. Was wird von den Entwicklern erwartet, wenn QA stattfindet? Da die Anzahl der Entwickler viel höher ist als die Anzahl der QA-Tester, werden Fehlerkorrekturen sehr schnell erledigt und die Entwickler haben gegen Ende des Sprints nichts zu tun.

Was wird von den Entwicklern während dieser QA-Tests erwartet, während sie Scrum folgen?

Der beschriebene Prozess klingt eher nach einem Wasserfall-Ansatz. Jeder Sprint hat ein Sprintziel, und bis dieses Ziel erreicht ist, kann die Arbeit nicht aufhören. Der agile Prozess besteht also aus einem funktionsübergreifenden Team, das iterativ arbeitet, was Tests und Korrekturen beinhaltet, bis das Ziel erreicht und die Definition of Done festgelegt ist.

Antworten (7)

TL; DR

Ihre Frage enthält einige falsche Annahmen über die lineare Natur des Testens innerhalb eines agilen Prozesses. Ein ausgereiftes agiles Team mit funktionsübergreifenden Fähigkeiten behandelt Entwicklung und Testen als miteinander verflochtene Aktivitäten und nicht als aufeinander folgende.

Sie sollten danach streben, Entwicklung und Tests zu integrieren, sodass es sich nicht um grundlegend getrennte Arbeitsabläufe handelt. Andernfalls müssen Sie die mit dem derzeit implementierten Workflow verbundenen Risiken und Prozessdefizite formal akzeptieren.

QA muss eingebettet sein, kein separater Prozesstrack

Typischerweise gibt es für ein Team von 3 bis 4 Entwicklern 1 QA-Ressource. Was wird von den Entwicklern erwartet, wenn QA stattfindet. Da die Anzahl der Entwickler viel größer ist als die QA, werden Fehlerkorrekturen sehr schnell erledigt und die Entwickler haben gegen Ende des Sprints nichts zu tun.

Sie machen kein Scrum, Sie machen einen Wasserfall. Die Aktivitäten sollten funktionsübergreifend sein und einen facettenreichen Teamansatz für alle Aufgaben nutzen.

Beispielsweise sollten Tester und Entwickler während eines Sprints im Gleichschritt arbeiten. Tester sollten früh und oft einbezogen werden, indem sie den Entwicklern helfen, testbare Funktionen zu entwerfen, indem sie von Anfang an an Testkriterien arbeiten, bevor eine einzige Codezeile geschrieben wird, und dazu beitragen, dass Tests zuerst geschrieben werden.

Die QA-Leute sollten jeden Tag kontinuierliche Integration durchführen, damit es eine enge (und idealerweise sofortige) Feedback-Schleife zwischen Entwicklung und Test gibt. Durch die Zusammenarbeit mit den Entwicklern wird QA nicht als separate Folgeaktivität behandelt, sondern zu einem wesentlichen Bestandteil der Design- und Entwicklungszyklen und nicht zu einer externen Angelegenheit.

Entwickler und QA sollten beim Testen zusammenarbeiten

Was wird von den Entwicklern erwartet, wenn QA stattfindet. Da die Anzahl der Entwickler viel größer ist als die QA, werden Fehlerkorrekturen sehr schnell erledigt und die Entwickler haben gegen Ende des Sprints nichts zu tun.

So wie von Testern erwartet wird, dass sie vom ersten Tag an mit den Entwicklern involviert sind, wird von Entwicklern erwartet, dass sie während der Testaufgaben mit der QA zusammenarbeiten. Anstatt den Testern Code über die Mauer zu werfen, sollten Entwickler und Tester am Testprozess zusammenarbeiten, damit Fehler behoben werden, sobald sie entdeckt werden.

Stellen Sie sich ein Pair-Programming-Szenario vor, in dem ein Tester und ein Entwickler gemeinsam an einer Testsuite arbeiten. Anstatt dass ein Entwickler eine Wand aus Code auf dem Tester ablegt und dann auf Ergebnisse wartet, könnten die beiden bei Tests und Refactorings zusammenarbeiten . Zum Beispiel:

  1. QA: Das X-Widget hat den Embiggening-Test nicht bestanden.
  2. DEV: Hoppla. Okay, ich überarbeite die embiggener-Klasse, während Sie den Beleidigungsgenerator für Endbenutzer testen.
  3. QA: Wird reichen. Oh, schau, der Beleidigungsgenerator hat bestanden!
  4. DEV: Großartig! Während Sie daran gearbeitet haben, habe ich den Embiggener erweitert. Versuche es noch einmal.
  5. QA: Es embiggen jetzt richtig. Lassen Sie uns gemeinsam zum nächsten Satz von Spezifikationen übergehen!

Wenn alles andere fehlschlägt, werfen Sie ein Licht auf dysfunktionale Prozesse

Wenn Ihr Team aus irgendeinem Grund nicht kooperativ über testbezogene Aktivitäten schwärmen kann oder will, muss der Prozess diese Kosten für das Team sichtbar machen . Wenn Entwickler und QA darauf bestehen, mit Aufgaben Volleyball zu spielen, indem sie Dinge über ein Netz hin und her werfen, anstatt sich zu integrieren, um die Arbeit gemeinsam zu erledigen, dann machen Sie diesen (möglicherweise dysfunktionalen) Prozess einfach vollständig sichtbar.

Haben Tester in der ersten Phase eines Sprints wirklich nichts zu tun? Nein, aber wenn das Ihr Prozess ist, erkennen Sie an, dass Tester, die einen halben Sprint lang im Team bleiben, einer der Kosten für die Geschäftstätigkeit sind. Wenn Entwickler in der zweiten Hälfte eines Sprints wirklich überhaupt nichts zum Testprozess beitragen können, dann erkennen Sie ausdrücklich an, dass Ihre Entwickler dafür bezahlt werden, 50 % der Zeit auf Facebook abzuhängen, und können dies akzeptieren Kosten für die Geschäftsabwicklung innerhalb des von Ihnen gewählten Prozesses.

Gesunde Teams behandeln alle Mitglieder als funktionsübergreifende Ressourcen, die in jedem Schritt des Prozesses einen Mehrwert bieten. Selbst wenn Sie das Testen nicht vollständig als erstklassige Aktivität in Ihre Sprints integrieren möchten, können sich Tester und Entwickler bei aktuellen Aufgaben gegenseitig unterstützen. Beispielsweise kann ein Tester während der Entwicklung zusammenarbeiten, um Testhalterungen zu entwerfen, während der Entwickler das Feature schreibt; Während des Testens kann der Entwickler dann eine Codeabdeckungsanalyse durchführen oder daran arbeiten, Testergebnisse in Dokumentation umzuwandeln, während der Tester die Tests durchführt.

Wenn das Team auf diese Weise nicht kooperativ arbeiten kann oder will, kann die Organisation einfach die Tatsache akzeptieren, dass einige Rollen innerhalb des Teams an bestimmten Stellen im Prozess untätig sind. Obwohl es nicht ideal ist, kann es politisch notwendig sein, einfach anzuerkennen, dass 50 % Ihrer Rollen zu einem bestimmten Zeitpunkt untätig sind und dass dies akzeptable Kosten für die Geschäftstätigkeit innerhalb Ihres aktuellen Entwicklungsprozesses sind. Ich persönlich halte dies zwar für eine suboptimale Option, aber es ist immer noch besser, als dem Trugschluss der 100%igen Auslastung zum Opfer zu fallen, der versucht, alle beschäftigt zu halten, selbst wenn dies verschwenderisch ist und keinen Wert generiert ... und manchmal sogar aktiv reduziert Produktivität.

Macht Sinn, @codegnome, was Sie vorschlagen, ist, dass ein QA und ein Entwickler weiterhin jeweils ihren Rollen folgen (die jeweils eine Stärke gegenüber dem anderen haben können), aber direkt von Beginn des Sprints an effektiver zusammenarbeiten das Ende?
@Tivep Das ist genau richtig. Es ist in Ordnung, in einem Sprint ungenutzte Zeit zu haben – tatsächlich ist ausreichend ungenutzte Zeit für Agilität unerlässlich – aber zu viel ungenutzte Zeit ist normalerweise ein Zeichen dafür, dass das Team mehr zusammenarbeiten, paaren oder schwärmen muss.

Sie könnten eine Reihe von Dingen tun. Was sie tun sollten, hängt von der Scrum/XP-Reife Ihres Unternehmens ab, aber hier sind einige allgemeine Punkte:

  • QA-Arbeit – Ja, Entwickler können QA, ob es nun darum geht, neue automatisierte Tests zu schreiben, die bestehende Testabdeckung zu erweitern oder die Testkomplexität zu reduzieren, manuelle Tests oder Leistungs-/Lasttests durchzuführen, Entwickler können und sollten QA durchführen. Das gesamte Team besitzt die Qualität des Produkts. Besonders disziplinierte Entwickler werden TDD verwenden, sodass die meisten Tests durchgeführt werden, bevor die Story an die Qualitätssicherung geht. Scrum-Teams mit 0 QA-Ressourcen sind weit verbreitet.

  • Tech-Schulden/Refactoring/Fehlerbehebung

  • Spikes für größere funktionale Stories kommen im nächsten Sprint

  • Erlernen neuer Fähigkeiten sowohl im Soft- als auch im technischen Bereich. Das Ende eines Sprints ist (wie jeder andere) eine großartige Zeit für kontinuierliche Verbesserungen. Haben Sie einen Entwickler, der denkt, es sei nicht seine Aufgabe zu testen. Koordinieren Sie ihn in der zweiten Hälfte des Sprints mit einer QA-Ressource.

  • Pflege des Backlogs/Arbeiten mit PO, um technische Überlegungen anzustellen.

  • Lernen, Geschichten/Aufgaben zu schreiben und zu pflegen, die klein sind, sodass nicht alle Tests in der zweiten Hälfte der Iteration stattfinden.

  • Verbesserung von Werkzeugen oder Prozessen rund um die kontinuierliche Integration.

Fazit: Wenn Ihre Entwickler in der zweiten Hälfte Ihrer Iteration untätig sind, während die QA Tests durchführt, haben Sie einige Möglichkeiten, die Vorteile echter Scrum/XP-Praktiken zu nutzen, anstatt das Mini-Wasserfall-Scrum zu leben.

Dank dafür. Es gibt dort einige nette Punkte @WBW, TDD wäre jedoch Teil der Dev-Aktivität und keine Post-Dev-Aktivität während der QA. Auch Unit-Tests und die Tests, die von einem QA durchgeführt werden, wären extrem unterschiedlich. Die Tatsache, dass dedizierte QAs kein Verständnis für die Programmierschwierigkeiten haben, ermöglicht es ihnen, die Rolle eines Benutzers zu übernehmen. Sehr gute Entwickler haben eine emotionale Bindung zum Code und können selten zu Pseudo-Nutzern werden. Diese beiden (QA und Dev) können nicht immer dieselbe Person sein, tatsächlich würde diese Entscheidung von der Art des Projekts abhängen.
Richtig, traditionelles TDD geschieht vor der Entwicklung. Es gibt eine weichere Form von TDD, bei der QA und Entwickler vor der Codierung zusammenarbeiten, um die Testfälle zu definieren (dies sind normalerweise detailliertere Versionen von AC, die auch Randfälle betreffen). Wirkt Wunder, wenn es darum geht, Entwickler und QAs dazu zu bringen, mehr zusammenzuarbeiten. Sorgt langfristig auch für weniger Fehler, da die Entwickler beginnen, nicht nur den Code zu schätzen, sondern auch das Geschäft dahinter. Ich würde Ihre Annahmen über QAs, die nicht sympathisieren, und Programmierer, die nur gut sind, weil sie emotional an den Code gebunden sind, in Frage stellen.
Geben Sie sich die Erlaubnis, ein echtes funktionsübergreifendes Team aus T-förmigen Personen aufzubauen, und Sie werden mit einem qualitativ hochwertigeren Produkt und oft hyperproduktiven Teams belohnt, die 300-400 % mehr leisten können als die traditionellen spezialisierten Mini-Wasserfall-Scrum-Teams.
Ich werde versuchen, das weiche TDD-Element hinzuzufügen. In Bezug auf das funktionsübergreifende Team, wie ich in einem anderen Kommentar erwähnt habe, würde das davon abhängen, in was die QA hineinwachsen möchte. Wenn er/sie sich zu einem Business Analyst weiterentwickeln möchte, wäre er/sie widerstandsfähiger gegenüber einer gründlichen Programmierung, was völlig fair ist. Ich muss Wachstumswünsche im Auge behalten und kann einen QA oder sogar einen UX-Designer nicht dazu zwingen, ein vollwertiger Entwickler zu werden. Jede Rolle hat etwas Einzigartiges zu bieten. Außerdem wäre dies auch ein Rekrutierungsalptraum.
Tolle Antwort @WBW. Unterstütze das voll und ganz. Ich habe gestern diesen Coaching-Vortrag vor einem erfahrenen Entwickler in einem Team gehalten.

"Normalerweise gibt es für ein Team von 3 bis 4 Entwicklern 1 QA-Ressource"

Da ist dein Problem. Es gibt drei Rollen in Scrum , Product Owner, Scrum Master und Mitglied des Entwicklungsteams. Ihr Entwicklungsteam soll ein multifunktionales Team sein, das auf die gleichen Ziele hinarbeitet. Es ist in Ordnung, Leute mit unterschiedlichen Fähigkeiten zu haben (in der Qualitätssicherung, in der Entwicklung), aber wenn Sie Teammitglieder haben, die nur sehr spezifische Dinge tun können (z. B. Tester, die nur manuelle Tests durchführen können), ist dies ein Problem, das Sie beheben müssen. Testautomatisierung ist eine nützliche Gemeinsamkeit zwischen Entwicklern und Testern.

QA als Funktion erfordert weit weniger technisches Wissen, selbst wenn sie Automatisierung betreiben. Beim QAs-Test sind sie eine Erweiterung der Endnutzer. Sie sind enger mit den Endverbrauchern verbunden. Die Entwickler kennen sich aus algorithmischer Sicht aus. Es wird nicht helfen, Devs und QAs zu denselben Personen zusammenzuführen.
Wenn nicht QA, dann müssen die Entwickler eine reduzierte Geschwindigkeit annehmen, um mit den Kunden / Benutzern zu kommunizieren, um Testszenarien, Testanzüge usw. zu entwickeln. Dies ist nicht umsetzbar, da ein großes Team immer noch eine sehr niedrige Geschwindigkeit und den Kunden haben wird würde ziemlich sauer werden.
@Tivep Ich frage nach T-förmigen Menschen. Einen QA-Experten für Testszenarien und Testsuiten zu haben, ist in Ordnung. Ihre Entwickler sollten wahrscheinlich sowieso mit Kunden sprechen. Ich sehe nicht, wie ein fähiges Team, das jederzeit zusammenarbeitet, die Geschwindigkeit verringern würde.
Sie sind technisch in der Lage. Aber er wird nicht in der Lage sein, ständig mit dem Kunden zu kommunizieren, da er auch ständig programmieren muss. Es gibt nur eine feste Anzahl von Stunden pro Tag, also müssen sie, um funktioneller beteiligt zu werden, etwas an Geschwindigkeit verlieren.
Tatsächlich kann ich Scrum nicht verwenden, wenn ich keine technofunktionalen Leute habe. Wenn es Alan Turings im Team gibt, mögen sie auf der technischen Seite fantastisch sein, aber Scrum wird mich daran hindern, diese Person effektiv einzusetzen. :(
@Tivep Ich würde es vorziehen, wenn Ihre Einstellung wäre: "Ich werde mein Team ermutigen und trainieren, um besser zu werden". Scrum hat einen Mangel in einem Team sichtbar gemacht, aber es liegt an Ihnen, wie Sie darauf reagieren.
Siehe @Nathan, das ist das Problem. Während ich vielleicht das Gefühl habe, dass ich einen Entwickler besser mache, indem ich ihn dazu bringe, sich auf UX, Domain, Funktionstests usw. zu konzentrieren, muss ich auch überlegen, ob der Entwickler das tun möchte. In den meisten Fällen möchten sie ihre Zeit nicht gleichmäßig zwischen dem Erlernen und Implementieren von Technologien und Fachkenntnissen aufteilen. Das muss ich ehren. Gleiches gilt für einen QA / BA, der sich mehr für das Produkt und seine Roadmap interessiert. Die Bereitstellung einer Web-App besteht aus Rollen wie UX, UI, App-Entwickler, QA. Eine Person kann leider niemals alle diese Rollen austauschbar spielen, insbesondere UX, da dies keine Technologie ist.
@Tivep: Niemand sagt, dass alle austauschbar/in allem gleich gut sein sollten. Das ideale Teammitglied ist ein Experte in einem oder zwei Bereichen und kann bei Bedarf einfache/grunzende Arbeiten in den anderen Bereichen übernehmen (als ob es sehr jung wäre). Wenn keine Entwicklungsarbeit abgeholt werden muss, sollte ein Entwickler bereit/bereit sein, den QA-Experten beim Testen des Produkts zu unterstützen, beispielsweise durch Ausführen vordefinierter Testfälle. Es kann länger dauern, außerhalb Ihres Fachgebiets zu arbeiten, aber das sollte kein Engpass sein.
„Sie sind technisch in der Lage. Aber sie werden nicht in der Lage sein, ständig mit dem Kunden zu kommunizieren, da sie auch ständig programmieren müssen.“ @Tivep Vorsicht vor dem Trugschluss der 100% igen Auslastung. Beachten Sie auch, dass der Großteil der Programmierung nicht auf einer Tastatur herumschlägt. Es versteht ein Problem. Geschwindigkeit ist ein Vektor. Es spielt keine Rolle, wie schnell Sie fahren, wenn es in die falsche Richtung geht. Vergessen Sie nicht, dass „Wochenlanges Programmieren eine Stunde Planung ersparen kann“. s/Planung/Gespräch mit Ihrem Benutzer
@Tivep Wenn alles, was Sie getan haben möchten, sowohl die Entwicklungsleitung als auch die Testleitung durchlaufen muss, bestimmt die kleinere, wie viel erledigt wird, und die größere verschwendet Kapazität. Daran führt KEIN Weg vorbei. Da das Hinzufügen weiterer Tester wahrscheinlich zum gegenteiligen Problem führen wird, ist die kanonische Lösung Cross-Funktionalität. Sie können dieses Problem mildern, indem Sie Ihre Tester enger mit den Entwicklern koppeln, sodass das Testen früher beginnen kann.

Es hört sich so an, als ob Sie nicht wirklich Scrum praktizieren, sondern „Timeboxed Waterfall“. Mit diesem Ansatz ist jeder Sprint ein eigenes Mini-Wasserfall-Projekt, mit der Entwicklung am Anfang und dem Testen am Ende. Wie Sie festgestellt haben, führt dies zu Zeitverschwendung, da Tester zu Beginn des Sprints wenig zu tun haben und Entwickler am Ende des Sprints wenig zu tun haben.

Stattdessen sollte das Team daran arbeiten, sicherzustellen, dass jeder so voll wie möglich beschäftigt ist ( Achtung, nicht zu 100 % ausgelastet, siehe Kommentare unten). Während der täglichen Standups und bei der Sprint-Planung sollte Ihr Team versuchen, herauszufinden, wie es den Testern sofort etwas liefern kann, und dies dann während des Sprints wiederholen, damit die Tester die Funktionalität in Teilen testen können, während sie geliefert wird.

Ein häufiger Teil des Standups könnte sein, dass ein Tester sagt, dass er später an diesem Tag nichts zu tun hat. Vielleicht bietet ein Entwickler dann an, ein paar Fehler zu beheben, von denen er weiß, dass sie an diesem Morgen geschlossen werden können, anstatt etwas Größeres zu beginnen. Das füllt dann eine Lücke für den Tester, während ein anderer Entwickler eine Arbeit fertigstellt, damit er morgen mit dem Testen beginnen kann. Niemand bricht sich den Magen, aber Sie haben einen höheren Arbeitsdurchsatz.

Ich verstehe. Aber wenn ein Sprint 2 Wochen dauert, wird es sehr schwierig, testbare Aufgaben zu haben, die 2 Tage lang sind. Damit QAs bereits in den ersten Tagen selbst getestet werden, müssten die einzelnen Aufgaben nur 2 Tage lang sein. Das ist aber nicht praktikabel :(
Diese Antwort ist eine Variante des Trugschlusses der 100 %-Auslastung . Das Ziel sollte niemals sein, „sicherzustellen, dass alle so voll beschäftigt wie möglich sind“. Das ist ein besonders ranziger Projektgeruch und normalerweise ein Zeichen für eine zutiefst fehlerhafte agile Implementierung.
@CodeGnome Ich bin irgendwie anderer Meinung. Ich habe mich entschieden, nicht auf das Konzept einer Auslastung von < 100 % als Ideal einzugehen, da dies die Antwort auf die gestellte Frage verwirrt hätte. Deshalb habe ich von „möglichst voll erwerbstätig“ und nicht nur von „100 % erwerbstätig“ gesprochen. Ich werde die Antwort bearbeiten, um sicherzustellen, dass mich niemand missversteht. Ich würde jedoch sagen, dass diese ganze Antwort keine Variation dieses Irrtums ist. Wenn Ihre Sprints kleine Wasserfälle sind, nutzen Sie die Teamzeit nicht vollständig. Der Versuch, das Problem zu beheben, indem Sie frühzeitig mehr Arbeit liefern, bedeutet nicht, dass Sie diesem Trugschluss zum Opfer gefallen sind
@Tivep Das letzte Unternehmen, bei dem ich gearbeitet habe, hat 2-wöchige Sprints durchgeführt und es geschafft, am ersten oder zweiten Tag des Sprints so ziemlich jedes Mal testbare Brocken zu liefern. Ihre Situation mag anders sein, aber ich würde wirklich gut darüber nachdenken, wie Sie dies möglich machen könnten. Gibt es wirklich keinen kleinen Teil dieser größeren Verbesserung, der vor dem Rest in den Test geliefert werden kann? Viele Unternehmen tun dies jeden Tag, bevor Sie entscheiden, dass es unmöglich ist, denken Sie darüber nach.
Ich habe ähnliche Erfahrungen gemacht. Die meisten Karten sollten in den Bereich von 1-3 Tagen fallen.

Es ist ein etwas ungewöhnliches Setup, das Sie dort haben, aber was Entwickler tun können, ist, sich auf den nächsten Sprint vorzubereiten, technische Herausforderungen mit den neuen User Stories zu lösen oder die vorhandene Codebasis umzugestalten.

Die zweite Option, das „Scrum Book“, würde vorschlagen, dass die Entwickler auch Tests durchführen sollen (Cross-Functional-Team-Idiom), natürlich kann ein Entwickler nicht testen, was er/sie implementiert hat.

Dritte Option: Vielleicht möchten Sie darüber nachdenken, zwei Sprints parallel, aber verschoben zu haben. Eine für die QA und eine für die Entwicklung. Die QA würde einen halben Zyklus später als die Entwicklung beginnen. Mit diesem Setup arbeiten Entwickler und QA, ohne lange Zeit untätig zu sein. Stellen Sie nur sicher, dass Sie in jedem Sprint Kapazität für Fehlerbehebungen haben, da sonst die Qualität des Codes abnimmt.

Vierte Option: Sie können einen weiteren QA beauftragen, um das Testen zu beschleunigen.

Sollte QA nicht idealerweise Teil von Sprints sein?
Es hängt von Ihrer Einrichtung ab. Die einen sagen, dass das sein sollte, andere sagen, sie können ihren eigenen Sprint haben. Es ist eine Clique, aber bei Agile geht es darum, herauszufinden, was gut für Sie ist . Wenn Sie in einem Sprint Probleme mit QA+Dev haben, probieren Sie etwas anderes aus und diskutieren Sie die Ergebnisse in einer Retrospektive.
Nein. Nicht das. Der Scrum-Leitfaden umfasst nur 16 Seiten und schließt ausdrücklich sowohl die Aufteilung von Teams nach Spezialgebieten ( "Keine Ausnahmen" ) als auch die Arbeit an Dingen außerhalb des Sprints aus. Wenn Sie der Meinung sind, dass Scrum falsch ist, und etwas anderes vorschlagen, seien Sie bitte deutlicher.
Niemand zahlt langfristig für untätige Entwickler. Entweder überzeugen sie Entwickler, QA durchzuführen – was ein hartes Geschäft ist – oder sie ändern ihre Arbeitsweise. Irgendwann werden sie einen Punkt erreichen, an dem die Abweichung von „nach dem Scrum-Buch“ unvermeidlich ist. Ich glaube, es liegt an @Tivep, wie sie weitermachen.
@Nathan, wäre es richtig zu sagen, dass das Scrum-Modell keine dedizierten Tester zulässt? Die Devs müssen als Tester fungieren?
@Tivep Ja. In der Praxis enthält die Entwicklerrolle eine so große Bandbreite an Verantwortlichkeiten (für automatisiertes Testen, Erstellen und Bereitstellen, Umgebungen usw.), dass die T-Form für andere Teammitglieder normalerweise eher ein Problem darstellt. Ich arbeite in einem Scrum-Team und arbeite immer auf die Ziele des Sprints hin, auch nachdem das letzte Feature eingecheckt wurde: Heute habe ich eine Menge automatisierter Testverbesserungen und tfs-Build-Magie vorgenommen. Ich vermute aufgrund dessen, was Sie über QA und Entwicklung gesagt haben, dass Sie an einem Ort arbeiten, an dem viele manuelle Tests durchgeführt werden: Ich würde das so schnell wie möglich beheben.
@Nathan, es wäre gut, solche Entwickler zu haben, aber normalerweise konzentrieren sich die Entwickler eher auf die Nuancen der Programmierung, Frameworks usw. Sie führen ständig POCs durch, um die technische Lösung zu bewerten. Sie sind in dieser Rolle äußerst produktiv. Wenn sie das Auge des Benutzers haben müssen, erfordert das andere Fähigkeiten. Hier brauchen wir ein scharfes Auge auf UX, Fachkenntnisse, funktionalen Fokus usw. Es ist normalerweise äußerst schwierig, Personen zu finden, die sich in beidem auszeichnen. Diese Nichtverfügbarkeit von Einzelpersonen macht Scrum hilflos.
Ein funktionsübergreifendes Team bedeutet nicht, dass jede Person im Team jeden Hut tragen muss. Es bedeutet nur, dass das Team als Ganzes über alle wesentlichen Fähigkeiten und Funktionen verfügt, die zur Vervollständigung jedes Features erforderlich sind.
Ich habe nicht geschrieben, dass jede Person jeden Hut tragen sollte.
@Tivep Scrum hindert Sie nicht daran, dedizierte Ressourcen in einem Team zu haben. Es besagt jedoch , dass das gesamte Team für alle Leistungen verantwortlich ist. Mit anderen Worten, „Joe“ ist vielleicht Ihr QA-Fachexperte, aber das gesamte Team ist dafür verantwortlich, dass Tests für jede Geschichte durchgeführt werden. Niemand darf sagen: "Oh, das ist Joes Job, weil er der QA-Typ ist." Allerdings stellen dedizierte Rollen anstelle von übergreifend geschultem Personal im Team ziemlich sicher, dass Sie Warteschlangenprobleme und Ressourcenbeschränkungen haben werden, also müssen Sie entweder ...
... akzeptieren Sie die reduzierte Produktivität oder schulen Sie Ihre Teammitglieder, damit jeder dort eingreifen kann, wo es nötig ist, auch wenn er nicht das KMU für diesen Wissensbereich ist.

Der Entwickler kann daran arbeiten, sowohl den Prozess als auch das Team durch mehrere Maßnahmen zu verbessern, die für das Ende des Sprints erforderlich sind, wie zum Beispiel:

  • Analyse der tatsächlichen vs. erwarteten Geschwindigkeit zur Verbesserung des Vertrauens
  • Kategorisierung der Fehlerursachen zur Vermeidung von Wiederholungsfehlern
  • Erstellung einer Itemliste für die Retrospektive zur Verbesserung der Zusammenarbeit
  • Kodierung manueller Tests in automatisierte Skripte zur Verbesserung der Effizienz

Verweise

Leider kann all dies erst geschehen, nachdem die QA abgeschlossen ist. QA ist ein wesentlicher Bestandteil für diese Diskussionen. Es würde keinen Sinn machen, sie wegzulassen.
@Tivep Was den letzten betrifft, wird dies für den Produktionscode durchgeführt, den die QA bereits überprüft hat, sodass sie weggelassen werden können.

Ich bin Entwickler.

Lassen Sie mich Ihnen sagen, was Sie falsch machen ...

Gar nichts! So ist Scrum aufgebaut und kein System ist perfekt. Kein Wunder, dass Sie gerade meine Antwort lesen, denn es handelt sich um ein universelles Scrum-Problem.

Folgendes sollten Sie nicht tun:

  1. Stellen Sie nicht mehr QA ein!
  2. Fordern Sie die Entwickler nicht auf, zu testen, obwohl der Code während der Entwicklung und während der PR-Überprüfungen getestet werden muss.
  3. Bitten Sie die Entwickler nicht, jemand anderem bei ihren Geschichten zu helfen, nein, sie brauchen keine Hilfe, es sei denn, sie wurde richtig kommuniziert.
  4. Nein, Entwickler sollten nicht "Paartests" durchführen, wie einige Antworten vorschlugen, beim Testen "zusammenzuarbeiten". QA-Mitglieder testen meinen Code. Sie werden mir Fehler zur Behebung liefern, wenn sie fertig sind, und ich werde sie beheben, und es geht weiter. ES GIBT NICHTS, DAS ICH TUN KANN ODER SOLLTE, während sie meinen Code testen, außer AUF SIE WARTEN!! Womit wir wieder dort wären, wo wir mit der Frage begonnen haben.

Hier ist, was ich am besten fand:

  1. Entwickler sollten ab dem nächsten Sprint an ihren Elementen weiterarbeiten.
  2. Schade, dass ich vorschlage, sich für die Zusammenarbeit zur Verfügung zu stellen, denn das sollte während des Sprints vom ersten Tag an so sein.
  3. Arbeiten Sie an Aufgaben, die Sie im Alltag nicht erledigen können, um Dinge rechtzeitig fertigzustellen.
  4. In einem früheren Unternehmen wurde diese Zeit in der Ausbildung verbracht.
  5. Haben Sie kleinere Stories, die in verschiedenen Phasen des Sprints enden, damit Sie keinen QA-Engpass erzeugen, wenn der meiste Code gegen Ende des Sprints getestet wird.

Wirklich, Nr. 1 (WORK AHEAD) hat mir am besten gedient, denn Nr. 2, Nr. 3 und Nr. 4 sollten während des gesamten Sprints durchgeführt werden, nicht nur, wenn der Code von der QA getestet wird!!!

Auch #5 versteht sich von selbst.

Also, ja ... Arbeiten Sie voraus!

Wenn ich meine Stories im aktuellen Sprint fertig habe, frage ich, mit welcher Story ich im nächsten Sprint beginnen soll.

Ich beginne mit einer Story aus dem folgenden Sprint, und weil ich früh angefangen habe, bevor der Sprint beginnt, beende ich meine nächsten Sprint-Storys (wenn auch nicht alle auf einmal) kurz nach Beginn des nächsten Sprints, Mitte des nächsten Sprints oder einige wenige Tage vor dem Ende (nicht ein oder zwei Tage vor dem Sprint Review).

Dadurch hat die QA genügend Zeit, meinen Code zu testen, und ich habe genug Zeit, um auf ihr Feedback zu reagieren. Außerdem bietet das Vorausarbeiten während des gesamten Sprints Testaufgaben für die QA, nicht nur in den letzten paar Tagen! Dadurch wird die QA-Arbeitslast ausgeglichen und nicht alles gegen Ende des Sprints.

Auch hier lautet die Antwort: WORK AHEAD!

Dadurch wird die Bereitstellung von Funktionen während des gesamten Sprintzyklus sichergestellt, wodurch die Testlast während des gesamten Sprints ausgeglichen wird!

Hier ist ein guter Artikel, den ich über meine Erfahrungen mit dem Thema geschrieben habe: Ich habe das Engpassproblem beim Agile-Testen gelöst!

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

Wer auch immer hier eine -1 gegeben hat, ich möchte wirklich gerne erfahren, warum Sie denken, dass meine einfache praktische Lösung Ihren agilen Standards nicht entspricht, lol
Danke für die Antwort. Nur um das klarzustellen, ich war es nicht, der die -1 gegeben hat. Aber ich kann mir den Grund vorstellen. Die Idee ist, die Antwort auf dieser Seite zu haben und nicht zu einem anderen Link gehen zu müssen, um sie nachzulesen. Es würde also helfen, den Inhalt in der Antwort zusammenzufassen und für die ausführliche Version auf jederzeit zu den Artikeln navigieren zu können.
Macht Sinn. Ich dachte wirklich, ich würde eine einfache, direkte Antwort geben. Danke schön. Ich habe meine Antwort aktualisiert.
Mann! Ich habe eine zweite -1 ... Ich aktualisiere meine Antwort erneut! Ja, es ist persönlich, dass jemand tatsächlich auf das hört, was ich aus Erfahrung gelernt habe, um unnötigen agilen Stress zu vermeiden, der aus der Unkenntnis der Scrum-Regeln resultiert.
Was wird von den Entwicklern während des Testens in der zweiten Hälfte jedes Sprints erwartet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v