Trends im Software Engineering – WS0910 · 2017. 1. 10. · • Warum agil? • Agile Methoden...

Advanced Software Engineering – WS0910 – Kapitel1Dr. Dominik Haneberg

AGILE METHODEN

15.12.2009 Advanced Software Engineering 11

Inhalte dieses Kapitels

• Warum agil?• Agile Methoden vs. schwergewichtige Prozesse• Das „Agile Manifesto“• Agile Werte, Prinzipien, Praktiken und Methodiken• XP, Scrum und Crystal• Kritische Betrachtung• Indikation und Kontraindikation


Agil? Warum denn auch das noch?

Softwarekrise [1968, NATO-Konferenz in Garmisch]

Wasserfallmodell[1970]

V-Modell[1986]

Unified Process[1996]

2009: 30 % der Softwareprojekte voll erfolgreich


Vorführender

Präsentationsnotizen

Seit der NATO-Konferenz (F.L.Baur Software-Engineering erfunden) wurden immer elaboriertere Entwicklungsprozesse vorgeschlagen und gleichzeitig wurden die Systeme immer größer. Signifikant besser geworden ist es nicht.

Erfolgsgeschichte Software Engineering?

• Nach 40 Jahren Softwaretechnik hat sich der relative Anteil der erfolgreichen, problematischen und total abgestürzten Projekte nicht signifikant verschoben

• Andererseits: Softwareprojekte sind heute um Größenordnungen komplexer als vor 40 Jahren

• Methodischen Fortschritte durch Komplexitätszuwachs „verbraucht“

• Andere Sichtweise: Die eingesetzten Prozesse fokussieren nicht auf das, was eigentlich wichtig ist


Vorführender


Die etablierten Prozesse sind schwergewichtig: Sie setzen auf vollständige Analyse zu Anfang und Abarbeiten des daraus entwickelten Plans. Gibt nur ein Problem dabei: Nächste FOLIE!


Vorführender


Wir haben das Problem, das viel von den anfangs erstellten Plänen sich mit Dingen beschäftigen, die dann entweder nicht gebraucht werden, falsch verstanden wurden oder so nicht funktionieren…jedenfalls in vielen Fällen Daher die Idee: Änderung nicht mehr als Übel betrachten, sondern als ganz normaler Teil des Geschäfts und dementsprechend Prozesse gestalten, die mit Veränderung besser umgehen können

Agile vs. schwergewichtige Prozesse

Schwergewichtige Prozesse Agile Prozesse

Dokumentenzentriert Codezentriert

Up-Front Design Minimale Analyse zu Beginn

Reglementiert Adaptiv, Prozess wird angepasst

Abarbeitung eines Plans Ständige Anpassung der Ziele

Lange Releasezyklen Häufiges Deployment


Das Agile Manifest

• 2001 von vielen Vertretern leichtgewichtiger Vorgehensweisen auf einer Tagung aus der Taufe gehoben

• Bewusst politisierender Gegenentwurf zu den etablierten Vorgehensweisen

• Argumentativ stark aus Praxis/Projekterfahrung geprägt

• Hat viele Unterstützer gefunden


Vorführender


Das Agile Manifest ist die Zusammenfassung der Prinzipien, die den agilen Methoden zugrunde liegen.

Wir entdecken Wege, Software besser zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Arbeit haben wir Folgendes zu schätzen gelernt:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.• Funktionierende Software ist wichtiger als umfassende Dokumentation.• Die Zusammenarbeit mit dem Kunden ist wichtiger als

Vertragsverhandlungen.• Sich auf unbekannte Änderungen einzustellen, ist wichtiger als einem Plan zu

folgen.

Wir schätzen aufgrund unserer Erfahrung die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite höher.

Das Agile Manifest


www.agilemanifesto.org

Vorführender


Teil 1: Die Aussagen sind Ergebnisse von Praxiserfahrung, keine Wunschvorstellungen Teil 3: Prozesse und Werkzeuge, Dokumentation, Verträge und Pläne sind nicht prinzipielle schlecht, sondern haben ihren Platz. Nur sollten diesen Dingen denen, die links stehen, nicht schaden

Werte, Prinzipien, Praktiken, Methodiken

Werte

• Grundsätze, wie Projekte das Problem der Änderungen angehen sollen

Prinzipien

• Konkretisieren Werte und sollen helfen diese umzusetzen

Praktiken

• Konkrete Handlungsempfehlungen für die Softwareentwicklung

Methodiken

• Kombination von Praktiken, die einer bestimmten Philosophie folgt


Vorführender


Jede agile Methodik hat ihre eigene Auswahl an Praktiken, je nach Alter der Methodik u.U. auch Werte/Prinzipien, die etwas von denen des agilen Manifest abweichen.

Werte, Prinzipien, Praktiken, Methodiken


Änderungskosten


Kost

en p

ro Ä

nder

ung

Zeit

Prädiktive Vorgehensweise

Adaptive Vorgehensweise

Vorführender


Warum sind Änderungen so problematisch, dass man sie im Prozess besser unterstützen muss: Bei prädiktiver Vorgehensweise (Analyse/Plan am Anfang, dann Abarbeiten) können die Kosten für die Durchführung einer Änderung exponentiell mit der verstrichenen Projektdauer steigen (je später die Änderung eintritt, desto mehr Arbeitsprodukte müssen überarbeitet werden), wohingegen agile Methoden, die auf ständige Anpassung ausgelegt sind, mit einer sehr flachen Kostenkurve bis zum Ende der Projektdauer auskommen (meistens)

Die agilen Werte


Vorführender


Die Individuen, die ein Projektteam bilden, und ihre Interaktionen untereinander und mit dem Umfeld werden höher bewertet als Prozesse. Im Vordergrund stehen also die Menschen, die ein Softwareprojekt ausmachen. Sie müssen miteinander interagieren können, um zu einem Projekterfolg zu kommen. Die ist wichtiger, als einen Prozess abzuarbeiten Prozess können Hilfsmittel sein, aber die Menschen sind nicht nur dazu da, stur einen Prozess einzuhalten oder ein Tool zu bedienen

Die agilen Werte


Vorführender


In einer agilen Entwicklung ist laufende Software das Maß der Dinge. Der Projektfortschritt wird anhand laufender Software nachgewiesen, sie wird vom Anwender beurteilt. Nur laufende Software kann zeigen, dass das Softwaresystem den Geschäftszweck erfüllt. Außerdem zeigt laufende Software, die vom Kunden beurteilt werden kann, dass das Projekt tatsächlich vorankommt. 10% der Features eines Projekts, die in einem lauffähigen Release getestet werden können, sagen viel mehr aus, als dass 90% aller Features in einem Entwurfsdokument beschrieben sind

Die agilen Werte


Vorführender


Nur in Zusammenarbeit mit den Kunden und den Anwendern können die Entwickler gebrauchstaugliche und sinnvolle Software entwickeln. Eigentlich sind schon Verträge des Typs Festpreisvertrag (festgelegter Preis und festgelegter Leistungsumfang) ein Problem: Wenn die Anforderungen anfangs falsch verstanden wurden oder der Kunde sie selbst nicht kannte, dann entsteht am Ende ein Produkt, mit dem eigentlich niemand zufrieden sein kann. Daher Zusammenarbeit mir dem Kunden über die gesamte Projektdauer

Die agilen Werte


Vorführender


Akzeptiert man Menschen als wichtig, ihre Interaktionen miteinander als notwendig, laufende Software als das Maß der Dinge und wichtige Basis für Rückkopplungen und die Zusammenarbeit mit dem Kunden als essentiell für den Projekterfolg, dann muss man davon ausgehen, dass sich zur Projektlaufzeit ständig Veränderungen ergeben An der laufenden Software wird erkennbar, was an anderer oder zusätzlicher Funktionalität benötigt wird Außerdem lernen alle während des Prozesses, ob und wie anders gearbeitet werden müsste Es ist besser, wenn man diese Veränderungen als zu begrüssen und damit umzugehen, als stur an einem Plan festzuhalten Es geht aber nicht um Beliebigkeit in dem Sinne, dass es keine Regeln mehr gibt, sondern um Flexibilität

Die 12 agilen Prinzipien

• Das Wichtigste sind die Bedürfnisse des Kunden

• Aktivitäten darauf ausgerichtet, dass Kunde die Software baldmöglichst einsetzen kann


Unsere höchste Priorität liegt darin, den Kunden durch frühzeitige und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.


• Von Anfang an auf unvorhersehbare Änderungen einstellen

• Änderungen nicht als Problem verstehen


Begrüße sich verändernde Anforderungen, selbst wenn sie erst spät bei der Entwicklung auftreten. Agile Prozesse nutzen Änderungen zugunsten des

Wettbewerbsvorteils des Kunden.


• Kunde soll neue Funktionalität schnell gewinnbringend einsetzen können

• Frühes Feedback erlaubt bessere Steuerung


Liefere häufig funktionierende Software aus, innerhalb weniger Wochen oder Monate, wobei der kürzeren Zeitspanne eindeutig der Vorzug zu geben

ist.


• Probleme werden durch enge Zusammenarbeit von Domänenfachleuten und Entwicklern früher erkannt


Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.


• Motivierte Mitarbeiter auswählen

• Mitarbeiter unterstützen

• Fachliche Entscheidungen den Mitarbeitern überlassen


Baue deine Projekte mit motivierten Mitarbeitern auf. Gib ihnen die Umgebung und die Unterstützung, die sie benötigen und vertraue ihnen,

dass sie ihre Arbeit erfolgreich beenden


• Direkte Kommunikation wirkungsvoller, nonverbale Komponente geht nicht verloren

• Verständnisschwierigkeiten können oft direkt aufgelöst werden


Die effektivste und effizienteste Methode, Informationen einem Entwicklungsteam zukommen zu lassen bzw. innerhalb eines

Entwicklungsteams auszutauschen, ist die direkte Kommunikation von Angesicht zu Angesicht.


• Funktionierende Software ist besser als Pläne, wie Software funktionieren könnte

• Nur durch funktionierende Software kann beurteilte werden, ob das Projekt weiter fortgeschritten ist


Funktionierende Software ist der primäre Maßstab für Fortschritt.


• Wenn nachts und in Überstunden entwickelt wird erreicht man nur, dass die dabei produzierten Fehler am Folgetag wieder ausgebaut werden müssen


Agile Methodiken fördern die kontinuierliche Entwicklung. Geldgeber, Entwickler und Anwender sollten in der Lage sein, ein beständiges Tempo

unbegrenzt beizubehalten.


• Entwickler sollten technisch up-to-date sein

• Wissen über technische Fortschritte erlaubt qualitativ bessere Software


Ständige Aufmerksamkeit gegenüber technisch hervorragender Qualität und gegenüber gutem Design erhöht die Agilität.


• Leichte Änderbarkeit reduziert Aufwand

• Einfachheit sorgt für leichte Änderbarkeit

• Daher alle Artefakte so einfach wie möglich


Einfachheit – die Kunst, unnötige Arbeit zu minimieren – ist essentiell.


• Entscheidungen dem Team überlassen, anstatt sie vorzugeben

• In der Regel finden weitegehend selbstorganisierende Teams besser Lösungen


Die besten Architekturen, Anforderungen und Designs ergeben sich aus sich-selbst-organisierenden Teams.


• Es ist wichtig regelmäßig über die eigene Arbeit nachzudenken und Verbesserungsmöglichkeiten auszuloten

• Es ist praktisch unmöglich, am Anfang die beste Methodik für ein Projekt zu bestimmen


In regelmäßigen Abständen macht sich das Team Gedanken darüber, wie effektiver gearbeitet werden kann und passt sein Verhalten entsprechend

an.

Vorführender


Daher: Aus Erfahrungen lernen um künftig ähnliche Probleme zu vermeiden

Praktiken

• Meistens konkrete Handhabungsformen, die beschreiben, wie Software entwickelt werden sollte

• Sind nicht Teil des agilen Manifests

• Auswahl der Praktiken wird den Methodikenüberlassen

• Großen Anzahl, oftmals mehrere Synonyme für dieselbe Idee


Praktiken

• Nicht alle Praktiken sind bahnbrechend neue Ideen. Viele existieren schon länger (z. B. Refactoring)

• Einige Praktiken entfalten ihren Nutzen nur im Zusammenspiel mit bestimmten anderen Praktiken, z. B. Refactoring und Regressionstests

• Eine Methodik ist eine Festlegung einer Menge von Praktiken (die idealerweise einer bestimmten Philosophie folgen)


Vorführender


Nicht alle Methodiken beinhalten Praktiken zu allen Themen. Fast alle enthalten Praktiken, die sich mit der Arbeit und den Aufgaben des Teams befassen, aber Scrum beinhaltet beispielsweise keine Praktiken, die vorschreiben, wie programmiert wird, im Gegensatz zu XP.

Methodiken


P1

P6

P5

P4 P3

P2

Methodik 1

• Eine Methodik legt für ein Projekt einen bestimmten Satz an Praktikenverbindlich fest

• Eine Methodik heißt agil, wenn sie sich an den Werten und Prinzipien des agilen Manifest orientiert

• Es sind also viele agile Methodiken möglich

Vorführender


Aufpassen: Nicht alles was sich agil nennt, ist auch agil im Sinne des agilen Manifest. Insbesondere sind Vorgehensweisen, in denen es keine Regeln gibt/sich keiner daran hält, nicht agil. Bei agilen Methodiken geht es um Flexibilität, nicht Beliebigkeit.

Methodiken

• In [Abrahamsson et al.] finden sich vier Eigenschaften, die eine „agile“ Methodik aufweisen muss

– Inkrementell– Kooperativ– Unkompliziert– Adaptiv


P. Abrahamsson et al.: Agile Software Development Methods – Review andAnalysis, VTT publications, 2002

Vorführender


Inkrementell: Entwicklung in kleinen Schritten. Neue Funktionalität wird Stück für Stück existierender, funktionierender Software hinzugefügt Kooperativ: Es muss ausgeprägte Zusammenarbeit zwischen allen Beteiligten herrschen Unkompliziert: Methodik leicht erlernbar und anpassbar Adaptiv: Methodik muss in der Lage sein, auch im letzten Moment noch größere Änderungen im Produkt zu ermöglichen

METHODIKDESIGN 101


Warum eine Methodik?

• Koordination der Projektbeteiligten

• Vermeidet es Fehler zu wiederholen (Eine Methodik sollte aus ausreichend Erfahrung abgeleitet sein)

• Vertrauensgewinn beim potentiellen Auftraggeber


Methodikdesign

• Ähnlich zu einem Brunch: Große Auswahl und nicht alles passt zusammen

