» DieZehn: 10 Dos & Dont‘s agiler Softwareentwicklung bei komplexen fachlichen Anforderungen

DieZehn: 10 Dos & Dont‘s agiler Softwareentwicklung bei komplexen fachlichen Anforderungen

von | 23. Juni 2020 | Die Zehn, News und Events

Die Softwareentwicklung hat agile Projekte quasi erfunden. SCRUM, SCRUM-Master und Product Owner rücken immer stärker in den Vordergrund, Fortschritte werden in Sprints geplant, durchgeführt und getestet. Mit unserem heutigen Beitrag in der Reihe DieZehn, haben unsere Experten für Sie die zehn Dos and Dont’s agiler Softwareentwicklung insbesondere bei komplexen fachlichen Anforderungen zusammengefasst. Ob Experte für Softwareprojekte oder nicht, an dieser agilen Vorgehensweise kommen Sie zukünftig kaum vorbei, weil die Digitalisierung uns vor immer komplexere fachliche und organisatorische Anforderungen stellt. Spätestens beim Einsatz von Künstlicher Intelligenz und einer zunehmenden Vernetzung über die komplette Supply Chain hinweg, brauchen wir agile und strukturierte Prozesse in der Softwareentwicklung. Wie es funktioniert, erfahren Sie hier.

  1. Schreiben Sie kleine User Stories.

User Stories sind das wichtigste Werkzeug, um Projekte inhaltlich zu steuern. Sie erzählen Softwareentwicklern, was der Kunde braucht und warum. Kleine User Stories können präziser beschrieben und zielgerichteter umgesetzt werden. Auch der Aufwand lässt sich besser und zuverlässiger abschätzen. Darüber hinaus lassen sie sich gut in Sprints einplanen.

Große User Stories lassen sich schlecht einplanen – schlicht und einfach – weil sie nicht in Sprints passen. Mit einer großen Story gefährden Sie das Sprintziel, weil die User Story immer wieder in den nächsten Sprint übernommen werden muss. Große User Stories neigen außerdem zu unpräzisen (weil zu kurzen) oder überkomplizierten (weil zu langen) Beschreibungen und sind damit schwer umzusetzen.

  1. Schreiben Sie Epics.

Epics beschreiben den Kontext des Anforderungsmanagements und geben damit die grobe Richtung des Projekts vor. Jede Epic umfasst mehrere User Stories welche in mehreren Sprints eingeplant und umgesetzt werden. Verfallen Sie dabei deshalb nicht in Details. Dafür sind User Stories – bei Epics geht es um die Vision, das große Ganze! Wurde die gemeinsame Vision von allen verstanden, funktioniert die Umsetzung auch einfacher.

  1. Pflegen Sie das Product Backlog.

Das Product Backlog besteht aus geplanten User Stories und wird vom Product Owner verwaltet. Delegieren Sie das Schreiben und Verwalten von User Stories nicht. Nehmen Sie sich die Zeit, denn die User Stories im Product Backlog beschreiben die Zukunft Ihres Produktes. Gestalten Sie aktiv Ihr Produkt!

  1. Planen Sie mit Vorlauf und Feedback.

Planen Sie User Stories im Product Backlog mit großem Vorlauf und holen Sie sich dazu Feedback von allen Seiten ein. Neben den Entwicklern sollten auch die späteren Anwender mit einbezogen werden. Und: Vergessen Sie nicht die Stakeholder, denn diese entscheiden auch über den Erfolg Ihres Produktes.

  1. Machen Sie sich früh Gedanken über eine passende Architektur.

Architektur ist eine technische Domäne, die aber äußerst viel Einfluss auf die Kosten und den mittel- und langfristigen Erfolg hat. Daher sollten mindestens die folgenden, überwiegend nicht technischen, Fragen geklärt werden:

  • Wie wird das Produkt eingesetzt?
  • Was ist die Vision des Produktes?
  • Welche querschneidenden Aspekte gibt es?
  • Wie viele Nutzer sollen das Produkt anwenden?
  • Wie soll das Produkt wachsen und skalieren?
  • Für wie viele Jahre soll das Produkt existieren?
  • Wie wird das Produkt deployed?
  • Mit welchen Schnittstellen soll das Produkt arbeiten?
  • Welche Technologien sind verfügbar?

Berücksichtigen Sie bei der Beantwortung dieser Fragen auch immer die Vision und das Marktumfeld für das geplante Produkt. Nur so lässt sich eine passende Architektur planen.

  1. Schreiben Sie Tests.

