21
Seite 1 von 21 Scrum – auf dem Bierdeckel erklärt Begriffe, Konzepte, Grundverständnis Dezember 2015, Version 1

Scrum – auf dem Bierdeckel erklärt - it-agile.de · Seite 2 von 21 Über diesen Artikel Dieser Artikel führt in Scrum ein. Er erläutert die grundlegenden Begriffe und Konzepte

  • Upload
    buibao

  • View
    239

  • Download
    0

Embed Size (px)

Citation preview

Seite 1 von 21

Scrum–aufdemBierdeckelerklärtBegriffe,Konzepte,Grundverständnis

Dezember2015,Version1

Seite 2 von 21

Über diesen Artikel DieserArtikelführtinScrumein.ErerläutertdiegrundlegendenBegriffeundKonzepteunderläutert,wiediesezusammenhängen.DieScrum-MechanikistnurdieeineSeitederMedaille.DiedahinterstehendenWerteundPrinzipiensindmindestensgenausowichtig.DaherfindetsichnachderScrum-EinführungeineBeschreibungdesagilenManifestes,dasdieagilenPrinzipiendefiniert.DanachfindetsicheineÜbersichtüberdieScrum-Rollen,-Artefakteund–Meetings,diezumNachschlagengeeignetist.

DerArtikelhilftdemScrum-Neuling,sicheinenerstenÜberblicküberdieFunktionsweisevonScrumzuverschaffen.DiesesGrundverständnisdientalsOrientierungshilfefürdieweitereVertiefunginScrum,diedurch Scrum-Einführungsbücher1oder Schulungen2erfolgen kann. Auf keinen Fall sind Sie nach derLektüre dieses kurzen Artikels in der Lage, Scrum einzuführen. Den Abschluss des Artikels bildet einAbschnittzudenHerausforderungenbeiderScrum-Einführung.

StefanRoock

CEOundManagement-Beraterbeiit-agile

[email protected],Tel.0172/4297617

1z.B.StefanRoock,HenningWolf:„Scrum-verstehenunderfolgreicheinsetzen“2z.B.http://www.it-agile.de/schulungen

Seite 3 von 21

Inhalt

SCRUM–DREIPERSPEKTIVEN 4

PRODUKTPERSPEKTIVE 5

ENTWICKLUNGSPERSPEKTIVE 7

VERBESSERUNGSPERSPEKTIVE 8

DASAGILEMANIFEST 9

ÜBERBLICKÜBERDIESCRUM-ROLLEN,-MEETINGSUND-ARTEFAKTE 11SCRUM-MASTER-AUFGABEN 11PRODUCT-OWNER-AUFGABEN 13AUFGABENDESENTWICKLUNGSTEAMS 13DAILYSCRUM 14SPRINTPLANNING 14SPRINT-REVIEW 15SPRINT-RETROSPEKTIVE 16BACKLOGREFINEMENT 16RELEASEPLANNING 17PRODUCTBACKLOG 17SPRINTBACKLOG 17PRODUKTINKREMENT 18SPRINTBURNDOWNCHART 18RELEASEBURNUPCHART 18

SCRUMEINFÜHREN 20

UNTERSTÜTZUNGDURCHIT-AGILE 21

Seite 4 von 21

Scrum – Drei Perspektiven MankannScrumineinemSatzbeschreiben:

Scrumbedeutet:AutonomeEntwicklungsteamsmitBusiness-Fokus,

dieihrenProzessinBesitzundVerantwortungnehmen.

In diesem Satz werden drei Perspektiven sichtbar,ausdenenmanScrumbetrachtenkann:

1. Die Produktperspektive (Business-Fokus)beleuchtet, wie Produkte definiert undverbessertwerden.

2. Die Entwicklungsperspektive (autonomeEntwicklungsteams) beleuchtet,wie TeamsProdukteentwickeln.

3. Die Verbesserungsperspektive (Prozess inBesitz und Verantwortung nehmen)beleuchtet, wie Zusammenarbeit undProzesseverbessertwerden.

Diese drei Perspektiven werden im das Scrum-Frameworkintegriert,dassoeinfachist,dassesaufeinenBierdeckelpasst(sieheAbbildungrechts)3.

WirbeschreibendiedreidargestelltenPerspektivenindenfolgendenAbschnittenausführlicher.

3Den dargestellten Scrum-Bierdeckel gibt es im it-agile-Shop:http://www.itagileshop.de

Seite 5 von 21

Produktperspektive DieProduktperspektivebeginntmitderProductOwner-Rolle. Der Product Owner verantwortet denProdukterfolg, indem er den Produktnutzen durch diePriorisierung der Produkt-Features optimiert. DerProduct Owner ist derjenige, der die Softwareentwickelthabenmöchte.WenndiesePersondieRolleselbst nicht ausfüllen kann oder möchte, kann sie dieProduct Owner-Rolle vollständig an jemand anderenabgeben. Auf jeden Fallmuss der Product Owner aberbevollmächtigt sein, die Produktentscheidungen zutreffen. Man kann sich den Product Owner auch alsUnternehmerimUnternehmenvorstellen.

FürdenProductOwnergiltdasHighlander-Prinzip:„Eskann nur einen geben.“ Die Rolle kann in Scrum nichtvonmehrerenPersonengeteiltwahrgenommenwerdenundschongarnichtdurcheinKomitee.Manmöchte inScrum, dass der Product Owner mit einer StimmegegenüberdemTeamunddenStakeholdernsprichtundEntscheidungenschnellfällenkann.

Der Product Owner verfolgt eine Produktvision.Passend zur Produktvision pflegt der Product OwnereinProductBacklog, indemdieProdukteigenschaftenbeschriebensind,diefürdenProdukterfolgnotwendigerscheinen. Das Product Backlog wird durch denProduct Owner priorisiert und durch dasEntwicklungsteamgeschätzt.

Scrum legt nicht fest, wie genau die Einträge desProduct Backlogs gestaltet sind. Viele Teamsmachengute Erfahrungen mit User Stories: ExemplarischeBenutzungsszenarien aus Sicht eines Benutzers. UserStories haben eine andere Qualität als klassischeAnforderungen. Bei User Stories liegt der Fokusdarauf, ein gemeinsames Verständnis bei allenBeteiligten zu erzeugen und nicht darauf, dass dieBeschreibung vollständig, widerspruchsfrei undkorrektist.

