Wandel des Mindsets in der Softwareentwicklung – Warum und sollte man mitgehen?

[Whiz-zarD]

vor 11 Stunden schrieb Mickey0501:

Ist die Microservices-Architektur nicht eher aus dem agilen Mindset heraus entstanden? Es ist ja nicht so, dass jemand sich einfach hingesetzt hat und entschieden hat, 'Jetzt machen wir Microservices'. Vielmehr ist es ein Muster oder Pattern, das über die Jahre hinweg gereift ist. 

Eher weniger. Es entstand aus mehreren Richtungen aber keiner davon hatte irgendwas mit Agile Softwareentwicklung zu tun gehabt. Microservices sind keine neuartige Erfindung. Microservices ist nur eine feingrunalare Serviceorientierte Architektur (SOA). SOA ist sogar älter als das Agile Manifesto und so agil sind Microservices nun auch nicht, weil man ganz schnell in eine Service-Hölle (distributed big ball of mud) kommen kann, wenn nur jeder das macht, was er will. Es ist also eine hohe Kommunikation und auch Disziplin von Nöten und sollten auch von kleineren Unternehmen vermieden werden, weil der Aufwand nicht zu unterschätzen ist. Bei Microservices ging es viel mehr darum, die Software rubuster gegen Veränderungen zu entwickeln. Es stand also mehr das Aufbrechen der Zuständigkeiten im Vordergrund. Man hatte mehr die Unix-Philosophie im Kopf: „Mache nur eine Sache und mache sie gut.“

Aufgrund der vielen Nachteile der Microservices, etabiliert sich immer mehr die Architektur des Modularen Monolithen. Monolithen sind ja per se erstmal nichts schlimmes und lassen sich auch agil entwickeln. Das Problem ist aber oft die Zuständigkeiten, wenn es innerhalb eines Monolithen keine klare Trennung der Fachlichkeit gibt und genau das versuchen Modulare Monolithen in den Griff zu bekommen.

Microservices haben sich also eher durchgesetzt, weil der Begriff "Monolith" verbrannt war, durch die millionenfache Legacy Produkte und Microservices dann als der Heilbringer verkauft wurde.

[Software-Schamanin]

vor 5 Minuten schrieb allesweg:

Früher war der klassische Softwareentwickler für die Implementierung der Vorgabe verantwortlich, der Anforderungsmanager für die Qualität der Anforderungen, der Projektleiter für die Termin- und Kapazitätsplanung, der Anayst für die Anforderungserstellung, ...

Welche dieser dezidierten Personen-Rollen-Zuordnungen gibt es in einem echt-agilen Umfeld noch? Welche Freigabeschleifen bremsen zwischen Idee und potentiell produktiv einsetzbarem Artefakt?

Jetzt würde ich tatsächlich sagen, dass das realitätsfern ist. Die meisten Firmen haben genau diesen Prozess nicht durchgemacht sondern entweder aus der Laune eines motivierten Mitarbeiters oder aufgrund von Befehl von oben genau das eingeführt. Andere sind nun agil also müssen wir das jetzt auch machen. Gleiches gilt auch für die Architektur andere machen Microservices also müssen wir die jetzt auch machen. 

Mag sein, dass das wirklich sehr stark abstrahiert ist. Aber für mich sind das Probleme und Fragestellungen mit denen ich mich täglich ausseinander setzen muss. Könnte evtl. an der Wahl der Firmen liegen.

Agile Transformation laut Lehrbuch findet man leider selten so dass es immer die Mischwelten sind mit denen man klar kommen muss. 

[Software-Schamanin]

vor 6 Minuten schrieb Whiz-zarD:

Eher weniger. Es entstand aus mehreren Richtungen aber keiner davon hatte irgendwas mit Agile Softwareentwicklung zu tun gehabt. Microservices sind keine neuartige Erfindung. Microservices ist nur eine feingrunalare Serviceorientierte Architektur (SOA). SOA ist sogar älter als das Agile Manifesto und so agil sind Microservices nun auch nicht, weil man ganz schnell in eine Service-Hölle (distributed big ball of mud) kommen kann, wenn nur jeder das macht, was er will.

