Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 3 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?

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des „systematischen Umgangs mit Anforderungen“, dies ist eine moderne Übersetzung des englischen Begriffs „Requirements Engineering and Management“, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es „unmotivierter Mehraufwand“ oder „Overhead für Dokumentation“, für manche agile Teams ist es „alter Hut“ und für erfahrene, gewachsene Fachabteilungen ist es „nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht“.

Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.

Eigentlich fast fertig? Die Definition of Done!

Erstellt am 17 Mai 2016
von Schreibe einen Kommentar
Definition of Almost Done

Definition of Almost Done

Es ist Freitag Vormittag, 09:00 Uhr; Zeit für unser Daily. Ein Kollege zeigt auf das Taskboard und sagt “Diese User Story ist eigentlich fertig und kann in unsere Done-Spalte gehängt werden”. Wörter, wie “eigentlich” oder „fast“ machen mich stutzig und ich kann nicht anders als nachzufragen, ob die Definition of Done für diese User Story erfüllt ist. Mein Kollege verneint und ergänzt: “Es fehlt noch die Betriebs-Doku”. Ich mache meine Kollegen aufmerksam, dass alle Kriterien der Definition of Done erfüllt sein müssen, damit eine User Story in die Spalte Done geschoben werden kann und somit als abgeschlossen gilt.

Die Anforderung lebt!

Erstellt am 31 Juli 2015
von 1 Komment

Ist das Requirement Engineering tot?

desertDen Begriff „Requirements Engineering“ verbinden viele mit schwergewichtigen, dokumentenorientierten Vorgehensweisen, mit denen man Riesenprojekte besonders in der Luft- und Raumfahrt durchführt. Es beschreibt eine Herangehensweise aus den alten Zeiten der trägen „Wasserfall“-Projekte. Das Wort „Engineering“ klingt dabei wie ein komplexes Konstrukt, eine aufwändige Maschinerie für Anforderungen, ein starres Gebilde, das viel Ressourcen verschlingt und sich, wenn überhaupt, nur träge und langsam bewegt.

Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Erstellt am 9 September 2014
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Casting für Product Owner

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Die Qual der Wahl – das Konferenzprogramm der Manage Agile 2014 steht fest

Erstellt am 29 Juli 2014
von Schreibe einen Kommentar

manageagile_2014_quadrat_500pxWir Frauen sind es ja eigentlich gewöhnt aus einem überreichen Angebot auswählen zu müssen. Das geht morgens schon los mit der Frage „Was soll ich anziehen“, setzt sich in der Mittagspause fort mit der Entscheidung ob „Salat, Gemüse, oder doch das Schnitzel“ und (ja, ich bediene jetzt wirklich jedes Klischee) endet mit Verlustgefühlen oder Gewissensbissen nach dem Besuch im Schuhladen (je nach Anzahl der erworbenen Paar Schuhe). Und nein, Sie sind nicht aus Versehen auf dem Blog einer Frauenzeitschrift gelandet – gleich geht’s weiter mit agil.

Xtreme Simplicity – mach’s doch mit der Hand!

Erstellt am 6 Mai 2014
von Schreibe einen Kommentar

Kürzlich nahm ich an einer Story Time eines Scrum Teams teil. Das Ziel war, Klarheit in einige User Stories zu bringen, um diese dann schätzen zu können. Als die Zeit für die Schätzung gekommen war, sehe ich mich um: Keine Planning Poker Karten, keine Handys (mit Poker-App) am Tisch, nichts… Wie will das Team schätzen? Ich stelle mich also auf eine langwierige Schätzsession mit vielen Diskussionen ein. Ich plane im Geiste schon meine anschließende Intervention, um das Thema relative Schätzung zu motivieren. Plötzlich geht alles ganz schnell. Auf ein Zeichen des Scrum Masters heben alle Teammitglieder eine Hand, die Schätzzahl wird notiert und es geht weiter. Was war passiert? Und wieder einmal habe ich etwas gelernt: es geht immer noch einfacher!

Story Splitting Revisited

Erstellt am 23 Juli 2013
von Schreibe einen Kommentar

Vor kurzem habe ich an dieser Stelle das Story Splitting Flowchart von Richard Lawrence vorgestellt, eine gute, praktische Hilfe zum Schneiden von Use Stories.

Heute möchte ich die darin enthaltenen Pattern um zwei weitere ergänzen, die sich schon in mehreren Projekten als sehr hilfreich erwiesen haben.

Use Cases und User Stories – Verbündete oder Feinde?

Erstellt am 15 Mai 2013
von 4 Kommentare

Sind Use Cases und User Stories dasselbe? Und wenn nein, was sind dann die Unterschiede? Kann man sie in der Praxis miteinander verbinden, oder sollte man sich lieber für eine Seite entscheiden?
Zunächst: dasselbe sind sie nicht.

Slice it nice

Erstellt am 2 April 2013
von Schreibe einen Kommentar

Wer sich schon einmal mit der Frage herumgeschlagen hat, wie man User Stories sinnvoll schneiden kann, kennt meist auch das Story Splitting Cheat Sheet von Humanizing Work. Kennen Sie auch den Story Splitting Flowchart von Richard Lawrence?

Story Splitting Flowchart

Zu finden unter: http://www.richardlawrence.info/splitting-user-stories/

Für die praktische Arbeit sehr brauchbar. Probieren Sie es aus!