basel · baden · bern · lausanne · zurich · düsseldorf · frankfurt/m. · freiburg i. br. ·...

Basel · Baden · Bern · Lausanne · Zurich · Düsseldorf · Frankfurt/M. · Freiburg i. Br. · Hamburg · Munich · Stuttgart · Wien

Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM

Patrick Spieler, Nicolas MügglerGlattbrugg, August 2008

http://blog.trivadis.com

© 2008Theorie und Praxis von agilen Entwicklungen mit VSTS und SCRUM 2

Agenda

Data are always part of the game.

Klassische vs. agile Projekte

Umsetzung des agilen Vorgehens

Ausblick


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

© 2008

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 4


Klassische Vorgehensmethode

Anforderungs-definition

System- undSoftwareentwurf

Realisation undKomponententest

Integration undSystemtest

Betrieb undWartung

Mögliches Phasenkonzept

Kunde

Entwicklungs-Team

Tester

Projektleiter


Klassische Zielerreichungsstrategie

Ausgangslage:Reise von Zürich Lugano

Vorgehen:1. Route festlegen San Gottardo2. Gesamte Reiseplanung erstellen

• Strecke: 204 km• Fahrzeit: 2h 30 min

3. Losfahren4. Vor Wassen:

Stau, da Gotthard gesperrt (Unfall!)a) im Stau wartenb) St. Gotthard umfahren

5. Routenänderung San Bernardino6. Geänderte Reiseplanung (gesamt)



Application Life Cycle (klassisch)

Business Analyse

Anforderungs-Analyse

DesignRealisation

Test

Betrieb Wartung

Business Case• Kosten/Nutzen• Time to Market• Organisation

RequirementsSpecification• Functional• Non-Functional

Werkvertrag SLA

Application Operation

Vorgabe Werk


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!


Agile Vorgehensmethode (Beispiel Scrum)

Product Backlog(priorized)

Tasksexpanded by

the Team

Sprint Backlog

30 days

24 h

DailyScrum

Meeting

Demonstrate & Verify newFunctionality

update

Project Team

n-Sprints

Product Owner

ScrumMaster

rot = Rollen / Aufteilung

blau = Ceremonies

grün = Artefakte

Sprint PlanningMeeting

Sprint Review

Sprint Retro-

spective

do not disturb!

Burn Down Chart


Agile Zielerreichungsstrategie

Ausgangslage:Reise von Zürich Lugano

Vorgehen:1. Etappe „A“ festlegen Wollerau2. Reiseplanung für Etappe „A“ erstellen

• Strecke: 30 km• Fahrzeit: 20 min

3. Etappe „A“ losfahren4. Bei Wollerau:

Situation analysieren, Staumeldung im Radio Gotthard gesperrt (Unfall!)

5. Etappe „B“ festlegen San Bernardino6. Reiseplanung für Etappe „B“ erstellen



Application Life Cycle (agil)

Business Analyse

Agile Vorgehensmethoden Betrieb Wartung

Business Case• Kosten/Nutzen• Time to Market• Organisation

RequirementsSpecification• Functional• Non-Functional

SLA

Application Operation

Zusammenarbeitsvertrag

Vorgabe Nutzen


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!


Agenda




Ausblick



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

© 20081515

Umgang mit Kosten: „Samstagseinkauf mit Budget“

VorgabenWunschliste mit Priorisierungen und Kostenschätzungen

KostenVereinbarter Budgetrahmen und generelle Zielsetzung

LeistungsbezugUmbau gemäss Wunschliste, tatsächlichem Angebot und Rücksprache

AbgleichZiel

AbgleichUmsetzung

„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


Application Life Cycle

Business Analysis

Initial Requirements

Analysis Iterative

Realization Operation

and Maintenance

Project Setup Transition

Application OperationBusiness Case

InitialRequirement

sSpecification

Workitem List+

Project Roadmap

State of Readiness


Application Life Cycle : „Initial Requirements Analysis“

Initial Requirements- Projektorganisation, Projektteam- Reporting (Projekt, Steering Committee)- Projektplan (Termin, Kosten,

Ressourcen)- Projektvorgehen

Initial Specification- Featureliste aller Anforderungen- Systemarchitektur- Software Factory

Business Analysis


Analysis Iterative


and Maintenance



InitialRequirement

sSpecification

Workitem List+

Project Roadmap

State of Readiness


Application Life Cycle : „Project Setup“

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

Business Analysis


Analysis Iterative


and Maintenance



InitialRequirement

sSpecification

Workitem List+

Project Roadmap

State of Readiness


Application Life Cycle : „Iterative Realization“

Business Analysis


Analysis Iterative


and Maintenance


Iteration 1 Iteration 2 Iteration n

Releases

Iterative Realization


InitialRequirement

sSpecification

Workitem List+

Project Roadmap

State of Readiness

6 – 8 weeks

© 2008

Sprint Tasks- Adressen

verwalten - Techn. Spezifikation erstellen - Datenbank modellieren - BusinessLogik erstellen - Unit Tests schreiben - …

Product Backlog

- Adressen verwalten- Duplikate finden- Adressen drucken- Ansteuerung Telefon- …

Product Details - Logische

Bereiche(Areas)- Können z. B. Module

sein- inkl.

Detailbeschreibung

eScrum Begriffe


1 n

Für

das

gan

ze P

rodu

kt /

Pro

jekt

Pro S

print

1

2

Wird laufend ergänzt und priorisiert

4

Durch Product-Owner verwaltet

Sprint Details - Sprint-Name

- Dauer (von – bis)- Ziele, Version, etc.

3

Durch Team verwaltet


Initial Requirements Analyse ProductBacklog

Kreativ / Brainstormin

g

Konkretisierung

Konkretisierung

© 2008

Einlesen Product Backlog


Requirements (Product Backlog)


Project Roadmap / Sprint Details

Project Roadmap (Sprint Details)

© 2008

Sprint Tasks definieren (auf Basis Product Backlog)


© 2008

Iterative Realization


Work Item Loadpro Sprint

Zeit Sprint 1 Sprint 2 Sprint 4 Sprint 3

6 - 8 weeks

Development

Release

© 2008

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.



Agenda




Ausblick

© 2008

Ausblick

Weiterentwicklung von VSTS im Hinblick auf agile Vorgehensmethoden

Einblick in VSTS Codename „Rosario“ April CTP

MSF Agile Prozess


© 2008

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


© 2008

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

© 2008

Arbeitspackete strukturieren


Work Items können hierarchisch gegliedert werden

User Story beinhaltet mehrere Tasks

© 2008

Manuelles Testing

Test Szenarien Management

Planung von manuellen Tests

Work Item Integration

Test Aufzeichnung und Nachbearbeitung


© 2008

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



Fragen?

?


Vielen Dank

!

basel · baden · bern · lausanne · zurich · düsseldorf · frankfurt/m. · freiburg i. br. ·...

Documents