Impressum

Nils Langner
Erfolgreiche Softwareprojekte im Web
100 Gedanken zur Webentwicklung

ISBN: 978-3-86802-620-7
© 2013 entwickler.press

Ein Imprint der Software & Support Media GmbH

Bibliografische Information Der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen
Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über
http://dnb.ddb.de abrufbar.

Ihr Kontakt zum Verlag und Lektorat:
Software & Support Media GmbH
entwickler.press

Darmstädter Landstraße 108
60598 Frankfurt
Tel.: +49 (0)69 630089-0
Fax: +49 (0)69 930089-89
lektorat@entwickler-press.de
http://www.entwickler-press.de

Lektorat: Sebastian Burkart
Korrektorat: Frauke Pesch
Satz: Laura Acker, Dominique Kalbassi

Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

Für meine Frau, ohne die dieses Buch nie zustande gekommen wäre.

Einleitung

Als ich im Jahre 2008 begonnen habe, für meinen Blog „phphatesme“ zu schreiben, versuchte ich, möglichst viel über Programmierprobleme im Bereich PHP zu verfassen. Nach einem Jahr und über 200 Artikeln wurden die codespezifischen Probleme, die ich beschreiben wollte, immer weniger und allgemeine Themen kamen an die Tagesordnung; allgemeine Themen, die sich mit der Softwareentwicklung im Ganzen beschäftigen – unter anderem Projektmanagement, Softwaretechnik und Qualitätssicherung. Erstaunlicherweise stieg die Leserzahl mit dem Wechsel enorm an, was den Schluss zuließ, dass genau diese Themen zu selten besprochen werden. Die Idee hinter den Artikeln war es, dem Leser ein Thema immer so nahe zu bringen, dass er ab diesem Zeitpunkt selbst daran weiterarbeiten und sich informieren kann. Der Ansatz war erfolgreich, was man an der Vielzahl weiterführender Kommentare merken konnte.

Der Blog wurde ein fester Bestandteil der deutschsprachigen PHP-Gemeinde, wodurch ich die Chance bekam, sehr viele große Namen aus der Szene kennenzulernen. Gespräche mit den „Helden meiner Kindheit“ brachten immer wieder neue Ideen für Artikel hervor, haben aber gezeigt, dass auch sie nur mit Wasser kochen und des Öfteren durch meinen Blog selbst inspiriert wurden. Motiviert durch dieses Kompliment kam 2011 die Idee auf, meinen Blog für einige Zeit zu schließen, und mich an mein erstes Buch zu setzen. Dieses Buch sollte die konsequente Fortsetzung der Artikel sein, die online bereits einem breiten Spektrum gefielen.

2012 ging es los mit der Ideenfindung. Inspiriert durch Joel Spolsky (www.joelonsoftware.com) mit seinem Blog „Joel on Software“, der den Schritt von Blog zu Buch auch gegangen ist, wurde das Konzept beim Verlag eingereicht. Das Buch sollte als eine Art gedruckter Blog fungieren und die Themenbereiche abdecken, die auch online vertreten waren. Die Themen sollten kurz angeschnitten werden und auf zwei bis drei Seiten den Leser an einen Punkt bringen, an dem Interesse geweckt wurde. Sicher wird man nach der Lektüre eines Kapitels nicht ein besserer Projektmanager oder Entwickler, aber man weiß, dass es dort draußen noch Themen gibt, mit denen es sich zu beschäftigen lohnt, um wirklich besser zu werden. Die Kapitel hatten ebenfalls den Anspruch, so kurz zu sein, dass man sie morgens in der Bahn vor der Arbeit durcharbeiten, den Tag darüber nachdenken und am Abend ein wenig über das Thema weiterlesen kann. Dieses Konzept bedeutet aber auch, dass Themen nicht bis zum Ende ausformuliert werden können, ansonsten wären 100 Kapitel ein hehres Ziel. Dies war aber auch nie das Ziel. Der breite Überblick über wiederkehrende Herausforderungen, die in der Softwareentwicklung gelöst werden müssen, stand im Fokus. Sicherlich wurden über alle Themen, die hier zu finden sind, bereits Bücher und Artikel geschrieben, sie wurden nur noch nie in dieser Kompaktheit zusammengestellt.

