Einleitung

Kennen Sie das Skalierungsproblem bei der Arbeit in Teams? Es besagt, dass die Effizienz eines Teams mit seiner Größe sinkt. Mit anderen Worten ein Team aus 10 Mitarbeitern hat die Schlagkraft von vielleicht sieben Einzelpersonen, der Rest geht bei Abstimmung und Absprachen verloren. Ein Team von 100 Mitarbeitern hat eine Schlagkraft von 40 Einzelpersonen, der Rest geht bei der Klärung von Missverständnissen, bei Streitigkeiten, Meetings, Kompetenzgerangel und durch unklare Absprachen verloren. Scheint logisch, oder!?

Aber Moment mal, irgend etwas stimmt doch hier nicht. Große Teams sollen doch eigentlich durch Synergien und durch Arbeitsteilung mehr schaffen als die gleiche Zahl von Einzelkämpfern. Also sollte doch ein Team von 10 Personen so viel schaffen wie 12 und ein Team von 100 soviel wie 140. So die Theorie. Was ist denn nur los mit der Praxis?

Die Praxis ist vollkommen in Ordnung, die Arbeit in großen Teams in vielen Gebieten der Wirtschaft läuft tadellos: wenn Sie mir nicht glauben, dann besuchen Sie mal eine Autofabrik oder reden Sie mit Leuten, die in der Elektronik- und Chip-Industrie arbeiten. Ich stelle die Frage also anders: Was läuft verkehrt in der Praxis der Softwareentwicklung?

Nach meiner Erfahrung aus vielen großen Projekten kann eine ähnliche Effizienz auch bei der Softwareentwicklung etabliert werden, wenn man Teams formt und Projekte organisiert. Für die Projektorganisation gibt es inzwischen mehrere Ansätze, sie alle versuchen das Entwicklungsprojekt als Prozess zu strukturieren und weisen deshalb neben ihren charakteristischen Unterschieden auch sehr viele Gemeinsamkeiten auf. Bei der Teamformung gibt es nach meiner Beobachtung weit weniger strukturiertes Vorgehen, allenfalls ist erkannt worden, dass Teamformung bisher zu wenig als ein Erfolgsfaktor gelebt wird.

Meine methodische Kompetenz fasse ich nach dieser Einleitung folgendermaßen zusammen:

1. Ich kenne die Vorgehensmodelle bei der Sofwareentwicklung (iteratives Vorgehen, Wasserfall, agiles Vorgehen) und weiß um ihre Vor- und Nachteile. Ich helfe Ihnen bei der Auswahl des geeigneten Vorgehens.
2. Ich helfe Ihnen bei der Teamformung, indem ich Sie dabei unterstütze, ein bestimmte Projektkultur zu entwickeln. Dafür bediene ich mich moderner Methodiken, wie artefakt-orientiertes Arbeiten, agile Praktiken und testgetriebene Entwicklung.
3. Das Anforderungsmanagement genießt allerhöchste Priorität. Mangelhaftes Anforderungsmanagement ist die Hauptursache für das Scheitern mittlerer und großer IT-Projekte. Ich bringe vitale Expertisen für Ihre Anforderungsanalyse und das Anforderungsmanagement in Ihr Projekt.
4. Ein wesentlicher Erfolgsfaktor in Softwareprojekten ist kollaboratives Arbeiten und Automatisierung. Hier spielen Erfahrung und die konsequente Anwendung geeigneter Werkzeuge die Hauptrolle. Ich stelle Ihnen meine Erfahrungen im Bereich der Dokument- und Versionsverwaltung und bei der Automatisierung des Softwarebuild zur Verfügung.

Individualsoftware

Die Entwicklung von Individualsoftware ist oft ein teures, kräftezehrendes und erfolgloses Unterfangen. Entscheidungsträger beginnen zu verstehen, wo die Ursachen dafür liegen, und wie dem zu begegnen ist. Wir befinden uns diesbezüglich in einer Zeit des Umbruches und ich stelle hier meine Sicht der Dinge dar. Die Reihenfolge der Aufzählung ist beabsichtigt.

