Jemand in meinem Unternehmen hat kürzlich Änderungen an unserem Kernprodukt vorgeschlagen, von denen unsere Manager glauben, dass sie einen aus meiner Sicht vollständigen QS-Zyklus auslösen sollten (dh das Testen der gesamten Produktsuite von Grund auf). Anscheinend dauert unsere QS 12 Wochen, um einen vollständigen QS-Zyklus für unser Produkt durchzuführen. Mein Problem dabei ist, dass wir versuchen, eine agile (obwohl meiner Meinung nach meistens halbherzige) Entwicklung durchzuführen. Wir werden eine ganze Reihe von Sprints machen und dann eine Veröffentlichung, die QS wohl ewig dauern wird. Die Frage ist wirklich, ob unsere Qualitätssicherung 12 Wochen in Anspruch nehmen wird, um ihre Arbeit zu erledigen. Sollten wir nicht einfach aufgeben, zu versuchen, Agile zu machen? Was zum Teufel ist der Grund, in einer solchen Situation zu versuchen, Agile zu machen?
Sollten wir aufhören zu versuchen, agil zu sein, wenn die Qualitätssicherung 12 Wochen dauert?
Antworten:
Nun, die direkte Antwort auf Ihre Frage wäre Mu. Ich fürchte, es gibt einfach nicht genug Details, um eine fundierte Vermutung anzustellen, ob Sie aufhören sollten oder nicht.
Das einzige, worüber ich ziemlich positiv bin, ist, dass das Maß an Agilität von den Kunden- / Marktbedürfnissen bestimmt werden sollte (über die Sie keine Informationen angegeben haben).
- Als IDE-Benutzer bin ich beispielsweise sehr glücklich, ein- oder zweimal im Jahr ein Upgrade auf eine neue Version durchzuführen, und habe es nie eilig, dies zu tun. Dh wenn ihr Release-Zyklus 3 Monate ( 12 Wochen ) beträgt, bin ich damit vollkommen zufrieden.
Andererseits kann ich mir leicht vorstellen, dass ein Finanzhandelsunternehmen bankrott geht, wenn es mehr als einen Monat dauert, bis sich seine Software an die Marktveränderungen anpasst - ein Testzyklus von 12 Wochen wäre in diesem Fall ein Weg zur Hölle. Nun - was sind Ihre diesbezüglichen Produktbedürfnisse?
Eine andere zu berücksichtigende Sache ist, welches Qualitätsniveau erforderlich ist, um Ihre Kunden- / Marktanforderungen zu erfüllen?
- Ein Beispiel: In einem Unternehmen, in dem ich einmal gearbeitet habe, mussten wir feststellen, dass ein Produkt, das von einem Softwarehersteller lizenziert wurde, über einige neue Funktionen verfügt. Ohne dieses Feature haben wir ziemlich stark gelitten, also wollten wir wirklich, dass sie agil sind und innerhalb eines Monats ein Update liefern.
Und ja, sie schienen agil zu sein und ja, sie haben dieses Update in einem Monat veröffentlicht (wenn ihr QS-Zyklus 12 Wochen beträgt, haben sie es wahrscheinlich einfach übersprungen). Und unser Feature hat sehr gut funktioniert - hätten wir uns wirklich darüber freuen sollen? Nein! Wir haben einen Fehler in der Showstopper-Regression in einigen Funktionen entdeckt, der zuvor einwandfrei funktionierte. Daher mussten wir mit einer älteren Version hartnäckig leiden.
Ein weiterer Monat verging - sie veröffentlichten eine weitere neue Version: unser Featurewar da, aber der gleiche Regressionsfehler war auch da: Auch hier haben wir kein Upgrade durchgeführt. Und noch einen Monat und noch einen.
Am Ende konnten wir nur ein halbes Jahr später so viel für ihre Agilität aufrüsten.
Schauen wir uns diese 12 Wochen etwas genauer an .
Welche Optionen haben Sie in Betracht gezogen, um den QS-Zyklus zu verkürzen? Wie Sie aus dem obigen Beispiel ersehen können, führt ein einfaches Überspringen möglicherweise nicht zu den erwarteten Ergebnissen. Daher sollten Sie besser agil sein und verschiedene Lösungsansätze in Betracht ziehen .
Haben Sie zum Beispiel überlegt, wie Sie die Testbarkeit Ihres Produkts verbessern können?
Oder haben Sie eine Brute-Force-Lösung in Betracht gezogen, um einfach mehr QA einzustellen? So einfach es auch aussieht, in manchen Fällen ist dies tatsächlich der richtige Weg. Ich habe gesehen, wie das unerfahrene Management versucht hat, Probleme mit der Produktqualität zu beheben, indem blindlings immer mehr leitende Entwickler eingestellt wurden, bei denen nur zwei durchschnittliche professionelle Tester ausreichen würden. Ziemlich erbärmlich.
Das letzte, aber nicht das letzte - ich denke, man sollte sehr agil sein, wenn es um die Anwendung agiler Prinzipien geht. Ich meine, wenn die Projektanforderungen nicht flexibel sind (stabil oder sich langsam ändern), warum dann die Mühe machen? Ich habe einmal beobachtet, wie das Top-Management Scrum zu Projekten gezwungen hat, auf die es sehr gut ankam. Was für eine Verschwendung. Es gab nicht nur keine Verbesserungen bei der Bereitstellung, sondern Entwickler und Tester waren auch alle unzufrieden.
Aktualisierung auf der Grundlage von Erläuterungen in den Kommentaren
Für mich ist es einer der wichtigsten Teile von Agile, am Ende jedes Sprints eine versandfähige Version zu haben. Das impliziert mehrere Dinge. Zunächst muss ein Testlevel durchgeführt werden, um sicherzustellen, dass keine Showstop-Bugs auftreten, wenn Sie glauben, dass Sie das Build für einen Kunden freigeben könnten ...
Lieferbare Version, wie ich sehe. Hm. Hmmm. Erwägen Sie, Ihrem Agile-Cocktail ein oder zwei Spritzer Lean hinzuzufügen . Ich meine, wenn dies kein Kunden- / Marktbedürfnis ist, dann würde dies nur eine Verschwendung von (Test-) Ressourcen bedeuten.
Ich sehe nichts Verbrecherisches darin, Sprint-End-Release als nur einen Kontrollpunkt zu behandeln , der das Team zufriedenstellt.
- dev: Ja, das sieht gut genug aus, um es an Tester weiterzugeben. QA: Ja, das sieht für den Fall gut genug aus, wenn weitere Versandtests erforderlich sind - solche Sachen. Team (dev + QA) ist zufrieden, das wars.
... Der wichtigste Punkt, den Sie angesprochen haben, war das Ende Ihrer Antwort in Bezug auf die Nichtanwendung von Agilität, wenn die Anforderungen nicht agil sind. Ich denke, das ist genau richtig. Als wir anfingen, agil zu arbeiten, wurde es angewählt, und die Umstände ergaben einen Sinn. Aber seitdem haben sich die Dinge dramatisch verändert und wir halten an dem Prozess fest, in dem es möglicherweise keinen Sinn mehr ergibt.
Du hast es genau richtig. Auch von dem, was Sie beschreiben, sieht es so aus, als wären Sie zum Status gelangt (Team- / Management-Reife und Kundenbeziehung), sodass Sie anstelle von Scrum eine regelmäßige iterative Modellentwicklung verwenden können. Wenn ja, dann könnten Sie auch daran interessiert sein, dass sich nach meiner Erfahrung in Fällen wie diesem regulären iterativen Verfahren produktiver anfühlte als bei Scrum. Viel produktiver - es gab einfach so viel weniger Overhead, es war einfach so viel einfacher, sich auf die Entwicklung zu konzentrieren (damit sich die Qualitätssicherung auf das Testen konzentriert).
- Normalerweise denke ich an Ferrari (als reguläre Iteration) und Landrover (als Scrum).
Wenn Sie auf einer Autobahn fahren (und Ihr Projekt scheint diese Autobahn erreicht zu haben ), schlägt Ferrari die Hölle vor Landrover.
Es ist das Gelände, auf dem man keinen Sportwagen braucht - ich meine, wenn Ihre Anforderungen unregelmäßig sind und / oder wenn die Teamarbeit und die Managementerfahrung nicht so gut sind, müssen Sie sich für Scrum entscheiden - einfach, weil Sie versuchen, regelmäßig zu fahren festgefahren - wie Ferrari im Gelände festgefahren ist.
Unser vollständiges Produkt besteht wirklich aus vielen kleineren Teilen, die alle unabhängig voneinander aufgerüstet werden können. Ich denke, unsere Kunden sind sehr bereit, diese kleineren Komponenten viel häufiger zu aktualisieren. Es scheint mir, dass wir uns vielleicht darauf konzentrieren sollten, diese kleineren Komponenten am Ende der Sprints freizugeben und zu testen ...
Oben klingt nach einem guten Plan. Ich habe einmal in einem solchen Projekt gearbeitet. Wir haben monatliche Releases mit Aktualisierungen in kleinen risikoarmen Komponenten ausgeliefert.
- Eine Sache, die Sie bei dieser Strategie berücksichtigen sollten, ist eine überprüfbare Bestätigung, dass Änderungen an den erwarteten Stellen lokalisiert werden. Selbst wenn dies bis zum bitweisen Dateivergleich für Komponenten reicht, die sich nicht geändert haben, sollten Sie es versuchen, sonst wird es nicht ausgeliefert. Es ist die Qualitätssicherung, die für die Veröffentlichungsqualität verantwortlich ist, nicht wir Entwickler.
Es ist das Problem des Testers, dafür zu sorgen, dass unerwartete Änderungen nicht übersehen werden - denn ehrlich gesagt, als Entwickler habe ich genug andere Dinge, um die ich mich sorgen muss. Das ist mir wichtiger. Und deswegen brauchen sie (Tester) wirklich einen soliden Beweis dafür, dass die Dinge unter Kontrolle sind, mit der Freigabe, die sie testen, um sie zu versenden.
Oh, ich fühle deinen Schmerz. Es gibt einige gravierende Änderungen, die Sie am QA-Team vornehmen müssen, damit dies funktioniert.
Mein Rat ist, das Team in drei Teams aufzuteilen:
Funktionstests - Schnelle Erprobung neuer Entwicklungen.
Regressionstest - Testen Sie das Produkt vollständig, bevor es aus der Tür geht. Dies sollte nicht länger als 3 Monate dauern, auch wenn die Teamgröße reduziert wurde, da die meisten Fehler vom ersten Team gefunden werden.
Automatisiertes Testen - Erstellen Sie eine vollständige Reihe von Regressionstests, um die Arbeit des Regressionstest-Teams zu beschleunigen.
Das dritte Team ist ein Bonus, aber wenn Sie die ersten beiden Teams nicht haben können, können Sie auch ein Wasserfall sein.
Zur Veranschaulichung:
Beachten Sie, dass Ihr QA-Team wahrscheinlich außerhalb des (ATDD-) Kreises arbeitet und Sie innerhalb dieses Kreises arbeiten.
Ich denke, es ist in Ordnung, so zu arbeiten. Wenn Sie in Ihren automatisierten Tests nachweisen können, dass Sie die Anforderungen des Kunden für jeden Sprint erfüllen, können Sie der Qualitätssicherung gestatten, ihre Tests nach Belieben durchzuführen und mit Fehlern zu Ihnen zu kommen, die Sie dann in den nächsten Sprint einarbeiten können.
Es hört sich so an, als hätten Sie ein Problem mit der "Definition of Done".
Da es sich bei Ihrer QS-Gruppe um eine externe Gruppe handelt, die nur an Kundenfreigaben beteiligt ist, können Sie sich nicht auf sie verlassen, um rechtzeitig Feedback zu Problemen zu erhalten. Das bedeutet, wenn Sie schnelles Feedback wünschen, müssen Sie einige Tests "in-house" für das Team mitbringen.
Behandle die QS-Gruppe so, als ob sie nicht existiert. Dies ist der Fall, wenn Ihre Veröffentlichung am Ende des Sprints am nächsten Tag in Ihrer kritischsten Umgebung bereitgestellt wird. Die Software wird erst fertiggestellt, wenn sie bereit ist, an die Kunden zu gehen.
QA sollte nichts finden.
Dies wird schwieriger zu erreichen sein. Sie werden wahrscheinlich einige Dinge haben, die sich die ersten Male durchschleichen. Automatisierte Akzeptanztests und "Regressionstests" sind hier Ihre besten Freunde. Mit TDD können Sie große Teile solcher Suiten aufbauen. Sie sollten in der Lage sein, schnell zu wissen, ob Sie etwas kaputt gemacht haben.
Haben Sie einen Kundenvertreter / Produktbesitzer, der eine bestimmte Version sehen kann, bevor die Qualitätssicherung abgeschlossen ist, und der Ihnen eine maßgebliche Rückmeldung gibt? In diesem Fall können Sie agile Methoden anwenden und den größten Nutzen daraus ziehen, während Sie die Qualitätssicherung als sekundäre, etwas langsame Quelle für Rückmeldungen behandeln. Eine Veröffentlichung wäre erst "offiziell fertig", nachdem die Qualitätssicherung abgeschlossen ist, aber Sie müssten nicht auf sie warten, bevor Sie mit der nächsten beginnen.
Wenn die Unternehmensregeln jedoch vorsehen, dass der Kunde eine Freigabe nicht sehen darf, bevor die Qualitätssicherung abgeschlossen ist, können Sie die Agilität so gut wie vergessen, bis Sie es geschafft haben, diese Regeln zu ändern.
Der von Ihnen beschriebene Prozess ist kein agiler Prozess. Teams mit einem hohen Maß an Beweglichkeit sind in der Lage, bei jedem Sprint zuverlässige und potenziell lösbare Builds zu liefern. In den meisten agilen Implementierungen ist die QS-Funktion im agilen Team integriert, um dieses Ziel zu erreichen.
Wenn Sie, Ihr Projektleiter, Ihr Product Owner und die Entwickler nicht zusammenarbeiten und keinen Verbesserungsplan (Rückblick) haben, geben Sie Ihrem Prozess einen anderen Namen und fahren Sie fort. Es scheint nicht, dass die Probleme Ihres Teams die Schuld der Manager oder der Qualitätssicherung sind. Sie scheinen auf ein systemisches Problem zu reagieren, das von der Entwicklungsorganisation ausgeht. Es geht nicht alles verloren, wenn das Team bereit ist, Verantwortung zu übernehmen und mit Stakeholdern zusammenzuarbeiten.
Sie könnten drei Dinge versuchen. Erstens: Stellen Sie sicher, dass jeder Stakeholder genau definierte Rollen hat und dass jede Person ihre Verantwortung versteht. Zweitens: Stabilisieren Sie den Build und lassen Sie sich von der Qualitätssicherung abmelden, ohne weitere Änderungen vorzunehmen. Drei, Institut Testautomatisierung. Das QA-Team wird Sie dafür lieben.
Es ist schade, dass das Feedback so lange dauert, aber ich denke nicht, dass es sich lohnt, mit Agile aufzuhören. Am Ende eines Sprints (oder eines Paares) bringen Sie ein Produkt heraus, von dem Sie sicher sind, dass es auf den Markt gebracht werden kann. Für Ihr Team bringt Agile die Fähigkeit mit sich, sich auf die zu erledigende Arbeit zu konzentrieren und das Produkt freizugeben. Wenn die Qualitätssicherung Probleme findet, schlage ich vor, Fehlerberichte für diese Probleme zu erstellen und diese im nächsten Sprint zu beheben (wenn sie eine ausreichend hohe Priorität haben).
Unsere Produktfeldtests dauern ganze 8 Wochen und wir sind von externen Züchtern abhängig. Dank unserer agilen Arbeitsweise können wir uns auf die Arbeit konzentrieren und bei Bedarf sehr schnell eine neue Version erstellen.
Das Problem liegt (in Ihren Augen) in der Qualitätssicherung. Kann das Problem dort gelöst werden? Hast du darüber gesprochen?
Was machen die QA-Mitarbeiter, während Sie mehrere Sprints ausführen? Klingt so, als müssten sie nach jeder Änderung alles testen (weshalb sie auf eine ganze Reihe von Änderungen warten).
Das Entwicklerteam ist agil, der Rest des Unternehmens jedoch nicht.
Wer für die Qualitätssicherung verantwortlich ist, weiß entweder nicht, was er / sie tut, oder sie haben einen Jedi-Mind-Trick am oberen Management durchgeführt und dürfen sich die Zeit nehmen. Wie kann die Qualitätssicherung länger dauern als die Entwicklung?