• Methodiken sind soziale Konstrukte(Die Konventionen, die die Gruppe akzeptiert)

• Wie bewertet man Methodiken, um eine „gute“ zu erstellen

– Elemente– Metriken


Vorführender


Elemente sind Gesichtspunkte, unter denen man Methodiken betrachten kann. Sie erlauben es, Methodiken nach bestimmten Gesichtspunkten zu strukturieren Metriken sind „Massbänder“, um quantitative Werte über Methodiken zu erhalten

Methodikelemente


A. Cockburn: Agile Software Development – The Cooperative Game, Addison Wesley, 2007

Vorführender


Prozess: Abfolge von Projektphasen. In agilen Methoden: Immer nicht-lineare Prozesse Aktivitäten: Neben endproduktbezogenen Aktivitäten (Analyse, Design,…) gibt es auch noch sonstige Aktivitäten (Weiterbildung, Einführen neuer Mitarbeiter, Ausfüllen eines Urlaubsantrags,…). Auch sonstige Aktivitäten müssen in der Planung berücksichtigt werden, da sie immer anfallen Arbeitsergebnisse: Nur notwendige Artefakte auch erstellen! Arbeitsergebnisse sollen dem Projekt so früh wie möglich zur Verfügung stehen, Arbeitsergebnisse nur so detailliert wie aktuell erforderlich

Metriken

• Erlauben den Vergleich anhand einer Skala

• Beispiele:– Größe der Methodik– Zeremonie– Gewicht der Methodik (Indikator für Inflexibilität)– Problemgröße– Kritikalität– Sichtbarkeit– Stabilität


Vorführender


Im Folgenden jeweils einige Details zu den verschiedenen Metriken

Metriken


Größe der Methodik

Vorführender


Je höher der Rauminhalt für die Methodik, desto größer ihre Größe

Metriken

• Zeremonie: Detaillierungsgrad der Artefakte und Toleranz gegenüber Abweichungen

• Gewicht der Methodik: „Produkt aus Größe und Zeremonie“

• Problemgröße: Wie komplex ist das zu lösende Problem


Vorführender


Ideen spontan auf Serviette entwickeln: wenig Zeremonie Anforderungsworkshop mit 30 Seiten Anforderungsspezifikation: viel Zeremonie Mit Projekten welcher Größe kann die Methodik umgehen: Hilft zu entscheiden, ob eine Methodik geeignet ist oder nicht

Metriken

• Größe des Schadens, wenn die Software nicht funktioniert

• Cockburn unterscheidet u. a. in der Crystal-Methodenfamilie folgende Grade:


Kritikalität


Klasse Beschreibung

C (Comfort) Komfort des Benutzer beeinträchtigt

D (Discretionary Money) Überschaubarer finanzieller Schaden

E (Essential Money) Erheblicher finanzieller Schaden (jenseits der Portokasse)

L (Life) Gefahr für Menschenleben

Vorführender


D: Z.B. Kosten für die Entwicklung eines Demoprototypen für die Auftragsakquise E: Erheblich Konventionalstrafen

Metriken

• Sichtbarkeit: Wie transparent sind die Vorgänge in einem Projekt

• Stabilität: Wie hoch ist die Wahrscheinlichkeit einer Veränderung


Vorführender


Sichtbarkeit hoch, wenn jeder weiß, was der andere tut. Hohe Sichtbarkeit mach Team unempfindlicher gegen den Truck-Faktor/Verlust einzelner Mitarbeiter Manche Methodiken sind besser für Projekte, mit vielen zu erwartenden Schwankungen, andere sind bei Projekten mit hoher Stabilität besser

Ansätze für das Design einer Methodik

• Tailoring:Bestehende Methodik anpassen

• Kombination:Das Beste aus mehreren Methodiken kombinieren

• Die Methodik muss ausgewogen und der jeweiligen Situation angemessen sein (keine Überbetonung einzelner Aspekte)


Vorführender


Tailoring: Eine geeignete Methodik, die aber mehr Praktiken bietet, als benötigt werden, auswählen und auf die Praktiken, die für das Projekt sinnvoll sind, zusammenstreichen Kombination: Auswahl der besten Praktiken/Ansätze aus verschiedenen Methodiken. Erfordert mehr Erfahrung, da im Prinzip Methodikenentwicklung auf der grünen Wiese GENERELL: Neue Methodik aus möglichst vielen Blickwinkeln (Elemente) betrachten, nicht einige überbewerten. Methodik schlank halten (EINFACH)

Häufige Fehler

• Eierlegende Wollmilchsau

• Unnötiges Beiwerk mangels Vertrauen

• Viel hilft viel


Bisher nicht in Erscheinung

getreten

Vorführender


Eierlegende Wollmilchsau: Die eine für alles Methodik. Fred Brooks 1986 in „Mythical Man-Month“: NO SILVER BULLET Unnötiges Beiwerk: Man traut der eigenen Praktikenwahl nicht und baut ständig weitere Regeln/Praktiken und Ideen dazu, und die Methodik wird zu schwer Viel hilft viel: Auch „Je größer, desto besser“, weil wir dazu neigen, unsere eigene Arbeit („ich bin der große Held“) monumentaler zu gestalten, als es sinnvoll ist

Häufige Fehler

• Ideenkill („Das funktioniert bestimmt nicht.“)

• Das Prinzip Hoffnung („Das müsste eigentlich funktionieren.“)

• Missachtung des Zusammenspiels einzelner Praktiken

• Vernachlässigung des Faktors Mensch


Vorführender


Ideenkill: Weil man sich nicht vorstellen kann, dass etwas klappt, die Idee zu früh verwerfen Prinzip Hoffnung: An etwas festhalten, was theoretisch gut klingt, aber in der Praxis gescheitert ist Zusammenspiel: z. B. Refactoring und Regressionstests, Refactoring und Collective-Code-Ownership Faktor Mensch: Methodik vernachlässigt die Menschen, bindet sie nicht ein, fördert nicht ihre Leistungsfähigkeit.

Cockburns 10 Prinzipien

1. Unterschiedliche Projekte erfordern unterschiedliche Methodiken.

2. Übermäßiges Gewicht in der Methodik ist kostspielig.

3. Größere Teams erfordern mehr Kommunikationspraktiken.

4. Projekte mit höherem potentiellen Schaden erfordern mehr Praktiken zur Überprüfung.


Vorführender


2: Jede Praktik, die zum Einsatz kommt verursacht Aufwände (Zeit, Geld). 3: Bei 4 Personen Team, Informationsaustauch im direkten Gespräch viel einfacher als bei 25 Personen-Team Bei n Personen (n * (n-1))/2 = (½) ( n^2-n) viele direkte Gespräche nötig.


5. Disziplin, Können und Verständnis können nicht durch Verfahren, Formalitäten und Dokumentation ersetzt werden.

6. Interaktive, direkte Kommunikation ist der günstigste und schnellste Kanal zum Austausch von Informationen.

7. Die Zunahme an Kommunikation und Feedbacks reduziert das Bedürfnis nach Dokumentation.


Vorführender


5: Diese Tugenden sind im Menschen verankert und kaum auf andere zu transferieren, schon gar nicht durch Regeln und Zwang 6: Direkte Kommunikation eröffnet auch non-verbale Kommunikationskanäle, einfaches Rückfragen… 7: Je mehr direkte Kommunikation/Feedback es gibt, desto weniger ist es nötig, dies alles schriftlich zu dokumentieren


8. Nebenläufige Entwicklung erhöht die Geschwindigkeit und Flexibilität; serielle Entwicklung verringert die Kosten.

9. In Aktivitäten ohne Flaschenhals ist Effizienz entbehrlich.

10. Bestimmte Praktiken („Sweet Spots“) beschleunigen die Entwicklung.



Vorführender


8,9,10: Siehe Kopien

Cockburns Sweet Spots

Projekte sollten versuchen, sich soweit wie möglich folgenden Praktiken zu nähern:

• Für jeden Entwickler nur eine einzige Aufgabe• Einsatz von erfahrenen Entwicklern• Kleine Teams, deren Mitglieder am gleichen Ort

platziert sind• Automatische Regressionstests• Leichter Zugang zu den Benutzern• Kleine Inkremente und häufige Auslieferung an echte

Benutzer


Vorführender


Viele diese Vorschläge finden sich in den Praktiken der noch folgenden agilen Methodiken in der einen oder anderen Form wieder. Dies verhindert Ablenkung, die die Produktivität senkt Erfahrene Entwickler können langsamere Entwickler betreuen und anspornen Verbessert Kommunikation Erhöht Qualität und bietet dem Team Sicherheit Damit auftretende Fragen schnell geklärt werden können Um sicherzustellen, dass das System nicht an den wahren Anforderungen vorbei entwickelt wird

PRAKTIKEN


Praktiken

• Praktiken sind konkrete Anleitungen, wie Software entwickelt werden soll

• Praktiken in den meisten Fällen aus Erfahrungswerten aus Projekten abgeleitet

• Es gibt sehr viele verschiedene Praktiken, keine Methodik nutzt alle

• Im Folgenden werden einige Praktiken beispielhaft vorgestellt


Pair Programming

• Immer zwei Entwickler an einemComputer

• Einer hat Tastatur und Maus und entwickelt Code

• Der Andere überwacht, denkt voraus an die nächsten Schritte

• Die Partner wechseln wiederholt die Rollen

• Besetzung der Paare wird regelmäßig gewechselt


Vorführender


Der Copilot vollzieht die Ideen nach, hinterfragt, korrigiert und ergänzt Es wird ein gemeinsames Ergebnis geschaffen, die Designentscheidungen werden im Team kommuniziert, es wird Vorwissen von zwei Leuten eingebracht und gemeinsam neue Erfahrungen gesammelt Wissensgefälle der Partner auf Dauer nicht zu groß!! Wechsel der Paare verteilt das Wissen um die Entscheidungen im Team Wichtig: Einlassen auf Zusammenarbeit unerlässlich. Mit Einzelkämpfern unmöglich Kritik: Doppelt so teuer. Stimmt aber nicht ganz, da: Training on the Job, teilweise Ersatz für Besprechungen, weniger Codereviews, beschleunigt Rückkopplungszyklus, so daß Probleme früher aufgedeckt werden. Begegnet uns im Abschnitt XP wieder

Refactoring

• Code ist wie Käse, mit der Zeit beginnt er zu stinken („code smells“)

• Refactoring verbessert bestehenden Code, ohne die Funktionalität zu verändern

– Umbenennen von Klassen– Entfernen von redundantem Code– Extrahieren von Interfaces

• Toolsupport wichtig

• Mehr zu Refactoring später


Beispiel zu Refactoring


Version 1 Version 2public class Circle {

private double radius;

public void setRadius(double radius) {this.radius = radius;

}public double getPerimeter() {double perimeter = 2 *

3.141592 *radius;

return perimeter;}public double getArea() {double area = 3.141592 *

Math.pow(radius,2);return area;

}}

Vorführender


Dieselbe Zahl (Konstante PI) an zwei Stellen im Code ausgeschrieben: Bei Änderung Gefahr Vorkommen zu übersehen oder inkonsistent zu ändern. Werte ohne Namen in Code schlecht

Beispiel zu Refactoring


Version 1 Version 2public class Circle {




3.141592 *radius;

return perimeter;}public double getArea() {double area = 3.141592 *


}}

public class Circle {public static final double PI = 3.141592;




PI *radius;

return perimeter;}public double getArea() {double area = PI *


}}

Product Backlog

• Öffentliche Liste aller Aufgaben, die für das Endprodukt noch getan werden müssen

• Nicht nur Funktionalität, auch Bugfixesund Dokumentationsbedarf,…

• Alle Einträge werden mit Prioritätund Aufwandsschätzungversehen


Vorführender


Product Backlog muss nicht elektronisch gespeichert werden: Nächste Folie Mehr dazu im Abschnitt Scrum

Product Backlog


Es muß nicht immer alleselektronisch sein

Collective Code Ownership

• Das Team als Gemeinschaft ist der Besitzer des Codes

• Jeder kann jeden Teil des Codes jederzeit ändern

• Wer der ursprüngliche Autor war, ist irrelevant

• Für alle gelten dieselben Programmierstandards und -richtlinien

• Hilft den Truckfaktor niedrig zu halten


Vorführender


Truckfaktor: Wahrscheinlichkeit, dass Projekt scheitert, wenn 1 Teammitglied von einem LKW überfahren wird: 0: Schadet dem Projekt nicht. 1: Projekt scheitert garantiert. Sollte nahe 0 sein

Praktikenbasar

• Machbarkeitsanalyse (Proof of concept)

• Anforderungspatterns

• Glossar

• Kunde vor Ort

• MoSCoW-Regel


• C. Dogs, T. Klimmer: Agile Software Entwicklung kompakt, mitp-Verlag, 2005

• http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html

Vorführender


Machbarkeitsanalyse: Vor Projektbeginn wird für kritische Teile bewiesen, dass gewählte Lösung funktioniert Anforderungspatterns: Ständig wiederkehrende Anforderungen werden an zentraler Stelle veröffentlicht und bei Bedarf wiederverwendet Glossar: Wörterbuch für Begriffe im Projekt, besonders aus Geschäftdomäne MoSCoW-Regel: Gruppierung für Anforderungen

Praktikenbasar

• Planning Game

• Prototypen

• Requirements Management

• CRC-Karten

• Designmentor


Vorführender


Planning Game: Kunde und Entwickler entscheiden gemeinsam, welche Funktionalität implementiert werden soll (Kunde erstellt Storycards) Prototypen: Schnell gebaute Modelle des geplante Endprodukts um bestimmte Aspekte zu beleuchten Requirements Management: Systematische Verwaltung der während des Projekts auftretenden Anforderungen zum Beispiel mit Tools Designmentor: Designmentoren beraten andere Mitarbeiter zu Fragen von gutem Design

Praktikenbasar

• Design Patterns

• Öffentliche Modellpräsentation (Wall of Wonders)

• Coding Standards

• Collective Ownership

• Individual Code Ownership


Vorführender


Modellpräsentation: Alle Projekte präsentieren ihre Modell öffentlich an einem zentralen Ort, damit alle Mitarbeiter von den Entscheidungen anderer lernen können und ggf. auch Verbesserungsvorschläge machen

Praktikenbasar

• Kurze Releases

• Pair Programming

• Refactoring

• Monkey-Tests

• Regressionstests


Vorführender


Monkey-Test: Man überlässt die Software einer total ahnungslosen Person, die einfach das System ohne Vorwissen ausprobieren soll.

Praktikenbasar

• 40-Stunden-Woche

• Weiterbildung

• Knowledge-Base/Wiki

• Selbstorganisierende Teams

