Gelernt: Suchmotivation kann auch indirekt sein

Schreibe eine Antwort

Für unsere Smoketests, die wir häufig für alle möglichen neuen Angebote durchführen, ergab sich, dass unsere DevOps-Dienstleistungen nicht direkt das Kaufinteresse des Kunden ansprechen konnten. Am Beispiel unserer DevOps-Angebote, konnten wir also nicht auf die naheliegenden Suchbegriffe gehen. Beispielsweise „devops dienstleistungen“ oder „devops team beauftragen“. Warum nicht und wie haben wir das gelöst?

TL;DR: Das Suchvolumen ist nicht groß genug. Es lässt sich kein ausreichend großer Traffic in kurzer Zeit für einen Smoketest erreichen. Es müssen benachbarte Interessen (z.B. plulp „softwareentwicklung beauftragen“) mit dem DevOps-Angebot beworben werden.

Spannenderweise ist das Interesse via Google für ein Buzz-Thema wie DevOps nicht groß genug. Die IT-Entscheider lieben dieses Thema, weil es langfristig Geld spart. Und dennoch: Dienstleistungen werden nicht gesucht.

In der SEO-Fachsprache Folgendes: Die Intention der Suchen (der sogenannte „Intent“) ist eher „informational“ und nicht „commercial“. Es gibt insgesamt vier: „transactional“ und „navigational“ sind die anderen zwei. Bei kommerziellen Suchen handelt es sich um Anfragen, welche in einen Kauf oder eine (vermutlich) kostenpflichtige Dienstleistung münden sollen. Beispielsweise “Dreirad kaufen, Betreuung Online Marketing“. Eine informative Suche ist in der Regel ein einzelner Begriff, welchen man erklärt haben möchte oder auch ein Vorgang oder eine Tätigkeit, die man erläutert haben mag. Als Beispiel “Europaparlament”, “Wie ziehe ich Tomaten auf dem Balkon?”, “Hinkelsteinherstellung”.

Es wird also nach DevOps gesucht, aber eher zu informativen Zwecken. Warum das so ist, ist mir zum jetzigen Zeitpunkt noch nicht klar. Eine Erklärung wären die verschiedenen Markttypen (nachzulesen beispielsweise bei Steve Blank, „Four Steps to the Epiphany“, ): Blank sagt, es gibt vier Typen von Märkten, nämlich existierende, resegmentierte, neue und Klonmärkte. Zählt DevOps noch zu den neuen oder resegmentierten Märkten? Dann sucht es niemand. Aber ist das so? So buzzy das Thema ist, bin ich ziemlich sicher, es ist DevOps-Dienstleistungen ein etablierter und damit existierender Markt in dem es ja auch genügend Konkurrenz gibt. Nach „Flugtaxi bestellen“ sucht erstmal noch kaum jemand. Wenn ich Flugtaxis anbiete, bin ich erstmal in einem neuen Markt und muss erstmal das Suchvolumen eine „adjacent“ (benachbarten) Marktes anzapfen: „Taxi bestellen“. Da habe ich natürlich mit erhöhten Streuverlusten zu kämpfen, aber das ist Preis des Innovationsgrades.

Ansonsten habe ich nur eine Arbeitshypothese. Vielleicht informiert sich ein Entscheider heute über die Vorteile von DevOps, ist aber in den meisten Fällen ohnehin mit einem Entwicklungsdienstleister bedient, bei dem er dann die Umstellung auf DevOps-Prozesse fordert und beauftragt.

Aus unserer Erfahrung gibt es viele Software-Dienstleister, die keine automatisierten CI/CD-Prozesse haben oder nur rudimentäre. Zumindest nach der informativen Recherche sollte also ein kommerzielles Interesse entstehen, um externe Hilfe dazu heranzuziehen. Was sich nach meinem Verständnis in einem entsprechenden Suchverhalten widerspiegeln sollte. „devops beratung“ z.B. Da dies nicht so ist, habe ich offensichtlich noch eine Verständnislücke. Ich werde das weiter analysieren.

Gelernt habe ich aber schonmal: Wenn ich Birnen via Google verkaufen möchte, kann ich nicht unbedingt darauf setzen, dass Kaufinteressierte „Birnen kaufen“ suchen. Das muss ich erst validieren. Falls das Ergebnis ist, das Suchvolumen ist gering, ist die Frage wieso. Eventuell weil Birnen out sind. Die saisonale Nachfrage nicht da ist. Es gibt viele Gründe. Wenn das nicht passt, kann es auch sein, dass nur indirektes Interesse besteht und man über – ich nenne sie mal so – „Strohmann-Keywords“ gehen. Dann muss ich mich für meine Birnen bei der Suche „Äpfel kaufen“ unterhaken.

Artikelbild: Illustration mit einer Gruppe von Kartenspielern die Planning Poker spielen

Die 6 besten Planning Poker Tools zur freien Verfügung

7 Antworten

Ein Update für 2024 gibt es hier zu lesen.

Das Planen im agilen Umfeld muss möglichst schnell und doch möglichst präzise sein. Ausschweifendes Schätzen mit Pflichten- und Lastenheft ist hier nicht gefragt. Wir wollten schnell zu neuen Ergebnissen kommt und darauf aufbauen.

Dennoch bedarf es einer gewissen Schätzung der anstehenden Aufgaben. Es empfiehlt sich, gemeinsam mit dem ganzen Team an der Planung zu arbeiten, damit sich alle Beteiligten gegenseitig austauschen können. Doch Experten, erfahrenere Kollegen oder extrovertierte Kollegen können die leisen Stimmen entmutigen und so das Ergebnis einer Diskussion verfälschen. Um spielerisch, einfach und objektiv zu schätzen bietet das Planning Poker (auch bekannt als Scrum-Poker) das richtige Werkzeug. Dabei geht es darum, den Aufwand einer Aufgabe einzuschätzen, um sich einen Überblick über die geplanten Aufgaben zu verschaffen.

Der Autor dieses Beitrags ist nicht unbefangen, bemüht sich dennoch um höchste Objektivität. Eines der aufgeführten Spiele wurde von uns entwickelt. Die Vorteile der anderen Planning Poker werden in diesem Artikel gleichwertig herausgearbeitet.

Planning Poker objektiviert den Schätzprozess bei Refinementmeetings und Sprintplannings. In einer klassischen Diskussion beeinflussen sich die Teammitglieder oft gegenseitig. Beispielsweise seniorigere Kollegen den Nachwuchs. Durch Planning Poker lässt sich Produktivität mit ein bisschen Spaß verbinden. Mit Schätzpoker werden sich alle Mitarbeiter motiviert fühlen und in einer guten Stimmung an den Aufgaben beteiligen. Der gesamte Arbeitsprozess gestaltet sich als sehr angenehm für alle Seiten.

