Wir haben bei unseren Softwareentwicklern in letzter Zeit festgestellt, dass Deadlines zu häufig überschritten werden und zu viele Bugs schlicht übersehen werden. Wie bekommen wir mehr Qualität in die Entwicklung?
Johannes Bohnet, Geschäftsführer der Software Diagnostics GmbH in Potsdam, antwortet: "Das Qualitätsbewusstsein ist bei Entwicklern in der Regel stark ausgeprägt. Eigentlich wollen sie gerne hochqualitativen Code abliefern, können dies häufig aber nicht, weil das Management ihnen nicht ausreichend Zeit zur Verfügung stellt. Dieses sieht oft nur die Features (beispielsweise einen neuen Button im Fenster) und belohnt diejenigen Entwickler, die in kurzer Zeit möglichst viele Funktionen präsentieren. Nach dieser Logik ist der Programmierer besser, der in einer Woche vier statt nur einen "neuen Button" im Team-Meeting vorzeigen kann. Was das Management dabei allerdings häufig außer Acht lässt, ist die Qualität der Software, also wie nachhaltig die einzelnen Features programmiert und wie gründlich der neue Code getestet wurde.
Geschwindigkeit ist nicht alles
Die abstrakte, "unsichtbare" Natur von Software macht es den Verantwortlichen dabei nicht einfach: Code mit geringer Qualität fällt anfangs nicht auf. Bugs und Fehlfunktionen treten erst im Laufe der Zeit auf, häufig erst, wenn die Software bei Beta-Kunden im Einsatz ist. Fehler zu diesem späten Zeitpunkt zu entdecken und korrigieren zu müssen, ist teuer. Oftmals muss der Code des vermeintlich schnellen Entwicklers gänzlich neu programmiert werden. Die Projektpläne laufen zwangsläufig aus dem Ruder.
Softwareverantwortliche sollten also von Anfang an darauf achten, dass die internen Anreiz- und Belohnungssysteme stimmen. Bei uns gilt: Ein Entwickler ist nur dann gut, wenn er viele Features innerhalb kurzer Zeit programmiert und diese getestet und in hoher Qualität programmiert hat. Um dies sicherzustellen, ist Transparenz notwendig. Sowohl das Management als auch die Entwickler müssen zu jeder Zeit sehen können, ob eine Software sauber oder schlampig programmiert wurde, ob sie durch Tests gesichert ist oder nicht.
Dieses Wissen erhalten wir, indem wir unseren gesamten Code in Form von Stadtkarten visualisieren. Wenn unser Entwicklungsverantwortlicher in der Karte ein rotes, einsturzgefährdetes Hochhaus sieht, weiß er, dass die Funktion zwar eingebaut wurde, aber der Entwickler noch lange nicht fertig ist. Jetzt heißt es, den Programmteil so lange zu verfeinern, bis daraus ein blaues Einfamilienhaus wird, das fest auf dem Boden steht und in die gesamte Infrastruktur eingefügt ist. Natürlich bedeutet dieses Vorgehen, dass wir am Anfang unserer Softwareprojekte ein wenig langsamer sind. Aber das ist gewollt. Denn spätestens ab der Hälfte des Projekts zahlt sich dieser Rückstand aus. Wir bleiben im Plan und sind oft sogar schneller als gedacht."
Johannes Bohnet, Geschäftsführer der Software Diagnostics GmbH in Potsdam, antwortet: "Das Qualitätsbewusstsein ist bei Entwicklern in der Regel stark ausgeprägt. Eigentlich wollen sie gerne hochqualitativen Code abliefern, können dies häufig aber nicht, weil das Management ihnen nicht ausreichend Zeit zur Verfügung stellt. Dieses sieht oft nur die Features (beispielsweise einen neuen Button im Fenster) und belohnt diejenigen Entwickler, die in kurzer Zeit möglichst viele Funktionen präsentieren. Nach dieser Logik ist der Programmierer besser, der in einer Woche vier statt nur einen "neuen Button" im Team-Meeting vorzeigen kann. Was das Management dabei allerdings häufig außer Acht lässt, ist die Qualität der Software, also wie nachhaltig die einzelnen Features programmiert und wie gründlich der neue Code getestet wurde.
Geschwindigkeit ist nicht alles
Die abstrakte, "unsichtbare" Natur von Software macht es den Verantwortlichen dabei nicht einfach: Code mit geringer Qualität fällt anfangs nicht auf. Bugs und Fehlfunktionen treten erst im Laufe der Zeit auf, häufig erst, wenn die Software bei Beta-Kunden im Einsatz ist. Fehler zu diesem späten Zeitpunkt zu entdecken und korrigieren zu müssen, ist teuer. Oftmals muss der Code des vermeintlich schnellen Entwicklers gänzlich neu programmiert werden. Die Projektpläne laufen zwangsläufig aus dem Ruder.
Softwareverantwortliche sollten also von Anfang an darauf achten, dass die internen Anreiz- und Belohnungssysteme stimmen. Bei uns gilt: Ein Entwickler ist nur dann gut, wenn er viele Features innerhalb kurzer Zeit programmiert und diese getestet und in hoher Qualität programmiert hat. Um dies sicherzustellen, ist Transparenz notwendig. Sowohl das Management als auch die Entwickler müssen zu jeder Zeit sehen können, ob eine Software sauber oder schlampig programmiert wurde, ob sie durch Tests gesichert ist oder nicht.
Dieses Wissen erhalten wir, indem wir unseren gesamten Code in Form von Stadtkarten visualisieren. Wenn unser Entwicklungsverantwortlicher in der Karte ein rotes, einsturzgefährdetes Hochhaus sieht, weiß er, dass die Funktion zwar eingebaut wurde, aber der Entwickler noch lange nicht fertig ist. Jetzt heißt es, den Programmteil so lange zu verfeinern, bis daraus ein blaues Einfamilienhaus wird, das fest auf dem Boden steht und in die gesamte Infrastruktur eingefügt ist. Natürlich bedeutet dieses Vorgehen, dass wir am Anfang unserer Softwareprojekte ein wenig langsamer sind. Aber das ist gewollt. Denn spätestens ab der Hälfte des Projekts zahlt sich dieser Rückstand aus. Wir bleiben im Plan und sind oft sogar schneller als gedacht."