• Tägliches Stand-Up-Meeting


Vorführender


Weiterbildung: Die Weiterbildung aller Mitarbeiter wird in allen technischen Bereichen gefördert, unabhängig vom aktuellen Projekt Selbstorganisierende Teams: Team erhält nur eine Zielvorgabe und organisiert sich daraufhin selbst und legt die eigenen Regeln fest

Praktikenbasar

• Timeboxing

• Anti-Patterns

• Einfachheit

• Risikogetriebene Priorisierung


Vorführender


Timeboxing: Eine Iteration dauert einen festgelegten Zeitraum, der nicht verlängert wird Anti-Patterns: Zu einer bestimmten Problemstellung wird beschrieben, was nicht getan werden soll

METHODIKEN


Methodiken gibt‘s viele


XP

Scrum

Crystal

Feature-DrivenDevelopment (FDD)

dX

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

PP

Taxonomie von Methodiken

Prozessorientiert

XP

Scrum

DSDM

FDD

Mitarbeiterzentriert

ASD

Crystal

Werkzeugzentriert

dX (RUP agil)

Unvollständig

Agile Modeling (AM)

Agile Database Techniques

(ADT)

Lean Software Development

(LSD)

Pragmatic Programming

(PP)


Vorführender


Prozessorientiert: Konzentrierten sich stark auf einen Prozess/ein Vorgehen Mitarbeiterzentriert: Stellen die Mitarbeiter in den Mittelpunkt der Betrachtung Werkzeugzentriert: Erwarten Einsatz eines oder mehrerer bestimmter Werkzeuge Unvollständig: Stehen in irgendeiner Form mit den Werten/Prinzipien des agilen Manifests in Verbindung, sind alleine aber theoretisch nicht ausreichend um funktionierende Software zu entwickeln. LSD: Adaptiert Lean Production (siehe Toyota Production System) auf Softwareentwicklung PP: Einfache Regeln für das Programmieren

EXTREME PROGRAMMING


Extreme Programming

• Bekannteste Agile Methodik• Von Kent Beck, Ward Cunningham und

Ron Jeffries 1996 entwickelt• Entstand aus Erfahrungen im C3 Projekt

(Chrysler Comprehensive Compensation System) von Chrysler

• XP stellt Entwickler und Kunden in den Vordergrund

• Praktiken zielen auf Programmierung und Einbindung des Kunden


Aspekte

XPWerte

Rollen

Prozess

Praktiken

Anwendung


Werte im XP

XP

Kommuni-kation

Einfachheit

Feedback

Mut


Nicht mit den Werten des agilen

Manifests verwechseln! XP

war früher!

Vorführender


Kommunikation: Fast alle Projektprobleme können auf mangelnde oder schlechte Kommunikation zurückgeführt werden Einfachheit: Kommunikation wird unterstützt, wenn Arbeitsprodukte möglichst einfach sind. Nicht nur leicht verständlich sondern auch so, dass genau die Aspekte berücksichtigt werden, die aktuell tatsächlich berücksichtigt werden müssen Feedback: Nur schnelle Rückmeldungen erlauben zu erkennen, dass getroffene Annahmen richtig sind. So können Fehlentwicklungen rechtzeitig vermieden werden. Mut: Mut seitens der Mitarbeiter nötig, um ungewöhnliche Schritte zu gehen. Bsp.: Manchmal besser, die Arbeit eines Tages zu entsorgen anstatt an schlechter Entscheidung festzuhalten.

Prinzipien im XP

Unmittelbares Feedback

Einfachheit anstreben

Inkrementelle Veränderung

Veränderung wollen

Qualitätsarbeit


Vorführender


Feedback: Rückkopplung so schnell wie möglich. Lernpsychologie: Zeitlicher Abstand zwischen Aktion und Feedback entscheidend für Lernerfolg. Außerdem frühes Feedback => weniger Zeitverschwendung an falsche Richtung Einfachheit: Einfache Lösungen haben viele Vorteile: Schneller zu erstellen, (=> schneller Feedback), leichter zu verstehen und zu kommunizieren, leichter änderbar (=> Entwicklung ist flexibler bei Änderungen) Inkr. Veränderung: Softwaresysteme werden mit der Zeit so komplex, dass Änderungen unerwartete Effekte haben. Wenn wir nur kleine Änderungen vornehmen, bleiben diese Effekte beherrschbar. Ursache eines Seiteneffekts leichter lokalisierbar Veränderung wollen: Bereit sein für Veränderungen, da nur so Fortschritt möglich Qualitätsarbeit: Arbeitsumfeld muss so sein, dass hohe Qualität an Software entwickelt werden kann (=> fördert Zufriedenheit der Entwickler), es muss aber klar festgelegt sein, was gute Qualität ist (hier bestimmt der Kunde den Maßstab für die Gebrauchsqualität der Software!)

Lernen lehren

Geringe Anfangsinvestition

Auf Sieg spielen

Gezielte Experimente

Offene, aufrichtige Kommunikation

Die Instinkte des Teams nutzen, nicht dagegen

arbeiten

Verantwortung übernehmen

An örtliche Gegebenheiten

anpassen

Mit leichtem Gepäck reisen

Ehrliches Messen

Prinzipien im XP

Unmittelbares Feedback

Einfachheit anstreben

Inkrementelle Veränderung

Veränderung wollen

Qualitätsarbeit


Vorführender


Lernen lehren: XP soll keine Befehlskette sein. Das Team soll lernen, selbst abzuschätzen wie viel Prozess, Tests,… nötig sind. XP soll das Team auch lehren, selbst zu lernen was nötig ist Gerin. Anfangs.: Geringe Anfangsinv. sorgen dafür, dass Risiko für neues Projekt nicht zu groß (auch wenn Projekt langfristig geplant kann immer was dazwischenkommen), außerdem sorgt kleines Budget am Anfang für Fokussierung auf die wichtigen Aspekte Auf Sieg spielen: Offensiv die anstehende Aufgaben angehen, anstatt „nur keinen Fehler machen“. „Bloß nicht verlieren“ ist eine hinderliche Einstellung. Außerdem sagt uns das Prinzip, dass man ein Projekt, das nicht mehr zu gewinnen ist, lieber beenden sollte Gezielte Experimente: Um Risiken zu minimieren, möglichst früh Klarheit, ob Entscheidung falsch war. Experimente können hier helfen. Dies bezieht sich auf die Software (Testen) aber auch auf den Entwicklungsprozess (Reviews des Prozesses) Offene Kommunikation: Aufgrund von Angst, Eitelkeit oder Rivalität gibt es in Projekten nicht selten keine offene und ehrlich Kommunikation. Das ist tödlich!! Herstellen offener und aufrichtiger Kommunikation ist eine zentrale und anspruchsvolle Aufgabe im Projekt. Instinkte nutzen: Erfahrung und Instinkten des Teams vertrauen. Verantwortung übernehmen: Verantwortung soll nicht zugewiesen sondern aktiv übernommen werden. Damit nimmt man die Aufgabe ernst (man hat sie ja selbst gewählt), Motivation wird gesteigert Örtli. Gegeben. anpassen: Unwahrscheinlich, dass der Prozess genau wie von K. Beck beschrieben angewendet werden kann. Ziel ist auch nicht exakte Nachahmung sondern ein erfolgreiches Projekt. Anpassungen die dem dienen sind gerechtferigt Mit leicht. Gepäck reisen: Wenig Gepäck um schnell und agil zu sein: Wenige aber nützliche Dinge einsetzen (z.B. Wiki als Wissensbasis) Ehrliches Messen: Kontrolle des Prozesses erfordert viele Messdaten (z.B. Tests für Komponentenkorrektheit…). Alles nur sinnvoll, wenn ehrlich gemessen wird. Alles grün, weil nicht-funktionierender Code auskommentiert wird, hilft nicht, da die Wahrheit verschleiert wird.

Rollen

Management Geschäftsdomäne

Projektunterstützung Sonstige Rollen

Design/ Programmierung


Big Boss

Coach

Kunde

Tester

ProgrammiererTracker

Consultant

Vorführender


Programmierer: Entwickeln Architektur, schreiben Code und Tests Big Boss: Verantwortlich für Projekterfolg, trifft grundlegende Entscheidungen, unterstützt Team wenn nötig (und nur dann). Hat mehrere Projekte, nicht an der täglichen Arbeit beteiligt Coach: Ähnlich einem Teamleiter, führt die Programmierer und zeigt, wie XP angewendet wird. Verantwortlich dafür, dass nicht von Zielen abgewichen wird, Ansprechpartner für alle Teammitglieder Tracker: „Historiker“ des Teams. Beobachtet Leistungen des Teams. Nutzt gesammelte Erfahrung zur Entwicklungsgeschwindigkeit, um auf Gefahr hinzuweisen, dass Zeitrahmen nicht mehr zu erreichen sind Kunde: Kunde stellt Anforderungen auf Story Cards, arbeitet eng mit Entwicklern zusammen. Schreibt Akzeptanztests Tester: Unterstützt Kunden beim formulieren von funktionalen Tests, verantwortlich für regelmäßiges Durchführen der Tests und Veröffentlichung der Ergebnisse Consultat: Externer, der ggf. benötigtes technisches Know-How einbringt

Rollen

• Programmierer– Entwickeln Architektur– Schreiben Quellcode und Unit Tests

• Big Boss– Verantwortlich für Projekterfolg– Grundlegende Entscheidungen– Unterstützung für das Team, wenn nötig– Nicht an der täglichen Arbeit beteiligt


Rollen

• Coach– Vergleichbar mit Teamleiter– Führt die Programmierer– Zeigt wie XP angewandt wird– Verantwortlich für Einhaltung der Ziele– Ansprechpartner für Teammitglieder

• Tracker– „Historiker“– Sammelt Daten zur Leistung des Teams– Achtet auf mögliche Gefährdung der vorgegebenen

Zeitrahmen


Rollen

• Kunde– Verwendet später die Software– Schreibt Story Cards als Anforderungen– Schreibt Akzeptanztests– Arbeitet mit den Entwicklern zusammen

• Tester– Unterstützt Kunde beim Formulieren von Tests– Verantwortlich für regelmäßige Durchführung der Tests

und Veröffentlichung der Ergebnisse


Rollen

• Consultant– Externer technischer Sachverstand


Ablauf der Entwicklung


Der eigentliche Prozess

Exploration

Planung Entwicklung

Freigabe Wartung

Ende

• Technische Experimente• Einweisung des Kunden




Exploration

Planung Entwicklung

Freigabe Wartung

Ende

Planning Game• Planung der Iteration durch

Kunde und Entwickler




Exploration

Planung Entwicklung

Freigabe Wartung

Ende

• Festlegung der Architektur• Schreiben von Unit und

Akzeptanztests• Paarweises Programmieren der

Software




Exploration

Planung Entwicklung

Freigabe Wartung

Ende

• Letzte Tests• Performanceoptimierungen




Exploration

Planung Entwicklung

Freigabe Wartung

Ende

• Überarbeitung der Software im Produktivbetrieb




Exploration

Planung Entwicklung

Freigabe Wartung

Ende• Schreiben der

Abschlussdokumentation• Projektabschluss

Explorationsphase

• Werkzeuge kennenlernen

• Technische Ansätze ausprobieren

• Kunde bekommt Methodik und seine spätere Rolle erklärt

• Wenige Wochen bis sehr wenige Monate. Falls mehr Zeit benötigt wird, Projektumfang verkleinern und Projekt so überschaubarer machen [Beck, 2000, Extreme Programming Explained]


Planungsphase

• Kunden und Entwickler entscheiden gemeinsam im Planning Game, welche Funktionalität im nächsten Release enthalten sein soll und wann diese implementiert werden soll

• Planning Game maximal 1 bis 2 Tage [Beck, 2000, Extreme Programming Explained]

• Hauptziel der ersten Iteration sollte hauptsächlich eine grobe Architektur des Systems sein


Ablauf Planungsphase

1. Kunde formuliert seine Anforderungen auf Story Cards

2. Entwickler schätzen den Aufwand jeder einzelnen Karte und stellen Anhängigkeiten fest (A nicht vor B)

3. Kunde priorisiert die einzelnen Karten (entsprechend seinem Nutzen)

4. Auf Basis von Prioritäten und Aufwänden werden gemeinsam die Karten ausgewählt, die implementiert werden. Ergebnis: Iterationsplan(welche Funktionalität in welcher Iteration)


Story Card


Story Cards


Aufwandsschätzungen


Gestern Heute

Vorführender


Prognose: „So wie‘s gestern war, wird‘s morgen“ oftmals ganz gut Geht nur in stabilen Randbedingungen: Team, das bereits miteinander gearbeitet hat, festgelegte technologische Randbedingungen, vereinbarte und gewohnte Zusammenarbeit mit dem Kunden Ein Problem beim Schätzen ist oft die unterschiedliche Interpretation einer fachlichen Anforderung durch verschiedene Teammitglieder => Nachfrage beim Kunden

Aufwandsschätzungen

• Alle Teammitglieder sind in den Schätzprozess eingebunden

• Technische und organisatorische Rahmenbedingungen müssen klar sein

• Anforderungen dürfen eine gewisse Maximalgröße nicht überschreiten

• Es werden abstrakte Schätzgrößen verwendet


Wie schätzt man Aufwände?

W.-G. Bleek, H. Wolf: Agile Softwareentwicklung, dpunkt.verlag,2008

Vorführender


Alle Teammitglieder sind eingebunden: Es soll nicht einer alle Schätzungen vorgeben. Z. B. erfahrener Entwickler äußert sich zuerst, keiner traut sich, zu wiedersprechen Wenn das Team für die Einhaltung der Schätzungen verantwortlich gemacht wird, müssen die Schätzungen auch aus dem Team kommen Es wird als Team geschätzt, so dass nicht einer geschätzte Vorgaben für andere macht, die diese nicht einhalten können Abstrakte Schätzgrößen: idealisierte Personentage, Gummibärchen, Aufwandspunkte (Umrechnungswert abstrakte Einheit zu realer Aufwand dann aus Erfahrungswerten)

Schätzpokern


Geschätzter Aufwand

Diskussionsbedarf1. Jedes Teammitglied erhält eine Farbe2. Anforderung wird vorgelesen3. Alle wählen ihre Schätzungskarte aus4. Schätzung wird verdeckt hingelegt5. Umdrehen, wenn alle geschätzt haben

Sching-Schang-Schong-Schätzen

• Funktioniert wie Kinderspiel „Schere-Stein-Papier“• Wertungsskala 1 bis 5• Alle rufen „Sching-Schang-Schong“ und signalisieren