Vorgehensweise

Jeder, der an der Planning-Poker-Session teilnehmen möchte, bekommt eine Anzahl an Spielkarten mit unterschiedlichen Nummern. Im ersten Schritt wird die Aufgabe oder ein Teil davon vorgestellt und alle Mitarbeiter wählen die Karte mit der Nummer aus, wie hoch oder wenig Aufwand sie dafür schätzen würden. Die Karten werden mit der Zahl nach unten in die Mitte des Tisches gelegt und nachdem alle ihre Entscheidung getroffen haben, aufgedeckt. Nun können sich die Kollegen über die Ergebnisse austauschen und seine Position begründen. Im zweiten Schritt wird der Vorgang wiederholt und alle sind dazu aufgefordert, nachdem der Meinungsaustausch stattgefunden hat, noch mal eine Schätzung abzugeben. Idealerweise einigen sich alle Mitarbeiter auf eine bestimmte Zahl. Ein Kompromiss ist gut, jedoch ist das Ziel vom Scrum-Poker, dass sich keiner von den Meinungen anderer beeinflussen lässt. Als Orientierung gilt nämlich die am meisten vertretene Zahl.

Diese Methode wird bereits von vielen großen Unternehmen eingesetzt und zeigt seine positive Wirkung. Schätzpoker ist eine agile Methode, die mit einer Vielzahl an Vorteilen überzeugt. Es verhilft dabei, bessere Strategien zu planen und den eigentlichen Arbeitsaufwand richtig einzuschätzen, denn oft verschätzen sich erfahrene Profis ebenso wie Anfänger und Praktikanten. Außerdem trägt diese agile Methode automatisch zum Teambuilding bei, denn im Pokerprozess wird auf gleicher Ebene agiert, unabhängig davon, welche Position ein Mitspieler eigentlich im Unternehmen oder im Team hat. Durch die Besprechungen und Diskussionen werden Meinungen nicht nur ausgetauscht, sondern man lernt viel voneinander. So können gegenseitig wertvolle Erfahrungen und Tipps von den Kollegen gesammelt werden.

Natürlich gibt es heute diverse Planning-Poker-Tools online, die uns die Möglichkeit geben, auch remote ein Teammeeting zu organisieren und gemeinsam am Sprint-Planning zu arbeiten. Diese kostenlosen Sprint-Poker-Tools stehen Ihnen frei, kostenlos zur Verfügung:

Agile Casino

https://agilecasino.kehrwasser.com/

Derzeit können wir über Agile Casino sagen, dass es sehr zuverlässig funktioniert. Wir nutzen es selbst bei Plannings in verschiedenen Teams. Es kann ohne Registrierung kostenlos genutzt werden. Es können beliebig viele Runden gespielt werden. Von mehr als sieben Spielern und weiteren Beobachtern. Unbegrenzt viele weitere User können als Zuschauer dem Raum beitreten. Es können einfach Einladungen an Teammitglieder z.B. per Mail oder der Chatanwendung der Wahl versendet werden. Bei Agile Casino können die Fibonaccizahlen als Punktesystem und weitere vorbereitete Reihen wie T-Shirtgrößen oder Power-of-2 gewählt werden. Auch individuelle Reihen können gewählt werden.

  • Es wird zügig auf Featurewünsche reagiert
  • Spieler können individualisiert werden

Scrum: Die maximale Anzahl von 7 Entwicklern (oder anderen Personen) in einem Entwicklerteam bzw. Scrumteam, laut Scrum Guide, ist damit abgedeckt.

planitpoker.com

https://www.planitpoker.com/

Eine ähnliche Variante ist die Planitpoker App, die sich vor allem dadurch auszeichnet, dass es besonders unkompliziert zu bedienen ist. Die Anmeldung erfolgt mit einem Klick und Sie können mit einer Planningsitzung direkt starten. Auch hier ist das Design eher schlicht gehalten, was die App angenehm für den Benutzer macht.

scrumvee.com

https://scrumvee.com/

Hier gibt es eine extra Portion Motivation für die Teilnehmende. Jedes mal, wenn die geschätzte Zahl einer Person ausgewählt wird, bekommt diese ein paar Punkte. Wer am Ende der Sitzung die meisten Punkte verdient hat, geht als der Sieger raus. Spieler haben so einen Anreiz, gut überlegte Schätzung abzugeben. Andererseits könnte es auch dazu führen, dass Spieler schneller dazu hingerissen werden, gewissen Leitwölfen zu folgen. Als Schätzungen zu übernehmen. Scrumvee ist ebenso als Mobile App oder online frei verfügbar.

planningpokeronline.com

https://planningpokeronline.com/

Es dauert nur wenige Sekunden, sich einen Account anzulegen und schon kann ihr Meeting starten. Sie können zwischen verschiedenen Bewertungseinheiten wie klassische Schätzpoker Zahlen oder Kleidungsgrößen wählen. Bei Bedarf besteht auch die Möglichkeit, die Zeit zum Nachdenken zu reduzieren und einen Timer zu setzen. Dadurch wird angeregt, dass die Teilnehmer ihre ersten Gedanken äußern, also eine spontane Einschätzung, ohne lange zu überlegen. Erfahrungsgemäß sind unsere ersten Gedanken meist die richtigen.

Firepoker

https://firepoker.io/

Noch eine gute Alternative für Sprint-Poker online, die sich vor allen dadurch auszeichnet, dass es so einfach gestaltet ist und dass der eigentliche Prozess unfassbar schnell anfangen kann, denn es dauert gar nicht so lange, bis eine Runde organisiert wird und alle Teilnehmende eintreten können. 

Parabol

https://www.parabol.co/agile/sprint-poker/

Dieses online Scrum-Poker-Tool ermöglicht es, die Planning-Session bis auf das kleinste Detail zu personalisieren. Individualisieren können der User die Farben der Kärtchen, Zahlen oder Symbole und noch vieles mehr. Außerdem erhalten Sie am Ende der Sitzung ein Protokoll über die Ergebnisse direkt auf Ihre E-Mail.

Ein Siebtes ist zu erwähnen:

scrumpoker.online

https://scrumpoker.online/

Die App ist kostenlos und man kann sie sowohl vom Handy aus als auch online vom Desktop nutzen. Das Interface ist vergleichsweise einfach gestaltet. Für mobile Geräte ist es sehr gut geeignet. Teilnehmer können über den Einladungslink dem Spiel beitreten.

Für ein paar Runden Sprintplanning gibt es auch eine Vielzahl an Apps für Android oder iOS. 

