1 May, Überblick. Agile Softwareentwicklung. Schwierigkeiten. Software Lebenszyklus: was nicht passieren sollte

Transkript

1 Überblick Agile Softwareentwicklung Was ist agile Softwareentwicklung EXtrem Programming Srump PD Dr.-Ing. Gabriella Kókai 2 Software Lebenszyklus: was nicht passieren sollte Schwierigkeiten Kunde weiss nicht genau, was er braucht (kann er z.t. nicht) Nicht alle Anforderungen und Stakeholder bekannt Kunde hat widersprüchliche Anforderungen, z.t. wg. Politik Politik, Management Risiken Auftragnehmer versteht nicht genau, was der Kunde will Auftragnehmer unterschätzt / überschätzt Aufwände (Planung) Änderungen in den Prioritäten, Geschäftsprozessen etc. während des Projektes Projekt in komplexe Projektlandschaft eingebunden Technische Risiken, z.b. Infrastruktur hält nicht was sie verspricht 3 4 1

2 Standard Modelle Wasserfall-Modell V-Modell Spiral-Modell Grafik von Iteratec GmbH, aus Starke: Effektive Softwarearchitekturen, Hanser; SWP-Paradigmen im historischen Überblick Agile Manifesto Agile Manifesto der Agile Alliance (Februar 2001) durch Vertreter von: 7 8 2

3 Das Manifest der Agilen Software-Entwicklung Durch das Entwickeln von Software und indem wir anderen bei der Entwicklung helfen, erschließen wir bessere Wege der Software- Entwicklung. Durch diese Arbeit haben wir folgende Werte zu schätzen gelernt: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Funktionierende Software ist wichtiger als umfassende Dokumentation. Kundenzusammenarbeit ist wichtiger als Vertragsverhandlungen. Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen. (Kent Beck, Alistair Cockburn, Martin Fowler et al., Feb 2001) 9 Prinzipien hinter dem agilen Manifest Die 17 Unterzeichner des Agile Manifesto konnten sich auf 12 Prinzipien einigen, die hinter diesem Manifest stehen. Auf detaillierteren Ebenen war keine Einigung mehr möglich. 12 Prinzipien als Grundlage des Vergleichs mit den klassischen Erfolgsfaktoren aus Balzert und DeMarco : 10 Prinzipien Nr Prinzipien Nr. 3+4 Die höchste Priorität liegt darin, den Kunden durch frühe und zahlreiche Lieferungen hochwertiger Software zufrieden zu stellen. Funktionierende Software muss regelmäßig geliefert werden, innerhalb weniger Monate, wobei der kürzeren Zeitspanne eindeutig der Vorzug zu geben ist. Im Rahmen der Software-Entwicklung bedeutet Prototyp ein funktionsfähiges Produkt, das bereits vor der Entwicklung desendgültigen Software- Produkts vorliegt. (Balzert) 11 Funktionierende Software ist der primäre Maßstab für den Fortschritt. Veränderte Anforderungen sollten immer positiv aufgenommen werden, selbst wenn sie sich erst spät in der Entwicklung zeigen. Agile Verfahren nutzen Änderungen zum Wettbewerbsvorteil des Kunden. Notwendig zur Planung gehört die Kontrolle, d. h. das möglichst lückenlose Messen des Entwicklungsfortschritts am Plan. [ ] Meilensteinberichte oder Projektstatusberichte dienen zur Information des Projektleiters. (Balzert) [ ] ein System [muß] so strukturiert sein, daß Änderungen während der Systementwicklung und am fertigen System überschaubar und leicht durchführbar sind. (Balzert) 12 3

4 Prinzipien Nr. 5+6 Prinzipien Nr Geschäftsleute und Entwickler arbeiten täglich gemeinsam im Projekt. Bauen Sie ihr Projekt um einzelne motivierte Mitarbeiter herum auf. Geben Sie diesen Mitarbeitern die Umgebung und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie ihre Arbeit gut machen. Erstellung der Anforderungen im Dialog mit dem Auftraggeber und u. U. den Benutzern. (Balzert) gute Leute einstellen diese glücklich machen, damit sie bleiben sie möglichst frei arbeiten lassen (DeMarco) Die effizienteste und effektivste Methode zur Informationsübermittlung für und innerhalb eines Entwicklungsteams besteht in der direkten Kommunikation. Die besten Architekturen, Anforderungen und Designs entwickeln sich in Teams, die sich selbst organisieren. Ständige Aufmerksamkeit gegenüber technisch hervorragender Qualität sowie gutem Design verbessert die Agilität. Die kontrollierte dezentralisierte Organisationsstruktur [ ] Jeder kommuniziert mit jedem und tauscht auch seine erstellten Teilprodukte [ ] aus. (Balzert) Änderbarkeit (modifiability): Grad, in dem ein Produkt den Einbau von Änderungen erleichtert, wenn die Art der gewünschten Änderung festgelegt ist. (Balzert) Prinzipien Nr EXtrem Programming Agile Prozesse fördern nachhaltige Entwicklung. Geldgeber, Entwickler und Benutzer sollten endlos ein beständiges Tempo beibehalten können. Schlichtheit - die Kunst, die Menge der nicht geleisteten Die Teams müssen in regelmäßigen Abständen darüber beraten, wie sie noch effektiver arbeiten können und ihr Verhalten dann entsprechend anpassen. Arbeit zu maximieren - ist essenziell. Qualitätssicherung durch Kollegen: In Firmen, in denen qualitätssichernde Maßnahmen unter den Mitarbeitern aktiv betrieben werden [ ] gibt es einen natürlichen Trend zur Vereinheitlichung von Methoden. (DeMarco) Was ist XP? - Grundlagen XP bezeichnet sich als leichte Methode des Software Engieneerings Prinzipien und Grundwerte von XP Kommunikation Einfachkeit Schnelle Rückmeldung/ konkret Experimente Inkrementelle Änderung Mut Travel light

