Qualifizierung für agile Methoden in der Programmiertechnik

Transkript

1 Qualifizierung für agile Methoden in der Programmiertechnik Fridolin Kathan *, Frank Klosa *, Birgit Krumpholz +, Frank Papenfuß +, Hartmut Pfüller +, Holm Rudert **, Frank Weicker ++ * SPS GmbH, Neubukower Str. 4, Moitin, f.klosa@sps-moitin.de + Universität Rostock, IEF, Institut MD, Rostock, vorname.nachname@unirostock.de ** RuTech IT Network Consulting, Alter Hafen Süd 4, Rostock, Rudert@rutech.de ++ Ingenieurbüro für Automation GmbH, Mühlenweg 15, Stäbelow, Weicker@ibagmbh.de (Das Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) innerhalb des InnoRegio Projektes Nukleus unter dem Förderkennzeichen 03i4922B gefördert. ) Einleitung In der Informatik zeigt sich in jüngster Zeit eine Vorgehensweise mit dem Namen Extreme Programming (nachfolgend auch abgekürzt als XP ) in vielfältiger Ausprägung. Ein schematischer Projektablauf dieser Strategie ist in Abb. 1 dargestellt. Der XP Programmierprozess, dessen innovativer Gehalt vor allem darin besteht, dass in Anlehnung an die Entwicklungsstrategie [1] einfache Prinzipien wie Kommunikation, Einfachheit der Lösung, schnelles Feedback und Mut zur Flexibilität favorisiert werden, unterscheidet sich vom Grundsatz her erheblich von den in den Firmen gegenwärtig praktizierten und gelehrten herkömmlichen Entwicklungstechniken. Diese Tatsache und den besonders dynamischen Ansatz des XP Modells verdeutlicht Tabelle 1 durch eine Gegenüberstellung von traditionellen, eher schwergewichtigen Methoden [1] einerseits und dem XP Modell zur Softwareentwicklung andererseits. Zur ersten Version des agilen Programmierens Die Technik des Extreme Programming (XP) stützt sich auf eine Reihe von etwa 28 (siehe [5]) unterschiedlichen Vorgehensweisen, die im Zusammenspiel nach bisheriger Erfahrung eine deutliche Verbesserung von Qualität und Produktivität bei der ingenieurmäßigen Erarbeitung von Softwarelösungen ermöglichen. Zu

2 Abb. 1: Schematische Darstellung des XP Projektablaufes nach [7]. Deutlich zu erkennen ist die zentrale Bedeutung der Iteration im XP Projekt. Sie bildet mit ihrer Länge von ca. 1-3 Wochen den Herzschlag des XP Projektes und die Grundlage für verlässliche Abschätzungen der Projektgeschwindigkeit und des Zeitpunktes der Fertigstellung des Projektes. Die Planung des Projektes kann dabei anforderungsorientiert (wann werden 100% der Anforderungen implementiert sein), zeitorientiert (gegeben ein fester Endtermin, wie viele Anforderungen werden zu diesem Termin verfügbar sein) bzw. durch eine Mischform aus beidem erfolgen. den wichtigsten neuen Vorgehensweisen beim Extreme Programming gehören nach heutigem Verständnis die folgenden: Häufige, aber kleine Auslieferungen 1 planen (betont Kontinuität, vermeidet Brüche durch weniger überschaubare Änderungen) Planung in Form von Spielregeln, Zielen, Erfolgspunkten ("Planning Game") Tests werden vor dem eigentlichen Programmquellkode geschrieben (widerspiegelt die Liste der Systemanforderungen in akribischer Form) Pair Programming (Peer Review bereits beim Erstellen des Quellkodes durch gemeinsames Programmieren zweier Entwickler, dadurch sehr kurze Rückkopplung bzw. schnelle Korrektur von Fehlern) fördert Durchschaubarkeit des produzierten Quellkodes Kunde vor Ort (enge Bindung zum Auftraggeber) Gemeinsame Codeverantwortung aller Entwickler Kontinuierliche Integration (im Abstand von Stunden oder Tagen, nicht von Wochen) 1 Eine Auslieferung meint eine komplette Installation der Software zum gegebenen Zeitpunk.