Digitalisierung

Schreibe eine Antwort

„Digitalisierung“ ist eines der meistverwendeten, aber auch meistmissverstandenen Schlagworte unserer Zeit. Viele Unternehmen glauben, sie seien auf dem richtigen Weg, wenn sie PDF-Formulare statt Papier nutzen oder Exceltabellen in der Cloud teilen. Doch echte Digitalisierung ist weit mehr als das.

Digitalisierung bedeutet: Arbeitsprozesse so zu gestalten, dass sie automatisiert ablaufen.

Im Kern ist Digitalisierung nichts anderes als die Fortsetzung des technologischen Fortschritts: Prozesse, die früher manuell und fehleranfällig waren, lassen sich heute durch Software, KI und Automatisierung vollständig abbilden. Der Unterschied zu früher? Heute ist diese Automatisierung universell möglich, nicht mehr nur in Fabriken, sondern auch in Büros, Kanzleien und Agenturen.

Was viele „Digitalisierungsprojekte“ falsch machen

Viel zu oft endet ein Digitalisierungsprojekt dort, wo die eigentliche Arbeit anfängt. Beispielsweise: Ein Formular wird nicht mehr gedruckt, sondern als Webformular bereitgestellt – aber danach wird es manuell geprüft, weitergeleitet oder abgetippt. Excel-Listen werden in Cloud-Speichern abgelegt – aber weiterhin per E-Mail hin und her geschickt.

Diese Praxis ist nicht Digitalisierung, sondern Schein-Digitalisierung. Der entscheidende Schritt fehlt: die Automatisierung. Nur wenn Prozesse wie Prüfungen, Berechnungen, Genehmigungen oder Übertragungen automatisiert ablaufen, entsteht der Produktivitätsgewinn, den Digitalisierung verspricht.

Digitalisierung als Fortsetzung der Industrialisierung

Die grundlegende Theorie ist älter als das Wort Digitalisierung selbst: Bereits in der Industrialisierung war das Ziel, menschliche Arbeitskraft durch Maschinen zu ergänzen oder zu ersetzen, um Skalierbarkeit und Effizienz zu erreichen. Damals geschah dies vor allem in der Produktion. Heute ist es der digitale Schreibtisch, der revolutioniert wird.

Wenn Digitalisierung richtig umgesetzt wird, steigert sie die Produktivität exponentiell – und damit den gesellschaftlichen Wohlstand.

Doch dieser Wohlstand entsteht nur, wenn nicht in teuren Projekten versickert, was eigentlich in Automatisierung fließen sollte.

Die Schattenseite: Wie Digitalisierungsprojekte bewusst verzögert werden

Viele Dienstleister profitieren davon, wenn Digitalisierungsprojekte möglichst lang laufen und möglichst viel betreut werden müssen. Deshalb wird oft: Komplexer geplant als nötig, mühsam „digitalisiert“, was sich direkt automatisieren ließe oder unnötig individualisiert, statt auf bewährte Komponenten zu setzen.

Das Ergebnis: Digitalisierung wird teuer, langsam und frustrierend – und liefert zu wenig Nutzen fürs investierte Geld.

Skeptisch werden, wenn keine belastbaren Zahlen den Fortschritt belegen

Das Hamburger Unternehmen Kehrwasser geht bewusst den Weg, mithilfe der Software Kehrwasser Beacon wird bei allen Kundenprojekten der Grad der Automatisierungsabdeckung kontinuierlich zu messen:

  • Welche Prozesse sind bereits automatisiert?
  • Wo werden noch manuelle Zwischenschritte gemacht?
  • Wie viel Zeit und Geld wurde dadurch eingespart?

Dieser kontinuierliche Audit-Ansatz stellt sicher, dass:

  • Digitalisierung kein Selbstzweck, sondern wirtschaftlich messbar wird.
  • Kunden über die Zeit eine echte Rendite auf ihre Investitionen sehen (ROI).
  • Projekte nicht entgleisen, sondern auf Kurs bleiben.

Fazit

Digitalisierung ist kein neues Buzzword – sondern die Möglichkeit, alte Fehler nicht zu wiederholen. Nur wer versteht, dass Digitalisierung Automatisierung meint, wird in Zukunft konkurrenzfähig bleiben.

Und nur wer diesen Fortschritt messbar und ehrlich umsetzt, schafft echten Mehrwert für sein Unternehmen, seine Mitarbeiter – und am Ende auch für die Gesellschaft.

Tipp: Wer wissen will, wie automatisiert sein Unternehmen bereits arbeitet, kann sich bei Kehrwasser für ein kostenloses Beacon-Audit registrieren.

Dockerimage für CI/CD mit Sloppy CLI

Schreibe eine Antwort

In CI/CD-Situationen, also in Situationen, in denen wir automatisiert gewisse Aussagen über und Aufgaben am aktuellen Entwicklungsstand einer Software vornehmen wollen, sind wir häufig auf die Kommandozeile angewiesen.

TL;DR: Das Runner-Image z.B. für GitLab ist auf DockerHub frei verfügbar dielok/sloppy-cicd. Wir werden die Dockerfile auch in Kürze bei Github veröffentlichen.

Über entsprechende Skripte, also aneinandergereihte Befehle, automatisieren wir dann den Prozess und visualisieren ihn in Form von sogenannten Build- und Deploymentpipelines.

Auch mit dem Cloud-Anbieter Sloppy muss dies natürlich irgendwie innerhalb eines Skriptes möglich sein, damit wir den Entwicklungsstand auch automatisiert veröffentlichen können. So kann die Anwendung auch letztlich von Endnutzern verwendet werden. Dies kann ein Server sein, oder ein ganzes Netzwerk aus Servern, daher sprechen wir von Umgebungen. Auf der sogenannten Produktivumgebung läuft die Anwendung für den Endverbraucher. Umgangssprachlich „Prod“.

Auch auf Umgebungen die nicht produktiv sind, müssen die aktuellen Entwicklungsstände ausgerollt werden können. Diese dienen beispielsweise den Tests der Qualitätssicherung, Demonstrationen für Stakeholder und der Beobachtung des Fortschritts durch Manager. Das soll so zuverlässig, einfach und schnell wie möglich ablaufen: Also automatisiert.

Das geht mit Sloppy im Handumdrehen. Super einfach ist ein neues Projekt (Umgebung) angelegt, Services, Apps in Form von Docker-Containern definiert.Nicht nur in dem UI. dem Portal von Sloppy. Sloppy bietet eine gut entwickelte CLI-Anwendung, mit der Apps, Services und Projekte verwaltet und gesteuert werden können.

