Neben dem eigentlichen Thema in der IT, dem Jahr 2038 Problem, werden auch sehr interessante Geschichten von vorhergehenden Problemen wie z.B. dem Jahr 2000 Problem erzählt.
Geschichten über den Absturz der Ariane 5, der Berliner Feuerwehr, den EC Karten, über das GPS, was passiert bei der Schaltsekunde, und was man bei der Steuerung von chemischen Prozessen beachten muss.
Ich finde das Phasenmodell bei low-code Entwicklungen zwar einen interessanten Ansatz, aber leider nur halb durchdacht.
Es werden einige Annahmen getroffen, die aus meiner Sicht zwar manchmal zutreffen, aber eben nur manchmal. Und diese Fälle dann als Argumentation für generelle Behauptungen zu verwenden finde ich falsch.
Annahmen
Die erste Annahme ist, daß die meisten IT Projekte Datenbank Projekte sind.
Ich gestehe zu, daß häufig Datenbanken in einer Applikation benötigt werden, aber dies sind dann häufig Grundlagen und nehmen nur einen geringen Teil einer Entwicklung oder Applikation ein. Ja, das Daten Modell muss natürlich passen, aber Sorry, das ist doch ein „no brainer“. Und wenn das Daten Modell im Laufe einer Entwicklung angepasst werden muss, macht man eben eine Migration der Datenbank. Die Argumentation ist typisch klassisch: Alles muss vorher definiert werden und darf sich nicht mehr ändern. So etwas kann man sich heute nicht mehr leisten. Eher muss man das Systemdesign so gestalten, daß eine spätere Datenbank Migration machbar ist. Durch diesen Ansatz erreicht man zwei Ziele. Einerseits eine frühzeitige Version der Applikation und die Möglichkeit, auch in der Zukunft mit möglichst geringem Aufwand Änderungen/Weiterentwicklungen an einem System durchführen zu können.
Die zweite Annahme, daß es sehr selten Personen gibt, die genau die Anforderungen verstehen, finde ich auch sehr spannend. Wie will man denn jemals die Kunden bzw. stakeholder zufrieden stellen, wenn man nicht mal weiß, was die wollen? Das ist die originäre Aufgabe eines Product Owners! Und ja, wenn diese Person den Job nicht richtig macht, dann wird das Produkt nicht gut werden. Aber das ist unabhängig von der jeweiligen Project Management Methode.
Annahme Nummer drei ist, dass man einmal das Daten Modell definiert hat und dann nur mehr low code „entwickelt“, sprich konfiguriert. So einfache Arbeiten bzw. so ein tolles framework zu haben, in dem das möglich ist, möchte ich mal sehen. Das funktioniert meiner Ansicht nach nur in einer Umgebung, die sehr stark auf das jeweilige Framework zugeschnitten ist. Und dies bedingt dann auch, dass keine größeren Änderungen mehr durchgeführt werden können. Man ist für „alle“ Zeiten auf das einmal definiert Datenmodell fixiert.
Agil oder klassisches Projekt Management
Ich stimme zu, daß man nicht immer scrum bzw. Agil machen muss. Es kann natürlich auch Sinn machen, klassisches Projekt Management im jeweiligen Projekt anzuwenden. Es gibt keinen Ansatz, der immer richtig ist.
Besonders beim initialen Projekt mit einem neuen Kunden wird man immer das Problem haben, daß der Kunde einen bestimmten minimalen feature Set erwartet. Dies wird inzwischen üblicherweise über die gemeinsame Definition eines MVP realisiert. Und was Teil des MVP ist, und welche Themen später realisiert werden, ist Teil einer Story map.
Story map
Die in dem Artikel genannten Phasen kann man natürlich trotzdem haben. Sie können sehr leicht über Sprint Ziele im Rahmen einer Scrum Entwicklung abgebildet werden.
Und das ist aus meiner Sicht auch bei Applikationen sinnvoll, die mit einem low-code Framework arbeiten.
Low-code applikationen
Natürlich entwickelt man mit einem low-code framework wesentlich schneller. Auf der anderen Seite bindet man sich unheimlich stark an das jeweilige framework und grössere kundenspezifische Anpassungen sind meist dann doch nicht mehr so einfach.
D.h. als Kunde muss man sich bewusst sein, dass man entweder mit dem Standard des jeweiligen frameworks zufrieden sein muss, oder dann doch wieder in die klassische Programmierung investieren muss.
Zusammenfassung
Ich kann mir die nicht gut verstandenen, aber starr definierten Applikationen gut vorstellen, die so entstehen. Damit möchte ich als Anwender nicht arbeiten wollen.
Wenn ich mir agile Reifegrade für Unternehmen auf einer Skala vorstelle, ist dieses Unternehmen aus meiner Sicht sehr weit unten.
Das wichtigste dabei ist die richtige Haltung (mindset). Wenn das durch das gesamte Unternehmen nicht passt, wird es für die Umsetzung von Projekten sehr schwer.
