Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

Präsentation zum Thema: "Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM"—  Präsentation transkript:

1 Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM
Patrick Spieler, Nicolas Müggler Glattbrugg, August 2008

2 Agenda Klassische vs. agile Projekte Umsetzung des agilen Vorgehens
Ausblick Data are always part of the game. In der Session wird die Theorie und Umsetzung einer agilen Entwicklungsmethode mit Hilfe von VSTS aufgezeigt. Zu Beginn wird der grundsätzliche Unterschied zwischen klassischen und agilen Projekten anhand einer einfachen Metapher aufgezeigt und erläutert. Danach zeigen wir die Umsetzung der agilen Vorgehens mit Hilfe von Tools und Team Systems konkret auf. Die Session wird mit einem Ausblick auf Rosario abgeschlossen, die nächste Version von Team System, welche weitere Unterstützungen, unter anderem in den Bereichen Requirements und Testing, bringen wird. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

3 Klassische vs. Agile Vorgehensmethode
Crescendo Vertragsmodell und Controlling Klassische vs. Agile Vorgehensmethode Zwei unterschiedliche Arten, wie die Realisierung eines Projektes durchgeführt werden kann. Die Aufgaben des Projektmanagements bleiben jedoch grundsätzlich gleich: „Projektmanagement ist die Gesamtheit von Führungsaufgaben, - organisation, -techniken und -mitteln für die Abwicklung eines Projektes“ (DIN 69901) Project Management Institute (PMI): “Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements”. Gesellschaft für Informatik: „Das Projekt führen, koordinieren, steuern und kontrollieren.“ Steuerung Was genau Projektmanagement ist, wird unterschiedlich definiert: DIN-Norm (DIN 69901): „Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes“. Project Management Institute (PMI): “Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements”. Gesellschaft für Informatik: „Das Projekt führen, koordinieren, steuern und kontrollieren.“ Projektum (Latein): das nach vorne Geworfene Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

4 Projekt-Planung - Vorgehensmethodik
Ziele Einheitliches Vorgehen Transparenz für die Entscheidenden und das Projektteam Klare Meilensteine („Etappen“) Unterstützung der Projektleitung bei der Planung und Steuerung Überblick bewahren trotz Detailarbeit Grundsätze der meisten Methoden dieselben Top-down (vom Groben zum Detail) Phasenweises Vorgehen Trennung von Planung, Realisierung und Einführung Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

5 Klassische Vorgehensmethode
Crescendo Vertragsmodell und Controlling Klassische Vorgehensmethode Anforderungs- definition Projektleiter System- und Softwareentwurf Kunde Realisation und Komponententest Integration und Systemtest Entwicklungs-Team Ausgehend von den Anforderungen wird ein Plan zur Umsetzung des Problems erstellt:  Klassische Sicht des Entwicklers (Lieferant) Betrieb und Wartung Tester Mögliches Phasenkonzept Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

6 Klassische Zielerreichungsstrategie
Ausgangslage: Reise von Zürich  Lugano Vorgehen: 1. Route festlegen  San Gottardo 2. Gesamte Reiseplanung erstellen Strecke: 204 km Fahrzeit: 2h 30 min 3. Losfahren Routenänderung  San Bernardino Geänderte Reiseplanung (gesamt) Strecke: 311 km Fahrzeit: 6h 30 min 4. Vor Wassen:  Stau, da Gotthard gesperrt (Unfall!) a) im Stau warten b) St. Gotthard umfahren Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

7 Application Life Cycle (klassisch)
Business Analyse Anforderungs- Analyse Design Realisation Test Betrieb Wartung Werkvertrag SLA Business Case Kosten/Nutzen Time to Market Organisation Requirements Specification Functional Non-Functional Application Operation Vorgabe   Werk Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

