Was hat ein Filmklassiker der 1960er Jahre mit moderner Softwareentwicklung zu tun? Auf den ersten Blick nichts. Auf den zweiten Blick – den Blick eines Entwicklers – hat sie jedoch sehr viel mit „Dr. Seltsam: Oder wie ich lernte, die Bombe zu lieben“ gemeinsam. Wie eine Bombe stellen nämlich „Softwareproduktivität“ oder „Application-Lifecycle-Management“ (ALM) durchaus eine reale Bedrohung für den Entwickler dar. Entwicklung als kreative Tätigkeit mit Produktivität in Verbindung zu bringen, scheint ein Widerspruch in sich zu sein.

Weitaus dramatischer wirkt dazu noch der Ansatz, Produktivitätssteigerungen durch Anwendung von Konzepten wie Application-Lifecycle-Management zu erreichen. Zumindest aus der Entwicklerperspektive sieht das zunächst nach Freiheits- und Kreativitätsverlust aus. Doch ist das wirklich so? Genauer betrachtet schafft Application-Lifecycle-Management genau die Freiräume, um Kreativität freizusetzen und letztendlich auch die Produktivität zu steigern. Machen wir uns also auf, Application-Lifecycle-Management lieben zu lernen.

Softwareproduktivität – Grau ist alle Theorie

Was ist Softwareproduktivität? Von Barry W. Boehm gibt es eine sehr allgemeine Definition von Produktivität:

Diese Formel zeigt deutlich, dass die Produktivität steigt, wenn die Summe der Ergebnisse erhöht wird oder aber sich der Verbrauch der eingesetzten Ressourcen verringert. Einfach formuliert bedeutet es, das Maximum an Ergebnis mit einem Minimum an Aufwand zu erreichen. In den klassischen Industrien, etwa der Automobilindustrie, fällt es nicht schwer, die Gleichung mit Inhalten zu füllen. Anders ist es jedoch in der modernen IT-Industrie, speziell in der Softwareentwicklung. Denn was ist das Ergebnis der Softwareentwicklung? Ein Stück ausführbarer Programmcode, der in der Produktion ohne weiteren Aufwand millionenfach kopiert werden kann. Anders als in anderen Industrien ist also in der Softwareentwicklung der Aufwand während der Entwicklung der maßgeblich bestimmende Anteil der Produktivität.

Um Kennzahlen für die Softwareproduktivität zu ermitteln, gibt es nun unterschiedliche Ansätze. Offensichtlich ist, dass ein einfacher Ansatz wie „Lines of Code” geteilt durch die Anzahl der Entwickler (oder der Projektmitarbeiter) zu kurz gedacht ist. Denn hier kann entweder die Zahl der Lines of Code einfach erhöht oder die Zahl der Entwickler/Projektmitarbeiter anders definiert werden, und schon ergibt sich eine bessere Produktivität. Demzufolge muss der Begriff der Softwareproduktivität wesentlich weiter gefasst werden. Das spiegelt sich auch in den modernen Softwareentwicklungsprozessen wider. Egal ob V-Modell, RUP oder agile Prozesse – alle behandeln die Entstehung von Software als ein komplexes Zusammenspiel von Anforderungsdefinition, Design, Entwicklung, Testen und Betrieb. In allen Modellen finden sich Metriken und Auswertungen, die dazu gedacht sind, die Softwareproduktivität zu messen. Diese Metriken beschäftigen sich zum Beispiel damit, wie viele Anforderungen in einer Iteration eines Meilensteins umgesetzt worden sind, wie viele Fehler in einer bestimmten Zeit behoben worden sind etc.

Letztendlich besteht dann die eigentliche Herausforderung in der Messung bzw. der Bewertung der Daten aus den unterschiedlichen Bereichen. Wie werden die Informationen aus dem Anforderungsmanagement mit den Informationen aus dem Design oder Konfigurationsmanagement zusammengebracht? Bereits seit mehreren Jahren gibt es von verschiedenen Toolanbietern Angebote auf dem Markt, die unter dem Stichwort Application-Lifecycle-Management (ALM) gehandelt werden. Dies sind Zusammenstellungen von Werkzeugen, die jeden Bereich der Softwareentwicklung abdecken und so eine End-to-End-Lösung für die Entwicklungsprojekte anbieten und letztendlich auch eine Messung der Softwareproduktivität ermöglichen sollen. Aber eine Suite von Werkzeugen, die eine Anwendung zur Anforderungsdefinition und zum Testmanagement enthält, ist noch lange keine ALM-Lösung. Denn dabei kommt es darauf an, dass die einzelnen Spezialdisziplinen miteinander integriert sind und die damit verbundenen Prozesse gelebt werden. Die fehlenden Integrationen und die Einfachheit der zu lebenden Prozesse sind die Punkte, an denen die ersten ALM-Lösungen vielfach Schwächen hatten.

