Vortrag 18

Titel:

Agile Softwareentwicklung – Lessons Learned

(Martin Weber / akquinet AG)

Session:

Agile Methoden

Datum und Uhrzeit:

Montag, 9. Mai 2011 von 15:05 bis 15:45 Uhr

Beschreibung:

Der Einsatz agiler Entwicklungsmethoden gehört inzwischen zum Standardrepertoire der industriellen Softwareentwicklung. Insbesondere Scrum wird breit eingesetzt. Unsere Erfahrung aus eigenen Projekten und Beratungseinsätzen zeigt allerdings, dass sich in der praktischen Anwendung agiler Ansätze sowohl Licht als auch Schatten zeigt.

Auf der Lichtseite findet sich vor allem die Konzentration auf das Wesentliche, nämlich die effiziente Entwicklung von Software mit einer hohen fachlichen Qualität. Neben einer Reduktion der formalen Aspekte der Projektverwaltung auf das minimal Notwendige, gehört vor allem die Betonung des menschlichen Faktors zu den aus unserer Sicht wichtigsten Beiträgen der agilen Gemeinschaft für die Softwareentwicklung. Der Einsatz kleiner Entwicklungszyklen und die enge Integration von Anwendern in den laufenden Entwicklungsprozess gehörten auch schon vor dem Aufkommen der agilen Methoden zu den bekannten Erfolgsfaktoren.

Natürlich finden sich auf der Schattenseite auch Erfahrungsberichte, bei denen die Einführung agiler Methoden nicht erfolgreich verlief. Das Aufgeben formaler Planungselemente kann dazu führen, dass eine belastbare Projektplanung gar nicht mehr möglich ist. Dies wird insbesondere dann relevant, wenn unterschiedliche Entwicklungsteams zusammen arbeiten müssen und sich Abhängigkeiten zwischen den erzeugten Artefakten ergeben. Der Ansatz von selbstorganisierenden Teams stellt hohe Anforderungen an die Teammitglieder und kann auch schon bei kleinen Gruppen scheitern. Für große Gruppen scheint er aktuell nicht möglich zu sein. Die Position eines externen Scrum-Masters, der keine Verantwortung für den Projektfortschritt und die Ergebnisqualität hat, vermittelt manchmal den Eindruck, als ob er von Beratungsunternehmen in eigenem Interesse erfunden wurde.

Aber auch die agilen Methoden, die sich mehr auf das konkrete Projektgeschäft konzentrieren, haben ihre Herausforderungen. Programmierung im Paar muss zunächst gelernt werden. Anderenfalls kann es zu erheblichen Spannungen im Team und zu einer halbierten oder auch geringeren Produktivität führen. Die gemeinsame geteilte Verantwortung für die gesamte Codebasis eines Projekts muss erstens von den Teammitgliedern innerlich akzeptiert werden. Sie müssen aber zweitens sowohl fachlich als auch technisch in der Lage sein, die Verantwortung operativ übernehmen zu können. Ein gemeinsamer Arbeitsraum mit allgemein zugänglichen Projektinformationen benötigt sowohl organisatorische und logistische Ressourcen als auch einen durchgängigen Verhaltenskodex, damit die Teammitglieder produktiv arbeiten können.

Nach unseren Erfahrungen führt der Einsatz agiler Methoden zunächst zu einer Verlangsamung des Entwicklungsprozesses. Es besteht insbesondere in der ersten Phase die Gefahr, dass sich entweder Mitarbeiter von dem Veränderungsprozess abkoppeln und diesen dann in der Folge passiv blockieren oder dass die etablierten Prozesse unter neuen Namen bestehen bleiben. Das kritische Element ist dabei die Transparenz. Explizites oder implizites Ziel vieler agiler Methoden ist das Schaffen eines übergreifenden Verständnis von Fachlichkeit, Umsetzung und Projektfortschritt, um so als Team verantwortliche und gute Entscheidungen treffen zu können. Die Kehrseite davon ist, dass sowohl die Leistungen als auch die Probleme einzelner Mitarbeiter für die anderen sichtbar werden. Dieses kann zu Abwehrreaktionen und damit zu Problemen im Projektgeschäft führen.

In diesem Artikel werden wir anhand konkreter Beispiele aus unserer Erfahrung aufzeigen, welche agilen Elemente wir in welchen Kontexten eher positiv oder eher als Herausforderung erlebt haben. Als Ergebnis stellen wir darauf basierende Empfehlungen für die Einführung konkreter Methoden auf.


Referent:

Martin Weber ist Geschäftsführer der akquinet tech@spree GmbH und seit vielen Jahren verantwortlich für die agile und nicht-agile Entwicklung kundenspezifischer Anwendungen. Er hat langjährige Erfahrung in der Durchführung komplexer Software-Entwicklungsprojekte und Software-Architekturen. Seit mehr als 25 Jahren hat er sich als Entwickler, Architekt, Berater, Coach und Projektleiter mit Methoden und Techniken objektorientierter und komponentenorienterter Software-Entwicklung beschäftigt.


NEWS +++ NEWS +++ NEWS
Proceedings verfügbar
Die Proceedings der SEE2011 sind nun abrufbar. mehr...
Rückblick SEE2011
Mittlerweile zum fünften Mal stellte die Firma 4Soft mehr...
SEE 2011 mit Fokus auf Offenheit
Pressemeldung der BIT zur SEE2011 mehr...
Eröffnungskeynote von Julian Hein, Open Source Business Foundation
Am Beispiel Icinga – einem “Fork” des Open Source Monitoring Projekts Nagios – wird Julian Hein mehr...

Veranstalter:

Veranstalter 4Soft Bundesstelle für Informationstechnik (BIT) TU Clausthal

 

Sponsoren:

Sponsoren microTOOL Capgemini sd&m

 

Medienpartner:

Medienpartner manage it move online