Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Die Frage taucht ja gerne mal wieder auf, und beschäftigt dann den oder die Product Owner: Soll das Scrumteam lieber ein Feature mehr entwickeln, oder sollte man die Zeit in einen Test stecken, der dazu dient, die Qualität zu verbessern.
Heute geht es um die Frage, wie wichtig ein neuer Ansatz für viele IT Unternehmen ist. Oft drückt der Markt, und fordert „Feature, Feature, Feature“. Sie werden aber sehen, daß es durchaus sinnvoll sein kann, auch mal nicht auf den Markt zu hören, und statt ein Feature zu entwickeln, einen Test zu machen. Es ist zwar ungewohnt, aber es stimmt – Kunden haben doch nicht immer recht….
Sie werden es sicher noch errinnern, daß das Softwarepaket Microsoft Vista nicht sehr gut im Markt aufgenommen worden ist. Insbesondere wurde die mangelhafte Qualität bemängelt, und das Produkt ist nie richtig beliebt gewesen, weil es als nicht sonderlich benutzerfreundlich bekannt war. Vista ist nicht wirklich erfolgreich gewesen – ein Problem für eine Firma, die quasi von diesem Betriebssystem lebt.
Mit Windows 7 hat Microsoft nicht nur am Produkt gearbeitet, sondern hat eben auch den gesamten Entwicklungsprozess verändert (mehr hierzu in meinem älteren Artikel →Pair Programming). Der Grund für diese Änderung war, daß man eingesehen hatte, daß die Software so groß geworden war, daß es nicht mehr anders sicherzustellen war, Qualität zu liefern. Letztendlich hat Microsoft sich den agilen Methoden verschrieben, und hat die dort entwickelten Qualitätsmethoden aktiv übernommen.
Wie ein älterer Blogbeitrag eines Microsoft Mitarbeiters zeigt, ist der Entwicklungsprozess bereits seit vielen Jahren durchaus komplex gewesen. Dort geht es darum, daß eine kleine Softwareänderung eine ganze Kette weitere Aktivitäten hinter sich herzog. Hier ein kleiner Ausschnitt von diesen Folgeaktivitäten:
- „One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
- One program manager to write the specification.
- One localization expert to review the specification for localizability issues.
- One usability expert to review the specification for accessibility and usability issues.
- At least one dev, tester and PM to brainstorm security vulnerabilities.
- One PM to add the security model to the specification……“
Grundsätzlich glaube ich, daß die Darstellung etwas übertrieben ist, schon alleine, wenn man daran denkt, daß Microsoft diesen Aufwand sicher nicht für jede Korrektur einzeln gemacht hat, sondern wohl eher für ein Bündel von Änderungen. Allerdings zeigt die Darstellung, daß Microsoft die „Wasserfallmethode“ verwendet hat, d.h einen großen Entwicklungsprozess, in dem die einzelnen Aufgaben bei einzelnen Funktionen zentralisiert waren.
Agile Methoden setzen stark auf befähigte Teams (Teams of Ten). In der neuen Entwicklungswelt ist das Team für die meisten Aufgaben selbst verantwortlich. Mit der seit Windows 7 bei Microsoft verwendeten agilen Methode sind daher viele Aufgaben in einem einzelnen Scrum Team angeordnet, und werden sogar vom selben Entwickler erledigt werden, wie zum Beispiel das Schreiben und das Reviewen der Spezifikation.
Auch in Bezug auf die Qualität ergibt sich eine andere Sicht: Sie ist nicht mehr die Aufgabe einer zentralen Testabteilung, sondern liegt eben in der Verantwortung des Teams. Eine dieser Methoden ist das Pair Programming. Zum Beispiel berichtet die Wissenschaft für diese Methode über einen sehr großen Nutzen (siehe →Pair Programming, what researchers say),
Auf den →Agile testing days wird es um die einzelnen Methoden gehen. Bereits der Agenda kann man entnehmen, daß es bei den agilen Methoden darum geht, die einzelnen Teammitglieder zu befähigen.
Das Microsoft-Beispiel hat aber auch noch einen anderen wahren Kern: selbst wenn Anforderungen klein aussehen, können sie eine große Menge von Änderungen herbeiführen. Diese Änderungen müssen ha alle irgendwie koordiniert werden. Auch arbeiten Menschen an der Umsetzung der Anforderungen. Dies bedeutet, daß Fehler nicht nur möglich sind, sondern Realität. Daher läßt sich die Eingangsfrage vielleicht so beantworten:
Das Testen/die Qualität ist genauso wichtig wie das Entwickeln von Features, d.h beiden Teile sollten in einem ausgewogenen Verhältnis zueinander stehen.
Wenn man sich dann noch vergegenwärtigt, daß selbst die große Firma Microsoft in Probleme läuft, wenn Qualitätsprobleme auftreten, kann man sich vorstellen, was mit einem StartUp passiert, daß sich nur um das Umsetzen von Anforderungen kümmert – vermutlich wird es nicht lange leben.
Das Explorative Testen zeigt sich immer mehr als eine Methode, die hierbei eine herausragende Bedeutung einnimmt, da gerade diese Methode den Entwicklern die Möglichkeit gibt, die Software einmal richtig durchzuprüfen.
Im Internet finden Sie weiterführende Artikel:
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