Die Entwicklung erfolgt in Iterationen, die in ScrumSprints heißen. Sprints haben eine immer gleicheLänge vonmax. 4Wochen.Was im Sprint entwickeltwird,wird imSprintPlanning festgelegt.Hierwerdenhochpriorisierte Einträge aus dem Product Backlogausgewählt, von denen das Entwicklungsteammeint,dasssiesie imSprintumsetzenkönnen.DasErgebnisist ein lieferbares Produktinkrement. Ob dasProduktinkrement tatsächlich anKunden ausgeliefertwird, entscheidet der Product Owner. Die imProduktinkrement implementierten Features müssenaberaufjedenFallproduktsreifsein(mind.entwickeltundqualitätsgesichert).

Seite 6 von 21

Das Entwicklungsteam demonstriert dasProduktinkrement im Sprint Review denStakeholdern4, damit diese Feedback zum Produktgeben können. Das Feedback wird vom ProductOwner entgegengenommen und nach seinemErmessenindasProductBacklogintegriert.

Gute Fragen, um nützliches Feedback zu erhalten,sind:

• „Was hindert uns daran, das vorliegendeProduktinkrementproduktivzubenutzen?“

• „Wie kann das vorliegendeProduktinkrementnochwertvollergestaltetwerden?“

4Stakeholder ist in Scrum jeder, der Interesse am Produkt oderEinfluss auf die Entwicklung hat: Kunden, Anwender, Sponsoren,Manager,Betriebsratetc.

Seite 7 von 21

Entwicklungsperspektive Das Entwicklungsteam entwickelt ausgehend vomSprint Backlog ein lieferbares Produktinkrement. DasEntwicklungsteam besteht aus 3-9 TeammitgliedernundenthältalleFähigkeiten,dienotwendigsind,umdasSprintBacklogindasProduktinkrementzuüberführen.Entwickler sind demnach nicht nur Programmierer,sondern je nach Kontext auch UX-Experten, Designer,Handbuch-AutorenoderTester.

DasEntwicklungsteamorganisiertsichselbst.Eswedereine formelle Hierarchie noch herausgehobene RollenoderPositionenimEntwicklungsteam.

Das Entwicklungsteam bestimmt im Sprint Planning,wievielArbeit es indenSprint aufnimmt.Eswendetdas Pull-Prinzip an (es „zieht“ Arbeit in den Sprint).Für die ausgewählten Einträge aus dem ProductBacklog erstellt dasEntwicklungsteameinenPlan fürdie Umsetzung im Sprint. Die ausgewählten Einträgeaus dem Product Backlog zusammen mit demUmsetzungsplanbildendasSprintBacklog.

Das Entwicklungsteam macht so eine Vorhersage(Forecast) darüber, was es im Sprint schaffen kann.Diese Vorhersage soll die Qualität einerWettervorhersage haben. In der Regel sollte dasEntwicklungsteam das liefern, was es eingeplant hat.Es sollte aber niemand übermäßig überrascht sein,wenndashinundwiedernichtklappt.

Während des Sprints treffen sich die Teammitgliederwerktäglich zum Daily Scrum, um sich über denArbeitsfortschritt und die nächsten Aufgaben imSprint abzustimmen. Dazu kommen dieTeammitglieder jeden Werktag zur gleichen Uhrzeitam immer gleichen Ort für maximal 15 MinutenzusammenundbeantwortendreiFragen:

1. Was habe ich seit dem letzten Daily Scrumerledigt,dasunsdemSprintzielnäherbringt?

2. Welche Hindernisse sehe ich auf dem WegzumSprintziel?

3. Wasplane ich,biszumnächstenDailyScrumzu erledigen, das uns dem Sprintzielnäherbringt?

DerProductOwner ist ein optionalerTeilnehmer amDailyScrum.

Seite 8 von 21

Verbesserungsperspektive Der ScrumMaster ist ein Coach für alle Beteiligten. Ersorgtdafür,dassProductOwner,dasEntwicklungsteamund Manager verstehen, wie Scrum funktioniert undhilftIhnen,Scrumeffektivanzuwenden.GegenüberdemEntwicklungsteamschafftereinenRahmen,indemsichdasTeamselbstorganisierenkannundhältdemTeamimmer wieder den Spiegel vor. Der Scrum Masterkümmert sich außerdem darum, dass Hindernisseidentifiziert und beseitigt werden. Er moderiert dieScrum-Meetings.

Der kontinuierliche Verbesserungsprozess ist beiScruminzweiMeetingsverankert.ZumeinennehmenVerbesserungen ihrenAusgang imDailyScrum,wennHindernisse identifiziert werden. Hindernisse sind inScrum alles, was die Arbeit an aktuellen Aufgabenblockiert oder verlangsamt. Der Scrum MasterkümmertsichumdieBeseitigungderHindernisse.Dasbedeutetnurselten,dasserdasHindernisalleineausder Welt schafft. Er wird dazu in der Regel mitweiteren Parteien im Unternehmen interagierenmüssen (z.B. um finanzielle Mittel für schnellereRechnungzubeschaffen).

AmEndedesSprintsfindetnachdemSprintReviewdie Sprint Retrospektive statt. Hier reflektiert dasEntwicklungsteam zusammen mit dem ProductOwner darüber, was im letzten Sprint gut undwaswenigergutgelaufenist.AufdieserBasisdefinierensie Verbesserungsmaßnahmen, die sie im nächstenSprint umsetzen wollen. Die Sprint RetrospektivewirddurchdenScrumMastermoderiert.

Seite 9 von 21

Das agile Manifest Für agile Entwicklung gibt esmit demAgilenManifest5einLeitbilddafür,wasAgilitätbedeutet.

DiesesLeitbildbeginntmitvierWertaussagen:

• IndividuenundInteraktionensindwichtigeralsProzesseundTools

• Laufende Software ist wichtiger alsausführlicheDokumentation

• ZusammenarbeitmitdemKundenistwichtigeralsVertragsverhandlungen

• Reagieren auf Veränderungen ist wichtiger alsPlanbefolgung

Das heißt, obwohlwir dieWerte auf der rechten Seitewichtig finden, schätzen wir die Werte auf der linkenSeitehöherein.

