BEYOND RE

Erstellt am 15 März 2019
von Schreibe einen Kommentar

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!

Die 3 größten User-Story-Mythen

Erstellt am 27 Februar 2019
von Schreibe einen Kommentar
User Story Mythen

In meiner Arbeit mit agilen Teams und als Trainer höre ich immer wieder Aussagen über User Stories, die von der ursprünglichen Intention abweichen und in der Praxis Probleme verursachen. Zeit, mit ein paar der häufigsten Mythen aufzuräumen.

Mythos #1: In Scrum wird eine Anforderung als User-Story dokumentiert.

Das kann man so machen, muss man aber nicht. Der Scrum Guide lässt völlig offen, wie Backlog Items zu dokumentieren sind. Ich persönlich mag User Stories, weil sie die Perspektive vom System auf den Nutzer verschieben. Aber vorgeschrieben ist das nicht.

Mythos #2: Wenn man User-Stories schreibt, dann muss man ein bestimmtes Template benutzen.

Wahrscheinlich denken Sie an: Als <Nutzer> möchte ich <Funktion> damit <Erfülltes Bedürfnis>.
Das Konzept der User Story hatte ursprünglich nichts mit diesem Template zu tun. Mike Cohn hat das Template dann später populär gemacht. Es ist genauso möglich, User Stories informell zu dokumentieren und auf das Template zu verzichten.

Mythos #3: User Stories werden mit Story Points geschätzt.

Als Scrum Master habe ich Teams beobachtet, die sich mit Diskussionen um Story Points, Schätzungen und Velocity verrückt gemacht haben.

Es gibt eine einfache Alternative. Das Team vereinbart kleine Stories. So 1-2 Umsetzungstage für das Team. Dann zählt es nach dem Sprint die Stories, die es fertiggestellt hat. Schon hat man die Velocity.


Sie sehen: Der Umgang mit User Stories ist in der Praxis gar nicht so schwierig. Wie setzen Sie User Stories in der Praxis ein? Ich freue mich über einen Kommentar!


Veranstaltungstipp

Die perfekte Gelegenheit zum weiteren Aufräumen der Mythen finden Sie in knapp zwei Wochen auf der REConf 2019 vom 11.-15. März in München.




RE – mit oder ohne agil?

Erstellt am 20 Februar 2019
von Schreibe einen Kommentar

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.

Stakeholder-Analyse in Entwicklungsprojekten

Erstellt am 22 Mai 2018
von Schreibe einen Kommentar

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.

Anforderungen strukturieren – 4. Das Informationsmodell

Erstellt am 25 April 2018
von Schreibe einen Kommentar
This entry is part 4 of 4 in the series Anforderungen strukturieren

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 

Ping-Pong ohne Pong

Erstellt am 7 September 2017
von Schreibe einen Kommentar
This entry is part 5 of 5 in the series Textuelle Anforderungen

Tischtennis oder Tennis sind in unserer Gesellschaft beliebte Spiele bzw. Disziplinen, an denen wir uns gerne messen und Spaß haben. Das Prinzip basiert darauf, dass jeder Spieler für sich seinen Schlag vorbereitet und ausführt (Ping). Der andere bekommt den Ball und reagiert in gleicher Weise wieder durch eine selbständige Vorbereitung und Ausführung des Gegenschlages (Pong).

In der Entwicklungsrealität haben wir dieses Prinzip in vielen Bereichen auch übernommen. Um dies näher zu beleuchten, zunächst ein Beispiel dazu.

Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 4 in the series Anforderungen strukturieren

Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?

UX == RE? – mit Gewinnspiel!

Erstellt am 27 Juni 2017
von Schreibe einen Kommentar

Ich möchte Ihnen heute einen Einblick in die Themen Usability und User Experience (UX) geben und aufzeigen, dass die Parallelen zum Requirements Engineering (RE) größer sind, als man auf den ersten Blick annehmen würde! Außerdem wartet ein Gewinnspiel auf Sie!

Anforderungen strukturieren – 2. Techniken

Erstellt am 26 April 2017
von 1 Komment
This entry is part 2 of 4 in the series Anforderungen strukturieren

Im letzten Blog „Anforderungen  strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“

Wie cool ist Requirements Engineering denn?

Erstellt am 15 Februar 2017
von Schreibe einen Kommentar

…wahrscheinlich nicht sooooo cool, zumindest bei meiner Tochter, denn die verbindet „Anforderungen“ eher mit Aussagen wie „Räum den Tisch ab!“ und „Räum dein Zimmer auf!“.

Doch welchen Stellenwert hat Requirements Engineering und der Umgang mit Anforderungen heutzutage im Umfeld der Software-, Produkt- und Dienstleistungsentwicklung?

Seit vielen Jahren geben wir Kurse für Requirements Engineering und Management. Vor einigen Jahren kamen dort interessierte Systemingenieure zu uns, die merkten, dass die Spezifikation „ihres“ Systems immer komplexer wird. Sie wollten wissen,