Softwareentwicklung in jungen Internetunternehmen

Diplomarbeit von Martin Zihla

Einleitung:

Auch heute stellt die Entwicklung von Software noch eine Herausforderung dar. Obwohl es zahlreiche Methoden gibt, die sich mit der Gestaltung eines optimalen Entwicklungsprozesses befassen, existiert noch kein universell einsetzbares Vorgehensmodell. Das Aufkommen der als agil bezeichneten Methoden der Softwareentwicklung hat darüber hinaus eine Diskussion über die korrekte Vorgehensweise bei der Entwicklung von Software angeregt. Junge Internetunternehmen müssen sich folglich nicht nur mit dem komplexen Gebiet des Software Engineering auseinander setzen, sondern sind auch den Einflüssen durch die schnelllebige Net Economy ausgesetzt. Dadurch sehen sie sich einer besonderen Herausforderung gegenüber.

Die zentrale Frage im Hinblick auf die Gestaltung des Entwicklungsprozesses ist somit nicht nur die durch Hruschka gestellte: „Wie viel ist ausreichend und wo beginnt die bürokratische Übertreibung?“ Für junge Internetunternehmen gilt es darüber hinaus zu ergründen, was in ihrer speziellen Situation und unter den gegebenen finanziellen und personellen Rahmenbedingungen überhaupt realisierbar und wirtschaftlich sinnvoll ist. Aus Sicht der Wirtschaftsinformatik ist diese Fragestellung interessant, da sie die Frage nach einer optimalen Vorgehensweise bei der Entwicklung von Internetanwendungen mit der Frage nach dem wirtschaftlichen Sinn der Realisierung einer solchen Vorgehensweise in Gründungsunternehmen verknüpft.

Die Situation von jungen Internetunternehmen lässt die Möglichkeit der sinnvollen Anwendung von wissenschaftlichen Erkenntnissen über die Entwicklung von Software auf die eigenen Projekte oftmals als fraglich erscheinen. Allein die in der Regel kleinen Teams lassen viele Methoden als völlig überdimensioniert erscheinen. Die regelmäßige, enge Zusammenarbeit zwischen den Gründern eines Internetunternehmens gibt zudem häufig Anlass zum Zweifel daran, ob die Formalisierung des Entwicklungsprozesses wirklich einen Mehrwert bietet. Obwohl die agilen Methoden der Softwareentwicklung hauptsächlich für kleine bis mittelgroße Teams entworfen wurden, ist ihre Anwendbarkeit in jungen Internetunternehmen zu hinterfragen, da auch diese Methoden grundlegende Annahmen über die Situation, in der ein Softwareprojekt durchgeführt wird, treffen.

Gang der Untersuchung:

Es gilt folglich zu untersuchen, was die spezielle Situation von Gründungsunternehmen in der Net Economy ausmacht und welche Implikationen sich hieraus für den Entwicklungsprozess und das Architekturdesign ergeben. Um dies zu ermöglichen erfolgt in Kapitel 2 eine Betrachtung der Net Economy, wobei auf die grundlegenden Merkmale dieser sowie auf die spezielle Situation der Gründungsunternehmen eingegangen wird. In Kapitel 3 werden die unterschiedlichen Ansätze des Software Engineering beschrieben, wobei schwerpunktmäßig die Unterschiede zwischen den agilen und den planungsgetriebenen Methoden der Softwareentwicklung betrachtet werden. Weiterhin erfolgt eine Betrachtung des Web Engineering, welches hauptsächlich die Charakteristika von Web-Anwendungen und die sich aus ihnen ergebenden Anforderungen an einen Entwicklungsprozess untersucht.

Die Rolle des Architekturdesigns und der Softwarearchitektur im Entwicklungsprozess wird in Kapitel 4 beschrieben. In Kapitel 5 wird der Versuch unternommen, aufbauend auf bereits bestehenden Ansätzen zur Klassifikation von Softwareprojekten, ein Projektframework speziell für Gründungsunternehmen in der Net Economy zu entwerfen. Ziel des Frameworks ist es, Projekte in jungen Internetunternehmen anhand von passenden Unterscheidungsmerkmalen besser voneinander abgrenzen zu können.

Aus den im Rahmen des Frameworks identifizierten Projektmerkmalen sowie den Erkenntnissen aus den vorherigen Kapiteln werden in Kapitel 6 Anforderungen an das Architekturdesign und den Entwicklungsprozess formuliert. In Kapitel 7 folgt ein abschließendes Fazit sowie ein Ausblick auf die weitere Vorgehensweise im Hinblick auf die in dieser Arbeit formulierten Anforderungen.