dann mit der Hand ihre Schätzung• Abweichung mehr als 2: Diskussionsbedarf


Vorführender


Vermeiden, dass ein Wortführer die Richtung vorgibt und andere Meinungen untergehen Abweichung mehr als 2: Kurze Diskussion: Ist der Inhalt der Story gleich verstanden worden, sieht jemand ein spezielles Problem?

Hierarchisches Schätzverfahren

• Wenn die Zahl der User-Stories zu groß wird oder nicht alle User-Stories erfasst werden können, werden beim Schätzen zusätzliche Hierarchieebenen eingezogen


Bearbeite Kunde

Lösche Kunde

Drucke Kundenliste

nach PLZ

Zeige Kundenliste an

Prüfe Plausibilität vor Speichern

Öffne Kunden aus Liste

Speichere Kunden

User -Stories

FeaturesSubsystem

Kunde

Hierarchisches Schätzverfahren

• Man benötigt mindestens 1 Subsystem, für das alle Features erfasst sind und darunter mindestens 1 Feature, für das alle Stories erfasst sind

• Zuerst wird Top-Down geschätzt– Alle Subsysteme in syep (System effort point)– Alle Features in feep– Alle Stories in step

• Dann ermittelt man wie viele Personentage ein step sind (z. B. durch Programmieren einiger Stories)

• Dann werden Botton-Up die konkreten Aufwände berechnet


Vorführender


Nächste Folie an Tafel entwickeln

Beispiel zu hierarchischem Schätzen


Kunde

Bearbeite Kunde3 feep

Lösche Kunde1 feep

Drucke Kundenliste

nach PLZ2 feep

2 syep

Auftrag Rechnung Lohn

5 syep 2 syep 3 syep

Öffne Kunden aus Liste

1 step

Prüfe Plausibilität vor Speichern

3 step

Speichere Kunden 1 step

Zeige Kundenliste2 step

Außerdem bekannt:1 step ≅ 2 PT

Vorführender


An der Tafel vorrechnen Feature „Bearbeite Kunde“ hat 3 feep und 7 step => 1 feep = 2,33 step Subsystem Kunde hat 2 syep und 6 feep => 1 syep = 3 feep = 7 step Ganze Anwendung hat 12 syep = 36 feep = 84 step. Das entspricht dann 168 PT

Entwicklungsphase

• Am Anfang: Entwickler sprechen sich ab, wie in der Iteration vorzugehen ist und wie das grobe Design für die Funktionalitäten auf den Story Cards aussehen soll

• Implementieren der Funktionalitäten einzelner Story Cards im paarweisen Programmieren und nach dem Test Driven Development (TDD)-Ansatz

• Tracker beobachtet Fortschritt der Implementierung (um im nächsten Planning Game beim Schätzen der Aufwände zu helfen)


Vorführender


Design: Will jemand eine Entwurfsentscheidung diskutieren, trägt er dies beim täglichen Treffen vor und Team vereinbart wie damit weiter verfahren wird. => Separates Treffen für Quick Design Session, bei der wenig formal, z. B. auf Flipchart eine Architekturskizze entworfen wird. Beteiligt werden alle, die sinnvoll zur Entscheidung beitragen können und wollen.

TDD Ablauf


Unit Test für neuen Code

schreiben

Test ausführen Code schreiben bzw. ändern

Refactoring

Test nicht bestanden

Test bestanden

Refactoringerfolgreich

Entwicklungsphase

• Kommt es in der Iteration zu Unklarheiten, werden diese mit den anderen Entwicklern oder dem Kunde (on-site customer) geklärt

• Abschloss einer Iteration nach der zuvor festgelegten Dauer (1 bis 4 Wochen). Ergebnis ist funktionierende Software

• Unit Tests sollte für geringe Fehlerquote sorgen

• Akzeptanztests werden ausgeführt


Entwicklungsphase

• Akzeptanztests wurden während der Iteration von Kunde und Tester zusammen entwickelt

• Ist das Ergebnis nicht zufriedenstellend 2 Möglichkeiten– Entwickler nehmen kurzfristig Änderungen vor– Kunde muss neue Story Card für nächstes Planning Game

formulieren

• Weitere Iteration oder Übergang zu Freigabephase (neues Release), je nach Iterationsplanung

• Faustregel: 8-10 Iterationen pro Release


Akronyme im agilen Umfeld

• YAGNI: You Ain‘t Gonna Need It. Keine Technik/Funktionalität/Generalisierung/Abstraktion auf Vorrat

• KISS: Keep it simple, stupid;DTSTTCPW: Do the simplest thing that could possiblywork. Lösungen sollen einfach sein, eine gute Architektur ist zuallererst immer einfach


Vorführender


Code auf Vorrat ist auch unwirtschaftlich: Er muss mit gewartet und gepflegt werden, auch wenn er noch gar keinen Nutzen hat

Akronyme im agilen Umfeld

• DRY: Don‘t Repeat Yourself;OAOO: Once And Only Once: Eine Entwurfsentscheidung soll sich an genau einer Stelle im Code wiederfinden.

• SCP: Speaking Code Principle: Code soll seinen Zweck kommunizieren, auch ohne Kommentar und Dokumentation

• SoC: Separation of Concerns: Jede Klasse soll für ihre Aufgaben zuständig sein, aber eben nur für ihre eineAufgabe

• TDA: Tell, Don‘t Ask: Klassen sollten Funktionalität bereitstellen, nicht nur Daten/Fakten


Vorführender


Nur an einer Stelle: Nur so ist gewährleistet, dass bei einer Änderung das Konzept an nur einer Stelle angepasst werden muss Beispiel zu TDA: Eine Klasse sollten nicht das Datum Mehrwertsteuersatz bereitstellen, sondern besser eine Funktion MehrwertsteuerBerechnen(BigDecimal preis). Steht etwas im Widerspruch zu SoC: Mittelweg finden

Freigabephase

• Aktueller Stand (Release-Candidate) wird dem Echtbetrieb übergeben

• Kunde prüft nochmals genau auf Mängel

• Entwickler machen Performanceoptimierungen

• Übergabe an die Anwender


Wartungsphase

• Anpassung der Software an veränderte Bedingungen

• Beheben von Fehlern

• Neue Anforderungen werden umgesetzt

• Software, die bereits im Einsatz ist, erfordert höhere Vorsicht bei Änderungen


Endphase

• Projekt endet, wenn keine weiteren Wünsche seitens des Kunden vorliegen

• 10- bis 15-seitige Dokumentation zu Software und Quellcode

• Das ist nicht die Benutzerdokumentation


Detailansicht des Prozesses


Praktiken des XP (V1)


Gemeinsame Verantwort-

lichkeit

Programmier-standards

Nachhaltiges Tempo

Fortlaufende Integration Metapher

Testen Einfaches Design

RefactoringProgram-mieren in

Paaren

Kunde vor Ort

Planungsspiel

Kurze Releasezyklen

Standup-Meeting

Retrospektive

Management-techniken

Vorführender


Kunde vor Ort: Kunde und Anwender stehen als Ansprechpartner für fachliches Wissen zur Verfügung. Es gibt kein Pflichtenheft (komplette fachliche Spezifikation), Unklarheiten werden direkt mit dem Anwender geklärt Planungsspiel: Legt Umfang des nächsten Inkrements fest, Anwender/Kunde und Entwickler sind beteiligt Standup-Meeting: Tägliches Treffen (zu einer festgelegten Zeit) in dem für 15 Minuten ein Austausch zum Projektfortschritt erfolgt Kurze Releasezyklen: Neue und geänderte Komponenten in kurzen Abständen zum Anwender. Schnellerer benefit für Kunde, schnellere Bewertung der Arbeit als Feedback Retrospektive: Rückblickende Reflexion durch die Projektbeteiligten. Ziel: Probleme und Blockaden im Softwareentwicklungsprozess finden und für Zukunft beseitigen. In Abständen von 1 bis 6 Monaten mit allen oder ausgewählten Projektteilnehmern. Dauer ca. 0,5 bis 3 Tage




lichkeit


Nachhaltiges Tempo




Paaren

Kunde vor Ort

Planungsspiel

Kurze Releasezyklen

Standup-Meeting

Retrospektive

Team-techniken

Vorführender


Metapher: Wenige klare Metaphern (Bilder) um die Kernideen des Systems zu beschreiben, ist immer auch Architekturvorgabe Gemeinsame Verantwortlichkeit: Alle Entwickler sind gemeinsam für das Projekt verantwortlich. Daraus folgt insbesondere, dass jeder alle Codeteile ändern darf Fortl. Integration: Durch (ständige) möglichst schnelle Integration geänderter Systemteile stehen diese den anderen Entwicklern schnell zur Verfügung. Änderungen können vom ganzen Team getestet werden. Gesamtintegrationsaufwand sinkt, da Konflikte früher zu Tage treten Programmierstandards: Einheitlicher Quellcode Voraussetzung für Pair Programming und gemeinsame Verantwortlichkeit. Dazu werden pragmatische Coding Standards definiert (z.B. Code Conventions for Java von SUN) Nachhaltiges Tempo: Entwickler sollen nicht mehr als Regelarbeitszeit arbeiten, also mit einem nachhaltigen Tempo vorgehen. Dadurch läßt sich Kreativität und Engagement über längeren Zeitraum sichern. Überstunden werden nur in engen Grenzen geduldet.




lichkeit


Nachhaltiges Tempo




Paaren

Kunde vor Ort

Planungsspiel

Kurze Releasezyklen

Standup-Meeting

Retrospektive

Programmier-techniken

Vorführender


Testen: Alles muss qualitätsgesichert sein: automatische Komponententests, Akzeptanztests für die Erfüllung fachlicher Anforderungen Einfaches Design: Das System soll möglichst einfach gestaltet sein. Dadurch kann es schneller umgesetzt werden, ist leichter zu verstehen, zu kommunizieren und zu testen. Refactoring: Strukturdefizite des Systems behindern des Weiterentwicklung und werden sofort behoben. Refactoring ist Verbesserung nichtfunktionaler Eigenschaften, bei der die Funktionalität unangetastet bleibt. Unittests prüfen, dass Funktionalität erhalten bleibt Programmieren in Paaren: Durch 2 kooperierende Entwickler bessere Ergebnisse und es verbreitet sich Wissen durch wechselnde Paare schneller.

Weitere Praktiken/Empfehlungen


Offene Arbeitsumgebung



Informativer Arbeitsplatz



CRC-Karten


• Just Rules

• Lokale Anpassungen

• Parties


XP V2

• Ende 2004 überarbeitete Version von Kent Becks „eXtreme Programming explained“

• Heißt auch XP2

• Zusätzlicher Wert: Respekt

• Jetzt auch Ergänzung um projektspezifische Werte möglich

• Wikipedia beschreibt XP2: http://de.wikipedia.org/wiki/Extreme_Programming


XP V2


Prinzipien

Vorführender


Menschlichkeit: SE ist menschliche Aktivität, in der soziale Beziehungen entscheidende Rolle spielen. Darf nicht nur an geschäftlichen Interessen ausgerichtet sein Wirtschaftlichkeit: Softwareprojekte müssen wirtschaftlich sein, indem sie mehr Gelb bringen als kosten Gegenseitiger Vorteil: Jede Aktion soll jedem Betroffenen einen Vorteil bringen (win-win-Situation) Selbstähnlichkeit: Lösungen, die an einer Stelle funktionieren, lassen sich häufig auf andere Kontexte/Größenordnungen übertragen Verbesserung: Alles kann uns muss ständig verbessert werden, nichts ist perfekt. Nicht von der Umsetzung abhalten lassen, weil man nicht weiß, wie die Lösung aussieht Mannigfaltigkeit: Menschen sind verschieden. Diese Mannigfaltigkeit ist manchmal unangenehm, birgt aber auch große Potentiale Fluss: Die Aktivitäten in einem XP-Projekt liefern einen ständigen Fluss an wertvoller Software, die immer ein kleines Stück besser wird Gelegenheit: In XP werden Probleme als Chance für Veränderung aufgefasst Redundanz: Es soll keine Redundanzen im Quellcode geben, aber im Entwicklungsprozess! Relevante Probleme werden nicht nur durch einen Mechanismus adressiert, sondern durch mehrere Fehlschlag: Fehlschläge sind nicht zu vermeiden und sogar hilfreich, wenn man aus ihnen lernt (Versuch macht klug) Qualität: Man kann Qualität nicht senken um Kosten zu sparen oder Termin einzuhalten. Stattdessen führen Investitionen in Qualität häufig zu schnellerer Entwicklung Reflexion: Gute Team reflektieren über ihre Arbeit Babyschritte: Jede Veränderung wird in kleinen Schritte vorgenommen Akzeptierte Verantwortung: Verantwortung muss akzeptiert werden, sie kann nicht zugewiesen werden. Zusammen mit Verantwortung kommt Autorität: Entwickler der sich Story nimmt, akzeptiert die Verantwortung für das Design, die Programmierung und Test, hat aber auch die Autorität, um über das Design zu entscheiden

XP V2


Praktiken

Vorführender


Komplettes Team: Alle für das Projekt erforderlichen Qualifikationen sollen im Team enthalten sein Energiegeladene Arbeit: Alle Teammitglieder sind engagiert bei der Sache und bringen vollen Einsatz Geschichten: Anforderungen werden als informelle Geschichten aufgeschrieben (neu: nicht notwendigerweise vom Kunden aufgeschrieben => dazu eine eigene Folgetechnik) Wochenzyklus: Eine Iteration dauert 1 Woche Quartalszyklus: Ein Release dauert 1 Quartal Freiraum: Entwickler brauchen Freiraum, um sich mit Neuerungen vertraut zu machen 10-Minuten-Build: Es dauert max. 10 Minuten das Projekt zu übersetzen Inkrementeller Entwurf: Der Entwurf soll immer nur die nächsten, konkret bekannten Anforderungen berücksichtigen

XP V2

• Echte Kundenbeteiligung• Inkrementelles

Deployment• Team-Kontinuität• Schrumpfende Teams• Ursprungsursachen-

Analyse

• Gemeinsamer Code• Code und Tests• Eine Codebasis• Tägliches Deployment• Vertrag mit

verhandelbarem Umfang• Bezahlung pro

Benutzung


Ergänzende Praktiken

Vorführender