In klassischen Kontexten generieren die Dinge auf derrechtenSeite subjektivwahrgenommeneSicherheit.Wersich an die Prozesse hält und die vorgeschriebenenTools einsetzt, wer jede seiner Tätigkeiten haarkleindokumentiert, wer alle Eventualitäten in Verträgenberücksichtigt undwer sich andenPlanhält, kannbeiProblemennachweisen,dassernichtSchuld ist.Leidergenerierenwir auf dieseWeise in komplexenMärktenkeinen Geschäftswert. In dynamischen MärktenbrauchenwirdieFlexibilität,dieunsdieDingeaufderlinkenSeitegeben.

Dieser Gegensatz erklärt,warum die Einführung agilerVerfahren in der Praxis häufig so schwierig ist. AlleBeteiligten müssen ein Stück dieser „Sicherheit durchStatik“ loslassen, um auf den Kunden und denGeschäftswertfokussierenzukönnen.

Ergänzt werden die vier Wertaussagen durch zwölfPrinzipien, die konkretisieren, wie die Werte sich aufdietäglicheArbeitauswirken:

1. Unsere höchste Priorität ist es, den Kundendurch frühe und kontinuierliche AuslieferungwertvollerSoftwarezufriedenzustellen.

2. Heiße Anforderungsänderungen selbst spät inder Entwicklung willkommen. Agile Prozessenutzen Veränderungen zumWettbewerbsvorteildesKunden.

3. Liefere funktionierende Software regelmäßiginnerhalb weniger Wochen oder Monate undbevorzugedabeidiekürzereZeitspanne.

4. FachexpertenundEntwicklermüssenwährenddesProjektestäglichzusammenarbeiten.

5. Errichte Projekte rund um motivierteIndividuen. Gib ihnen das Umfeld und dieUnterstützung, die sie benötigen und vertrauedarauf,dasssiedieAufgabeerledigen.

6. Die effizienteste und effektivste Methode,Informationen an und innerhalb einesEntwicklungsteams zu übermitteln, ist imGesprächvonAngesichtzuAngesicht.

5http://agilemanifesto.org

Seite 10 von 21

7. Funktionierende Software ist das wichtigsteFortschrittsmaß.

8. Agile Prozesse fördern nachhaltigeEntwicklung.DieAuftraggeber,EntwicklerundBenutzer sollten ein gleichmäßiges Tempo aufunbegrenzteZeithaltenkönnen.

9. Ständiges Augenmerk auf technische ExzellenzundgutesDesignfördertAgilität.

10. Einfachheit-dieKunst,dieMengenichtgetanerArbeitzumaximieren-istessenziell.

11. Die besten Architekturen, Anforderungen undEntwürfe entstehen durch selbstorganisierteTeams.

12. In regelmäßigen Abständen reflektiert dasTeam,wieeseffektiverwerdenkannundpasstseinVerhaltenentsprechendan.

Seite 11 von 21

Überblick über die Scrum-Rollen, -Meetings und -Artefakte

DieserAbschnittgibtprägnanteÜbersichtenundChecklisten für die Rollen 6 , Meetings undArtefakte von Scrum. Diese sollten auf keinenFalldogmatischverwendetwerden.Esgibtnichtdie eine richtige Form, die Meetingsdurchzuführen, die Rollen auszuleben oder dieArtefakte zu gestalten. Dieser Abschnitt kannaber als Kurzreferenz helfen sowie alsStartpunkt, um überhaupt einmal mitirgendetwas anzufangen. Wer Scrum allerdingsnach fünf Sprints immer noch genausopraktiziert, wie es in den Übersichten undCheckliste dargestellt ist, macht etwas falsch:Inspektion und Adaption (Inspect&Adapt) desProzessesfehlt!

Scrum-Master-Aufgaben DieMeetingsmacheninScruminderSummeca.10%derZeitaus.RechnenwirfürdieVor-undNachbereitung noch einmal dieselbe Zeit,verbleibtdocheinerheblicherAnteilArbeitszeit,in denen der Scrum Master sich auf andereWeise nützlich macht. Welche Aufgaben ScrumMaster in der Praxis übernehmen, hängt vomUnternehmen, vom Projekt und von der Reifedes Teams ab. Im Folgenden findet sich eineListe mit Beispielen aus der Praxis. Die fettgesetzten Punkte sind die Aufgaben, die derScrumMasteraufjedenFallwahrnehmenmuss.

Teamebene

1. Gemeinsam mit dem Team

Retrospektiven-Maßnahmenumsetzen

2. Die Entwickler unterstützen, ein besserestechnischesVerständnis zuerwerben,dabeiggf. an Entwicklermeetings teilnehmen undagile Entwicklungspraktiken einführen

6Die Aufgabenlisten für ScrumMaster und Product Ownerbasieren zum Teil auf Vorschlägen unseres Ex-KollegenBerndSchiffer.

(testgetriebeneEntwicklung,kontinuierlicheIntegration,PairProgramming)

3. Gerade für neue Scrum-Teams: demTeam beim Umgang mit Veränderungen

helfen, die beim Umstieg auf Scrum

anstehen

4. Materialnachschub fürs Taskboardorganisieren

5. Einzelgespräche mit Entwicklern führen;generell ein Ohr am Team haben, ummitzubekommen,waslosist

6. Impediments aufnehmen und bei der

Behebung unterstützen: Diese könnenkonkret aus einzelnenEntwicklungsaufgaben resultieren,Teamprobleme sein,Kommunikationsprobleme im Team, mitdem Product Owner oder zu Stakeholdern,sich aber auch auf Organisationsebenebefinden.(WasdarfdasTeam,werstörtdasTeam?)

7. Teammitglieder an die vereinbarten

Spielregelnerinnern

8. Für Festlegung von Teamspielregeln

sorgenunddiesegutsichtbarmachen9. Einzelgespräche mit Teamfokus: Was

brauchstdu im/vomTeam?Wiegehtesdirgerade?Wiezufriedenbistdu?Feedbackandich, Feedback von dir?Wie sehe ich deineRolle im Team und deinen Beitrag fürsTeam?WostehstdudemTeamimWeg?Wokönntest du dich mehr einbringen?(Empfehlung: Einzelgespräche alle zwei bisdrei Wochen mit jedem TeammitgliedinklusiveProductOwnerführen.)

10. Aha-Momente oder Leidensdruck

erkennen als Initialpunkt für sofortige

Veränderung (nicht immer nur Input fürRetrospektiven,oftauchdirektumsetzbar)

11. Netzwerk durchforsten für Ideen, wie manProbleme/Herausforderungen des Teamslösenkönnte(Optionenschaffen)

