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.

Für Agilität doch noch nicht zu spät?

Erstellt am 25 August 2015
von Schreibe einen Kommentar

Stellen Sie sich vor, Sie arbeiten jahrelang als Systemanalyst im Automotivekontext. Die Methoden des klassischen Requirements Engineering sind Ihnen in Fleisch und Blut übergegangen, Sie kennen die Stärken und Schwächen. Nun werden Sie mit agilen Werten und Prinzipien konfrontiert. Wurde der Samen einmal gepflanzt, ist ein Umdenken nicht mehr aufzuhalten.

Die vier Entwicklungsstadien einer Anforderung

Erstellt am 18 August 2015
von Schreibe einen Kommentar

Anforderungen entstehen üblicherweise im Laufe eines Entwicklungsprojektes und beeinflussen in hohem Maße dessen weiteren Verlauf. Sie sind die Grundlage vieler Entwicklungstätigkeiten und steuern damit zu einem nicht unerheblichen Teil das Geschehen. Änderungen in den Anforderungen führen häufig auch zu Änderungen der gesamten Projektsituation.

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.

„Es zählt nicht das Erreichte, sondern es reicht das Erzählte“

Erstellt am 14 Juli 2015
von Schreibe einen Kommentar

Mit diesem Spruch brachte der Projektleiter eines unserer Kunden seinen Ärger zum Ausdruck, als das Management von ihm verlangte ein neues Metrik-Tool für das aktuelle Projekt zu nutzen. Ärgerlich war, dass sich bereits vor Jahren ein Metrik-Tool im Unternehmen etabliert hatte, welches neben den üblichen Aufgaben im Projektalltag zusätzlichen Aufwand verursachte.

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.