Facebook
Twitter
Google+
Kommentare
4
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

Die 40-Stunden-Woche

… oder „Warum sind meine Core-Bibliotheken so schlecht?“

Eine von der agilen Bewegung empfohlene Praktik ist die Einhaltung der 40-Stunden-Woche. Wird beispielsweise im Team Scrum eingesetzt, soll beim Planen eines Sprints darauf geachtet werden, dass die Zielvorgaben vom Team in seiner Regelarbeitszeit und damit ohne Überstunden erfüllt werden können.

Das klingt zunächst nur wie ein Vorteil für die Angestellten. So möchte der Arbeitgeber doch so viele Funktionen wie nur möglich implementiert haben. Und wenn die Zeit knapp wird möchte er erst recht nicht hören, dass das Release verschoben werden muss.

Warum sollte er also entgegen dem betriebswirtschaftlich offensichtlichen Standpunkt die Mitarbeiter nicht „darum bitten“, Überstunden zu machen?

Ken Schwaber erklärt in seinem Google Tech Talk mit dem Thema „Scrum“ weshalb es unbedingt vermieden werden sollte, dass das Team überlastet ist und Überstunden machen muss.

Arbeitet ein Entwickler nur 8 Stunden am Tag an seiner Aufgabe, so ist es laut Schwaber möglich, sich in dieser Zeit auf die Arbeit zu konzentrieren und gute Arbeit zu leisten.

Meist sollen sich laut Schwaber Entwickler auch nach der Arbeit in Gedanken mit den ihnen gestellten Problemen befassen und finden gelegentlich dadurch Lösungen für Probleme, auf die sie in der Arbeitszeit nicht gekommen wären.

Arbeit, die über die Regelarbeitszeit hinaus geht, bringt den Software-Entwickler an einen Punkt der Erschöpfung, der zum einen seine Konzentrationsfähigkeit schwächt und zum anderen seinen Wunsch stärkt, nach der Arbeit „abzuschalten“. Dies bedeutet in der Regel, dass versucht wird, von den Themen der Arbeit Distanz zu halten. Dadurch wird nicht mehr reflektiert, was an diesem Tag gearbeitet wurde.

Ordnet der Vorgesetzte an, dass Release Dates gehalten und dafür wenn nötig Überstunden gemacht werden müssen, ist die übliche Reaktion von Software-Entwicklern, zu versuchen, durch Erhöhung der Geschwindigkeit Überstunden zu vermeiden.

Genau das Erhöhen der Entwicklungsgeschwindigkeit kann jedoch nicht ohne weitere Verluste geschehen:

  • Bei der Konzipierung der Systeme werden schnelle Entscheidungen getroffen
  • Oft werden dabei die Lösungen gewählt, die am einfachsten zu implementieren sind
  • Diese Lösungen sind in der Regel unflexibler
  • Gründliches Testen oder Unit-Tests werden vernachlässigt
  • Code Reviews werden nicht gemacht
  • Der Code wird nicht durch Refactoring wieder in einen wartbaren Zustand gebracht

All diese Faktoren sind der Grund, weshalb kontinuierlicher Druck im Team dazu führt, dass Komponenten mit der Zeit immer schwerer zu warten werden.

Wenn schnellere Entwicklung und Überstunden vom Team akzeptiert werden und dadurch Release Dates gehalten werden können, wird der Vorgesetzte beim nächsten Mal wieder vom Team erwarten, dass es diese Geschwindigkeit liefern kann.

Jedoch dann steht dem Team eine Software zur Verfügung, die eine Codebasis hat, mit der wesentlich schwerer und langsamer entwickelt werden kann.

Mit der Zeit entstehen Bereiche in der Software, die nahezu unwartbar sind und von denen die Entwickler am Liebsten die Finger lassen. Das sind oft die Core-Bibliotheken, die Klassen im System, die am häufigsten modifiert wurden.

Es ist also wichtig zu erkennen, dass bei der Software-Entwicklung eine Erhöhung der Entwicklungsgeschwindigkeit und ein Erzwingen von Überstunden nicht wie bei anderen Professionen mit der Zeit wieder ausgeglichen wird. Vielmehr handelt es sich hier um einen Kreislauf, der die Situation ständig verschlimmert.

Es wird klar, dass es keine Verlust-Situation für das Management sein kann, wenn sie das Release zugunsten der 40-h-Woche verschieben, denn dann kann in kontinuierlicher Qualität entwickelt werden. Und schließlich soll meistens die Software mehr als zwei Quartale weiterentwickelt werden.

Über den Autor

Timo Holzherr

Software-Entwicklung ist für mich mehr als ein Beruf, mit dem ich mir die Brötchen verdiene - es ist meine Leidenschaft. Themen wie professionelle, objektorientierte Software-Entwicklung, moderne Web-Entwicklung, Agiles Projektmanagement sind für mich so spannend wie ein guter Krimi. Deshalb habe ich 2003-2006 Informationstechnik studiert und nach dem Studienabschluss meinen Job als Web-Entwickler gewählt. Seit 2006 halte ich Vorlesungen im Fach "Software-Engineering" an der DHBW (Dualen Hochschule Baden-Württemberg) in Stuttgart und bin im Prüfungsausschuss der DHBW in Horb. Obwohl ich so viel Zeit beruflich mit der Entwicklung von Software verbringe, bin ich privat trotzdem unermüdlich und habe deshalb mein zweites Hobby, die Musik, mit dem ersten Verbunden: Im Juli 2009 habe ich mein erstes großes privates Web-Projekt gestartet - GUESSASONG. (http://www.guessasong.net/) Ich bin gespannt, was ihr über meine Beiträge denkt und werde versuchen trotz vollem Terminplan regelmäßig hier Posts zu machen.
Kommentare

4 Comments

  1. Leider gibt es aber immer wieder Projekte, bei denen diese Probleme wissentlich in Kauf genommen werden, um in schneller Folge immer neue Features an einen labilen Anwendungskern anzuhängen. Ich schon manches mal sehr überrascht wie lange eine solche Konstruktion halten kann aber das Fiasko ist meist schon früh absehbar.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen