Requirements sollen festlegen, was im (Software)-Projekt umgesetzt werden muss. In klassischen Projekten gibt es Requirements-Dokumentation zumeist in Form eines Pflichtenheftes; wenn nicht, muss ein Vor-Auftrag diese zumindest ansatzweise erfassen.Wobei Kunden manchmal nicht einsehen, dass diese „Akquise“-Tätigkeiten Geld kosten, weswegen man geneigt ist, auf die Erfassung der Anforderungen zu verzichten.
In diese Bresche schlagen dann die in definierten Zyklen arbeitenden agilen Prozesse – diese tauschen den Begriff „Requirement“ gegen „Story“, und geben den Projektbeteiligten die Möglichkeit diese zu Beginn eines jeden Entwicklungszyklus zu definieren.
Wir bei CosmoCode haben leider nur selten Kunden, die sich auf einen agilen Prozess einlassen und brav jede Stunde, die gearbeitet wird, bezahlen. Die meisten Kunden wollen vor dem Auftrag eine gewisse Garantie „Leistung gegen Geld“. Umsetzen kann man das dann gerne im agilen Prozess.
An dieser Stelle passiert häufig folgendes: Die Leistungen werden vorab nicht sauber definiert (man arbeitet ja agil), sondern bestenfalls stichpunktartig festgelegt. Das Budget wird gedeckelt, und man gibt sich auf die agile Reise. Der Kunde konkretisiert die Anforderungen im Projektprozess – oder auch nicht; irgendwann stellt man fest: das Geld ist alle, die Lösung noch nicht fertig.
Der agile Prozess sichert einem zumindest zu, nach jedem Zyklus ein Schritt weiter gekommen zu sein – ob der Prozess aber gegen die Zeit-, Funktions- und Bugdet-Koordinaten konvergiert, ist … zwar nicht Glückssache, aber häufig nicht wirklich steuerbar.
Soweit, so schlimm – doch wie geht man damit um?
- Man sucht sich Kunden, die den agilen Prozess komplett durchfinanzieren.
- Man definiert die Anforderungen vor dem agilen Prozess.
Die unter 1) benannten Kunden sind leider eine äußerst knappe Ressource, weswegen es Sinn macht, in den sauren Apfel zu beißen und die Requirements vorab abzustecken – und im Projektverlauf zu konkretisieren.
Im sprintDoc Projekt befassen wir uns auch mit der Requirements-Dokumentation, und eine grundlegende Frage ist eben: Unterscheiden sich Stories und Requirements, oder ist dasselbe?
Meine Position dazu ist:
- Requirements werden in der Anforderungsanalyse ermittelt und sind Basis unserer Angebote. Noch präziser: Die Requirements sind die Leistungsbausteine der Angebote. Die Summe der Aufwände der Requirements/Leistungsbausteine ergibt das Projektgesamtvolumen.
- Bei Projektende werden die Requirements für die Abnahmetests verwendet.
- Stories werden im agilen Prozess nach Bedarf erzeugt.
Wie Requirements und Stories zusammenhängen
Um ein Aufwandscontrolling im agilen Prozess durchführen zu können, muss geprüft werden ob die geschätzten Aufwände der Requirements mit den tatsächlichen Aufwänden übereinstimmen (Okay, dies tun sie nie. Aber ein Frühwarnsystem bei Überschreitung wäre doch schön, oder?).
Das bedeutet, das alle Stories (Issues) einem Requirement zugewiesen sein sollten.
Wie man Requirements-Dokumentation in JIRA macht.
In JIRA gibts hierfür schon ein prima Werkzeug: die Epics.
Wir schlagen vor:
- Alle Anforderungen/Requirements vorab konzipieren und mit Abnahmekriterien versehen
- Für jedes Requirement ein Epic in Jira anlegen
- Alle Issues im agilen Prozess Epics zuweisen (Kann man das nicht: siehe unten)
- Sukzessive prüfen, ob Requirements erfüllt ist, ob Aufwandslimits erreicht sind.
Kann man ein Issue keinem Requirement zuordnen, hat man entweder einen Change Request („Hallo Kunde, wir müssen übers Geld reden“), oder einen Fehler in der Anforderungsanalyse gemacht, was ja zumindest als Learning verbucht werden kann.