Kennt Ihr die russischen Matroschka Puppen? Diese unterschiedlich großen, bemalten Holzpuppen stecken ineinander. Unter der ersten Puppe befindet sich eine zweite. Öffnen wir die zweite dann kommt ein drittes, noch kleineres Modell zum Vorschein. Diese Puppen stehen sinnbildlich für die Familie. Es gibt Vorfahren, Nachfahren und Mütter. Die Ahnen und ihre Vorgängerinnen sind elementarer Bestandteil ihres Seins. Damit stehen die Matroschka-Puppen für Tradition und Beständigkeit, sowie dafür, dass es immer weiter geht.
BEYOND RE – das war das Motto der gerade vergangenen REConf 2019. Es findet sich in den Matroschka Puppen wieder. Das „klassische Requirements Engineering“ ist die größte Puppe. „Beyond“, also wenn wir weiter gehen, kommen immer kleinere, schlankere, wendigere, iterativere Versionen zum Vorschein. Hinter RE ist also wieder RE, nur „kleiner“, „wendiger“, „leaner“, „agiler„, „digitaler“, „KI-iger“, „nicer“oder „kanbaniger“.
Um im Bild der Familie zu bleiben: Die Nachfahren profitieren von den Erfahrungen der Vorfahren. Neue Umstände, Zwänge und Nöte sorgen aber dafür, dass die Erfahrungen mit den neuen Herausforderungen in Einklang gebracht werden. Somit bleibt die nächste „Generation RE“ zukunftsfähig, auch wenn man das dann vielleicht gar nicht mehr „RE“ nennen will. „BEYOND RE“ steht dafür, dass sich das Anforderungsmanagement ständig an unsere disruptive, agile, dynamische Welt anpasst.
Die Keynotes der REConf, viele der Vorträge, die Sponsoren und Aussteller gingen in dieser Woche „Beyond RE“. Mit kreativen, innovativen, agilen und digitalen Ansätzen haben wir die eingetretenen Pfade verlassen. Das Motto für die REConf 2020 vom 22.-27.03. steht auch schon: „RE- Eine Frage der Kultur?“ Wir freuen uns auf ein Wiedersehen mit Euch!
Nun bin ich nun schon ein paar Monate als „HOODlerin“ unterwegs und habe viel über unsere Arbeit im Requirements Engineering und der Agilität erfahren. Heute widme ich mich der Frage, wie es ausschaut, wenn wir die beiden Disziplinen miteinander kombinieren. Was ändert sich also, wenn wir RE agil machten? Wird das Anforderungsmanagement besser oder „nur“ agil? Dazu habe ich meine Experten-Kollegen bei ihrer Arbeit beobachtet und befragt, und teile nun mein Ergebnis ganz unverholen mit euch.
Agilität mit Coach
Agil zu werden bedeutet, laut einer Definition, sich selbst in Frage zu stellen. Im RE geht es darum die richtigen Fragen zu stellen. Das gehört für mich jetzt erstmal nicht zwangsläufig zusammen. Weshalb Agilität in Unternehmen eingeführt wird, hat aber einen wirtschaftlichen Grund. Das Unternehmen kann sich im Ergebnis schneller und flexibler mit seinen Produkten und Dienstleistungen den Marktbedürfnissen anpassen.
Die Einführung agiler Arbeitsweisen geschieht oft durch Coaching der interdisziplinären Teams von außen. Das agile Coaching verbessert die Zusammenarbeit, die Kommunikation und gibt dem Team Methoden zur Hand, mit komplexen Aufgaben produktiv umzugehen. Gleichzeitig fördert der Coach auch ein neues, agiles Mindset in seinem Team: Regeln brechen, eigene Regeln aufstellen, ständiges Hinterfragen, freies Denken und natürlich auch freies Artikulieren der Gedanken sind dabei wichtige Bestandteile. Mit einem solchen Mindset können ganz neue Lösungen entstehen. Denn der Raum ist angstfrei und lebendig. Es herrscht Spaß und Veränderungsfreude. Die einstigen Probleme, die beispielsweise aus hierarchischen Strukturen, unzureichender Kommunikation, oder Angst, „sich zu weit aus dem Fenster zu lehnen“ stammen, werden an der Wurzel gepackt.
Mit diesem neuen Mindset ändert sich beispielsweise auch die Art mit Fehlern umzugehen. Sie werden als Chance, und damit als etwas Gutes, aus dem man lernen kann, betrachtet. Neben all den Vorteilen kann das neue Mindset allerdings im restlichen, noch nicht agilen Teil des Unternehmens, als Nachteil wahrgenommen werden: Die agilen Kollegen passen nun nicht mehr so recht in eine ansonsten hierarchische Unternehmensstruktur.
Requirements Engineering mit einem Consultant
Beim Requirements Engineering (RE) legen wir fest, welchen Anforderungen ein Produkt oder auch ein Prozess standhalten muss. Beispielsweise schaut man in der Software Entwicklung, welche Funktionen die Software in welcher Qualität haben soll. Was wünschen sich die Anwender und andere Stakeholder? Um das zu wissen, bindet man den Stakeholder früh und kontinuierlich in den Entwicklungsprozess ein. Im laufenden Prozess werden aus den anfänglichen Vermutungen der Entwickler klar dokumentierte Anforderungen. Die Chance steigt, dass die Software am Ende des Entwicklungsprozesses sowohl dem Anwender, also dem Auftraggeber, als auch dem Entwickler gefällt. Dadurch, dass die Anforderungen klar dokumentiert sind, sind alle Mitwirkenden im Bilde und Unstimmigkeiten werden schnell offensichtlich. In dem gesamten Prozess steht den Teams oft ein unterstützender externer RE Consultant zur Seite.
Anforderungen gut zu schreiben ist eine Kunst. Diese Kunst wird auch oft bei uns in den Trainings geübt. Anforderungen und Dokumentation müssen vollständig, prüfbar und widerspruchsfrei sein.
Daneben gilt es die richtigen Ermittlungstechniken wie bspw. Interviews, Fragebogen und Produktanalyse zu wählen. Passt alles, wird das Risiko für Fehlentwicklungen drastisch reduziert und führt im besten Fall, vorausgesetzt die Idee ist gut, zu einem guten Produkt.
Wie sieht nun die Mischung aus agil und RE aus?
Wenn man sich nun diese beiden Disziplinen Agile und RE ansieht ist es ganz klar: Wenn RE gut funktioniert, dann ist es wahrscheinlich meistens sogar schon agil. Es besteht ein offenes Klima, in der die Teams gut zusammenarbeiten. Denn das Geheimnis liegt, wie so oft, in der Kommunikation.
Beim agilen Arbeiten kommunizieren Entwickler- und das Anwenderteam kontinuierlich. Die Teams prüfen täglich, hinterfragen, testen, und werfen auch mal alles um, wenn das für ein besseres Ergebnis notwendig ist. Regeln sind da, um gebrochen zu werden. Dieser Spruch passt in diesem Kontext besser denn je. Die agile Vorgehensweise und das Mindset, das dies alles möglich macht, führt am Ende zu einem besseren Produkt und einer kürzeren Produktentwicklungszeit. Das ist schließlich wieder ganz im Sinne des Unternehmens.
Also einmal RE mit agil bitte!
Veranstaltungstipp
Die perfekte Gelegenheit zum Networken in der RE-Community bietet übrigens die REConf 2019 vom 11.-15.März in München. Komm vorbei. Ein Tag oder fünf, alles ist möglich.
Als Apple das iPhone 2007 veröffentlichte, löste es eine Revolution auf dem Mobilfunkmarkt aus. Steve Jobs wurde als innovatives Genie gefeiert.
Heute haben alle Smartphones Touchscreens. Damit kann man niemanden mehr begeistern. Innovation bedeuetet, am Puls der Zeit zu bleiben. Und ein Augenmerk auf die Kundenbedürfnisse zu haben.
Genau darum geht es in der agilen Entwicklung laut Jeff Sutherland, Vater von Scrum, dem erfolgreichsten agilen Framework:
Kern von Scrum ist die Entwicklung in Sprints von wenigen Wochen. Am Ende des Sprints steht ein „Produkt-Inkrement“. Zum Beispiel fertig entwickelte, getestete und dokumentierte Software.
So kann das Team regelmäßig Feedback einholen. Die wichtigsten Stakeholder sind die externen Kunden. Durch das Einarbeiten ihres Feedbacks maximiert man ihre Zufriedenheit.
Empirisches Requirements Engineering heißt: Das Team vereinbart erst am Anfang des Sprints die umzusetzenden Anforderungen. Basierend auf aktuellem Wissen.
Man versucht nicht, Entwicklungsumfänge Monate im Voraus detailliert zu planen. Fachkonzepte, Lastenhefte oder Pflichtenhefte sind passé.
Stattdessen akzeptiert man, dass Anforderungen veralten. Während der Entwicklung gewinnt das Team neue Erkenntnisse über Kundenbedürfnisse. Und über die technologische Umsetzung. Details von Anforderungen werden erst kurz vor der Umsetzung festgelegt.
Empirisches Requirements Engineering: Die 3 Planungsebenen
Heißt das, man muss jede Planung aufgeben, die über einen Zwei-Wochen-Horizont hinausgeht? Nein! Nur: je weiter man in die Zukunft plant, desto gröber wird die Planung. Dadurch wird die Planung robuster gegen Änderungen.
In der
Praxis haben sich drei Planungsebenen für ein Produkt bewährt:
Man muss das große Ganze im Blick behalten. Eine Produktvision ist der Nordstern für die Entwicklung. Sie adressiert die Kundenbedürfnisse und gibt die Richtung vor. Sie sorgt für Motivation, als Team an einem Strang zu ziehen.
Die Planung der Lieferung kann mehrere Sprints umfassen. In der Softwareentwicklung wird auch von Releaseplanung gesprochen. Wichtig ist, dass man auf Details der Anforderungen weitgehend verzichtet. Eine gut geeignete Praktik ist Story Mapping.
Die Planung des Sprints erfolgt in Scrum mit Hilfe der Backlogs. Das Team legt die Details der Anforderungen fest. Also zum Beispiel die Akzeptanzkriterien von User Stories. Auch während des Sprints kann das Team Anforderungen noch detaillieren.
Wenn Sie mehr über Empirisches RE wissen wollen, treffen wir uns im CARS-Kurs. Mehr zur Wandlung der Märkte lesen Sie in diesem Blogbeitrag.
Sie wollen fundiert, gleichzeitig tief ins Requirements Engineering einsteigen? Und das in kürzester Zeit? Oder einer Ihrer Kollegen? Dann gibt es dazu die ideale Gelegenheit auf der REConf in München: Starten Sie mit meinem neugestalteten RE-Einsteiger-Workshop „Anforderungen sind Kommunikation – RE Basics“ am 11.3.2019 nachmittags. Danach bieten sich Ihnen noch zwei weitere Tage, um hochkarätige Keynotes und Vorträge zu verschiedensten Themen des RE anzuhören, sowie sich mit Kollegen und Experten auszutauschen und zu vergnügen.
Die Stakeholder-Analyse bezeichnet die Identifikation der Projektteilnehmer, weiterer Personen und Institutionen, die ein Interesse an einem Entwicklungsgegenstand haben. Durch genaueres Untersuchen der Einstellung und Beziehung der Stakeholder zum Entwicklungsgegenstand bekommen die Projektverantwortlichen ein besseres Verständnis für die Erfolgsfaktoren des Entwicklungsgegenstandes.
Heute der 4. Teil der Serie „Anforderungen strukturieren“ mit der Frage: „Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?“. Im sogenannten Anforderungs-Informationsmodell wird definiert, welche
Entwicklung muss organisiert und strukturiert werden, das ist klar. Das V kann wohl als das Erfolgsmodell bezeichnet werden, um dieses zu tun. In Deutschland ist es aber nicht nur das standardisierte V Model XT des Bundes, es sind viele Variationen von V-Modellen, die für das Vorgehen in großen und kleinen Produktentwicklungen Pate standen.
In diesem und den nächsten zwei Blog’s beschäftige ich mich mit dem V-Modell. Zum einen wird das eine Basis für meinen REConf2019-Workshop „Daily Build@Hardware“ sein, zum anderen geht es mir auch um eine „Dekonstruktion“ des Models um die Sicht für grundsätzlich andere Vorgehensweisen zu öffnen. Im ersten Teil des Triablogs will ich erst mal die historischen Wurzeln mit einer Betrachtung der Evolution des V Models erläutern. Im zweiten Teil geht es dann um die verschiedenen Umsetzungssichten, hybride Ansätze und Erweiterungen, die zu einem agilen V-Modell führen. Der finale dritte Teil diskutiert alternative Ansätze, untersucht „Revolutionäres“ und „Disruptives“ und wirft einen Blick auf deren Tauglichkeit für die Produktentwicklung der Zukunft.
Beim RE kommt man nie umhin, auch über Anfragen für weitere Anforderungen zu sprechen. Hierbei geht es jedoch nicht um späte Anfragen für Änderungen nach einem Design-Freeze oder nach Serienreife, welche über ein Change-Control Board laufen, sondern um Anfragen, die bestenfalls bereits in einer frühen Entwicklungsphase berücksichtigt werden sollten. Warum ich heute über Kanban schreibe ist, dass diese Anfragen strukturiert, visualisiert, nachvollziehbar und transparent im Team dargestellt werden müssen. Hierfür eignet sich beispielsweise Kanban. Wie stellt man also sicher, dass Entwicklungsprojekte Anfragen von Kunden umfassend dokumentieren und umsetzen?
blog.hood-group.com nutzt Cookies, um den Traffic auf diese Website zu analysieren. Informationen zu Ihrer Nutzung unserer Website werden daher an Google übermittelt.OkDetails ansehen