Licht am Ende des Tunnels

Softwareentwicklung ist ein komplexer Prozess, und nach den bisher gemachten Erfahrungen kann dieser nur von ganzheitlich ansetzenden ALM-Lösungen beherrscht werden. Ganzheitlich bedeutet in diesem Fall, dass die ALM-Lösung nicht eine Sammlung von Einzellösungen mit einer Anzahl von Features ist, sondern dass der Teamgedanke im Vordergrund steht und nur die Funktionalitäten in die Werkzeuge eingebaut werden, die die Projektarbeit im Team unterstützen. Nicht zuletzt ist der Begriff für diese Lösungen dann nicht mehr nur Application-Lifecycle-Management, sondern vielmehr Collaborative-Application-Lifecycle-Management (CALM). Um ein Beispiel für einen solchen Ansatz zu nennen: IBM Rational Team Concert, basierend auf dem Jazz-Projekt, stellt als komplette Neuentwicklung die Funktionalität bereit, die ein Team in einem Softwareentwicklungsprojekt benötigt: Iterationsplanung, Aufgabenmanagement, Versionskontrolle, Build-Management und Fortschrittsauswertung.

Das sind sicherlich alles Themen, die einen Projektmanager oder einen Entwicklungsleiter aufhorchen lassen. Aber was bedeutet das für den einzelnen Entwickler in einem solchen Projekt? Bedeutet das nicht eine Einschränkung seiner Kreativität? Bei so vielen Managementkomponenten: Wo bleibt da der Freiraum für die Entwicklung? Und wie wirkt sich das letztendlich auf die Produktivität aus? Statt trockener Kennzahlen und Statistiken soll das folgende praktische Beispiel eine typische Situation verdeutlichen. Es handelt sich dabei um kein reales Softwareentwicklungsprojekt, sondern um eine Art Simulation, die die wichtigsten Erkenntnisse im Zeitraffer darlegt.

Neulich auf einer Entwicklerkonferenz

Ein Unternehmen, das sich mit agilen Softwareentwicklungsprozessen beschäftigt, möchte auf einer Konferenz Besucher an seinen Stand locken. Es vergibt also an jeden Teilnehmer einen einzelnen Legostein. Mit diesen Steinen sollen dann die Teilnehmer am Stand eine Ritterburg bauen. Die einzige Vorgabe, die das Unternehmen macht, ist ein Zeitlimit von 30 Sekunden. Innerhalb dieser Zeit können die Besucher alles machen, also abreißen oder unter Zuhilfenahme zusätzlicher Steine bauen. Auf diese Weise möchte das Unternehmen die Kreativität der Entwickler wecken. Am Abend des ersten Tages hat das Ergebnis aber nur entfernt etwas mit einer Ritterburg zu tun. Zwar gab es durchaus schöne Einzellösungen, wie zum Beispiel Balkone oder Verliese, aber ein Gesamtkonzept ist nicht zu erkennen.

Darum ändert das Unternehmen am zweiten Tag der Konferenz sein Konzept. Nun gibt es ein Designmodell, also eine Zeichnung der zu erstellenden Burg. Darüber hinaus existiert nun auch ein Anforderungsdokument, in dem die wichtigsten Anforderungen beschrieben werden, etwa die Höhe der Mauer, die Anzahl der Türme und dass eine Zugbrücke eingebaut werden soll. Ferner gibt es nun auch eine Qualitätskontrolle: Ein Mitglied der Standbesetzung vergleicht den aktuellen Stand der Bauarbeiten mit dem Modell und dem Anforderungsdokument und führt in den Zeiten zwischen den einzelnen Bauphasen notwendige Korrekturarbeiten durch. Von diesen Vorgaben abgesehen können die Entwickler aber wieder ihrer Kreativität freien Lauf lassen. Am Abend des zweiten Tages sind die meisten Vorgaben umgesetzt worden, und auch das Designmodell ist ziemlich gut getroffen. Der Projektfortschritt ist ziemlich gut erkennbar, denn die Ritterburg sieht wesentlich funktionstüchtiger als die vom Vortag aus.