12. BeurteilungderSituationmitScrum-Master-Kollegen, Coaches oder Netzwerkdiskutieren, um wach zu bleiben und nichtauf die eigene Perspektive beschränkt zubleiben

13. InformativenWorkspace gestalten bzw. dasTeamanregen,ihnzugestaltensowieaktuellundhilfreichzuhalten

14. Organisatorische Aufgaben wie das BuchenvonMeetingräumenetc.(abernichtso,dassdie Teammitglieder das nicht mehr selbstkönnen)

Seite 12 von 21

15. Social Events für das Team-Buildingorganisieren (das kann auch das BestärkenvonKollegensein,diedanndieOrganisationübernehmen)

16. Auf Missstände hinweisen, selbst wenndieseerstmal fürdasTeamkeingroßes

Problem zu sein scheinen (Beispiel:Sprints werden nicht geschafft, was dasTeam zwar nicht so dramatisch findet, derScrum Master oder die Stakeholder aberschon.)

17. Konfliktemoderieren18. Beteiligung an Diskussionen,

insbesondere um zu helfen, mehr

Optionen zu schaffen und auf Daten

aufmerksam zu machen sowie

Beobachtungenwiederzugeben (auchmalauf Gutes hinweisen, also Dinge, die schongutlaufen)

19. Sessions zum ThemaEigenverantwortlichkeitorganisieren

20. Die Erstellung eines Teamvertrags

moderieren

21. DemTeamhelfen,Akzeptanzkriteriendirektin testbare Form zu bringen und dannentsprechendautomatisiertzutesten

22. In Konfliktsituationen Einzelgespräche mitTeammitgliedernführen

23. DasTeamvorunerwünschtenEinflüssenvon außen schützen, also z.B.Teammitgliedern den Rücken stärken, dievon ihrem Chef für nicht vereinbartezusätzliche Aufgaben abgezogen werdensollen

TeamübergreifendeOrganisationsebene

24. Unterstützung bei der Organisation vonteamübergreifendem Wissenstransferzwischen Entwicklern, Testern etc.,beispielsweise in Communities of Practice(CoP)

25. Austauschmit anderenScrum-Mastern (z.B.in einer Scrum-Master-CoP, aber auch überCommunity-Events), um überHerausforderungen und Verbesserungen zusprechen und um neue Ideen fürVerbesserungsmaßnahmenzubekommen

26. NeueScrumMasterausbilden27. TeilnahmeanMeetingsundGesprächenmit

ZuliefererndesTeamsoderEmpfängernvonTeamergebnissen gemeinsam mitTeammitgliedern und dem Product Owner,damit das Team optimal in dieGesamtprozesseeingebundenistundimmer

alle nötigen Informationen hat (undweitergibt)

28. Scrum erklären: Rollen,Meetings,Werteerklären für das Team, aber auch für

weitere Personen im Unternehmen oder

beiKunden

29. Wenn es schon halbwegs läuft� mit Scrum,an Organisationsmeetings teilnehmen, diedas Team� betreffen (könnten), umAnregungenfürmehroder� konsequenteresScrum zu geben, die Teambedürfnisse zukommunizieren und um direktereKommunikationmitdemTeamherzustellen

30. Teamübergreifenden Austausch anregen(aufProduct-Owner-undTeamebene)

31. Mit Rat und Tat Fragen zu Scrumbeantworten für das Team und

Außenstehende

32. Mit Managern, Projektleitern,

Teamleitern etc. über Rechte und

Pflichten der Teams sprechen und

darüber,wiedieTeamsgestärktwerden

können

33. Scrum/agilderPersonalabteilungerklären34. Zusammenspiel/Abstimmung zwischen

Teamsverbessern

35. Manager dabei unterstützen, das Team fürschwierigepersonelle SituationenLösungenfinden zu lassen, anstatt selbst Lösungenvorzugeben

36. DieinternenScrumMasterunterstützenundcoachen

37. Änderungen der Team-Zusammensetzungmoderieren

38. DasControllingmitderneuenScrum-WeltinVerbindungbringen

39. Die unternehmensinterne Vernetzung derScrum Master und „Agilen“ über Spartenhinausbegleiten

Anforderungsebene und Product Ownerunterstützen

40. Bei Story-Schnitt und Backlog-

Organisation den Product Owner

unterstützen

41. Den Product Owner beim Stakeholder-Managementunterstützen

42. MitdemProductOwnerundauchmitdenEntwicklern das Schreiben von User

Storiesüben

43. Die Product Owner dabei unterstützen,die Anforderungsflut strukturierter zu

bewältigen

Seite 13 von 21

44. Die Prozessfindung beimPortfoliomanagement der Product OwnerundStakeholderbegleiten

Product-Owner-Aufgaben Die Aufgaben des Product Owners variierenabhängig von Unternehmen und Projekt. Diefolgende Liste enthält Beispiele von Product-Owner-Aufgaben aus der Praxis. Die fettgesetzten Punkte sind die Aufgaben, die derProduct Owner auf jeden Fall wahrnehmenmuss.

Produkteigenschaften

1. Produktvisionerstellen2. Produktvision an Stakeholder und

Entwicklunsteamkommunizieren

3. Schreiben von User Stories (allein, mitStakeholdern,mitdemEntwicklungsteam)

4. Akzeptanzkriterien für User Stories

formulieren (in der Regel zusammen mitdemEntwickungsteam)

5. Ordnen/Priorisieren des Product

Backlogs (inkl. Entscheidung, wasentwickeltwirdundwasnicht)

6. Die bereits entwickelten

Produktinkrementekennen

7. Mit den bereits entwickelten

Produktinkrementen„herumspielen“

8. DieWertschöpfungdesProduktsdefinieren9. DieWertschöpfungdesProduktskennen,

messenundoptimieren

10. Produktbezogene Feedbackschleifeninstallierenundverkürzen

ZusammenarbeitmitdemTeam

11. RefinementdesProductBacklogs (in derRegelzusammenmitdemTeam)

12. Zu großeUser Stories aufsplitten (in derRegel zusammen mit demEntwicklungsteam), sodass sie in Sprintspassen

13. Eine Sprint-Ziel-Skizze in das SprintPlanningmitbringen

14. Hoch priorisierte, gut ausgearbeiteteProduct-Backlog-Einträge in das Sprint

Planningmitbringen15. MitarbeitimSprintPlanning16. Beantwortung fachlicher Fragen des

Entwicklungsteams im Sprint Planning