Inhaltsverzeichnis:

Textprobe:

Kapitel 3.3.3, Der Faktor Mensch:

Der Faktor Mensch ist ein zentraler Bestandteil der agilen Methoden. Selbstorganisierende Teams, das Streben nach technischer Exzellenz sowie nach der fortschreitenden Verbesserung der eigenen Effektivität verlangen nach fähigen und motivierten Entwicklern. Nach Hruschka „(...) sind hoch motivierte, selbstständige, gut ausgebildete Projektteams, die dann aufgrund ihrer Erfahrungen situationsgerecht richtig entscheiden können, wie die Ziele effizient erreicht werden [eine der wesentlichen Voraussetzungen für die Anwendung agiler Prinzipien].“ Er konstatiert weiterhin: „Agilität setzt also nicht nur auf mutige, engagierte Mitarbeiter, sondern vor allem auch auf mutige, charismatische Führungspersönlichkeiten.“ Dies kann allerdings auch ein einschränkender Faktor sein. So stellt Constantine etwa kritisch fest: „There are only so many Kent Becks in the world to lead the team. All of the agile methods put a premium on having premium people (...).“ Die Fähigkeit der Entwickler ist also ein zentraler Erfolgsfaktor bei der Anwendung agiler Methoden. Um die Fähigkeiten bezüglich des Einsatzes von Entwicklungsmethoden zu beschreiben, leitet Cockburn von den drei Verständnisebenen des Aikido (Shu-Ha-Ri) drei Ebenen des Verständnisses für Softwareentwicklungsmethoden ab.148 Diese werden von Boehm/Turner angepasst, um sie sowohl für agile als auch für planungsgetriebene Methoden einsetzen zu können:

Level 3: Der Entwickler ist in der Lage, eine Methode zu überarbeiten und an neue, noch nie da gewesene Situationen anzupassen.

Level 2: Der Entwickler kann eine Methode an eine neue Situation anpassen (Präzedenzfall vorhanden).

Level 1A: Nach einem Training ist der Entwickler dazu in der Lage, stark vom eigenen Ermessen abhängige Methodenschritte (bspw. die Anpassung von user stories an Inkremente) durchzuführen. Mit zunehmender Erfahrung ist ein Aufstieg auf Level 2 möglich.

Level 1B: Nach einem Training ist der Entwickler dazu imstande, prozedurale Methodenschritte durchzuführen (z.B. eine simple Methode zu programmieren oder Programmierstandards einzuhalten).

Level -1: Der Entwickler besitzt evtl. technische Fähigkeiten, ist aber weder zur Zusammenarbeit mit anderen Entwicklern noch zur Verwendung einer Methodik bereit.

Nach Boehm/Turner können Level 1B Entwickler gut in Teams eingesetzt werden, die eine planungsgetriebene Methode verwenden und in einem stabilen Umfeld operieren. Ein Team das auf agile Methoden setzt und sich mit einer unsicheren und instabilen Situation konfrontiert sieht, kann jedoch durch 1B Entwickler verlangsamt werden. Projekte mit agilen Methoden können gut von Level 1A Entwicklern durchgeführt werden, wenn genügend Level 2 Entwickler vorhanden sind, um diese zu führen. Die Notwendigkeit, mindestens einen Level 2 (oder höher) Entwickler im Projektteam zu haben, wird auch von Cockburn betont. Level 2 Entwickler können, ebenso wie solche auf Level 3, für das Management agiler oder planungsgetriebener Teams gleichermaßen gut eingesetzt werden. Zusammenfassend kann gesagt werden, dass agile Methoden sich am besten einsetzen lassen, wenn die Entwickler zum Großteil mindestens Level 1A erreicht haben. Planungsgetriebene Methoden können hingegen im späteren Projektverlauf auch gut mit vielen Level 1B Entwicklern funktionieren.

Einfachheit:

Einer der Hauptunterschiede zwischen den traditionellen, planungsgetriebenen und den agilen Ansätzen der Softwareentwicklung ist der Umfang und der Detailgrad der Methoden. Traditionelle Methoden haben oft sehr detaillierte Vorgaben für Rollen, Aktivitäten, Prozesse, Techniken und Werkzeuge. Agile Methoden hingegen setzen auf minimale Prozesse, Dokumentation und Formalitäten. Das Hauptziel der agilen Methoden besteht darin, funktionierende Software zu liefern, die den Kunden zufrieden stellt. Dabei gilt es allerdings auch das Nebenziel zu beachten: Die Software muss auch in Zukunft wart- und anpassbar sein. Hierbei besteht die Schwierigkeit darin festzulegen, wie viel Zusatzaufwand nötig ist, um dieses Nebenziel zu erreichen. Nach Hruschka ist deshalb eine der Hauptfragen beim Einsatz agiler Methoden: „Wie viel ist ausreichend und wo beginnt die bürokratische Übertreibung?“ Er schlägt vor, dass das Vorgehensmodell zur Erreichung der Ergebnisse „gerade eben ausreichend sein“ soll. Cockburn benutzt dafür die Bezeichnung „barely sufficient“ und betont, dass dies nicht nur im Hinblick auf das Hauptziel (laufende Software), sondern auch für die Erreichung des Nebenziels gilt. Der Ansatzpunkt bei vielen agilen Methoden ist es, lediglich einige wenige zu Grunde liegende Regeln vorzugeben. Diese Regeln beschreiben allerdings nicht alles, was in einem Softwareentwicklungsprojekt getan werden muss. Die Idee hinter diesem Vorgehen liegt vielmehr darin, dass die zugrunde liegenden Regeln immer eingehalten werden müssen. Aufbauend auf diesen Regeln sollen, wenn nötig, im Laufe des Projekts Erweiterungen vorgenommen werden. Highsmith verweist hier auf die Erforschung komplexer adaptiver Systeme.157 Diese zeichnen sich u.a. durch das emergente komplexe Verhalten eines Systems auf der Basis von einfachen Regeln für die Interaktion zwischen seinen Individuen aus.

Einfachheit ist aber nicht nur das Ziel im Hinblick auf die Gestaltung des Projektmodells, sondern auch im Hinblick auf das Design der Software. Traditionelle Projektmodelle setzen oft auf eine ausgedehnte Designphase vor dem eigentlichen Beginn der Programmierung. Dies wird oft auch als „Big Design Up Front“ (BDUF) bezeichnet. Agile Methoden hingegen setzen, wie das Agile Manifest verdeutlicht, auf Emergenz,: „The best architectures, requirements, and designs emerge from self-organizing teams.“ Gegner des agilen Ansatzes sehen darin einen großen Schwachpunkt, da sie befürchten, dass durch das Fehlen einer expliziten Designphase unstrukturiertes Hacking Einzug hält. Fowler nimmt sich diesem Kritikpunkt mit seinem etwas provokativ formulierten Artikel „Is Design Dead?“ an. Das Ergebnis seiner Untersuchung ist, dass auch bei agilen Methoden wie XP Design stattfindet. Design ist somit nicht tot, hat aber seine Natur verändert. Anstelle des BDUF tritt bei den agilen Methoden das evolutionäre Design. Dies zeichnet sich dadurch aus, dass das Design wächst, während das System implementiert wird. Highsmith betont, dass bei agilen Ansätzen Planung, Architektur und Anforderungen keine Phasen, sondern Aktivitäten des Entwicklungsprozesses darstellen. Ihm zufolge kann ein agiler Ansatz genau soviel Zeit für diese Aktivitäten aufwenden, wie ein traditioneller – dies dann allerdings über multiple Iterationen hinweg. Martin sieht beim Softwaredesign die Gefahr, dass selbst ein gutes initiales Design mit der Zeit degradiert, wenn es nicht konstant an veränderte Anforderungen und Erkenntnisse angepasst wird. Der Ansatz des evolutionären Designs kommt dieser Erkenntnis entgegen, da hier das Design nicht von der Implementierung entkoppelt wird. Im Gegensatz zu sequenziellen Prozessmodellen (vgl. Kapitel 3.2.1) werden Tätigkeiten wie Analyse, Design, Implementierung und Testen nicht nacheinander, sondern parallel durchgeführt. Sowohl beim Testen als auch beim Codieren können bspw. Erkenntnisse gewonnen werden, die unmittelbare Auswirkungen auf das Design des Systems haben. Diese Erkenntnisse können beim evolutionären Design flexibler berücksichtigt werden, so dass das Design im Entwicklungsprozess ständig verbessert werden kann. Neben dem potenziellen Vorteil der Flexibilität besteht hier aber auch die nicht zu vernachlässigende Gefahr eines nicht-konvergierenden Designs.