Wie werden in Ihrer Firma Anforderungen ermittelt? Ist da von Masken, Feldern, Datenbankspalten und Algorithmen die Rede? Oder von Kundenvorteil, neuen Fähigkeiten für den Kunden und Ergebnissen einer Interaktion des Users mit dem System?

Meine Empfehlung: Versetzen Sie sich in die Lage eines echten Benutzers und denken Sie dann erst darüber nach, was Ihre Software für ihn tun kann. Arbeiten Sie heraus, wer dieser Benutzer ist, seine „Persona“:

  • Wie alt ist er wohl?
  • Welche Fähigkeiten oder Ausbildung hat er schon?
  • Welche Werkzeuge benutzt er sonst noch für seine Arbeit?
  • Mit wie vielen Leuten arbeitet er zusammen?
  • Wie oft braucht er Ergebnisse?
  • Was will seine Chefin oder was wollen seine Kollegen von ihm?

Stellen Sie sich ihre typischen Personae mal vor und entwerfen Sie einen Steckbrief für jede Persona. Erfinden Sie…

  • Name
  • Geschlecht
  • Beruf
  • Alter
  • Arbeitszeiten
  • Arbeitsorte/-plätze
  • Bedürfnisse
  • Hobbies
  • Beziehungen zu anderen Personae

usw. usw.  — was auch immer Sie brauchen, um sich wirklich vorzustellen, für wen Sie eigentlich die Software entwickeln. Und dann fällt es Ihnen plötzlich ganz leicht, deren Verhalten im Umgang mit der Software aufzuschreiben, in Form von Szenarios:

  • GEGEBEN: eine bestimmte Grundsituation, in der die Persona vor der Arbeit mit Ihrem System steckt oder eine Menge von früheren Ergebnissen, die die Persona bereits in der Hand hält
  • WENN: ein bestimmtes Ereignis auftritt, das Vorgänge in Ihrer Software auslöst
  • DANN: die Menge von Ergebnissen, die Ihr System der Persona liefern muss, damit sie das Gefühl hat, einen Fortschritt erreicht zu haben.

Schreiben Sie Szenarios auf Karteikarten und ordnen Sie sie an der Wand, z.B. nach Persona und nach derjenigen User Story, die in dem Szenario ausgeführt wird. Bilden Sie dann Pakete von Szenarios und geben Sie sie in die Entwicklung und den Test. Besser noch: Lassen Sie Entwickler und Tester gleich an der Erarbeitung der Szenarios mitmachen und Ideen liefern. Das reduziert Kommunikationsaufwand und öffnet den Blick für mehr Ideen. (Das Ganze nennt man nebenbei „behaviour driven development“.)

Viel Erfolg!

, Agile Entwicklung , Produkt und Business