• Das Projektziel ist zwar klar vorgegeben, wird aber nicht von den Entscheidungsträgern respektiert. Gerade in großen, langlaufenden Projekten werden Entscheidungen als Kompromisse herbeigeführt. Diese Kompromisse müssen sich am Projektziel ausrichten und nicht an den Karriereplänen weniger Akteure im Projekt. Die wichtigsten Projektziele müssen auf monetärer Basis definiert werden.
• Das Anforderungsmanagement ist mangelhaft. Anforderungsmanagement wird heute häufig als Sammeln großer Mengen spezieller Geschäftsvorfälle verstanden. Dabei wird oft die Anforderungsanalyse vernachlässigt und auf die Phase der technischen Konzeption abgewälzt. Anforderungsanalyse, also die Verteilung der Geschäftslogik auf verschiedene Abstraktionsstufen ist insofern unverzichtbar, als dabei eine frühzeitige Zusammenarbeit zwischen Fachkonzeption und Entwicklung notwendig ist. Dies kann der entscheidende Erfolgsfaktor im Projekt sein.
• Das Konfigurationsmanagement, also die Betreuung der Projektartefakte und Produkte über ihre gesamte Lebensphase, ist mangelhaft. Oftmals erfasst das Konfigurationsmanagement nur die Artefakte der unmittelbaren Entwicklungsarbeit.
• Das Oberflächendesign wird von den Fachanwendern im Rahmen des Anforderungsmanagements bestimmt und nicht von erfahrenen Experten und Sachzwängen. Ein Symptom dafür sind pixelgenaue umgesetzte Anwendungen, die dennoch aus Sicht der Anwender nicht erwartungskonform arbeiten.

Und diese Punkte halte ich für unkritisch, man braucht keine Energie daran zu verschwenden:

1. Technologien: die heute im Einsatz befindlichen Technologien sind normalerweise vollkommen ausreichend für die Lösung der gestellten Aufgaben.
2. IT Wissen: natürlich lassen sich hier oft Defizite feststellen, selten bedeuten diese aber ein echtes Projektrisiko.
3. Werkzeuge: falsche Werkzeuge sind fast nie die Ursache eines Problems (aber oft ein Symptom dafür).

Anforderungsmanagement

• Mangelhaftes Anforderungsmanagement (AM) ist in der überwiegenden Zahl aller Individual-Softwareprojekte verantwortlich für den de facto Misserfolg der Projekts, die Unzufriedenheit der Entwickler mit ihrer Arbeit und der Anwender mit dem Produkt.
• Anforderungsmanagement wird notorisch falsch besetzt, nämlich mit kundenseitigen Fachkräften statt mit IT-Ingenieuren des Auftragnehmers. Die Folge ist, dass das Ergebnis des AM bestenfalls eine große, lose und unzusammenhängende Sammlung von Geschäftsfällen ist. Wie gesagt: bestenfalls.
• Die Anforderungsanalyse - der wichtigste Teil des AM, denn hier erfolgt der Bau der Brücke zwischen der Fachseite und der Umsetzungsseite - erfolgt nicht oder erst während und nach der Umsetzung. Das AM versäumt außerdem, die Stufen zunehmender Abstraktion, die von der Formulierung der Fachlichkeit bis zur Codierung erforderlich sind, zu benennen und einzuhalten.
• Das AM versäumt die Definition und Einhaltung der ROI-entscheidenden Geschäftsvorfälle also das Formulieren und Durchsetzen von Prioritäten.
• Das AM ist Schlachtfeld der Politik und Diplomatie und nicht Teil des Softwareentwicklungsprozesses.
• Artefakte des AM werden nicht wie die Artefakte der Umsetzung behandelt. Insbesondere fehlt eine Versionierung und die Integration in das Releasemagement.
• Das AM wird Frontend-lastig betrieben, es beschäftigt sich dann oft mit unwichtigen Dingen, zum Beispiel mit dem pixelgenauen Entwurf von Eingabemasken.

Oft wird im Projekt das Werkzeug des Anforderungsmanagements für auftretende Mängel verantwortlich gemacht. Das sehe ich nicht so und ich entgegne, dass nur der Punkt sechs davon berührt wird. Hier ist mein Vorschlag für das ideale "Werkzeug" für Anforderungsmanagement:

• Alles Relevante ist als unformatierter Text oder als Bild (zum Beispiel eingescanntes Whiteboard oder Handskizze) zu hinterlegen.
• Das Ganze wird wie Code in Paketen verwaltet und im gleichen Repository mit dem Werkzeug der Entwicklung (zum Beispiel Eclipse + Subversion) gehalten.
• Diese so versionierten Artefakte sind Bestandteil der Releasezyklen im Projekt und erst als Releases verbindlich.
• Dank Versionierung kann sich jeder im Projekt an der Formulierung der Artefakte des Anforderungsmanagements beteiligen.
• Für fehlerhafte Artefakte wird die gleiche Fehlerverfolgung durchgeführt, wie für fehlerhaften Code.

Zusammengefasst: Anforderungsmanagement wird in allen Facetten genauso betrieben wie Code-Entwicklung.