Clean Development in Wort und Bild
In unserer mehrteiligen Video-Serie reden wir über unser Verständnis von professioneller Softwareentwicklung. Wir beleuchten unser Mindset und wie wir dieses nutzen können, um Eure Softwareprojekte durchzuführen oder Eure Projektteams auf ein neues Level zu heben.
Wozu existieren wir
Gerissene Deadlines, unzufriedene Stakeholder, ein Team unter Dauerdruck, und jetzt auch noch KI. Wenn Ihr das aus Euren Softwareprojekten kennt, seid Ihr nicht allein. Wir haben es selbst in unzähligen Projekten erlebt.
Genau deshalb gibt es Clean Development Partners: Wir sind überzeugt, dass Softwareprojekte anders laufen können. Verlässlich, planbar und mit einem Ergebnis, hinter dem alle stehen. Dass das so selten gelingt, liegt weder am Team noch am Legacy-Code. Die eigentliche Ursache ist unbequemer. Welche das ist, erfahrt Ihr im Video.
Transkript
Wenn Du hier gelandet bist, kennst Du die Probleme in Softwareprojekten.
Stakeholder sind unzufrieden mit dem Ergebnis. Deadlines werden gerissen oder gerade so erreicht. Das gesamte Team steht unter Druck. Letztlich, niemand ist so richtig zufrieden. Und jetzt auch noch KI: Heilsversprechen und Fluch gleichzeitig.
Wir kennen diesen Schmerz. Wir haben ihn erlebt, in unzähligen Projekten.
Die Gründe dahinter sind vielfältig. Aber eine Beobachtung vorneweg:
Das Team ist nicht das Problem. Üblicherweise mögen und respektieren sich die Teammitglieder. Und der legacy Code ist auch nicht die Ursache. Der erodiert nur, weil vorher etwas Anderes schiefläuft.
Und dieses Andere ist möglicherweiße unbequem: Denn auch wenn menschlich alles passt, arbeiten wir in Softwareprojekten oft unprofessionell:
Zusagen werden gemacht und nicht gehalten. Entwickler und Fachbereich reden aneinander vorbei, Anforderungen werden nicht verstanden. Und niemand öffnet den Raum, um positive Änderungen zu etablieren.
Was Professionalität für uns bedeutet, haben wir über Jahre aus echten Projekten herausgearbeitet. Wir nennen es das "Clean Development Mindset".
In den nächsten Episoden zeige ich Dir, was dahintersteckt und wie die Clean Development Partners GmbH Dich in der Durchführung professioneller Softwareprojekte unterstützt.
Wir reden z.B. über Fokus, über die Macht des Durchstichs, über gemeinsames Arbeiten, und so viel mehr.
Wenn Du KI in dieser Auflistung vermisst: Das ist bewusst.
Natürlich reden wir auch darüber, wie KI unsere Branche gerade umbaut.
Aber an der Art, wie man professionell arbeitet, ändert sie nichts. Sie macht einfach nur sichtbar, wer es tut und wer nicht.
Wenn Du also mehr wissen willst, dann abonniere unsere Seite. Und schreib uns, was Dir gerade am meisten weh tut.
Das Clean Development Mindset
Alle Projektbeteiligten sind bemüht, und trotzdem läuft das Projekt unrund. In der Retro landet Ihr dann bei den immer gleichen Punkten: unklare Anforderungen, zu langsame Entwicklung, keine Zeit für Qualität. Und auch Clean Code allein löst das nicht.
Denn der Projekterfolg entscheidet sich weder am Code noch an gut formulierten Stories. Er entscheidet sich daran, was Ihr baut und was nicht, was Ihr durchdenkt, bevor Ihr tippt oder promptet, und was Ihr als Erstes streicht, wenn es eng wird. Genau darum geht es im Clean Development Mindset. Die Übersicht über seine Kernprinzipien gibt es im Video.
Transkript
Kennst Du das? Alle Projektbeteiligten sind bemüht, und trotzdem läuft das Projekt unrund oder ist dabei zu scheitern.
Vielleicht macht Ihr Retros, und dabei kommt heraus: Die Anforderungen sind vom PO unklar formuliert. Die Entwicklung ist zu langsam. Es wird keine Zeit für Qualität eingeräumt. Oder was ist das bei Dir?
Vielleicht folgst Du dem Clean Code Ansatz, damit soll ja alles gut werden. Wird es aber oft nicht.
Der Projekterfolg ist nicht vom Code abhängig und auch nicht von ausreichend formulierten Stories. Er entscheidet sich darin, was Ihr baut und was nicht. Darin, was Ihr durchdenkt, bevor Ihr tippt oder promptet. Darin, ob Ihr nach maximal zwei Wochen echten Mehrwert liefert oder nur Konzepte produziert. Darin, was Ihr gemeinsam wisst und wie Du Dein Team unterstützt. Darin, ob Ihr Erfolg messt oder nur den Status erfühlt. Und darin, was Ihr als Erstes streicht, wenn es eng wird.
Die Qualität darf das nie sein!
Das ist der Unterschied zwischen sauberem Code und sauberer Entwicklung: Das ist das Clean Development Mindset. Professionell arbeiten heißt, diesen Kernprinzipien zu folgen, auch bei Druck.
Um Dir das näher zu erläutern, gehe ich in weiteren Episoden auf folgende Punkte ein: Kundenproblem im Fokus, Entwurf vor der Implementierung, Durchstich zuerst, Kollaboration im Team, Messen & Automatisieren sowie Qualität ist nicht verhandelbar (und nicht teuer).
Wir schauen uns jeweils an, was sich dahinter verbirgt, woran Teams oft scheitern und was wir konkret tun können, um das zu verbessern.
Abonniere unsere Seite, wenn Du dabei sein willst.
KI: Was sich ändert und was nicht
KI-Tools sind im ganzen Team angekommen, alle fühlen sich schneller, und trotzdem kommt das Release nicht früher. Denn mit dem Tippen fällt auch die Zeit weg, in der man nebenbei nachgedacht hat. Unklare Anforderungen und fehlender Entwurf landen so direkt als Code im Projekt.
Macht KI damit Clean Code / Clean Development überflüssig? Im Gegenteil: Der Engpass war nie das Tippen. Was bleibt, ist zu entscheiden, was gebaut wird, es zu durchdenken, bevor es entsteht, und gemeinsam zu prüfen, ob es stimmt. Dass das Clean Development Mindset dadurch noch wichtiger wird, erfahrt Ihr im Video.
Transkript
Ihr habt inzwischen vielleicht KI-Tools im gesamten Team eingeführt. Alle fühlen sich schneller. Und trotzdem kommt das Release nicht früher. Ist das bei Dir auch so?
Bevor wir in dieser Videoserie in die Clean-Development-Kernprinzipien einsteigen, reden wir über KI. Ihr habt uns oft gefragt, wie wir damit umgehen. Und wenn wir das jetzt nicht klären, hängt an jedem Prinzip, das ich Dir zeigen werde, die Frage: Macht das nicht jetzt schon KI?
Also: Warum wird nicht alles besser, obwohl der Code so viel schneller entsteht?
Früher war das Tippen auch die Zeit, in der man nebenbei nachgedacht hat. Was soll das eigentlich tun? Passt das zum Rest? Und diese Zeit fällt jetzt weg.
Das heißt: Unklare Anforderungen und fehlender Entwurf landen sofort als Code im Projekt. Und die Komplexität steigt, bevor es jemand merkt.
Wir hören oft: Clean Code verliert an Bedeutung und es ist nur eine Frage der Zeit, bis KI sauberen Code schreibt. Was auch immer „sauber“ bedeutet, denn da sind wir Menschen uns auch nicht einig.
Wenn man Clean Code nur als ordentlich formatierten Code versteht, mag das stimmen. Aber zu Clean Code gehören auch Tests, denen Du wirklich vertrauen kannst. Und die Disziplin, nichts zu bauen, was keiner braucht. Und das ist heute wichtiger denn je.
Und selbst der sauberste Code, der hilft Euch nicht, wenn damit kein Mehrwert erzeugt wird. Ganz egal, wer ihn schreibt.
Der Engpass, will ich sagen, war nie das Tippen. Wer bisher nur Code geschrieben hat, wird es in Zukunft schwer haben.
Was aber bleibt, ist: Es muss entschieden werden, was gebaut wird. Durchdacht werden, bevor irgendwas entsteht. Und prüfen, ob das stimmt. Und zwar müssen wir das gemeinsam tun. Und daran sind Projekte bisher gescheitert.
Und das ist der neue Job in der Softwareentwicklung. Ehrlich gesagt: Ich finde ihn spannend.
Die KI nimmt den leichten Teil ab. Und das, was wir Clean Development nennen, wird dadurch umso wichtiger.
Wenn Du also in den nächsten Folgen, die Du hier abonnieren kannst, Dir denkst: „Das macht doch die KI“, dann lass uns mal genau hingucken, wo die KI bestärkt, was Du aktuell schon tust.
Fokus
Das Team ist meist weit weg von den Menschen, die die Software benutzen. Anforderungen kommen gefiltert an, also optimiert Ihr, was Ihr selbst seht: elegante Architektur, saubere Abstraktionen, Vorbereitung auf alles, was vielleicht mal kommt. Davon sehen Eure Nutzer nichts.
Die Lösung kennt jeder: YAGNI, You Ain't Gonna Need It. Trotzdem klingt jede Ausnahme vernünftig, und mit KI ist sie in Minuten gebaut. Warum der Treiber trotzdem immer die Kundenanforderung ist, erfahrt Ihr im Video.
Transkript
Dieses wohlige Gefühl, wenn Du siehst, dass Nutzer mit Freude verwenden, was Ihr gebaut habt!
Wie gut kennst Du das eigentlich? Oder weißt Du vor allem, wie durchdacht Eure Software ist?
Meistens ist das Team weit weg von den Menschen, die die Software benutzen. Anforderungen kommen gefiltert an, über den Fachbereich, Tickets, Product Owner, etc. Also optimiert das Team, was es selbst sehen kann. Das ist: eine elegante Architektur, saubere Abstraktionen, ausgefeilte KI-Workflows, eben Vorbereitung auf alles, was vielleicht mal kommt.
Und davon sehen Eure Nutzer: nichts! Sie bewerten, ob ihre Probleme durch die Software gelöst werden oder eben nicht. Und jede Stunde, die in die Entwicklung von etwas "Vorstellbarem" fließt, fehlt bei dem, was tatsächlich gebraucht wird.
Wir brauchen also Fokus auf den Kundennutzen, und eine Lösung dafür kennt jeder: YAGNI. You Ain't Gonna Need It. Du wirst es nicht brauchen. Alle finden das richtig!
Und trotzdem hören wir in jeder Beratung, sobald wir es einfordern: "Aber ich muss mich ja nicht dumm stellen", "Das kommt auf jeden Fall", "Wenn wir schon im Thema sind, machen wir das gleich mit." Mit KI ist so eine Ausnahme in Minuten gebaut, pflegen muss man sie trotzdem.
YAGNI scheitert nicht am Wissen, sondern darin, dass jede Ausnahme davon so vernünftig klingt. Dabei sind Ausnahmen Wetten auf die Zukunft, die heute schon Komplexität bringen.
Deshalb ist der Treiber immer die Kundenanforderung. Eleganz darf sein, gar keine Frage, aber sie folgt der Anforderung, und ob diese umgesetzt ist, merken Eure Nutzer. Ganz nebenbei ist YAGNI die direkteste Art, Kosten zu senken und Wert zu steigern.
Wenn Du das nächste Mal denkst: "Das kommt auf jeden Fall!", dann schreib uns. Wir atmen kurz durch und halten gemeinsam den Schmerz aus, Dinge vielleicht auch mal noch nicht zu bauen.
Und wenn Du die weiteren Clean Development Prinzipien nicht verpassen willst, dann abonniere natürlich unsere Seite.
Entwurf
Im Bewerbungsgespräch greift man zum Zettel, im Team wird aus dem Ticket direkt Code. Natürlich entsteht dabei auch ein Entwurf, aber beim Tippen, im Kopf von nur einer Person, und niemand kann ihn prüfen. In der Demo wundert Ihr Euch dann, warum es anders aussieht als gedacht.
Der Entwurf gehört an einen Tisch, an dem Fachbereich und Entwicklung zusammensitzen, und er beginnt an der Oberfläche, bei dem, was Eure Nutzer sehen und tun. Warum Ihr eine falsche Entscheidung so in Minuten statt in Tagen korrigiert, erfahrt Ihr im Video.
Transkript
Stell Dir folgende Situation vor: Du führst ein Bewerbungsgespräch und Dein Gegenüber bekommt eine kleine Programmieraufgabe, greift zum Zettel und sagt: "Ich mache mir erst mal Gedanken, wie ich das löse." Gutes Zeichen, nicht wahr?
Ein halbes Jahr später sitzt derselbe Mensch in Deinem Team, und einen Zettel gibt es dort nicht mehr. Aus dem Ticket wird direkt Code. Natürlich entsteht dabei auch ein Entwurf, aber beim Tippen, im Kopf von nur einer Person, und niemand kann diesen Entwurf prüfen. Du siehst das Ergebnis zum ersten Mal in der Demo und wunderst Dich, warum es anders aussieht, als Du gedacht hast.
Ich habe viele solcher Zettel gesehen. Meistens waren sie leer und eigentlich eine Pause, um Zeit zu gewinnen. Entwerfen wollten alle, aber gelernt hat es niemand. Programmieren lernt man überall, ein Problem sauber zu zerlegen, nicht.
Der Entwurf entsteht an einem Tisch, an dem Fachbereich und Entwicklung zusammensitzen. Dort klärt sich, wie Ihr über die Sache sprecht, ob alle dasselbe Problem verstehen und welche Lösung dazu passt. Am Ende stehen Entscheidungen, die alle verstanden haben.
Wir beginnen dabei an der Oberfläche, bei dem, was Eure Nutzer sehen und tun. So kann jeder den Entwurf prüfen, ohne eine Zeile Code zu schreiben. Die Überraschung in der Demo bleibt aus, denn auf dem Papier korrigiert Ihr eine falsche Entscheidung in ein paar Minuten, im Code kostet sie Tage.
Für den Entwurf nutzen wir Flow Design von Stefan Lieser und Ralf Westphal, eine Methode, die Software als Fluss von Daten beschreibt und zerlegt. Es gibt andere Methoden, sie müssen letztlich zu Euch passen. Wichtig ist, dass Ihr wirklich entwerft, bevor der Code oder der Prompt entsteht.
Wenn Du wissen willst, was auf Euren Zettel stehen sollte, schreibt uns. Das Whiteboard bringen wir gegebenenfalls mit.
Und wenn Du die weiteren Episoden nicht verpassen willst, abonniere diese Seite.
Durchstich
Bevor die eigentliche Anforderung umgesetzt werden kann, muss das System erst technisch sauber werden. Also wird Schicht für Schicht gebaut, von der Datenbank über die Geschäftslogik bis zur Oberfläche. Ob alles ineinandergreift, zeigt sich erst ganz am Ende, und bis dahin gibt es wochenlang nichts zu sehen.
Bei uns kommt deshalb der Durchstich zuerst: ein schmaler Schnitt durch alle Schichten, von Anfang an integriert. Warum sich das trotz des Aufwands lohnt und was in einem übernommenen Projekt schon nach einer Woche zu sehen war, erfahrt Ihr im Video.
Transkript
Im Statusmeeting hörst Du wieder und wieder denselben Satz: "Bevor die eigentliche Anforderung umgesetzt werden kann, muss das System erst technisch sauber werden." Zu sehen gibt es dann wochenlang nichts.
Dahinter steckt eine Intuition, die jeder kennt: Ein Haus baut man von unten nach oben. Erst das Fundament, dann die Wände, dann das Dach.
In der Software heißt das: erst die Datenbank, dann die Geschäftslogik, dann die Oberfläche, die UI.
Nach diesen Schichten werden oft sogar ganze Teams geschnitten. Jede Schicht wird fertig gemacht und an die nächste weitergegeben.
Ob alles ineinandergreift, zeigt sich erst ganz am Ende. Und bis dahin kann kein Nutzer etwas ausprobieren.
Nur: Ob ein Fundament trägt, weißt Du erst, wenn etwas draufsteht.
Deshalb kommt bei uns der Durchstich zuerst.
Fachlich heißt das Vertical Slice: ein schmaler senkrechter Schnitt durch alle technischen Schichten. Ein Durchstich enthält zum Beispiel die UI (ein Formular), die Berechnung und eine Tabelle in der Datenbank. Diese sind sofort ineinander integriert, und Du siehst sofort, ob die Teile zusammenpassen. Du lernst schon während der Entwicklung dazu und bekommst früh Rückmeldung, auch von Euren Nutzern und Stakeholdern.
Ehrlich gesagt ist das anstrengend: Man wechselt zwischen diesen Schichten und es ist gar nicht so einfach, immer einen guten, passenden kleinen Vertical Slice zu finden. Es lohnt sich trotzdem. Wir haben einmal ein Projekt übernommen, in dem wochenlang am Code gefeilt wurde, ohne dass etwas Nutzbares herauskam. Nach einer Woche konnten wir trotzdem den ersten echten Mehrwert zeigen. Die Anwendung konnte noch lange nicht alles, aber jeder konnte damit arbeiten und uns sagen, was genau fehlt.
Dadurch werden auf einmal auch Zusagen verbindlich und Planung möglich, weil jede Woche etwas entsteht, das Du anfassen kannst.
Wenn bei Euch seit Wochen nichts Sichtbares mehr entstanden ist, dann ruft uns an und wir schauen darauf, wie wir bei Euch den Vertical Slice finden können.
Und solltest Du weitere Episoden dieser Serie nicht verpassen wollen, abonniere unsere Seite.
Kollaboration
Freitagmorgen im Daily fragt eine Kollegin, wer mit ihr vor dem Urlaub die Übergabe macht. Das klingt verantwortungsvoll. Doch wenn sich im Planning jeder seine Story nimmt und für sich arbeitet, sammelt sich das Wissen bei genau einer Person. Remote passiert nur noch, was jemand bewusst einrichtet, der Rest landet in privaten Chats und im Chatverlauf mit der KI. Wird jemand plötzlich krank, gibt es nicht einmal eine Übergabe.
Kollaboration ist deshalb ein Prinzip im Clean Development Mindset: Wissen gehört dem Team. Wie das beim Erklären von Stories, beim Pairing, in synchronen Code-Reviews und im gemeinsamen Teamkanal aussieht und warum es anstrengend sein darf, erfahrt Ihr im Video.
Transkript
Es ist Freitagmorgen und im Daily sagt eine Kollegin: "Ich bin ab heute Abend im Urlaub. Wer macht mit mir die Übergabe?" Du nickst, das klingt ja auch verantwortungsvoll.
Im Planning nimmt sich sowieso jeder seine Story. Alle sind ausgelastet, jeder arbeitet für sich, und das Wissen über eine Story sammelt sich bei genau einer Person. Im Büro hast Du früher vielleicht vieles nebenher mitbekommen, am Nachbartisch oder an der Wand mit den Stickies.
Remote passiert nur noch, was jemand bewusst einrichtet. Der Rest landet in privaten Chats, inzwischen auch im Chatverlauf mit der KI.
Die Übergabe klingt nach Verantwortung. In Wahrheit zeigt sie Dir, wo Euer Wissen auf einer Insel liegt.
Und wird ein Kollege plötzlich krank, gibt es nicht einmal eine Übergabe.
In einem Team, das wirklich zusammenarbeitet, kann jeder einfach auch mal fehlen. Deshalb ist Kollaboration für uns ein Prinzip: Wissen gehört dem Team. Das beginnt in der Runde, in der Ihr die nächsten Aufgaben durchsprecht. Dort erklärt bei uns jemand aus dem Entwicklungsteam die Story und der Product Owner hört zu. Erst beim Erklären zeigt sich, was wirklich verstanden ist.
Dazu kommt Pairing, also zu zweit an einer Aufgabe arbeiten, remote am geteilten Bildschirm zum Beispiel.
Code-Reviews machen wir ebenfalls synchron: Wir schauen uns den Code gemeinsam an und reden darüber. Und alles, was das Projekt betrifft, steht im gemeinsamen Teamkanal.
Wenn Dir jetzt der Gedanke kommt, das kostet zu viel Zeit, dann prüf mal, was Du eigentlich meinst und ob es vielleicht einfach nur anstrengend ist. Denn dann bist Du auf dem richtigen Weg. Genauso arbeiten erfolgreiche Teams.
Wenn bei Euch vor jedem Urlaub eine Übergabe ansteht, dann schreib uns. Wir sorgen mit Euch dafür, dass beim nächsten Urlaub niemand mehr solch eine Übergabe braucht.
Und wenn Du die weiteren Prinzipien unserer Serie nicht verpassen willst, abonniere wie immer gerne unsere Seite.