5 extreme Programming:Abhängigkeiten Was ist extrem an XP Code review ist gut paarweise Programmieren Testen ist gut ständige Test (Programmierer und Kunde) Entwurf ist gut ständiges überarbeiten des Entwurfs Einfachkeit ist gut implementieren das Einfachste das funktioniert.. Wann sollte XP eingesetzt werden? In many software environments dynamically changing requirements is the only constant. (Don Well auf Keine klaren Vorstellungen über Funktionalität Sich ständig ändernde Anforderungen Hohes Projektrisiko (Erfahrung/Fristen) Direkte Einbeziehung des Kunden von Anfang bis Ende Kleines Entwicklerteam (K.B.: 2-10 Personen) Aufwandschätzung Voraussetzungen Einfach halten (Keep it simple) Vergleiche mit früheren Projekten (Use what happened in the past) Erfahrungen (Learn from the experience) Teamarbeit Spike schreiben, wenn keine Erfahrung Commitment Business Value (high-value first) Technisches Risiko (high-risk first) Verantwortlichkeit nur mit hoch qualifizierten Teams (nur qualifizierte Leute wissen, was zu tun ist) kleine Teams bis zu 10 Personen (Große Teams führen zur Kommunikationsexplosion) Team braucht gemeinsamen Raum Eigenbrödler, Star-Architekten und Gurus nicht gefragt (?) Management-Akzeptanz Wiederholbarkeit der Ergebnisse nicht über Prozess gewährleistet Planbarkeit, Verträge bei änderbarem Prozess? Gutes Arbeiten von Chaos unterscheidbar?

6 Iterationsplanung nur Entwickler aufteilen der Benutzergeschichten in einzelne Tasks Zeithorizont 1-4 Wochen (eine Iteration) Praxis - Lebenszyklus eines XP Projectes XP kann in vier Bereiche eingeteilt werden: Planen Ausarbeitung der Anforderungen durch Team und Kunde in Form von Stories Einteilen des Projektes in Iterationen Kodieren Code wird nach vereinbarten Standards entwickelt Der Code wird immer in Paar-Programmierung erzeugt Modellieren Einfache Strukturen mit einheitlicher Systemmetapher Refactoring soviel und sooft wie möglich Testen Jedes Codefragment wird getestet Testfälle werden vor dem Programmcode geschrieben Praxis - Lebenszyklus eines XP Projectes Planungsstrategie Customer Story Beschreibung einer Anforderung vom Kunden verfasst Funktionalitätsmass Grundlage für Akzeptanztests The story represents a concept and is not a detailed specification. A user story is nothing more than an agreement that the customer and developers will talk together about a feature. (Kent Beck)

7 Planungsstrategie Planungsspiel Sowohl in der Releaseplanung als auch in der Iterationsplanung eingesetzt Abstimmen der Anfoderungen des Kunden mit der Programmierkapazität Entscheidungen im Planungsspiel Umfang Priorität Releaseplanung Entwicklungsstrategie Projekt auf die gesamte Dauer geschätzt lediglich Momentaufnahme Aufwand der Benutzergeschichten in Ideal Programming Weeks messen Zusammenstellung der Releases Zeitpunkt der Releases

8 Merkmalen Merkmale Schlichtes Design Änderungen im Design der Normalfall geringstmöglicher Aufwand Über die Zeit weiterentwickelt Fortlaufende Integration Nachdem eine Aufgabe vollständig implementiert wurde wird die Codeänderung sofort in das System integriert. Integration nur wenn Unit Tests 100% separater Arbeitsplatz Kleine Releases Investition soll früh rentieren Anforderungen ändern sich während der Projektlaufzeit Projektverlauf einfacher zu beeinflussen Collective Code Ownership: Jeder Programmierer darf jedes Stück Code jederzeit editieren Vorteile von Collective Code Ownership Komplexer Code schneller eliminiert Projektrisiko reduziert; geringere Abhängigkeit vom einzelnen Programmierer Wissen wird im Team verteilt Abwechslung für Programmierer Merkmale Merkmale Pair Programming Dialog zwischen zwei Entwicklern, die zusammen programmieren, anlysieren, designen und testen. höhere Qualität höhere Produktivität Wissensunterschiede im Team reduziert (Paarweises Lernen) zufriedene Entwickler Refactoring Vereinfachung des Code Beispiel: switch -Statements ersetzen durch Polymorphismus (Martin Fowler: "Refactoring - Improving the Design of Existing Code", Addison-Wesley, ISBN ) Kunde vor Ort Kunde Bestandteil des Programmierteams Beantwortet Detailfragen in Bezug auf die Customer Stories

9 Teststrategie Teststrategie The idea is that the developers are responsible for proving to their customers that the code works correctly; it's not the customer's job to prove that the code is broken. -- Kent Beck Nach Refactoring kann verifiziert werden, dass Änderung keine Nebeneffekte hat Kunde und Entwickler sind überzeugt von der Qualität Unit Tests Interface einer Methode ist unklar Implementation ist kompliziert seltene Ausnahme im Code Refactoring steht an xunit Testing Framework, Funktionale Tests (Akzeptanztests) Kunde kann prüfen ob System funktioniert Programmierer sieht was fehlt Müssen bis zum Ende des Release nicht zu 100% durchlaufen Nice Was ist Scrum? Scrum ist just an interaction model for teams and stakeholders eine PL-Methodik, welche stark auf das Erreichen von geschäftsrelevanten Zielen fokussiert ist (ROI) eine Sammlung von einfachen Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Software- Entwicklung Eine Entwicklungsperiode (Sprint) wird auf 30 Tage terminiert Jede Aufgabe wird im Team gelöst Am Ende des Sprints: Die entwickelten Funktionen werden präsentiert -echte Funktionalität, keine Screen-Shots Nach der Präsentation: Feedback einholen, Ideen und Vorschläge für die nächsten 30 Tage sammeln

10 Wie funktioniert Scrum ( Scrum : Gedränge beim Rugby) Scrum Teams mit maximal 7 Personen mit unterschiedlichen Fähigkeiten, einem Leiter (Scrum Master) Bei größeren Teams: mehrere Teilteams durch Scrum Master Koordiniert Zentrales Steuerungselement: Scrum meetings; jeden Tag 15 Minuten: was habe ich seit letztem Meeting gemacht? was werde ich bis zum nächsten Meeting machen? was hat meine Arbeit behindert? Scrum Master ist Koordinator; beseitigt Behinderungen; kommuniziert im Unternehmen Arbeitsablauf im Team wird vom Team selbst geregelt 37 Scrum Master Zentrale Person in Scrum Schnittstelle Team Management Verantwortlich für Durchsetzung der Scrum Regeln Unterstützt Management beim Finden eines Product Owners und beim Bilden des Scrum Teams Unterstützt Team beim Festlegen von Sprint Goal und Sprint Backlog Grafik aus Seminararbeit von Raffael Schweizer, Uni Zürich 38 Wie funktioniert Scrum Wie funktioniert Scrum Scrum Master Keine vorgeschriebenen Rollen Zusammensetzung so, dass Sprint Goal erreicht werden kann Umfang kann bei Unterschätzung des Aufwands reduziert werden. Sprint Goal muss erreicht werden! Sprint Planning Meeting Bestimmung Sprint Goal Definition Umfang für nächsten Sprint Aufteilung in Aufgaben (4-16 h) Sprint Backlog Während Sprint ständig aktualisiert Für alle einsehbar

11 Sprint Dauer: 30 Tage Team fokussiert auf Sprint Goal Völlig autonom bzgl. Vorgehen Sprint Backlog nur durch Team veränderbar Produziert neue Produktversion Tägliche Scrum Meetings mit Scrum Master 41 Daily Scrum Meeting Kurzes Treffen (ca.15 Min) Geleitet durch Scrum Master 3 Fragen: Was hast Du seit dem letzten Treffen erledigt? Was wirst Du bis zum nächsten Treffen erledigen? Was hat Dich bei Deiner Arbeit behindert? Verbessert Kommunikation Alle sind über Projektstand informiert Macht weitere Treffen überflüssig Hilft bei der Beseitigung von Hindernissen Pigsand chickensrule Diskussionen in anschliessenden Treffen 42 Lesehinweise Sprint Review Meeting Team stellt neue Produktversion vor und berichtet über Verlauf des Sprints Entscheidungsgrundlage für Management und Kunde über weiteres Vorgehen. (Release / Neuausrichtung / Abbruch /...) Anpassung Product Backlog Neues Sprint Planning Meeting Guter Überblick: Agility Kompakt, Spektrum Verlag Extreme Programming das Manifest, Extreme Programming Planen Methoden-URLs XP SCRUM Agile URLs

12 Literature: Aufgaben Volker Brosche, Michael Koch, Dr. Achim Selz 1822 S inform Software GmbH:Agile Softwareentwicklung Klassische Erfolgsfaktoren neu verpackt? Unser Kunde: Dr. Thomas Halva Labella Gerd Beneken Software & Systems Engineering Fakultät für Informatik, TU München:Agile Methoden