undwährenddesSprints17. TeilnahmeanDailyScrums18. Teilnahme an und Mitarbeit in Sprint-

Retrospektiven

19. Dem Entwicklungsteam helfen, seinenProzesszuverbessern

20. DefinitionderDefinitionofReadyzusammenmitdemEntwicklungsteam

21. Definition der Definition of DonezusammenmitdemEntwicklungsteam

22. Feedback zu implementierten Featuresan das Team im Sprint oder im Sprint-

Review23. Dem Entwicklungsteam eigene

Unzufriedenheiten deutlich machen und

erklären. Mitarbeit bei der Suche nachLösungen.

24. Dem Entwicklungsteam die relevantenGeschäftszahlen/KPIstransparentmachen

25. Dem Entwicklungsteam verdeutlichen, wiedas Produkt auf dem Markt bzw. bei denKundenankommt

Kunden/Anwender

26. Kundenbedürfnisse verstehen (mitKunden/Anwendernsprechen)

27. DenMarktverstehen28. Ausgewählte Kunden/Anwender in die

Sprint-Reviewsintegrieren

29. Aufsetzen und Durchführen geeigneterErfolgsmetriken (z.B. KundenzufriedenheitüberdenNetPromoterScoremessen)

30. Risikomanagement über die

Ordnung/Priorisierung des Product

Backlogs

31. Annahmen über

Kunden/Anwender/Märkte testen (z.B.miteinemMinimumViableProduct)

ManagementsonstigerStakeholder

32. Dafür sorgen, dass die richtigen

StakeholderzumSprint-Reviewkommen

33. Erstellung und Aktualisierung desReleaseplans

34. AktualisierungdesReleaseBurnupCharts35. Kommunikation von Releaseplan und

ReleaseBurnupChartandieStakeholder36. Stakeholder über neue

Produkteigenschafteninformieren37. Budgetkontrolle

Aufgaben des Entwicklungsteams Die Aufgaben des Entwicklungsteams variierenabhängigvonUnternehmenundProjekt.Waszuden Aufgaben des Entwicklungsteams gehörtund was nicht dazu gehört, wird zum GroßteilüberdieDefinitionofReadyunddieDefinitionofDone formuliert. Die folgende Liste enthält

Seite 14 von 21

Beispiele von Aufgaben des EntwicklungsteamsausderPraxis.DiefettgesetztenPunktesinddieAufgaben, die das Entwicklungsteam auf jedenFallinScrumwahrnehmenmuss.

Arbeitsorganisation

1. Umsetzungsplan im Sprint Planning

erstellen

2. Organisation der Teamarbeit im Daily

Scrum3. PairProgrammingmitTeammitgliedern4. EinarbeitungneuerTeammitglieder

Technisch

5. Produktinkremente programmieren,

testenunddokumentieren

6. Automatisierte Tests (Unit Tests,Integrations-, Last-, Akzeptanztests)erstellenundkontinuierlichdurchführen

7. System- und Softwarearchitektur

erstellen

8. SoftwaretechnischerEntwurf9. AuswahlgeeigneterTechnologienfürdie

Umsetzung

10. Betrieb und Support der entwickeltenSoftware

BezogenaufStakeholder

11. Usability-Testsdurchführen12. UserAcceptanceTestsdurchführen13. Umgebung für Continuous Integration

aufsetzenundamLaufenhalten14. Produktinkremente im Sprint-Review

demonstrieren

15. UserExperiencegestalten16. Bugsbeseitigen

UnterstützungdesProductOwners

17. SchätzungdesProductBacklogs18. Den Product Owner bei der Konzeption

unterstützen.19. Zusammen mit dem Product Owner

Product Backlog Items erstellen und im

Refinementverfeinern

Verbesserung

20. Sich selbst bzw. Technologien, das

Vorgehen und die fachliche Domäne

weiterentwickeln

21. Zusammen mit dem Product Owner dieDefinitionofReadyformulieren

22. Zusammen mit dem Product Owner dieDefinitionofDoneformulieren

Daily Scrum n Ergebnis: Einsatzplanung für das Team für

denTagn Dauer:max.15Minuten(jedenWerktagzur

selbenUhrzeitamselbenOrt)n Teilnehmer: Entwicklungsteam und Scrum

Master; Product Owner optional;Stakeholder optional (Stakeholder dürfenzuhören,abernichtsprechen)

n Vorgehen (dieTeammitgliederbeantwortendreiFragen):• Washabeichgesternerledigt,dasmeinemEntwicklungsteam geholfen hat, dasSprint-Zielzuerreichen?

• Habe ich Hindernisse gesehen, die michoder das Entwicklungsteam daranhindern,dasSprint-Zielzuerreichen?

• Was werde ich heute erledigen, ummeinem Entwicklungsteam zu helfen, dasSprint-Zielzuerreichen?

n Empfehlungen:• Das Daily Scrum findet vor einemphysikalischenTaskboardstatt.

• Die ersten beiden der obigen Fragenwerden einzeln vondenTeammitgliedernbearbeitet.WenndiesebeidenFragenvonjedemTeammitgliedbeantwortetwurden,wirddiedritteFragegemeinsamimTeambeantwortet.

• Hindernisse,diedieWeiterarbeitaneinerUser Story oder einem Task blockieren,werden mit roten Haftnotizen direkt aufden zugehörigen User Stories bzw. Taskskenntlichgemacht.

• Andere Hindernisse werden in der NähedesTaskboardsvisualisiert.

Sprint Planning n Ergebnisse: selektierte Einträge aus dem

Product Backlog, Plan für die Umsetzung,Sprint-Ziel

n Dauer: maximal zwei Stunden pro Sprint-Woche (also vier Stunden für einenzweiwöchigenSprint)

n Teilnehmer: Product Owner, ScrumMaster,Entwicklungsteam, bei Bedarf eingeladeneFachexperten für spezifische anstehendeFachfragen

n Vorgehen:• Der Scrum Master fragt beimEntwicklungsteam die Anzahl der für denSprintverfügbarenPersonentageab.

Seite 15 von 21

• DerProductOwnerstelltseineIdeefüreinSprint-Ziel vor sowie die hochpriorisiertenUserStories.

• Der Scrum Master fragt dasEntwicklungsteam,obdieersteUserStoryin den Sprint passt. Beantwortet dasEntwicklungsteam die Frage positiv, fragtder Scrum Master, ob die zweite UserStoryzusätzlichindenSprintpasst.DiesesVerfahren wird so lange wiederholt, bisdas Team Zweifel hat, ob es noch mehrschaffenkann.

