Wie geht moderne Softwareentwicklung?

Felix: Moderne Softwareentwicklung ist die Anwendung der Erfahrungen aus den letzten zwanzig Jahren. Ganz klassisch gab es früher das Pflichten- und Lastenheft. Der Kunde hat seine Anforderungen in einem Riesenbuch zusammengeschrieben. Dann wurde zwei Jahre entwickelt. Anschließend kriegte der Kunde eine Lösung – und die war gar nicht das, was er haben wollte.

Das Learning daraus ist der agile Ansatz: Wir fangen mit etwas an und schauen in regelmäßigen Abständen mit dem Kunden drauf. So kann er recht früh Einfluss auf die Entwicklung nehmen. Das ist meistens deutlich günstiger, als wenn es nach zwei Jahren eine grundlegende Anpassung geben soll.

Björn: Man könnte das auf einen Satz herunterbrechen: Frühzeitigstes Feedback einholen. Sowohl was die Methodik angeht, dass wir Scrum-Termine – Reviews, Plannings, Refinements – machen, bei denen der Kunde dabei sein kann. Aber auch was wir technologisch machen. Continuous Deployment zielt darauf ab, dem Kunden möglichst frühzeitig zu zeigen, was man gemacht hat. Damit ermöglichen wir dem Kunden neu entwickelte Features sehr zeitnah zur Entwicklung zu testen, zu reviewen und ggf. gegenzusteuern, wenn er – aus welchen Gründen auch immer - merkt, dass etwas noch nicht so ist, wie er es braucht.

Felix: Was ich an diesen kurzen Zyklen auch super wertvoll finde, ist, dass die Entwickler und Entwicklerinnen ein viel besseres Verständnis dafür kriegen, warum der Kunde bestimmte Entscheidungen trifft.

Felix: Früher hast du vom Kunden sehr grobe Anforderungen bekommen, für die dann ein Entwicklungsteam Lösungen geschustert hat. Heute definiert er die Anforderungen, dann guckt das Entwicklungsteam drüber, stellt seine Rückfragen und finalisiert sie direkt mit dem Kunden.

Björn: Da haben am Ende in den meisten Fällen alle Teammitglieder das gleiche Verständnis, was als Ergebnis herauskommen soll. Aber nicht nur die Entwicklerinnen und Entwickler erhalten ein besseres Bild von den tatsächlichen Anforderungen, sondern auch für unsere Kunden bietet das heutige agile Vorgehen den großen Vorteil, dass sie selbst mit jeder Iteration besser herausfinden können, was sie eigentlich wirklich brauchen.

Björn: Das ist je nach Projekt unterschiedlich: In den größeren Projekten stellt der Kunde meistens eine Person, mit der wir die Anforderungen herausarbeiten und der das Produkt letztlich gegenüber seinen Stakeholdern verantwortet – da kommt der Name Product Owner ja auch her. Es kann aber auch durchaus mehr als eine Person dabei sein. So war es bei einem Kunden die Regel, dass vier bis fünf Leute bei den Scrum-Terminen waren: IT-Leiter, QS, Projektleiter und weitere Leitungsfunktionen.

Felix: Ich habe gerade einen kleineren Start-up-Kunden, der ist bei jedem Meeting bis hin zum Daily dabei. Das sorgt bei ihm für ein größeres Verständnis, wenn wir mal mit irgendetwas struggeln. Er ist bei der Entstehung des Problems dabei und kann auch den Fortschritt bis hin zur Lösung des Problems verfolgen.

Björn: Wir haben 2008 bei einem größeren Kunden den agilen Ansatz eingeführt. Unser Kollege Frank Düsterbeck hat mit Daily-Stand-ups angefangen. Das hat erstmal für Verwunderung gesorgt, warum jetzt so viele Menschen, sechs bis sieben Leute, auf einmal jeden Morgen in der Besprechungsecke stehen und miteinander quatschen. Das war schon ungewöhnlich. Da musste man für werben. Es gab aber auch damals schon Leute auf der Kundenseite, für die das zumindest theoretisch nicht neu war und die das gerne ausprobieren wollten.