Wenn man sich mit dem Thema ausseinander setzt bin ich allerdings auch schnell bei  Conway:

Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.

Ja das Systeme per Webservice kommunizieren ist keine neue Technologie. Was neu ist, ist dass ich durch Clouddienste Bibliotheken usw. viel schneller bin diese bereitzustellen. 

Wenn man sich mit dem Thema auseinander setzt, wird immer betont, dass die Teams autark strukturiert sein müssen um autarke Systeme zu erstellen. Wenn ich zum Beispiel ein Frontend- und ein Backendteam mache, habe ich auch zwei Services. Diese sind aber nicht autark und erschweren nur die Kommunikation und die Abhängigkeiten. 
Oder der klassiker den man häufig findet. Ich habe einen Service/Team der den Zugriff auf meine zentrale Datenbank verantwortet. Für jedes neue Feature muss immer dieser Service angepasst werden. Und das ist meist der Punkt wo man dann sagt Microservices sind blöd weil man in einer Service-Hölle endet.

[Whiz-zarD]

vor 27 Minuten schrieb allesweg:

Früher war der klassische Softwareentwickler für die Implementierung der Vorgabe verantwortlich, der Anforderungsmanager für die Qualität der Anforderungen, der Projektleiter für die Termin- und Kapazitätsplanung, der Anayst für die Anforderungserstellung, ...

Welche dieser dezidierten Personen-Rollen-Zuordnungen gibt es in einem echt-agilen Umfeld noch? Welche Freigabeschleifen bremsen zwischen Idee und potentiell produktiv einsetzbarem Artefakt?

Hat es diese Rollen wirklich jemals gegeben, außer auf dem Papier? Ich würde sagen, nein. Ansonsten gäbe es ja keinen Grund, Agil zu arbeiten, wenn die Qualität der Anforderungen hoch ist und die Termin- und Kapazitätsplanung funktionieren würde. Ich denke aber mal jeder Entwickler kennt die schlechtbeschriebenen Anforderungen oder die zu knappen Deadlines.

Agile Softwareentwicklung ist ja nicht durch ein Management entstanden, sondern von Entwicklern selber. XP entstand ja dadurch, dass ein Projekt (eine interne Buchhaltungssoftware) stillstand und man dann zusammen mit den Facharbeitern gearbeitet hat. Neben einem Entwickler saß auch ein Facharbeiter, der die Anwendung später bedienen sollte. Die Entwickler waren also im ständigen Austausch mit den Benutzern und bekamen sofort Feedback.

vor 4 Minuten schrieb Mickey0501:

Ja das Systeme per Webservice kommunizieren ist keine neue Technologie. Was neu ist, ist dass ich durch Clouddienste Bibliotheken usw. viel schneller bin diese bereitzustellen.

Sowas nannte man früher Terminalserver.

Bearbeitet 6. Februar von Whiz-zarD

[Software-Schamanin]

vor 19 Minuten schrieb allesweg:

Solange man objektiv begründen kann, was man vorgibt, tragen Teams die Entscheidung üblicherweise mit?

Bei den jüngeren Entwicklern, die die agile Denkweise mitnehmen ist das meist kein Problem. Schwierig wird es für mich immer bei den "älteren" 
Die älteren Entwickler, die gewohnt sind, dass sie Konzepte bekommen usw. sind meist sehr irritiert, dass sie eigenverantwortlicher arbeiten müssen oder Entscheidungen vielleicht sehr spät und dynamischer getroffen werden. Wenn die Software agil ist, dann kann man auch nur schwer im Vorfeld planen. 

Oder man hat Entwickler die selbst anfangen alles bis ins kleinste Detail zu planen anstatt erstmal den MVP umzusetzen. Da sie es aber auch so gewohnt sind an jede Funktionalität zu denken. 

