Inhalt : Agiles Requirements Management (Barcamp Stuttgart 2012)

Beim Barcamp Stuttgart am 22. September 2012 moderierte Andreas Birk eine Diskussionssession zum Thema "Agile Software Requirements". Diese Seite fasst die Ergebnisse dieser Session zusammen und gibt Fragestellungen und Erfahrungen mit agilen Requirements wieder. Sie ergänzt eine ähnliche Session-Zusammenfassung vom Barcamp Karlsruhe 2012.

Diskutiert wurden die folgenden Fragen. Nach den Fragen, die näher diskutiert wurden, sind die Antworten aufgelistet:

Wie bepreise ich ein agiles Projekt? (speziell: in der Auftragsentwicklung)

keine weitere Diskussion dieser Frage

Wie mache ich einen Entwicklungsauftrag agil?

Wie stelle ich fest, wie gut ein Auftrag für agile Entwicklung geeignet ist?

Was kann ich tun, um einen Auftrag

• Statt Werksvertrag einen Dienstvertrag abschließen
• Gleichzeitig dem Auftraggeber einen konkreten Nutzen aus der Entwicklungsleistung zusichern (siehe Value und Vision in der agilen Entwicklung)
• Projekt so auslegen, dass schnell erstes Ergebnis (siehe: Minimal Viable Product in der agilen Entwicklung)

SCRUMBAN: Welcher agilen Methode folgen wir eigentlich?

Anmerkung: Scrum und KANBAN sind sehr verbreitete agile Methoden; SCRUMBAN ist eine Kombination dieser Methoden

• Die konkrete Form der Vorgehensweise den jeweiligen Erfordernissen und Rahmenbedingungen im Projekt anpassen
• Im Verlauf des Projektes die agilen Instrumente zur kontinuierlichen Verbesserung nutzen (v.a. Iteration Retrospectives), um das Vorgehen schrittweise immer mehr zu optimieren und auch an sich wandelnde Rahmensituationen anzupassen

Toolunterstützung für agile Software-Entwicklung?

• Erst die Vorgehensweise auswählen und gestalten, dann das Tool passend auswählen und anpassen
• Vorgehensweise und Tool zügig nach kurzer Abwägung auswählen und beginnen konkrete Erfahrung damit zu gewinnen; durch die agilen Feedback-Mechanismen bald Erfahrungen auswerten und Vorgehensweise und Toolentscheidung weiter entwickeln
• Toolunterstützung immer wichtiger, je größer und komplexer das Projekt und sein Umfeld werden (z.B. kleine lokale Teams arbeiten oft sehr gut mit physischen Scrum-Boards, verteilte Entwicklung erfordert sehr wahrscheinlich Toolunterstützung)
• Toolunterstützung für verteilte Entwicklung kann auch aus Videoconferencing und Collaborationtools bestehen
• Beachten, dass auch die Kundenvertreter im Projektumfeld Zugang auf Projektplanung und -status sowie auf die betreffenden Tools benötigen; mitunter verschiedene Sichten auf die Projektinformationen für Kunden und für Entwicklungsteam anbieten

Problem Space versus Solution Space

Anmerkungen: Anforderungen können sich auf den Problemraum beziehen oder auf den Lösungsraum; oft besteht die Neigung, mit den Requirements (zu früh) eine bestimmte Lösung zu implizieren und somit ungewollt andere, möglicherweise noch bessere Lösungen auszuschließen

• Agile Requirements (z.B. User Stories) klar auf den Lösungsraum beziehen

Physisches Board versus Tool?

• Entscheidung wird vom Team getroffen
• Was funktioniert und sich bewährt, das ist auch erlaubt
• Bei Bedarf kann die Entscheidung revidiert werden
• Es gibt auch Verfahren, mit denen physisches Board und Tool gleichzeitig eingesetzt werden

Weitere Erfahrungen und Ideen:

• MindMap als Startpunkt für die Auftragsgestaltung einsetzen; das leichtgewichtige MindMapping-Verfahren kommt der agilen Entwicklung entgegen
• Die Rolles des "Product Owners" und wie man sie ausgestaltet hat eine große Bedeutung dafür, wie gut ein Projekt mit den Requirements umgehen kann
• Jedes Team soll sein eigenes agiles Vorgehen gestalten und mithilfe der agilen Instrumente kontinuierlich weiter entwickeln
• User Journeys können bei Bedarf User Stories detaillieren; dabei ist eine User Journey eine konkrete Beschreibung der Interaktion eines Benutzers mit dem zu entwickelnden System
• Auch Akzeptanztests können User Stories detaillieren; sie erfüllen zudem ihre wichtige Rolle bei der Entwicklung (automatisierte Akzeptanztests und Acceptance Test Driven Development als Feedback-Instrument für die Entwickler) und bei der Abnahme der Iterationsergebnisse durch die Kunden, Auftraggeber bzw. Product Owner