Auf dieser Seite... (ausblenden)
Ein Vorgehensmodell dient dazu, die Softwareentwicklung übersichtlicher zu gestalten und in der Komplexität beherrschbar zu machen. Da komplexe Software nur schwer zu erstellen und zu warten ist, bedienen sich Softwareentwickler eines Planes zur Entwicklung von Software. Dieser Plan (das Vorgehensmodell) unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen. Die Software wird somit Schritt für Schritt fertiggestellt. Vorgehensmodelle spalten einzelne Aktivitäten auf verschiedene Phasen im Entwicklungsprozess auf und diese werden dann – u. U. mit geringen Modifikationen – einmal oder mehrmals durchlaufen.
Die Agile Softwareentwicklung beschäftigt sich mit Methoden, die den Entwickler kreativ arbeiten und Verwaltungsaspekte zurücktreten lassen, d.h. sie zeichnet sich durch geringen bürokratischen Aufwand und wenige, flexible Regeln aus.
Das Ziel ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen.
Agile Werte bilden das Fundament. Agile Prinzipien basieren auf den Agilen Werten und bilden Handlungsgrundsätze. Agile Methoden sind konkrete Verfahren während der Softwareentwicklung, die sich auf die Werte und Prinzipien stützen. Der Agile Prozess ist die Zusammenfassung aller angewandten Methoden und dient der Agilen Softwareentwicklung.
Ein Prinzip beschreibt kein direkt umsetzbares Verfahren, sondern einen Grundsatz, den man auf Methoden, die einen Prozess bilden sollen, anwenden kann. Ein Agiles Prinzip ist also ein Leitsatz für die agile Arbeit.
Beispiele für Agile Prinzipien:
Ein Kennzeichen vieler agiler Methoden ist, dass sie in einem Prozess dazu dienen können, die Aufwandskurve möglichst flach zu halten. Als Leitsatz für agile Methoden gilt: „Je mehr Du nach Plan arbeitest, um so mehr bekommst Du das, was Du geplant hast, aber nicht das, was Du brauchst.“ Daraus resultieren einige Prinzipien des Agile Modeling und des Extreme Programmings.
Beispiele für Agile Methoden:
Ziel ist, den Softwareentwicklungsprozess durch Abbau der Bürokratisierung und durch die stärkere Berücksichtigung der menschlichen Aspekte effektiver und für alle Beteiligten vorteilhafter zu gestalten. Die Einfachheit der meisten Agilen Prozesse wird unterstrichen, indem sie sich lediglich als Zusammenfassung einiger Agiler Methoden verstehen.
Den meisten Agilen Prozessen liegt zu Grunde, dass sie versuchen, die reine Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen, welche dann in regelmäßigen, kurzen Abständen dem Kunden zur gemeinsamen Abstimmung vorgelegt werden kann. Auf diese Weise soll es jederzeit möglich sein, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen.
Allen agilen Prozessen ist gemeinsam, dass sie sich zahlreicher Methoden bedienen, die Aufwandskurve möglichst flach zu halten. Inzwischen gibt es eine Vielzahl von agilen Prozessen. Der Bekannteste ist Extreme Programming (XP).
(Quelle: Wikipedia (20.02.2008): Agile Softwareentwicklung. Online im Internet: URL: http://de.wikipedia.org/wiki/Agile_Softwareentwicklung [20.02.2008])
Extreme-Programming (XP), auch Extremprogrammierung, ist ein flexibles Vorgehensmodell in der Softwaretechnik, das sich den Anforderungen des Kunden in wiederholten kleinen Schritten unter Verwendung von Rückkoppelungen sowie einer kommunikationsintensiven Herangehensweise zielgerichtet annähert.
XP bejaht die Ungewissheit, mit der Softwareentwicklung verbunden ist, stellt aber keinen Freibrief zum Chaos aus. Es folgt vielmehr einem klaren, strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stetige Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist dabei eine Grundsäule dieses Vorgehensmodells
Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt sowie eine höhere Softwarequalität und Zufriedenheit des Kunden als mit traditionellen Ansätzen erreichbar sein.
Angefangen mit einer ersten kleinen Version der Software vergrößert sich der Entwicklungsrahmen ständig. Neue Funktionalität wird permanent entwickelt, integriert und getestet.
XP definiert fünf zentrale Werte, abstrakte Elemente, die von zentraler Bedeutung sind: Kommunikation, Einfachheit, Feedback, Mut und Respekt.
Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess selbst erfordert hohe Kommunikationsbereitschaft. Es existiert ein stetiger Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden. Es kommen auch Personen zu Wort, die in einer gerade diskutierten technischen Aufgabenstellung keine Experten sind. So werden sie miteinbezogen, es gibt zusätzliches Feedback und jeder fühlt sich dem Team und dem Produkt verpflichtet. Stetige Kommunikation mit dem Kunden, Aufnahme seines Feedbacks und Erfüllung seiner Wünsche, also auch eines lauffähiges Produktes, das seinen Wünschen voll entspricht, ist wichtiger als Vertragsverhandlungen. Die Kommunikation zeichnet sich ferner durch einen respektvollen Umgang aus, sowohl im Team untereinander als auch mit dem Kunden. Unterschiedliche Meinungen werden akzeptiert.
Die Entwickler sollen mutig sein und die Kommunikation offen gestalten. Falls eine Anforderung nicht in einer Iteration umgesetzt werden kann, wird in offener und ehrlicher Art und Weise direkt darauf hingewiesen. Es muss eine Atmosphäre geschaffen werden, die herkömmliche Störungen (wie unnatürlichen Konkurrenzkampf innerhalb des Teams zu Lasten des Produktes) minimiert. Um die Offenheit und den Mut zu fördern und gruppendynamischen, psychologischen Schwierigkeiten entgegenzutreten, kann bewusst ein Doomsayer zur offenen, zeitnahen Aussprache von schlechten Nachrichten oder möglichen Schwierigkeiten oder auch ein Advocatus Diaboli eingesetzt werden.
Es soll die einfachste Lösung für eine Problemstellung realisiert werden. In jeder Iteration konzentriert sich das komplette Team genau auf die momentan umzusetzenden Anforderungen. Die Lösungen sind technisch immer möglichst einfach zu halten.
Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen. Je häufiger integriert wird, desto höher wird laut XP die eintretende Routine. Fehler werden damit früh aufgedeckt. Die mit der Integration verbundenen Kosten sollen fast auf Null minimiert werden, da die Integration zu einem täglichen Schritt gehört der weitestgehend vollautomatisiert und selbst stabil und durchgetestet sein muss.
Bei der testgetriebenen Entwicklung werden erst die Modultests (Unit-Test) geschrieben bevor die eigentliche Funktionalität programmiert wird. Der Entwickler befasst sich dadurch früh mit dem Design des Codes und überdenkt seine Programmierarbeit genau. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht in diesem Zusammenhang auch von Grey-Box-Tests. Die Tests sind automatisiert. Im Laufe einer Integration werden Integrationstests durchgeführt. Es wird zwischen Regressionstest und Modultest unterschieden. Während Modultests (Unit-Tests) einzelne Module testen, ist ein Regressionstest die kollektive Ausführung aller Tests um die unveränderte Lauffähigkeit der alten, bereits vor der Iteration existenten Funktionalität zu überprüfen. Auch Performancetests, bei denen die Leistungs- und Geschwindigkeitsmerkmale in Bezug auf die geforderten Werte gemessen werden, sind üblich. Der Entwickler bekommt Rückmeldung (Feedback) wie viele und welche Tests nicht erfolgreich waren. Ein Akzeptanztest ist die Präsentation des Standes des Produktes, um die Zufriedenheit des Kunden und die Nutzbarkeit zu validieren.
Laufendes Refactoring, ständige Architektur, Design- und Code-Verbesserungen, auch um Anti-Patterns umgehend erkennen und beseitigen zu können. XP bejaht die Existenz von Code, der am Beginn nicht perfekt ist. Stattdessen sind sämtliche Teile einem stetigen Review unterworfen. Die Behebung von gefundenen, optimierungsfähigen Stellen wird gewöhnlich sofort durchgeführt oder als Fehler (Bug) definiert, der in einer späteren Iteration behoben wird.
Das Team hält sich bei der Programmierarbeit an Standards, welche erst die gemeinschaftliche Verantwortung des Teams bei dieser Aufgabe ermöglichen. Wechselnder Einsatz der Entwickler in allen Bereichen der Software ist laut XP nur durch gemeinsame Standards sinnvoll möglich.
Es soll die einfachste Lösung angestrebt werden, also diejenige, die genau das Gewünschte erreicht (und nicht mehr). Bewusst allgemein (generisch) gehaltene Lösungen oder vorbereitende Maßnahmen für potentiell zukünftige Anforderungen werden vermieden. Zum Thema Einfachheit sind die umgangssprachlichen Akronyme KISS („Keep it small and simple“) und YAGNI („You Ain’t Gonna Need It”) verbreitet.
Neue Versionen der Software werden in einem Planning-Game, auch als Planning-Poker bekannt, spezifiziert und der Aufwand zu deren Umsetzung abgeschätzt. An diesem iterativen Prozess sind sowohl Entwicklungsmannschaft als auch Kunde beteiligt.
Eine der theoretischen Grundlagen des Extreme-Programming ist der Flexibilitätsgrad des zu entwickelnden Softwaresystems. XP geht von einem mindestens proportionalen Zusammenhang zwischen dem Gegenteil der Flexibilität, der sogenannten Steifheit, und den Pflegekosten zur Fehlerbehebung oder Erweiterung des Systems aus. Je flexibler ein Softwaresystem, desto geringer sind die Pflege-Kosten, je steifer, desto höher.
Einige Steifheitskriterien:
Die Flexibilitätskriterien sind das Gegenteil der Steifheitskriterien, zum Beispiel ein leicht verständlicher und flexibler Entwurf.
Einige der als Bestandteil des Extreme-Programming definierten Mechanismen dienen laut XP der Erhöhung der Flexibilität:
Praktik |
Richtiges Vorgehen nach XP |
Traditionelles oder falsches Vorgehen/Risiko nach XP |
Kommunikation |
Stetiger Austausch wird gefördert und erwartet. |
Jeder muss zunächst mal seine Aufgaben lösen. |
Mut |
Offene Atmosphäre. |
Angst vor versäumten Terminen und Missverständnissen mit Kunden. |
Kollektives Eigentum |
Programmcode, Dokumente etc. gehören dem Team. |
Jeder fühlt sich nur für seine Artefakte verantwortlich. |
Pair-Programming |
Zu zweit am Rechner. |
Jeder will und muss zunächst auf seine ihm zugewiesenen Aufgaben schauen. |
Testgetriebene Entwicklung |
Testen hat sehr hohen Stellenwert. |
Testen kostet nur Zeit. Wenige manuelle Tests. |
Kundeneinbeziehung |
Der Kunde wird zur aktiven Mitarbeit aufgerufen. |
Der Kunde ist selten wirklicher Partner sondern nur die „andere Seite des Vertrages“. |
Refactoring |
Suboptimales Design und Fehler werden akzeptiert. |
Fehler sind verpönt. Erstellte Artefakte laufen angeblich immer direkt perfekt. |
Keine Überstunden |
Einhaltung der regulären Arbeitszeit. |
Stetige, regelmäßige Überschreitung der regulären Arbeitszeit. |
Iterationen |
Ein Release wird in viele handliche Iterationen unterteilt. |
Iterationen sind nicht nötig, es wird an einem Release gearbeitet. |
Stand-up-Meeting |
Täglicher, strukturierter Austausch. |
Große, lange, seltenere Projektmeetings. Die Personenanzahl und der Inhalt sind häufig zu aufgebläht. |
Dokumentation |
Täglicher, strukturierter Austausch. Große, lange, seltenere Projektmeetings. |
Wichtiges Artefakt. Alles muss standardisiert dokumentiert sein. Dokumentation wird aber nicht genutzt. |
Metapher |
Ein gemeinsames Vokabular. |
Kunde und Entwicklung sprechen in zwei Sprachen, häufig aneinander vorbei. |
Team |
Das Team ist sehr wichtig. Es existieren keine Rollen. Feedback wird von jedem erwartet. |
Spezialistentum. Abschottung. Wissensmonopole. |
Standards |
Standards, wo es sinnvoll erscheint. |
Überregulierung. Starrer Prozess. |
Qualität |
Inhärenter Bestandteil. |
Der Faktor, der als erster vernachlässigt wird, wenn Zeit oder Geld knapp werden. |
(Quelle: Wikipedia (20.02.2008): Extreme Programing. Online im Internet: URL: http://de.wikipedia.org/wiki/Extreme_Programming [20.02.2008])
Grundsätzlich: Jede Stud.IP-Erweiterung oder -Änderung für das offizielle Release, die kein Bugfix ist, wird durch ein Stud.IP-Enhancement-Proposal (StEP) vorgeschlagen, anschließend diskutiert und nach erfolgreicher Abstimmung programmiert und in das Release aufgenommen.
Die letztendlich Entscheidung über die Aufnahme eines Features liegt bei der Developer-Core-Group, nur deren Mitglieder können Änderungen direkt in das CVS einchecken. Deshalb ist es für Entwickler, die (noch?) nicht zur Core-Group gehören sinnvoll, sich ein Core-Group-Mitglied zu suchen, das den StEP-Prozess begleitet.
Jeder kann einen StEP unter der Bedingungen einbringen, dass sich jemand aus der Core-Group als sog. "sponsor" gefunden hat. Dies geschieht im Developer-Board und stellt sicher, dass von Seiten der Core-Group ein Koordinationspartner (Stichwort Abstimmungen) am StEP beteiligt ist. Ggf. ist so auch ein - zumindest vorerst indirekter - CVS Zugang zu studip-unstable möglich.
Das Vorgehen zusammengefasst:
Ein StEP muss folgendes beinhalten :