Avision über beliebte Fehler in Software-Entwicklungsprojekten Aus Fehlern anderer Development-Teams lernen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Avision GmbH

Kein Mensch ist unfehlbar, das gilt auch für Developer. Damit sind nicht nur klassische Programmierfehler gemeint, auch organisatorisch lauern Stolpersteine. Der IT-Dienstleister Avision nennt einige besonders weit verbreitete Fehler in Entwicklungsprojekten.

Manche Fehler, die in Software-Entwicklungsprojekten gemacht werden, sind besonders weit verbreitet. Der auf Software-Aufbereitung spezialisierte IT-Dienstleister Avision will mit deren Benennung eine weitere Ausbreitung verhindern: „Aus Fehlern wird man klug. Und besonders klug wird man, wenn man nicht nur aus den eigenen, sondern auch aus den Fehlern anderer lernt“, kommentiert Nadine Riederer, CEO von Avision.

Im Folgenden die beliebtesten Development-Schnitzer im originalen Wortlaut:

• Weil sie einfach nett sind und der Product Owner oder die Fachabteilung es sich so sehr wünschen, nehmen Entwickler kurz vor Ende des Sprints noch einmal eine neue Anforderung auf. Das ist keine gute Idee, denn am Ende verursacht dann genau ihre Umsetzung einen Fehler. Besonders häufig passiert das bei kleinen Anforderungen, die unproblematisch erscheinen und deshalb nicht wirklich ernst genommen werden.

• Ebenfalls ein beliebter Last-Minute-Fehler: kurz vor Ende des Entwicklungsprojekts noch eine Komponente austauschen. Bei einem Framework, das wir verwenden, ist ein Bug aufgetaucht? Dann nehmen wie eben eine neuere Version davon. Da stellt sich dann aber leider raus, dass diese fünf andere Bugs hat.

• „Ich hab‘ da mal schnell was angepasst, weil es nicht schön war.“ Klingt nach lobenswerter Eigeninitiative, geht aber allzu oft nach hinten los. Bei solchen Aktionen schreiben Entwickler nämlich meist keine Testfälle und kontrollieren auch nicht, welche Auswirkungen ihre Anpassungen auf den Rest der Software haben.

• Das Entwicklungsprojekt hat zeitlichen Verzug? Dann wechseln wir einfach vom konservativen zum agilen Vorgehen, Agilität ist ja schließlich ein Garant für schnelle Entwicklung. Stimmt nur leider nicht. Agil entwickeln heißt, die Bedürfnisse der Nutzer besser zu erfüllen, weil man flexibler ist. Agilität sorgt dafür, dass man das Ziel genauer trifft, nicht schneller.

• Ein weiterer häufiger Versuch, zeitlichen Rückstand aufzuholen, ist das Aufstocken des Teams. Das kann sogar klappen, wenn man das Team von zehn auf elf Mitarbeiter erhöht. Aber fünf neue Mitarbeiter sind zu viel des Guten. Sie müssen alle eingearbeitet werden und der Kommunikationsaufwand im Team erhöht sich deutlich. Außerdem brauchen manche Prozesse einfach eine bestimmte Zeit – ganz egal, wie viele Personen daran arbeiten.

• Vermeintliche Zeitersparnis zum Dritten: Um schneller zu sein, setzt das Team beim Testen der Software verstärkt auf Testautomatisierung. Hier verhält es sich aber ähnlich wie bei der Agilität. Durch automatisierte Tests wird der Code besser, aber er ist nicht schneller fertig. Da die Teams zusätzlich zum Code die Testfälle entwickeln müssen, kommen sie in Summe auch nicht schneller voran.

(ID:48535035)