Und so können auch die Deployment-Schritte in der Pipeline mit Sloppys CLI-Tool automatisiert werden. Das Skript für diesen Schritt ist dann gerade einmal zwei Zeilen lang:

script:
- export SLOPPY_APITOKEN="$SLOPPY_APITOKEN"
- sloppy change --image docker/container:${CI_COMMIT_REF_NAME} umgebung/service/app

(Auszug aus der CI/CD-Konfiguration für Gitlab)

Zu verbessern wäre, dass dieser Pipelineschritt noch wartet, bis das Deployment erfolgreich abgeschlossen wurde und der Service gestartet werden konnte.

Doch wie bekommt die Pipeline die Sloppy CLI, sodass der Befehl sloppy überhaupt zur Verfügung steht? Entweder lädt und installiert die Pipeline die Binaries bei jeder Ausführung dieses Schrittes oder die Anwendung wird bereits in den zugrundeliegendeliegenden Container installiert und steht immer gleich zur Verfügung.

Für unser Zwecke habe ich den Container mal erstellt und auf Docker Hub verfügbar gemacht: dielok/sloppy-cicd. Viele Erfolg.

Sloppy hat einen genialen Ansatz als Cloud-Anbieter

Schreibe eine Antwort

Wenn ich Sloppy richtig verstehe, wollen sie ein Cloud-Anbieter sein, der grundsätzlich bei den Großen mitmischt. Und ich denke, dass werden sie auch, denn Sloppy nicht aus dem Silicon Valley sondern aus Köln zeigt mir gerade, was AWS, Google Cloud und Azure eigentlich falsch machen.

Sloppy ist im Wesentlichen ein Cloud-Anbieter, der auf den Kern der Sache konzentriert ist: Container (ob jetzt Pod oder Docker oder oder) spezifizieren und und den Cluster hochfahren. Das, sowie die restlichen Aufgaben, die es im Operrationsumfeld gibt, sollten nicht, eigentlich nicht und hätten es nie müssen: Hexenwerk sein.

Beispielsweise etwas, was vollkommen unterschätzt ist: Die sogenannte Docker-Compose-Datei. Im eigenen Team habe ich es miterlebt: Docker-Compose wird so ein bißchen als Spiellösung abgetan. Es ist aber ein komplett ausreichendes, universelles Interface um Cluster im Allgemeine zu definieren. Ob das jetzt Kubernetes, OpenShift oder sonst was läuft.

Sloppy hat dies sofort erkannt. Mindestens über deren CLI-Tool kann man diese Docker-Compose-Datei hochladen und damit den gesamten Cluster hochfahren und konfigurieren. Ich finde es schon alleine bemerkenswert, dass so eine kleine Firma ein beachtliches, einfach zu nutzendes CLI-Tool entwickelt und den Users zu Verfügung stellt.

Die GUI ist bereits jetzt sehr gut verwendbar. Es lassen sich verschiedene Projekte erstellen. Verschiedene Zonen. Ich kann die Container (standarmäßig vom Docker-Hub) definieren und die Instanzen skalieren. Rolling-Deployments kommen gleich mit.

In CI/CD Pipeline kann ich ohne viel Aufwand Deploymentsteps definieren, die die Anwendungen auf die jeweiligen Umgebungen deployen bis durch auf die Produktionsumgebung.

Ich weiß nicht, welche Wünsche das offen bleiben, für welchen Anwendungsfall.

Evtl. gibt es diverse Compliantsrichtlinien, die sich ohne die Konfigurationsmöglichkeiten eines AWS oder Azure nicht realisieren lassen. Okay. Aber das ist doch dann die eigentliche Niesche.

Eigentlich könnten man sogar darauf wetten, dass sich herausstellen wir, dass der Sloppy-Ansatz eigentlich für die Masse geeigneter ist, als die großen Cloud-Anbieter. Denn der Betrieb via Sloppy erfüllt im Prinzip alles, was 95% der aktuellen Nutzer derzeit bei AWS und Co. nur kompliziert und umständlich und nicht so einfach bekommen. Das macht Sloppy schon sehr gut.

Positionierung: Ergebnisse des Smoketests mit Google Ads

Schreibe eine Antwort

So, wir kennen also die Angebotslücken am Markt (Artikel „Ergebnisse unserer Markanalyse“). Aus der Marktanalyse wissen wir, dass das Angebot für Marktplatzentwicklung und DevOps relativ gering ist. Also klare Sache? Die entsprechenden Suchanfragen bei Google bespielen und die Projektanfragen flattern rein? Denkste!

Neben der A/B-Splittests, der Smoketests, der Landingpages, der Zielgruppendefinition ist auch das Schalten und Designen von Google Anzeigen wieder eine eigene Wissenschaft. Auch hier bin ich Autodidakt und schreibe diesen Artikel als Amateur im Online Marketing (Auch wenn ich mittlerweile überzeugt bin, dass man diesen Anspruch an Kleinteiligkeit bei den meisten sogenannten Experten nichteinmal bekommen wird).

Die Keywordrecherche mittels „Intents“

Die Idee war, eine Keywordrecherche durchzuführen. Die Grundlagen kenne ich seid Jahren. Ich habe zusätzlich gelernt, dass Google mittlerweile verschiedene Suchanfragen bestimmten, sogenannten „Intents“ zuordnet. Für unsere Themen wäre das z.B. der Intent „Was ist Marketplace Development?“ oder „Was ist DevOps?“. Diese Intents gibt es in drei Kategorien: Informational, Purchase und Transactional. Die „Was ist…“ Intents sind klar aus der Kategorie Informational. Denn diese Intents suchen halt nach Detailinformationen. Uns wir später noch beschöftigen, dass es nicht immer klar ist, zu welcher Kategorie Google gewisse Intents zuordnet.

Mir waren die Intentkategorien erstmal egal. Ich habe eine erste Keywordrecherce, vorerst für DevOps selbst gemacht und diese Liste dann einem selbsternannten Keywordexperten gegeben. Der hat dann noch diverse Tools verwendet, um weitere Keywordideen zu finden. Wahrscheinlich hat der auch nichts anderes gemacht, als den Google Keyword Planner zu verwenden und mich dafür zu Kasse gebeten. So ist das Unternehmerleben: Manchmal zahlt man nur für die Möglichkeit einer erbrachten Leistung.

Ich habe unterschiedliche Keywords in der Liste: „devops ci cd“, „devops vorteile“, „gitlab devops“, „devops bedeutung“, „devops tutorial“, „devops“ und viele ähnliche Weitere. Wie man sieht, sind fast alle aus der Kategorie Informational, aber zu welcher Kategorie gehört „devops“?

Anzeigen entwerfen

