Dr. Marcus Winteroll, oose Innovative Informatik GmbH am Swiss Requirements Day 2011
Die Erfahrung, Empirie soll für verbesserte Prozesse, den nächsten Release genutzt werden.
Was braucht der Kunde?
Es ist nicht realistisch, dass der Kunde beim Projektstart klare Vorstellungen aller Aspekte der Lösung hat.
Untersuchungen zeigen: 45% der Features von Software werden niemals genutzt, 19% werden kaum genutzt, 16% manchmal. Nur 20% werden oft oder immer genutzt.
Anforderungen können mit Tools wie Anwendungsfälle, User Stories, UML, atomare Anforderungen formulieren und in einem Product Backlog oder Lastenheft festhalten. Bei Änderungen gehen die Probleme los…
Ein stimmiges Gesamtbild entsteht meist nicht bottom-up aus guten Einzelteilen. Man macht sich eher zuerst ein grobes Gesamtbild. Es ist also zu klären: In welchem Zusammenhang stehen die Anforderungen? Wozu dienen sie?
Ãœberblick mit Storymaps
Die typische Herausforderung am Projektbeginn
Ausgangspunkt: Es gibt unterschiedliche Vorstellungen über die Ziele. Die zu unterstützenden Abläufe sind den Beteilgten nicht klar.
Der Weg: Gemeinsame Systemziele festlegen, z.B. mit Produktkartons mit wichtigsten Features auf beschränktem Platz. Zu unterstützende Abläufe gemeinsam beschreiben.
Das Ziel: Die Systemziele sind allen klar und werden von allen mitgetragen. Die Abläufe sind allen grob klar.
Die Geschichte hinter den Geschichten: Storymaps
Einzelne Anfroderungen werden ineinem Gesamtzusammenhang eingeordnet.
Die wesentliche Schritte des Geschäftsprozesses werden herausgearbeitet, auf Details wird verzichtet.
Es wird gemeinsam ein Verständnis der zu unterstützenden Abläufe erarbeitet.
Der Aufwand ist erheblich geringer als bei einer Geschäftsprozssanalyse
Das Vorgehen ist besonders für agiles Vorgehen geeignet
Beispiel einer Storymap
Der Ablauf von Tätigkeiten (Tasks gemäss Jeff Patton) wird gemeinsam gesammelt (rosa Felder). Die Geschäftsprozesse oder Features (Activities) können auch visualisiert werden (blaue Pakete).
Alternativszenarien werden unterhalb der ursprünglichen Tätigkeiten visualisiert. Details werden unterhalb angeordnet (gelb)
Kundenanfroderungen mit Releases empirisch ergründen
Eine Heizungssteuerung würde jedermann mit einer Rückmeldung koppeln wie Temperatur im Raum und allenfalls auch aussen.
Auch Software sollte man immer mit Rückmeldung umsetzen: Am Beginn des Projektes sind nie alle Anforderungen bekannt. Deshalb wird empfohlen, einen minimal marktfähigen Release einzusetzen, um möglichst schnell Feedback von Kunden am Markt zu erhalten. D.h. Konzentration auf das Wesentliche, dafür frühe Lieferung.
Beim iPhone wurde dies erfolgreich vorgemacht: Die erste Generation umfasste z.B. noch keine copy/paste-Funktion.
Aufteilen von Tätigkeiten
Notwendiges: Welche Teile einer Tätigkeit sind absolut unentbehrlich, damit die Lösung funktioniert?
Summary:
Einfach zu liefern, was der Kunde bestellt, ist kein Erfolgsrezept.
Den wahren Bedarf herauszuarbeiten ist eine Gemeinschaftsaufgabe.
Musmassungen über den wahren Bedarf sollten möglichst früh mit der Realität konfrontiert werden.
Die Erfahrungen der Nutzer sollten für die Weiterentwicklung eingesetzt werden.
http://twitter.com/#!/WalterSchaerer/status/83478009746690048