Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Neben den Features einer Software hat die Qualität der Produkte eine überragende Bedeutung. Viele von Ihnen kennen noch den alten Ansatz, der daraus besteht, Qualität in das Produkt hineinzutesten.
Viel sinnvoller ist es aber, die Produkte gleich qualitätsgerecht zu entwickeln. Besonders vielversprechend ist eine Organisationsform, die die Qualität im Entwicklungsteam anordnet.
Sie werden es glauben, oder nicht: Die Google Suche, und dort insbesondere die erweiterte Suche sieht zwar einfach aus. Es ist aber bei Weitem nicht so tivial, wie es aussieht, diese Funktionalität zu testen. James Whittaker von Google beschreibt im Testing Blog mehrere Teile des Qualitätsprozesses der Firma Google.
Die Artikelserie besteht aus mehreren Artikeln. Heute hat es mir der erste Teil der Serie angetan, bei dem es um die Philosophie geht (siehe → How Google Tests Software – Part One).
Den alten Ansatz der Softwareentwicklung kennen Sie vom Frühstückstoast. Er lautet „Du verbrennst den Toast – Ich kratze ihn sauber“. In die betriebliche Realität übersetzt, könnte man auch sagen: „Die Entwicklung entwickelt, und das Qualitätswesen testet solange, bis die Fehler beseitigt sind“.
Wenn auch Sie dieser Satz an das oben gezeigte Video erinnert, haben Sie die alte Methode vielleicht sogar selbst kennengelernt.
Einige Vorteile sind schnell aufgezählt:
Die Nachteile lassen sich aber auch finden:
Bei Google ist das Entwicklungsteam verantwortlich für die Qualität. Die Tester haben lediglich die Aufgabe, die Entwickler methodisch dabei zu unterstützen, die Tests zu planen und durchzuführen. Der Vorteil dieser Vorgehensweise ist einfach: Die Verantwortung wird dorthin angeordnet wo sie hingehört (siehe → How Google Tests Software – Part One).
Yes, that’s right: at Google it’s the product teams that own quality, not testers. Every developer is expected to do their own testing. The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.
What I like about this strategy is that it puts developers and testers on equal footing. It makes us true partners in quality and puts the biggest quality burden where it belongs: on the developers who are responsible for getting the product right.
Es sind deshalb unterschiedliche Aufgaben von einem Produktowner, und dem Scrum Team zu leisten.
Einmal ist es notwendig für jede Entwicklungsaufgabe auch die notwendigen Qualitätsaufgaben zu planen. Diese bestehen meistens aus Tests zum Prüfen der Qualität der neuen Entwicklung, sowie aus Regressionstests, die dazu verwendet werden, die Funktionen der existierenden Software tournusmäßig zu prüfen (Schliesslich soll die neue Funktion so entwickelt werden, daß die existierende Software immer noch läuft).
Die Done Kriterien sind notwendig, damit der Produktowner entscheiden kann, ob ein Backlog Item erledigt ist, oder nicht. Mit den Done Kriterien werden standardisierte Qualitätsregeln festgelegt, die jeder Entwickler einhalten muss. Oft geben sich Teams eigene Kriterien.
Gerade am Anfang sind die Entwickler noch relativ unbelesen in den üblichen Techniken der Qualitätssicherung. Daher sollten gerade am Anfang Aufgaben vorgesehen werden, über die es gelingt, das Team in die Testthemen einzuarbeiten.
Ein wichtiges Element ist die offene und transparente Rückmeldung, die das Team benötigt, um den Qualitätsstatus jederzeit zu verstehen. Es ist daher notwendig Backlog Items vorzusehen, die genau diesem Reporting gewidmet sind.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
