Extreme und Rapid: So verkürzen wir die Entwicklungszeit in Software-Projekten
Wer möchte das nicht? Während die Konkurrenz noch versucht, die erste App auf den Markt zu bringen, arbeitest du schon an der Version 2.0. Oder du wirst schon einen Monat vor der Projekt-Deadline mit der App fertig und kannst die verbleibende Zeit dafür nutzen, einen perfekten Launch vorzubereiten. Den Meilensteinen in Projekten hinterherzurennen ist häufig der pure Stress für den Projektleiter und kontraproduktiv für die Softwareentwickler. Zeit ist ein wichtiger Wettbewerbsfaktor in jeder Industrie, insbesondere in der schnelllebigen IT-Welt und entscheidet oft allein über den Erfolg eines Software-Projektes.
Gute Software-Produkte sind nur dann gut, wenn sie auch schnell geliefert werden. Diese Meinung teilen Steve Jobs und Jeff Bezos. Steve Jobs hat im Jahr 1986 folgendes gesagt: “We are going to be judged about what our product is and how timely we bring it to market. If we can’t prove we can do something great in 18 months, why should we believe we could do it one year later. The world is not standing still, the technology window passes us by, all the work we have done we throw it on the toilet. A lot of things can happen in one year.“[1]
Verzögerungen in Software-Projekten oder eine langsamere Ausführung haben nach Steve Jobs negative Folgen: Die Finanzierung des Projektes ist in Gefahr, die Glaubwürdigkeit des Teams wird in Frage gestellt oder die Attraktivität eines ganzen Unternehmens leidet darunter – was wiederum dazu führt, dass die Fluktuationsrate steigt oder es schwieriger wird, sehr gute Mitarbeiter einzustellen.
Eine ähnliche Meinung vertritt auch Jeff Bezos. In einer der ersten Stellenanzeigen im Jahr 1994 suchte er für Amazon nach einem neuen Programmierer mit folgenden Skills: "You must have experience designing and building large and complex (yet maintainable) systems, and you should be able to do so in about one-third the time that most competent people think possible." [2]
Für Jeff Bezos reicht nicht allein die Fähigkeit, große und komplexe Systeme bauen zu können. Die Systeme müssen auch noch in sehr kurzer Zeit fertiggestellt werden und leicht wartbar sein. Und das alles ohne Abstriche bei der Qualität.
Wenn eine Software nicht schnell geliefert wird, dann kann sich das gesamte Projektteam plötzlich neuen Herausforderungen gegenübersehen: Neue Gesetze treten in Kraft und müssen berücksichtigt werden. Auf neuen Druck vom Wettbewerb und geänderte Marktbedingungen muss reagiert werden. Die Software muss an neue Technologien und neue Standards angepasst und auf optimierte Geschäftsprozesse ausgerichtet werden. Auch die Kundenanforderungen können sich im Verlauf der Zeit komplett ändern, was dazu führen kann, dass bereits verrichtete Arbeit als nutzlos gestrichen wird.
Ein anderes Problem von lange andauernden Projekten ist die schlechte Prognostizierbarkeit beim Planen, die analog mit der Projektlänge wächst [3]. Sie wird ungenau und verfehlt meistens das Ziel, denn je weiter ein Projektmeilenstein in der Zukunft liegt, desto unwahrscheinlicher wird es, das Ziel in der geplanten Zeit zu erreichen. Dadurch entstehen neue Wartezeiten und folglich eine Gesamtprojektverzögerung, falls etwa die abgestimmten Module nicht rechtzeitig sukzessiv bereitgestellt werden können. Und je länger die Projektmeilensteine gestreckt sind, desto länger bleiben die Probleme versteckt oder unentdeckt.
Wenn wir aber stattdessen versuchen, die Entwicklungszeit in Software-Projekten zu verkürzen, dann vermeiden wir nicht nur die oben genannten Probleme, sondern haben auch mehr Zeit, um eine bessere Qualität zu liefern. Besser gesagt: Schnelles Liefern führt automatisch zu höherer Qualität, weil wir zum Beispiel auf Nacharbeit und aufwändige Korrekturen verzichten, wie wir später sehen werden. Das steht im starken Kontrast zu der traditionellen Denkweise, dass Qualität gleichbedeutend mit mehr Zeitaufwand ist. In diesem Artikel wird dargelegt, dass die Verkürzung der Durchlaufzeit in Software-Projekten automatisch zu besserer Software führt.
Aber wie lässt sich die Entwicklungszeit in Projekten ganz konkret verkürzen? Die Antworten auf diese Frage verstecken sich in den folgenden sechs Clustern, beginnend mit den Kriterien "Einfachheit" und "Code-Effizienz".
Einfachheit und Code-Effizienz
Programmieren ist eine mentale Herausforderung. Tausende Zeilen Code zu lesen und zu verstehen kann sehr anspruchsvoll sein. Das beste Beispiel sind sogenannte "Logic Bombs", also Prozeduren aus sehr vielen Zeilen oder sehr komplex geschriebenem, unleserlichem Code. Einfache Strukturen und Designs und gute Code-Lesbarkeit hingegen erleichtern das Verständnis und ermöglichen eine schnellere Anpassung und Erweiterung des Systems. Die Systemarchitektur und die Objekt- und Datenmodelle sollten deshalb so einfach wie möglich gehalten werden. Zum Erreichen dieser Einfachheit trägt die klare Trennung der Zuständigkeiten zwischen den einzelnen Komponenten bei.
Der Code sollte vor diesem Hintergrund stets gut kommentiert sein. Insbesondere muss im Code ersichtlich und begründet sein, warum etwas auf eine bestimmte Weise gemacht wird und nicht anders. So werden vermeintliche Optimierungen vermieden, die später schmerzhaft wieder zurückgefahren werden müssen.
Auf eine aufwändige Dokumentation vor dem Start oder während der Entwicklungszeit kann verzichtet werden. Eine Dokumentation aber, die nach Abschluss des Projektes in der Retrospektive geschrieben wurde, ist sehr wertvoll und unverzichtbar, denn dann kann sie nur valide Informationen enthalten und nicht als überholt gelten. Das Dokument sollte die Architektur des Systems und seine wichtigsten Komponenten und Schnittstellen inklusive des Datenmodells beschreiben. Zudem wird darin das Funktionsprinzip erläutert und es werden alle wichtigen Design-Entscheidungen und die getroffenen Annahmen dokumentiert, sodass es leichter und einfacher wird, das System zu einem späteren Zeitpunkt zu warten und zu erweitern. Hier darf auch ein Kapitel "Was der Entwickler noch wissen muss" nicht fehlen, in dem viele kleinere Details, Informationen, Regeln und Hinweise aufgelistet werden, wie etwa: Warum gibt es zwei Kalender? Was muss an welcher Stelle umgestellt werden, wenn der Mehrwertsteuer-Satz geändert wird? Und was ist bei einer Archivierung zu beachten? Diese Informationen, die auf den ersten Blick sehr kleinteilig erscheinen, sind für den zukünftigen Entwickler aber umso wichtiger, um das System leichter und sicherer weiterzuentwickeln. Das Fehlen und folglich auch das Missachten solcher Informationen kann später bei einer möglichen Systemanpassung einen hohen und unnötigen Zeitaufwand verursachen.
Der produzierte Code sollte darüber hinaus von hoher Qualität sein und möglichst wenige – noch besser keine – Defekte enthalten. Eingebaute Bugs und spät entdeckte Fehler erfordern Codekorrekturen und rauben viel Zeit. Um die Korrektheit sicherzustellen und Nacharbeit zu vermeiden, können reichlich Validierungsprüfungen und Constraints verwendet werden, sowohl in der Interaktion mit dem Benutzer als auch zwischen den ausgeführten und aufrufenden Funktionen, Prozeduren und Methoden im Code. Die Implementierung eines Features mit so wenigen Zeilen Code wie möglich sollte da, wo es machbar ist, angestrebt werden. Code Contracts und Assertions helfen dabei, schlanken Code zu produzieren. Auf eine aufwändige und ausgeklügelte Fehlerbehandlung, eine unnötige Performance-Optimierung und schöne Oberflächen (Gold Plating) kann verzichtet werden, wenn diese nicht explizit angefordert wurden (YAGNI).
Stattdessen gilt: Finde neue Wege und setze innovative und außergewöhnliche Ideen ein, um Aktivitäten schneller auszuführen, Zeit zu gewinnen und frühes Kunden- und Nutzerfeedback einzuholen. Können Teile des Codes automatisch generiert werden? Können vorhandene Bibliotheken wiederverwendet werden? Lassen sich unterschiedliche Blöcke von Funktionalitäten so programmieren, dass sie intern nach dem gleichen Schema arbeiten (baugleiche Prozeduren müssen nur einmal entwickelt werden)?
Die meiste Zeit (und damit bis zu 70 Prozent der Gesamtkosten) wird bei der Wartung und Weiterentwicklung von Software verbraucht. Wenn man bedenkt, dass Programme seit mehreren Jahrzenten in Betrieb sind, dann stellt man fest, dass der Aufwand für die Wartung des Systems überproportional größer ist als für die anfängliche Implementierung. Deshalb suchen wir nach Möglichkeiten, diese Aufgaben schneller zu machen oder zu eliminieren.
Unter Wartung und Weiterentwicklung fallen diverse Code-Änderungen aufgrund von Korrekturen, neuen Wünschen oder notwendigen Anpassungen in einer neuen Umgebung wie Migration und Integration. Die Wartbarkeit ist gleichzeitig auch eine wichtige Eigenschaft bei der Definition der Software-Qualität [4]. Je einfacher die Code-Basis des Systems ist, desto geringer fällt der Wartungsaufwand auf. Die Software muss deshalb so programmiert sein, dass die einzelnen Komponenten einfach zu ändern sind und die Änderungen schnell durchgeführt werden können (Modifizierbarkeit), zum Beispiel wenn nur eine einzige Stelle im Code zu bearbeiten ist. Die Änderung sollte auch einfach zu testen sein (Testbarkeit). Das ist etwa der Fall, wenn Code-Teile einzeln und getrennt voneinander ausführbar sind. Und nicht zuletzt: Wie schnell kann die Stelle gefunden werden, die zu ändern ist? Das ist die Analysierbarkeit, also ein Indiz dafür, ob eine schnelle Diagnose von Fehlerursachen möglich ist.
Debugging ist zeitaufwändig und teuer. Entwickler sollten daher versuchen, Fehler (vom Benutzer verursacht oder vom Entwickler selbst) im voraus proaktiv abzufangen, indem sie antizipieren, was alles in der Zukunft schief gehen könnte. Welche Fehler könnten auftreten? Was kann falsch interpretiert werden? Wie könnte das System missbraucht werden? Können falsche Funktionsaufrufe erkannt und abgewiesen werden? Kann sich das System von einem Neustart oder Katastrophenfall erholen? Werden invalide Zwischenstände gespeichert? Können böse oder faule User bestimmte Funktionen umgehen? Was passiert bei einem Wechsel der Sprache des Betriebssystems oder bei einem Regionswechsel? Und was passiert, wenn ein anderes Encoding als das Erwartete verwendet wird?
Viel Zeit kann also gespart werden, wenn man sich auf das Erstellen von Code mit hoher Qualität und einfachen Designs konzentriert. Und im Management der Kundenanforderungen liegt sogar noch mehr Potenzial zur Zeitersparnis.
Requirements jederzeit im Griff
Jede Softwareanforderung kostet Zeit in der Umsetzung – die falschen umso mehr, weil sie später jemand entfernen muss. Aber auch die fehlenden und anfänglich nicht genannten Anforderungen kosten viel Zeit, da sie jemand zu einem ungünstigen späteren Zeitpunkt doch erfüllen muss.
Verlasse dich nicht auf Vermutungen, Annahmen, unsichere Fakten und Halbwahrheiten, die du vom Kunden hörst.
Lange bevor die allererste Zeile Code geschrieben wird, sollte eine gründliche Analyse der Kundenanforderungen stattfinden. Die Mühe, Anforderungen einzusammeln und so einfach und verständlich wie möglich zu erfassen und zu dokumentieren, lohnt sich. Entwickler sollten sich stets mit dem Kunden vergewissern, dass die Anforderungen valide, aktuell und erwünscht sind. Nur die echten Kundenwünsche sollten umgesetzt werden. Viele Anforderungen sind zweideutig oder missverständlich. Lasse Features weg, die nicht gebraucht werden – dadurch werden Fehlentwicklungen und Korrekturen vermieden. Aufwändige Aufgaben solltest du noch intensiver prüfen und dich fragen, ob sie tatsächlich benötigt werden und ob es vielleicht doch einfachere Alternativen gibt. Sind die Features auch in der Zukunft ohne Anpassung nutzbar und ist die Programmierung dieser Eigenschaften daher eine sinnvolle Investition? Verlasse dich nicht auf Vermutungen, Annahmen, unsichere Fakten und Halbwahrheiten, die du vom Kunden hörst. Sei sehr kritisch bei der Aufnahme der Kundenanforderungen. Die Anforderungen sind leider häufig entweder falsch, nicht vollständig oder sie müssen später geändert werden – eine vermeidbare Zeitverschwendung.
Das Ziel der Entwicklung sollte gute Software sein:
- Sprich mit den Nutzern offen über die einzelnen Features. Lasse Features weg, die sehr zeitaufwändig sind (80/20-Regel). Das erste iPhone konnte auch kein Copy-&-Paste und keine MMS verschicken.
- Du kannst schlechte Ideen oder Vorschläge ablehnen [5], wenn sie dem Nutzer keinen Mehrwert bieten, oder wenn sie deine Prinzipien für gutes Software-Design verletzen, also zum Beispiel sehr komplex oder nicht leicht änderbar sind.
- Lerne, "Nein" zu sagen, wenn du sicher bist, dass eine Idee nicht gut ist.
- Analysiere zuerst jene Anforderungen, bei denen du die größten Implementierungsrisiken siehst.
- Schließe die Unsicherheit aus dem System aus. Du solltest dir über alle Features, deren Umfang, Schwierigkeit und Auswirkungen im Klaren sein.
- Vermeide das unkontrollierte und schleichende Hinzufügen von neuen Funktionalitäten während der Entwicklung (Scope Creep). Du kannst gezielt Features auf ein künftiges Release verschieben. Die Rolle des Entwicklers ist nicht, blind Features umzusetzen.
- Versuche vorausschauend zu denken, fehlende Anforderungen zu entdecken und Fehler oder Lücken in den Anforderungen zu finden. Wenn du dich in die Rolle des Anwenders hineinversetzt, dann kannst du auch deine eigenen Anforderungen oder Ergänzungen an das System stellen, um später Nacharbeit (Rework) und Bug-Korrekturen zu vermeiden. Dafür musst du die Fachlichkeit und das Business gut kennen und dich häufig und intensiv mit dem Kunden austauschen.
Zusammenarbeit mit Kunden
Eine enge Zusammenarbeit mit dem Kunden oder dem Anwender bringt zweierlei Vorteile: Entscheidungen werden schneller getroffen und es werden die richtigen Entscheidungen in der richtigen Zeit getroffen. Eine offene und direkte Kommunikation und eine vertrauensvolle Beziehung zwischen Entwicklungsteam und Kunde lässt eine schnellere Eskalation und Lösung von technischen oder fachlichen Problemstellungen zu. Bei vielen Design-Entscheidungen, die täglich zu treffen sind, muss der Kunde zu Rate gezogen werden. Deshalb ist es notwendig, jederzeit ein kurzes Feedback einholen zu können, denn sonst gibt es Produktivitäts-Kills. Oder noch schlimmer: Es werden gar keine oder die falschen Entscheidungen getroffen. Wenn die Beziehungen zum Kunden sehr gut sind, dann kann das Team Fragen schneller klären, wichtiges Feedback jederzeit einholen und sich täglich über das System und den Nutzen austauschen. Wichtige Design-Entscheidungen werden gemeinsam getroffen und die Beteiligten liefern sich gegenseitig Anregungen, weisen auf potenzielle Fehler hin und klären Missverständnisse. Zusammen können Entwickler und Kunden die Aufgaben umpriorisieren, Konflikte lösen und Features vereinfachen, optimieren oder streichen.
Es gibt Details, die einen Entwickler stark bremsen können, wenn sie nicht sofort geklärt werden.
Idealerweise sitzen Entwickler und Kunden zusammen im selben Raum. Wichtig ist, dass nicht für jede kurze Absprache ein Termin vereinbart werden muss. Es gibt Details beim Programmieren, oft kleinerer Natur, die einen Entwickler stark bremsen können, wenn sie nicht sofort geklärt werden. Ein gutes Vorgehen ist deshalb, wenn kleinere Teams gebildet werden, die autonom agieren können und beispielsweise ein Feature komplett selbständig fertigstellen und alle Entscheidungen selbst treffen. Je mehr Parteien in der Entscheidungsfindung involviert sind, desto langsamer wird die Entwicklung voranschreiten.
In enger Zusammenarbeit mit dem Kunden kann die Idee des Prototyping praktiziert werden. Die Softwareentwickler zeigen sehr früh eine einfache, aber funktionierende Version des Systems, um ein Gefühl für die Software zu bekommen und Annahmen zu validieren. Das System muss nicht zu Ende spezifiziert werden, bevor der Anwender etwas sehen kann. Es soll ein stetiger Fluss von Kundenfeedback und Informationen etabliert werden (Build, Feedback, Adjust), um das Projekt frühzeitig in die richtige Richtung lenken zu können.
Das Projekt bekommt Flügel und kann schneller ausgeführt werden, wenn es einen Sponsor hat: Eine wichtige Schlüsselperson mit Entscheidungshoheit in der Organisation, die die Projektziele aktiv unterstützt und wirkungsvoll hilft, langwierige Abstimmungsprozesse zu vermeiden und Probleme schnell abzuräumen. Der berühmte Port in der Firewall kann dann sofort geöffnet werden, anstatt in mehreren Tagen oder Wochen und ohne Sponsor den normalen Weg über einen formalen Antrag gehen zu müssen.
Tools und Technologien
Mit den richtigen Tools lassen sich Ergebnisse im Projekt schneller erzielen. Für jede Aufgabe sollte die am besten geeignete Technologie verwendet werden. Es lassen sich zum Beispiel nicht alle Probleme mit SQL lösen. Die richtige Mischung macht es. Aber: Nicht übertreiben, denn der Einsatz von vielen verschiedenen Technologien in einem System birgt Integrationsrisiken. Jedes Framework hat seine eigenen Grenzen. Manchmal ergibt es Sinn, ein kommerzielles Entwicklungstool zu benutzen, um eine höhere Produktivität zu erreichen. Wenn du etwa eine 10 GB große Textdatei editieren musst und feststellst, dass das mit den kostenfreien Open-Source-Tools nicht geht, dann ist es vermutlich besser, ein Tool für 50 Euro zu kaufen, bevor du stundenlang versuchst, das Problem günstiger zu lösen.
Neue Technologien, zum Beispiel Frameworks oder Programmiersprachen, bergen viele Risiken, wenn man sie nicht ausreichend kennt. Selbst die Realisierung von kleinen Features kann zu einem übermäßig großen Aufwand führen. Das Wissen über die verwendete Technologie sollte aktuell sein. Das inkludiert auch Shortcuts, Tipps und Tricks, Best Practices, Patterns und Antipatterns. Ein Entwickler, der seine Sprache, Tools und Frameworks beherrscht, ist um ein Vielfaches produktiver als einer, der die Technologie nicht sehr gut kennt. Steve Jobs hat in einem Interview gesagt, dass das beste Auto vielleicht zweimal schneller als ein Durchschnittsauto ist. Ein guter Programmierer dagegen könne 50- bis 100-mal effektiver sein als der Durchschnitt.
An dieser Stelle möchte der Autor auf zwei populäre Entwicklungsmethoden oder Paradigmen eingehen, die das Potenzial haben, die Entwicklungszeit in Softwareprojekten zu verlängern: Test Driven Development (TDD) und die objektorientierte Programmierung (OOP).
- Die vielen Tests, die man in TDD schreiben muss, bedeuten einen doppelten Aufwand, müssen gewartet werden und motivieren sogar gegen Refactoring und vieles mehr. Diese und weitere Argumente gegen den Einsatz der Methode liefert David Heinemeier Hansson, der Autor von "Ruby on Rails", mit seiner Veröffentlichung "TDD is dead" [6]. Die Zeit, die man investiere, Tests zu schreiben, Tests zu testen und Tests zu korrigieren, könne man sinnvoller damit verbringen, die Anforderungen im Detail zu analysieren oder in einem kreativeren Problemlösungsprozess Code höherer Qualität zu produzieren.
- Seit Jahren kursieren in der Fachöffentlichkeit auch gut begründete Meinungen gegen OOP, zum Beispiel unter dem provokanten Titel "Object-Oriented Programming – The Trillion Dollar Disaster" [7]. In der OOP ist geschriebener Code sehr komplex und fehleranfällig. Die Softwareentwicklung mit einer objektorientierten Methode dauert länger. Auch das Testen ist mit OOP aufwändiger als bei der strukturierten oder funktionalen Programmierung. In OOP entstehen viele komplexe Abhängigkeiten zwischen den Objekten im Code. Das Verhalten der Objekte während der Laufzeit ist nicht immer gut vorhersagbar, weil sie gegenseitig den internen Zustand verändern. Tage können vergehen, um solche Veränderungen beim Debugging nachzuvollziehen. Das ist reine Zeitverschwendung.
Joe Armstrong, der Autor von Erlang, ergänzt dazu folgendes: "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
In der funktionalen Programmierung wird die Zeit genutzt, um echte Probleme zu lösen, anstatt passende Abstraktionen, Objekthierarchien und Design Patterns zu suchen. Du kannst OOP-Sprachen benutzen, aber den Code nach dem funktionalen Paradigma schreiben. Alle Aufgaben werden dann durch Funktionen realisiert und die Funktionen leben getrennt von den Daten.
Projektmanagement
Bei der Planung, Durchführung, Steuerung und Überwachung von Softwareprojekten gilt es, insbesondere folgende Aspekte zu beachten: Der Projektfortschritt muss täglich messbar sein und Probleme müssen sofort sichtbar werden. Täglich durchgeführte Meetings und Code Reviews zeigen, ob eine Repriorisierung der Arbeitspakete oder das Erstellen einer verbesserten Planung sinnvoll ist.
Das Projekt sollte die Abhängigkeiten von Dritten, zum Beispiel Schnittstellen zu anderen Systemen oder zu Lieferanten, gering halten oder diese Aufgaben möglichst früh erledigen, denn solche Abhängigkeiten stellen ein unkontrollierbares Risiko dar. Die Aufgaben innerhalb des eigenen Entwicklerteams werden so aufgeteilt, dass möglichst viel unabhängig voneinander bearbeitet werden kann und die Projektmeilensteine im zeitlichen Rahmen erreicht werden.
Zeitdruck führt in der Softwareentwicklung zu schlechter Qualität. Und schlechte Qualität führt zur Zeitverzögerungen. Als qualitätssichernde Maßnahme eignet sich häufiges Testen (Test early, Build often). Der Entwickler muss ein guter Tester sein und testet den eigenen Code immer selbst als Erster. Er kann sich in den Anwender hineindenken und weiß, ob die Anforderungen erfüllt sind. Wenn er einen Teil oder sogar die komplette Geschäftslogik kennt, wird das Testergebnis umso besser. Die ideal anzustrebende Situation: Das Programm wird für den Anwender zum Testen freigegeben. Der Anwender findet keine Bugs und keine Fehler (weil diese schon vorher vom Entwickler gefunden und beseitigt wurden). Er findet höchstens Aspekte, die im Anforderungsdokument gefehlt haben. Das Ziel ist, unnötige Zyklen zu vermeiden, etwa wenn der Tester oder der Anwender einen Fehler findet, den Code an den Entwickler zurückgeben muss, dieser den Fehler beseitigt und der Test wiederholt werden muss. Solche Zyklen verlangsamen den Entwicklungsprozess. Zudem können zwischen Programmierung und Test mehrere Tage oder sogar Wochen liegen – Zeit, die verloren geht. Häufiges Testen bringt im Projekt die Selbstsicherheit, dass alles zeitlich so läuft wie geplant und dass die Teilergebnisse den Qualitätserwartungen entsprechen.
Auch die Filmindustrie in Hollywood arbeitet ähnlich [8]: Der Filmschnitt, also das Zusammenschneiden der einzelnen gedrehten Szenen zu einem ganzen Film, erfolgt nicht erst ganz zum Schluss, nach Ende der Dreharbeiten, sondern synchron zwischen den Szenen. Wenn eine Szene noch einmal gedreht werden muss, dann kann dies schnell entschieden werden, solange die Filmcrew noch vor Ort ist und das Filmsetting nicht abgebaut wurde.
Für ein effizientes Zeitmanagement kann die Methode des Timeboxing (wie in Hollywood) verwendet werden, um Zeitüberschreitungen oder Zeitverzögerungen zu vermeiden. Dabei geht es darum, zur Erledigung einer Aufgabe eine begrenzte Zeit vorzugeben. In dieser Zeit bemüht sich das Entwicklerteam, den versprochenen Umfang in der abgesprochenen Qualität so gut wie möglich umzusetzen. Teams, die diese Methode anwenden, arbeiten fokussierter und versuchen nicht, viel zu viel Arbeit innerhalb von viel zu wenig Zeit zu erledigen. In Hollywood müssen fast alle Filme innerhalb von 45 Tagen gedreht werden und dürfen eine Dauer zwischen 80 und 140 Minuten haben.
Trotz aller Bemühungen sollte das Projektmanagement auf unvorhergesehene Änderungen vorbereitet sein oder, noch besser, diese sogar erwarten (Design for Change). Denn auch einige Systemeigenschaften werden sich – obwohl es meist nicht im Anforderungsdokument definiert ist – im Laufe des Projektes verändern. Beispiele dafür sind neue Geschäftsregeln, neue Hardware, schwache 1:n-Beziehungen im Datenmodell, die schleichend zu m:n-Beziehungen mutieren oder auch neue Features für die nächste Version oder Features, die von Konkurrenzprodukten abgeschaut wurden.
Das richtige Mindset entscheidet
Die persönliche Einstellung entscheidet oft darüber, ob das Projekt das Ziel der Verkürzung der Durchlaufzeit erreichen wird oder nicht. Viele der aufgezeigten Maßnahmen erfordern Verhandlungsgeschick, Überzeugungskompetenz und Kampfgeist. Als Entwickler muss man bereit sein, für seine Ideen einzustehen und versuchen, die guten Ideen durchzusetzen und die Kunden und Kollegen zu überzeugen. Dazu gehört auch der Mut, Anforderungen und Designs zu hinterfragen und auf den ersten Blick außergewöhnliche Vorschläge einzubringen.
Ein Entwickler muss sich in sein System verlieben können.
Wer etwas Großes erreichen will, der muss auch in der Lage sein, große Probleme zu lösen. Und er muss offen und bereit sein, etwas Neues zu lernen und sich ständig weiterzuentwickeln. Viele Probleme können mit einer kreativen Herangehensweise schneller gelöst werden. Begeisterung und Engagement setzen in Projekten viel positive Energie frei und das steigert auch das Kundenvertrauen.
Ein Entwickler muss sich in sein System verlieben können, dann wird er sich auch um die kleinsten Details kümmern. Programmieren heißt, jede Minute eine Design-Entscheidung zu treffen – die natürlich stets gut überlegt sein sollte. Aktives Zuhören und fokussierte Arbeit verbessern die Kommunikation und die Ergebnisse.
Es ist hilfreich und sehr motivierend, die eigentlichen Projektziele und die Kundenerwartungen von Anfang an zu verstehen und sich damit auseinanderzusetzen. Warum wird diese Software geschrieben? Was erwartet der Kunde wirklich? Wie kann ich dem Kunden helfen, seine Ziele zu erreichen? Ist es das Ziel des Projektes, ein CRM-System einzuführen oder nicht vielmehr, den Kundenschwund auf null zu senken?
Fazit
Der vorliegende Artikel wollte zeigen, dass Software-Projekte trotz Komplexität und hoher Volatilität in den Anforderungen erfolgreich und schnell abgeschlossen werden können. Ist der produzierte Code einfach zu ändern, sind die Anforderungen jederzeit im Griff, ist der Kunde eng im Projekt eingebunden und werden die Tools und Methoden sorgfältig ausgewählt, dann kann mit Mut und Entschlossenheit in kurzer Zeit Großes erreicht werden.
- Youtube: Steve Jobs brainstorms with the NeXT team 1985
- Jeff Bezos sought candidates to work faster than ‘most competent people think possible
- R. Suri, 1998: Quick Response Manufacturing: A Companywide Approach to Reducing Lead Times. Taylor & Francis Inc.
- Wikipedia: ISO/IEC 9126
- A. M. Kanat, 2017: Understanding Software
- D. Heinemeier Hansson: TDD is dead
- I. Suzdalnitski, 2019: Object-Oriented Programming — The Trillion Dollar Disaster
- J. Persse, 2008: Hollywood Secrets of Project Management Success. Microsoft Press.
Helfried Richter
am 22.09.2023Die darin erwähnte Kundenzentrierung halte ich, neben lesbarem Code, für das wichtigste Element in Projekten.
Als Freelancer habe ich so gearbeitet und nur gute Erfahrungen damit gemacht,
auch wegen Details mit dem Kunde zu kommunizieren.
Ergebnisse waren funktionierende Programme, die immer ohne ausführliche Endnutzer-Dokumentation ausgeliefert werden konnten und den Kunden das lieferten, was in der engen Zusammenarbeit festgelegt wurde.