Jetzt ist die Frage: Ist da genug? Ich habe jedenfalls jetzt erstmal keine Ideen mehr.

Der Verlauf der Kampagne

Gewundert hat mich, dass es wieder nur 5000 Menschen zu geben scheint, die in ganz Deutschland, Österreich und der Schweiz, die in drei Wochen nach DevOps-Themen bei Google suchen. Das glaube ich nicht, wenn man sich den Buzz um DevOps vor Augen führt. Eher hätte ich damit gerechnet, dass 10000 pro Woche suchen und entsprechend die Klickpreise hoch sind, da es viel Konkurrenz gibt.

An den schlechten Klickrate konnte ich auf die Schnelle nichts ändern. Aber die Anzahl der Impressionen könnte auch an unserem Tagesbudget gelegen haben. Daher habe ich dieses mal von 5€ auf 15€ pro Tag angehoben und tatsächlich war ein proportionaler Anstieg der Klicks zu sehen. Da ist also Luft nach oben.

Der Klickpreis liegt bei unter 1,50€, was ich okay finde und uns Spielraum für Experimente gibt. Bei 10€ pro Klick wäre jedes weitere Experiment ein teures Unterfangen.

Ergebnisse des Smoketests

Auf wenn also die Performance mit 1,21% Klickrate (Click Trough Rate, CTR) unterirdisch ist. Die Ausstiegsrate auf unserer DevOps-Landingpage ist auch nicht so gut. 20% steigen derzeit aus. Eine gute Erkenntnis ist aber, dass wir 1,48€ pro Klickzahlen und mit einem Budget von 25€ pro Tag durchschnittlich 20 User an Traffic auf unsere Landingpage leiten können, wann immer wir wollen.

Was uns eine neue Kundenanfrage (also eine Konversion) allerdings kostet, können wir aktuell nicht abschätzen, da wir bisher leider keine Konversion hatten. Wir können nur sagen, dass bei jetzigem Setting, eine Kundenanfrage teurer als 155€ ist, was ich nicht gehofft habe. Hoffentlich können wir das optimieren.

Learnings

Build, Meassure, Learn ist noch immer das Motto. Also war haben wir gelernt? Wir können Hypothesen für einen nächsten Test ableiten. Eine starke Vermutung ist die Intentkategorie. Wir haben Anzeigen geschaltet, die einen Suchenden erwarten, der nach einer Dienstleistung sucht, die also einen Intent der Kategorie Purchase erwarten. Die Keywords gehen fast alle eindeutig auf Intents der Kategorie Information. Und selbst das Keyword „devops“, das nicht eindeutig einer Intentkategorie zuzuordnen ist, gehört wahrscheinlich zu Information. Denn schaut man sich die anderen Suchergebnisse und Anzeigen auf „devops“ an, sind dies klar Inhalte, die DevOps erklären und es nicht verkaufen wollen.

Daraus erklärt sich möglichweise die niedrige CTR. Wir sollten als Experiment also Anzeigen entwerfen, die Informationen zum Thema bieten.

Nebenbei: Kann man daraus eine Regel ableiten? Wenn das zentrale Keyword eines Themas zur Intentkategorie Information gehört und ein hohes Interesse erfährt, dann ist das Thema in einem Frühstadium des Produktlebenszyklusses?

Aber wenn es also so gut wie keine Suchen vom Intent Purchase gibt, woher kommen dann die Kunden für DevOps. Nur wie unsere durch Word-of-Mouth? Vielleicht von Messen? Irgendwo müssen die ja herkommen. Eine Hypothese ist, unsere Kunden geben allgemeine Keywords ein um dann einen auf DevOps spezialisierten Dienstleister aus der Masse herausstechen zu sehen und mit den Vorteilen von DevOps konvertiert werden. Das entspricht allerdings wenig meiner persönlichen Erfahrung mit Kundenverhalten.

Ausblick

Wir werden es sehen. Wir machen nun folgende Experimente: Wir checken, ob die CTR bei Anzeigen, die dem Informationintent entsprechen, steigt. Wir checken, ob DevOps-Anzeigen auf unspezifische Suchen wie „Individuelle Softwareentwicklung“ besser funktionieren. Wir A/B-Splittesten die DevOps-Landingpage um zu schauen, ob wir nicht trotz der schlechten Werte, einen akzeptable Preis pro Projektanfrage erzielen können. Letztlich, wenn 1/10 Anfragen erfolgreich ist, wir je Anfrage einen Aufwand von 4 Stunden haben, haben wir eine CAC (Customer Acquisition Cost) von etwa 2.500€, was bei üblichen Projektumfängen immer noch okay wäre.

Planning-Poker-Tool bekommt neue Version

Eine Antwort

Sprint Planning in Remoteteams ist an und für sich eine runde Sache. Als die Remotearbeit aufgrund der Pandemie anstieg, haben wir uns daran begeben und auch das Planning Poker runder gemacht. Jetzt haben wir unserem Agile Casino ein Update gegönnt. Mit dem Update kamen Features dazu, die Stabilität wurde erhöht. Im Folgenden gehen wir etwas ins Detail.

Hintergrund

Wir haben am Anfang der Pandemie einen Prototypen (eher schon ein MVP) für das Planning Poker. Was heißt hier „wir“? Das Team lässt mich an der Stelle mit Recht etwas im Stich, denn die haben Wichtigeres zu tun. Ich halte es allerdings für eine tolle Gelegenheit, auch mal zu demonstrieren, wie wir an die Entwicklung von modernen Cloudanwendungen herangehen.

Grundsätzlich – wenn auch klein – erfüllt es alle Eigenschaften einer Cloud-Anwendung (eine SaaS, Software as a Service). Es gibt zwar keine Abomodell (da es kostenlos ist), das könnte es aber geben (andere Scrumpoker online haben ja Pläne wie 8 Euro pro Monat etc.) und Abo ist ja ein Kennzeichen für eine Cloudanwendung. Unser Abomodell kostet quasi 0 Euro.

Das Update

In diesem Update ging es um ein paar Features und um Stabilität. Für den Betrieb im Cluster mussten wir Änderungen vornehmen. Auch die QS-Schritte haben wir auf ein professionelles Niveau gehoben, in dem wir die anfänglich rundimentären automatisierten Tests (sogenannte Integrationstests) erweitert haben.

An Features gibt es nun neben der Rolle des Entwicklers auch die Rolle des „Inspectors“. Denn es ist häufig der Fall, dass weitere Personen dem Planning beiwohnen, die den Entwicklern im Raum keinen Platz wegnehmen sollen. Inspektoren sind alle Nichtentwickler eines Scrumteams und Sonstige. Was bleibt also nach Scrum Guide noch? Genau: Der Scrum Master und der Product Owner. Sonstige können alle möglichen Stakeholder sein.