Echte Kundenbeteiligung: Kunde erst integrieren, wenn das Team mit Stories und inkrementellem Entwurf gut arbeitet Inkrementelle Ausbreitung: Altsysteme/Existierende Systeme stückchenweise ersetzen durch Deployment geeignet gewählter Featurebundles beim neuen System und parallelem Einsatz von alt und neu Team-Kontinuität: Alle Projektmitglieder zu 100% im Projekt, Personalfluktuation soll minimiert werden Schrumpfende Teams: Ziel ist, die Produktivität des Projekts soweit zu erhöhen (mit der Zeit), dass ein Entwickler aus dem Projekt entfernt werden kann und seine Erfahrungen dann in einem anderen Team einbringen kann Ursprungsursachen-Analyse (engl. Root-Cause Analysis): Problemen wird systematisch auf den Grund gegangen Code und Test: Außer dem Quellcode und den Tests werden keine weiteren Artefakte gepflegt. Der Code soll seinen Zweck kommunizieren Eine Codebasis: Es gibt nur eine Codebasis, an der entwickelt wird. Branches sind nur kurzzeitig erlaubt Tägliches Deployment: Der aktuelle Systemstand soll jeden Tag an die Anwender verteilt werden. Nur möglich wenn sehr weniger Fehler pro Jahr!!! (unter 12) Vertrag mit verhandelbarem Umfang: Vertrag geht über ein fixes Budget, aber was der Kunde bekommt ist variabel Bezahlung pro Benutzung: Der Kunde zahlt nicht pro Release sondern er bezahlt die Funktionen pro Benutzung (gibt‘s schon für Hardware im Servermarkt und beim Application Hosting) Wirklich neu nur Bezahlung pro Benutzung, Ursprungsursache-Analyse und Schrumpfende Teams

Neue und alte Praktiken


Bewertung/Anwendbarkeit

• XP ist nur für kleine Teams ausgelegt (≤ 10 Entwickler).

• XP erfordert hochqualifizierte Mitarbeiter.

• Die XP-Praktiken sind untereinander stark verkettet. Das erzwingt ein „Alles oder Nichts“-Vorgehen.

• Wenn kein Kunde vor Ort möglich, da keiner existent (Software für den Massenmarkt), sollten ausgewählte Teammitglieder diese Rolle Vollzeit übernehmen.


Bewertung/Anwendbarkeit

• Gibt es mehrere Kunden, kann es Probleme geben, wenn die Machtverhältnisse nicht geklärt sind

• Die am häufigsten verwendete agile Methodik, aber fast immer an das Projekt angepasst (und so soll es auch sein!)


XP Simulation


SCRUM


Scrum Facts

• Scrum ist ein agiles Managementframework

• Scrum ist nicht auf Softwareprojekte limitiert…

• ...und enthält auch keine Praktiken, die vorschreiben, wie die Software entwickelt werden soll

• Scrum ist von den Ideen des lean management/leanproduction inspiriert

• Erstes Scrum-Projekt war 1993

• Einer der Väter ist Jeff Sutherland


J. Sutherland: Agile Development: Lessons Learned from the First Scrum, in: Cutter ConsortiumAgile Project Management Advisory Service. Executive Update, Vol. 5, No. 20, 2004

Was ist ein Scrum?


Scrum (deut. „Gedränge“) ist ein Spielzug aus dem

Rugby

Der Spielzug ist kompliziert, er muss sorgsam einstudiert

und orchestriert werden

Verlangt disziplinierte Teamarbeit

Scrum ist…

• ein empirischer Prozess: inspect and adapt

• no silver bullet

• harte Arbeit für alle Beteiligten

• inspiriert von den Ideen der lean production(japanische Unternehmen, insb. Toyota)

• ein Versuch Überlastung systematisch zu vermeiden, durch Selbstverpflichtung eines autonomen Teams


Vergleich von Entwicklungszyklen


Ziele in Gefahr

Mehr Mitarbeiter, längere

Arbeitszeiten

Schlechte Softwarequalität,

schlechte Mitarbeitermoral

Mehr Kontrollen

Teufelskreislauf

Vergleich von Entwicklungszyklen


Umsetzung von Anforderungen in

Software regelmäßig überprüfen

Probleme und Hindernisse frühzeitig

erkennen

Ursachen finden, Lösungsoptionen

entwickeln

Die richtigen Maßnahmen

ergreifen

Scrum-Kreislauf

Verbesserungen durch Scrum

• Mitarbeiterzufriedenheit

• Kundenzufriedenheit

• Time to market

• Qualität

• Produktivität


Scrum Alliance

• Scrum ist stärker institutionalisiert

• Es gibt Schulungen zum Certified Scrum Master und Certified Scrum Product Owner

• www.scrumalliance.org


Scrum im Überblick


Max. 30 Tage

User Story 1Der User soll irgendwas irgendwas können,und ywar möglichst was interesaaantes

Sprint

ProductBacklog

Sprint Backlog

Daily Scrum

Auslieferbares Produktinkrement

Vorführender


Scrum Projekt = folge kurzer Arbeitszyklen Jeder Zyklus wandelt Anforderungen aus dem Product Backlog in ein auslieferbares Produktinkrement Dauer eines Sprints maximal 30 Tage! Ein Sprint endet zum vereinbarten Termin (timeboxing) Vor dem Projekt: Product Owner, Team und Scrum Master müssen einsatzbereit sind ProBackl muss initial gefüllt sein, mit Prioritäten Am Anfang jedes Sprints: Planungssitzung bei der das Team Anforderungen (ProdBackl) auswählt und in das Sprint Backlog einträgt Jeden Tag am selben Ort zur selben Zeit kurzes Meeting: Daily Scrum: anstehende Arbeit koordinieren, Hindernisse identifizieren… Am Ende des Sprints: Sprint-Review: Product Owner überprüft Arbeitsergebnisse und nimmt sie ab Partiell fertige Sachen gelten als nicht erledigt Im Anschluss: Sprint-Retrospektive: Über Zusammenarbeit reflektieren, Verbesserungen ableiten

Inkrementelle Innovation

• Anforderungen an neue Version möglichst minimal• Dafür so schnell und häufig wie möglich Funktionalität

ausliefern• Kein „Big-Bang“-Release mit umfangreichen neuen

Funktionen auf einen Schlag• Scrum passt hierfür sehr gut, da jeder Sprint ein

Produktinkrement erzeugt• Vorgehen: Identifiziere die kleinste Menge an

vermarktbaren Merkmalen, die einen echten Mehrwert darstellt


Vorteile Inkrementeller Innovation

• Projektdauer und Time-to-market niedriger

• Früherer break-even und verbesserter cash-flow

• Risikominimierung durch Reduktion der notwendigen Investitionen pro Version

• Höhere Profitabilität (besserer ROI) möglich

• Bessere Vorhersage der Kundenbedürfnisse und schnellere Rückmeldung

• Kurze Zyklen helfen, termingerecht zu liefern


Vorführender


Schnelles Feedback und aktuelle Infos zu Kundenbedürfnissen erlauben schnellere Reaktion auf Marktveränderungen Beispiel PatientKeeper, Firma für Software für medizintechnische System, stellt Kunden alle 3 Monate eine neue Version zu Verfügung. Wobei nicht alle Kunden jede neue Version nutzen können

Rollen in Scrum

Scrum

ProductOwner

Team

ScrumMaster


Product Owner

• Anforderungsbeschreibung und –management

• Releasemanagement und Return on Investment

• Enge Zusammenarbeit mit dem Team

• Stakeholder-Management

• Ist nicht der Kunde


Scrum Master: Aufgaben

• Scrum etablieren

• Das Team unterstützen

• Direkte Zusammenarbeit zwischen Product Ownerund Team sicherstellen

• Hindernisse beseitigen

• Entwicklungspraktiken verbessern helfen

• Führen durch Dienen


Vorführender


Führen durch dienen: Der Scrum-Master ist ein servant-leader, eine Führungsfigur, deren Aufgabe es ist, dem Team zu dienen. Scrum Master hat zwar Einfluß, aber keine Autorität bezüglich der Arbeitsorganisation des Teams Deshalb: Aufgabe ist, das Team zu unterstützen, nicht Anweisungen zu verteilen

Scrum Master: Fähigkeiten

• Moderation

• Coaching

• Erfahrung in der (Software-)Entwicklung


Scrum Master

• …sollte idealerweise vom Team bestimmt werden

• …sollte keine Personalverantwortung für die Teammitglieder haben

• …hat eine sich über die Projektdauer ändernde Rolle: Vom Vollzeit-Scrum Master als Change Agent zu Beginn bis zum Teilzeit-Scrum Master, der auch an der Erreichung des Sprint-Ziels mitwirkt, am Ende


Team

• Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare Produktinkremente nötig sind

• Entscheidend: Die richtigen Mitarbeiter im Team (Mitarbeiter müssen über das relevante Wissen und die notwendigen Fähigkeiten verfügen)

• Empfehlung: Die Mitarbeiter bestimmen lassen, in welchem Projekt sie mitarbeiten (bei Google sollen sich die Entwickler für Projekte selbst nominieren)


Wie sollte das Team sein?

• Bevollmächtigt (empowered)

• Autonom

• Interdisziplinär besetzt

• Selbstorganisiert

• Klein


Vorführender


Empowered: Team entscheidet allein, wie viele Anforderungen es im nächsten Sprint in ein Produktinkrement umsetzen kann. Team entscheidet, welche Arbeitsschritte notwendig sind und wie es seine Arbeit organisiert. Es muss auch in schwierigen Situationen in der Lage sein, nein zu zu vielen Anforderungen zu sagen. Bevollmächtigung verlangt vom Management Vertrauen in die Fähigkeit des Teams Autonom: Team muss in der Lage sein, das Sprint-Zeil ohne wesentliche externe Abhängigkeiten zu erreichen. Schlechtes Indiz: Regelmäßig Aufgaben im Sprint-Backlog, die von Mitarbeitern außerhalb des Teams ausgeführt werden müssen Interdisziplinär: Alle Rollen, die für die Umsetzung von Projekt- und Sprint-Ziel benötigt werden, müssen im Team vertreten sein: Architekt, Tester, Entwickler, Dokumentationsexperte,… Klein: Zwischen 5 und 9 Mitglieder

Arbeitsorganisation des Teams

• Vollzeitmitarbeiter

• Collocation: Alle Arbeitsplätze in unmittelbarer Nähe, am besten in einem Teamraum

• Team muss Normen und Standards für die Arbeit formulieren

• Visueller Arbeitsplatz


Das Scrum-Team

• Echtes Team, keine Ansammlung von Individuen

• Verfolgt gemeinsam ein Ziel

• Zeichnet sich durch gegenseitigen Respekt und Verständnis seiner Mitglieder aus, folgt gemeinsamen Normen

• Mitglieder arbeiten eng zusammen und unterstützen sich gegenseitig

• Teambildungsprozess erforderlich, ein Team entsteht nicht über Nacht


Phasen der Teamentwicklung nach Tuckman

Forming

Storming

Norming

Performing


Änderung der Team-zusammensetzung

Änderung der Team-zusammensetzung

Bruce W. Tuckman: Developmental Sequence in Small Groups, in: Psychological Bulletin, Vol. 63, 1965

Vorführender


Forming: Team wird formiert (formell/organisatorisch) Storming: Phase der Auseinandersetzung Norming: Herausbildung gemeinsamer Arbeitsweisen/Normen Performing: Team arbeitet produktiv Nächste Folie erst an Tafel sammeln.

…und wer macht die Projektleiterjobs?

Aufgabenbereich Scrum-RollenScope-Management •Product Owner für Produktversion

•Team für Sprints

Zeitmanagement •Product Owner für den Releaseplan•Team für das Sprint Backlog

Kostenmanagement Product Owner

Kommunikationsmanagement •Product Owner für das Release-Reporting•Team für Berichterstattung im Sprint

Risikomanagement Product Owner mit Input vom Team

Qualitätsmanagement •Product Owner für die Produktleistungsmerkmale•Team für qualitätssichernde Maßnahmen•Scrum Master für die richtige Anwendung des

Prozesses

Lieferantenmanagement Product Owner und Team

Personalmanagement •Management für die Bereitstellung der Mitarbeiter•Team für Produktivität und kontinuierliche

Prozessverbesserung


Anforderungsgewinnung


Anforderungs-beschreibung Umsetzung

Sprint 1

Anforderungsbeschreibung

Umsetzung

Sprint n

Traditionelles Vorgehen

Vorgehen in Scrum

Vorführender


PO entscheidet über Anforderungen für eine Softwareversion und beschreibt diese in Zusammenarbeit mit dem Kunden, dem Team und anderen Interessenvertretern. Zentrales Instrument ist das Product Backog. Traditionell: Großer Bestand an Anforderungen am Anfang erstellen, aber oft sehr instabil, Informationsverlust durch Übergaben, Überproduktion an Funktionalität. -> Wollen wir alles nicht

Anforderungsgewinnung


Product Owner

Kunde Endanwender Interessenvertreter

Team

Product Backlog

Vorführender


Im Product Backlog werden alle Anforderungen und Arbeitsergebnisse gesammelt, die für das Projektziel erreicht werden müssen: FURPS+ Anforderungen aber auch Aufgaben wie „Bug x entfernt“, „Test- und Entwicklungsumgebung verfügbar“. Im Product Backlog stehen keine Aktivitäten sondern Ergebnisse! Aktivitäten identifiziert das Team für das Sprint Backlog

Das Product Backlog

• Nicht fix, sondern ein „lebendiges“Dokument

• Entwickelt sich iterativ und inkrementell

• Scrum kennt keine „Change-Requests“, dennoch ist es oft nützlich, Änderungen am Product Backlog zu dokumentieren

• Alle Einträge priorisiert und bzgl. Aufwand geschätzt


Vorführender


Nicht fix: Anforderungen werden modifiziert, verfeinert oder entfernt, neue Anf. Kommen dazu Keine Change-Requests: Es ist dennoch sinnvoll, Änderungen am PB zu dokumentieren, z.B. durch Versionierung Priorisierung: Durch den PO. Er wählt auch wonach er priorisiert, z.B. Risiko, Nutzen, Kosten. Team gibt Input zu technischen Risiken Nicht alle Eintrage gleich detailliert: Hochpriore Anforderungen detaillierter Abgeschätzt: Durch abstr. Schätzgröße wie story points. Aufwandsschätzung kommt vom Team!

Das Product Backlog


Vorführender


Empfehlung von Praktikern: Anfangs Erfassung mit Karten (besonders bei Anforderungsworkshops), wenn die wichtigsten erfasst sind, Übertragung in elektronische Form

Wie kommt man zum Product Backlog?


Produktkonzept

ProduktideeProduct Backlog

Vorführender


