Stellen Sie sicher, dass Entwickler die Anforderungen befolgen und ihren Code testen

Das klingt nach einem Problem der Teamreife in Bezug auf die Softwareentwicklung im Allgemeinen und die agile Softwareentwicklung im Besonderen; selbst eingeschlossen. Ich sage dies nicht als scharfe Kritik, sondern nur als Beobachtung, die auf den folgenden Beweisen basiert.

1. Die Problembeschreibung ist sehr tool- und prozesszentriert (JIRA, Gherkin etc.); wohingegen die Denkweise der agilen Softwareentwicklung dazu tendiert, sprechende Menschen zu bevorzugen. (Erster agiler Wert.)
2. Es hört sich so an, als gäbe es keinen Scrum Master oder Coach (jemanden wie mich, der hilft, das Team zu führen und zu konditionieren), nur eine PM (und Sie selbst ... vielleicht sind Sie der Coach??); und PMs existieren nicht wirklich in Scrum (oder einem mir bekannten agilen Framework; die Verantwortlichkeiten, die normalerweise von einem PM wahrgenommen werden, sind auf das gesamte Team verteilt).
3. Es scheint auf Ihrer Seite den Wunsch zu geben, Konflikte zu vermeiden, was für Technologie-Leute ziemlich normal ist. Nachdem ich das gesagt habe ...
4. Letztendlich erstellen wir jeden Sprint potenziell auslieferbare Inkremente, wenn wir (das Team als Ganzes, Sie, der PM, QA, die Entwickler) es nicht geschafft haben, ein potenziell auslieferbares Inkrement zusammenzustellen, dann sind wir gescheitert. Es ist nicht der Entwickler oder QA oder der PM oder wer auch immer schuld ist. Wir als Team sind gescheitert. Warum hat sich das Team nicht an die Anforderungen gehalten? Warum hat das Team keine besseren Anforderungen geschrieben? Warum ist QA ein separates Team und wird als Schritt in einem Prozess betrachtet (Scrum ist kein Prozess)?
5. Es scheint so, als ob sich Ihr Team sozusagen in der „Shu“-Phase befindet. Daran ist nichts auszusetzen, wir alle schwanken; der schwierige Teil ist, es zu realisieren. Das Problem/die Frage verwendet „Agile“-Begriffe, scheint aber das Mischen unterschiedlicher Verständnisse dieser Begriffe zu beinhalten … nicht jeder verwendet zum Beispiel den Begriff „episch“ auf die gleiche Weise. Also zu sagen, dass jede User Story ein Epos ist, sagt nicht wirklich etwas aus.

Zur Frage:

