Auf LinkedIn hat mich (wohl aufgrund unserer agilen Projektmanagement-Angebote auf LinkedIn Learning) eine Frage erreicht:

„Was sind mögliche Requirements der Kunden?“ – also nicht allgemein, sondern im agilen Umfeld. Ich wurde um ein, zwei Stichworte gebeten.

Hier nun meine Antwort:

Also ganz ohne Kontext ist eine solche Frage nur schwer zu beantworten, da muss ich auf die Metaebene ausweichen:

Der Kunde benötigt frühzeitig erste Ergebnisse um zu Lernen und Feedback geben zu können.

Es gibt ein paar Voraussetzungen, die dafür erforderlich sind und die allzu leicht übersehen werden:

• Die Requirements/Backlog Items/Users Stories müssen „schneidbar“/modularisierbar sein (historisch war ja auch die modularisierte Webentwicklung eine der Turbostränge des agilen Projektmanagements).
• Entsprechend ist die Skalierbarkeit des Projekts/der Lösung häufig ein Problem. Es gibt zwar auch hoch skalierte Formen agilen Projektmanagements, ob diese aber immer den Namen „agil“ verdienen darf bezweifelt werden.

Wenn ich über meine Antwort von heute morgen noch weiter nachdenke, dann könnte man auch noch Voraussetzungen für die Zusammenarbeit im Sinne des Mindset des agilen Manifests anführen, aber da verlassen wir die Anforderungsebene noch mehr.

Wem weitere Aspekte dazu einfallen, der ist herzlich eingeladen die Kommentarfunktion zu nutzen.

Und was unsere agilen Projektmanagement-Trainings angeht: Der agile Lernpfad hat jetzt auch ein Prequel zum Berufsbild bekommen. Diesmal mit unserem Daniel im Lead, analog zum Prequel im allgemeinen PM-Lernpfad.

Im „allgemeinen“ Lernpfad finden übrigens agile, wie traditionelle Ansätze gleichermaßen Berücksichtigung. Der allgemeine Lernpfad „Projektmanager:in werden“ ist übrigens auch das von Microsoft für alle kostenlos frei zugänglich geschaltete Kursangebot – also auch ohne LinkedIn Premium Account.

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.

Der ursprüngliche Post stammt aus dem Jahr 2017.

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.