Wissen Sie wirklich schon ganz genau, was Sie brauchen? Oder ist es nicht eher so, dass wir die tatsächlichen Möglichkeiten, die sich für ein Projekt ergeben, oft erst später, im Verlauf des Softwareentwicklungsprozesses sehen?
Tatsächlich kennen wir meist alle Anforderungen erst ganz am Ende eines Projekts. Wenn man also das beste Ergebnis zu Projektstart noch nicht einschätzen kann, muss das Ergebnis variabel bleiben. Zeit und Kosten können dadurch im Gegenzug leichter fixiert werden. Wichtig sind viele kleine Iterationen aus Planung und Umsetzung und der rege Austausch über die bisherige Umsetzung zwischen Ihnen als Auftraggeber und uns als Umsetzende. Ganz nach unserem Motto: Gemeinsam besser.

Was sich nach einem Widerspruch anhört, ist bei weitem keiner. Agil bedeutet schließlich nicht kopflos und mit blindem Aktionismus einfach anzufangen. Im Gegenteil: Eine Idee für den nötigen Weg sowie eine Vision vom fertigen Produkt ist bei agilen Projekten besonders wichtig. Diese Vision kann sich jedoch mit der Zeit konkretisieren und, wenn nötig, auch verändern. Die beste Planung beruht auf den bisherigen Erfahrungen. Mit einem Burn-Up-Chart erhält man eine ehrliche Vorschau auf Basis des bisher zurückgelegten Wegs. Ziel ist es nicht, die Zukunft vorauszusagen, sondern rechtzeitig reagieren und nachjustieren zu können, um gemeinsam zum bestmöglichen Ergebnis zu kommen.

SE-icon

Sprechen Sie mich an für ein individuelles Angebot

Rolf Thoma

Media Engineer, Certified Scrum Master & Product Owner, UXQB Certified Professional für User Experience

Projektmanagement, Strategie

Kontaktieren Sie mich

Anforderungsanalyse

„Konsequente und methodische Anforderungsermittlung ist die Basis für ein qualitativ hochwertiges Produkt!“

