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:
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.
Die Stakeholder-Analyse bezeichnet die Identifikation der Projektteilnehmer, weiterer Personen und Institutionen, die ein Interesse an einem Entwicklungsgegenstand haben. Durch genaueres Untersuchen der Einstellung und Beziehung der Stakeholder zum Entwicklungsgegenstand bekommen die Projektverantwortlichen ein besseres Verständnis für die Erfolgsfaktoren des Entwicklungsgegenstandes.
Heute der 4. Teil der Serie „Anforderungen strukturieren“ mit der Frage: „Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?“. Im sogenannten Anforderungs-Informationsmodell wird definiert, welche
Unsere diesjährige REConf®2017, die größte Konferenz zum Thema Requirements Engineering im deutschsprachigen Raum, fand vom 27. bis 31. März 2017 im Holiday Inn München City Center im Herzen von München statt. Wie jedes Jahr war die REConf® wieder sehr gut besucht. Neben interessanten Vorträgen und Workshops gab es für die Teilnehmer genügend Raum für Diskussionen und persönlichen Austausch mit anderen Teilnehmern, aber auch mit den Referenten.
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?
Kü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.
Den 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.
Ist es in ihrem Unternehmen auch völlig normal geworden, dass jede scheinbar noch so unbedeutende Kleinigkeit ausgewertet und analysiert wird? Gibt es auch bei ihnen einen Mitarbeiter, der nichts anderes tut, als seine Kollegen zu überwachen? Diesen Trend hin zu immer mehr Kontrolle und Statistiken beobachte ich seit einiger Zeit mit wachsender Besorgnis – denn diese metrikgetriebene Entwicklung hat einen erheblichen Einfluss auf den Arbeitsalltag aller Entwicklungsbeteiligten. Lesen Sie hier, warum sich das titelgebende Sprichwort nicht immer bewahrheitet.
„Wo sind die Lücken und Brücken im Requirements Engineering?“. Das war die Frage auf dem World Café der REConf® 2015 – mit inspirierenden Ergebnissen. Viele Themen dazu wurden von den Teilnehmern, über den Vormittag verteilt, an eine Pinnwand gehängt und am Abend auf dem World Café diskutiert. Hier eine Zusammenfassung der Ergebnisse:
Eine einheitliche Abgrenzung zwischen den Begriffen Requirements Engineering und Requirements Management findet sich in der fachlichen Literatur nicht. Häufig wird Requirements Management als Teil des Requirements Engineering dargestellt, aber auch mal Requirements Engineering als Teil des Requirements Management. Als dritte Option werden Requirements Engineering und Requirements Management als nebeneinanderstehende Tätigkeiten betrachtet.
blog.hood-group.com nutzt Cookies, um den Traffic auf diese Website zu analysieren. Informationen zu Ihrer Nutzung unserer Website werden daher an Google übermittelt.OkDetails ansehen
Unsere diesjährige REConf®2017, die größte Konferenz zum Thema Requirements Engineering im deutschsprachigen Raum, fand vom 27. bis 31. März 2017 im Holiday Inn München City Center im Herzen von München statt. Wie jedes Jahr war die REConf® wieder sehr gut besucht. Neben interessanten Vorträgen und Workshops gab es für die Teilnehmer genügend Raum für Diskussionen und persönlichen Austausch mit anderen Teilnehmern, aber auch mit den Referenten.
Kü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“.