Meine Vermutung ist, dass das daher kommt, dass Software früher viel langsamer releaset wurde und alles perfekt laufen musste. Während es heute in bestimmten Bereichen "egal" ist, wenn es noch nicht hundertprozentig läuft. 

Dann wird es halt angepasst und neu deployed. Dafür konnte man schonmal sehen, wie das Feature von den Kunden/Zielgruppe angenommen wird.  

[Software-Schamanin]

vor 11 Minuten schrieb Whiz-zarD:

Sowas nannte man früher Terminalserver.

okay die gab es auch.

Aber wenn ich eine Datenbank brauche kann ich mir ein Clouddienst suchen und die mal eben hochfahren. Habe ein gesichertes System, dass ich jeder Zeit nutzen kann. Das ging natürlich früher nicht. Bietet natürlich auch potenzial zu schauen, ob für mein konkretes Problem eine andere Datenbank vielleicht besser geeignet ist als meine jetzige

[Whiz-zarD]

Das hat aber nichts mit Cloud an sich zu tun. Das kann ich auch lokal mit Containern machen. Früher wurden dafür auch fertige VMs bereitgestellt, die heute aber durch Container verdrängt worden sind.

Ich persönlich hatte damals eine Linux VM mit einem Apache Webserver und einer MySQL-Datenbank, die ich dann einfach hochgefahren habe. Klar, mit Clouddiensten geht es heute schneller aber sie macht nichts möglich, was damals nicht ging.

Bearbeitet 6. Februar von Whiz-zarD

[allesweg]

vor 26 Minuten schrieb Whiz-zarD:

Hat es diese Rollen wirklich jemals gegeben, außer auf dem Papier?

Ich sage ja.

vor 26 Minuten schrieb Whiz-zarD:

Ansonsten gäbe es ja keinen Grund, Agil zu arbeiten, wenn die Qualität der Anforderungen hoch ist und die Termin- und Kapazitätsplanung funktionieren würde.

Richtig.

vor 27 Minuten schrieb Whiz-zarD:

Ich denke aber mal jeder Entwickler kennt die schlechtbeschriebenen Anforderungen oder die zu knappen Deadlines.

Das ist aber kein Fehler innerhalb der Methode sondern (die üblicherweise in großer Zahl auftretende) Umsetzungsfehler.

Agilität verbessert weder die Anforderungsqualität noch die Zuverlässigkeit der Planung/Terminzusage sondern schafft zeitnahe Tranzparenz über den aktuellen Zustand des Gesamtsystems.

[Maniska]

vor 46 Minuten schrieb Mickey0501:

Die älteren Entwickler, die gewohnt sind, dass sie Konzepte bekommen usw. sind meist sehr irritiert, dass sie eigenverantwortlicher arbeiten müssen oder Entscheidungen vielleicht sehr spät und dynamischer getroffen werden. Wenn die Software agil ist, dann kann man auch nur schwer im Vorfeld planen.

Agile Softwareentwicklung bedeutet nicht einfach mal ohne Konzept drauf los zu entwickeln.

Die grundlegende Architektur sollte schon "stehen" bevor man extrem viel Zeit in ein Projekt steckt ohne das man dann am Ende 3x zurück ans Reißbrett muss um Fehler im Fundament auszubügeln. Vor allem Fehler die man nicht gemacht hätte, wenn man sich vorher ausreichend Gedanken gemacht hätte.

Zitat

Oder man hat Entwickler die selbst anfangen alles bis ins kleinste Detail zu planen anstatt erstmal den MVP umzusetzen. Da sie es aber auch so gewohnt sind an jede Funktionalität zu denken. 

Ich bin kein Entwickler, aber ich denke mal, dass es auch dort langfristig "besser" ist, schon mal 3 Schritte weiter zu denken, zu überlegen welche Requests bzgl. Funktionalitäten sind zu erwarten, was kann ich jetzt schon implementieren um dem Entwickler der dann X, Y und Z machen soll das Leben zu erleichtern...