Es gibt viele Faktoren, die über den Erfolg oder Misserfolg von Projekten entscheiden. Die Anforderungsanalyse ist eine Schlüsseldisziplin im Softwareentwicklungsprozess und bei der Entwicklung von Systemen. Dabei geht es nicht um eine effiziente Art der Verwaltung von Anforderungen, sondern um die bestmögliche Vorgehensweise zur Ermittlung von Anforderungen – häufig auch als Requirements Engineering bezeichnet. In der Praxis ist es nicht so einfach, die richtigen Anforderungen zu ermitteln. Und leider lässt sich die Frage nach den besten Konzepten und Techniken zur Ermittlung der relevanten Anforderungen nicht allgemeingültig beantworten. Es gibt nämlich oft unüberschaubar viele Einflussfaktoren die gleichzeitig berücksichtigt werden müssen. Ein guter Einstieg ist der Fokus auf die User (siehe dazu auch: https://www.mediendesign.de/user-research.html) In mehreren Schritten kommt man so schließlich zu den wichtigen Features, die in der Software umgesetzt werden sollen, man spricht auch von Feature Driven Development. Darüber hinaus müssen weitere technische Einflussfaktoren in der Anforderungsanalyse beachtet werden. z. B.

  • Software-architektonische Rahmenbedingungen wie Schnittstellen oder Bestandssysteme
  • Anforderungen der Betriebsumgebungen
  • Nicht-Funktionale Anforderungen wie z. B. Performance-Vorgaben, Anforderungen zur Barrierefreiheit,...

User Stories

User Stories sind eine bewährte und beliebte Möglichkeit um Anforderungen zu formulieren, denn die wichtigsten Fragen: Wer? Was? Warum? werden kompakt in einem einzigen Satz für alle verständlich formuliert:

"Als <ROLLE> möchte ich <FUNKTION> um <BEDÜRFNIS/WERT>"
z. B. Als "MITARBEITER IM KUNDENSERVICE" möchte ich "DIE PASSENDE BEDIENUNGSANLEITUNG ANGEZEIGT BEKOMMEN" um "DEM KUNDEN GENAU FÜR SEINE MASCHINE DIE PASSENDE HILFESTELLUNG GEBEN ZU KÖNNEN".

Für die konkrete Umsetzung in einem Softwareprojekt müssen natürlich mehr Details festgelegt werden. Das geht gut mit sogenannten Akzeptanzkriterien, die beschreiben, was erfüllt sein muss, damit eine  User Story erfolgreich abgschlossen ("done") ist. Sie werden zu jeder User Story formuliert und können später auch gut getestet werden. Auch hier hilft eine einheitliche Formulierung:

Gegeben <IST-ZUSTAND> Wenn <AKTION> dann <SOLL-ZUSTAND>
z. B. Gegeben "LISTE ALLER BEDIENUNGSANLEITUNGEN" Wenn "EINGABE IM SUCHFELD" dann "REDUZIERUNG DER LISTE AUF TREFFER"

Mit mehreren Akzeptanzkriterien und weiteren Informationen wird eine User Story nach und nach weiter verfeinert und beschrieben. Diesen Prozess bezeichnet man als Refinement. Am Ende des Refinements schätzt das Entwicklungsteam die Größe für die Umsetzung der User Story. Mit dieser Information kann anschließend die Priorisierung im Vergleich mit anderen geschätzten User Stories überdacht und angepasst werden. Anforderungen, die projektübergreifend für alle User Stories gelten sollen, werden nicht in jeder User Story wiederholt, sondern in einer übergreifenden DOD (Definition of Done) zusammengefasst. Diese enthält oft Vorgaben zu notwendigen Softwaretests, zum projektspezifischen Review-Prozess oder allgemeine Qualitätsanforderungen.

Für die Verwaltung aller User Stories eines Projekts verwenden wir das Tool Jira. Neben User Stories können auch Bugs oder kleinere Aufgaben als Jira Item angelegt werden und übersichtlich in verschiedene Sprints oder Releases gruppiert werden.

Mit dem Prinzip eines Minimum Viable Product (MVP) verfolgen wir das Ziel, möglichst früh und oft ein wertvolles Nutzerfeedback zu erhalten. Bei dem MVP handelt es sich um die allererste Version eines Produktes bzw. die minimale Dienstleistung, die für den Kunden von Wert ist und die dem Kunden so früh wie möglich zur Verfügung gestellt wird. So können wir schon während des Projekts zusammen mit unseren Kunden immer weiter dazulernen. Die neuen Erfahrungen fließen dann natürlich sofort in die Planung der nächsten Iterationen und in die Beschreibung der nächsten User Stories mit ein. Diese kleinen Kurskorrekturen schon während der Projektlaufzeit beugen größeren Fehlentwicklungen vor, die womöglich an den Anforderungen der Nutzer vorbeigehen würden.

Um ein MVP oder einen weiteren Zwischenstand zu testen, gibt es verschiedene Möglichkeiten. Ideal ist aus unserer Sicht immer ein Usability Test mit echten Nutzern. Unser UX Team hat dazu ein großes Repertoire an Usability Test Methoden (https://www.mediendesign.de/usability-test.html), um den passenden Test für die individuelle Situation zu finden. Aber auch schon ein ausführliches Review im Projektteam oder mit wichtigen Stakeholdern kann hilfreiche Erkenntnisse liefern.

Nicht jedes agile Softwareprojekt läuft gleich ab. Die eingesetzten Methoden müssen auf das Projekt abgestimmt werden. Oft kann dadurch ein spezifisches agiles Vorgehensmodell wie SCRUM nicht mit allen Details umgesetzt werden. Es gibt aber einige wichtige Methoden, die bei uns meistens zum Einsatz kommen, weil sie uns in bisherigen Projekten geholfen haben unsere Softwareentwicklung agiler zu machen.

CI/ CD

REFACTORING

PAIRPROGRAMMING

TDD

KANBAN

RETROSPEKTIVE

Continuous Integration & Continuous Deployment

Dem MVP Prinzip folgend, soll auch eine Software kontinuierlich zu lauffähigen Versionen mit neuen Funktionen zusammengeführt werden, um möglichst früh zu erkennen, ob die Neuerungen im Zusammenspiel mit der bisherigen Software funktionieren und um schnell mit potentiellen Nutzern testen zu können. Wir verwenden für unsere CI/CD Pipeline (siehe auch DevOps und Azure) aktuelle Softwarelösungen wie z. B. Bitbucket und GitLab mit TeamCity und SonarQube zur automatischen Codeanalyse.

Refactoring

Refactoring ist keine Schande, sondern Teil eines professionellen und kontinuierlichen Verbesserungsprozesses. Software sowie ihre verwendeten Programmiersprachen, Plattformen und Frameworks befinden sich in einer kontinuierlichen Weiterentwicklung. Um eine Software aktuell zu halten, müssen nicht nur Sicherheitsupdates eingespielt werden, sondern auch Programmteile immer wieder refactored, also überarbeitet werden.

Pairprogramming

Gemeinsam besser. Das ist nicht nur der Markenkern der mediendesign AG, sondern erklärt auch den Gedanken hinter einer etablierten Arbeitstechnik in der Softwareentwicklung. Beim Pairprogramming können durch den Austausch über mögliche Lösungsvarianten und das Vier-Augen-Prinzip schon während der Programmierung Fehler vermieden und schneller der beste Lösungsweg gefunden werden. Das führt zu einer deutlich verbesserten Softwarequalität.

Test Driven Development

Die im Vorfeld gemeinsam definierten Akzeptanzkriterien bieten eine gute Ausgangssituation für eine testgetriebene Entwicklung. Dabei wird der Test schon vor dem Quellcode geschrieben und dient somit während der gesamten Umsetzung als Orientierung. In Kombination mit automatisierten Tests erreichen wir so eine große Testabdeckung und damit eine hohe Softwarequalität.

Kanban Board

Auf einem Kanban Board werden die aktuellen Aufgaben und Unteraufgaben für das Entwicklungsteam visualisiert und nach ihrem Fortschritt strukturiert. Bei den täglichen Abstimmungsrunden kann so gezielt über die nächsten Schritte gesprochen werden und alle haben einen guten Überblick über den aktuellen Stand. Natürlich sind unsere Boards mittlerweile digital, z. B. in Jira oder Trello. Trotzdem arbeiten wir auch gerne mit Post-It und Whiteboard.

Retrospektive

Nicht nur digitale Produkte und Softwarelösungen unserer Kunden werden kontinuierlich verbessert, sondern auch unsere Arbeitsweise als Team. Dazu machen wir regelmäßig Retro-Meetings, in denen wir gemeinsam, vertrauensvoll und konstruktiv hinterfragen, wie wir unsere Zusammenarbeit verbessern können. Diese Selbstreflektion ist wichtiger Bestandteil unserer Arbeit, denn nur gute Teams können bessere Software entwickeln.

Ergänzend zu unserer täglichen Arbeit in internen und externen agilen und interdisziplinären Teams, sammeln wir unsere Erfahungen auch im Austausch mit anderen Unternehmen bei Schulungen und Fortbildungen.

Get in Touch

Ihr Ansprechpartner