Es sind zwar weiterhin nur sieben Entwickler möglich (das es in einem Scrum Team nur maximal neun Personen geben darf, neun minus zwei ergibt sieben Entwickler). Ich finde diese Aussage im aktuellen Scrum Guide nicht mehr. Dahre denke ich, werde ich diese Begrenzung evtl. aufheben.

Außerdem habe ich den Invite Link verbessert. Der lässt sich jetzt einfacher in die Zwischenablage kopieren und ist professionell eingebunden.

Geplante Features

Jira: Ich ich denke bereits über eine Jira-Anbindung nach. Es wäre sehr nützlich, wenn geschätzte Werte gleich via Klick in die entsprechende Story im Jira übernommen werden könnte. Aber auch sehr aufwändig. Vielleicht packe ich das Feature mal in eine Art Premiumpaket, dass treue Leser und Kunden natürlich kostenlos erhalten.

Timer: Ein Timer wäre sehr nützlich, der für alle synchron läuft.

Score: Im Score-Board sollten die Spieler mit den Minimal- und Maximalwerten markiert werden. Die Spielergebnisse je Schätzrunde sollten auch hübscher dargestellt werden.

T-Shirt-Größen: Derzeit gibt es nur die vorgegebene Werteskala. Der User sollte weitere Skalen wählen können. Eventuell sollte er auch Skalen erstellen können.

Fazit

Der agile Ansatz funktioniert einmal mehr. Agile Casino bietet bereits jetzt eine gute Basis und den Nutzen, Schätzpoker in Remote-Teams störungsfrei und kostenlos durchzuführen.

Mit dem aktuellen Update kommen weitere Möglichkeit hinzu. Aus Qualitätssicherungssicht ist die Anwendung ab dieser Anwendung jetzt komplett stabil.

Was haltet ihr von dem ganzen Vorgang? Nutzt ihr das Tool oder wollt ihr es nutzen? Welche Features sollten wir noch reinbringen und was hat eurer Meinung nach Priorität? Schreibt es in die Kommentare.

DevOps: Versionierungsstrategie bei Continuous Delivery

Schreibe eine Antwort

Setzen wir die Version aus dem Quelltext heraus? Sollte die CI/CD-Pipeline die Version setzen und womöglich auch einen Tag automatisiert im Version Control System (VCS, z.B. Git, Mercurial, Subversion) setzen?

Achtung: Dieser Artikel ist eher Low-Level und für Build-Engineers, Entwickler und Architekten geeignet.

TL;DR: Wenn der Kunde mit kryptischen Buildnummern oder Hashwerten und keine Aussage über die Kompatibilität in der Versionsbezeichnung nötig ist, kann der einfach mit jedem Commit bis auf die Produktion automatisiert werden.

Meist ist dies jedoch nicht der Fall. Die Anwendung besteht wahrscheinlich aus einem Backend und einem Frontend, wenn es sich um einen einfachen Fall handelt. In vielen Fällen haben wir bereits Microservice Infrastruktur mit mehreren Servicen, die über Schnittstellen miteinander kommunizieren und voneinander abhängen. Abwärtskompatibilitäten und Breaking-Changes wollen durch die Versionierung transparent gemacht werden.

Doch Breaking Changes in einem Softwarestand zu identifizieren, ist aus meiner Sicht nicht automatisiert möglich. Eventuell könnte man experimentell über Schnittstellenkontrakte und automatisierte Tests Abwärtskompatibilität automatisiert testen, das ist aber nur eine fixe Idee eines zu kreativen Entwicklers. Auch zwischen Patch und Minor-Release zu unterscheiden ist Ermessenssache. Der Punkt ist, um abhängige Anwendungen mittels der Versionsnummer über Major-Updates und wahrscheinliche oder sogar sichere Kompatibilitätsprobleme zu informieren, benötige ich einen Menschen.

Zum Einsatz kommt natürlich Semantic Versioning — Sie wissen schon: major.minor.patch-snapshot.

Das ist der manuelle Teil. Der automatisierte Teil ist relativ unproblematisch: Jeder Commit im VCS erzeugt über die CI/CD-Pipeline ein Artefact mit der Buildnummer (wahlweise dem Commit-Hash). So etwas wie meine-anwendung:4711, wobei 4711 die Buildnummer ist.

Dieses Artefakt – sei es ein Docker-Image, eine EXE, ein Tar-Archiv, eine Jar-Datei, whatever – wird üblicherweise in einem Artefaktspeicher abgelegt (Artifactory, Nexus, Docker Registry, etc.) und von dort dann weiter auf die entsprechenden Umgebungen bis hin zur Produktion ausgerollt: „deployt“. Dort werden dann verschiedene Integrationstests, Ende-zu-Ende-Tests, Abnahmetests und so weiter ausgeführt.

Bei einer Codebasis, einer Anwendung, die gepflegt, weiterentwickelt und ausgeliefert wird, ist das easy. Die Buildnummer ist zentrale Wahrheit. Was aber wenn x Anwendungen entwickelt werden und in einem Ökosystem zusammenspielen müssen. Was bedeutet in diesem Kontext ein „neuer Build“? Anwendung-1 ist bei Build 6364 während Anwendung-12 erst bei Build 56 ist. Wie komme ich hier zu allgemeinen, automatisierten Testaussagen. Das behandeln wir mal in einem anderen Artikel.

Für unser einfaches Szenarion kommt jetzt wieder die manuelle Versionierung ins Spiel. Denn ich möchte meine neue Version nicht als 4711 veröffentlichen. Eine oft genutzte Eigenschaft meiner Schnittstelle stand in der letzten Version 1.2.3 noch zur Verfügung, ist aber jetzt nicht mehr dabei. Es ist Zeit für eine Version 2.0.0.

Wie benennen wir jetzt also den Build 4711 mit 2.0.0? Manuelles Ändern des Dateinamens? Sicher nicht. Aus meiner Sicht ist das Folgende am einfachsten: Wir nutzen Tags, falls uns VCS das hergibt (Git kann das natürlich).

Die Buildnummer ist nichts weiter als die fortlaufende Nummer der Pipelineausführung, durch die das Artefakt erzeugt wurde. Dieser Pipelinedurchlauf läuft auf einem bestimmten Codestand, der wiederum in einem Commit im VCS eindeutig enthalten ist.

Indem wir manuell einen Tag 2.0.0 auf diesen der Buildnummer 4711 eindeutig zugeordneten Commit setzen, lösen wir ein Event aus. Dieses Event triggert eine Pipeline, die nun das Artefakt nicht mit der Buildnummer, sondern der Tag-Bezeichnung versieht.