Die einzelnen Kapitel sind mit Themen gefüllt, die jeden Entwickler früher oder später beschäftigen werden. Sie sind Bestandteil vieler Projekte und spiegeln Herausforderungen wieder die ich in den letzten Jahren lösen musste. Dabei hat es sich immer stärker herauskristallisiert, dass ich ein Anhänger der agilen Methoden bin, was sich auch in vielen Artikeln widerspiegelt. Auch wenn die meisten der siebzig hier niedergeschriebenen Kapitel im Webumfeld und im Besonderen anhand der Programmiersprache PHP entstanden sind, ist dieses Buch kein Buch über Technologien. Die wichtigen Aussagen, die getroffen werden, sind allesamt unabhängig von der verwendeten Sprache oder der Art des Projekts, was eines der Hauptziele dieses Buchs ist.

Viele der Aussagen, die in diesem Buch getätigt werden, beruhen auf den Erfahrungen, die ich im Laufe meiner professionellen Karriere gesammelt habe. Baz Luhrmann, ein australischer Regisseur, Drehbuchautor und Schauspieler, hat wunderbar ausgedrückt, wie dieses Buch zu verstehen ist.

If I could offer you only one tip for the future, sunscreen would be it. The long term benefits of sunscreen have been proved by scientists whereas the rest of my advice has no basis more reliable than my own meandering.

Das Lied „Everybody’s Free (To Wear Sunscreen)”, aus dem diese Zeilen stammen, fand weltweit Beachtung und schaffte es in England sogar auf Platz 1 der Charts.

Viele Eindrücke und Erfahrungen, die man über die Jahre sammelt, sind nicht messbar oder einfach wissenschaftlich zu belegen. Es wäre schade, sie aus diesem Grund nicht weiterzugeben. Ich bin mir an dieser Stelle trotzdem sicher, dass man sich als Softwareentwickler in fast jedem Kapitel wiederfinden wird, und ähnliche Situationen in seiner eignen Laufbahn bereits erfahren musste.

Der Aufbau des Buchs ist einfach. Die Reihenfolge, in der die Kapitel einsortiert wurden, entspricht den Phasen eines Projekts. Wir beginnen recht allgemein mit Informationen zum Aufbau von Teams und was noch in der Initialisierungsphase zu beachten ist. Dieser Abschnitt geht fließend über in eine Entwurfs- und Umsetzungsphase, bei der es um konkretere Softwareentwicklungsthemen geht. Abschließend werden noch ein paar wichtige allgemeine Gedanken formuliert, die einem helfen, Projekte besser zu verstehen, und das Miteinander stärken sollen.

Die Gastautoren

Wie bereits erwähnt, hatte ich in den letzten Jahren immer wieder die Chance, mit wirklichen Experten zusammen zu arbeiten. Jeder von ihnen war Profi in seiner Domäne und von jedem einzelnen konnte ich etwas mitnehmen. Sei es menschlich oder fachlich. An dieser Stelle möchte ich mich für die vielen guten Gespräche bedanken, die wir geführt haben. Einige von meinen „Lieblingen“ konnte ich dafür gewinnen, an diesem Buch mitzuwirken. Alle wurden gebeten, ihr größtes Learning aus den letzten zehn Jahren in der Softwareentwicklung niederzuschreiben. Ich fand die Frage interessant, was ein Experte an die Nachwelt weitergeben würde, wenn er nur eine Idee überbringen dürfte.

Über den Autor

Nils Langner studierte an der Universität Freiburg Informatik mit Nebenfach Mathematik. Nach seinem erfolgreich abgeschlossenen Studium verschlug es ihn nach Karlsruhe zu Nero, einem der führenden Unternehmen im Bereich Multimediasoftware. Dort verbrachte er einige Jahre als Teamleiter der Intranetentwickler. Mit dem ständigen Ziel, den Entwicklungsprozess zu verbessern, führte er hier das agile Vorgehensmodell Scrum und diverse qualitätssichernde Maßnahmen ein. Bereits damals war der Fokus auf qualitativ hochwertige Software spürbar. Aus diesem Grund war ein Wechsel in diese Branche unabdingbar. Bei Gruner + Jahr fand er eine neue Heimat als Qualitätsmanager, wo er bis heute angestellt ist. Gruner + Jahr als größtes europäisches Verlagshaus betreut Medien wie stern.de, ftd.de oder eltern.de und gehört somit in Deutschland zu den wichtigsten Anlaufstellen im Nachrichtenbereich.

Seit 2008 bloggt Nils Langner erfolgreich für www.phphatesme.com über Themen im Bereich der Softwaretechnik. Mittlerweile wurden diese Artikel durch diverse Veröffentlichungen in Fachmagazinen wie c’t, iX, PHP Magazin oder t3n ergänzt. Seit 2011 ist er regelmäßiger Sprecher auf Entwicklerkonferenzen.