Zitat

Meine Vermutung ist, dass das daher kommt, dass Software früher viel langsamer releaset wurde und alles perfekt laufen musste. Während es heute in bestimmten Bereichen "egal" ist, wenn es noch nicht hundertprozentig läuft. 

Ja, nennt sich Bananensoftware und reift beim Kunden.

Wenn jetzt aber jemand versucht mir derartigen Schrott als Vorzüge agilen Arbeitens zu verkaufen, dann bleib ich beim Wasserfallmodell. Früher gab es noch Zeit für Qualitätskontrolle, einen Anspruch an die eigene Arbeit und kein "ja, hau mal raus. Team 2 kann ja schon mal anfangen den Patch zu stricken"

[allesweg]

vor 56 Minuten schrieb Mickey0501:

Aber wenn ich eine Datenbank brauche kann ich mir ein Clouddienst suchen und die mal eben hochfahren.

Einfach so eine Datenbank bei einem beliebigen Clouddienst ins Firmennetz einbinden? Was machen die Firewall-Admins und Datenschützer hauptberuflich?

Ohne jetzt auf Lizenzrecht einzugehen.

[Software-Schamanin]

vor 30 Minuten schrieb allesweg:

Einfach so eine Datenbank bei einem beliebigen Clouddienst ins Firmennetz einbinden? Was machen die Firewall-Admins und Datenschützer hauptberuflich?

Ohne jetzt auf Lizenzrecht einzugehen.

Wenn ich bereits in der Cloud bin dann ist das durchaus üblich genau das zu machen. Ich schaue welche Technologie mir hilft mein Problem zu lösen. Wenn mir meine relationale Datenbank mehr Probleme als nutzen bringt, versuche es mal für die Teilproblem eine dokumentenorientierte zu nehmen. Durch die lose Kopplung betrifft das ja nur einen Teil des Systems. 

Das Systeme immer mehr komplett in der Cloud gehostet werden ist auch nicht unüblich um genau diese Flexibilität zu haben.

[allesweg]

Du hast "einen Clouddienst suchen" geschrieben - da steht nix von "etwas von einem bereits im Haus vertretenen Anbieter für meinen Arbeitgeber Verfügbares einbinden"

[Whiz-zarD]

vor 1 Stunde schrieb allesweg:

Agilität verbessert weder die Anforderungsqualität noch die Zuverlässigkeit der Planung/Terminzusage sondern schafft zeitnahe Tranzparenz über den aktuellen Zustand des Gesamtsystems.

Exakt, weil es noch nie eine hohe Anforderungsqualität oder Zuverlässigkeit gab aber die Prozesse so ausgelegt waren, dass die sie hoch waren. Ergo: Die Qualität der Projektplanung wurde vernachlässigt, weil sich niemand dafür wirklich verantwortlich gefühlt hat bzw. niemand so recht wusste, wie man diese Probleme in den Griff bekommt. Personen, die sich dann z.B. Anforderungsmanager nannten, wurden dann diesen Stellen nicht gerecht und die Lösung der Probleme heißt "Transparenz".

vor 56 Minuten schrieb Maniska:

Die grundlegende Architektur sollte schon "stehen" bevor man extrem viel Zeit in ein Projekt steckt ohne das man dann am Ende 3x zurück ans Reißbrett muss um Fehler im Fundament auszubügeln. Vor allem Fehler die man nicht gemacht hätte, wenn man sich vorher ausreichend Gedanken gemacht hätte.

Exakt. Ich könnte über eine nette Anekdote hier im Unternehmen berichten, wenn ich dürfte aber ja, Fehler im Fundament können auch im agilen Umfeld entstehen, wenn man einfach drauf losporgrammiert.

vor 8 Minuten schrieb Mickey0501:

Wenn ich bereits in der Cloud bin dann ist das durchaus üblich genau das zu machen. Ich schaue welche Technologie mir hilft mein Problem zu lösen. Wenn mir meine relationale Datenbank mehr Probleme als nutzen bringt, versuche es mal für die Teilproblem eine dokumentenorientierte zu nehmen. Durch die lose Kopplung betrifft das ja nur einen Teil des Systems. 

Genau dieses Prinzip hat aber auch massive Nachteile. Es ist vielleicht schön und toll, dass du dich mit dokumentenbasierten Datenbanken auskennst aber wie sieht es allgemein im Unternehmen aus? Schließlich muss die Software gepflegt werden und das klappt nur, wenn genug Know-How im Unternehmen existiert bzw. von Außen über Neueinstellungen eingebracht werden kann. D.h. selbst bei Microservices sollte man tunlichst einen Wildwuchs an Technologien vermeiden und sich auf bestimmte Kern-Technologien verständigen. Mag sein, dass bei einem Problem eine dokumentenbasierte Datenbanken besser wäre aber wenn es keinen im Unternehmen gibt, die sie pflegen kann, ist sie dann keine gute Wahl.

Es gibt auch noch genug On-Premise-Lösungen auf dem Markt und da sind Microservices in der Regel keine gute Wahl.

Bearbeitet 6. Februar von Whiz-zarD

[Maniska]

vor 26 Minuten schrieb Mickey0501:

Wenn ich bereits in der Cloud bin dann ist das durchaus üblich genau das zu machen. Ich schaue welche Technologie mir hilft mein Problem zu lösen. Wenn mir meine relationale Datenbank mehr Probleme als nutzen bringt, versuche es mal für die Teilproblem eine dokumentenorientierte zu nehmen. Durch die lose Kopplung betrifft das ja nur einen Teil des Systems.

Wenn deine Software in meiner Umgebung eingesetzt werden soll, dann läuft sie entweder auf meinem MS-SQL Cluster oder gar nicht. Oder ihr liefert den bereuenden Admin gleich kostenneutral mit.

Zitat

Das Systeme immer mehr komplett in der Cloud gehostet werden ist auch nicht unüblich um genau diese Flexibilität zu haben.

Solange der Endkunde kein SaaS Produkt erwirbt, bei dem ihm der Unterbau egal ist, solange muss sich deine Software an die Industriestandards halten die beim Kunden in Place sind, und das ist im Regelfall nicht die fancy neue Sau des Monats die gerade durchs Dorf getrieben wird, sondern irgendein alter Moloch.

[Software-Schamanin]

vor 27 Minuten schrieb Maniska:

Wenn deine Software in meiner Umgebung eingesetzt werden soll, dann läuft sie entweder auf meinem MS-SQL Cluster oder gar nicht. Oder ihr liefert den bereuenden Admin gleich kostenneutral mit.

Solange der Endkunde kein SaaS Produkt erwirbt, bei dem ihm der Unterbau egal ist, solange muss sich deine Software an die Industriestandards halten die beim Kunden in Place sind, und das ist im Regelfall nicht die fancy neue Sau des Monats die gerade durchs Dorf getrieben wird, sondern irgendein alter Moloch.

Soweit korrekt. Wenn ich Software direkt an den Kunden ausliefere passt das auch. Aber mit dem Trend der agilen Entwicklung gehen auch viele Firmen immer mehr den Weg SaaS anstatt direkte Deploys beim Kunden anzubieten. Natürlich auch mit allen kaufmännischen Konsequenzen.

Die Frage ist kann ich in der Branche noch Bestand haben, wenn ich den Weg nicht mit gehe? Vielleicht ist meine Qualität bei dem Produkt, dass ich ausliefere durch längere Releasezyklen eine Bessere. Aber die neuen Features werden von der Konkurrenz schneller geliefert, da sie durch Cloud-Infrastruktur und dem Verwenden von zielgerichteter Technoligen viel schneller liefern können. 

