Ich stelle immer wieder fest, dass Projektleiter von Softwareprojekten dem Irrtum zum Opfer fallen, man könne einfach einen Softwareentwickler ins Projektteam packen und dann kommt Software heraus, die funktioniert, robust, erweiterbar ist und wartbar bleibt. Das ist nicht so. Robert C. Martin erklärt in verschiedenen Büchern, wieso das so ist.
Robert C. Martin, auch bekannt als „Uncle Bob“, ist ein bekannter Softwareentwickler und Autor, der vor allem durch sein Buch „Clean Code“ bekannt geworden ist. Martin hat eine klare Vorstellung davon, was er unter Softwareentwicklung versteht und wie sie richtig durchgeführt werden sollte.
Für Martin ist Softwareentwicklung der Prozess, bei dem wir Anforderungen an ein System in Form von Code umsetzen. Dieser Code sollte dann in der Lage sein, die Anforderungen des Systems zu erfüllen und zu einem späteren Zeitpunkt leicht wartbar und erweiterbar sein.
Martin betont die Bedeutung von Qualität in der Softwareentwicklung. Für ihn bedeutet dies, dass der Code einfach zu lesen und zu verstehen ist, gut strukturiert und modular aufgebaut ist und frei von Fehlern und Inkonsistenzen ist. Er glaubt, dass die Qualität des Codes direkt proportional zur Qualität und zur Wartbarkeit des Systems ist.
Ein wichtiger Aspekt der Softwareentwicklung, den Martin betont, ist die Kommunikation. Er betont die Bedeutung von klaren und präzisen Anforderungen und glaubt, dass effektive Kommunikation zwischen Entwicklern, Kunden und anderen Stakeholdern entscheidend für den Erfolg eines Projekts ist.
Martin ist auch ein Verfechter von professionellem Softwareengineering und glaubt, dass Softwareentwickler professionell ausgebildet und zertifiziert werden sollten. Er betont die Bedeutung von Prozessen und Methoden wie agile Methoden und Code-Reviews, die dazu beitragen, die Qualität des Codes zu verbessern und Fehler zu minimieren.
Schließlich betont Martin die Bedeutung von Weiterbildung und Lernen in der Softwareentwicklung. Er glaubt, dass es wichtig ist, sich ständig weiterzubilden und sich über neue Technologien und Entwicklungen auf dem Laufenden zu halten, um am Puls der Zeit zu bleiben und die bestmögliche Arbeit zu leisten.
Insgesamt versteht Martin unter Softwareentwicklung einen Prozess, der auf Qualität, Kommunikation, professionellem Softwareengineering und ständigem Lernen ausgerichtet ist. Er glaubt, dass diese Aspekte entscheidend sind, um erfolgreich Software zu entwickeln, die zuverlässig, wartbar und erweiterbar ist.
In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.
Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.
Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen
Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.
Halten Sie eine Besprechung vor der Besprechung ab
Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.
Was ist Backlog Grooming?
Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:
priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
Enthält eine aktuelle Schätzung für jedes Arbeitselement
Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.
Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)
Informieren Sie die Sprintplanung mit Daten
Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.
Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.
Aus Erfahrung
Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.
Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:
Feiertage, persönlicher Urlaub und teamweite Ereignisse
Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird
Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.
Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.
Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.
Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.
Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…
Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?
Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.
Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.
Auf die Plätze, fertig, Sprint!
An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.
Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.
Die Skalierbarkeit von Software ist ein wichtiges Thema, da sie dafür sorgt, dass ein System in der Lage ist, sich an die wachsenden Anforderungen anzupassen und auch bei hoher Nutzung stabil zu bleiben. Es gibt verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt.
Eine der wichtigsten Maßnahmen ist die Verwendung von modularen und wiederverwendbaren Komponenten. Indem man das System in kleine, wiederverwendbare Bausteine unterteilt, kann man es leichter warten und erweitern. Zudem ermöglicht es die Verwendung von Komponenten, das System leichter zu testen und zu debuggen.
Eine weitere wichtige Maßnahme ist die Verwendung von Caching. Caching beschleunigt das System, indem es häufig verwendete Daten und Ergebnisse zwischenspeichert, anstatt sie jedes Mal neu zu berechnen. Auf diese Weise kann das System schneller auf Anfragen reagieren und weniger Ressourcen verbrauchen.
Eine weitere Möglichkeit, das System skalierbar zu halten, ist die Verwendung von Microservices. Bei Microservices wird das System in kleine, unabhängige Dienste unterteilt, die einzeln entwickelt, getestet und bereitgestellt werden können. Dies ermöglicht es, das System leichter zu warten und zu erweitern, da man sich auf einen kleineren Teil des Systems konzentrieren kann.
Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist das Load Balancing. Beim Load Balancing werden Anfragen auf mehrere Server verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Load Balancing einsetzen kann, wie zum Beispiel das Round-Robin-Verfahren oder das Least-Connection-Verfahren.
Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist die Verwendung von Datenbank-Sharding. Bei Datenbank-Sharding werden die Daten auf mehrere Datenbanken verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Datenbank-Sharding einsetzen kann, wie zum Beispiel das Horizontal-Sharding, bei dem Daten nach bestimmten Schlüsselwerten auf verschiedene Datenbanken verteilt werden, oder das Vertical-Sharding, bei dem bestimmte Spalten auf verschiedene Datenbanken verteilt werden.
Eine weitere wichtige Maßnahme ist die Verwendung von geeigneten Tools und Technologien. Es ist wichtig, dass man für das System geeignete Tools und Technologien auswählt, die gut skalierbar sind und den Anforderungen des Systems entsprechen. Dies kann beispielsweise die Wahl eines geeigneten Datenbanksystems oder eines geeigneten Load Balancers sein.
Abschließend ist es wichtig, das System regelmäßig zu überwachen und zu optimieren. Durch die Überwachung des Systems kann man frühzeitig mögliche Probleme erkennen und entsprechend reagieren. Zudem kann man durch die regelmäßige Optimierung sicherstellen, dass das System stets auf dem neuesten Stand bleibt und gut skalierbar bleibt.
In Zusammenfassung gibt es verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt. Dazu gehören die Verwendung von modularen und wiederverwendbaren Komponenten, Caching, Microservices, Load Balancing, Datenbank-Sharding und die Verwendung von geeigneten Tools und Technologien. Auch die regelmäßige Überwachung und Optimierung des Systems sind wichtig, um sicherzustellen, dass das System gut skalierbar bleibt.
Viele glauben, dass eine Businesssoftware nur dann lohnenswert und wirklich „gut“ ist, wenn sie alle Geschäfts- oder Aufgabenbereiche abdecken kann. Sicher, ein Komplettpaket ist schnell eingerichtet und hat alles an Bord, was Sie brauchen – aber das macht es nicht automatisch zur Ideallösung. Tatsächlich sind spezialisierte Cloudanwendungen oft sinnvoller und schlichtweg besser. Die Gründe dafür lesen Sie im Folgenden.
1. Innovationen
Spezialisierung begünstigst Innovation. Ein Beispiel: Jira ist eine Projektmanagementanwendung aus dem Hause Atlassian, die ursprünglich zur Problembehandlung eingesetzt wurde. Mittlerweile hat sich die Spezialsoftware zu einer der erfolgreichsten Anwendungen auf dem Gebiet des Prozess- und Aufgabenmanagements entwickelt. Eine beliebte Alternative ist Microsoft Project, allerdings ist dieses an die Office Suite gebunden und damit weniger innovationsfreudig.
Wenn wir uns die globalen Google-Suchanfragen für Jira und MS Project in den letzten zwei Jahren ansehen, wird schnell ersichtlich, wer von den beiden buchstäblich gefragter ist:
2. Flexibilität
Eine Businesssoftware, die alles kann, klingt zunächst ja gar nicht so verkehrt. Die Frage ist aber: Wie flexibel sind Sie damit noch? Überlegen Sie sich gut, ob Sie sich dauerhaft an eine einzige Software binden möchten, denn dadurch machen Sie sich auch von deren Preisen und Leistungen abhängig.
Wieder das klassische Office-Beispiel: Wer sich die Office Suite von Microsoft zulegt, kauft automatisch auch Publisher und Access mit. Für diejenigen, die diese Tools gar nicht benötigen, lohnt sich der Kauf also nur teilweise. Ein anderes Problem ergibt sich, wenn Sie die Tools zwar nutzen, aber deren Funktionsumfang irgendwann nicht mehr ausreicht. Was passiert dann mit der Office Suite? Wenn Sie Word, Excel und Co weiterhin nutzen möchten, müssen Sie auch Access weiterzahlen – plus das Nachfolgertool.
Noch komplizierter wird die Angelegenheit, wenn die Software mehrere Geschäftsbereiche verknüpfen soll. Ohne Flexibilität werden Sie hier sehr schnell an finanzielle oder funktionelle Grenzen stoßen (ganz zu schweigen von dem Risiko, dass Sie all Ihre Prozesse von einem einzigen Anbieter abhängig machen).
Die Lösung? Nutzen Sie für jeden Bereich Ihrer Geschäftsplanung eine flexible Spezialsoftware. Anregungen und Beispiele wären:
Eine zentrale Philosophie aus der Softwareentwicklung ist die sogenannte KISS-Regel (engl. Keep it simple, stupid). Sie besagt, dass ein Problem immer so einfach wie möglich gelöst werden sollte, was im Kern der Aussage von Ockhams Rasiermesser ähnelt. Übertragen heißt das: Spezialisierte Cloudanwendungen werden Ihr Problem höchstwahrscheinlich einfacher lösen als eine komplette Suite für eintausend verschiedene Bereiche.
Investieren Sie lieber etwas Zeit in die richtige Wahl einer Spezialsoftware, als dass Sie sich einen Allrounder zulegen, dessen Funktionsumfang weit über das eigentliche Problem hinausgeht. Da Sie für all diese Funktionen bezahlen, ist eine Spezialsoftware (vor allem modular) in der Regel günstiger.
4. Benutzerfreundlichkeit
Unter Entwicklern und UX Designern gibt es eine Regel, die sich das „Prinzip der geringsten Überraschung“ nennt (engl. Rule of Least Surprise). Aus Nutzersicht ist damit gemeint, dass eine Software möglichst intuitiv gestaltet sein sollte und alle Buttons und Shortcuts genau das tun, was sie auch überall sonst tun.
Behalten Sie diese Regel im Hinterkopf, wenn Sie sich zwischen einer Business Suite und einer spezialisierten Anwendung entscheiden. Eine Suite ist grundsätzlich komplexer im Umfang und damit auch in der Bedienung. Erfahrungsgemäß ist die Lernkurve bei Spezialsoftware mäßiger, weil ihr Schwerpunkt auf einer guten Backend-Steuerung liegt.
Zusammenfassung
All-inclusive ist ein hervorragendes Konzept für den nächsten Urlaub, aber nicht beim Thema Businesssoftware. Bevor Sie sich also für eine Suite entscheiden, fragen Sie sich, ob Sie die Inhalte und Funktionen wirklich benötigen. Spezialisierte Cloudanwendungen sind schlanker, bedienungsfreundlicher und problemfokussierter, was sich letztendlich in einer besseren Preis-Leistung niederschlägt. Vor allem aber bleiben Sie damit flexibel – und das ist einer der wichtigsten Erfolgsfaktoren überhaupt.
Websites lassen sich heutzutage ohne eine einzige Codezeile entwickeln. Treiber dieser Nocode-Revolution sind sogenannte Baukastensysteme, die es Anwendern ermöglichen, Webseiten visuell über vorgefertigte Bausteine zusammenzustellen. Marktführer in dieser Branche ist das WordPress-Plugin Elementor – ein mächtiger Page-Builder, der professionelle Websites in Nullkommanichts aus dem Boden stampft. Wir erklären Ihnen, was Elementor alles kann und warum er auch für Softwareentwickler hilfreich ist.
Elementor: Grundlagen, Funktionen, Einsatzzwecke
Webbaukästen wie Elementor enthalten bereits eine grafische Oberfläche (GUI) sowie eine Reihe an Elementen und Vorlagen, um eine Webseite nach dem WYSIWYG-Prinzip zu bauen. Sprich: Bausteine und Inhalte werden direkt auf der Seite bearbeitet statt im Quellcode („Live Editing“). Elementor bietet dafür eine praktische Drag & Drop-Funktionalität, mit der das Anordnen und Anpassen der einzelnen Elemente zu einem Kinderspiel wird.
Eine Besonderheit von Elementor ist, dass der Page-Builder nicht nur statische Seiten, sondern auch dynamische Templates erstellen kann. Das beginnt bei der aktuellen Jahreszahl im Copyright-Hinweis und endet bei spezifischen Popups, wenn jemand auf ein bestimmtes Feld klickt. Außerdem liefert das Plugin ein eingebautes „Responsive Editing“, mit dem Sie Ihre Seiten und Elemente für verschiedene Auflösungen steuern können.
Wie unterscheiden sich die Free- und die Pro-Version?
Für Elementor-Starter dürfte sich zunächst die Frage stellen, ob die kostenlose Basisversion für die eigenen Zwecke ausreicht oder ob der Griff zur Pro-Version (ab 49 Dollar/Jahr) sinnvoll ist. Wie nicht anders zu erwarten, ist die Auswahl an Funktionen und Vorlagen in der kostenlosen Variante stark begrenzt. Die folgenden Punkte erläutern die wichtigsten Unterschiede:
Templates: Templates sind Design-Vorlagen für einzelne Seiten (z.B. Landing Pages oder Beiträge). Eine große Auswahl kann Ihnen hier nur die Pro-Version bieten.
Widgets: Elementor Free liefert um die 40 Basis-Widgets für einfache Websites. In der Pro-Version erhalten Sie dutzende weitere, darunter auch Theme-Elemente (für Header, Footer, 404-Seiten usw.) und Widgets für WooCommerce.
Kits: Elementor Kits sind Layout-Packs mit mehreren Templates für eine komplette Website. In der Basisversion können Sie zwischen fünf Kits wählen, während die Pro-Version über 100 Kits bereitstellt.
Dynamische Inhalte: Die bereits angesprochenen dynamischen Inhalte und Tags sind nur für Pro-Nutzer verfügbar.
Builder-Tools: Den Drag & Drop Builder können Sie in beiden Versionen nutzen. Weitere Builder wie den Theme Builder, Popup Builder oder WooCommerce Builder gibt es ausschließlich bei Elementor Pro.
Zusammenfassend lässt sich sagen: Für einfache, statische Seiten wird Ihnen die kostenlose Version genügen. Falls Sie jedoch komplexere Inhalte benötigen oder sogar ein Shopsystem mit WooCommerce planen, kommen Sie um die Pro-Version nicht herum.
Vorteile von Elementor in der Softwareentwicklung
Elementor oder Page Builder im Generellen sind in erster Linie für Personen gedacht, die keine oder wenige Programmierkenntnisse mitbringen. Doch selbst für versierte Web Developer bieten Nocode-Entwicklungsumgebungen große Vorteile, da sie den Webentwicklungsprozess deutlich beschleunigen. Vorgefertigte Bausteine sind schnell anpassbar und in der Anwendung oft sicherer und stabiler als neu programmierter Code. Da Elementor open source ist, können Sie das Plugin mit individuellen Add-ons erweitern, ohne den Aufwand einer kompletten Websiteerstellung zu haben oder andere Plugins hinzuziehen zu müssen. Die Vorteile von Elementor auf einen Blick:
Intuitive Bedienung dank des visuellen Frontend Editings (auch für Neulinge)
Erweiterbarkeit für Developer mithilfe des Theme Builders
Sehr viele Designeinstellungen und einfachste Bearbeitungsoptionen
Globale Widgets, die über mehrere Websites hinweg verwendet werden können
E-Commerce Integration sowie eingebaute Marketing-Tools
Große Developer-Community für zusätzliche Seitenvorlagen oder Add-ons
Zusammenfassung
Elementor ist ein hochfunktionaler Page-Builder für WordPress-Seiten, der mit rein visuellen Elementen statt Quellcode-Programmierung arbeitet. Für Entwickler bietet diese Nocode-Lösung erhebliche Zeit- und Ressourcenvorteile, da im Grunde nur noch die Feinheiten angepasst werden müssen – und selbst diese erfordern nur marginale bis gar keine Code-Skills.
Wer glaubt, dass sich damit nur einfachste Seiten bauen lassen, hat sich getäuscht: Elementor Pro liefert auch komplexe Webfunktionalitäten, sei es das Erstellen dynamischer Templates oder die Integration von WooCommerce-Elementen. Diese extrem hohe Flexibilität ist einer der Gründe, warum Elementor zu Recht der erfolgreichste und am häufigsten genutzte Page-Builder für WordPress ist.
Die Idee, dass wir nun alle Projektleiter mit No-Code-Werkzeugen ausstatten und statt Excel-Listen mit den Mitarbeitern zu pflegen, gleich Apps generieren, optimiert generiert für Dateneingabe, Statusrückmeldungen, Arbeitsnachweise, you name it, bereit für den Produktivbetrieb, muss leider ein Wunsch bleiben.
Realistisch ist: Durch No-Code und Low-Code rücken die fachlichen und nicht-funktionalen Anforderungen näher an die Umsetzung. Die Umsetzung kann effektiver agieren. Für wenig exotische bzw. wenig innovative Geschäftsprozesse werden nicht mehr unbedingt spezielle Programmierer benötigt. Sodass Informationen durch die Organisation hinweg schneller und zuverlässig auflaufen und gesammelt werden können.
Besonders Prozessverantwortliche in Projekten oder Abteilung einer Organisation durften häufiger das Bedürfnis haben, Abläufe direkter beeinflussen zu können, als ständig durch alle Phasen der Softwareentwicklung zu müssen. Ein Exceldokument hier, ein Abrechnungsbogen da und zu dem spezielle Anforderungen vom Kunden. Für diese Prozesse gleich eine Entwicklermannschaft zu beauftragen, ist mindestens aufwändig und immernoch keine schneller Prozess. In den wenigsten Fällen ist es überhaupt finanziell sinnvoll. Schön wäre es, wenn nichttechnisches Personal die Workflows zusammenklicken könnten, oder?
Dieses Versprechen macht uns Low-Code und No-Code.
Den Wunsch, dieses lästige „Programmieren“ klickbar zu machen und damit die Möglichkeiten, die Programmierern im Allgemeinen vorbehalten sind, allen zugänglich zu machen, gibt es schon seit je her. Und gute Entwickler arbeiten auch selbst daran, sich selbst überflüssig zu machen. Seit der Nutzen von Software für Unternehmen oder Privatpersonen klar wurde, ist das praktisch so.
Den Entwickler herausrationalisieren
Gleich zu Beginn von Internet und Hypertextdokumenten (HTML) gab es im Officepaket von Microsoft das zweifelhaft berühmt gewordeme „Frontpage“. Die Idee war damals schon klar: Lasst und das lästige Programmieren aus der Gleichung kürzen, damit jeder Webseiten bauen kann. Das hat nicht funktioniert, zu komplex die Aufgabe. Mit Internetdiensten, die den Desktopnanwendungen in Funktion und Bedienung immer ähnlicher wurden (heute Progressive Webapps, abgekürzt PWA), war schnell klar: Das ist kein Problem, was man durch Ziehen und Klicken lösen kann.
Die Software „WordPress“ füllt diese Lücke seit Jahrzehnten bestmöglich aus, was ihr Beliebtheitsgrade widerspiegelt. Kleine- und mittlere Unternehmen klicken sich aus unzähligen Plugins ihre Webprojekte zusammen. Längst nicht nur einfach Internetseiten, sondern rudimäntare Plattformen, Communities, Webshops, Terminabspracheformulare, Feedbackfunktionen und andere Webapplikation (ich denke, man darf sie so nennen) werden da zusammen geklickt. Sicherlich bereits die Anfänge von Low-Code und No-Code.
Ein Spaß ist das meistens jedoch auch nicht und längst vermisst der Enduser bei den Ergebnissen eine gewisse Beständigkeit, Robustheit und Sauberkeit. Die Eingabemasken zu Erstellung der Applikation enthalten jetzt natürlich die Komplexität, mit der normalerweise die Programmierer in ihrem Code umgehen müssen. Jetzt werden unzählige Entscheidungsbäume, Automatisierungsregeln, Datentypen und sonstige komplexe Aufgaben eben über eine entsprechende komplexe Eingabemaske gelöst.
Der klare Vorteil ist schonmal, dass nun keine eigene Sprache gelernt werden muss. Es ist also möglich, so zu gewünschten Ergebnissen zu kommen. Man wird weniger auf Softwareingenieure angewiesen sein. Irgendjemand – muss weiterhin sagen, wie das Zusammenspiel von verschiedenen Anwendungen ablaufen soll, worauf es beim Komponieren von Anwendungen ankommt, wo die Anwendungen im Gesamtunternehmen, im Gesamtprojekt einzuodnen sind. Doch sie werden nicht mehr ständig für die gesamten Phasen der Anwendungsentwicklung benötigt.
Interessant ist dieser Trend auf jeden Fall. Das größte Problem, was wir an unnötigen Overhead derzeit noch haben, ist, dass viele Prozesse von den Entwickler wieder und wieder neu entwickelt werden. Diese Arbeitszeitverschwendung könnte durch Low-Code und No-Code bald der Vergangenheit angehören. Denn komplizierte Datenbankgestaltungen könnten tatsächlich der Vergangenehit angehören.
Ingesamt kann also der Einsatz von No-Code dazu führen, dass ein Entwicklerteam innerhalb eines Projektes oder Unternehmens effizienter und schlanker wird. Auch wird es möglich, dass juniorigere Kollegen robustere Ergebnisse erzielen, da sie durch den No-Code-Ansatz nicht anders können, als bereits reife Arbeiten wiederzuverwenden und das Rad daher nicht immer wieder neu erfinden (wie sie es sonst tendenziell tun).
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.
Wir haben kein gutes kostenfreies Planning Poker für Remoteteams gefunden, daher haben wir selbst ein entwickelt. Auch im Businesskontext muss man nicht unbedingt für jede kleine Spielerei 9€ Abogebühr im Monat ausgeben.
Bei einem unserer anfangs eher improvisierten Sprintplannings im Homeoffice, war die erste klägliche Idee, „auf drei“ zu zählen und dann die Schätzung in den Chat zu tippen. Das war nicht die beste Idee. Also war ich auf der Suche nach einem kostenlosen online Planning-Poker-Tool oder Scrum Poker Online (Was ist Planning Poker). Ich benötigte ein vertrauensvolles, kostenfreies und am besten werbefreies Tool für unser Team. Eine Alternative zu den üblichen, mit Werbung überfrachteten, instabilen Freebies, die man sonst online so findet. Eine robuste, reife Open-Source-Lösung wäre ideal. Noch besser: Als SaaS-Variante.
Jetzt in diesem Coronazustand, in dem auch unsere Kunden vermehrt im Homeoffice in Deckung gehen, ist es eine zuverlässige Möglichkeit, uns in agilen Projektteams wie gewohnt selbst zu organisieren und effizient zu arbeiten. (Planning Poker ist nicht nur für das agile Projektmanagement geegnet.)
Die Kommunikation funktioniert mit den aktuellen Chat- und Videocallanwendungen wirklich gut. Aus dieser Situation heraus, wird das eigentlich erst richtig klar. Wir haben Slack und Microsoft Teams im Einsatz, je nach Projekt und Kunde.
Zuverlässige Software entwickeln können, deshalb haben wir selbst ein Tool entwickelt
Aus diesem Grunde haben wir uns über Ostern (2021) entschieden und ein Planning-Poker-Tool entwickelt. Es sollte vorerst nicht mehr und auch nicht weniger Funktion als gerade notwendig haben. Selbstverständlich haben wir natürlich auf Qualitätssicherung gesetzt.
Verfügbar zum gratis Losschätzen ist es auf https://agilecasino.kehrwasser.com. Wir verzichten auf eine Registrierung und es ist vollumfänglich kostenlos nutzbar.
Einfach Spielernamen eingeben und Raum erstellen oder mit bekannter Raumnummer einem bestehen Raum beitreten. Teamkollegen einladen und schon geht es im Multiplayerroom los.