Produktkonzept: was ist das zu befriedigende Kundenbedürfnis wesentliche Leistungsmerkmal, Zielgrößen => Alleinstellungsmerkmale, wichtige Funktionen Mehrwert für den Kunden/Anwender Roadmap PO erstellt PK unter Einbeziehung von Kunden,Team, Interessenvertreter (wie Marketing, Service, Vertrieb…) PO somit frühzeitig auch in Innovations- und Marktforschungsaktivitäten involviert PK kein muß für Scrum, hat aber Vorteile: *Eruierung des Markpotentials, Formulierung wirtschaftlicher Ziele, somit Go/No-Go Entscheidungsgrundlage *Basis für zielgerichtete und effiziente Erstellung des PB *Einheitliche Ausrichtung aller Interessensvertreter (Team, Kunde,Marketing,…) PK kurz und knapp, leicht verständlich. Fokus: Mehrwert und Merkmale, die für wirtsch. Erfolg entscheidend Annahme, dass Kaufmotiv nicht in 1 Satz beschrieben werden kann ist falsch (sagt Marktforschung). Die meisten erfolgreichen Produkte haben einen eindeutigen, klaren Mehrwert

Das Product Backlog füllen

• Product Backlog möglichst minimalistisch, dennoch alle wichtigen Anforderungen von Beginn an festhalten

• Initial mindestens Anforderungen für die erste 2-3 Sprints

• Zentrale Funktionalität ins Product Backlog, aber auch nichtfunktionale Anforderungen


Vorführender


Negativbeispiel: Initiales PB mit 1800 Anforderungen noch vor dem 1. Sprint Generell: Alle für den Geschäftserfolg wesentlichen Anforderungen aufnehmen Initial Material für 2-3 Sprints, um dem Team und PO genügend Material für eine Sprintplanung zu geben. Außerdem Sicht über den unmittelbar nächsten Sprint hinaus nützlich Nichtfunktionale Anf.: Von Skalierbarkeit über Performanz bis zu Anforderungen für die Benutzerschnittstelle (diese sind oft sehr bedeutsam für den Erfolg, daher vom PO möglichst früh zu ermitteln)

Das Product Backlog füllen

• Die Einträge im Product Backlog werden unterschiedlich detailliert ausgearbeitet

– Hoch priorisierte Einträge werden detaillierter erfasst– Je höher das Risiko und je niedriger das Domänenwissen

des Teams, desto genauer muss eine Anforderung formuliert sein

• Beschreibungen der Einträge werden über die Zeit verfeinert


Vorführender


Unterschiedliche Detaillierungsstufen helfen den initialen RE-Aufwand niedrig zu halten Verfeinerung: Von Thema über grobe Aufgaben zu Einzelfunktionen

Themen als Strukturierungswerkzeug

• Themen gruppieren mehrere inhaltlich zusammenhängende Einträge im Product Backlog

• Vorteile von Themen– Überblick behalten– High-level Sicht kann das Priorisieren erleichtern– Themen können bei der Freigabeplanung helfen, da für die

Endnutzer üblicherweise Merkmalsbündel interessant sind, nicht einzelne Anforderungen. Mit Themen kann der Product Owner leichter überwachen, welchen Fertigstellungsgrad einzelne Merkmalsbündel haben.


Vorführender


Beispiel für ein Thema ist „Kalender“. Darunter fällt z.B. „Termin eintragen“, „Teilnehmer zu Besprechung einladen“, „Uhrzeit einer Besprechung ändern“

Zum Product Backlog in 5 Schritten

1. Eigenschaften, die aus dem Produktkonzept folgen, sowie Anforderungen, die durch Fokusgruppen, Kundeninterviews, Anforderungsworkshops,… ermittelt wurden, kommen in das Product Backlog

2. Product Owner gruppiert Anforderungen zu Themen

3. Product Owner priorisiert die Themen und ggf. einzelne Anforderungen (in Zusammenarbeit mit dem Team)


R. Pichler: Scrum, dpunkt.Verlag, 2008

Vorführender


Bei Schritt 1: Alles erst mal grobgranular beschrieben. Wichtig ist alle bekannten Anfo. rasch aufzunehmen (funktionale und auch nicht-funktionale und User-Interface-Anforderungen) Dies ist dann die initiale Befüllung des PB. Nach Schritt 2 haben wir eine aufgefülltes PB, das inhaltlich nach Themen strukturiert ist Unter einer Fokusgruppe (aus dem englischen: "focus group") versteht man eine Form der Gruppendiskussion, die zum Beispiel in der Marktforschung eingesetzt wird: eine moderierte Diskussion mit 8-12 Teilnehmern, welche im Normalfall 1,5 bis 2 Stunden dauert und durch einen erfahrenen Moderator geleitet wird. Es handelt sich hierbei um ein Verfahren der qualitativen Sozialforschung, das auf Robert K. Merton zurückgeht.

Zum Product Backlog in 5 Schritten

4. Product Owner verfeinert die hochpriorenAnforderungen (vorzugsweise in Anforderungs-workshops) unter Einbeziehung des Teams

5. Aktualisierung, Verfeinerung oder Löschung existierenden Anforderungen anhand der Ergebnisse nachfolgender Anforderungsworkshops. Neue Themen und Anforderungen werden aufgenommen.


Vorführender


Nach Schritt 4 sollte das PB in einem Zustand sein, in dem der erste Sprint gestartet werden kann

Anforderungsworkshop

• Hilfreiches Werkzeug zur Anforderungsgewinnung, ergänzt Fokusgruppen, Interviews, Beobachtung der Anwender

• Alle Interessenvertreter an einem Tisch

• Etabliert gemeinsames Verständnis, sorgt für gemeinsame Sprache und adäquate Beschreibung

• Mehrere vor dem ersten Sprint, regelmäßig während der Sprints um neue Anforderungen zu bestimmen


Vorführender


Gemeinsame Anforderungsentwicklung macht Reviews der Anforderungen überflüssig Der PO lädt dazu ein Technik: Z.B. Karteikarten, sind leicht handhabbar Moderation muß gut sein!! Werden neue Methoden (z.B. User Stories) eingesetzt, diese vorher einführen!

Priorisieren des Product Backlog

• Warum? Das Wichtigste zuerst!– Zielgerichtete Verfeinerung der wichtigsten Anforderungen– Team weiß, was für den Erfolg des Projekts entscheidend

ist und fokussiert darauf

• Priorisieren ist schwierig! Product Owner muss Kundenbedürfnisse genau kennen und beurteilen, welche Funktionen für erfolgreichen Einsatz entscheidend sind


Vorführender


Frühzeitige Umsetzung der wichtigsten Anford. erlaubt der frühere Überprüfung durch PO im Sprint-Review und ein Vorführen vor dem Kunden Fokussierung auf die hochprioren Anforderungen beim Verfeinern hält Aufwand für Anforderungsbeschreibung vor 1. Sprint gering

Kriterien für Priorisierung

Priorität

Kosten

RisikoWert


Primäre Frage: Wie viel Wert schafft eine Anforderung

Ziel eines Projekts ist die Generierung von

Mehrwert

Vorführender


Die Beantwortung der Hauptfrage bedingt natürlich, dass man die Bedürfnisse des Kunden kennt! Verantwortlich für Priorisierung ist der PO, er muss aber die Kundensicht einnehmen Kano-Modell an der Tafel Vor nächster Folie Studenten kurz überlegen lassen, was eigentlich ein Risiko ist

Risiken

• Beispiele sind– Verständnis der Anforderung– Architektur und Technologieauswahl– Infrastruktur und Prozess

• Je innovativer ein Projekt, desto mehr Unsicherheit

• Product Owner und Team identifizieren gemeinsam die Risiken (bei jeder Aktualisierung das Releaseplans)


Risiko

Unsicher

Verursacht Schaden

In der Zukunft

Vorführender


Kostenbestimmung/Kostenschätzung wie in XP in einer abstrakten Messgröße. Kosten können durch Umlage der geschätzten Gesamtkosten des Sprints (in Euro) auf die akkumulierten Storypoints des Sprints

Risiken

• Identifizierte Risiken werden analysiert, Gegenmaßnahmen werden zu neuen Einträgen im Product Backlog

• Keine Analyse möglich ⇒ Anforderung hoch priorisieren und im nächsten Sprint umsetzen

• Ein solches Vorgehen hilft vermeiden, dass Risiken erst spät wirksam werden. Ein early-fail ist dabei nicht ausgeschlossen

• Scrum ist ein risikoorientierter Ansatz


Vorführender


Mögliche Gegenmaßnahmen sind beispielsweise Prototyp, Mitarbeiterschulung… Umsetzung im nächsten Sprint eines nicht zu analysierenden Risikos: Risiko wird exploriert, mehr Informationen verfügbar, ggf. weitere Gegenmaßnahmen Bsp.: Risiko Kundenanforderung falsch verstanden. Implementierung erlaubt zum Sprintende Feedback durch Kunde ob alles OK Scrum ist ein risikoorientierter Ansatz: Probleme frühzeitig offen adressieren. Ähnlich Spiralmodell Innovation ohne Risiko ist unmöglich! Nächste Folie kurz an der Tafel

Wert-Risiko-Matrix


Risiko

Wert

Vermeiden Als erstes

Zuletzt Als zweites

Hoch

Niedrig

Niedrig Hoch

MuSCoW Einteilung


Must have

Should have

Could have

Won‘t have

Vorführender


Won‘t have kommen in die nächste Iteration. Es gibt 2 Puffer: Entwicklung schneller als gedacht: „Won‘t have“ schon früher Entwicklung langsamer als gedacht: „Could have“ in die nächste Iteration

Mehr zu Anforderungen

• Eine Anforderung sollte die INVEST-Eigenschaften haben

– Independent– Negotiable– Valuable– Estimable– Small– Testable


Vorführender


Independent: Im Idealfall Abarbeitung in beliebiger Reihenfolge möglich. Dies ist natürlich nicht immer möglich. Z.B. muss es eine Entwicklungsumgebung geben, bevor mit dem Entwickeln begonnen wird Negotiable: Die Einträge im PB müssen dem PO und dem Team einen gewissen Spielraum für die Sprint-Planungssitzung lassen. Ist beispielsweise eine Anforderung zu groß, um ganz umgesetzt zu werden, so sollte es möglich sein, diese zu modifizieren und so eine vollständige Realisierung möglich machen Valuable: Einträge im PB sollen einen klaren Nutzen haben. Auch nicht wertschöpfende Einträge müssen einen Nutzen für das Projekt haben (z.B. Testumgebung) Estimable: Einträge im PB müssen vom Team abgeschätzt werden können, d.h. insbesondere, dass das Team den Eintrag/die Anforderung verstehen muss Small: Die Einträge im PB sollen kurz gehalten werden. Auch komplexe Anfoderungen zunächste nur skizzenhaft erfassen. Nur die hochprioren Anforderungen detailliert Testable: Einträge im PB sollten testbar sein (Akzeptanzkriterien!). Die Akzeptanzkriterien präzisieren oft auch den Anforderungstext

Anforderungen erfassen

• Beschreiben Anforderungen aus Sicht des Endanwenders

• Bestandteile– Name– Kurze Beschreibung der Anforderung– Akzeptanzkriterien

• Text beinhaltet Benutzerrolle, Ziel der User Story und optional den Nutzen des Merkmals

• 3 C-Bedingung einhalten: Card, Conversation, Confirmation


User Stories

Vorführender


Werden traditionell auf einfachen Kartekarten erfasst, Name+Beschreibung auf Vorderseite, Akzeptanzkriterien auf Rückseite Card: Passt auf 1 Karte Conversation: Karte ersetzt nicht Gespräch zwischen PO und Team sondern dokumentiert dessen Ergebnis Confirmation: Geschichte muß überprüfbar und testbar sein Unterschied zu Use-Cases: Use Cases beschreiben die Interaktion eines Anwenders mit dem System mit verschiedenen Szenarien (Hauptszenario, alternative Szenarien, Ausnahmeszenarien). Use Cases typischerweise komplexer als User Stories. Use Case lässt sich in der Regel nicht in einem Sprint ganz in ein Produktinkrement umsetzen Auch nichtfunktionale Eigenschaften wir Performanz lassen sich in einer User Story erfassen, z.B.: „Als Anwender will ich in der Lage sein, Informationen innerhalb von 500 Millisekunden zu erhalten.“. Akzeptanzkriterium dann z.B.: „Bis zu 500 Anwender gleichzeitig aktiv.“ Nicht gut für Anforderungen an User Interface und Anforderungen für Subsysteme/Komponenten. Hierfür UI-Spezifikationen/UI-Prototypen bzw. UML-Dokumente besser geeignet.

Vorteile von User Stories

• User Story beschreibt Anforderung zusammen mit Nutzen für Anwender

• User Stories unterstützen systematische Verfeinerung von Anforderungen

• Gute User Stories erfüllen die INVEST-Kriterien

• Einsatz leicht zu erlernen

• Akzeptanzkriterien bilden gute Grundlage für Akzeptanztests


Vorführender


Aus Punkt 1 folgt automatisch, dass die Anforderung einen Mehrwert erzeugt

Releaseplanung

• Aspekte der Releaseplanung:– Schätzen– Planen– Berichten


Ziel: Vorausschauende Steuerung und Optimierung der Kundenzufriedenheit und Wertschöpfung über die Grenzen einzelner Sprints hinweg

Vorführender


Beim Schätzen kommen Techniken wie im XP zum Einsatz Releaseplan ist nötig, wenn Projekt nicht sehr klein oder unkritisch. Man will nicht blind von Sprint zu Sprint stolpern Anzahl und grobe Inhalte der Sprints sollen antizipiert werden: Wie viele Sprints nötig (=> ungefähre Schätzung der Projektdauer) und wann wird welche Anforderung voraussichtlich umgesetzt? Releaseplan ist wichtiges Werkzeug für PO um rechtzeitig Entscheidungen treffen zu können und um Kosten und Termine in Einklang zu bringen

Unterschiede zur traditionellen Releaseplanung


Kein detaillierter Plan mit allen Aktivitäten zu Anfang des Projekts

Verzicht auf den aussichtslosen Versuch, alle Eventualitäten vorhersehen und planen zu können

Vorführender


Der Releaseplan gibt Team+PO ein gemeinsames Verständnis über die Reihenfolge, in der Anford. sinnvollerweise umgesetzt werden sollten. Dies ermöglicht es, den Arbeitsanfall möglichst gleichmäßig zu verteilen und die Produktivität zu optimieren. Planung in Scrum hat zum Ziel, keine faule Kompromisse bei der Qualität eingehen zu müssen und gleichzeitig gesunde und motivierte Mitarbeiter und zufriedene Kunden am Ende des Projekts vorzufinden.

Releaseplan in Scrum

• Basis sind die derzeitigen Informationen zu– den geschätzten Aufwänden im Product Backlog– der derzeitigen Entwicklungsgeschwindigkeit des Teams