Felix: Ich glaube, viele Unternehmen haben verstanden, dass gerade in der IT agiles Vorgehen absolut sinnvoll ist. Und es wird ja jetzt auch in anderen Bereichen adaptiert. Nach wie vor ist es aber ein schwieriger Prozess, wenn Kunden das nicht gewohnt sind. Sie müssen sich umstellen und sich wirklich aktiv einbringen, damit wir die Lösung bauen können, die sie wirklich haben wollen. Das ist ein Prozess, bei dem der Kunde im Vorfeld abgeholt werden muss.

Felix: Was wir häufig machen ist, dass wir ihnen Leute an die Hand geben, die sie in diesem Prozess unterstützen. Einen Proxy-PO zum Beispiel.

Björn: Und auch einen oder eine Agile Masterin, die es zu ihrer Aufgabe macht, dem Kunden die agilen Prozesse näher zu bringen und dabei hilft, Schwierigkeiten zu beseitigen.

Felix: Beim agilen Vorgehen sollte man auch als Entwickler selbst in der Lage sein, mit dem Kunden zu kommunizieren und die technische Entscheidung vor ihm vertreten zu können. Früher hat das häufig der jeweilige Projektleiter übernommen. Aber dem fehlt im Zweifel das technische Know-how.

Felix: Am Ende des Tages auf ein Produkt, das die Bedürfnisse des Kunden erfüllt. Die Entwicklung soll schnell sein. Time-to-Market ist heute wichtig, gerade wenn du nicht der einzige Player im Markt bist und das Produkt deshalb möglichst schnell veröffentlicht kriegen willst.

Björn: Kundenzufriedenheit, das sowieso. Aber auch die Abwägung der Qualitätsziele, die so ein System haben sollte. Das kann von Projekt zu Projekt komplett unterschiedlich sein. Vielleicht ist Time-to-Market bei einem anderen Projekt gar nicht so wichtig. Dafür musst du dann eventuell einen größeren Fokus auf Datensicherheit haben, oder das System muss möglichst ausfallsicher sein.

Das sind vielleicht Dinge, die – wie Felix sagt – bei einem Start-up erstmal nicht so wichtig sind. Hier muss man manchmal den technologisch nicht so super perfekten Ansatz wählen, damit man nicht Gefahr läuft, in Schönheit zu sterben. Es hat schließlich niemand was davon, wenn nach fünf Sprints ein super sauber strukturiertes System steht, das aber nichts von dem kann, was das Start-up dringend braucht und auf einmal das Geld alle ist.

Felix: Ausnahmen bestätigen die Regel. Aber ich würde sagen, ja. Ich könnte mir nicht mehr vorstellen, ein Projekt nicht agil anzugehen.

Björn: Es hat auf jeden Fall immer agile Komponenten. Es kann natürlich sein, dass du bei Software, die kritisch für Leib und Leben ist, Flugzeugsoftware oder so, wahrscheinlich deutlich formaler vorgehen musst. Aber unsere Projekte machen wir agil.

Felix: In der Vergangenheit haben wir manchmal agile Projekte zum festen Betrag angeboten. Das widerspricht sich. Das sind keine Festpreisprojekte, sondern Aufwandsprojekte. Häufig wird vergessen, dass die Schätzung, die man im Vorfeld macht, eben eine Schätzung ist. Auch da muss man den Kunden abholen.

Felix: Jedes Projekt hat ein gewisses Maß an Unsicherheit. Man kann aber versuchen, diese Unsicherheiten frühzeitig zu eliminieren. Beim Kunden Safeboxen zum Beispiel war der Scope des Projektes von vorneherein klar: Ein Container mit Schließfach-Boxen und einem Portal, über das dann irgendwie die Schlösser aufgehen. Ein Portal bauen, das können wir. Das haben wir schon x-mal gemacht. Aber bevor wir mit dem Team das Portal entwickeln, wollten wir im Vorfeld testen, wie sich die Bluetooth Controller in diese Schlösser integrieren lassen. Wenn das nicht funktioniert, dann brauchen wir den Rest gar nicht bauen.

