Leitfaden für die agile Methodik – Scrum-Teamrollen, agile Zeremonien, FAQs

Skip navigation

Was ist die agile Methodik?

Kernmerkmale von agiler Entwicklung sind die Steigerung der Zusammenarbeit, die Stärkung der Entwicklungsteams und die Transparenz des Entwicklungsprozesses. Obwohl jede Art von agiler Methodik anders ist, integriert jede die Elemente der iterativen Entwicklung und des kontinuierlichen Feedbacks bei der Erstellung einer Anwendung. Jedes agile Entwicklungsprojekt beinhaltet kontinuierliche Planung, Continuous Testing, Continuous Integration und andere Formen der kontinuierlichen Entwicklung.

Agile Intro Image

Die Rollen in einem Scrum-Projekt

  • Scrum Master

    Scrum Master

    Coach und Gatekeeper

    In seiner Doppelrolle als Coach und Gatekeeper ist der Scrum Master für die Einhaltung der Regeln des Agilen Frameworks verantwortlich. Dabei steht er dem Rest des Teams beratend zur Seite und stellt das notwendige Projektwissen bereit, während er gleichzeitig Hindernisse und Ablenkungen beseitigt. Der Scrum Master arbeitet direkt mit dem Product Owner zusammen, um gemeinsam zu entscheiden, welche User Stories in einem Sprint behandelt werden. Erfahren Sie hier mehr.

    Read more
  • Product Owner

    Product Owner

    Die Liaison

    Der Product Owner trägt die Verantwortung für den Erfolg des gesamten Teams. Er definiert die Projektziele und Aufgabenpakete und stellt sicher, dass diese auch vom gesamten Team verstanden werden. Außerdem erstellt, verwaltet und priorisiert er das Backlog von User Stories. In Abstimmung mit dem restlichen Scrum-Team weist er die Elemente mit der höchsten Priorität dem folgendem Sprint zu.

    Read more
  • Subject Matter Experts

    Subject Matter Experts

    Das Wissen

    Als Subject Matter Expert (SME) wird grundsätzlich jede Person bezeichnet, die die notwendigen Kenntnisse für eine erfolgreiche Produktauslieferung besitzt. Beispiele für SMEs sind der System-Administrator als Infra SME und ein UX-Experte als UX SME. Alle partizipierenden SMEs werden als Stakeholder des Projekts betrachtet, aber nicht alle Stakeholder sind auch SMEs. Außerdem ist ein Subject Matter Expert nie Teil des Scrum-Teams, auch wenn er immer zur Stelle ist, sobald dieses sein zusätzliches Expertenwissen benötigt.

    Read more
  • Business Owner

    Business Owner

    Der Umsatztreiber

    Der Business Owner ist sozusagen der Sponsor des Scrum-Teams. Er verlässt sich auf den Product Owner, dass dieser ein passendes und kompetentes Team für das Projekt bereitstellt. Der Business Owner tritt als Hauptakteur in Erscheinung. Er ist sowohl Sponsor der zu entwickelnden Applikation und definiert für den Product Owner die entsprechenden Geschäftsbedürfnisse, denen die Anwendung gerecht werden muss.

    Read more
  • Development team

    Entwickler-Team

    Die Schöpfer

    Hier handelt es sich um die Leute, die die Software tatsächlich entwickeln. Entwicklungs-Teams sollten relativ klein gehalten werden und umfassen typischerweise weniger als sieben Developer. Denken Sie darüber nach Business Developer in das Scrum-Team miteinzubeziehen. Dieser Schritt hilft dabei die Applikation so bereitzustellen, dass sie auch den tatsächlichen Geschäfts- und Kundenanforderungen entspricht und nicht nur den User Stories.

    Read more

Agile Zeremonien

Planung der Sprints

Ein Sprint ist die Grundeinheit bei der Entwicklung in Scrum. Die Sprint-Planung ist ein kollaborativer Prozess, an dem der Scrum Master, der Product Owner und das gesamte agile Entwicklungsteam beteiligt sind. Der Scrum Master unterstützt das Treffen, der Product Owner ist verantwortlich für die Klärung der Produkt-Backlog-Items und ihrer Akzeptanzkriterien, und das agile Entwicklungsteam definiert die Arbeit und den Aufwand, die zur Erfüllung der Sprint-Verpflichtung erforderlich sind.

Täglicher Stand-Up