Jetzt ist es noch wichtig, die Artefakte vielleicht systematisch aufzuräumen, aber auch das ist ein Thema für einen weiteren Artikel.

Wirtschaftlicher Nutzen von CI/CD

Eine Antwort

Produktinnovation ist in einer digitalisierten Welt der Schlüssel zum Erfolg. Um sich vom Wettbewerb abzuheben, sollen Innovationen so rasch wie möglich und voll funktionsfähig an den Markt gebracht werden. Doch konventionelle Entwicklungsmethoden sind meist schwerfällig und bremsen die Time-to-Market. Um die Zeitspanne zwischen Entwicklung und Marktveröffentlichung zu verkürzen, sind in der Vergangenheit effektive Ansätze entwickelt worden.

Bei konventionellen Vorgehensweisen, vergehen teilweise Monate bis es zu einem Release kommt. Zunächst müssen alle Fehler behoben und Funktionen entwickelt bzw. erweitert werden. Erst danach folgt ein großes Update. Dabei werden beinahe alle Änderungen und Anpassungen manuell durchgeführt und der Prozess wird dementsprechend anfälliger für Fehler. Der gesamte Prozess ist wenig flexibel sorgt oftmals für komplexe Workarounds für die Entwickler.

Eine Lösung für dieses umständliche Vorgehen muss her. Ein lohnender Ansatz soll den Entwicklungsprozess von Software vereinfachen und zugleich beschleunigen: Das CI/CD.

Unterschied zwischen Continuous Integration (CI) und Continuous Delivery (CD)

Was ist also CI/CI? CI bzw. CD steht für Continuous Integration bzw. Continuous Delivery. Continuous Integration (CI) ermöglicht eine kontinuierliche Integration von neuem Code in ein gemeinsames Repository während Continuous Delivery (CD) für die Überführung des Codes von Repository in die Produktion zuständig ist.

Durch die Anwendung von CI/CD können sowohl die Fehlerquote als auch der Release-Zyklus minimiert werden. Im ersten Schritt, der Continuous Integration, testet der Entwickler den von ihm produzierten Teil des Codes bevor er ihn in das Controle-Repository übermittelt. Danach folgt meist eine neue Quellcode-Version, welche mittels Unit-Tests auf Fehler geprüft und in Testumgebungen eingefügt wird. Hier werden auch ganzheitliche Systemtests durchgeführt. Wenn der neue Teil des Codes erfolgreich alle Tests durchlaufen hat, wird das Team automatisch benachrichtigt. Zudem werden Informationen über die Anzahl der Tests und der gefundenen Fehler gesammelt.

Continuous Delivery (CD) setzt dort an, wo Continuous Integration endet. Bevor Software in die Produktionsumgebung übermittelt wird, werden Systemtests, Unit-Tests (inklusive API-Tests und Lasttests) und Integrationstests durchgeführt. Diese Tests sind allesamt Teil von Continuous Delivery und werden automatisch durchgeführt. Über den kompletten CI/CD-Prozess hinweg, können Fehlermeldungen rasch und direkt über Feedback-Kanäle an die Entwickler weitergeleitet werden.

Nachfolgend sind die relevantesten Vorteile von CI/CD aufgelistet, die letztlich in einer Kostensenkung resultieren.

  • Kleine Schritte: Statt große Teile des Codes auf einmal zu integrieren und in späterer Folge deren Fehler umständlich zu beheben, werden bei CI/CD mehrere kleinere Teile in das Repository eingefügt. Das Continuous Testing wird dadurch erleichtert, weil nur kleinere Stücke untersucht werden müssen und mögliche Probleme somit eher gefunden werden.
  • Kürzere Release Rates: Durch das rasche Erkennen und Beheben von Fehlern, können mehrere kleinere Code-Teile in kürzeren Abständen released werden. Dies ist allerdings nur möglich, wenn in einem kontinuierlichen Prozess entwickelt und der Code in einem releasefähigen Zustand gehalten wird.
  • Ordentlicher Backlog: Wird CI/CD in den Entwicklungsprozess integriert, so verändert sich die Fehlerquote im Backlog. Da kleinere Fehler rascher gefunden werden, kann sich das Team auf kritische Probleme konzentrieren.
  • Einfache Wartung: Mithilfe von Microservices können einzelne Bereiche eines Systems heruntergefahren werden ohne das restliche System betroffen ist. Somit können Wartungsarbeiten nahezu unbemerkt stattfinden.
  • Continuous Feedback: Durch die regelmäßige Integration des Codes, entsteht eine verlässliche und kontinuierliche Feedbackschleife. In dieser befinden sich vor allem Entwickler. Deren Rückmeldung zu Pipeline Build-Fehler, Merging-Problemen, Architektur-Rückschlägen usw. ist enorm wichtig für den gesamten Prozess.

Darauf sollte geachtet werden

Den Entwicklern soll die Arbeit mit dem CI/CD-Ansatz erleichtert werden, weshalb ein einfacher Prozessaufbau essentiell ist. Je weniger sie sich mit dem eigentlichen Prozess und manuellen Aufgaben aufhalten, desto effektiver kann gearbeitet werden. Zudem sollten Entwickler bis auf wenige Ausnahmen, direkt am Master-Branch arbeiten um eine sofortige Integration und das zugehörige Testen zu ermöglichen.

Wird CI/CD in den Entwicklungsprozess von Software integriert, so müssen automatisierte Tests auf allen Ebenen durchgeführt werden. Dies schließt mitunter Unit-, Integrations- und Systemtests ein, genauso wie automatisierte Tests für Funktionalität, Benutzerfreundlichkeit, Leistung, Last, Stress und Sicherheit durchgeführt werden müssen. Erst dann kann von CI/CD ganzheitlich profitiert werden.

Als nützliche Tools erweisen sich beispielsweise Repository-Management-Systeme wie Gitlab und Bitbucket oder Services für die Build-Automatisierung wie Jenkins oder eben auch Gitlab. Beispiele für die Testautomatisierung sind das Tool Katalon Studio oder jUnit in der Javawelt. Aber die Auswahl ist praktisch unendlich.

Fazit

Continuous Integration und Continuous Deployment zerstückeln den Entwicklungsprozess in kleine Teile. Diese Teile werden in regelmäßigen Abständen in ein gemeinsames Repository integriert und nach dem Testen dem Kunden rasch zur Verfügung gestellt. Sie sind ein zentrale Teil der DevOps-Methodik. Der gesamte Entwicklungsprozess wird übersichtlicher und flexibler, dadurch werden Fehler einfacher gefunden und behoben. Um mit der Konkurrenz mitzuhalten bzw. diese sogar zu übertreffen und unnötige Fehlersuche zu vermeiden, ist die Integration von CI/CD in den Entwicklungsprozess also eine einfache, effektive aber auch mittlerweile unverzichtbare Methode.