Björn: Du musst sehen, dass du das Wichtigste, den MVP (Minimum Viable Product, etwa: kleinstes funktionsfähiges Produkt), herausschälst und den Fokus darauf legst, diesen umzusetzen. Damit hast du das größte Risiko minimiert. Dann kann der Kunde entscheiden, ob es weitergeht oder nicht. Eine Option ist eben auch, dass der Kunde abbrechen kann, wenn sich nach drei, vier Sprints nichts Zufriedenstellendes ergibt. Diese wird zum Glück nicht allzu oft gezogen.

Felix: Ich glaube das ist, wieviel Eigenverantwortung in den Teams liegt. Sie sind nach dem Projektstart vollständig verantwortlich für das Projekt mit allem, was dazugehört. Die Teams haben jederzeit Einsicht in das Budget. Sie wissen, wo das Projekt steht. Sie müssen technische Entscheidungen treffen. Um die Anforderungen umzusetzen, müssen sie Verantwortung übernehmen. Bei den meisten Leuten führt diese hohe Eigenverantwortung zu einer hohen Motivation. Es motiviert, wenn du Dinge entscheiden kannst.

Björn: Das hat sich mit den Jahren auch gewandelt. Früher hatten wir in Projekten oft die klassischen Rollen: eine macht Architektur, einer kümmert sich um QS, der nächste um die Projektleitung und dann noch ein paar Entwickler:innen. Das wird heute meist durch Teamarbeit erledigt. Und hierdurch fühlt sich jedes Teammitglied für die jeweiligen Themengebiete verantwortlich.

Genau hier kommt auch das Thema DevOps ins Spiel: In den meisten Projekten betreibt das Team das, was es entwickelt hat, hinterher auch. Da habe ich ein deutlich gesteigertes Interesse, die Prozesse möglichst handhabbar zu machen.

Björn: ChatGPT. Reicht doch!

Felix: Das ist auf jeden Fall ein Punkt. Ich glaube, dass wir lernen, sowas wie ChatGPT zu bedienen. Klar brauchst du noch Leute, die das verstehen, was da am Ende an Code herauskommt. Wir werden aber davon wegkommen, dass man alles per Hand tippen muss. Wir verproben bei uns gerade den GitHub Copilot. Das ist schon beeindruckend, was der uns an Boilerplate-Code abnehmen kann, also Code, der nur Fleißarbeit ist.

Björn: Das wird in Zukunft aber noch deutlich mehr Semantik haben. Ich kann dem Tool eine Aufgabe stellen und es kommt ein bisschen mehr heraus als dieser 0815-Code.

Felix: Eine Herausforderung im Vergleich zu vor zehn Jahren ist, dass es nicht mehr reicht, Java und das eine oder andere Framework zu können. Heute muss ich mich mit viel mehr Sachen auskennen, nicht bis in die Tiefe, aber so weit, dass ich sie benutzen kann. Ich muss ein bisschen Ahnung von Docker haben, von Deployment, Datenbanken, dann die eigentliche Entwicklung im Backend und Frontend. Du musst neben deiner Projektarbeit gleichzeitig immer gucken, was rechts und links in dieser IT-Welt passiert. Das ist eine schwierige Balance.

Björn: Und du musst am Ball bleiben. Gerade bei Themen wie KI / AI, da passiert so viel! Das ganze Thema rund um ChatGPT oder GitHub Copilot hat ja erst in den letzten zwölf Monaten so richtig Fahrt aufgenommen und gefühlt kommen jede Woche Neuerungen hinzu. Nichtsdestotrotz müssen wir auch in der Zukunft unsere Basis-Technologien im Blick haben, um hier keine Neuerungen zu verschlafen.

Felix: Das auf jeden Fall. Ich denke aber, jenseits aller technischen Neuerungen müssen wir in Zukunft noch viel mehr unseren Fokus darauf legen, unsere Kunden bei der Analyse ihrer Anforderungen von der technischen Seite zu unterstützen, damit wir ihnen Lösungen bauen können, die sie auch wirklich brauchen. Das wird zeitnah kein AI-Tool übernehmen können und wird schließlich immer mehr zu unserer Kernkompetenz werden.