Der tägliche Stand-Up ist ein wichtiger Teil des Kooperationsaspekts der agilen Entwicklung. Das gesamte Scrum-Team trifft sich täglich, um sich über den aktuellen Status des Projekts auszutauschen und Hindernisse zu identifizieren, die dem Abschluss des Sprints im Weg stehen. Das Team wird sich in der Regel das Burn-Down-Diagramm ansehen, das zeigt, wie viel der erforderlichen Arbeit schon erledigt wurde. Das Treffen findet im Stehen statt, um es kurz und bündig zu halten.

Sprint Review Meeting

Das Sprint Review Meeting findet am Ende des Sprints statt, damit das agile Entwicklungsteam die abgeschlossenen Arbeiten präsentieren und überprüfen kann. Dies ist eine Gelegenheit, einer breiteren Gruppe, einschließlich des Product Owners, des Managements und der Endnutzer, die verbesserte Version der Software zu präsentieren. Zusätzlich zur Bewertung des Projekts anhand der Sprint-Ziele kann die Gruppe Feedback über die aktuelle Lösung und die noch nicht erfüllten Bedürfnisse geben. Dieses Feedback fließt dann in das nächste Sprint-Planungsmeeting ein.

Retrospektive

Retrospektive Meetings finden in der Regel am Ende eines jeden Sprints oder am Ende eines großen Entwicklungszyklus statt und sind entscheidend, um die Kommunikation zwischen den Beteiligten zu starten. Während des retrospektiven Treffens sollte das Team reflektieren, was gut gelaufen ist und was in zukünftigen Sprints besser gemacht werden kann.

Die Vorteile der agilen Methodik in einer Low-Code Plattform

Transparency Icon

Transparenz

Die Plattform sollte ein zentraler Ort sein, an dem alle am Entwicklungsprozess Beteiligten sofort sehen können, wie weit die Anwendung ist und durch Kommentare und Stories ein besseres Verständnis von den Geschäftszielen und –anforderungen bekommen können. Die Verknüpfung von Stories und Kommentaren mit der zu entwickelnden Software bietet dem Empfänger und Prüfer den Kontext, der die Wahrscheinlichkeit von Missverständnissen und Fehlern reduziert und gleichzeitig alle Beteiligten produktiver macht.

Rapid Iteration Icon

Schnelle Iteration

Eine gemeinsame Sprache zwischen dem Entwicklungsteam und den Geschäftsbereichen ermöglicht das gegenseitige Verständnis und die Kommunikation zwischen allen Beteiligten sowie die Entwicklung einer Lösung, die sowohl den geschäftlichen als auch den technischen Anforderungen entspricht. Low-Code-Plattformen verwenden visuelle, modellgetriebene Entwicklungstechniken zur Definition von Benutzeroberflächen, Datenmodellen und der Logik einer Anwendung. Visuelle Modelle sind für das gesamte Team leicht verständlich und ermöglichen die kontinuierliche Zusammenarbeit zwischen Entwicklern und der Business-Abteilung.

User Feedback Icon

Nutzer-Feedback

Low-Code-Plattformen mit integrierten Feedback-Widgets ermöglichen es Nutzern, direkt in einer Anwendung Feedback zu geben. Ein geschlossener Feedback-Kreislauf ermöglicht es dem Entwicklungsteam, Anfragen aus dem Unternehmen schnell zu beantworten und eine hohe Iterationsrate zu gewährleisten. Außerdem kann die eingebaute App-Validierung mit sofortiger App-Sharing-Funktion die agile Zusammenarbeit verbessern. Darüber hinaus können Apps geräteübergreifend im Vorschaumodus angezeigt und anderen Nutzern freigegeben werden. So können Endanwender die App schon in einem frühen Status ausprobieren und kontinuierlich Feedback dazu geben.

Development Agility Icon

Entwicklungsagilität

Wenn agile Grundsätze in den Kern einer Low-Code-Plattform integriert sind, ermöglicht dies häufiges Feedback und Zusammenarbeit in Echtzeit. Mit der Erweiterung auf die Verantwortlichen der Geschäftsbereiche werden Feedbackschleifen deutlich reduziert, sodass das Team schneller Lösungen liefern kann, die sowohl die Nutzerbedürfnisse als auch die Geschäftsziele erfüllt.