• JetztwirddasSprint-Zielüberarbeitetundfinalisiert. Der Product Owner schätzt ab,obderSprinteinenpositivenROI(Returnon Investment) hat, wenn die gewähltenUser Stories umgesetzt werden können.Wenn dies nicht der Fall ist, geht dasScrum-TeamzurückzumerstenSchritt.

• Dann wird der sogenannte Task-Breakdown durch das Entwicklungsteameingeleitet. Dazu werden Kleingruppenvon jeweils zwei bis drei Entwicklerngebildet.JedeKleingruppewählteinenTeilderUserStoriesausunderstelltdieTasksfürdieUmsetzung.

• Die erstelltenTaskswerden anschließendim Plenum vorgestellt, und es wirdFeedback eingesammelt. Gegebenenfallswird eine zweite RundeKleingruppenarbeitangeschlossen.

• Es wird auf Basis der erstellten Tasksgeprüft, obdie ausgewähltenUser Storiestatsächlich im Sprint umgesetzt werdenkönnen.

• Der Product Owner wird über dasErgebnis der Abschätzung informiert.Gegebenenfalls wird eine User Story ausdem Sprint Backlog entfernt oder eineweitere hinzugefügt. Wenn notwendig,wirddasSprint-Zielangepasst.

n Empfehlungen:• DerBeamerbleibtaus.DerProductOwnerbringtdieUserStoriesaufPapiermit.DieTaskswerdenebenfallsaufPapiererstellt.

• Der Product Owner bleibt während desTask-Breakdown imRaum. (Häufig tretenbei dieser Tätigkeit weitere fachlicheRückfragenauf.)

• Für die Tasks gilt die Regel, dass siemaximal einen Personentag an Aufwandgroß sein dürfen. Tasks müssen alsoentsprechendkleingestaltetsein.

• Mit so kleinen Tasks kann man für diefinale Abschätzung, ob man die UserStories im Sprint schaffen kann, einfachdieTaskszählenundmitdenverfügbarenPersonentagenimSprintvergleichen.

Sprint-Review n Ergebnisse: Klarheit darüber, was am

ProduktmithoherPrioritätnochzu tun ist;Änderungen am Product Backlog; ggf.FortschreibungdesReleaseplans

n Dauer: ca. eine Stunde pro Sprint-Woche(also zwei Stunden für einen zweiwöchigenSprint)

n Teilnehmer: Product Owner, Scrum Master(Moderation), Entwicklungsteam,Stakeholder (insbesondere Kunden undAnwender)

n Vorgehen:• Demonstration des Produktinkrementsdurch das Entwicklungsteam. DieDemonstration erfolgt auf einer vorhervereinbarten Test- undIntegrationsumgebung und nicht aufeinem Entwicklerrechner. Es darf nurgezeigtwerden,wasgemäßderDefinitionof Done komplett erledigt ist. Der ScrumMaster bestätigt, dass die Definition ofDoneeingehaltenwurde.

• Gegebenenfalls Akzeptanz der Featuresdurch den Product Owner (wenn nichtbereitsimSprinterfolgt)

• GegebenenfallsAktualisierungdesReleaseBurnupCharts(sieheunten)

• FeststellungdurchdenProductOwner,obbzw. inwieweit das Sprint-Ziel erreichtwurde

• Sammeln von Feedback zum Produkt;Festhalten des Feedbacks durch denProductOwner

• Feststellen, welches Feedback besondersdringlich ist. Anpassung des ProductBacklogs bezüglich dieses dringlichenFeedbacksdurchdenProductOwner

• Gegebenenfalls Anpassung desReleaseplans

n Empfehlungen:• Der Product Owner sorgt dafür, dass dierichtigen Stakeholder beim Sprint-Reviewanwesendsind.

• Die Demonstration desProduktinkrements basiert auf demSprint-ZielunderzählteineGeschichte,die

Seite 16 von 21

es den Stakeholdern erleichtert, dasGezeigte in einen geeigneten Kontext zusetzen.

• DerScrumMastersorgtdurchModerationdafür, dass die Stakeholder nützlichesFeedbackzumProduktgeben.

• Bei vielen Stakeholdern im Sprint-Reviewsorgt der Scrum Master durch geeigneteTechniken der GroßgruppenmoderationfürdieeffektiveDurchführungdesSprint-Reviews.

Sprint-Retrospektive n Ergebnisse: Verbesserungsmaßnahmen, die

das Entwicklungsteam im nächsten Sprintumsetzenwill

n Dauer:ca.eineStundeproSprintwoche(alsozwei Stunden für einen zweiwöchigenSprint)

n Teilnehmer: ScrumMaster (als Moderator),ProductOwner,Entwicklungsteam

n Vorgehen:• Set the stage: Der Scrum Master eröffnetdie Retrospektive und stellt eineArbeitsumgebung her, in der sich alleTeilnehmerengagierenmöchten.

• Gather data: Die Teilnehmer sammelnqualitative und quantitative Daten überdenletztenSprint.

• Generate insights: Die Teilnehmergewinnen Einsichten darüber, warumbestimmte positive oder negative Effekteaufgetretensind.

• Decide what to do: Die Teilnehmerentscheiden, was sie tun wollen, umnegative Effekte zu beseitigen oder zudämpfen und um positive Effekte zuverstärkenoderzuerhalten.

• Closing: Der Scrum Master beendet dieRetrospektive und sorgt dafür, dass sichjemandumdieErgebnissekümmert.

n Empfehlungen:• Es sollten nur wenige Maßnahmenvereinbart werden, die das Team auchrealistisch im nächsten Sprint umsetzenkann.

• Es sollte auch über Stimmungen undGefühlegesprochenwerden.

• Der ScrumMaster sollte die verwendetenTechnikenvariieren.

• Es sollte geprüft werden, ob dieMaßnahmen der letzten Retrospektive

umgesetztwurdenundwelcheEffektedieMaßnahmengezeigthaben.

Backlog Refinement n Ergebnisse: Product Backlog in einem

aktuellen,aufgeräumtenZustandn Dauer: ca. zwei Stunden pro Sprint-Woche

(häufigjedeWochezweiStundenamselbenWochentag zur selben Uhrzeit; z.B.donnerstags10–12Uhr).