Entwickler schaffen sich ab: WebAssembly, jHipster und Low-Code – und das ist gut so

Schreibe eine Antwort

Wir machen uns überflüssig. Meine These: Und das ist gut so. Wir wollen es noch nicht wahr haben und genießen derzeit noch eine Art Schutzposition. Während es Mangel an IT-Kräften gibt und die Digitalisierung für viele Bereiche Stellenabbau bedeutet entwickeln sich die Technologien paradox. Paradox ist es aber nur auf den ersten Blick.
Die scheinbare Paradoxie: Entwickler werden durch ihre eigene Digitalisierung selbst von den Auswirkungen auf den minimierten Arbeitskräftebedarf betroffen sein. Nicht langfristig, sondern es steht kurz bevor! Wie kann das sein?

Entwickler sind derzeit noch in einer Position, dass die Digitalisierung so langsam akzeptiert ist, in manchen Bereichen bereits Fahrt aufnimmt, aber so richtig verankert in vielen Bereichen noch nicht ist. Auch mit dem Pandemieschub ist im Allgemeinen die Führungskraft abhängig von ihren Technologieberatern, meist Entwickler, die Aufgaben planen und Aufwände einschätzen. Überliche Muster dabei sind: Backendentwicklung ist sehr aufwändig im Vergleich zur Frontendentwicklung, native Appentwicklung ist keine einfache Webentwicklung und zu einem gegeben Design benötigt es grafikaffine Entwickler, die dies auch Umsetzen können. Die Entwicklung verrät dem Management natürlich nur zögerlich, dass diese Aufgaben heute zu einem Bruchteil des Aufwandes zu erledigen sind.
Die drei Kernbereiche, aus denen die Aufwände für die Entwicklung entstehen, sind kurz davor zu fallen.

Kernbereich 1: Backendentwicklung wird durch Standgeneratoren ersetzt

Die Backendentwicklung hat den Ruf, das eigentliche Feld des hochspezialisierten Entwicklers zu sein. Das ist historisch so gewachsen. Betriebssystementwicklung (Linux-Kernel, etc.), Algorithmenentwicklung (Facebook, Google) sind das Herzstück der jeweiligen Innovationen. Und in der Tat, überall dort, wo es viel neue Businesslogik zu entwickeln gibt, werden auch in Zukunft noch die spezialisierten Entwickler benötigt. Doch für die meisten Geschäftsmodelle gibt es heute Frameworks, die in dem Backendbereich eingesetzt wird. Dazu kommen Generatoren, wie jHipster, die nicht nur große Teile des Backends einfach auf Basis von standardisierten Diagrammen automatisiert erzeugen können. Auch Swagger geht nach dem Konzept „Interface-First“ vor. Gar nicht so unglaublich aber wahr: Eigentlich braucht man nur beschreiben, welche Daten ausgetauscht werden sollen und schon steht fast das gesamte Backend. Und das ist ein sinnvoller Fortschritt, der dort vollzogen wird. Warum sollen die immerselben Businesslogiken von der Backendtruppe immer wieder auf neue händisch eingetippt werden? Oder warum soll der Entwickler sich Stunden aufschreiben, in denen er eigentlich nur Altes kopiert und sich ansonsten auf die faule Haut legt?

Da wir bereits von Businesslogik sprechen, die früher üblicherweise im Backend angesiedelt war, so kommt der eine oder andere vielleicht auf die Idee, dass diese nun einfach in die Frontendentwicklung abwandert und dann eben dort stattfindet. Das ist nicht richtig. Sie wandert zwar im Zuge der ebenfalls richtigen Evolution von klassischen, serverabhängigen, mehrseitigen Anwendungen in richtung Singlepage-Application oder PWA (Progressive Web Apps) also Anwendungen, die eher unabhängig von einem Server funktionieren und deshalb viel Businesslogik in der Anwedung selbst und nicht im Server haben. Doch diese wird bereits von den entsprechenden Generator wie jHipster gleich mitgeneriert.

Kernbereich 2: Spezialisten für native Appentwicklung

Derzeit ist es sinnvoll für Innovationen, mit einem plattformunabhängigen Framework App für mobile Geräte zu entwickeln. Einfach weil es günstiger ist, gleich für mehrere Plattformen zu entwickeln. Besser und hochwertiger allerdings ist die native Entwicklung für jede Plattform im Speziellen. Also eigens für Apple (iOS) und eigens für Android. Dafür benötigt man spezielle Swift oder Java-Entwickler. WebAssambly ist die nächste Evolutionsstufe: So wie Website einfach von eine Domain geladen werden, können mit WebAssembly schon heute native Apps entwickelt werden, die nicht über einen AppStore geladen werden müssen, sondern einfach über eine Domain abgerufen werden können. Und diese werden, sobald es die entsprechenden Phones dafür gibt, gleichmaßen gut auf dem Phone, dem Tablet und dem Desktop laufen. Schnell, nativ entwickelt.

Kernbereich 3: Frontendentwickler ablösen

Zu meiner Anfangszeit gab es Microsoft Frontend. Wer mit diesem Tool glaubte, Webentwicklung betreiben zu können, wurde schnell eines besseren belehrt. Das Tool wurde praktisch zu einem Witz unter allen Menschen, die sich mit der Entwicklung von Software oder auch nur einfachen Webseiten im Web beschätigten. Auch andere Tools, die Frontends irgendwie grafisch entwickeln lassen wollten, erreicht nie den Wartbarkeits und Erweiterbarkeits und Sauberkeitsanspruch echter Softwareentwickler. Heute gibt es allerdings die ersten Tools, wie WebFlow, die einen Grafiker in die Lage versetzen, seine Designs quasi direkt in diesem Tool umzusetzen, mit den üblichen Werkzeugen, mit leicht ungewohnter Herangehensweise. Ist diese Herangehensweise in gewissen Blöcken zu denken, allerdings akzeptiert, so generiert der Design gleich das gesamt Frontend. Ein Entwickler stöpselt bloß noch die Details zusammen. So ein Tools ist beispielsweise WebFlow.

Was für den Entwickler bleibt ist Zusammenstöpseln: Das werden die Waldundwiesenentwickler übernehmen. Davon wird der Bedarf dann in Zukunft gewaltig abnehmen. Und neue Businesslogik für echte Innovationen wird weiterhin benötigt. Das wiederum werden die besten Spezialisten auf ihrem Gebiet ausführen.