UX == RE? – die Auswertung

Erstellt am 18 Oktober 2017
von Schreibe einen Kommentar

Am 27. Juni 2017 haben wir Sie im Blog-Beitrag UX == RE? – mit Gewinnspiel! aufgefordert, an einer Umfrage zum Thema UX (User Experience) teilzunehmen. Nach zahlreichen Rückmeldungen freuen wir uns, Ihnen das Ergebnis dieser Umfrage in Form dieses Blogbeitrages vorstellen zu dürfen.

Beginnen möchte ich mit den Aussagen eins bis drei:

Aussage 1: Der Benutzer steht im Mittelpunkt unserer Entwicklung

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 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?

Heisse Anforderungen und späte Änderungen

Erstellt am 4 Juli 2017
von Schreibe einen Kommentar

Das zweite agile Prinzip handelt nicht etwa von zu warmen Anforderungen an denen man sich die Finger verbrennt (die Überschrift enthält kein „ß“), sondern stellt in der Produktentwicklung vielmehr ein ungeschriebenes Gesetz dar.

Anforderungen strukturieren – 2. Techniken

Erstellt am 26 April 2017
von 1 Komment
This entry is part 2 of 3 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?“

Anforderungen strukturieren – 1. Kriterien

Erstellt am 30 März 2017
von Schreibe einen Kommentar
This entry is part 1 of 3 in the series Anforderungen strukturieren

Die Teilnehmer unseres Trainingsangebotes bringen häufig ein konkretes Problem aus ihrem beruflichen Umfeld mit. Viele wollen wissen, wie man gute Anforderungen schreibt, andere wollen einfach die Grundlagen umfassend kennenlernen, die bei dem Umgang mit Anforderungen notwendig sind, sei es im klassischen oder agilen Umfeld.

Eine der häufigsten Fragen lautet: „Ich habe da eine Menge Anforderungen von verschiedenen Seiten in meinem Projekt. Wie strukturiere ich am besten diese heterogenen Anforderungen?

Es ist Samstagabend…

Erstellt am 14 März 2017
von 1 Komment
This entry is part 3 of 3 in the series Anforderung und Implementierung

…nach dem Abendessen, meine Mutter und mein Bruder sind bei uns zu Besuch. Meine Tochter ist auch Zuhause und wir haben uns entschieden, Karten zu spielen. „Schwimmen“ , so heißt unser Lieblingsspiel und unsere Gäste kennen es noch nicht, so müssen wir das Spiel nun erläutern. Der Kampf „ums Erklären dürfen“ geht los. Unser Töchterchen studiert Technische Redaktion und ich bin Berater. Das Töchterchen gewinnt und darf das Spiel erklären, während ich das Geschehen beobachte.

Inwieweit kann man das Erlernen eines Kartenspiels mit der Qualifizierung von Menschen in der Formulierung von Anforderungen in einem Entwicklungsunternehmen vergleichen und was wir hierbei voneinander lernen können, folgt jetzt:

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,

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.

Guter Kunde, schlechter Kunde – Product Owners Glück und Leid in agilen Zeiten

Erstellt am 10 Mai 2016
von Schreibe einen Kommentar

Das richtige Paradigma

b_01Wenn wir nur so gut Software und Systeme wie Häuser bauen könnten. Nein, wie ein gut gepflegter Garten- so sollten wir entwickeln. Halt, unsere Systeme sollen schon wachsen, aber die sollen auch gleich verkaufbar sein, also einen Wert stiften. Also besser, erst einmal einen Roller entwickeln, dann ein Motorrad und dann ein Auto. So sind doch erfolgreiche Produkte entstanden. Oder?