Anzeige
Was soll dieses Beispiel an dieser Stelle? Im Prinzip haben wir hier ein Entwicklungsprojekt im Zeitraffer gesehen und auch die Ergebnisse der beiden deutlich voneinander verschiedenen Arbeitsweisen. Am ersten Tag gab es keine Vision, keine genau definierten und vor allen Dingen leicht zu verstehenden Anforderungen. Auch die Prozessvorgabe war relativ schwach und es wurde kaum auf die Einhaltung der Vorgaben geachtet. Im Endeffekt bedeutete dieser Modus, dass von der jedem Entwickler zur Verfügung stehenden Zeit (30 Sekunden) erst einmal ein großer Teil dafür verloren ging, sich den Überblick zu verschaffen: Was gibt es schon? Wo könnte ich ansetzen? Weitere Zeit ging beim Überlegen verloren, was eigentlich gebaut werden sollte. Am Ende blieb für die eigentliche Entwicklungsarbeit nur wenig Zeit übrig, sodass eine nur halbfertige Burg mit niedrigen Mauern, ohne Zugbrücke und zum Teil mit groben Fehlern entstanden ist.

Am zweiten Tag dagegen gab es eine klare Vision, ein Design, beides wurde klar kommuniziert und war jederzeit sichtbar. Durch diese Vorgaben hatten die Entwickler keine Mühe, sich zurechtzufinden, und konnten direkt mit der Entwicklung beginnen. Unter dem Strich konnte jeder wesentlich mehr der kostbaren 30 Sekunden auf das Bauen verwenden als am ersten Tag. Im Ergebnis war die Ritterburg kompletter als die des ersten Tages, und vor allen Dingen waren die Anforderungen getroffen.

What‘s in it for me?

Welche Rückschlüsse können aus diesem Beispiel abgeleitet werden? Das wichtigste Ergebnis ist deutlich zu sehen: Kreativität, wenn sie nicht zielgerichtet eingesetzt wird, führt zu einem kreativen Chaos. Mit dem richtigen Maß an Anleitung und Management aber führt Kreativität letztendlich zu einer wesentlich besseren Produktivität. Oder anders ausgedrückt: ALM ist notwendig – wenn es in meinem Projekt stattfindet, dann muss ich mich als Entwickler abfinden. Also gilt es, den richtigen Nutzen daraus zu ziehen. Hier kommt dem einzelnen Teammitglied der ganzheitliche Ansatz der modernen ALM-Lösungen entgegen.