8 Charakter der klassischen Vorgehensmethoden
Grundprinzip ist das sequenzielle Vorgehen Grundlage für die Realisation ist die vollständige Beschreibung des zu erstellenden Werks (=Software) vollständig  alle Anforderungen definiert und fix zu erstellende  vor der Realisation bekannt  tue alles auf Anhieb richtig!  formal streng geführt (prozessorientiert)  Abweichungen vom Plan sind „unbeliebte“ Änderungen Negative Einstellung zu Veränderungen Es entsteht ein Werk gemäss Anforderungsspezifikation! Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

9 Agile Vorgehensmethode (Beispiel Scrum)
do not disturb! rot = Rollen / Aufteilung Daily Scrum Meeting blau = Ceremonies grün = Artefakte 24 h ScrumMaster update Sprint Backlog 30 days Demonstrate & Verify new Functionality Sprint Planning Meeting Product Owner Burn Down Chart Tasks expanded by the Team Sprint Review Sprint Retro- spective Project Team Product Backlog (priorized) n-Sprints Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

10 Agile Zielerreichungsstrategie
Ausgangslage: Reise von Zürich  Lugano Vorgehen: 1. Etappe „A“ festlegen  Wollerau 2. Reiseplanung für Etappe „A“ erstellen Strecke: 30 km Fahrzeit: 20 min Etappe „A“ losfahren Etappe „B“ festlegen  San Bernardino Reiseplanung für Etappe „B“ erstellen Strecke: 237 km Fahrzeit: 2h 50 min Bei Wollerau:  Situation analysieren, Staumeldung im Radio  Gotthard gesperrt (Unfall!) Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

11 Application Life Cycle (agil)
Business Analyse Agile Vorgehensmethoden Betrieb Wartung Zusammenarbeitsvertrag SLA Business Case Kosten/Nutzen Time to Market Organisation Requirements Specification Functional Non-Functional Application Operation Vorgabe   Nutzen Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 11

12 Charakter der agilen Vorgehensmethoden
Grundprinzip ist das iterative Vorgehen Grundlage für die Realisation ist die nutzenoptimierte Erstellung eines Werks (=Software) in überschaubaren Planungszyklen nutzenoptimiert  alle für den Kundenutzen wichtigen Anforderungen überschaubar  kurz, transparent, steuerbar, effizient  tue, was du verstehst!  durch Ereignisse geführt (lösungsorientiert)  Abweichungen vom Plan sind „geplante“ Änderungen positive Einstellung zu Veränderungen Es entsteht ein Nutzen gemäss Business Case! Pro Agile Die Anforderungen an ein System lassen sich bei Projektbeginn oft nicht zuverlässig festlegen, weil ... ein SW-Entwicklungsprojekt ein ständiger Lernprozess über das Business des Anwenders ist sich die Anforderungen an das Business schnell ändern Praxiserfahrung: In den meisten Fällen entspricht das Endergebnis nicht den ursprünglichen Vorgaben Agile Softwareentwicklung ... … hat eine Roadmap mit Rahmenschätzung ... ist spezialisiert auf Anforderungsänderungen ... führt zu massgeschneiderten, greifbaren Lösungen ... fördert das Vertrauen durch frühe Ergebnisse … und transparentes Reporting Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

13 Agenda Klassische vs. agile Projekte Umsetzung des agilen Vorgehens
Ausblick Data are always part of the game. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