Mit Tests, sind Unit Tests und End-to-End Tests gemeint. (Agile) Projekte verändern sich schnell und können daher leicht bestehende Funktionalitäten wieder verändern und beschädigen. Automatisieren Sie daher die Tests und lassen Sie diese bei jedem sogenannten „Build“ (Entwicklungsstufe) ausführen. Darüber hinaus sollten Sie Metriken wie z.B. die Test-Coverage (Testabdeckung zur Qualitätssicherung) erfassen.

7. Schreiben Sie Technische Schulden als „User Stories“ auf.

Sogenannte „Technische Schulden“ – mögliche Konsequenzen schlechter technischer Umsetzung – verlangsamen die mittel- und langfristige Entwicklung des Produkts. Sie sehen dabei immer nur die Spitze des Eisbergs. Wenn Sie sich keiner Technischen Schulden im Produkt bewusst sind, gibt es vermutlich sehr viele. Mit den Technischen Schulden steigen die Entwicklungskosten für weitere Entwicklungen bis zum Stillstand des Projekts. Arbeiten Sie Technischen Schulden daher zeitnah ab, in dem Sie sie beispielsweise in User-Stories aufnehmen.

  1. Aber: Sammeln Sie manchmal bewusst Technische Schulden an!

Das mag überraschend klingen, aber in der agilen Entwicklung ist es immer wieder notwendig „halbe“ Sachen zu machen, um User Stories klein zu halten und Konzepte zu erproben sowie allgemein schnell zu Wert und Feedback zu kommen. Im Unterschied zu Punkt 7 sind Sie sich der Technischen Schulden bewusst und können gezielt abwägen, ob die mittel- oder langfristig höheren Entwicklungskosten bis zur Behebung der Technischen Schulden es wert sind und den Entwicklungsprozess fördern.

  1. Versuchen Sie nicht, jedes Detail im Verlauf der Entwicklung zu steuern.

Wenn Sie mit einem guten Entwicklerteam arbeiten, wird es sich sehr selbstständig organisieren und auch hin und wieder eigenständig Entscheidungen treffen, die Sie überraschen werden. So sollte es sein! Nutzen Sie das Potenzial Ihres Teams und sollte der vom Team eingeschlagene Weg dann doch einmal deutlich von Ihren Vorstellungen abweichen, sprechen Sie dies offen an.

  1. Öffnen Sie sich gegenüber dem Projektteam und leben Sie selbst aktiv die Prinzipien der agilen Entwicklung.

Je mehr Sie Ihrem Team für Fragen und Diskussionen zur Verfügung stehen, desto eher können zuvor unentdeckte Probleme und Schwachstellen erkannt und behoben werden. Jedes Projekt kommt auf seinem Weg an Kreuzungen und Abzweigungen. Je gefestigter die Vision vom gemeinsamen Ziel in Ihrem Team ist, desto leichter fällt es, an diesen Abzweigungen zusammen die richtige Richtung einzuschlagen.

Jetzt liegt es an Ihnen. Starten Sie mit Ihrem Team agil durch. Halten Sie sich an unsere Dos und vermeiden Sie die Dont’s. Bei Fragen wenden Sie sich gerne an unsere Experten.

Unsere Experten

Petyo Gadzhanov
Fraunhofer-Institut für Materialfluss und Logistik IML
Michael Dominik Görtz
Fraunhofer-Institut für Materialfluss und Logistik IML
Max Günther
Fraunhofer-Institut für Materialfluss und Logistik IML

Diesen Beitrag teilen:

Auch interessant:

Multitalent als Studentische Hilfskraft gesucht!

An der Technischen Universität Dortmund ist an der Fakultät Maschinenbau an der Graduate School of Logistics zum nächstmöglichen Zeitpunkt die Stelle einer Studentischen Hilfskraft mit einer wöchentlichen Arbeitszeit von 14 Stunden zu besetzen. Du packst an? Du kannst...

Neues Stipendium: Instandhaltungsfreie Produktion

Promovieren in drei Jahren, an Fragestellungen aus der industriellen Praxis und in einem umfassenden wissenschaftlichen Netzwerk? Das geht – mit einem Stipendium in der Graduate School of Logistics (GSofLog) in Dortmund. Bewirb dich auf ein Stipendium und werde...

Herzlich willkommen an der GSofLog!

Tobias Rösner hat zum 1. September 2020 sein Stipendium in der Graduate School of Logistics gestartet. Nach seinem Master of Engineering an der Jade Hoschule, ging er in die Praxis zur Daimler AG in Böblingen und wagt nun den Schritt zurück in die Wissenschaft. Seine...