1 Scrum löst eure Probleme nicht

Starke Worte für einen der größten Verfechter der agilen Herangehensweise. Scrum löst die meisten Probleme, die ein Unternehmen hat, nicht, aber es zeigt sie auf. Nehmen wir das klassische Beispiel der Priorisierung. In den meisten Softwareunternehmen werden Task-Tracking-Tools eingesetzt. Betrachtet man dort die Art, nach der priorisiert wird, existiert meist eine Handvoll Einstufungsmöglichkeiten. Blocker, sehr wichtig, wichtig, muss irgendwann mal gemacht werden usw. Was passiert in solchen Unternehmen mit der Priorität? Natürlich ist alles erst einmal sehr wichtig. Es könnte ja das nächste große Ding dabei sein, und wenn wir das nicht alles sofort umsetzen, haben wir ein Problem. Wenn aber alles eine sehr hohe Einstufung bekommt, dann haben wir im Endeffekt gar keine Bewertung vorgenommen. Was ist denn jetzt wichtiger? Feature A oder Feature B? Meist weiß es der Produktverantwortliche selbst nicht. Dieses Vorgehen ist nicht optimal, aber verstößt auch gegen keine Regel des Wasserfallmodells oder anderer veralteter Standards.

Bei Scrum ist es anders. Es wird vom Product Owner verlangt, alle Features in eine Reihenfolge zu setzen. Es ist eine einfache Liste mit Wünschen, und wie bei allen Listen gibt es keine Einträge, die auf derselben Position verharren. Das Team, welches das Projekt technisch betreut, weiß also immer genau, was als Nächstes ansteht und was zum jetzigen Zeitpunkt das Potenzial hat, bald umgesetzt zu werden.

Wo war aber das eigentliche Problem? Im ersten Beispiel war es der Produktverantwortliche, der sich nicht entscheiden konnte, was denn momentan das Wichtigste ist und wie die verschiedenen Features untereinander gewichtet werden sollen. Hilft uns Scrum dabei, dieses Problem zu lösen? Die Antwort ist ein klares Nein. Das Gute an Scrum ist aber, dass es uns als Rahmenwerk dazu zwingt, unser Projekt besser zu verstehen. Es zwingt uns, eine klare Reihenfolge zu definieren. Der Product Owner muss sich Gedanken darüber machen, in welcher Reihenfolge die Punkte abgearbeitet werden sollen. Er reflektiert sein Produkt immer und immer wieder, spricht mit anderen Stakeholdern und stimmt sich mit ihnen ab.

Oft ist einem gar nicht klar, was dies eigentlich bedeutet, und es wird als pure Schikane empfunden. Das ist aber nicht der Fall. Die Entwickler haben auf einmal nicht mehr den riesigen unsortierten Berg an Arbeit vor sich liegen und können strukturierter mit der Arbeit beginnen. Wünsche, die ganz hinten auf der Liste stehen, müssen erst einmal gar nicht in Betracht gezogen werden, und es wird nur das entwickelt, was gerade relevant ist. Auch wird den Verantwortlichen klar, was es vielleicht nicht in das nächste Release schaffen wird, und man kann sich frühzeitig darauf einstellen. Es handelt sich also keinesfalls um Schikane.

Nehmen wir ein zweites Beispiel: Bei Scrum gibt es täglich ein aktuelles Sprint Burndown Chart, das dazu verwendet wird, den Fortschritt im aktuellen Sprint zu visualisieren.

Die optische Aufbereitung hilft den Entwicklern zu erkennen, wann sie mit ihrer Arbeit hinterherhinken und wann sie nahe an der erhofften Geschwindigkeit liegen. Man könnte jetzt meinen, das Burndown Chart löst das Problem des faulen Entwicklers und ist dazu da, ihn immer wieder darauf hinzuweisen, dass er härter arbeiten soll. Viele Arbeitgeber sehen das genau so. Zum Glück ist es aber falsch.

Das Burndown Chart ist ein Werkzeug, um Probleme aufzuzeigen. Sobald etwas Unerwartetes im Diagramm zu sehen ist, heißt es, dass man nachforschen muss, um herauszubekommen, was der Grund dafür ist. In den allermeisten Fällen ist es nicht das faule Team, sondern es sind die Rahmenbedingungen, die nicht stimmen. Häufig sind es unaufgelöste Abhängigkeiten, ungenaue Schätzung durch zu viele unbekannte technische Voraussetzungen oder zu ungenaue Beschreibung der eigentlichen Features.

