Qualität, Features und Termindruck
Wahrscheinlich ist die Entscheidung für jeden Produktowner ein Klassiker: Worauf den Schwerpunkt legen – Features oder Qualität? Oft steckt hinter der Frage jedoch mehr.
Termindruck kommt in der Praxis oft durch Faktoren zustande, die ein einzelner Produktowner nur schwer beeinflussen kann, wie zum Beispiel das Ziel der gesamten Firma, möglichst oft ein komplettes Release abzuliefern, das dann noch möglichst viele neue Funktionen enthalten soll.
Ein kurzes Zitat sollte uns zum Denken anregen. Es zeigt, daß es vielleicht machmal sinnvoller sein könnte, ein Feature zu abzusagen, als die Qualität zu kompromittieren.
Oracle und Google haben die meisten Sicherheitslücken
Lange war das MS Windows Betriebssystem das Ziel von Hackerangriffen, und ist fast ständig mit irgendeiner Sicherheitslücke in der Presse aufgetaucht. Dies hat dazu geführt, daß zunehmend Kunden verunsichert wurden, und auf andere Produkte umgeschwenkt sind.
Um die jüngsten Releases fehlerfreier zu machen, hat Microsoft den Entwicklungsprozess fundamental verändert. Früher hat man dort nach der Wasserfallmethode entwickelt, und sich regelmäßig viel vorgenommen. Hierbei wird ein großes Release erstellt das dann vor der Auslieferung umfangreich getestet wird.
Heute nutzt man moderne Methoden der Qualitätssicherung, wie zum Beispiel das Test Driven Development, oder das Pair Programming. Diese Methoden sehen auf den ersten Blick teuer aus, sind es aber nicht, wenn man genauer hinschaut.
Beim Test Driven Development erstellt man zuerst einen Test, und dann das produktive Coding, d.h man testet das Coding aus sich heraus. Beim Pair Programming entwickeln zwei Personen zusammen ein Programm, und korrigieren sich gegenseitig.
Diese Methoden machen sich bezahlt, wie folgendes Zitat zeigt, das aus dem Artikel →Google and Oracle overtake Microsoft in security flaws stammt:
Google and Oracle have overtaken Microsoft as the vendors with the most vulnerabilities, according to Trend Micro’s Third Quarter Threat Report.
Dort steht aber noch mehr, nämlich, daß bei Google und Oracle die zwei Klassiker zu solchen Problemen führen, daß sie sicher früher oder später den Verkaufserfolg ihrer Software negativ beeinflussen:
“… the short cycles between product releases, which limit how much bug testing can be done.
acquisition of Sun and its Java products by Oracle in 2009 had caused the latter’s code-base to become large and complicated to maintain, contributing to the rise in exploitable bugs.”
Die Klassiker, die ich meine, sind kurze Releasezyklen, und Probleme, den Code zu warten (und Bugs auszubauen).
Gegen die kurzen Releasezyklen kann man als einzelner Produktowner wenig tun, außer vielleicht, daß man aufpasst, sich nicht zuviel Featurewünsche vorzunehmen, und, daß man darauf achtet, diese Features ausreichend zu testen.
Um Coding wartbar zu machen helfen einem allerdings die oben erwähnten Methoden, und ganz besonders eine Methode mit Namen “Clean Code”. Hierbei arbeitet man regelmäßig an der Verbesserung des Codings, um dessen Wartbarkeit zu verbessern. Da hierbei keine Funktionalität entsteht, sollte man allerdings aufpassen, daß man die Aufwände sorgsam plant.
Weiterführende Informationen
Wenn Ihnen der Artikel gefallen hat, warum nicht meinen Blog abonnieren →Mailingliste, oder →mir auf Twitter folgen?
Weiterführende Informationen im Internet
Hier finden Sie weiterführende Informationen zum heutigen Thema im Internet:
- →Google and Oracle overtake Microsoft in security flaws
- →International Software Testing Qualifications Board
Weiterführende Informationen auf www.Produkt-Manager.net
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
- →Feature versus Qualität
- →Final Cut Pro – Produktmanagement- Perspektive
- →Exploratory Testing – Scrum Teams testen wie Touristen
Tags: Agile Development, Quality, Work-Life Balance | Comments Off

















Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen mit dem Schwerpunkt globale Standardanwendungen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.


