1 TIT10AIK @ WS 2012
Software-Engineering II
Vorgehensmodelle
2 TIT10AIK @ WS 2012
Themenübersicht» Objektorientierung» Aspektorientierung» Vorgehensmodelle» UML» Analyse- & Entwurfsmuster» Objektorientiertes Testen» Versionsverwaltung» Refactoring» Labor (Praktischer Teil)
3 TIT10AIK @ WS 2012
VorgehensmmodelleErfolgreich mit Objektorientierung
B. OestreichOldenbourg
390 Seiten
ISBN: 3-4862-5565-7 (Deutsch)
4 TIT10AIK @ WS 2012
Agile EntwicklungAgile Software-Entwicklung kompakt
Carsten Dogs, Timo Klimmer
254 Seiten
ISBN: 3-8266-1503-4 (Deutsch)
5 TIT10AIK @ WS 2012
ScrumScrum. Produkte zuverlässig und schnell entwickeln
Boris Gloger
392 Seiten
ISBN: 3-4464-1495-9 (Deutsch)
6 TIT10AIK @ WS 2012
Test-Driven Development
Test-Driven Development
Kent Beck
240 Seiten
ISBN: 0-321-1465-30 (Englisch)
7 TIT10AIK @ WS 2012
Vorgehensmmodelle
» Untersuchung der Standish Group International Inc. 1995
8 TIT10AIK @ WS 2012
Vorgehensmodelle
» Software-Entwicklung ist komplex» Gründe für fehlgeschlagene Projekte
» Unvollständige, ungenaue Anforderungen» Mangelnde Einbeziehung von Beteiligten» Ressourcenmangel» Unrealistische Erwartungen» Mangelnde Unterstützung des Managements» Sich häufig ändernde Anforderungen» Mangelhafte Planung» Veraltung des Konzeptes - Wird nicht mehr benötigt» ...
» Vorgehensmodelle» Komplexität entfernen» Ansätze, die Entwicklung organisiert zu strukturieren» Messbarkeit des Fortschrittes
9 TIT10AIK @ WS 2012
Phasen
» Entwicklung wird in Phasen aufgeteilt» Planung» Analyse» Entwurf» Implementierung» Test» Einsatz/Wartung}Haben die meisten
Vorgehensmodelle gemeinsam
10 TIT10AIK @ WS 2012
Phasen: Planung
» Erstellung eines Lastenhefts» Projektplanung» Projektkalkulation» Spezifikation in der (natürlichen) Sprache des Anwenders
11 TIT10AIK @ WS 2012
Phasen: Analyse
» Erstellung eines Pflichenhefts» Spezifikation der Anforderungen in der Sprache der Informatik
» Modellierung mit hohem Abstraktionsniveau» Zur Kommunikation mit Vorgesetzten und Projektpartnern
» Als Grundlage für spätere Phasen
12 TIT10AIK @ WS 2012
Phasen: Entwurf
» Detaillierte Modellierung der technischen Architektur» Als Implementierungsgrundlage» Auf Basis der bisher entstandenen Modelle
13 TIT10AIK @ WS 2012
Phasen: Implementierung
» Implementierung der Software» Anhand der in den in den vorhergehenden Phasen entstandenen Modelle
» Hier entsteht der Programmcode» Physische Repräsentation der Lösung
14 TIT10AIK @ WS 2012
Phasen: Test
» Testen des entstandenen Produktes anhand der Programm-Spezifikationen» Manuelle Tests» Automatisierte Tests
» Eventuell: Test-Modell, welches die Anwendungsfälle um Testfälle erweitert
15 TIT10AIK @ WS 2012
Phasen: Einsatz/Wartung
» Auslieferung des fertigen Produktes zum Kunden
» Instandhaltung der Software
16 TIT10AIK @ WS 2012
Modellarten
» Prozessmodelle können in verschiedene Kategorien eingeordnet werden» Linear» Nichtlinear
»Iterativ»Evolutionär»Inkrementell»Nebenläufig
17 TIT10AIK @ WS 2012
Lineare Prozessmodelle
» In jeder Phase wird exakt die eine Aufgabe erledigt» Nachfolgende Prozessphasen beginnen erst wenn vorhergehende Phasen abgeschlossen sind
Analyse Design Coding Testing
18 TIT10AIK @ WS 2012
Nichtlineare Prozessmodelle
» Zu Beginn des Projektes sind die Anforderungen » Unvollständig» Können sich deutlich ändern
» Annahme: Es ist nicht möglich, eine Phase komplett abzuschließen bevor eine Neue beginnt
19 TIT10AIK @ WS 2012
Iterativ
» Software wird in Iterationen erstellt» Jede Iteration durchläuft eine, mehrere oder
alle Phasen: Analyse, Entwurf, Implementierung, Test, Integration
» Dabei existiert nach jeder Iteration ein funktionsfähiges Programm
Analyse Design Coding Testing
Iterationen
20 TIT10AIK @ WS 2012
Evolutionär
» Iteratives Prozessmodell, bei dem in jeder Iteration alle Phasen durchlaufen werden
» Dadurch werden auch die ursprünglichen Ziele wieder angepasst
Analyse Design Coding Testing
Iterationen
21 TIT10AIK @ WS 2012
Inkrementell
» Alle Iterationen bauen auf den Ergebnissen der früheren Iterationen auf
» Iterationen können unterschiedliche Schwerpunkte besitzen
Analyse Design Coding Testing
Analyse Design Coding Testing
...
22 TIT10AIK @ WS 2012
Nebenläufig
» Es wird an mehreren Phasen gleichzeitig gearbeitet
Analyse
Design
Coding
Testing
Einsatz
23 TIT10AIK @ WS 2012
Wahl des Modells
» Es gibt keinen idealen Prozess für alle Problemfälle
» Jede Vorgehensweise besitzt ihre Vor- und Nachteile» Es ist wichtig, diese zu kennen
» Nach der Entscheidung für ein Modell ist es notwendig, es an die Gegebenheiten des Projekts anzupassen („Tayloring“)
24 TIT10AIK @ WS 2012
Konkrete Modelle
25 TIT10AIK @ WS 2012
Kein Prozess
» In vielen Projekten wird kein explizites Vorgehensmodell angewandt» Anforderungen an das System wurden mehr oder weniger geklärt» Programmierung und Testen in einem Zyklus so lange bis die
Software einen akzeptablen Stand erreicht hat» Vorteile:
» Kein Prozessoverhead, da keine Zeit für Design, Dokumentation, Standardisierung verbraucht wurde
» Keine Vorkenntnisse notwendig» Nachteile:
» Meist kein Profit durch die Verwendung objektorientierten Designs» Klassen entstehen bei der tatsächlichen Codierung» Schlecht erweiter- und wartbare Systeme
» Geringe Möglichkeiten der Projektsteuerung (Risikomanagement, Messung des Fortschrittes)
» Fazit:» Ausschließlich bei „Wegwerfprototypen“ und „Proof-Of-Concept“-
Implementierungen geeignet
26 TIT10AIK @ WS 2012
Wasserfallmodell
Analyse
Design
Implementierung
Test
Am Ende jeder Phase wird durch ein Review entschieden, ob die Ziele der Phase erreicht wurden
Erst wenn eine Phase erfolgreich abgeschlossen ist, kann der Übergang zur nächsten erfolgen
Lineares Modell
Lineares Modell
27 TIT10AIK @ WS 2012
Erweitertes Wasserfallmodell
Analyse
Design
Implementierung
Test
Zurückkehren in eine frühere Phase bei zu spät erkannten Fehlern möglich
28 TIT10AIK @ WS 2012
Wasserfallmodell
» Vorteile:» Aufgaben aller Phasen klar umrissen» Geringer Prozess-Overhead» Projektplanung sinnvoll einsetzbar
» Nachteile:» Zurückkehren in frühere Phasen ist aufwendig» Später Beginn der Implementierung
» Verzögertes Erkennen von Problemen» Modell „scheitert“ bei verspäteten Änderungsanforderungen
» Fazit:» Gut geeignet für Projekte mit stabilem Projektumfeld
29 TIT10AIK @ WS 2012
Spiralmodell
30 TIT10AIK @ WS 2012
Bewertung Spiral-Modell
» Nichtlinear, Iterativ-Inkrementell» Weiterentwicklung von Wasserfall» Risikobetrachtung in jeder Iteration» Vorteile
» Flexibles Modell» Risiken werden frühzeitig eliminiert» Scheitern des Projektes früher erkennbar
» Nachteile» Hoher Managementaufwand» Risikien oft nicht einfach abschätzbar (zu geringes Wissen)
31 TIT10AIK @ WS 2012
Rational Unified Process» Vorgehensmodell & UML-Software von IBM» Nichtlinear, Iterativ-Inkrementell» Nebenläufig» Iterationen werden in Phasen aufgeteilt
Kurven stehen für Intensität in den Phasen.
RUP verwendet stark UML für Planung.
Model Driven Development.
32 TIT10AIK @ WS 2012
Inception
» Deutsch: „Beginn“» Definition des Projektes» Prüfung der Wirtschaftlichkeit» Machbarkeitsstudien» Häufig 1 Iteration
33 TIT10AIK @ WS 2012
Elaboration
» Deutsch: „Ausarbeitung“» Anforderungsanalyse» Analysemodell» Design einer stabilen Software-Architektur» Durchaus mehrere Iterationen bei größeren Projekten
34 TIT10AIK @ WS 2012
Construction
» Deutsch: „Errichtung“» Funktionsumfang des Produktes wird evolutionär entwickelt
» Ende der Phase:» Fertiges Produkt, das ausgeliefert werden kann
35 TIT10AIK @ WS 2012
Transition
» Deutsch: „Übergang“» Übergabe der Software an den Anwender» Schulung des Support-Personals
36 TIT10AIK @ WS 2012
Iterationen
» Jede Phase besteht aus 1 oder mehreren Iterationen
» Anzahl und Dauer hängt von der Größe und Komplexität des Projekts ab
» Mittleres Projekt: 2-3 Monate pro Iteration
» Jede Iteration endet mit einem ausführbaren Produkt
» Schwerpunkte der Iterationen sind unterschiedlich
» Das Testen verteilt sich gleichmäßig auf die gesamte Projektlaufzeit
37 TIT10AIK @ WS 2012
Bewertung RUP» positiv:
» Hoher Abstraktionsgrad durch Modellierung
» Risikomanagement: Weil in jeder Iteration alle Phasen durchlaufen werden ist es möglich, früh Probleme in einer Phase zu erkennen
» Da kontinuierlich getestet wird, wird die Arbeitsauslastung des Test-Teams gleichmäßiger
» Negativ:» Projektaufwand häufig unterschätzt: tatsächliche Entwicklung ist oft doch komplexer
» Bei großen Projekten erheblicher Initialaufwand
38 TIT10AIK @ WS 2012
Agile Entwicklung
» Anforderungen an Software ändern sich kontinuierlich
» Agile Entwicklung versucht dies zu akzeptieren
» Definiert» Vier Werte» Zwölf Prinzipien» Praktiken» Methodiken
39 TIT10AIK @ WS 2012
Die agilen Werte
» Sollen helfen flexibler gegenüber Änderungen an den Anforderungen zu sein1. Individuen und Interaktionen
2. Funktionierende Software
3. Zusammenarbeit mit dem Kunden
4. Auf unbekannte Änderungen einstellen
40 TIT10AIK @ WS 2012
1. Individuen und Interaktionen
„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“
» Oft sind Prozesse und Werkzeuge im Vordergrund» Mensch wird als austauschbare Ressource gesehen» Fehleranalyse im Quellcode» Mitarbeiter werden unmotiviert
» Werkzeuge geben eine nötige Struktur» Aber: Mitarbeiter und deren Zusammenarbeit
sind wichtiger als Werkzeuge» Mitarbeiter werden als Experten in ihrem Fach
und ihrer Selbstorganisation betrachtet» Mitarbeiter können frei arbeiten, so wenige
Prozesse wie möglich werden vorgegeben
41 TIT10AIK @ WS 2012
„Funktionierende Software ist wichtiger als umfassende Dokumentation.“
» Nur funktionierende Software hat einen reellen Wert» Theoretische Modelle gewinnen erst an Wert, wenn sie in
der Praxis sinnvoll verwendet werden» Im Vorfeld keine übertriebenen Design-Dokumente
erstellen ohne die Praxis zu kennen» Begründung:
» Dokumente veralten wenn die Software sich verändert» Oft ist in der Praxis keine Zeit für die Anpassung aller
Dokumente» Dokumente die nicht auf dem aktuellsten Stand sind, sind oft
wertlos oder irreführend» Das Notwendigste dokumentieren» Gedankengänge statt Tatsachen darstellen
» Nicht welche Alternative gewählt wurde und wie sie funktioniert, sondern warum
2. Funktionierende Software
42 TIT10AIK @ WS 2012
„Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.“
» Bei Vertragsabschluss sind selten alle Anforderungen klar
» Der Kunde bemerkt während des Projekts, was er haben möchte
» Verträge sind oft mehrdeutig definiert» Ausgeprägte Zusammenarbeit mit dem Kunden
unumgänglich» Entwickler und Kunden sollten aufeinander
zugehen, die beste Lösung suchen anstatt auf Vertragsklauseln zu beharren
3.Zusammenarbeit mit dem Kunden
43 TIT10AIK @ WS 2012
„Sich auf unbekannte Änderungen einzustellen ist wichtiger als einem Plan zu folgen.“
» Prädiktive Vorgehensweise» (Wasserfall, ...)» Vollständigen Plan ausarbeiten» Ausgefeilte Ausweichpläne für spezielle Problemfälle entwerfen
» Adaptive Vorgehensweise» (Agile Entwicklung, ...)» Keine Annahmen treffen» Vorkehrungen treffen, damit Anpassungen leichter gemacht werden können
» Abweichungen gehören zum Plan
4. Auf unbekannte Änderungen einstellen
44 TIT10AIK @ WS 2012
Die Agilen Prinzipien
» Definieren Strategien zur Einhaltung der Agilen Werte
1. Höchste Priorität: Bedürfnisse des Kunden2. Begrüße sich ändernde Anforderungen3. Häufige Auslieferungen der Software an den Kunden4. Enge Zusammenarbeit zwischen Kunden und Entwickler5. Mitarbeiter: Motivation und Vertrauen6. Bester Informationsaustausch: Direkte Kommunikation7. Funktionierende Software als Maßstab für Fortschritt8. Reguläre Arbeitszeiten, gleichbleibende Geschwindigkeit9. Wert auf gute Qualität und ein gutes Design legen10. Einfachere Lösungen sind bessere11. Sich selbst organisierende Teams12. Regelmäßige Selbstreflektion
45 TIT10AIK @ WS 2012
Agile Praktiken
» Aktivitäten, die dabei helfen, die Prinzipien der Agilen Entwicklung umzusetzen
» Es gibt eine Vielzahl von Praktiken» Beispiele
» Tägliche Stand-Up-Meetings» Planning Poker» Pair Programming» Refactoring» Unit Tests» Test-Driven Development
46 TIT10AIK @ WS 2012
Planning Poker» Spiel um realistische
Aufwandsabschätzungen für Features zu erhalten
» Alle Teammitglieder spielen mit
» Die Spieler decken zur gleichen Zeit die Karte mit ihrer Abschätzung auf
» Bei großen Unterschieden erläutern die jeweiligen Spieler ihre Ansichten
» Nach einer Diskussion werden die Karten erneut zur Schätzung verwendet
» Dies wird so lange gemacht, bis sich die Spieler einig sind
» Eine Sanduhr limitiert Diskussionen auf 2 Minuten
Echte Planning Poker SpielkartenJeder Spieler erhält einen kompletten Satz Karten
Online-Version:www.planningpoker.com
47 TIT10AIK @ WS 2012
Pair Programming
» Zwei Entwickler sitzen an einem Rechner und schreiben gemeinsam Quellcode
» Ein Entwickler hat die Tastatur und tippt Code ein, der andere denkt über die nächsten Schritte nach
» Oft werden auch zwei Tastaturen angeschlossen» Die Rollen werden in kurzen Abständen
gewechselt» Pair Programming Partner werden regelmäßig
gewechselt» So erfolgt ein gleichmäßiger Wissensaustausch
im Team» Die Qualität der Software ist meist
wesentlich besser
48 TIT10AIK @ WS 2012
Test-Driven Development1. Der Test-Code wird anhand der Spezifikation
geschrieben2. Test-Code compilieren (Nicht kompilierbar, da die
Implementierung fehlt)3. Gerade so viel Quellcode implementieren, dass die
Tests compilieren aber fehlschlagen4. Genau so viel Code entwickeln, dass die Tests
erfolgreich sind5. Duplikaten Code und unschöne Stellen refactoren6. Wieder bei 1. beginnen» Folge:
» Sehr gute Testabdeckung der Software» Sicherstellung, dass die Software so funktioniert,
wie sie spezifiziert war» Vermeidet, dass „zu viel“ entwickelt wird
49 TIT10AIK @ WS 2012
Agile Methodiken
» Kombination von Agilen Praktiken in ein Schema
» Eine Methodik ist agil, wenn sie folgende Eigenschaften besitzt» Inkrementell» Kooperativ
» Erfordert das Mitspielen aller Mitarbeiter» Erfordert das Mitspielen des Auftraggebers
» Unkompliziert» Leicht erlernbar
» Adaptiv » Auch im letzten Moment sind noch große Änderungen am Produkt möglich
50 TIT10AIK @ WS 2012
Methodik: eXtreme Programming
» Nichtlin., Inkrementell-Iterativ (Da agil!)» Praktiken rund um die Programmierung und die
Einbindung der Kunden» Pair Programming» Planning Poker» Test-Driven Development» Kunde vor Ort» 40-Stunden-Woche
» Einsatzgebiete» Für kleine Teams (< 10 Entwickler)» Guter Informationsaustausch muss vorhanden sein» Erfordert hochqualifizierte Mitarbeiter» Mitarbeiter müssen die selbe Vision verfolgen
51 TIT10AIK @ WS 2012
PhasenExploration
Planung Entwicklung
Freigabe
Wartung Ende
Iterationen
52 TIT10AIK @ WS 2012
Exploration
» Einweisung des Kunden in eXtreme Programming
» Mit den Werkzeugen vertraut machen
» Verschiedene Ansätze probieren» Dauer: 2 Wochen bis 2 Monate
53 TIT10AIK @ WS 2012
Planung
» Kunde und Entwickler spielen das Planning Game
» Legen fest, welche Features im nächsten Release sind
» Legen fest, wann die Features implementiert werden
» Dauer: 1-2 Tage
54 TIT10AIK @ WS 2012
Entwicklungsphase
» Zu Beginn» Grobes Design festlegen
» Entwicklung» Pair Programming» Test-Driven Development» Erfahrungen fürs nächste Planning Poker sammeln» Rückfragen persönlich mit Entwicklern oder mit dem
Kunden vor Ort klären» Am Ende
» Prüfung, ob der Kunde mit den Entwicklungen zufrieden ist
» Falls ja, wechsel in die Freigabephase» Falls nein, Change Requests für das nächste Planning
Game» Dauer: 1-4 Wochen» Ca. 8-10 Iterationen
55 TIT10AIK @ WS 2012
Freigabephase
» Software wird in den Echtbetrieb übernommen
» Kunde prüft letztes Mal Software auf Mängel
» Letzte Performanceoptimierungen» Freischaltung des Systems
56 TIT10AIK @ WS 2012
Wartungsphase
» Spät entdeckte Fehler werden behoben» Neue Anforderungen werden implementiert
» Vorgehensweise ist die selbe wie in der Entwicklungsphase
» Erschwerte Bedingungen, da die Software bereits produktiv eingesetzt wird
» Sind größere Weiterentwicklungen gewünscht, kann wieder in die Planungsphase gewechselt werden
57 TIT10AIK @ WS 2012
Endphase
» Kunde hat keine Wünsche mehr» 10- bis 15-seitige Dokumentation » Funktionen der Software» Funktionsweise des Quellcode» Ermöglicht nachkommenden Entwicklern die Einarbeitung in das System
58 TIT10AIK @ WS 2012
Methodik: Scrum» Nichtlin., Inkrementell-Iterativ (Agil!)» Mehr als eine Methodik oder ein Prozessmodell» Mittel zur Projektsteuerung» Nicht notwendigerweise nur für die IT
» Ideal: Bis zu 10 Teammitglieder» Experten in ihrem Bereich» Sehr selbstorganisiert» Gemischte Teams (Entwickler, Designer, DB-Experten, IT-Operations, ...)
» Bietet hohe Transparenz» Deckt Schwächen in der Team- und Management-Zusammenarbeit auf
59 TIT10AIK @ WS 2012
Product Owner, Backlog
» Hat die Idee für das Projekt» Überarbeitet die Idee und
formuliert sie als „Product Vision“
» Erarbeitet die Liste der Produkt-Funktionalitäten » „Product Backlog Items“» Alleine oder zusammen mit dem Team
» Aus dieser Liste wird das Product Backlog erstellt
» Die Punkte auf dieser Liste werden sortiert nach dem zu erwartenden Gewinn/Nutzen
Vision!Vision!
Backlog
ProductOwnerProductOwner
60 TIT10AIK @ WS 2012
Zeitschätzung, Scrum-Team
» Scrum-Team» Personen, die notwendig sind, Backlog Items in „usable software“ zu verwandeln» Programmierer» Designer» Datenbanken-Spezialisten
» Schätzt den Aufwand für jedes Backlog-Item
» Die Schätzung wird dem Product Owner mitgeteilt
» Dadurch weiß der Product Owner, welche Kosten ihn erwarten
» Alle Beteiligten im Prozess wissen über die geplanten Features Bescheid
Scrum-Team
Backlog
61 TIT10AIK @ WS 2012
Iterationen: der Sprint» Iterationen
» Werden „Sprints“ genannt» Zeitlich klar abgegrenzt» Dauer: 2-4 Wochen» Nach jeder Iteration entsteht eine Version, die funktionsfähig ist „usable code“
62 TIT10AIK @ WS 2012
Sprint Planning Meeting 1» Wie viele und welche Backlog Items werden entwickelt?
» Instruktionen geben und Ziele für alle klar setzen
» Heraus kommt das Selected Product Backlog: Elemente, die tatsächlich entwickelt werden
ProductOwnerProductOwner
AnwenderAnwender
ManagementManagement
Das TeamDas Team
Die TeilnehmerDie Teilnehmer
Sprint Plannin
g Meetin
g I
63 TIT10AIK @ WS 2012
Sprint Planning Meeting 2» Das Team bespricht, wie die Elemente des Selected Product Backlog umgesetzt werden können
» Besprechung des Software-Design und der Architektur
» Ausarbeitung der Backlog Items»Es entsteht das Sprint Backlog»Liste aller Aufgaben, die erledigt werden müssen um die einzelnen Backlog Items zu erfüllen
Sprint Plannin
g Meetin
g II
64 TIT10AIK @ WS 2012
Daily Scrum
» Teammitglieder stimmen täglich die Aufgaben untereinander ab
» Diskussionspunkte» Erreichtes seit dem letzten Daily Scrum» Ziele bis zum nächsten Daily Scrum» Welche Hindernisse waren mir im Weg?
» Die Teammitglieder suchen selbst aus, welche Sprint Backlog Items sie abarbeiten wollen
» Oft werden diese Meetings im Stehen gehalten, um die Mitarbeiter zu zwingen, die Dauer zu begrenzen» „Stand-up Meeting“
DailyScrum11.45
–12.00
65 TIT10AIK @ WS 2012
Sprint Review
» Nach Ende des Sprints» Demo
» Fertiggestellte Funktionalität wird anhand von „usable software“ vorgestellt» Führt zu neuen Ideen
» Retrospektive:» Optimierung der eigenen Arbeitsprozesse» Kontinuiertliches Hinterfragen der Vorgehensweise» Ermöglicht das Lernen aus Fehlern
SprintReview
66 TIT10AIK @ WS 2012
Burndown-Chart» Daily Scrum Meeting
» Jeder Mitarbeiter berichtet den aktuellen Fortschritt
» Verbleibender Aufwand des Backlog Items = Entwicklungszeit in Stunden
» Verbleibender Aufwand für den Abschluss des Sprints = Summe der Aufwände aller Backlog Items
» Kann auch für das komplette Product Backlog angewendet werden
Task Remaining Effort (h)
Optimize Login 10
Add new language 4
Create new Images 4
Implement new Images 2
Overall 20
67 TIT10AIK @ WS 2012
Burndown-Chart
» Nach jedem Daily Scrum Meeting wird der verbleibende Aufwand in ein Diagramm aufgetragen
» Verbindet man den ursprünglichen Aufwand mit dem aktuellen Aufwand zu einer Geraden, ergibt der Wert der Geraden am Tag des Sprint-Endes den voraussichtlichen Sprint-Abschluss
» Scrum macht Probleme frühzeitig deutlich
» Die Kurve kann ansteigen, wenn erkannt wird, dass Entwicklungen länger dauern werden als geplant
5 Stundendefizit