Entwicklungsprozesse

Jedem Projekt liegt eine vordefinierte Vorgehensweise bei der Durchführung zugrunde. Bei Softwareprojekten bezeichnet man dies als Entwicklungsprozess. Auch wenn dieser nicht explizit benannt wird, bestimmen Absprachen, Aufgabenteilung und Best Practices innerhalb des Teams einen "Entwicklungsprozess", der Sie erfolgreiche Softwareprojekte durchführen lässt.

Im Überblick betrachtet, existieren dabei - neben der klassischen Bandbreite von "formal" bis "hochagil" - natürlich vor allem zahllose "unternehmenseigene" oder auch "projekteigene" Prozesse, die sich in der Praxis hervorragend bewähren.

Hierbei setzt sich immer mehr der Gedanke durch, dass es nicht einen Entwicklungsprozess geben kann, der alle Eventualitäten in sämtlichen Organisationsformen abdeckt. Denn man muss in Entwicklungsprojekten einerseits der Kreativität genügend Freiräume gewähren, um die gestellte Aufgabe optimal bearbeiten zu können, anderseits aber auch Leitplanken definieren, die allen Beteiligten die Möglichkeit geben, sich inhaltlich und zeitlich miteinander abzustimmen sowie Feedbackschleifen zu verkürzen. Speziell die letzten Punkte beschreiben auch schon das Ziel des Entwicklungsprozesses. Der Entwicklungsprozess soll helfen, die Zusammenarbeit und Verantwortlichkeiten zu regeln, um einen reibungslosen Projektablauf zu gewährleisten.

Alle Prozesse haben ihre Stärken und Schwächen. Was als Stärke oder als Schwäche zu interpretieren ist, hängt stark von der Aufgabe, der Organisation, dem Projektumfeld und den Personen ab. Die heutigen Prozesse haben aber auch eines gemeinsam: einen iterativen beziehungsweise inkrementellen Charakter. Daher schließen sie sich nicht gegenseitig aus. Über ein gezieltes Tailoring lassen sich die (subjektiven) Stärken in einem projekt- oder organisationsspezifischen Prozess zusammenführen.

Nimmt man dies genauer unter die Lupe, so kommt man schnell zu einer modularen Betrachtung, die aufzeigt, aus welchen Elementen sich ein Prozess zusammensetzt. Dies können zum Beispiel die folgenden sein:

In den vergangenen Jahren wurde vielfach der Fehler begangen, sehr schwergewichtige Prozesse vorzuschreiben. Diese konnten zwar eine Vielzahl von Eventualitäten abdecken, aber im Projektalltag erwiesen sie sich oftmals als hinderlich, nicht als hilfreich. Aus dieser Zeit kommt auch der oft zweifelhafte Ruf der "Entwicklungsprozesse", die vielfach als reine "Papierwerke" oder Intranetpamphlete verstaubten, ohne von den Projektteams wirklich gelebt zu werden.

Als Kernpunkt sollte man daher folgende Überlegungen einbeziehen, bevor man sich für einen Prozess und die Art des Einsatzes entscheidet:

• Der Prozess muss zum Unternehmen wie zur Projektgröße und Projektkultur passen. Hierbei spielt die fachliche Domäne eine wichtige Rolle, da sie zum Beispiel über notwendige Regularien entscheidet
• Agile Prozesse bieten neue Möglichkeiten, auch für kleine Teams standardisierte Vorgehensweisen schnell und effektiv einzuführen und einzusetzen
• Die Einhaltung des Prozesses muss für den einzelnen Mitarbeiter möglichst einfach, intuitiv und ohne signifikanten Zusatzaufwand möglich sein. Dazu gehört auch, dass die von ihm verwendeten Werkzeuge den Prozess weitestgehend unterstützen und in diesen integriert werden können
• Der Prozess sollte möglichst vollständig von einem Werkzeug im Bereich Projektmanagement unterstützt werden. Dies hilft, die Arbeit mit dem Prozess einfach und effizient zu gestalten. Dazu gehört auch die Möglichkeit, Prozesse einfach anzupassen und damit auf veränderte Rahmenbedingungen zu reagieren

Im Application Lifecycle Management kommt dem Entwicklungsprozess eine zentrale Rolle zu, da es die einzelnen Disziplinen verbindet und durch eine strukturierte Vorgehensweise zusammenführt. Genau hierin besteht einer der Hauptvorteile: Das Werkzeug bildet den Prozess ab, unterstützt die Zusammenarbeit und führt den Prozess im Idealfall nahtlos zu den einzelnen Disziplinen sowie den einzelnen Rollen.

Ein paar Prozesse im Überblick

Speziell in der jüngeren Vergangenheit wurden eine Vielzahl von Prozessen definiert, die ihre Schwerpunkte an sehr unterschiedlichen Stellen setzen. So konzentriert sich beispielsweise Extreme Programming (XP) auf einfache Methodikelemente (Simplicity, Pair Programming, Test First, Continuous Integration ...), die im täglichen Geschäft zum Tragen kommen. XP definiert jedoch keinen Makroprozess in Form eines Phasenmodells mit Meilensteinen.

Scrum, als weiteres Beispiel, konzentriert sich sehr stark auf Projektmanagementpraktiken (Sprints, Reviews, Retrospectives, Scrums), um sicherzustellen, dass die Feedbackschleifen zwischen den verschiedenen Stakeholdern geschlossen werden. Im Gegensatz zu XP werden keine strikten Vorgaben hinsichtlich der Entwicklungsaktivitäten gemacht. Scrum versucht, ein transparentes Projektmanagement sicherzustellen, gleichzeitig trotzdem schlank zu bleiben und möglichst wenig einzuschränken. Übrigens lassen sich XP und Scrum sehr gut miteinander kombinieren.

Der Rational Unified Process konzentriert sich sehr stark auf einen risikobasierten Ansatz, der sich im übergeordneten Phasenmodell und in der Projektmanagementdisziplin widerspiegelt. Auch die Aktivitäten für Entwicklungsdisziplinen (Anforderungsmanagement, Analyse und Design, Implementierung, Test ...) sind sehr ausführlich beschrieben, sodass insgesamt ein sehr umfangreicher Prozess entstanden ist. Dieser kann und muss an die organisatorischen und projektspezifischen Gegebenheiten angepasst werden (Tailoring). Die Möglichkeiten für das Tailoring sind ein inhärentes Konzept dieses Prozessframeworks.

V-Modell XT

Das V-Modell XT versucht, den oben genannten Punkten Rechnung zu tragen. Um einem Projekt die größtmöglichen Erfolgschancen einzuräumen, schreibt das V-Modell XT einen Prozessrahmen (Makroprozess) vor, der befolgt werden muss. Gleichzeitig lässt es aber die Ausprägung der Methodik in den einzelnen Aktivitäten (Mikroprozess) bewusst offen, um die Kultur in der Entwicklung nicht unnötig einzuschränken. Der Makroprozess legt dabei einen Schwerpunkt auf die Kommunikationsschnittstelle zwischen Auftraggeber und Auftragnehmer, weil hier beiden Seiten die teuersten Missverständnisse und damit die größten Risiken drohen.