In Scrum ist der Releaseplan eine

Vorhersage

Ebenen der Planung


Release-planung

Sprint-planung

Tages-planung

ProductBacklog

Release-plan

Sprint Backlog

Aktueller Fortschritt und

aktuelle Probleme

Vorführender


Releaseplanung macht der PO Sprintplanung macht das Team, die Sprintplanung erfolgt in der Sprint-Planungssitzung am Anfang des Sprints, ca. 0,5 Tage Tagesplanung in Form des Daily Scrum macht das Team Releaseplan ist grobe Vorhersage und enthält antizipierte Reihenfolge der PB Einträge (soweit möglich) Sprint-Backlog beschreibt, welche Anford. ins nächste Produktinkrement aufgenommen werden; wird täglich aktualisiert

Typen von Sprints


Explorations-sprints

Standardsprints

Releasesprints

Beispiel für Releaseplan


Verfolgen des Projektfortschritts

• Häufiger Abgleich zwischen Plan und Wirklichkeit hilft Projektfortschritt zu verstehen und ggf. gegensteuern zu können

• In Scrum ist Berichterstattung in hohem Maße transparent → Verzögerungen/Probleme früh erkennen

• Traditionell eher Verdrängung von Problemen üblich

• Releaseberichterstattung basiert auf Aufwänden im Product Backog und dem tatsächlichen Fortschritt


Vorführender


In vielen Projekten gilt immer noch „shoot the messenger“. Wer Probleme anspricht wird dafür nicht gerade gelobt. Wenn die Probleme nicht mehr ignoriert werden können, wird mit einer Notlösung reagiert Hier ist für den Einsatz von Scrum ein Umdenken der Mitarbeiter gefragt. Damit in Scrum ein realistisches Bild des Fortschritts entsteht ist es nötig, dass der PO nur fehlerfreie Arbeitsergebnisse akzeptiert und abnimmt (keine Leichen im Keller)

Burndown-Chart


Release-Burndown

Sprints

Aufwände im Product Backlog

1 2 3 4 5 6 7

Vorführender


Trend (besser/schlechter als geplant) früh erkennbar. Erlaubt es frühzeitig mit dem Kunden über Streichen von Anforderungen oder verschieben des Releases zu sprechen Es ist z.B. auch die gezielte Frage möglich: Sind Hindernisse aufgetreten, die noch nicht beseitigt sind

Entwicklungsgeschwindigkeitsbericht


15 17 18 2012

20

Sprints

Erledigte Aufwandspunkte

1 2 3 4 5 6

18

7

Ø aller Sprints

Ø der 3 schlechtesten

Sprints

Vorführender


Bildet Vorhersagegrundlage für die weitere Releaseplanung Durchschnitt der schlechtesten Sprints kann für einen Worst-Case-Releaseplan herangezogen werden

Themenpark

• Stammt als Berichterstattungsform ursprünglich aus dem FDD

• Stellt Fertigstellungsgrad und Freigabefähigkeit von Funktionalitätsclustern dar


Thema A4 Geschichten

12 Punkte

Thema B3 Geschichten

4 Punkte

Thema C3 Geschichten

18 Punkte

Vorführender


Wird am Ende jedes Sprints aktualisisert

Sprints


Sprints im Überblick

Sprint-planung

ProductBacklog

Umsetzungsaktivitäten und Daily Scrum

Sprint-Review und Sprint-Retrospektive

Verbesserungs-maßnahmen

Vorführender


Übergang von Sprint zu Sprint mit Review/Retrospektive und Planungssitzung an der Tafel

Sprints

• Wandelt Anforderungen in lauffähige, getestete und dokumentierte Software um

• Vorgehen ist iterativ und inkrementell• Agile Entwicklungspraktiken (z.B. TDD) einsetzbar

aber nicht festgelegt• Während des Sprints keine Änderung an dessen

Dauer, den Anforderungen in Sprint Backlog und der Teamzusammensetzung

• Overhead für Scrum-spezifische Aktivitäten ≤ 10%


Vorführender


Iteratives Vorgehen mit Grafik veranschaulichen Scrum-spezifische Aktivitäten: Sprint-Planung, Sprint-Retrospektive,… Bei einem 4-Wochen Sprint bedeutet das, dass für Planung ca. 1 Tag und für Review und Retrospektive ca.1 Tag zur Verfügung stehen

Sprint-Planungssitzung

• …definiert der Product Owner das Sprint-Ziel– Erklärt allen Beteiligten, was in der Summe das erwartete

Ergebnis des Sprints ist– Realistisch, kurz und gut verständlich– Team in die Formulierung einbeziehen, Release Plan liefert

ebenfalls Input– Sorgt für einheitliche Ausrichtung aller Beteiliten– Erleichtert Kommunikation des Sprint-Inhalts an die

Interessenvertreter und die Erfolgskontrolle• …beginnt der Product Owner einige Tage vorher mit

der Verfeinerung und Aufbereitung der Anforderungen (z.B. Anforderungsworkshop)


Zur Vorbereitung der Sprint-Planungssitzung

Vorführender


Sprint-Ziel sollte das Projekt seinem Gesamtziel einen Schritt näher bringen Für Anforderungsworkshop (PO und Team) nicht unbedingt das ganze Team, aber immer einiger Entwickler und Tester Stellt sich bei der Verfeinerung der Anforderungen heraus, dass viel Explorationsarbeit (z.B. Wegwerfprototypen) nötig ist, dann kann dies als Eintrag im PB Teil das nächsten Sprints werden oder es wird ein Explorationssprint durchgeführt


• …werden Aufwände für die ausgewählten Anforderungen geschätzt

• …werden die Anforderungen priorisiert

• …wird die Teamkapazität bestimmt


Zur Vorbereitung der Sprint-Planungssitzung

Die Vorbereitung einer Sprint-

Planungssitzung ist viel Arbeit.

Frühzeitig beginnen!

Vorführender


Für die Sprint-Planungssitzung mehr Anforderungen auswählen, als das Team mit seiner aktuellen Geschwindigkeit erledigen kann Bei der Teamkapazität auch Urlaub, etc. berücksichtigen!


• Auswahl eines realistischen Sprint Backlog

• Scrum Master moderiert

• Teamkapazität im Auge behalten: Planungsglas


Sprint-Ziel und Anforderungen

Aktivitäten bestimmen und

schätzen

Aufnahme der Anforderung,

wenn umsetzbar

ProductOwner Team

Vorführender


PO stellt Sprint-Ziel und eine Vorauswahl von Anforderungen vor, die umgesetzt werden sollen Team bestimmt die notwendigen Aktivitäten und deren Aufwand (iterativ, beginnend mit der höchstprioren) Hat das Team die Kapazität und das Wissen, um alle Aktivitäten für eine Anforderung durchzuführen, so wird die Anforderung teil der Sprint-Verpflichtung. Dies ist dann eine Selbstverpflichtung des Teams: Scrum ist commitment-driven Aktivitäten möglichst präzise beschreiben, beispielsweise auf Karteikarten, max. Aufwand für eine Aktivität: 1 Tag Wer später welche Aktivität ausführt, bestimmt das Team selbst. Koordination im Daily-Scrum. Es gilt, dass die Aktivitäten für die höchstpriore Anforderung zuerst angepackt werden.


• Scrum Master plant• Ein Teammitglied dominiert• Viel Designdiskussion• Product Owner identifiziert Aktivitäten• Product Owner nimmt nicht teil• Aktivitäten zu vage oder zu groß• Sitzung schlecht vorbereitet


Ergebnis

• Vereinbartes realistisches Sprint-Ziel• Realistisches Sprint Backlog, zu dem sich das Team verpflichtet hat

Typische Fehler

Vorführender


Sprint-Backlog besteht aus Anforderungen und den zugehörigen Aktivitäten, welche detailliert beschrieben und abgeschätzt sind

Sprint Backlog

• Beinhaltet alle Aktivitäten, die zur Umsetzung der Anforderungen notwendig sind

• Wird täglich aktualisiert– Aktivität beginnen: Karte mit Namen kennzeichnen– Neue Aktivität identifiziert: Schätzen und in Sprint Backlog

einfügen– Am Ende des Tages aktualisieren alle Teammitglieder die

Aktivitäten, an denen sie gearbeitet haben und schätzen den Restaufwand


Vorführender


Das Sprint-Backlog ist ein Werkzeug zum kollektiven Zeitmanagement des Teams Es sind nur Aktivitäten für Anforderungen enthalten, zu denen sich das Team verpflichtet hat Tägliche Aktualisierung des SB macht Arbeitsorganisation und –fortschritt transparent Praxistipp: Karteikarten und Stellwand. Vorteile: Transparenz, da ständig für alle sichtbar, und leichter Zugang, so dass alle ohne Probleme den Plan jederzeit aktualisieren können

Sprint Backlog


Vorführender


Weitere Spalten sind möglich, z.B. „Tests bereit“, „Zu prüfen“

Daily Scrum

• Max. 15 Minuten

• Immer zur gleichen Zeit am selben Ort

• Ziel: Selbstorganisation des Teams unterstützen, Hindernisse identifizieren

• Wer: Komplettes Team, Scrum Master. Product Ownersollte dabei sein, weitere Interessenvertreter als Zuhörer möglich


Vorführender


Kurz und bündig! Scrum Master moderiert Daily Scrum zeigt Probleme auf, sie werden dort aber nicht gelöst

Daily Scrum

• Drei Fragen für jeden:– Was getan seit letztem Daily Scrum?– Was mache ich bis zum nächsten Daily Scrum?– Was behindert meine Arbeit?

• Hindernisse mit Datum versehen notieren

• Vorbereitung für effizientes Daily Scrum:– Sprint Backlog ist aktuell– Sprint Burndown-Chart liegt vor


Daily Scrum


Techniken für das Daily Scrum

Speech Token

Stand-UpMeeting

Meta-diskussion

Variation

Vorführender


Stand-Up Meeting: Im Stehen durchführen! Speech Token: Nur wer das Token hat, redet Metadiskussion: Gibt es Abweichungen vom vorgeschriebenen Vorgehen im Daily Scrum und besteht die Gefahr, dass es ineffektiv wird, sollte die Diskussion unterbrochen werden und in einer Metabesprechung über die Probleme im Besprechungsvorgehen und mögliche Lösungen gesprochen werden Variationen: Eintönigkeit vermeiden, z.B. zusätzliche Frage am Montag: „Was war das Highlight des Wochenendes“ oder Speech Token zuwerfen

Sprint Burndown Chart


Tage

Aufwände im Sprint Backlog

1 2 3 4 5 10 15 20

Vorführender


Hindernisbericht: Enthält alle identifizierten Hindernisse (aus Daily Scrum) mit Datum, z.B. auf Flipchart. Wurde ein Hindernis beseitigt, wird das Datum der Erledigung hinzugeschrieben.

Sprint-Review

• Ziel: Begutachtung der Arbeitsergebnisse

• Product Owner prüft, ob alle akzeptierten Anforderungen vollständig und fehlerfrei umgesetzt wurden

• Dauer ca. 1 bis 2 Stunden

• Wer: Komplettes Team, Product Owner, ScrumMaster, optional weitere Interessenvertreter (Kunde!, Endanwender!)


Sprint-Review

1. Kurze Reflektion über das Sprint-Ziel

2. Team macht Live-Demo der Umsetzung der Anforderungen

3. Product Owner und Interessenvertreter stellen Fragen und geben Feedback

4. Product Owner entscheidet für die einzelnen Anforderungen ob akzeptiert oder nicht


Ablauf

Vorführender


Zu 1: Alle erinnern sich an das große Ziel des Sprints und welche Verpflichtungen das Team eingegangen ist. Macht allen klar, welche Anforderungen als Teil des Produktinkrements umgesetzt sein sollten Zu 2: Der PO muss in der Lage sein, auch selbst Tests auszuführen und die Funktionsweise der Software zumindest stichprobenartig zu prüfen. Sind auch anderer Arbeitsergebnisse (Benutzerhandbuch, Online-Hilfe, Entwicklerdokumentation,…) vereinbart, so sollten diese ebenfalls für Review verfügbar sein Zu 4: Partiell fertiggestellte oder fehlerhafte Arbeitsergebnisse werden nie abgenommen. Fehlerhafte oder halb-fertige Anforderungen stellen keinen Beitrag zu einem auslieferbaren Produktinkrement dar. Fehler oder partiell fertige Funktionalität sollten stets im nächsten Sprint abgearbeitet werden (und stellen neue Einträge für das PB dar) Scrum Master lädt zum Review ein und moderiert. Ans Time-Boxing auch für das Review denken!

Sprint-Review


Techniken für die Sprint-Review

Aktiver ProductOwnerHart,

aber herzlich

Vertrauen ist gut, Transparenz

ist besser

Offenes Protokollieren

Vorführender


Hart, aber herzlich: PO muß klares Feedback geben (Führungsrolle). Deutlich machen, was gefällt und was man nicht für gut befinden kann. Ich-Botschaften. Loben und Kritik üben. Aber immer kollegiale Atmosphäre waren, die Bemühungen des Teams respektieren Aktiver PO: PO muß fähig sein, die angemessene Umsetzung der Anforderungen zu beurteilen. Er muß Fragen stellen und darf vor technischen Begriffen nicht zurückschrecken. Selber ausprobieren und mit der Software arbeiten! Nicht nur Zuschauer oder Kopilot Vertrauen ist gut…: Güte der Software kann der PO oft besser beurteilen, wenn auch Daten über Metriken vorliegen. Daher sind mindestens gefragt: Testprotokolle des letzten offiziellen Build, Testabdeckung, Refaktorisierungspotenzial bzw. Komplexität der Software (wie leicht änderbar, wie hat sich die Komplexität entwickelt im Vergleich zum letzten Sprint) und Coding-Style-Treue Offenes Protokollieren: Auf Whiteboard oder Flipchart dokumentieren, welche Anforderung abgenommen wurde und welche nicht

Sprint-Review


• Passiver Product Owner• Herausstellen Einzelner• Falsches Schulterklopfen• Hokuspokus• Privater Build

Typische Fehler

Vorführender


Passiver PO: PO nickt Arbeitsergebnisse ab und gibt kaum Feedback Herausstellen Einzelner: Nie einzelne Teammitglieder herausstellen, weder positiv noch negativ. Dies würde Einheitsgefühl, Autonomie und Selbstorganisation des Teams untergraben Falsches Schulterklopfen: PO muß Probleme klipp und klar ansprechen, auch wenn das nicht immer leicht ist. Falsches Schulterklopfen und Vermeiden von Konflikten schadet dem Projekt. Für gut Arbeit sollte der PO das Team aber gebührend loben Hokuspokus: Bei Projekte mit viel Aufmerksamkeit seitens des Managements besteht Gefahr, dass das Team ds Review in eine wohlinszenierte Show verwandelt. Dies ist nicht im Sinne des Erfinders. Keine animierten Powerpoint-Präsentationen und spezielle Prototypen Privater Build: Keine Abnahme von Arbeitsergebnissen, wenn nicht der letzte offizielle Build gezeigt wird, der in der dedizierten Testumgebung läuft