Wie weiter oben schon angedeutet, hat bei den Softwareherstellern ein Umdenken stattgefunden. Anstatt Features in den Vordergrund zu stellen, liegt das Hauptaugenmerk darauf, was in einem Softwareentwicklungsteam wirklich benötigt wird. Welche Arbeitsweisen machen eine Softwareentwicklung wirklich effektiv? Zu dem Stichwort Effektivität gibt es einen sehr schönen Beitrag von Eric Lopes Cardozo „The seven habits of effective iterative development”. Angelehnt an die Bücher von Stephen Covey (zum Beispiel „Die 7 Wege zur Effektivität“) beschreibt Cardozo, wie die „seven habits“ auch in iterativen Softwareentwicklungsprojekten nutzbar sind. Fast jeder kennt die einfachen „Habits” und weiß, dass ein Befolgen der Regeln zu größerem Erfolg führt. Die Kernaussagen der „Seven Habits“ sind:

  • Be proactive: In der Softwareentwicklung heißt das Risiken frühzeitig erkennen und adressieren. Das Bearbeiten von Risiken ist damit gebunden, dass alle im Team zeitnah und umfassend über die zu erwartenden Risiken informiert werden. Moderne ALM-Lösungen haben deshalb nicht nur die Möglichkeit, Risiken explizit zu erfassen, sondern geben an alle Teammitglieder transparent und übersichtlich Auskunft über deren Auftreten und Auswirkungen. Erst dadurch können Risiken rechtzeitig erkannt und adressiert werden.
  • Begin with the end in mind: Von Cardozo auf die iterative Softwareentwicklung übertragen bedeutet dies: Strukturiere dein Projekt anhand von klaren Zielen in Iterationen. Jede Iteration hat ein Ziel, zum Beispiel das Erreichen eines Meilensteins. Solche Pläne, Projektpläne, Iterationspläne gibt es sicherlich in allen Softwareentwicklungsprojekten. Aber was nützen sie dem Entwickler, wenn der Plan an der Wand des Projektleiters hängt? Auch für die einzelnen Teammitglieder gilt, dass sie für die alltägliche Arbeit die Ziele leicht zugänglich vor Augen haben sollen. Hier stellen moderne ALM-Lösungen den Iterationsplan in eine zentrale Position. Die Pläne sind jederzeit für alle Teammitglieder zugänglich und der Fortschritt im Projekt wird dort jederzeit aktuell dargestellt. Dabei ist der Iterationsplan selbst nicht nur die textliche Darstellung der Vision, sondern auch Organisationsmittel für die Abarbeitung der Aufgaben. Dadurch, dass jedes Teammitglied die Ziele und Aufgaben einer Iteration jederzeit verfügbar hat, ist diese Habit in einer ALM-Lösung perfekt umgesetzt.
  • Put first things first: Auch hier wird jeder sagen „Klar, das weiß ich doch. Das Wichtige erledige ich immer zuerst!”. In der Softwareentwicklung, wie in jedem anderen Bereich auch, gilt es aber, die wichtigen Dinge zu erkennen. Dazu gehört, dass in einem Entwicklungsteam nicht nur Fehler und Erweiterungswünsche abgearbeitet werden müssen, sondern zu dem Projekt auch andere Aufgaben, Risiken, Ideen usw. gehören. ALM-Lösungen setzen dort an und stellen alle Arten von Aufgaben gleichberechtigt nebeneinander, jeweils mit der Möglichkeit zu priorisieren und nach der Schwere einzuteilen. Auch hier gilt wieder: Dadurch, dass die Lösung an sich diese Aufgaben jederzeit aktuell darstellt, fällt es den Projektmitarbeitern leicht, eine Entscheidung zu fällen.
  • Think Win-Win: Eine Win-Win-Situation in der Softwareentwicklung herbeizuführen bedeutet, ein Maximum an Businessanforderungen mit einem Minimum an Aufwand zu implementieren. Um eine solche Abschätzung machen zu können, muss das Projekt die zu erwartenden und die realen Aufwände miteinander ins Verhältnis setzen. Deshalb bieten moderne ALM-Lösungen den Anwendern an, diese Aufwände – geplante und erledigte – mit den entsprechenden Aufgaben zu speichern. Gleichzeitig werden Aufwände summiert und im Iterationsplan dargestellt, sodass jeder Mitarbeiter den aktuellen Stand der Iteration und das Verhältnis der geschafften Arbeit zum geleisteten Aufwand ersehen kann. Nur durch eine solche transparente Darstellung ist es möglich, noch ausstehendes Potenzial für die Schaffung solcher Win-Win-Situationen zu erkennen. Bei einigen Lösungen stehen diese Möglichkeiten auch dem einzelnen Mitarbeiter zur Verfügung. Die ALM-Lösungen zeigen den Auslastungsgrad des Mitarbeiters an und geben ihm auch für die eigene Planung der Aufgaben die Möglichkeit, Freiräume für wichtige Arbeiten zu finden (siehe auch Put first things first).
  • Seek first to understand, then to be understood: Nicht erfolgreiche Softwareentwicklungsprojekte haben häufig das Problem, dass die Kommunikation im Team und zum Kunden nicht funktioniert. Das wirkt sich dann natürlich auch auf die Zusammenarbeit aus. An der Stelle setzen wiederum die ALM-Lösungen an. Durch die Nutzung von Web-2.0-Technologien wie RSS-Feeds und Chat direkt in der Entwicklungsumgebung ist es einfach, Informationen zu bekommen. Änderungen an Aufgaben sind ständig transparent verfügbar. Aber eine solche Art der Kommunikation und Zusammenarbeit ist nicht nur auf die Arbeit innerhalb eines Projekts beschränkt. Auch der Austausch mit dem Kunden kann mit modernen ALM-Lösungen verbessert werden. Ein Beispiel dafür ist die Seite jazz.net, auf der IBM die Entwicklung der neuen JAZZ-Technologie mit Kunden und Interessenten diskutiert. Wie auch schon bei den anderen diskutierten Habits ergibt sich, dass ALM-Lösungen ganz klar die Kommunikation in den Vordergrund stellen und somit zum Collaborative-Application-Lifecycle-Management werden.
  • Synergize: Ein gut funktionierendes Teamwork ist besser als die Summe der individuellen Arbeitsergebnisse. Der Teamgedanke steht in den ALM-Lösungen an erster Stelle. Die real existierenden Teams werden im Werkzeug in virtuellen Teams abgebildet. Ebenso werden die unterschiedlichen Rollen, die die Projektmitarbeiter haben, übertragen. Da diese Rollen natürlich auch verschiedene Pflichten und Rechte haben, unterstützt eine ALM-Lösung jeden Projektmitarbeiter in der Einhaltung des zu befolgenden Prozesses. Alle Softwareentwicklungsteams beanspruchen für sich, nach einem Prozess zu arbeiten. Aber nur in den erfolgreichen Teams wird der Prozess auch tatsächlich eingehalten. Die Durchsetzung bzw. Kontrolle der Einhaltung des Prozesses ist mit modernen Werkzeugen möglich, da in diesen Lösungen der Prozess schon „eingebaut” ist. Synergien ergeben sich dadurch, dass dem Projektmitarbeiter seiner Rolle entsprechende Aktionen angeboten oder auch verwehrt werden. Dadurch, dass er sich nicht aktiv selbst um den Prozess an sich kümmern muss, bleibt natürlich mehr Zeit für die kreative Arbeit.
  • Sharpen the saw: Dieser Habit beschäftigt sich mit der Aus- und Weiterbildung. Nur durch ständiges Lernen und Verbessern lässt sich die eigene Arbeitsleistung steigern. Das gilt natürlich für den einzelnen Projektmitarbeiter, aber genauso auch für die Verbesserung der Arbeitsweise im Projekt. Anpassungen am Prozess für einzelne Teams, Erweitern der Workflows und natürlich auch das fortwährende Neuplanen oder erweiterte Planen der Iterationen und der damit verbundenen Aufgaben. Um hier tatsächlich die „Säge schärfen” zu können, müssen natürlich die Schwachstellen im Projekt transparent und möglichst aktuell dargestellt werden. Deshalb sind Metriken und voreingestellte Dashboards mit den wichtigsten Reports und Übersichten ein zentraler Bestandteil von ALM-Lösungen. Verbesserungspotenzial, sei es nun das persönliche für den Entwickler oder das generelle für das gesamte Projekt, muss erst einmal erkannt werden, um es tatsächlich zu erreichen.

