Prozessmodell zur Stud.IP-Entwicklung
[ Zurück: Was Stud.IP ist und was es nicht ist … | Index: Übersicht | Vor: Kapselung von lokalen Besonderheiten?
Übersicht
Prozessmodell: Agile Softwareentwicklung
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.
Agile Werte
- Individuen und Interaktionen gelten mehr als Prozesse und Tools. Zwar sind wohldefinierte Entwicklungsprozesse und hochentwickelte Entwicklungswerkzeuge wichtig, wesentlich wichtiger ist jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
- Funktionierende Programme gelten mehr als ausführliche Dokumentation. Gut geschriebene Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Außerdem ist eine intuitiv verständliche Software hilfreicher als umfangreiche Dokumentation, die sowieso niemand liest.
- Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Ein Vertrag ist normalerweise die Grundlage für die Zusammenarbeit. Was der Kunde aber wirklich will, kann nur in ständiger Kommunikation mit ihm ermittelt werden.
- Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans. Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.
Agile Prinzipien
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:
- Vorhandene Ressourcen mehrfach verwenden
- einfach ("Keep it small and simple"/KISS-Prinzip)
- zweckmäßig
- kundennah
- Gemeinsamer Code-Besitz (Collective Code Ownership)
- Der Übergang zwischen Prinzipien und Methoden ist fließend.
Agile Methoden
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:
- Paarprogrammierung
- Testgetriebene Entwicklung
- ständige Refaktorisierungen
- Story-Cards
- schnelle Codereviews
Agile Prozesse
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: Agile Softwareentwicklung, 20.02.2008)
Agiler Prozess: Extreme Programming (XP)
(ChaosRadio Podcast über XP)
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.
Werte
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.
Augewählte Praktiken
Permanente Integration:
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.
Testgetriebene Entwicklung bzw. Permanentes Testen:
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.
Refactoring:
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.
Coding-Standards:
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.
Einfaches Design:
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.
Planning-Game:
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.
Flexibilitätsgrad vs. Steifheit
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 Anzahl überflüssiger bzw. ungenutzter Merkmale
- Eine schlechte, fehlende, schwer verständliche oder zu umfangreiche Dokumentation
- Ein schwer verständlicher oder unflexibler Entwurf
- Fehlende Regressionstests
- Ein schwerfälliges Gesamtsystem
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:
- Die testgetriebene Entwicklung sorgt für ein ausreichendes Vorhandensein von Regressionstests und eine verbesserte Testbarkeit der Software
- Das ständige Refactoring führt zur Fehlerbeseitigung, einem leicht verständlichen und flexiblen Entwurf sowie guter Dokumentation
- Die kontinuierliche Integration erfordert zwangsläufig ein leichtgewichtiges Gesamtsystem
- Um die zu entwickelnde Funktionalität zu bestimmen, und zwischen Kunde und Entwicklungsteam auszuarbeiten, werden User-Storys eingesetzt
Verbreitete XP-Kerndisziplinen und Risiken bei herkömmlicher Herangehensweise
(:table border=1 width=100% align=center cellspacing=0 :)
(:cellnr width=20% align=center bgcolor=#CCCCCC :)
Praktik
(:cell width=40% align=center bgcolor=#CCCCCC :)
Richtiges Vorgehen nach XP
(:cell width=40% align=center bgcolor=#CCCCCC :)
Traditionelles oder falsches Vorgehen/Risiko nach XP
(:cellnr align=left bgcolor=#EEEEEE :)
Kommunikation
(:cell align=left bgcolor=#EEEEEE :)
Stetiger Austausch wird gefördert und erwartet.
(:cell align=left bgcolor=#EEEEEE :)
Jeder muss zunächst mal seine Aufgaben lösen.
(:cellnr align=left bgcolor=#EEEEEE :)
Mut
(:cell align=left bgcolor=#EEEEEE :)
Offene Atmosphäre.
(:cell align=left bgcolor=#EEEEEE :)
Angst vor versäumten Terminen und Missverständnissen mit Kunden.
(:cellnr align=left bgcolor=#EEEEEE :)
Kollektives Eigentum
(:cell align=left bgcolor=#EEEEEE :)
Programmcode, Dokumente etc. gehören dem Team.
(:cell align=left bgcolor=#EEEEEE :)
Jeder fühlt sich nur für seine Artefakte verantwortlich.
(:cellnr align=left bgcolor=#EEEEEE :)
Pair-Programming
(:cell align=left bgcolor=#EEEEEE :)
Zu zweit am Rechner.
(:cell align=left bgcolor=#EEEEEE :)
Jeder will und muss zunächst auf seine ihm zugewiesenen Aufgaben schauen.
(:cellnr align=left bgcolor=#EEEEEE :)
Testgetriebene Entwicklung
(:cell align=left bgcolor=#EEEEEE :)
Testen hat sehr hohen Stellenwert.
(:cell align=left bgcolor=#EEEEEE :)
Testen kostet nur Zeit. Wenige manuelle Tests.
(:cellnr align=left bgcolor=#EEEEEE :)
Kundeneinbeziehung
(:cell align=left bgcolor=#EEEEEE :)
Der Kunde wird zur aktiven Mitarbeit aufgerufen.
(:cell align=left bgcolor=#EEEEEE :)
Der Kunde ist selten wirklicher Partner sondern nur die „andere Seite des Vertrages“.
(:cellnr align=left bgcolor=#EEEEEE :)
Refactoring
(:cell align=left bgcolor=#EEEEEE :)
Suboptimales Design und Fehler werden akzeptiert.
(:cell align=left bgcolor=#EEEEEE :)
Fehler sind verpönt. Erstellte Artefakte laufen angeblich immer direkt perfekt.
(:cellnr align=left bgcolor=#EEEEEE :)
Keine Überstunden
(:cell align=left bgcolor=#EEEEEE :)
Einhaltung der regulären Arbeitszeit.
(:cell align=left bgcolor=#EEEEEE :)
Stetige, regelmäßige Überschreitung der regulären Arbeitszeit.
(:cellnr align=left bgcolor=#EEEEEE :)
Iterationen
(:cell align=left bgcolor=#EEEEEE :)
Ein Release wird in viele handliche Iterationen unterteilt.
(:cell align=left bgcolor=#EEEEEE :)
Iterationen sind nicht nötig, es wird an einem Release gearbeitet.
(:cellnr align=left bgcolor=#EEEEEE :)
Stand-up-Meeting
(:cell align=left bgcolor=#EEEEEE :)
Täglicher, strukturierter Austausch.
(:cell align=left bgcolor=#EEEEEE :)
Große, lange, seltenere Projektmeetings. Die Personenanzahl und der Inhalt sind häufig zu aufgebläht.
(:cellnr align=left bgcolor=#EEEEEE :)
Dokumentation
(:cell align=left bgcolor=#EEEEEE :)
Täglicher, strukturierter Austausch. Große, lange, seltenere Projektmeetings.
(:cell align=left bgcolor=#EEEEEE :)
Wichtiges Artefakt. Alles muss standardisiert dokumentiert sein. Dokumentation wird aber nicht genutzt.
(:cellnr align=left bgcolor=#EEEEEE :)
Metapher
(:cell align=left bgcolor=#EEEEEE :)
Ein gemeinsames Vokabular.
(:cell align=left bgcolor=#EEEEEE :)
Kunde und Entwicklung sprechen in zwei Sprachen, häufig aneinander vorbei.
(:cellnr align=left bgcolor=#EEEEEE :)
Team
(:cell align=left bgcolor=#EEEEEE :)
Das Team ist sehr wichtig. Es existieren keine Rollen. Feedback wird von jedem erwartet.
(:cell align=left bgcolor=#EEEEEE :)
Spezialistentum. Abschottung. Wissensmonopole.
(:cellnr align=left bgcolor=#EEEEEE :)
Standards
(:cell align=left bgcolor=#EEEEEE :)
Standards, wo es sinnvoll erscheint.
(:cell align=left bgcolor=#EEEEEE :)
Überregulierung. Starrer Prozess.
(:cellnr align=left bgcolor=#EEEEEE :)
Qualität
(:cell align=left bgcolor=#EEEEEE :)
Inhärenter Bestandteil.
(:cell align=left bgcolor=#EEEEEE :)
Der Faktor, der als erster vernachlässigt wird, wenn Zeit oder Geld knapp werden.
(:tableend:)
(Quelle: Extreme Programming, 20.02.2008)
Stud.IP Prozessmodell
Regeln für Stud.IP Enhancement Proposals (StEPs)
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:
- Erweiterung/Idee wird vorgestellt (Developer-Board)
- jemand aus der Core-Group meldet sich als "sponsor" und schlägt vor ein StEP draus zu machen
- StEP wird gemeinsam formuliert (in der entsprechenden Veranstaltung) und dort weiter diskutiert [ein entsprechender Hinweis wird dann im developer-board gepostet, so dass Interessenten wissen, wo es weitergeht]
- Abstimmung über StEP durch die Core-Group
- Einchecken in Stud.IP unstable durch core-group-Mitglied
- weitere Diskussion innerhalb der StEP od. ggf. eigener Veranstaltung
Ein StEP muss folgendes beinhalten :
- Ziel
- Sehr knappe Zusammenfassung des Proposals (Titel/Überschrift)
- Beschreibung:
- Problembeschreibung bzw. Ziel der Änderung
- Begründung, warum das Proposal sinnvoll bzw. notwendig erscheint
- Eine Widerlegung der wichtigsten Einwäne sollte stichpunktartig enthalten sein.
- Maßnahmen (Überblick)
- Knappe Beschreibung einer Lösung ohne Implementationsdetails
- sollte dennoch in Grundzügen auf wichtige Punkte eingehen (neue DB-Tabellen, Benutzung von vorhandenen Funktionalitäten,…).
- Maßnahmen (Details)
- konkrete Beschreibung, die keine wesentlichen Fragen hinsichtlich technischer Umsetzung und Interfacegestaltung offen lässt.
- kann schrittweise entwickelt werden
- Kurzbezeichnung des Integrationsaufwandes
- gering: eigenständiges Modul, das über Konfigurationsschalter komplett ein-/ausschaltbar ist oder Änderungen an einzelnen Dateien, die keine Änderungen an Datenbank oder systemweit genutzten Datenstrukturen erfordern
- mittel: tief greifende Änderung an wenigen Dateien, die geringe Modifikationen der Datenbankstruktur erfordern und keine systemweiten Auswirkungen haben, oder geringfügige Änderungen an vielen Dateien, die gut überschaubare systemweite Auswirkungen haben
- hoch: alle Änderungen mit gravierenden systemweiten Auswirkungen
- Durchführung
- Verbindliches Angebot eines Durchführungsplanes, bestehend aus:
- klar benannter Zuständigkeit für Implementation, Testing und Pflege
- Aufwandsabschätzung für Implementation, Testing und Pflege
- mit dem Releasezyklus abgestimmter Zeitplan
Attach:Stud.IP-Entwicklungszyklus.pdf