1. Holen Sie sich einen Trainer; entweder für dich selbst oder für deine Crew. Vorzugsweise nicht jemand, der neu im Coaching ist. (Ich neige dazu zu glauben, dass es besser funktionieren kann, neuere Trainer mit erfahrenen Teams zu paaren und umgekehrt … aber ich könnte mich irren, es gibt immer Ausnahmen.)
2. Vereinfachen Sie Ihre Terminologie innerhalb Ihres Teams und verstehen Sie, dass Personen außerhalb Ihres Teams möglicherweise nicht dasselbe Verständnis haben. Zum Beispiel empfehle ich, den Begriff Feature und nur Feature zu verwenden, um das zu beschreiben, was ein Benutzer mit dem Produkt machen kann (kein Epic, keine User Story, vergiss Bananen) ... alles andere ist nur eine Ebene der Komplexität und Abstraktion, die meinen zerbrechlichen Verstand ärgert. „Ich muss nicht denken, oh, wir reden über ein Epos, das heißt, ein Feature, das diese Qualitäten hat “; stattdessen ist es „wir sprechen über eine Funktion … etwas, das ein Benutzer tun möchte“ (wie lange es dauert, wie viel Aufwand, spielt keine Rolle). Aber das bin ich. Das mag bei anderen nicht funktionieren. Was uns zu...
3. Haben wir ein potenziell lieferbares Inkrement erstellt? Wenn nein, warum nicht? Und wie reagiert das Team? Diese Fragen sind mein Mantra für die Sprint Retrospektive. Nein haben wir nicht; die Entwickler sagen, es sei die Schuld der QA, nicht schnell genug zu sein; QA sagt, es sei die Schuld des Entwicklers, die Anforderungen nicht zu erfüllen; Die Entwickler sagen, dass die spezielle Beschwerde darauf zurückzuführen ist, dass die PO von vornherein keine guten Anforderungen geschrieben hat. Die PO sagt, dass die Entwickler nie Fragen zu den Anforderungen gestellt haben, also dachte ich, sie hätten es verstanden; und jemand, der in der Position ist, in der Sie sich befinden, steckt fest und fragt: „Wem glaube ich?“ (Aber aus der Problembeschreibung geht hervor, dass Sie sich mehr für die Qualitätssicherung und die Bestellung als für die Entwickler einsetzen, warum ist das so? Oder Sie könnten genau wissen, warum die Entwickler an diesem Punkt nicht liefern können, Führen Sie ein Experiment durch, um zu sehen, ob dies wirklich der Fall ist, könnte jedoch ein teures Experiment werden.) Und diese Art der Interaktion zeigt einen Mangel an Vertrauen und das Vorhandensein von Abwehrhaltung, Angst usw. innerhalb des Teams. Die extreme Alternative besteht darin, dass die Entwickler die QA fragen: „Wie können wir Ihre Arbeit erleichtern?“ (Eher eine Lean-Denkweise.) Und die Qualitätssicherung verlangt die gleichen Dinge von den Entwicklern. (Weniger, wer schuld ist, und mehr, wie kann ich helfen). Wieder Frage der Mannschaftsreife.
4. Holen Sie sich einen Trainer. Nur zur Wiederholung. Jemand, der darin geschult und erfahren ist, Menschen, Spieltheorie und Wirtschaft zu beobachten (es scheint, als ob Technologie für Sie nicht wirklich ein Anliegen ist, also würde jemand wie ich – Entwickler mit UX-Hintergrund – die Lücke verstärken … aber Sie könnten es sein gehen die geschäftliche Perspektive und der Druck zur Neige). Auch hier könnte es nur ein Coach für Sie selbst sein, der Sie bei Ihrem Weg zur kontinuierlichen Verbesserung unterstützt ... vorzugsweise jedoch für das Team.

Ich hoffe, das hilft.

https://en.m.wikipedia.org/wiki/Shuhari

Folgende mögliche Probleme sehe ich:

• Überschuldung. Wenn Ihre Qualität nach dem Testen und Reparieren immer noch fehlt, dann haben Sie sich offensichtlich mehr vorgenommen, als Ihr Team bewältigen kann.

• Definition von Done. Sie scheinen entweder keine ausreichend starke Definition von Erledigt zu haben oder Sie scheinen sie zu ignorieren und sich neuen Aufgaben zuzuwenden, ohne die aktuellen tatsächlich zu erledigen.

• Mangelnde Prüfung. Einige schnelle Recherchen zeigen, dass Ihr 3:2-Verhältnis auf der Testseite bereits ziemlich großzügig ist. Verwendet Ihre Qualitätssicherung hauptsächlich manuelle Tests? Verwenden Sie Gherkin nur zur Spezifikation oder führen Sie auch Tests damit durch? Wie ist die Aufteilung der Verantwortlichkeiten in Bezug auf das Testen zwischen Ihrer QA und Ihren Entwicklern? Oder anders gefragt: Wenn Ihre Entwickler Software in der Qualität an QA liefern würden, die Sie von ihnen erwarten. Was müsste QA noch tun? Und was machen sie jetzt zusätzlich?

Ohne weitere Details zu kennen, ist es ziemlich schwierig, konkrete Schritte vorzuschlagen. Das Beste, was Sie tun können, ist mit Ihrem Team zu sprechen und herauszufinden, warum die Dinge so laufen, wie sie sind. Was sagt der Scrum Master? Was sagt das Team in den Rückblicken? In Ihrem Team / Ihrer Abteilung gibt es höchstwahrscheinlich soziologische Probleme.