n Teilnehmer: ScrumMaster (als Moderator),Product Owner, Entwicklungsteam,Fachexperten(aufEinladung)

n Vorgehen:• Entfernen obsoleter Einträge aus demProductBacklog

• HinzufügenneuerEinträge indasProductBacklog (Vorstellung der neuen EinträgedurchdenProductOwner)

• Schätzungder neuenEinträge imProductBacklog

• Neuschätzung der Einträge im ProductBacklog,dieeinerNeuschätzungbedürfen

• ÜberarbeitungderPriorisierung• Verfeinerung hoch priorisierter ProductBacklogItemsfürdienächsteneinbisdreiSprints (Product Backlog Items auf eineangemessene Größe aufteilen; fachlicheDetails klären; Akzeptanzkriterienergänzen)

n Empfehlungen:• Es handelt sich um einen Workshop, indem Product Owner undEntwicklungsteam gemeinsam dieVerantwortung für die Vorbereitung dernächstenSprintsübernehmen.

• DerBeamerbleibtaus.DerProductOwnerbringt die Product-Backlog-Einträge aufPapiermit.

• Beim Aufteilen von Product-Backlog-Einträgen arbeiten die Entwickler mit.Auch neue Product-Backlog-Einträgekönnen von den Entwicklern erstelltwerden.

• Akzeptanzkriterien werden gemeinsamzwischenProductOwnerundEntwicklernfestgelegt.

• Das Meeting ist optional und nicht injedem Kontext notwendig bzw. sinnvoll.Experimentieren Sie ggf. mitverschiedenenAnsätzen.

Seite 17 von 21

Release Planning n Ergebnisse: mit den Stakeholdern

abgestimmterReleaseplann Dauer:½bis1Tagn Teilnehmer: ScrumMaster (als Moderator),

Product Owner, Entwicklungsteam (oderTeiledavon),Stakeholder

n Vorgehen:• Vor dem Release-Planning wurde dasinitialeProductBacklogerstellt, geschätztundpriorisiert.

• Der Product Owner stellt dieProduktvisionvor.

• Der Product Owner stellt das priorisierteProductBacklogvor.

• Der Scrum Master oder dasEntwicklungsteam stellt dieEntwicklungsgeschwindigkeit (Velocity)vor.

• Der Product Owner legt Product BacklogItemsgrobaufdieZeitachse.

• Die daraus resultierenden Konsequenzenwerden gemeinsam diskutiert.Gegebenenfalls werden Änderungen anReleasedatum oder Product Backlogvorgenommen.

• Eswirdvereinbart,wiederProductOwnerdie Stakeholder über den Fortschritt imRelease und Änderungen am Releaseplaninformiert.

n Empfehlungen:• DerBeamerbleibtaus.• Das Meeting ist optional und nicht injedemKontextnotwendigbzw.sinnvoll.

Product Backlog n Zweck: Überblick über die noch

ausstehenden Eigenschaften/Features desProdukts

n Eigenschaften:• Einträge beschreiben das Was und nichtdasWie.

• Geordnet(inderRegelnachPriorität)• Hoch priorisierte Einträge sind klein unddetailliertausgearbeitet.

• NiedrigpriorisierteEinträgesindgroßundnurgrobskizziert.

• IstGeschätzt.• Transparent für das EntwicklungsteamunddieStakeholder

• Enthält nur die noch offenenEigenschaften/Features (und nicht diebereitsabgeschlossenen)

n Verwendung:• Ordnung/PriorisierungdurchdenProductOwner

• SchätzungdurchdasEntwicklungsteam• BasisfürReleaseplanungund–Controlling

n Empfehlungen:• DasProductBacklogexistiertphysikalisch(Karteikarten/HaftnotizenanderWand).

• Beschränkungaufmaximal70–80Einträgepro Release (noch besser: ein bis zweiDutzend)

• Unterscheidung in Einträge, die für dasaktuelle Release geplant sind und solchefürspäter(Ideen)

• User Stories und Epics als ProductBacklogs Items (wenn im Unternehmennicht bereits ein anderes gutfunktionierendesFormatetabliertist)

• GruppierungderEinträgenachThemen• Bugs, die nicht sofort beseitigt werden,werdeninsProductBacklogaufgenommenunddurchdenProductOwnerpriorisiert.

Sprint Backlog n Zweck: Überblick über die noch

ausstehendenArbeitenimSprintn Eigenschaften:

• Enthält die für den Sprint ausgewähltenProduct-Backlog-Einträge sowie den PlanfürdieUmsetzung

• Geordnet(inderRegelnachPriorität)• ZeigtdenZustandderPlanumsetzung.

n Verwendung:• Wird im Sprint Planning durch dasEntwicklungsteamerstellt.

• Aktualisierung durch dasEntwicklungsteamimDailyScrum

n Empfehlungen:• DasSprintBacklogexistiertphysikalischinForm eines Taskboards(Karteikarten/Haftnotizen an der Wand)imTeamraum.

• DieReihenfolgeaufdemTaskboardbildetdie Priorisierung der Product-Backlog-Einträgeab.

• Spalten:UserStory,ToDo,Doing,Done• DarstellungvonSprint-ZielundDefinitionofDoneaufdemTaskboard

Seite 18 von 21

• UserStoriesundTasksalsEinträge(wennimUnternehmennichtbereitseinanderesgutfunktionierendesFormatetabliertist)

• Eigene Zeile oben auf dem Taskboard fürungeplante Bugs, die noch im Sprinterledigtwerdenmüssen

Produktinkrement n Zweck:WertschöpfungfürdasUnternehmen

undden/dieKundenn Eigenschaften:

• Lieferbar (gemäßderDefinitionofDone),mindestens:

- funktionsfähig unterProduktionsbedingungen

- qualitätsgesichert- dokumentiert

n Verwendung:• Erstellung und Qualitätssicherung im

SprintdurchdasEntwicklungsteam• Demonstration im Sprint-Review auf

einer vorher vereinbarten Test- undIntegrationsumgebung, um FeedbackzumProduktzubekommen

n Empfehlungen:• Automatisierte Unit Tests und

Continuous Integration als InstrumentezurQualitätssicherung(inkl.Regression)

• Testgetriebene Entwicklung undRefactoring, um bei inkrementellerEntwicklung eine Erosion derEntwurfsqualitätzuvermeiden

• Notwendige Dokumentation über dieDefinitionofDonevereinbaren

Sprint Burndown Chart n Zweck: frühe Einschätzung der