Sprint-Retrospektive

• Ziel: Zusammenarbeit im Team und Anwendung des Prozesses verbessern

• Wann: Direkt nach dem Sprint-Review

• Dauer: 1,5 bis 2,5 Stunden

• Wer: Komplettes Team, Scrum Master, ProductOwner. Nach Bedarf werden weitere Interessenvertreter (z.B. Führungskräfte) eingeladen

• Muss gut vorbereitet werden


Sprint-Retrospektive

1. Check-In

2. Daten sammeln

3. Erkenntnisse erlangen

4. Entscheidungen treffen

5. Abschluss


Ablauf

Vorführender


Check-In: Jeder sagt in einem Satz, wie er sich fühlt: Alle Beteiligten werden aktiv eingebunden, der Kontext zum Sprint-Review wird hergestellt. (Bei unerfahrenen Teams: Zielsetzung und Ablauf genau erklären, Regeln vereinbaren. Ehrliche Kommunikation essentiell Daten sammeln: Reflektion über Zusammenarbeit im Team und Anwendung des Prozesses. Hier kommen Moderationstechniken z.B. mit Karten zum Einsatz. Positive und negative Erfahrungen auf Karten, dann kurz vorstellen und an Wand hängen (ggf. beschränken auf 3 pos., 3 neg.). Dann nach Themen gruppieren und das Thema auswählen, dass am dringlichsten angegangen werden muss Erkenntnisse erlangen: Klären wie es zu den aufgefundenen Problemen kommen konnte. Was ist die Ursache des Problems fragen und dann rekursiv auf die Ursachen des Problems (bzw. die Ursachen der Ursachen), bis Klarheit herrscht, warum das Problem aufgetreten ist Entscheidungen treffen: Nachdem die Ursachen geklärt sind, werden Maßnahmen identifiziert, die eine Wiederholung der Probleme ausschließen. Wenige aber konkrete, realistische und überprüfbare Verbesserungsmaßnahmen identifizieren. Diese werden in die nächste Sprint-Planung eingebracht. Abschluss: Metabetrachtung über die Sprint-Retrospektive und Identifikation von Verbesserungsmaßnahmen hierfür. Zu kurz oder zu lang? Welche Techniken hilfreich? Noch ein Hinweis am Ende: Scrum geht auch bei großen Projekten. Ken Schwaber berichtet von einem Projekt über 2,5 Jahre mit 3500 Teilnehmern in dem er als Coach mitgearbeitet hat. Geht mit speziellen Techniken wie Scrum of Scrums usw. Typische Fehler: Selbstzerfleischung, Aussitzen, Schwafeln

CRYSTAL METHODOLOGIES FAMILIE


Crystal Fakten

• Entwickelt von Alistair Cockburn

• Crystal ist eine Familie von Methodiken fürunterschiedliche Projektgrößen und -kritikalitäten

– Jeweils so konkret wie möglich, damit als Template verwendbar– Projektgröße gemessen in benötigten Mitarbeitern– Kritikalität gemessen am resultierenden Verlust, wenn

Anforderungen oder Implementierung fehlerhaft• Unterschiedliches Vorgehen, je nach Kritikalität


A. Cockburn: Agile Software Development – The Cooperative Game, Addison Wesley, 2007A. Cockburn: Crystal Clear: A Human-Powered Methodology for Small Teams, Addison Wesley, 2005

Kritikalitätsstufen in Crystal

• C (Comfort):Nur ein Ärgernis, Beispiel: Ein Fehler in einem Spiel

• D (Discretionary Money):Monetärer Verlust, aber in erträglichem Rahmen, Beispiel: Wegwerfprototyp, Kundenverlust durch Fehler im Servicesystem

• E (Essential Money):Monetärer Verlust mit Gefahr für den Fortbestand des Unternehmens, Beispiel: Substantieller Geldverlust durch Fehler in Finanztransaktionssystem

• L (Life):Menschen können verletzt oder getötet werden, Beispiel: Fahrzeugkontrollsysteme, Medizintechnik, IuK-Systeme im Katastrophenschutz


Varianten von Crystal


Risik

o

Zahl der Personen im Projekt

C

D

E

L

6 20 40 80 100-200 200-500 500-1000

Varianten von Crystal


Risik

o

Zahl der Personen im Projekt

C

D

E

L

6 20 40 80 100-200 200-500 500-1000

Zu Crystal Clear: http://alistair.cockburn.us/Crystal+Clear+distilled

Crystal Clear

Crystal Clear ist ein optimierter Ansatz, ein kleines, an einem Ort arbeitendes Team zu nutzen,• mit Priorität auf sicherer Lieferung eines

zufriedenstellenden Ergebnisses,• Effizienz in der Entwicklung und• mit Arbeitskonventionen, mit denen mal leben kann.


Vorführender


Crystal Clear ist für D6-Projekte, sollteaber für E8 oder D10 angepasst werden können

Crystal Clear

• Chefdesigner und zwei bis sieben weitere Entwickler• … in einem großen Raum oder nebeneinanderliegenden Räumen,• … „Informationsstrahler“ wie Whiteboards oder Flipcharts

nutzend,• … mit problemlosem Zugang zu Expertennutzern,• … ohne Ablenkungen,• … die jeden oder jeden zweiten Monat (schlimmstenfalls 1 mal pro

Quartal), • … lauffähigen, getesteten und benutzbaren Code an die Nutzer

ausliefern,• … und regelmäßig über ihre Arbeit reflektieren und ihre

Arbeitskonventionen entsprechend anpassen.


Die zentralen Bausteine

Projektsicherheit in Crystal Clear

1. Regelmäßige Auslieferung2. Reflektion und Verbesserung3. „Osmotische Kommunikation“4. Sicherheit der Mitarbeiter5. Fokussierung6. Einfacher Zugriff auf Expertennutzer7. Technisches Umfeld mit automatisierten Tests,

Konfigurationsmanagement und regelmäßiger Integration


Zwingend vorgeschrieben

Vorführender


Auch Crystal kann als Einstieg in Richtung XP bzw. als Fallback von XP eingesetzt werden. Crystal legt mehr Wert auf die persönlichen Präferenzen der einzelnen Teammitglieder, XP erreicht etwas höhere Produktivität durch die größere geforderte Disziplin. Crystal einfacher einzuführen, XP liefert bessere Ergebnisse (wenn das Team dem Prozess folgen kann)

INDIKATION UND KONTRAINDIKATION


Kontraindikationen gegen agiles Vorgehen


Beim Kunden• Projektziel nicht SMART• Prozess vorgegeben und reglementiert• Nice-to-have-Projekte• Lange Entscheidungswege• Langwierige Change-Request-Verfahren• Kein Anwenderkontakt möglich• Kundenrolle nicht oder zu knapp besetzt• Erstellung lebenskritischer Software• Angst und organisierte Unverantwortlichkeit• Kunde steht nicht hinter dem Vorgehen• Keine Arbeit vor Ort möglich• Festpreisprojekte• Kunde ist Behörde

Bei den Entwicklern• Keine Erfahrung mit agilem

Vorgehen und kein Coach vorhanden

• Lernunfähigkeit oder –unwillen• Kultur von Befehl und Gehorsam• Entwickler wollen keinen

Anwenderkontakt• Hohe Mitarbeiterfluktuation• Keine Arbeit vor Ort gewünscht• Kein Management-Commitment

auf agile Methoden

Bei den Technologien• Lange Build-Zeiten

Vorführender


Nicht SMART: SMART steht für spezifisch, messbar, angemessen, relevant, terminiert. Gibt es kein solches Ziel, ist es schwirieg agil darauf zu zuarbeiten Prozess vorgegeben: Bei extern festgelegtem Vorgehen (z.B. Behörde) kompletter Umstieg auf agil meist unmöglich. Aber vielleicht in einzelnen Teilen agiles Vorgehen möglich, aber schwierig, da Abstimmung mit externem Prozess nötig. Oft Problem: Erkenntnisse die durch Rückkopplung gewonnen wurden, dürfen nicht berücksichtigt werden, da extern Change-Request nötig Nice-to-have-Projekte: Projekt ohne Druck und Stellenwert bedeuten oft, dass kein ernsthafter Kunde da ist und fachliche Entscheidungen trifft Change-Request: Spezialfall von langen Entscheidungswegen beim Kunden Kein Anwenderkontakt möglich: Anwender für Rückfragen wichtig (sollen schnell, direkt und persönlich erreichbar sein). Fehlt das, wird es sehr schwierig. Bei anonymen Kunden (Webprojekte) hilft vielleicht ein Produktmanager Kundenrolle inadäquat besetzt: Kunde muß erfahrungsgemäß über 50% seiner Arbeitszeit für die Kundenrolle aufbringen. Passiert dies nicht -> Lange Entscheidungswege. Auch schlecht; Kunde hat keine Produktvision oder kann sie nicht vermitteln Lebenskritische Software: Im allgemeinen Beweise der Korrektheit gefordert Angst und organisierte Unverantwortlichkeit: Wenn in einer Organisation niemand bereit ist Verantwortung zu übernehmen, i.a. geppart mit der Angst Fehler zu machen, da sie nicht als Anlass zum lernen gesehen werden, sind schlechte Vorzeichen für agiles Vorgehen: Übernahme von Verantwortung muss in agilen Projekten vom Kunden bis zu den einzelnen Entwicklern gewährleistet sein. Fehler machen ist erlaubt, wenn man daraus lernt Kunde steht nicht dahinter: Kundenunterstützung ist unerlässlich, weil er sonst die Kundenrolle nicht adäquat ausfüllen wird und ihm wahrscheinlich nicht klar ist, welche Entscheidungen und Rückkopplungen er zur Projektlaufzeit zu leisten hat Keine Arbeit vor Ort möglich: Ohne Arbeit beim Kunden vor Ort fehtl eun wesentlicher Kanal schneller Rückkopplung. Vielleicht Alternative Kunde vor Ort bei den Entwicklern. Ist aber selten und schwierig Festpreisprojekte: Projekt mit festem Preis und festem Lieferumfang verhindert es, von agilen Methodiken und neuen Erkenntnissen zu profitieren. Aber einige Praktiken kann man vielleicht trotzdem anwenden. Speziell für Festpreisprojekte: Feature-Driven Development Kunde ist Behörde: In Normalfall lange Entscheidungswege, Festpreis, vorgegebener Prozess Lernunfähigkeit/-unwilligkeit: Agil Vorgehen heißt im Kern, Softwareentwicklung als Lernprozess zu aufzufassen und das jeweils unterwegs Gelernte so schnell wie möglich in den weiteren Projektverlauf einzubringen Kultur von Befehl und Gehorsam: Strikt hierarchisches Umfeld und Befehl/Kontrolle-Kultur mit agilen Methoden nur schwer vereinbar Hohe Mitarbeiterfluktuation: Behindert die Arbeit des Teams Kein Management-Commitment: Agile Teams brauchen Rückendeckung!

Indikationen für agiles Vorgehen


Beim Kunden• Start-Ups• Innovative Projekte• Neue Anwendungsbereiche• Schnelle Auslieferung notwendig (Time-to-

Market)• Nutzenorientierte (statt kostenorientierte)

Perspektive des Kunden

Bei den Entwicklern• Neugierige Entwickler• Arbeit beim Kunden sowieso

gegeben• Konkrete Probleme im Team

bekannt

Bei den Werkzeugen• Inkrementelle Compiler• Interpretierte Skriptsprachen• Refactoring-Tools im Einsatz• Test-Frameworks bekannt oder im Einsatz

Vorführender


Start-Ups brauchen typischerweise Agilität, da schnelle Ergebnisse und Flexibilität gefragt sind Innovative Projekte: Brauchen meist auch Zeit zum Lernen, daher agiles Vorgehen passend. Mit kleinen Zyklen und häufigen und intensiven Rückkopplungen lassen sich innovative Lösungen erkennen. Außerdem haben solche Projekte oft hohes Engagement und commitment der Beteiligten: Passt auch gut zu agil Neue Anwendungsbereiche: Ähnlich wie innovative Projekte: Erkenntnis durch Lernen wichtig Schnelle Auslieferung: Passt gut, da agile Methoden früh und häufig neue Releases produzieren, die vielleicht noch nicht alles können, aber haben Produktivqualität und man hat einen Fuss in der Tür Nutzenorientierte Sicht des Kunden: Agiles Vorgehen bietet dem Kunden den besten Weg, den maximalen Nutzen aus dem Projekt zu erzielen

BEWERTUNG


Wo stehen/Was können die agilen Methoden?


Für kleine Teams einsetzbar

Werden immer stärker akzeptiert Nicht für hochkritische

Systeme

Oft höhere Mitarbeiterzufriedenheit

Bauen auf Annahme einer flachen Kostenkurve

Viele unterschiedliche Methodiken: Geeignete

Auswahl für Projekt und Team

Risiko, das Falsche zu bauen wird reduziert

Durch Praxiswissen getrieben

Nur mit willigen Kunden

Auch kein silver-bullet

Agil heißt nicht undiszipliniert

Adaptiv statt prädiktiv

Hohe Anforderungen an Mitarbeiter

Literaturtipps

• Agile Softwareentwicklung bei Wikipedia: http://de.wikipedia.org/wiki/Agile_Softwareentwicklung

• W.-G. Bleek, H. Wolf: Agile Softwareentwicklung; dpunkt.verlag; 2008

• C. Dogs, T. Klimmer: Agile Software-Entwicklung kompakt; mitp-Verlag; 2005

• H. Wolf, S. Roock, M. Lippert: eXtreme Programming; dpunkt.verlag; 2005

• K. Beck: eXtreme Programming Explained (2. Auflage); Addison-Wesley; 2004

• R. Pichler: Scrum; dpunkt.verlag; 2008• M. Beedle, K. Schwaber: Agile Software Development with Scrum;

Prentice Hall; 2002• A. Cockburn: Agile Software Development; Addison-Wesley; 2007


Trends im Software Engineering – WS0910 · 2017. 1. 10. · • Warum agil? • Agile Methoden...

Documents

Transcript of Trends im Software Engineering – WS0910 · 2017. 1. 10. · • Warum agil? • Agile Methoden...