Scrum gibt auch in diesen Fällen nicht vor, wie die Probleme zu lösen sind, es hilft einem aber, zeitnah festzustellen, dass dort Probleme existieren. Wie sie zu lösen sind, muss das Team entscheiden.

Probleme in Unternehmen sind zwar häufig ähnlich, aber doch immer wieder ein wenig anders. Ein Projektmanagementframework, das alle möglichen Probleme löst, ist also fast unmöglich zu konzipieren, ohne dass das Regelwerk den Umfang einer Enzyklopädie annimmt. Scrum geht also den richtigen Weg, indem es einem die Werkzeuge an die Hand gibt, Probleme aufzudecken und sich bei der Lösung im Groben erst einmal heraushält.

Leider verstehen Projektverantwortliche nicht immer, welche Ideen hinter den einzelnen Bestandteilen des agilen Vorgehensmodells stehen, und streichen sie einfach, sobald sie unliebsam werden. Das Burndown Chart sieht immer problematisch aus? Dann machen wir einfach keins. Wir haben keine Zeit für die Retrospektive? Gestrichen. Viele Unternehmen behaupten von sich, dass sie nach Scrum arbeiten. Tatsächlich nehmen sie einige Bestandteile, die sie verstehen, und lassen den Rest weg, wundern sich aber dann, warum das System für sie nicht funktioniert. Für dieses Vorgehen wurde der Begriff ScrumBut [http://www.scrum.org/ScrumBut] geprägt. „We use Scrum, but Retrospectives are a waste of time, so we don't do them". Leider versteckt man auf diese Art nur ein Problem, das über Scrum aufgezeigt wird. Gelöst wird es sicher nicht.

2 Der Anwalt des Teufels

Dank regelmäßiger Reviews und der Einführung von Pair Programming steht man recht gut da, wenn es um die Qualität einer Anwendung geht. Es gibt aber noch weitere Vorgehensweisen, die dazu verwendet werden können, Entscheidungen zu verbessern. Der Anwalt des Teufels ist ein solches Vorgehen.

Auch wenn behauptet wird, dass Testen die einzig destruktive Disziplin in der Softwareentwicklung ist, gibt es noch weitere Wege, zerstörerisch vorzugehen, um damit die Qualität eines Produkts zu verbessern. Der Anwalt des Teufels kann immer dann eingesetzt werden, wenn es um die Bewertung von Ideen oder Entscheidungen geht. Leider ist es in nicht eingespielten Teams oft der Fall, dass Kritik etwas ist, was man nicht offen aussprechen sollte. Und wenn man es doch tut, sind die bösen Blicke des Kollegen sicher. Trotzdem ist es häufig notwendig, Ideen anderer zugunsten besserer Vorschläge anzugehen.

Um ein solches Aufeinandertreffen von einer scheinbar persönlichen Ebene auf eine fachliche zu heben, ist es wichtig, eine Formalisierung vorzunehmen. Es muss dediziert die Aufgabe vergeben werden, das vorgestellte System niederzumachen. Die Person, die diesen Auftrag bekommt, ist der Anwalt des Teufels.

Der Ausdruck „Anwalt des Teufels“ stammt aus der katholischen Kirche. Dieser Anwalt wird bei der Selig- und Heiligsprechung eingesetzt, um Gründe vorzubringen, die gegen die Kanonisation sprechen. Auch wenn der Anwalt selbst nicht der Meinung ist, dass die Heiligsprechung unrechtmäßig ausgerufen wird, so hat er doch die Aufgabe, alles ihm Mögliche zu tun, sie zu verhindern. Sollten die gefundenen Gründe nicht ausreichen, das Verfahren zu stoppen, so wird die Person in den Kreis der Heiligen aufgenommen.

Genau diesen Prozess gilt es zu adaptieren, wenn die Qualität eines Produkts oder einer Idee gesteigert werden soll. Nimmt man zum Beispiel ein Architektur-Review [Vier Augen und die Architektur], in dem ein Entwickler seine Ideen für eine neue Struktur vorstellt: Es kann schwer sein, diese in einer Diskussionsrunde so anzugreifen, dass sich der Entwickler nicht persönlich angegriffen fühlt. Man darf dabei nicht vergessen, dass die Gedanken und der Entwurf, den er sich gemacht hat, sein Baby ist, und wer mag es schon gern, wenn man auf seiner Familie rumhackt. Sicherlich wäre es fachlich sinnvoll, wenn erst einmal alle Review-Beteiligten das Optimierungspotenzial ausschöpfen, das kann aber leicht in Demotivation ausarten. Aus diesem Grund muss die Rolle des „Miesmachers“ explizit verteilt werden.

Wenn ein Team merkt, dass Kritik zu sehr auf der persönlichen Ebene angenommen wird oder es junge Programmierer verunsichert, so muss der Anwalt des Teufels eingesetzt werden. Vor einem Review wird diese Rolle verteilt, und eine Person versucht, das Vorgestellte schlecht zu machen. In den meisten Fällen hilft das bereits, um wieder auf der fachlichen Ebene zu diskutieren. Richtig gespielt, kann dieses Vorgehen auch neue Energie und Kreativität in Termine bringen.

Ein weiterer Vorteil bei diesem Vorgehen ist es, Kollegen, die gerne kritische Fragen stellen, besser zu unterstützen. Oft werden die Fragen und Anmerkungen von solchen Personen als negativ aufgefasst und stellen diese in ein Licht, in das sie nicht gehören. Nur weil jemand Dinge hinterfragt und auch mal Entscheidungen als falsch erachtet, heißt das nicht, dass er das Projekt sabotieren will. Leider wird das von der Außenwelt nicht immer so wahrgenommen. Wenn man hier wieder explizit die Aufgabe verteilt, Kritik zu äußern, kann diese Sichtweise nicht mehr auf eine Person projiziert werden.

3 Messen, was wichtig ist

von Bastian Hofmann

Mein größtes Learning der letzten Jahre ist es, erkannt zu haben, wie wichtig es für die Entwicklung einer Webanwendung ist, nicht nur technische Metriken im Blick zu haben, um sicherzustellen, dass die eigene Anwendung und die Server laufen, skalieren und die eigene Anwendung so schnell wie möglich ist. Auch Businessmetriken und Key-Performance-Indikatoren, die für das Produkt wichtig sind, müssen erhoben werden und die Produktentwicklung muss zum Teil daran ausgerichtet werden. Das heißt natürlich nicht, dass innovative Ideen nicht mehr wichtig sind, vielmehr kann man sein Produkt und seine Features auf Grund dieser Zahlen validieren und perfektionieren. So kann es zum Beispiel sehr hilfreich sein, zum Start der Entwicklung festzulegen, was man mit einem neuen Feature verändern möchte und welche Indikatoren sich verbessern sollen. Dadurch merkt man nach dem Abschluss der Entwicklung schnell, ob die eigenen Nutzer eine neue Funktion annehmen und wie sie sie benutzen. Nach dem Launch des Produkts oder eines neuen Features sollte daher die Entwicklung noch lange nicht abgeschlossen sein, die spannende Phase der Optimierung fängt damit gerade erst an. Ein sehr effektives Mittel hierfür ist es, verschiedene Varianten einer Funktion in Experimenten mit einem A/B- oder Bandit-Testing-Algorithmus gegeneinander zu testen. Das kann bei der Farbe und Beschriftung eines Buttons anfangen und mit vollkommen unterschiedlichen Klickpfaden wie zum Beispiel in der Registrierung enden. Ich finde es immer wieder bemerkenswert zu sehen, wie stark man hierdurch Indikatoren und Konversion eines Features verbessern kann.

Damit das Ganze auch wirklich Spaß macht, ist es lohnenswert, sich einmal grundlegend mit den Themen „Erfassen von Businessmetriken“ und „Testen mit Experimenten“ zu beschäftigen und dies in seiner Anwendung so einfach wie möglich zu machen. Für Metriken gibt es zum Beispiel zahlreiche Open-Source-Tools (Graphite: http://graphite.wikidot.com/), StatsD: https://github.com/etsy/statsd ...) oder Platform-as-a-Service-Anbieter (Librato: https://metrics.librato.com/), die das Erfassen der Metriken und die Darstellung und Auswertung dieser Zahlen zu einem Kinderspiel machen. Beim Testen mit Experimenten ist es etwas komplizierter, denn das ist stark abhängig von der Architektur der eigenen Anwendung und der verwendeten Programmiersprache oder des verwendeten Frameworks. Man sollte aber den Einsatz von Experimenten so einfach und unaufwändig wie möglich machen, zum Beispiel durch die Kapselung der Logik zur Entscheidung, welche Variante dem Nutzer angezeigt wird. Aber auch hierfür gibt es Platform-as-a-Service-Anbieter, die einem Teile der Implementierung abnehmen können (Myna: https://mynaweb.com/), Visual Website Optimizer: http://visualwebsiteoptimizer.com usw.).

Allerdings gilt es, bei der Erhebung und Nutzung von Metriken sowie bei Entwicklung mit Experimenten einige potenzielle Stolpersteine im Auge zu behalten:

Neben der schon oben genannten Gefahr, dass man innovative Produktentwicklung gerade in der Anfangsphase komplett von Metriken abhängig macht, hängen sie vor allem mit der Entscheidung zusammen, welche Metriken für das eigene Produkt eigentlich wichtig und wie diese Zahlen zu interpretieren sind. Selbst bei einem vermeintlich einfachen Beispiel wie einem Onlineshop kann das mehr sein als nur Gewinn oder Umsatz. So könnten auch Umsatz pro Kunde, Anzahl der Neukunden, Anzahl der wiederkehrenden Kunden etc. wichtige Indikatoren für den Erfolg des Shops sein.

Ebenso kann es bei Experimenten zu Situationen kommen, durch die Testergebnisse verfälscht und invalide werden. Das fängt damit an, dass man das Ziel eines Experiments sehr genau definieren muss: Ist es zum Beispiel nur der Klick auf den „In den Warenkorb legen“-Button oder der darauf hoffentlich folgende Kaufabschluss? Eventuell ist hier je nach Definition des Ziels die bessere Variante eine ganz andere. Aber auch Faktoren außerhalb des eigentlichen Experiments können das Ergebnis beeinflussen. So haben wir zum Beispiel bei ResearchGate herausgefunden, dass bei unterschiedlichen Einstiegspunkten in die Benutzerregistrierung unterschiedliche Anordnungen der Schritte, die zu einer Registrierung notwendig sind, unterschiedliche Konversionen erzielen. Um solche Effekte zu vermeiden, lohnt der Blick auf Experimentalgorithmen, die über das klassische A/B-Testen hinausgehen (weiterführende Blog-Posts und Diskussionen gibt es hier http://news.ycombinator.com/item?id=4040022 und hier http://news.ycombinator.com/item?id=4052997).

Zusammengefasst: Die konsequente Erhebung und Nutzung von Businessmetriken sowie das Testen mit Experimenten ist aufwändig (viele erfolgreiche Webfirmen haben zum Beispiel ganze Teams, die sich nur darum kümmern). Der Aufwand lohnt sich aber auf jeden Fall.

Über den Autor

Bastian Hofmann (bashofmann@gmail.com) arbeitet als Software Engineer bei ResearchGate, dem sozialen Netzwerk für Forscher und Wissenschaftler, und ist dort vor allem für die Softwarearchitektur des Web-Frontends und APIs verantwortlich. Davor hat er bei den VZ-Netzwerken maßgeblich die Spiele- und App-Plattform sowie die APIs der Plattformen entwickelt. Neben seiner Entwicklertätigkeit spricht er häufig auf internationalen Konferenzen über Softwarearchitektur, Skalieren von Webanwendungen und offene Standards und Protokolle.

4 Klassisches Vorgehen

Um ein Projekt erfolgreich abzuschließen, gilt es, strukturiert die anfallenden Aufgaben zu erledigen. Diese Struktur kann durch ein konkretes Vorgehensmodell in eine Richtung gelenkt werden. Früher waren klassische Modelle wie Wasserfall und V-Modell das Mittel der Wahl, denn sie hatten bereits in vielen Disziplinen bewiesen, dass sie Erfolg bringen können.

In den letzten Jahren kam immer häufiger der agile Ansatz zum Tragen, der in vielen Unternehmen dabei ist, den Wasserfall zu verdrängen. Um zu verstehen, warum der agile Weg in vielen Fällen die bessere Wahl ist, muss man verstehen, wie die herkömmlichen Methoden kranken.

Herangehensweisen wie das Wasserfall- und V-Modell wurden in den letzten Jahre häufig eingesetzt, und si e können auch funktionieren - aber leider nicht in der Softwareentwicklung bei Webanwendungen. Das Internetbusiness ist viel zu schnelllebig und unberechenbar, als dass starre Modelle zum Erfolg führen würden. Betrachtet man die Gesamtheit der begonnenen Anwendungen, erkennt man diverse Muster, die immer wieder bei gescheiterten Projekten auftreten.

Die Welt dreht sich weiter

Baut man ein Haus, so ist das Vorgehen klar. Man engagiert einen Architekten, der entwirft das Anwesen und es wird im Anschluss von der Baufirma erstellt. In einem solchen Fall würde Wasserfall das Projekt zum Ziel bringen. Es ist verständlich, dass man nach dem Abschluss des Kellers nicht mehr auf die Idee kommen sollte, dass man vielleicht doch einen Indoor-Pool haben möchte.

Bei Internetanwendungen ist das aber Gang und Gäbe. Sobald ein Feature fertig ist, stürzen sich die Projektmanager und Konzepter darauf und verbessern bzw. erweitern es. Und das ist auch gut so, denn die Welt hat sich in der Zwischenzeit weitergedreht. Neue Ideen sind entstanden, und die Konkurrenz ist mittlerweile auch ein Stück weitergekommen. Alles gute Gründe, auch weiter zu denken.

Im klassischen Wasserfall sind Änderungen während der Entwicklung nicht geplant. Kostspielige Änderungsanforderungen müssen eingekippt und wahrscheinlich muss der Auftrag geändert werden, da der Umfang, der am Anfang geplant wurde, nicht mehr aktuell ist.

80-Prozent-Syndrom

Projekte haben viele Teilaufgaben. So viele Teilaufgaben, dass es eine gute Idee erscheint, zu parallelisieren. Das ist auch bedingt richtig. Wenn man viele Teammitglieder hat, kann man es probieren. Die Bedeutung für das Projekt ist leider häufig sehr ähnlich. Von den 20 gleichzeitig angegangenen Aufgaben sind 15 offen, aber zu 80 Prozent fertig. Leider kann man erst wirklich etwas damit anfangen, wenn es 100 Prozent sind.

Misslungene Schätzungen

Sich das fachliche Feinkonzept zu Gemüte zu führen und danach eine präzise Schätzung abzugeben, hat noch nie geklappt. Trotzdem passiert es immer wieder, dass ein Projektmanager oder ein einzelner Entwickler diese Aufgabe zugeschustert bekommt. Dass dies im Normalfall bis zu 500 Prozent danebenliegen kann, ist empirisch belegt [DKDIP]. Bei besonders hartnäckigen Projektleitern kann es auch vorkommen, dass diese Schätzung bereits in einem frühen Projektstadium in Stein gemeißelt wird und die TV-Werbung für den Launch sozusagen schon auf den Tag genau gebucht wird. Eine Anpassung des Zeitplans ist somit nicht mehr möglich.

Priorisieren

Fragt man den Auftraggeber, welches Feature besonders wichtig für den Erfolg des Projektes sei, dann ist die Antwort oft die gleiche. Alle. Viele. Für das Priorisieren ist dies recht kontraproduktiv. Das Team muss entscheiden, was zuerst angegangen wird. Wenn dann aber an einem bestimmten Meilenstein das Falsche fertig ist, wird es den Entwicklern vorgeworfen.

Projektabschlusshektik

Das Gute an klassischen Projekten ist, dass auch sie irgendwann einmal ein Ende finden. Nur leider ist das Ende meist mit Überstunden, Druck und Stress verbunden. Alles, was man bis kurz vor dem Abschluss noch nicht implementiert hat, muss jetzt in kürzester Zeit nachgeholt werden. Meist wird in einer solchen Phase auch auf Qualität keinen großen Wert mehr gelegt. Erfahrungsgemäß sind Unit Tests das Erste, das gestrichen wird, wenn ein Projekt unter Stress zu Ende geführt wird.

In einer solchen heißen Phase wird das Produkt meist nicht mehr strukturiert unter Kontrolle gehalten, sondern in Wild-West-Manier drauflos programmiert. Auf Entwickler wird in dieser Zeit ebenfalls keine große Rücksicht genommen. Der große Vorteil bei uns Menschen ist, dass wir uns nach so einer Zeitspanne wieder erholen. Die einen schneller, die anderen langsamer. Das Projekt wird nicht von alleine genesen. Die oft geforderte Refactoring-Phase wird häufig auf unbestimmte Zeit verschoben, da im Betriebsmodus auch keine Zeit mehr vorhanden ist.

5 Spezialisierung ist böse

Spezialisierung als böse zu bezeichnen, ist sicherlich eine recht provokante These. Ohne Spezialisierung würden viele neue Werkzeuge nicht existieren und technische Innovationen wären nicht so häufig in der Presse wie heute. Spezialisierung ist wichtig. Trotzdem muss man bewerten, in welchem Kontext Spezialisierung sinnvoll ist. In den meisten Webprojekten geht es darum, einfache Anwendungen zu basteln, die in ihren Einzelteilen nicht sonderlich innovativ sind. Das Große und Ganze letztendlich kann dies dennoch sein.

Analysiert man ein solches Projekt, kommen nicht selten folgende Bestandteile zum Vorschein:

Backend-Code (z.B. PHP)

HTML und CSS

JavaScript

MySQL

Jetzt könnte man ein Team zusammenstellen, indem man aus jedem Bereich einen ausgewiesenen Experten nimmt, der sich genau auf diese eine Technologie spezialisiert hat. Solche Spezialisten sind zumeist recht teuer und verlassen ihre Domäne nur ungern.

Analysiert man in einem Projekt nun die einzelnen Technologiebestandteile, so fällt auf, dass im Normalfall die Spezialisierung nicht nötig ist. 80 Prozent der zu lösenden Anforderungen und häufig auch mehr können ohne jahrelange Beschäftigung mit der Sprache oder Technologie gelöst werden. Hierbei handelt es sich um Standardaufgaben. Natürlich kann es nicht schaden, auch diese Aufgaben von einem Spezialisten gelöst zu bekommen, kosteneffizient wird diese Lösung aber nicht sein.

Der Ansatz, dass jeder Mitarbeiter in einem Projekt genau einer Domäne zugeordnet ist, funktioniert auch nur so lange, wie die Domänen vom Aufwand her gleich verteilt sind. Sollte es Phasen geben, in denen die gewählte Technologie nicht zum Einsatz kommt, ist Däumchendrehen an der Tagesordnung, da beispielsweise die Unterstützung eines reinen JavaScript-Entwicklers meist nicht geschätzt wird, wenn es um die Erstellung von SQL Queries geht.

Geht man weg von dem Ansatz der Spezialisierung hin zu den Generalisten, so wird schnell der Vorteil sichtbar, dass 80 Prozent eines Projekts, nämlich die Standardaufgaben, von jedem Teammitglied erledigt werden können. Skalierbarkeit über alle Teammitglieder ist somit einfach möglich. Für die Planbarkeit eines Projekts ist sowas sicherlich auch interessant, da nicht mehr jede Domäne oder Technologie für sich betrachtet werden muss, sondern das gesamte Projekt in den Vordergrund tritt.

Ein Phänomen, das häufiger zu Projektende beobachtet werden kann, ist das Ungleichgewicht der Aufgaben in Bezug auf die Spezialgebiete. In einer solchen Phase werden kaum neue funktionale Anforderungen gestellt, und es wird nur noch an der Optik und der Usability gefeilt. Backend-Entwickler können in dieser Zeit eher unnötig sein. Projiziert man diese Situation auf ein Team von Generalisten, wird das Risiko eines Flaschenhalses durch das Frontend-Team minimiert, wenn nicht sogar komplett verhindert.

Was passiert aber mit den 20 Prozent, die eben doch keine Standardaufgaben sind? Hier kann man versuchen, gemeinsam eine Lösung zu finden. Oft sind viele Generalisten ebenso kreativ und effizient wie einzelne Spezialisten. Wenn kein Konsens gefunden wird und keine Lösung gemeinsam konzipiert werden kann, so besteht immer noch die Möglichkeit, genau für diese eine Anforderung externes Wissen einzukaufen. Der Markt ist voll von Spezialisten, die sich genau für solche kniffligen Probleme anheuern lassen.

Jetzt kann man natürlich einwenden, dass Spezialisten schneller ihre Aufgaben lösen können, als Generalisten dies bewerkstelligen. Seine Gültigkeit hat die Aussage mit Sicherheit in den 20 Prozent, die man in Speziallösungen investiert. Bei Standards wird das aber nicht lange der Fall sein. Genau in diesen Aufgaben stellt sich schnell Routine ein und somit steigt die Effizienz auf einen hohen Wert.

Ob man nun mit einem Team von Spezialisten oder mit einer Team von Generalisten besser fährt, kann natürlich nicht pauschal beantwortet werden. Vor Projektbeginn sollte auf jedem Fall analysiert werden, wie außergewöhnlich die Aufgaben sind und wie stark man spezialisiert sein muss, um 80 Prozent der gestellten Aufgaben lösen zu können.

6 Baue nichts, was du nicht messen kannst

Neue Features sind etwas Tolles. Das denken nicht nur die Produktverantwortlichen, sondern auch die Kunden und sicherlich auch die Entwickler, die es umsetzen dürfen. Vergeht einige Zeit im Lebenszyklus des Produkts, hat man eine Menge Features gebaut, die alle als Erfolg eingeplant wurden, aber nur vielleicht zehn Prozent dürfen diesen Status für sich in Anspruch nehmen. In einer idealen Welt würde das Produktteam die erfolglosen Erweiterungen nehmen und sie wegwerfen, denn alles, was uns nichts bringt, verwirrt nur den Kunden. Mir ist kein Kunde bekannt, der eine Webseite aufgrund ihrer vielen nutzlosen Besonderheiten liebt.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!