Erfolgswahrscheinlichkeit des Sprints fürdasEntwicklungsteam

n Eigenschaften:• Prognostiziert den weiteren Fortschritt

imSprintaufBasisderbereits imSprinterledigtenArbeit.

• Visualisiert dazu bereits die im SprinterledigteArbeitunddenangenommenenFortschrittfürdenRestdesSprints.

• DieoptionaleIdealliniezeigtdenidealenArbeitsfortschritt, damit Abweichungenfrüh erkannt und diskutiert werdenkönnen.

n Verwendung:• Aktualisierung direkt vor oder im Daily

ScrumdurchdasEntwicklungsteam

• Betrachtung im Daily Scrum, um dasweitereVorgehenimSprintzuplanen

n Empfehlungen:• Handgezeichnet auf DIN A3 oder

Flipchart• HängtdirektnebendemTaskboard.• RestaufwandbasiertaufdenTasks(bzw.

dem Umsetzungsplan für die Product-Backlog-Einträge).

• RestaufwandermittelndurchZählenvonTasks (ohne denOverhead, Reststundenzuschätzen)

• FortgeschritteneTeams,diesehrwenigeProduct-Backlog-Einträge parallel inArbeit haben, können das SprintBurndown Chart auf Basis erledigterProduct-Backlog-Einträge (statt Tasks)führen.

• Das Sprint Burndown Chart ist einoptionales Artefakt. Es ist in langenSprints sehr nützlich und wenigernützlichinsehrkurzenSprints.

Release Burnup Chart n Zweck: frühe Einschätzung des Umfang des

Releases bzw. des Releasetermins für denProductOwnerunddieStakeholder

n Eigenschaften:• Prognostiziert den weiteren Fortschritt

im Release auf Basis der bereitserledigtenProduct-Backlog-Einträge.

• Visualisiert dazu bereits erledigteFeatures und den angenommenenFortschrittfürdenRestdesReleases.

• DieoptionaleIdealliniezeigtdenidealenArbeitsfortschritt, damit Abweichungenfrüh erkannt und diskutiert werdenkönnen.

n Verwendung:• AktualisierungimSprint-Review

Seite 19 von 21

• Betrachtung im Sprint-Review, um dasweitereVorgehenimReleasezuplanen

• Der Restaufwand basiert auf denSchätzungen des Product Backlogs (z.B.StoryPoints).

n Empfehlungen:• Handgezeichnet auf DIN A3 oder

Flipchart• Hängt direkt neben dem Product

Backlog.• Das Release Burnup Chart ist ein

optionales Artefakt. Es ist in langenReleases sehr nützlich und wenigernützlich in sehr kurzen Releases (undkomplett überflüssig beikontinuierlichenReleases).

Seite 20 von 21

Scrum einführen AgileEntwicklungerfordertveränderteVerhaltens-undDenkweisen bei allen Beteiligten. Nur die Scrum-Mechanikzuinstallieren,reichtalsonichtaus.

Die notwendigen Verhaltensänderungen lassen sichnicht über Anweisungen herbeiführen, wienebenstehende Abbildung zeigt. Jeder hat einWertesystem im Kopf. Ein Glaubenssatz könnte z.B.sein: „Vertrauen ist gut, Kontrolle ist besser.“ DiesesWertesystemprägtdas konkreteVerhalten, daswir andenTaglegen,z.B.„Hr.Müller,ichvertraueIhnendieseAufgabe an und möchte, dass sie mir morgen frühBerichtüberdenFortschritterstatten.“DiesesVerhaltenerzeugt im gegebenen Kontext bestimmte Reaktionenund Ergebnisse und prägt damit die Erfahrungen, diewirmachen.SoerfahrenwirvielleichtamnächstenTag,dassHr.MüllermitderihmanvertrautenAufgabenochnicht mal angefangen hat. Diese Erfahrungen wirkenzurück auf unser Wertesystem („Gut, dass ichkontrolliert habe.“). In der Regel haben sich Zyklenentwickeln, in denen sich Werte und Erfahrungengegenseitig verstärken („Nächstes Mal kontrolliere ichambestenhalbtäglich.“).

Die neuen Verhaltensweisen müssen schrittweiseerlernt werden. Ein verändertes Verhalten erzeugteandere Erfahrungen und schließlich ändert sich unserWertesystemimKopf.

Werschonmalversuchthat,abzunehmenodermitdemRauchenaufzuhören,weiß,wieschweresist,angelernteVerhaltensweisen abzulegen. So geraten wir immerwiederinSituationen, indenenwirunswiderbesseresWissen unpassend verhalten. Und selbst wennwir diegewünschteVerhaltensweiseineinerSchulungeingeübthaben, fallen wir in Stress-Situationen häufig wiederzurückinalteVerhaltensmuster.

Coaching(durchdenScrumMasterodereinenexternenScrum-Coach) hilft dabei, Verhalten nachhaltig zuändern. Dazu muss der Coach verstehen, was agileEntwicklung wirklich bedeutet und dazu muss er esbereits praktiziert haben – ansonsten hat der denProzess der Verhaltensänderung selbst noch nichtdurchlaufen.

Für eine erfolgreiche Scrum-Einführungmuss also dasWissen vermittelt und Verhaltensweisen geändertwerden. Eine Kombination aus Schulungen undCoachingistunabdingbar.

Seite 21 von 21

Unterstützung durch it-agile Wir freuen uns, wenn Sie unsere Unterstützung inAnspruch nehmen. Unsere (festangestellte) Berater-Gemeinschaft kumuliert mehrere hundert JahreErfahrung mit agilen Transitionen: Wir haben kleinenUnternehmen mit nur einem Team geholfen, agiler zuwerden und Transitionen mit mehreren tausendMitarbeitern begleitet (wir stellen Ihnen konkreteFallbeispielegerneimpersönlichenGesprächvor).

Dabei beschränkt sich unser Unterstützungsangebotnicht auf die IT oder einzelne Teams. Umden größtenVorteilausagilenAnsätzenzuziehen,solltediegesamteWertschöpfung betrachtet und ganzheitlich optimiertwerden.WirbeziehendaherdieverschiedenenFacettendes Unternehmens und der Wertschöpfung in unsereBeratungundunserCoachingmitein.

Nehmen Sie gerne Kontaktmitunsauf:

StefanRoock

Tel.0172/4297617

[email protected]

http://www.it-agile.de