14 Umsetzung des agilen Vorgehens
Die nachfolgend vorgestellte Umsetzung ist eine Erweiterungen und Konkretisierungen auf Basis des agilen Vorgehens SCRUM Diese legt dabei speziellen Wert auf folgende Werte: Zielorientierung Agilität Messbarkeit Planbarkeit Zielorientierung Das oberste Ziel agiler Vorgehensmodelle ist es, auf dem direktesten Weg lauffähige, robuste und bedürfnisgerechte Software zu erstellen. Dieser Grundsatz gilt auch für Crescendo. So wird beispielsweise die Strategie verfolgt, von der ersten Iteration an ein funktionierendes Release auf der Zielumgebung verfügbar zu machen. Dies erlaubt eine Prüfung und Stellungnahme durch den Kunden und stellt sicher, dass technische und organisatorische Probleme frühzeitig zum Vorschein kommen. Des Weiteren wird bei Crescendo darauf geachtet, dass sich die Lösung stets am Kundennutzen orientiert. Auf diese Weise wird vermieden, dass Zeit für die Realisierung unwichtiger Funktionalität verschwendet wird. Agilität Der Kunde soll während des Projektes die Möglichkeit haben, ohne einen aufwändigen, formalen Prozess bestehende Anforderungen zu ändern oder neue Anforderungen einzubringen. Dieser Anspruch wird von jedem agilen Vorgehensmodell erfüllt. In den letzten Jahren haben sich einige agile Vorgehensmodelle besonders gut etablieren können. Eines davon ist Scrum, eine Methode, die in den Neunzigerjahren von Ken Schwaber, Jeff Sutherland und Mike Beedle geprägt wurde und mittlerweile Tausenden von Projekten zum Erfolg verholfen hat. Crescendo 2007 orientiert sich an Scrum und nutzt damit die umfangreiche Fachliteratur und die Lehrmittel, die zu diesem Vorgehensmodell verfügbar sind. Messbarkeit Ein wichtiger Aspekt qualitätsorientierter Verfahren ist die Nachvollziehbarkeit und Messbarkeit der Prozesse und Arbeiten. Ziel eines jeden Projektes ist es, Software zu erstellen, die bezüglich verschiedener Qualitätsmerkmale den Anforderungen entspricht. Wenn nachgewiesen werden soll, ob dies zutrifft, müssen nicht nur die Anforderungen dokumentiert sein, sondern auch die dazugehörenden Testfälle. Dies ist insbesondere auch wichtig, wenn das System Qualitätsstandards wie ISO 9000 oder FDA entsprechen muss. Crescendo 2007 verwendet deshalb Team-System, ein auf die Abwicklung agiler Software-Projekte konfigurierbares Planungs- und Managementsystem. Team-System unterstützt das Anforderungsmanagement, die Umsetzung sowie das Controlling und liefert wertvolle Nachweise und Kennzahlen. Planbarkeit Agile Vorgehensmodelle stehen im Widerspruch zur Vorstellung, dass sich ein Software-Projekt zu Beginn zuverlässig planen lässt. Trotzdem sind auch Kunden agiler Projekte auf Anhaltspunkte zum zukünftigen Projektverlauf angewiesen. Crescendo 2007 führt zu diesem Zweck eine Project Roadmap, die beschreibt, welche Ziele und Ergebnisse mit welcher Iteration erreicht werden sollen. Die Project Roadmap entspricht einer systematischen Produktplanung und dient als Hilfsmittel zur strategischen Abstimmung zwischen Business und Projekt. Sie wird nach Abschluss jeder Iteration geprüft und bei Bedarf angepasst. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

15 Umgang mit Kosten: „Samstagseinkauf mit Budget“
Vorgaben Wunschliste mit Priorisierungen und Kostenschätzungen Kosten Vereinbarter Budgetrahmen und generelle Zielsetzung Leistungsbezug Umbau gemäss Wunschliste, tatsächlichem Angebot und Rücksprache Abgleich Ziel Abgleich Umsetzung „Nach Aufwand mit Budgetrahmen und flexiblem Ergebnis“ Ergebnis orientiert sich an Budget und Zielsetzung (Nutzen) Kostenrisiko lässt sich durch überschaubare Aufgaben eingrenzen Bietet sich an, wenn Zielsetzung definiert ist aber Details noch nicht vollständig geklärt sind Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 15

