Haben Sie zu viel Geld?

Erstellt am 25 Januar 2017
von Schreibe einen Kommentar

Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?

Zeig doch mal die Metrik!

Erstellt am 13 Dezember 2016
von Schreibe einen Kommentar

Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.

Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016

Erstellt am 8 November 2016
von Schreibe einen Kommentar

Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, abbildung05wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese „zwei Gebiete“ immer mehr zusammenwachsen und gemeinsam betrachtet werden.

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.

Das Internet der Dinge und seine Auswirkungen auf unsere Welt

Erstellt am 5 Juli 2016
von Schreibe einen Kommentar

Laut einer Prognose auf der diesjährigen Cebit in Hannover werden 50 Milliarden Geräte bis 2020 vernetzt sein.

Perzeptive Umgebungswahrnehmung, Geosensitive Daten, Wearables, Cyberphysikalische Systeme – eine Vielzahl neuer Schlagwörter kursiert in diesen Tagen durch das Netz. Sie künden eine neue Welt der rechnergestützten Informationssystemen an, in denen smarte Alltagsgegenstände mit digitaler Logik, Sensorik und der Möglichkeit zur Vernetzung ein „Internet der Dinge“ bilden.

Interview zur Entwicklung der REConf®

Erstellt am 2 Februar 2016
von Schreibe einen Kommentar

Seit 15 Jahren findet jährlich in München die REConf® statt, die wichtigste Konferenz zum Requirements Engineering im deutschsprachigen Raum

Wie alles angefangen hat, wie sich die REConf® entwickelt hat und welche Weiterentwicklung die REConf® in den kommenden Jahren durchlaufen wird, erfahren Sie in diesem Interview mit Rupert Wiebel, Geschäftsführer der HOOD GmbH, dem Veranstalter der REConf®. Das Interview wird geführt von Gerhard Versteegen, Geschäftsführer der HLMC GmbH.

HOOD beteiligt sich am BMBF Forschungsvorhaben autoSWIFT

Erstellt am 15 Dezember 2015
von Schreibe einen Kommentar

logo

Schnellere Innovationszyklen für Elektroniksysteme entlang der Automobilwertschöpfungskette

Feature Driven Development – Ein Stück näher an eine agile Vorgehensweise

Erstellt am 8 Dezember 2015
von Schreibe einen Kommentar

Große Unternehmen mit Taylorscher Organisationsstruktur lassen sich nur schwer
komplett in ein agiles Unternehmen verwandeln. Methoden mit agilem Einfluss, wie z.B. „Feature Driven Development“, können jedoch auch in großen Unternehmen schwergewichtige Vorgehensweisen bei der Entwicklung von Produkten vereinfachen.

Gegen das „Nicht Verstehen“ – SCRUM richtig Agil machen

Erstellt am 4 November 2015
von Schreibe einen Kommentar

SCRUM ist beliebt und erfreut sich einer immer weiteren Verbreitung. Aber nicht für alle, die sich dieser Methodik annähern, scheint es ein „Silver Bullet“ zu sein. Neben den vielen erfolgreichen Projekten gibt es eine ganze Reihe von Firmen, die noch  keine erfolgreiche Entwicklung mittels SCRUM erreichen konnten. Solche Schwierigkeiten werden kaum an die große Glocke gehängt, aber wenn man im Netz sucht, dann stößt man auf agile Coaches, die auch schon mal Ihr Leid klagen:

Usability Requirements Engineering!

Erstellt am 29 September 2015
von Schreibe einen Kommentar

Anforderungen an ein Produkt kommen von ganz unterschiedlicher Seite: Normen, Gesetze und Richtlinien, Umwelteinflüsse, andere Systeme oder auch Prozesse. Die wichtigste Quelle ist und bleibt jedoch der Mensch. Schließlich werden die meisten Systeme am Ende auch durch Menschenhand bedient.

Die Diskrepanz zwischen anfänglichen Nutzererwartungen und praktikablem Ergebnis eines Entwicklungsprojektes ist allerdings häufig groß; auch adaptive Änderungen am Produkt oder Prototypen in kurzen Iterationen bringen oftmals nicht die gewünschte Zufriedenheit.

Warum ist das so? Die Entwicklung durch Prototypen, erlebbare Ergebnisse und frühzeitige Testvarianten ist zwar anwenderfreundlich und flexibel, hat bei unvorsichtiger Durchführung allerdings auch Nachteile. Sie kann wie ein Korsett wirken.

Eine Auftragsarbeit wird durch kurzfristige Entwicklungsergebnisse für den Kunden nachvollziehbar und plastisch. Über die Erfahrung des Erlebens und Anfühlens durch einen ersten Prototyp kann der Nutzer gezielt auf die weitere Konzeption Einfluss nehmen. Häufig wird aus einem ersten technischen Entwurf im Laufe einer Entwicklung das spätere Endprodukt (evolutionärer Prototyp). Der Nutzer begleitet dieses Produkt bei dessen Entstehung. Kreativität, Innovationskraft und vor allem unterbewusste Kundenbedürfnisse bleiben aber häufig unerkannt. Die faktische „Realität“ des Prototyps schränkt den Anwender bereits ein. Das Zusammenspiel zwischen Anwender und Entwickler reduziert sich auf ein „Angebot akzeptiert“ oder „Angebot abgelehnt“. Hinzu kommt, dass ein technischer Prototyp häufig aus dem Standardrepertoire der Entwickler entsteht. Innovation und Einfallsreichtum daher häufig nicht gefördert.

Hier sind Konzepte wie Usability Engineering oder User Experience, die den Nutzer in den Mittelpunkt rücken, tatsächlich nur bedingt nutzerzentriert.

Um auf möglichst breiter Spur entwickeln zu können, ist eine Verlagerung bekannter UI/UX-Ansätze in den Analysebereich bzw. in die Anforderungsermittlung sinnvoll. Low-Fi-Prototypen mit Flipchart, Smartphone-Kamera oder Wireframes sind nicht restriktiv, suggerieren kaum Umsetzung oder Lösung und verursachen weit weniger Hemmungen, das Erstellte wieder vollends zu verwerfen und neu anzufangen. Sie sollten daher parallel zu technischen Prototypen weiterhin eingesetzt werden.

Die klassischen Bezeichnungen Usability Engineering und Requirements Engineering sollten enger zusammenwachsen und die Schwerfälligkeit des Engineering-Begriffs durch agile Entwicklungsprinzipien aufgeweicht werden. Für eine moderne, nutzerzentrierte Entwicklung gelten daher folgende Prinzipien:

  • Usability von der Entwicklung stärker in die Analyse verlagern
  • Der Entwurf neuer Ideen, Möglichkeiten und potentieller Lösungen muss zuerst in die Breite gehen (Divergenz anstatt Konvergenz)
  • Der Charakter eines Prototyps muss zuerst explorativ und dann experimentell sein
  • Verstärkte Bereitschaft bereits Entwickeltes wieder aufzugeben (kein einzelner evolutionärer Prototyp)
  • More Paper, less Code – Low-Fi-Prototypen und Kreativtechniken für mehr Freiheit, Ideenentwicklung und innovative Wagnisse

 

In den nächsten Beiträgen möchte ich auf diese Prinzipien genauer eingehen und konkrete Techniken beschreiben, wie wir den Einbezug des Nutzers bzw. der unterschiedlichen Nutzergruppen verbessern können, um gemeinsam innovative Produkte zu entwickeln.