Zwei Sätze an die KI, Minuten später läuft etwas Lauffähiges – und die Frage liegt nahe, wozu man überhaupt noch Anforderungen sauber aufschreiben soll. Die unbequeme Antwort: Wer die Anforderungsarbeit weglässt, automatisiert nicht das Denken, sondern das Am-Ziel-vorbei-Bauen. Nur schneller und in größerer Menge.
Vom 24. bis 27. Juli führte uns unsere diesjährige Sommerreise in die Schnitzmühle bei Viechtach – mitten in einer der schönsten Regionen des Bayerischen Waldes. Die Landschaft rund um den Schwarzen Regen wird liebevoll auch „Bayerisch Kanada“ genannt. Der Name kommt nicht von ungefähr: Dichte Wälder, beeindruckende Felsformationen, der ruhig dahinfließende Fluss und die unberührte Natur verleihen der Region eine ganz besondere Atmosphäre.
Schon bei der Ankunft war klar: An diesem Wochenende geht es nicht um Projekte, Termine oder To do Listen, sondern darum, gemeinsam Zeit zu verbringen, neue Energie zu tanken und den Alltag für ein paar Tage hinter uns zu lassen.
Weiterlesen„Als Nutzer möchte ich …” – die Schablone ist brav ausgefüllt, das Product Backlog ist voll, und trotzdem kommt aus der Entwicklung die Rückfrage: Was sollen wir hier eigentlich bauen? Der Grund ist unbequem: Eine formal perfekte User Story kann leer sein – und dieser Fehler fällt nicht im Refinement auf, sondern erst im Sprint.
Im Video zeigt dir Michael an einem durchgehenden Smart-Home-Beispiel, woran du eine gute User Story erkennst: die drei W-Fragen (Wer, Was, Wozu), warum der Wozu-Teil der wichtigste ist und trotzdem fast immer fehlt, was die sechs INVEST-Kriterien leisten – und wann das INV reicht – und wie Akzeptanzkriterien aus einer Story einen Abnahme-Anker machen.
Die Satzschablone für User Storys, die drei W-Fragen und alle Beispiele aus dem Video findest du vertieft in unserer kostenfreien Agilitätsbroschüre: https://sophist.de/5ajj
Noch mehr davon? Auf unserem YouTube-Kanal erscheint jede Woche ein neues Video zu Requirements Engineering, Systems Engineering und KI im RE – schau vorbei und lass gerne ein Abo da, dann verpasst du keines: SOPHIST GmbH
Attribute gefüllt, Status auf „geprüft”, Traces gezogen – und trotzdem kommen aus der Entwicklung dieselben Rückfragen wie vor der Tool-Einführung. Wer ein Requirements-Management-Tool einführt und erwartet, dass die Anforderungen dadurch besser werden, löst das falsche Problem: Ein Tool kennt den Zustand einer Anforderung, nicht ihre Qualität.
Viele denken bei Modellierung im Requirements Engineering sofort an UML, Diagramme, Symbole und Notationen. Doch echte Modellierung beginnt nicht erst beim Zeichnen, sondern bereits bei der Frage, welche Sicht auf die Realität ein Modell überhaupt zeigen soll.
Weiterlesen