16 Application Life Cycle
Crescendo Vertragsmodell und Controlling Application Life Cycle Business Analysis Initial Requirements Analysis Project Setup Iterative Realization Transition Operation and Maintenance Business Case Initial Requirements Specification Workitem List + Project Roadmap Application State of Readiness Operation Zusammengefasst lässt sich der Lebenszyklus wie folgt darstellen: Die Business Analyse erfolgt meist durch den Kunden. Er legt die unternehmerischen Ziele (Business Case) für das Vorhaben fest und befasst sich dabei mit den betriebswirtschaftlichen, terminlichen und finanziellen Aspekten. Auf der Basis des Business Case wird eine Anforderungsanalyse durchgeführt. Wie weit die Anforderungen zu diesem Zeitpunkt ermittelt werden können, hängt von der Komplexität des Systems sowie von Projektrahmenbedingungen wie Zeit oder Wissen ab. Die resultierende Anforderungsspezifikation hat vorläufigen Charakter, da im Verlauf des Projektes Verfeinerungen, Änderungen und Ergänzungen daran angebracht werden können. Sie sollte in jedem Fall ein Gesamtbild der zu erstellenden Funktionalität und der Systemeigenschaften liefern, sodass es möglich ist, ein geeignetes Lösungskonzept daraus zu entwickeln. Aufgrund der Anforderungsspezifikation wird eine Projekt Setup Phase durchgeführt. Im Rahmen dieser Phase werden alle bereits bekannten Anforderungen in eine strukturierte Gesamtliste (Product Backlog) aufgenommen und zusammen mit dem Kunden priorisiert. Zudem wird eine Aufwandschätzung für die Realisierungsphase durchgeführt. Das resultierende Realisierungsbudget dient zusammen mit dem Product Backlog als Grundlage für die Definition der Project Roadmap, in welcher der Iterationsplan, die inhaltlichen Iterationsziele vorgegeben werden. Auf der Basis der Projekt Roadmap und des Product Backlogs erfolgt nun die iterative Realisierung. Die Iterationen werden gemäss Scrum als Sprint bezeichnet und dauern bei Crescendo je nach Projekt zwischen 2 und 6 Wochen. Mit jedem Sprint werden nutzbare Ergebnisse erarbeitet, üblicherweise ein um neue Funktionalität erweitertes Software-Release. Auf diese Weise entsteht schrittweise eine immer umfassendere Applikation bis ein Stand erreicht wird, der in die Produktion übergeben werden kann. In der Einführung wird das Ergebnis des letzten Sprints für die Produktivsetzung vorbereitet. Dazu gehören Abnahmetests, Schulungen sowie die Vorbereitung von Support und Wartung. Die Einführungsphase ist von den betrieblichen Rahmenbedingungen der Applikation abhängig und kann sich von Projekt zu Projekt stark unterscheiden. Schliesslich startet die Phase Betrieb und Wartung. Je nach Situation wird dies vom Kunden selbst oder von einem Anbieter wie Trivadis übernommen. Falls sich in dieser Phase Ausbauwünsche ergeben, lässt sich dies mit denselben Verfahrensprinzipien wie zuvor in der iterativen Realisierung bewerkstelligen. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 16 16

17 Application Life Cycle : „Initial Requirements Analysis“
Crescendo Vertragsmodell und Controlling Application Life Cycle : „Initial Requirements Analysis“ Business Analysis Initial Requirements Analysis Project Setup Iterative Realization Transition Operation and Maintenance Business Case Initial Requirements Specification Workitem List + Project Roadmap Application State of Readiness Operation Initial Requirements - Projektorganisation, Projektteam - Reporting (Projekt, Steering Committee) - Projektplan (Termin, Kosten, Ressourcen) - Projektvorgehen Initial Specification - Featureliste aller Anforderungen - Systemarchitektur - Software Factory Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 17 17

18 Application Life Cycle : „Project Setup“
Crescendo Vertragsmodell und Controlling Application Life Cycle : „Project Setup“ Business Analysis Initial Requirements Analysis Project Setup Iterative Realization Transition Operation and Maintenance Business Case Initial Requirements Specification Workitem List + Project Roadmap Application State of Readiness Operation Initial Workitem List - Gegliederte Gesamtliste aller Anforderungen (Übernahme der Anforderungen aus der vorangehenden Phase) - Priorisierungen und Grobschätzungen Project Roadmap - Iterationsplan (Anzahl, Termine, Team- kapazität) - Planung der Qualität und des Umgangs mit den Iterationsergebnissen Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 18 18