3 Einfachstes Design (Ausmerzen jeglicher entbehrlichen Kompliziertheit) Refactoring (Verbesserung der Strukturierung sowie Vereinfachung sofort, wann immer Möglichkeiten dafür erkennbar sind) System Metapher (zu lösendes Problem in bildlichen Vergleich einbetten damit sich bei den Beteiligten "automatisch" möglichst übereinstimmende Assoziationen einstellen) Keine Überstunden (denn Überanstrengung führt zu schlechterem Code) Verbindliche Einigung auf Codierstandards (Textgestaltungsregeln, Art und Weise der Nutzung bestimmter Softwarebibliotheken usw.). Extreme Programming wird zu der Gruppe der leichtgewichtigen Prozessmodelle gezählt, die durch Agilität gekennzeichnet sind [6]. Diese neue und von vielen Programmierern als vorteilhaft bewertete Agilität ist nach Martin [8,9] durch folgende Merkmale zu beschreiben: Menschen und direkte konstruktive Zusammenarbeit haben Vorrang vor formalen Prozessen und Werkzeugen, Funktionierende Software (also verlässliche Resultate) im Gegensatz zu ausufernder Dokumentation um ihrer selbst willen, Enge Zusammenarbeit mit dem Kunden im Gegensatz zu vertraglichen Auseinandersetzungen, Rechtzeitige Reaktion auf Veränderungen im Projektablauf im Gegensatz zu Einhaltung eines festen Plans. Eine Anwendung der beschriebenen XP Technologie wird nach [1] bei Vorliegen nachfolgender Projektmerkmale zunächst jedoch nicht empfohlen: Internationale Projekte Teure Hardware Große Teams Festpreisprojekte Frameworkentwicklung. Diese Merkmale treffen im Allgemeinen nicht auf Softwareprojekte in kleinen und mittleren Unternehmen zu. Des Weiteren werden Methoden wie z. B. der höhere Aufwand an Kommunikation und die sehr speziell angelegte Rollenverteilung der Projektmitarbeiter in der Literatur [4] diskutiert. Es bestehen zum Teil Zweifel in der Umsetzbarkeit der Rollen innerhalb von kleineren Teams, da das Teammanagement höheren Aufwand verursacht. Dies ist ein gewichtiger Grund, aus den vielen XP Vorgehensweisen die geeigneten Methoden herauszuarbeiten und in notwendigen Fällen anzupassen oder auch nötigenfalls zu verwerfen.

4 Traditionelles Modell XP Modell Leitbild: Software Entwicklung ist eine durch die vorschriftsmäßige Erzeugung von Papieren gekennzeichnete Ingenieurwissenschaft Leitbild: Software Entwicklung ist in sehr hohem Maße ein Kommunikationsprozess Der Kunde weiß, was seine Anforderungen sind. Das Schwierige ist nur, sie zu erkennen und umzusetzen. Das traditionelle Modell geht von der oft unzutreffenden Annahme aus, dass der Kunde seine Anforderungen vollständig und präzise kennt. Das Problem besteht darin, dieses Wissen an die Programmierer zu übermitteln. Der Kunde erkennt seine Anforderungen erst in Interaktion mit dem Programm hinreichend genau. Das Vorgehensmodell akzeptiert, dass dem Kunden viele Einzelheiten seiner Vorstellungen oft erst im intensiven Dialog mit den Softwarebearbeitern klar werden. Anforderungsanalyse gemäß einem formal festgelegten Pflichtenheft. Anforderungsanalyse auf informellen Story Cards und am lebenden Programm. Späte Produktivschaltung, lange Zyklen Frühe Produktivschaltung, kurze Zyklen Vertrauensbildung durch Zertifizierungen und formale Qualitätssicherungsprozesse. Vertrauensbildung durch schnelle Umsetzung von Kundenwünschen in (kurzzeitig verfügbaren) neuen Versionen des Programms. Metapher: Mondrakete auf ballistischer Bahn (der Kurs steht im Wesentlichen bereits vor dem Start fest). Metapher: Autofahrt (Der Kurs kann während der Fahrt jederzeit den Gegebenheiten angepasst werden). Tabelle 1: Gegenüberstellung der Softwareentwicklungsmodelle nach Baran [1]