Anzeige
Ein Blick auf die Arbeitsweise moderner ALM-Lösungen hinterlässt den Eindruck, als ob diese Kernaussagen bei der Entwicklung Pate gestanden haben. Oder anders gesprochen: Der größte Nutzen aus einer ALM-Lösung wird dann erreicht, wenn versucht wird, nach den Seven Habits zu arbeiten.

Auf den Punkt gebracht

ALM ist in aller Munde und ALM-Lösungen versprechen, die Softwareentwicklung beherrschbar zu machen. Aktuelle Softwareprojekte kommen nicht um den Einsatz solcher Werkzeuge herum, um das Potenzial des Entwicklungsteams auszuschöpfen. Für die einzelnen Teammitglieder bedeutet das, sich die Vorteile der Werkzeuge herauszupicken. Im Vergleich zu ersten Versionen ist dies mittlerweile einfacher geworden, da die Toolhersteller mehr Augenmerk auf Kommunikation und Zusammenarbeit im Team legen. Effektives Arbeiten im Team, selbst in großen geografisch verteilten Projekten ist möglich. Und so kann es tatsächlich zu einem hollywoodreifen Happy-End für die Entwickler kommen: von der Zwangsehe hin zur Liebesheirat.

Über den Autor:

Dr. Henning Sternkicker studierte an der RWTH Aachen und promovierte dort 1999 im Fachbereich Chemie. Seit Anfang 2000 betreut er für Rational Software Kunden im Bereich Change und Release Management als Trainer, Berater und Technical Sales.

Dieser Artikel entstand im Zuge einer Kooperation mit der von Createordie organisierten webinale, die vom 31. Mai bis 02. Juni 2010 in Berlin stattfindet.

Bildmaterial: mzacha