vor 58 Minuten schrieb Whiz-zarD:

Genau dieses Prinzip hat aber auch massive Nachteile. Es ist vielleicht schön und toll, dass du dich mit dokumentenbasierten Datenbanken auskennst aber wie sieht es allgemein im Unternehmen aus? Schließlich muss die Software gepflegt werden und das klappt nur, wenn genug Know-How im Unternehmen existiert bzw. von Außen über Neueinstellungen eingebracht werden kann. D.h. selbst bei Microservices sollte man tunlichst einen Wildwuchs an Technologien vermeiden und sich auf bestimmte Kern-Technologien verständigen. Mag sein, dass bei einem Problem eine dokumentenbasierte Datenbanken besser wäre aber wenn es keinen im Unternehmen gibt, die sie pflegen kann, ist sie dann keine gute Wahl.

Auch die Leute, die sich mit neuen Technologien auskennen, fallen nicht vom Himmel. Das wissen kommt ja daher, dass man es in einzelnen Projekten mal ausprobiert hat. Eigentlich ist es fast die Regel, dass man im Zuge eines Projektes auch Erfahrungen mit neuen Technologien sammelt. 
Zudem ist es ja auch meist ein Team, dass diese Erfahrungen sammelt und keine Einzelperson. 
Das heißt nicht, dass ich alles blind einsetze, aber ich sollte schon den Mut und die Fähigkeit haben an der entscheiden Stelle zu wissen, was ich Einsetzen kann um schneller ans Ziel zukommen. 

[allesweg]

vor 8 Stunden schrieb Whiz-zarD:

Exakt, weil es noch nie eine hohe Anforderungsqualität oder Zuverlässigkeit gab aber die Prozesse so ausgelegt waren, dass die sie hoch waren. Ergo: Die Qualität der Projektplanung wurde vernachlässigt, weil sich niemand dafür wirklich verantwortlich gefühlt hat bzw. niemand so recht wusste, wie man diese Probleme in den Griff bekommt. Personen, die sich dann z.B. Anforderungsmanager nannten, wurden dann diesen Stellen nicht gerecht und die Lösung der Probleme heißt "Transparenz".

Und Neuverteilung der Verantwortung. Früher prüfte der Anforderungsmanager die Qualität der Anforderung und fand sie gut. Der Projektleiter schätzte darauf basierend den Zeitbedarf. Dann kam der Entwickler und sollte aus einem Halbsatz Gold gewinnen. Dann beschwerte er sich über den PL, der auf den Anforderungsmanager verwies, welcher auf den Autor der Anforderung verwies sowie dass der PL die Anforderung ja angenommen hätte. Außerdem hätte der Entwickler das implementiert, was er in der Anforderung verstanden hätte, womit ja alles gut wäre?!

Im agilen Umfeld gibt es unter anderem die lebenden Kriterien "Definition of Ready" und die "Definition of Done", welche ein BacklogItem erfüllen muss, bevor der Statusübergang zulässig ist. Jedem Teammitglied muss es gestattet sein, die Übernahme eines Items anzuzweifeln. Und genau letzterer wird meistens ignoriert.

[Parser]

Am 6.2.2024 um 09:51 schrieb Mickey0501:

In meiner Praxis habe ich beobachtet

bist du Arzt ? 

[Rabber]

DoR? DoD? Davon habe ich mal gehört. So in der Theorie. Oder in irgendwelchen verstaubten Wikis, die keiner liest. 😁

[allesweg]

@Rabber man muss diese beiden nicht irgendwo als Dokument ausformuliert ablegen - sie zu leben ist der wichtige Teil.

Wenn ich jeden Halbsatz-Task mit unreifen Gedanken zur Implementierung annehme, kommt irgend was halbgares raus.

Und wenn keine Abschluss-Bedingungen definiert sind, kann ich entweder die Tasks jederzeit schließen oder sie ewig weiter offen mit rum schleppen.