Auf Scrum umgestellt, führen Entwickler jetzt nur noch QA durch

Scrum hat nichts mit Entwicklung oder QA oder so etwas zu tun. Es ist wirklich nur eine Philosophie, um bessere Schätzungen zu erstellen, indem die Sichtbarkeit des Fortschritts verbessert und auch eine stärkere Kommunikation zwischen den Teammitgliedern gefördert wird.

Agil ist genau dasselbe.

Ihre bessere Wette wäre, die Opportunitätskosten zu erklären - dass Entwickler (im Allgemeinen) mehr kosten als dedizierte QA. Trotzdem kann es sein, dass Ihre Entwicklungspraktiken schäbig sind und Sie zu viel QS-Arbeit erstellen, und diese "Entwickler, die als QS Schwarzarbeit machen" zwei Dinge tut

1. Sie dazu bringen, den QA-Rückstand zu lösen
2. Stellen Sie sicher, dass Sie den QA-Rückstand nicht erweitern

Ich bezweifle, dass es eine Mr. Miyagi-Lektion oder so etwas ist. Sie sollten jedoch besser darüber nachdenken, wie Sie die QA automatisieren können, anstatt sich zu beschweren, dass Sie die QA nicht mögen.

In Anbetracht dessen, dass Sie den ganzen Tag nur QA tun, sollten Sie eine sehr gute Vorstellung davon haben, was die Schritte sind und wie der QA-Prozess abläuft. Finden Sie heraus, wie Sie das (ganz oder teilweise?) automatisieren können, zeigen Sie das dem Management, bauen Sie dieses Tool auf. Das ist eine gute Möglichkeit, eine Beförderung zu erhalten, indem Sie Initiative zeigen, etwas aufbauen und mit der Qualitätssicherung aufhören.

Beachten Sie, dass Sie Ihr QA-Tool immer noch einer QA unterziehen müssen, sodass Sie die QA mit dieser Idee nicht vollständig stoppen können.

Ich vermute, dass etwas passiert ist, das einen Ruf nach einem weitaus strengeren QA-System hervorruft. Das Management kümmert sich nicht wirklich darum, wer das macht, aber sie wollen, dass es richtig gemacht wird, und sie wollen die Ergebnistabellen an Leute schicken, die sich um diese Dinge kümmern.

Zu sagen, dass QA „Teil von Scrum“ ist, bedeutet nicht wirklich viel und ist hier nicht wirklich relevant. Der Kern des Problems besteht darin, dass noch mehr QA-Arbeit geleistet werden muss.

Da Ihr Team so gut wie vollständig mit QA beauftragt ist, können Sie es wirklich nur durchführen und diese Aufgabe nach besten Kräften erledigen. Die Werkzeuge wegzulegen und zu sagen: „Wir sind Ärzte, keine Warpkerntechniker“, wird dem Projekt im Moment nicht wirklich helfen.

In Zukunft müssen Sie entweder ein dediziertes QA-Team einstellen/mit Ressourcen ausstatten oder einen formelleren QA-Stream in Ihre Entwicklungsmethodik einbauen.

Besprechen Sie dies mit Ihren Vorgesetzten, wenn die aktuelle Testphase abgeschlossen und die Panik vorbei ist. Wenn sich dies im Laufe der Zeit nicht ändert, muss sich das Management mit der daraus resultierenden Fluktuation befassen, die dadurch verursacht wird, dass Menschen die Jobs erledigen wollen, für die sie ursprünglich beschäftigt waren.

Ein wichtiger Aspekt von Scrum ist, dass das Team zusammenarbeitet, um eine Arbeitseinheit in einem kurzen Zeitraum zu liefern. Die Lieferung einer Arbeitseinheit umfasst alles, was erforderlich ist, um die Arbeit als abgeschlossen zu betrachten. Dies kann Design, Codierung, Bereitstellung, Qualitätssicherung usw. sein. Alle sind gemeinsam für alle Aspekte der Arbeit verantwortlich.

Jeder Teil der Arbeit sollte von den Personen ausgeführt werden, die dazu in der Lage sind, die Arbeit auszuführen. Das bedeutet, dass die Entwickler helfen sollten, wenn Qualitätssicherungsarbeiten durchgeführt werden müssen, es sei denn, sie müssen auch etwas anderes tun. Dieser Ansatz hat eine Reihe von Vorteilen. Es legt Wert darauf, etwas Nützliches zu liefern. Eine bestimmte Aufgabe wie das Codieren ist nicht wichtig. Es ist wichtig, alles Notwendige zu tun, um die Arbeit abzuschließen. Zweitens bricht es die Silos zwischen verschiedenen Fähigkeiten auf, darunter Softwareentwickler, Qualitätssicherung, Betrieb usw. Niemand kann seinen Beitrag leisten, ohne zu berücksichtigen, wie sich dies auf alle anderen auswirkt.

Dies ist für viele Menschen eine zufriedenstellendere Art zu arbeiten, da Sie, anstatt alleine an bestimmten Aufgaben zu arbeiten, die Freiheit innerhalb des Teams erhalten, sich selbst zu organisieren, um ein Build-Ding zu liefern.

Wenn die Qualitätssicherungsarbeit zu viel Zeit in Anspruch nimmt, obwohl Sie nicht zu Scurm gewechselt sind, dann haben Sie ein Problem identifiziert, das Sie schon immer hatten. Ihr Team sollte daran arbeiten, Wege zu finden, um die Qualitätssicherung effektiver durchzuführen. Dies kann die Einstellung der Fähigkeiten im Team ändern, um spezifischere Fähigkeiten zur Qualitätssicherung zu haben, oder es kann sein, dass die Softwareentwickler an automatisierten Tests oder Code-Refactoring arbeiten, um die Testbarkeit der Arbeit zu verbessern.

Wenn Entwickler denken, dass sie nicht an Qualitätssicherungsaufgaben arbeiten sollten, dann ist die Arbeit in einer agilen Umgebung nichts für sie. Sie sollten losgelassen werden, damit sie irgendwo arbeiten können, wo sie codieren und die Qualität das Problem von jemand anderem sein lassen können.

Wie ich in einem Kommentar zur ursprünglichen Frage erwähnt habe, denke ich, dass dies die Art und Weise des Managements ist, zu behaupten, Agile zu betreiben, während Wasserfall tatsächlich aufrechterhalten wird. Insbesondere,

Wir prüfen neue Anwendungsfälle, an die noch nicht gedacht wurde

klingt sehr danach, als würde man Monate damit verbringen, das gesamte Produkt zu entwerfen, bevor man mit dem Codieren beginnt.