Klassisch, agil, und dann? – Teil 2 Agile Ansätze im Requirements Engineering

Michael Blasi* |

Anbieter zum Thema

Diese dreiteilige Beitragsserie gibt einen Überblick zu klassischen und agilen Verfahren des Requirements Engieneering und wirft einen Blick auf zukünftige Herausforderungen. Teil 2 beschäftigt sich mit den heute sehr beliebten agilen Methoden, ihren Techniken, Vor- und Nachteilen.

*Die dreiteilige Beitragsserie "Klassisch, agil und dann?" entstand nach Unterlagen einer Semesterarbeit (Literaturreview) im Fachbereich Wirtschaftsinformatik an der FOM Hochschule für Oekonomie und Management München.  Der Autor des zweiten Teils, Michael Blasi, ist hauptberuflich Geschäftsführer der M. & J. EDV GmbH & Co. KG. Das Unternehmen bietet Dienstleistungen im Bereich Schulung, Beratung und Datenbank-Entwicklung an.
*Die dreiteilige Beitragsserie "Klassisch, agil und dann?" entstand nach Unterlagen einer Semesterarbeit (Literaturreview) im Fachbereich Wirtschaftsinformatik an der FOM Hochschule für Oekonomie und Management München. Der Autor des zweiten Teils, Michael Blasi, ist hauptberuflich Geschäftsführer der M. & J. EDV GmbH & Co. KG. Das Unternehmen bietet Dienstleistungen im Bereich Schulung, Beratung und Datenbank-Entwicklung an.
(Bild: Clipdealer)

Aufgrund der Softwarekrise in den sechziger Jahren wurde auf der NATO Konferenz in Garmisch-Partenkirchen der Begriff „Software Engineering“ geprägt. Ziel war, eine ingenieurmäßige Vorgehensweise bei der Entwicklung von Software und Systemen vorzugeben. Ursache dieser Krise war die Tatsache, dass erstmals die Kosten für die Software die Kosten der Hardware überstiegen. Ausschlaggebend hierfür waren verzögerte Fertigstellungen, unbefriedigende Resultate oder extreme Kostenüberschreitungen. Die Entwickler unterschätzten teils die sehr komplexen Projekte oder waren damit überfordert.

Im Zuge dieser Reform wurden zahlreiche Vorgehensweisen entwickelt. Diese wurden immer aufwendiger und komplexer und lenkten den Fokus mehr auf den Entwicklungsprozess an sich, weniger auf das zu entwickelnde System. Teils führte dies regelrecht zu Verdruss bei den Entwicklern.

Bildergalerie

Durch provozierende Aussagen zu Extreme Programming, kurz XP, prägten Kent Beck und Ward Cunningham ein anderes Leitbild für Softwareentwicklung, welches 17 Experten 2001 in Utah konkretisierten. Dieses Idealbild, welches nach heftigen Diskussionen der anwesenden Softwareentwickler und Methodenforscher festgelegt wurde, wird als Manifest der agilen Softwareentwicklung bezeichnet.

Diese agile Bewegung ist keine Gegenbewegung, vielmehr soll das Gleichgewicht wiederhergestellt werden. So wird die Dokumentation durchaus befürwortet, aber nicht um Unmengen Papier zu produzieren, das nie gepflegt wird und selten Verwendung findet. So sollen in einem turbulenten Umfeld die Grenzen der Planung erkannt werden. Im Manifesto heißt es wörtlich übersetzt „Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung helfen…“ (Fowler und Highsmith, 2001)

Tabelle 1: Prioritäten im Agilen Manifest. Z.B. wird die Bedeutung von Prozessen und Werkzeugen anerkannt, aber das Zusammenspiel der beteiligten Akteure erhält mehr Gewicht.
Tabelle 1: Prioritäten im Agilen Manifest. Z.B. wird die Bedeutung von Prozessen und Werkzeugen anerkannt, aber das Zusammenspiel der beteiligten Akteure erhält mehr Gewicht.
(Quelle: Fowler und Highsmith, 2001)

Tabelle 1 illustriert die Prioritäten des agilen Manifests. In jeder Zeile gibt das erste Segment eine Präferenz wieder, während das zweite Segment zwar wichtig ist, aber eine niedrigere Priorität genießt. So wird die Bedeutung von Prozessen und Werkzeugen anerkannt, aber das Zusammenspiel der beteiligten Akteure hat eine größere Bedeutung. Eine umfangreiche Dokumentation ist ebenfalls notwendig, das Hauptaugenmerkt sollte aber nicht auf der Dokumentation sondern der lauffähigen Software sein.

So sollte jedes Projektteam selbst entscheiden, welche Unterlagen zwingend erforderlich sind, und welche nicht. Verträge liefern die notwendigen Rahmenbedingen für eine erfolgreiche Zusammenarbeit. Aber nur durch den regelmäßigen Austausch kann das Verständnis des Projektteams für das zu entwickelnde Produkt entstehen und somit auch das gewünscht Resultat, die benötigte Software, entstehen. Zum Zeitpunkt der Erstellung eines Plans kann aufgrund der turbulenten Welt der Wirtschaft und Technik niemand abschätzen, ob das geplante Vorgehen so korrekt ist. Daher kann ein striktes befolgen dessen fatale Folgen haben.

Artikelfiles und Artikellinks

(ID:42704398)

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung