Was ist Empirisches Requirements Engineering?

Erstellt am 6 Februar 2019
von Schreibe einen Kommentar

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:

Innovation is what agile is all about.

Quelle: Embracing Agile, https://hbr.org/2016/05/embracing-agile

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.


Raus aus der Taylor-Wanne! Mit neuem Mindset Systeme entwickeln

Erstellt am 13 Februar 2018
von Schreibe einen Kommentar

Sie baden sich in Ihren Unternehmen noch immer in ausgefeilten Prozessen, blubbern in hierarchischen Strukturen und planschen in Reporting-, Monitoring-, Status- oder Eskalationsmeetings? Dann sitzen Sie immer noch in der Taylor-Wanne – OMG!

Im 19. Jahrhundert trug der US-Amerikaner Frederick W. Taylor mit seiner Prozesssteuerung durch Arbeitsteilung

Metriken erstellen – der langweiligste Job der Welt?

Erstellt am 23 Juni 2015
von Schreibe einen Kommentar

Kennen Sie auch folgendes Szenario: ÄnderungshäufigkeitDas Projekt startet, Sie bringen Struktur ins Projekt und die ersten Anforderungen werden geschrieben. Erst mal sieht alles gut aus. Im Laufe der Zeit nehmen die Anforderungen zu und damit das Arbeitspensum der Mitarbeiter, insbesondere durch weitere Projekte. Es herrscht Chaos. Ein möglicher Ausweg – den Projektfortschritt messen und beobachten.

Das Familienexperiment

Erstellt am 31 Dezember 2014
von Schreibe einen Kommentar

Die lieben KinderWeihnachtszeit ist Familienzeit und das ist auch ein schöner Brauch in unserer Familie. Jenseits der interessanten Kundenprojekte der letzten Monate, bleibt in den Tagen des Jahreswechsels vor allem Zeit zum Durchatmen und Erholen. So hatte ich viel mehr Gelegenheiten als sonst, meine Kinder anstatt meine Kunden zu beobachten. Die Analyse führte zu der Erkenntnis, dass bei einigen Erziehungsfragen eingegriffen werden muss. Und so war die Zeit für ein Experiment in unserer Familie gekommen.

Irrtum Nr. 9: Requirements Engineering in Projekten kostet nichts

Erstellt am 29 April 2014
von Schreibe einen Kommentar

Meine Kollegen Jens Donig und Frank Stöckel haben in ihrem Artikel Sieben Irrtümer bei der Einführung von Requirements Engineering die häufigsten Fehleinschätzungen bei der Einführung von RE beschrieben und haben dazu nochmals auf der REConf 2012 vorgetragen. Ein achter Irrtum in dem Vortrag war zu glauben, dass es nur sieben Irrtümer über die Einführung gäbe. Deshalb möchte ich daran anschließen und auf einen weiteren Irrtum Nr. 9 aufmerksam machen:

Requirements Engineering in Projekten kostet nichts!

Konsens oder Kompromiss? Eine Entscheidungshilfe

Erstellt am 11 Dezember 2013
von Schreibe einen Kommentar

Bei meiner Arbeit mit agilen Teams erlebe ich immer wieder heftige und langwierige Diskussionen, wenn eine gemeinsame Lösung gefunden werden soll bzw. eine Entscheidung getroffen werden muss. Das kann z.B. die Einigung über eine technische Umsetzung sein oder auch eine Übereinkunft über die Zusammenarbeit im Team. Um diese Diskussionen abzuschließen, kommt es häufig zu einer Abstimmung, wobei die Mehrheit dann „Recht“ hat. Dabei besteht die Gefahr, daß ein Teil des Teams offen oder versteckt in den Widerstand geht und die Entscheidung nicht mitträgt. Um das zu vermeiden, aber auch, um diesen Konflikten möglichst aus dem Weg zu gehen, wird versucht, es allen recht zu machen. Es wird ein Kompromiss gesucht.

Unschärfe zulassen, oder wie weit können Sie in die Zukunft schauen?

Erstellt am 24 September 2013
von Schreibe einen Kommentar

Am Anfang eines Projektes sind die Ziele und Anforderungen oft vage und unscharf formuliert, oder sie liegen noch gar nicht vor. Erschwerend kommt hinzu, dass Kunden häufig nicht in der Lage sind Ihre Wünsche und Vorstellungen zu formulieren, wenn Ihnen keine konkreten Beispiele (z.B. frühe Softwarereleases, Prototypen,…) vorliegen.

„Ein Plan ist nichts, Planung ist alles.“

Erstellt am 30 Juli 2013
von Schreibe einen Kommentar

So sagte Dwight D. Eisenhower. Gerade hatte ich meinen Projektplan aktualisiert, schon ruft mich – völlig unerwartet – mein Kollege an. Er müsse unbedingt noch diese Woche für sein parallel laufendes Projekt arbeiten und steht mir erst übernächste Woche wieder zur Verfügung. Kurz darauf erreicht mich mein Kunde und eröffnet mir, dass wir unsere Testphase zwei Wochen früher starten müssten. Der gerade aktualisierte Projektplan pulverisierte sich gerade vor meinem geistigen Auge.