{"id":1204,"date":"2017-09-07T08:00:49","date_gmt":"2017-09-07T06:00:49","guid":{"rendered":"https:\/\/se-trends.de\/?p=1204"},"modified":"2017-09-06T17:46:44","modified_gmt":"2017-09-06T15:46:44","slug":"requirements-management-in-an-agile-environment","status":"publish","type":"post","link":"https:\/\/www.se-trends.de\/en\/anforderungsmanagement-im-agilen-umfeld\/","title":{"rendered":"Requirements management in an agile environment"},"content":{"rendered":"

Der k\u00fcrzlich erschienene Artikel zum agilen Systems Engineering<\/a> wurde sehr positiv aufgenommen. Die Resonanz zeigte deutlich, dass das Thema agil<\/a> nach wie vor hochaktuell ist.<\/p>\n

Die Anmeldung f\u00fcr das Modeling Craftsmanship Camp<\/strong> am 18.11. in Hannover l\u00e4uft (Anmeldung >><\/a>), und das\u00a0 systems.camp Nord<\/strong> der GfSE am 7.10. in Hamburg ist bereits halb ausgebucht (Anmeldung >><\/a>)<\/p>\n

Ein sehr wichtiger Teilbereich des Systems Engineering ist das Requirements Engineering. Da Maik Pfingsten k\u00fcrzlich ein Gespr\u00e4ch zu dem Thema mit Michael Mahlberg<\/a> beim Zukunftsarchitekten gef\u00fchrt hat, m\u00f6chte ich das Thema hier aufgreifen.<\/p>\n

Das Gespr\u00e4ch war interessant und ist h\u00f6renswert. An einigen Stellen konnte ich zun\u00e4chst den beiden nicht unqualifiziert zustimmen. Im Laufe des Podcasts merkte ich aber, dass dies wohl daran lag, dass der Kontext nicht explizit gesetzt wurde. Die Fragen von Mike spielten darauf an, agiles RE im Bereich Embedded und funktionaler Sicherheit einzusetzen. Die Antworten von Michael implizierten, dass er eher an die reine Softwareentwicklung dachte in Bereichen, wo Sicherheit eine untergeordnete Rolle spielt. In beiden Bereichen kann agiles RE betrieben werden, aber die Anforderungen an die Entwicklung unterscheiden sich erheblich. Gerade solche Nuancen machen solche Aufnahmen interessant und regen zum Denken an.<\/p>\n

<\/p>\n

Wer ist im agilen RE f\u00fcr die Anforderungen verantwortlich?<\/h2>\n

Die Kernfrage von Maik war, wie sich RE im agilen Umfeld vom traditionellen Umfeld unterscheidet. Dabei wurde implizit davon ausgegangen, dass die Zuh\u00f6rer mit RE im traditionellen Umfeld zumindest rudiment\u00e4r vertraut sind. Vor diesem Hintergrund stellt sich die Frage, wer im agilen Umfeld \u00fcberhaupt f\u00fcr die Anforderungen verantwortlich ist, denn die Rolle des Requirements Engineers gibt es in der Regel gar nicht. Wer sich in agiler Entwicklung auskennt, der w\u00fcrde auf den Product Owner tippen, doch laut Michael ist dies weder w\u00fcnschenswert noch realistisch, da dieser selten alle erforderlichen Kompetenzen vereint. Stattdessen sieht er es als Teamarbeit, die Anforderungen zu bearbeiten.<\/p>\n

Es ist \u2013 bei den realen Besetzung dieser Rolle \u2013 weder w\u00fcnschenswert noch realistisch, dass der Product Owner alle Anforderungen alleine beschreibt (Michael Mahlberg) [tweetthis]Es ist meistens weder w\u00fcnschenswert noch realistisch, dass der Product Owner alle Anforderungen alleine beschreibt @MMahlberg[\/tweetthis]<\/p><\/blockquote>\n

Anforderungen werden auch nicht fertiggestellt und dann umgesetzt. Hier wurde die Analogie zum traditionellen Lastenheft gezogen, das an den Umsetzer \u00fcbergeben und in der Form eines Pflichtenhefts beantwortet wird. Stattdessen verglich er die Anforderungen mit einem Klumpen, der im Laufe des Projekts umgeformt wird. Dabei stellte sich die Frage, welche Elementtypen denn im agilen Umfeld eingesetzt werden. Hier kam die Antwort, dass im agilen Umfeld die Artefakte eher aus \u201eim Wiki zusammengetackerten Elementen\u201c bestehen.<\/p>\n

An dieser Stelle vertrete ich eine andere Meinung: Im agilen Umfeld ist der Umgang mit \u00c4nderungen ein wesentlicher Erfolgsfaktor. Um jedoch mit \u00c4nderungen umgehen zu k\u00f6nnen, brauchen wir saubere Grenzen zwischen Informationselementen und sauber definierte Beziehungen (Traceability). Das hier beschriebene Vorgehen kann sicher f\u00fcr kleine Projekte funktionieren. Aber ich sehe hier Skalierungsprobleme, insbesondere, wenn die Entwicklung Aspekte der funktionalen Sicherheit beinhaltet. Und im Bereich der funktionalen Sicherheit ist so ein Vorgehen nicht akzeptabel. Was \u00fcbrigens auch sp\u00e4ter von Maik aufgegriffen wurde.<\/p>\n

Lifecycle: Ein wichtiger Unterschied im agilen RE<\/h2>\n

Ein wesentlicher Unterschied besteht bez\u00fcglich des Lifecylces in der Entwicklung. Dabei sieht Michael traditionell vieles vorgelagert (\u201eWasserfall\u201c), w\u00e4hrend beim agilen RE viele Anforderungen erst im Prozess entstehen. Dabei wies er auch auf kleine aber wichtige Unterschiede der verschiedenen Vorgehen hin, bspw. Scrum vs. Lean. Das halte ich auch f\u00fcr einen sehr wichtigen Aspekt, denn agil ist nicht gleich agil. Ein Diskussionspunkt war der zeitliche Aufwand f\u00fcr die Erstellung eines Lastenhefts, wobei eine Dauer von 6-9 Monaten genannt wurde, was durchaus in der traditionellen Praxis vorkommt. Das kann jedoch laut Michael auch im agilen Umfeld vorkommen, wobei das Schreiben des Lastenhefts dann nicht vorgelagert ist, sondern ein Transformationsprozess von Lastenheft zu Pflichtenheft ist, der parallel zu der Entwicklung abl\u00e4uft. Auch hier stimme ich nicht ganz zu: f\u00fcr mich sollten auch im agilen Umfeld Problem und L\u00f6sung voneinander getrennt bleiben.<\/p>\n

Mit \u00c4nderungen umgehen<\/h2>\n

Erst sp\u00e4t in der Diskussion kam ein Thema auf, welches ich im agilen Umfeld f\u00fcr extrem wichtig halte: Baselines, Traceability und ein daraus abgeleitetes \u00c4nderungsmanagement.<\/p>\n

Michael vertrat den Standpunkt, dass Baselines f\u00fcr Revisionssicherheit overkill sein k\u00f6nnen, da in einem (bspw.) Wiki-basierten System jede Seite sowieso versioniert wird und somit die Historie leicht greifbar ist. Das hat er durchaus recht, aber das ist meiner Meinung nach nur ein m\u00f6glicher Anwendungsfall von Baselines. Der Clou bei Baselines ist es ja, dass eine Gruppe von Elementen zusammengefasst wird. Der klassische Anwendungsfall ist es, dass eine Baseline mit einer anderen, oder dem aktuellen Stand, verglichen wird. In dem Scenario interessieren mich nicht alle kleinen \u00c4nderungen, sondern nur der Unterschied zwischen den beiden Baselines. Wenn dabei ein einzelnes Element auff\u00e4llig wird, kann dessen Historie im Detail untersucht werden.<\/p>\n

Ebenso die Frage nach der Traceability. Dort sah Michael die Anwendung prim\u00e4r darin, die Auswirkungen von \u00c4nderungen abzusch\u00e4tzen, also die klassische Impaktanalyse. Er sah weniger Wert darin, im Nachhinein \u00c4nderungen nachzuvollziehen \u2013 prim\u00e4r wegen des anfangs angesprochenen Umwandlungsprozesses: Die zu verfolgende Information ist nach der Weiterentwicklung vielleicht schon verschwunden.<\/p>\n

Einen Baum vom groben Requirement bis zum Detail habe ich im agilen Umfeld auch, nur zu einem viel sp\u00e4teren Zeitpunkt (Michael Mahlberg) [tweetthis]Auch im agilen habe ich einen Baum vom Groben bis zum Detail, nur viel sp\u00e4ter[\/tweetthis]<\/p><\/blockquote>\n

Das ist der Grund, warum ich \u2013 gerade im agilen Umfeld \u2013 eine klare Trennung von Problem und L\u00f6sung f\u00fcr so wichtig halte: W\u00e4hrend sich die L\u00f6sung sehr schnell \u00e4ndern kann (und wird), bleibt die Problemstellung relativ stabil. Wenn sich aber die Problemstellung \u00e4ndert, ist es umso wichtiger, alle Implikationen davon zu pr\u00fcfen. Das klassische Mittel von fast allen RE-Werkzeugen sind die \u201esuspekten Links\u201c. Konkretes Beispiel aus dem Podcast: \u201eDer Nutzer muss sich authentisieren.\u201c Nun kann eine L\u00f6sung iterativ entwickelt werden. Wenn sich w\u00e4hrend der Entwicklung der L\u00f6sungsansatz \u00e4ndert, so ist das f\u00fcr die Problemstellung irrelevant. Wenn die Problemstellung jedoch erg\u00e4nzt wird, bspw. \u201emit 2-Faktor Authentisierung\u201c, so ist es wichtig, alle abh\u00e4ngigen L\u00f6sungselemente als \u201esuspekt\u201c zu markieren. Ansonsten w\u00fcrde vielleicht beim Password-Recovery-Link der zweite Faktor vergessen werden.<\/p>\n

W\u00e4hrend des Podcasts musste ich lachen, denn Maik bemerkte, \u201eDu hast etwas beschrieben, was in meiner Welt ein hochiteratives V-Modell darstellt\u201c. Dem wiederum kann ich voll und ganz zustimmen: Das ist auch das, was ich im Artikel \u201eagile Systementwicklung beschrieben hatte\u201c. Um so etwas jedoch leben zu k\u00f6nnen, m\u00fcssen Artefakte sauber getrennt und sauber verkn\u00fcpft sein.<\/p>\n

Agiles RE ist in meiner Welt ein hochiteratives V-Modell (Maik Pfingsten) [tweetthis]Agiles RE ist in meiner Welt ein hochiteratives V-Modell[\/tweetthis]<\/p><\/blockquote>\n

Fazit<\/h2>\n

Der Podcast war voller guter Ideen. Die teilweise widerspr\u00fcchlichen Aussagen lie\u00dfen sich dadurch erkennen, dass hier agiles RE von zwei unterschiedlichen Richtungen beleuchtet wurde: Sowohl aus dem bekannten Bereich der agilen Softwareentwicklung, als auch aus der sicht der Embedded-Entwicklung, in der agiles RE noch nicht so weit verbereitet ist. Diese nicht explizit ausgesprochenen Unterschiede k\u00f6nnen unter Umst\u00e4nden beim H\u00f6rer zur Verwirrung f\u00fchren.<\/p>\n

Aber mit diesem Unterschied im Kopf machten Maiks Kommentare zu \u00fcber funktionale Sicherheit und Systems Engineering Sinn. Michael hingegen sprach \u00fcber Eingabemasken und Softwarecode. F\u00fcr solche Entwicklungen kann ein Wiki durchaus ausreichend sein.<\/p>\n

\n
Photo by \u0160tefan \u0160tefan\u010d\u00edk<\/a> on Unsplash<\/a><\/span><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

The recently published article on agile systems engineering was very well received. The response clearly showed that the topic of agile is still highly topical. Registration for the Modeling Craftsmanship Camp on 18.11. in Hanover is open (registration >>), and the GfSE's systems.camp Nord on 7.10. in Hamburg is already half booked (registration >>)...<\/p>","protected":false},"author":1,"featured_media":1209,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[34,53],"tags":[36,100,225],"class_list":["post-1204","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agilitaet","category-interview","tag-agilitaet","tag-anforderungen","tag-embedded"],"_links":{"self":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts\/1204","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/comments?post=1204"}],"version-history":[{"count":0,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/posts\/1204\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/media\/1209"}],"wp:attachment":[{"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/media?parent=1204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/categories?post=1204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.se-trends.de\/en\/wp-json\/wp\/v2\/tags?post=1204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}