Häufig gestellte Fragen

  • Wie unterstützt Low-Code die agile Softwareentwicklung?

    Low-Code-Entwicklungsplattformen wie Mendix passen sich gut an die agile Methodik an, indem sie Kollaborationswerkzeuge bereitstellen, die für aufeinanderfolgende schnelle Sprints geeignet sind. Mit der Sprintr-Funktion von Mendix sind Projektmanagement, Debugging und Feedbackschleifen so intuitiv wie nie zuvor.

    Lesen Sie hierzu auch: Wie Low-Code die agile Softwareentwicklung unterstützt

  • Was ist Scrum?

    Scrum gilt als eines der schlanksten Frameworks mit einer breiten Anwendungsbasis bezüglich des Managements und der Kontrolle iterativer und inkrementeller Projekte aller Art. Darüber hinaus gibt es noch zwei weitere bekannte und effiziente Frameworks für die agile App-Entwicklung: Kanban und Extreme Programming.

    Ein weiteres agiles Framework ist Extreme Programming, das sich vor allem auf die technischen Prinzipien konzentriert und die Bereitstellung hochwertiger Software verfolgt. Das Lösen von Programmieraufgaben steht hier im Vordergrund. Die Teams arbeiten in kurzen Entwicklungszyklen zusammen, sind somit flexibel und können sich schnell an Veränderungen anpassen. Die Methodik basiert auf der Verwendung von User Stories und häufigen, kleinen, geplanten Releases.

  • Welche weiteren Beispiele für agile Frameworks gibt es?

    Kanban konzentriert sich auf einen visualisierten Workflow, der aus kleinen, parallel verlaufenden Arbeitseinheiten besteht. Durch die Einhaltung klar definierter Projektgrenzen und expliziter Prozessrichtlinien, sowie der Messung und Steuerung von gleichmäßigen und kurzen Durchlaufzeiten, ist Kanban speziell darauf ausgerichtet, Engpässe und Ressourcenverschwendungen zu identifizieren und Wartezeiten zu verkürzen.

    Ein weiteres agiles Framework ist Extreme Programming, das sich vor allem auf die technischen Prinzipien konzentriert und die Bereitstellung hochwertiger Software verfolgt. Das Lösen von Programmieraufgaben steht hier im Vordergrund. Die Teams arbeiten in kurzen Entwicklungszyklen zusammen, sind somit flexibel und können sich schnell an Veränderungen anpassen. Die Methodik basiert auf der Verwendung von User Stories und häufigen, kleinen, geplanten Releases.

  • Was hat agile Entwicklung mit Design Thinking zu tun?

    Während es bei agiler Entwicklung um die Art und Weise der Softwareentwicklung geht, zielt Design Thinking darauf ab, ein Produkt so zu entwickeln, wie es der Kunde erwartet. Das Grundkonzept von Design Thinking besteht darin, zu überlegen was der Kunde wirklich möchte oder braucht und die Anforderungen von dort aus weiterzuentwickeln. Erfahren Sie, wie eine Reihe von IT-Abteilungen in Unternehmen agile Entwicklung zusammen mit Design Thinking nutzen, um die richtigen Probleme zu finden, die gelöst werden müssen.

  • Epics vs. Stories vs. Tasks

    Epics sind ganze Features und Funktionalitäten und können mehrere Sprints umfassen. Sie werden in Stories aufgeteilt und Stories können weiter in Tasks aufgeteilt werden. Ein Epic wird mehrere Stories haben, und jede Story kann mehrere Tasks haben. Während Epics mehrere Sprints umfassen können, sollten die Stories auf den jeweils aktuellen Sprint begrenzt werden. Stories sollten priorisiert und auf der Grundlage von Feedback von Stakeholdern erstellt werden. Bei der Erstellung von Stories sollte immer diese Vorlage verwendet werden: Als ein _ möchte ich _, sodass ich _ kann.

  • Ist agile Entwicklung nur für Innovationsprojekte geeignet?

    Agile Entwicklung wird nicht mehr nur für Innovationsprojekte eingesetzt, sondern ist zu einer etablierten Entwicklungsmethode für Unternehmensanwendungen geworden. Tatsächlich zeigt eine IDC-Studie, dass im Jahr 2016 48 Prozent der Unternehmen agile Entwicklungsmethoden nur für „Innovationsprojekte“ eingesetzt und nur 32 Prozent es als „primäre Entwicklungsmethode“ genutzt haben. Ein Jahr später haben bereits 45% der Unternehmen primär agile Entwicklungsmethoden eingesetzt.