5 Weiterentwicklung des Verfahrens Die Methodik des extreme Programming wird ständig verbessert und weiterentwickelt. Inzwischen sind die eingangs genannten zwölf Techniken verfeinert und erweitert worden. Einen neueren Stand der Technik bezüglich der XP Praktiken und XP Regeln zum gibt [5] wieder. Diese Techniken und Praktiken wurden in der Folgezeit noch mehr verfeinert. die Änderungen sind von einem der ursprünglichen Begründer des XP Modells, Kent Beck, in einem neuen Buch [3] vorgestellt worden. XP wurde Ende der 90er von den Softwarevisionären Kent Beck, Ward Cunningham und John Jeffries entwickelt und publiziert. Wolf u. a. [2] beziehen sich auf diese Arbeit und geben hilfreiche, praktische Beispiele für die Umsetzung dieser Techniken in die Praxis. Dies ist besonders hilfreich, weil die Erfahrungen, welche die Autoren beschreiben, aus erster Hand kommen. Sie sind in der eigenen Firma gesammelt worden. Besonders hilfreich für das Verständnis, welche ursprünglichen XP Techniken der ersten Generation (Abb.1) in welche Technik(en) der zweiten Generation (Abb. 2) gemündet haben, ist Roock [10]. Roock erläutert hier kurz und knapp, warum der Übergang in eine neue Generation der XP Techniken erfolgte. Im Wesentlichen wird nun zwischen fünf XP Werten (engl. values), 14 XP Prinzipien (engl. principles) und insgesamt 24 XP Techniken (engl. practices) unterschieden. Echte Kundenbeteiligung (real customer involvement) Vertrag verhandelbaren Umfangs (negotiated scope contract) Bezahlung pro Benutzung (pay per use) Geschichten (stories) Inkrementelle Ausbreitung (incremental deployment) Gemeinsamer Code (shared code) Zusammen Sitzen (sit together) Wochenzyklus (weekly cycle) Tägliche Ausbreitung (daily deployment) Freiraum (slack) Energiegeladene Arbeit (energised work) Komplettes Team (whole team) Kerntechniken (core practices) Quartalszyklus (quarterly cycle) Inkrementeller Entwurf (incremental design) Informative Arbeitsumgebung (informative workspace) Team-Kontinuität (team continuity) 10 min Build Paarprogrammierung (pair programming) Code and Test Eine Codebasis (single code base) Kontinuierliche Integration (continuous integration) Ursprungsanalyse (root cause analysis) Schrumpfende Teams (shrinking teams) Abbildung 2: Darstellung der XP2 Techniken. Gezeigt werden die Kern- bzw. Primärtechniken (schwarz) und die Folgetechniken (weiß).

6 Hierbei unterscheidet man die 24 XP Techniken weiterhin in 13 Kern- bzw. Primärtechniken und 11 Folgetechniken, wie Abbildung 2 veranschaulicht. Wichtig im Zusammenhang der Anwendung von XP in der Softwareindustrie ist die Herausbildung des sogenannten Industrial XP (IXP). Die Firma Industrial Logic, Inc. (siehe mit Sitz in den USA hat diese Modifikation von XP entwickelt. Literatur [1] Baran, Reinhard: Extreme Programming: Ein leichtgewichtiger Softwareentwicklungsprozess. Internet, 2002 Online [2] Wolf, Henning; Roock, Stefan und Lippert, Martin: extreme Programming, Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis. Aufl. 2. Heidelberg : dpunkt.verlag GmbH, Seiten. [3] Beck, Kent: Extreme programming explained: embrace change. Aufl. 2. Upper Saddle River : Addison Wesley, 2004 (The XP series). 224 Seiten. ISBN [4] Bischofs, Ludger: Softwareentwicklungsmodelle für verteilte Teams. Oldenburg: Universität Oldenburg, [5] Wells, J. D.: The rules and practices of extreme Programming, Feb. 2004, [6] Lappe, Torsten: Extreme Programming Darstellung und kritische Würdigung in der Literatur. Köln, Universität Köln, 2002 [7] Wells, J. D.: Extreme Programming Project, Aktualisiert: 28. Feb. 2004, [8] Martin, Robert C.: Agile processes, Martin, Robert C. (Hrsg.) In: Agile Software Development: Principles, Patterns, and Process, 2001, S. 7-16, [9] Martin, Robert C.: Agile methods - The bottom line : Aktualisiert: 29. May. 2003, _The_Bottom_Line.pdf [10] Roock, Stefan: extreme Programming der zweiten Generation : it-agile GmbH, Aktualisiert: 26. Feb. 2005