Softwareentwicklung Status Quo

Freitag, 19 Uhr. Einige Softwareentwickler sitzten angespannt vor Ihren Computern, tippen fleissig am Quelltext.  Manche starren immer wieder konzentriert in den Raum. Einer in der Gruppe sitzt nervös herum, starrt fortwährend auf die Uhr. Hie und da steht er auf, geht von Kollege zu Kollege, redet mit jedem kurz, scherzt, lacht verlegen. Er ist für das Projekt verantwortlich und sieht einem unangenehmen Termin mit dem Kunden entgegen. Der gleich zu Beginn erstellte Projektplan hat sich als zu optimistisch herausgestellt, aber mit ein paar Überstunden und gutem Teamwork lässt sich das Problem lösen. So die Annahme des Projektmanagers. Er hat das Team darauf eingeschworen, das gesamte Projekt in überschaubare Teilaufgaben aufgeteilt und – um dem Team administrative Arbeiten zu ersparen – jedem im Team genau erklärt was er zu tun hat, damit die Aufgabe noch geschafft werden kann

Samstag, 17 Uhr. Die Entwickler sitzen voll konzentriert bei der Arbeit. Jeder hat seine Aufgaben und ist guter Dinge damit fertig zu werden. Nachdem der Zeitdruck so hoch ist und man die anderen nicht stören will schafft sich jeder eine Umgebung, in der er die Arbeitsergebnisse auch testen kann. Man hat ja einen gewissen Qualitätsanspruch und will belegen können, dass die eigene Arbeit wunderbar funktioniert. Der Projektmanager stellt erfreut fest, dass die meisten Aufgaben tatsächlich fertig gestellt worden sind und trägt die Ergebnisse in den Projektplan ein.

Sonntag, 22 Uhr. Völlig unerwartet gibt es noch Hindernisse. Die einzelnen Komponenten arbeiten für sich so wie geplant, nur bei der Integration zum gesamten Produkt gibt es große Probleme. Die Entwickler diskutieren, streiten über fachliche Missverständnisse und belegen stolz, dass ihre Komponente in der Testumgebung präzise funktioniert. Der Projektmanager versucht die Diskussionen in eine konstruktive Bahn zu lenken, gibt aber noch 30 Minuten entnervt auf. Emotionen und Müdigkeit lassen keine fachliche Diskussion mehr zu.

Montag, 9 Uhr. Der Projektmanager sitzt beim Kunden. Das Meeting beginnt…

Die Geschichte ist fiktiv und überspitzt formuliert. Wir erleben dennoch immer wieder Projekte im IT-Alltag, die aus den Rudern laufen. Sei es, weil die Aufwände und Kosten das Budget weit überschreiten oder sei es, weil der gewünschte Nutzen nicht erreicht wird. Im schlimmsten Fall trifft  beides zu. Um solche Szenarien abzuwenden haben vor etwa 10 Jahren einige der klügsten Köpfe der noch recht jungen Wissenschaft des Software Engineerings untersucht, warum IT Projekt so häufig scheitern und welche Maßnahmen man ergreifen kann, um dies zu verhindern.

Das Ergebnis dieser Überlegungen haben Sie im "Agilen Manifest" dokumentiert:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Programme sind wichtiger als ausführliche Dokumentation
  • Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen
  • Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans 

Basierend auf diesen Werten sind einige Methoden zum Software Projektmanagement sowie des Software Entwicklungsprozesses ausgearbeitet oder auf dieses Manifest abgestimmt worden. Die heute wohl bekanntesten Methoden sind Scrum und Kanban.

Bei der Umsetzung des agilen Manifests ist es besonders wichtig Verantwortungen zu teilen und ein Projekt nicht nur einseitig zu betrachten. Kommunikation und Teamplay sind unabdingbar für einen Projekterfolg. Wichtig ist, dass nicht nur der Projektumsetzer, sondern auch der Projektsponsor Teil des Projektteams ist. Gerät ein Projekt in Schwierigkeiten trägt auch dieser – als Teil des Teams – einen Teil der Verantwortung. Die stete Abstimmung mit dem Kunden ist mindestens genauso wichtig wie ein Team von Profis das mit der umzusetzenden Aufgabe nicht überfordert ist.

Teilergebnisse müssen laufend beurteilt werden um im Projekt die Ausrichtung auf das Projektziel nicht zu verlieren. Betrachtet man ein erfolgreiches Softwareprojekt so entdeckt man, dass ein erheblicher Teil des Aufwandes auf die Abstimmung des Projektteams entfällt. Das agile Manifest zeigt auf, dass die Anforderungen an ein modernes Software Unternehmen sehr hoch sind. Es reicht nicht ein Team von ausgezeichneten Technikern zu sein. Man benötigt mindestens genau so gute Kommunikationsfähigkeiten, sowie Flexibilität und Kreativität im Umgang mit Änderungen. Dies gilt noch viel mehr, wenn ein Projekt oder Teile eines Projekts an einen externen Dienstleister ausgelagert werden sollen. Denn eines sollte nach 40 Jahren Softwareentwicklung klar geworden sein. Keine komplexe Lösung kann im Vorfeld so detailliert ausgearbeitet werden, dass sich während der Umsetzung keine Änderungen an den Anforderungen mehr ergeben. Eine "fire and forget" Strategie seitens des Projektsponsors ist hier zum Scheitern verurteilt.

Quellen:

* http://agilemanifesto.org/
* http://openforce.com/
* http://timejim.com/