Felix: Weil sie sonst ein Softwareprodukt hätten, für das sie wahrscheinlich keinen Dienstleister mehr finden, der das weiterpflegen möchte. Wenn ein Projekt in Betrieb geht und du fasst es drei Jahre nicht an, dann hast du eine unglaubliche Arbeit, bis du die ganzen neuen Versionen aktualisiert hast. Darum stellen viele Kunden bei uns über einen Support-Vertrag sicher, dass die Software up-to-date gehalten wird.

Björn: Was anders ist als früher, ist die Langlebigkeit von Projekten, die fast schon keine Projekte mehr sind, sondern eher Produkte der "Losgröße 1". Die meisten Projekte sind auf Langfristigkeit ausgelegt, also dass sie länger als fünf Jahre laufen. Deshalb wird Wartbarkeit und Erweiterbarkeit in diesen Umfeldern oft immer wichtiger.

Felix: Perfektes Stichwort: Wartbarkeit. Das hat sich auch geändert. Das ganze Thema Testing. Als ich angefangen habe, steckte das noch in den Kinderschuhen. Du willst auch nach fünf Jahren noch sicherstellen können, dass wenn du etwas anfasst, nicht etwas an anderer Stelle umfällt.

Björn: Ich will das schon nach zwei Tagen sicherstellen! Das hat auch etwas mit Eigenschutz zu tun. Wenn du früher – in der Zeit als Unit-Testing noch nicht so verbreitet war - ein Refactoring machen musstest, wie konntest du sicherstellen, dass das System hinterher noch funktioniert? Das war Stress pur! Genauso wenn man früher nur einmal im Quartal eine neue Version ausgeliefert hat. Da gab es dann Wochenenden, an denen alle gezittert haben, ob man sonntags nicht doch die alte Version zurückspielen muss. Daher hat alles, was wir heute an Continuous Integration und Continuous Deployment machen, auch den Hintergrund, dass das eine Art von Training ist und du sicher sein kannst, dass dir ein Fehler sofort auf die Füße fällt und eben nicht erst ein Vierteljahr später, wenn du keinen Schimmer mehr hast, warum.

Felix: Ich finde, wir sind gerade schon in einer superspannenden Zeit. Klar, das KI-Thema ist nochmal ein Schlag obendrauf. Wenn ich mir ansehe, was sich da getan hat, kann ich mir nicht vorstellen, was in den nächsten zehn Jahren noch passieren soll. Das ist schon total krass.

Björn: Prozesse, die wir heute noch manuell machen, werden wahrscheinlich weiter automatisiert werden. Ich kann mir gut vorstellen, dass das noch deutlich komfortabler und für die Entwickler:in einfacher wird. Tools und Systeme wie bspw. Kubernetes haben eine hohe Komplexität und steile Lernkurve. Da wird sich mit Sicherheit noch einiges tun, damit der Einstieg und die Bedienung künftig einfacher sind.

Felix: Worauf ich mich auf jeden Fall freue, das ist auch eine coole Geschichte bei der HEC, sind regelmäßig wechselnde Projekte und Kunden. Es werden früher oder später alle Bereiche zur Digitalisierung gezwungen sein. Man begleitet viele Leute beim Weg in die Digitalisierung. Das ist superspannend. Und irgendwie schon cool, wenn du siehst, was die vorher für abgefahrene Prozesse hatten. Mit Excel ausdrucken, einscannen, abtippen, wieder Excel, faxen... Und jetzt kriegen sie eine Lösung, mit der das alles auf Knopfdruck funktioniert!

Björn: Beim Handwerkszeug gibt es spannende Entwicklungen. Früher waren Code-Reviews, Pair Programming und Mob Programming nicht so gang und gäbe. Durch Corona hat das einen Push gegeben. Allerdings leidet durch das Homeoffice das soziale Umfeld im Team. Wenn das Team nicht funktioniert, funktioniert das Projekt nicht. Deshalb denke ich immer mehr, ein zwei Tage vor Ort fände ich schon schön. Das ist vielleicht das, worauf ich mich freue: Dass es in Zukunft wieder ein bisschen mehr persönliche Treffen geben wird.