19 Application Life Cycle : „Iterative Realization“
Crescendo Vertragsmodell und Controlling Application Life Cycle : „Iterative Realization“ Business Analysis Initial Requirements Analysis Project Setup Iterative Realization Iterative Realization Transition Operation and Maintenance Business Case Initial Requirements Specification Workitem List + Project Roadmap Application State of Readiness Operation 6 – 8 weeks Iteration 1 Iteration 2 Iteration n Releases Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 19 19

20 eScrum Begriffe Product Details Sprint Details Product Backlog
Durch Product-Owner verwaltet Durch Team verwaltet Product Details Logische Bereiche(Areas) Können z. B. Module sein inkl. Detailbeschreibung Sprint Details Sprint-Name Dauer (von – bis) Ziele, Version, etc. 1 3 Pro Sprint Für das ganze Produkt / Projekt Product Backlog Adressen verwalten Duplikate finden Adressen drucken Ansteuerung Telefon … Sprint Tasks Adressen verwalten - Techn. Spezifikation erstellen - Datenbank modellieren - BusinessLogik erstellen - Unit Tests schreiben - … 1 n 2 4 Wird laufend ergänzt und priorisiert Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

21 Initial Requirements Analyse  ProductBacklog
Crescendo Vertragsmodell und Controlling Initial Requirements Analyse  ProductBacklog Konkretisierung Kreativ / Brainstorming Req. Medienbruch Konkretisierung Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

22 Einlesen Product Backlog
Requirements (Product Backlog) Hinweis auf NON-Hierarchie bei Items Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 22

23 Project Roadmap / Sprint Details
Crescendo Vertragsmodell und Controlling Project Roadmap / Sprint Details Project Roadmap (Sprint Details) Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

24 Sprint Tasks definieren (auf Basis Product Backlog)
Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

25 Iterative Realization
Work Item Load pro Sprint Release Development 6 - 8 weeks Sprint 1 Sprint 2 Sprint 3 Sprint 4 Zeit Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

26 Reporting / Controlling / Monitoring
Das Verhältnis „Schätzung zu tatsächlichem Aufwand“ wird fortlaufend ermittelt und für die Extrapolation und Forecast des Projekt- fortschritts verwendet. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

27 Agenda Klassische vs. agile Projekte Umsetzung des agilen Vorgehens
Ausblick Data are always part of the game. Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

28 Ausblick Weiterentwicklung von VSTS im Hinblick auf agile Vorgehensmethoden Einblick in VSTS Codename „Rosario“ April CTP MSF Agile Prozess Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

29 Was schmerzt / was fehlt?
Keine Gruppierung von Arbeitspackete Fehlende Analyse Unterstützung Controlling muss selbst aufgebaut werden Fehlende Abwicklung von manuellem Testing Scrum Prozess Template „eScrum“ war nur mit Work-Around auf Team System 2008 lauffähig Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

30 Wo werden wir besser unterstützt?
Unterstützung in der Analyse durch entsprechende UML Diagramme Arbeitspakete können hierarchisch verwaltet werden Controlling und Reporting ausgebaut Manuelles Testing besser integriert Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

31 Requirement Analyse - Diagramme
Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

32 Arbeitspackete strukturieren
Work Items können hierarchisch gegliedert werden User Story beinhaltet mehrere Tasks Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

33 Iterations Planung in Excel
Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

34 Ressourcen Planung Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

35 Reporting Services Reports
Auswertungen für Projekt Stakeholder verbessert Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

36 Automatisierte Excel Trend Reports
Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

37 Manuelles Testing Test Szenarien Management
Planung von manuellen Tests Work Item Integration Test Aufzeichnung und Nachbearbeitung Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

38 Testing mit Camano Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

39 Fazit All-In-One Suite wird langsam Wirklichkeit
Unterstützung von Analyse bis zum Testing Wichtig: CTP Release: Funktionalität und Verhalten können / werden sich noch ändern! Release Datum für Rosario noch nicht bekannt = Nicht warten, jetzt umsteigen und ALM Gedanke leben Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

40 Fragen? ?

41 Vielen Dank !