© CGI Group Inc. 2013
Agile Testing in der Praxis
Paradigmenwechsel als Game Changer
Ein Praxisbericht über einen kompletten Schwenk in der Prozessorganisation eines
Testprojektes.
Markus Schell (CGI), Nadja Brendel (Daimler AG) 27.01.2016
2
Agenda
Vorstellung
Bestimmung der Ausgangssituation
Daraus resultierende Probleme
Wir ändern die Spielregeln > Jetzt agil
Was bei einer Einführung zu beachten ist
Fazit
1
2
3
4
5
6
Nadja Brendel
Projekterfahrung
• Daimler AG
• Tätigkeiten:
• Entwicklung von effizienten Softwareentwicklung-Vorgehensmodellen gemäß
Projekt-Rahmenbedingungen
• Requirements Engineering und Requirements Management in IT-Großprojekten
• RE-Methodenberatung in IT-Großprojekten
• Business Consulting und Business Process-Optimierung
• Ansprechpartner für Requirements Engineering und Management in Agilen
Projekten inkl. Atlassian Toolchain JIRA and Confluence
• Product Owner in Agilen Projekten
Ausbildung Rolle Zertifizierungen
Product Owner
Schwerpunkte
RE und RM -
Beratung in Agilen
Projekten
Rolle Product
Owner für MB
Retailer Website
Dipl. Informatiker (FH)
Software Engineering Certified Requirements Engineer
SOA-Analyst
Professional Product Manager
Certified ITM Business Consultant
Certified Product Owner
Markus Schell
Projekterfahrung
• Kunden: Automobilbranche
• Tätigkeiten:
• Testmanagement und Testkoordination (Onside, Nearshore und Offshore)
• Beratend in den Initialisierungsphasen von agilen Projekten für das Setup der
Werkzeuge und Prozesse sowie Tätigkeiten als agiler Tester.
• Ansprechpartner für Testwerkzeuge HP Quality Center und Atlassian JIRA und
deren professionelle Projekteinführen.
• Qualitätsmanagement (QS-Prüfung interner Dokumente anhand von QS-
Checklisten, Audits/Reviews beauftragen)
• Assessments zum Software-Entwicklungsprozess und dessen Verbesserung in
einer gesamtheitlichen Betrachtung.
Ausbildung Rolle Zertifizierungen
Dipl.-Ing. (FH)
Elektrotechnik
Test Manager
Schwerpunkte
• Test
Management
• Agile Testing
• Testwerkzeuge
HP QC und
Atlassian JIRA
• Quality
Management
• Change-
Request
Management
ISQi Certified Agile Tester
ISTQB CTAL Testmanager
ISTQB Certified Tester Foundation Level
PRINCE 2 Foundation
ITIL V3 Foundation
Hamburg
Bremen
Düsseldorf
Leinfelden-
Echterdingen
München
Karlsruhe
Darmstadt
Köln
Frankfurt/
Sulzbach
Mannheim
Hannover Berlin
Erfurt
Ganz nah und weltweit geschätzt Unsere Kompetenz vor Ort
5
Führend in Deutschland*
Business Innovation/Transformation Partner
(Lünendonk, 2013)
Anbieter für Application Management
(PAC, 2013)
IT-Dienstleister im Telekommunkationssektor
(PAC, 2013)
Global gelistet*
Magic Quadrant for Application Testing
Services, Worldwide (Gartner, 2014)
Forrester Wave™: Enterprise Mobility
Services (Forrester, 2013)
Führender Anbieter für Smart Grids
(IDC, 2013)
Top Arbeitgeber
2.300 Mitarbeiter
13 Standorte
* Auszug: CGI-Ranking 2013/2014
6
Wie alles begann - Bestimmung der
Ausgangssituation
7
Projekt und seine Ziele
Projekt
CMS Adobe Day CQ 5.5 als Plattform der
Mercedes-Benz Internetpräsenz und besteht
aus 2 Teilprojekten:
1. Vollständige Neuentwicklung der Händler-
webseiten.
2. Migration der bestehenden Händlerdaten
Ziele (technische und fachliche)
• Konfigurieren statt programmieren
• Inhalte auf Interessen der Händlernutzer
zuschneiden
• Überleitung von Händler auf Produkt-
informationen
Ausgangssituation
8
Projekt und seine Ziele
Projekt
Das Projekt soll das neue strategische CMS Adobe
Day CQ 5.5 als Plattform der Mercedes-Benz
Internetpräsenz bereitstellen und besteht aus 2 Teil-
projekten:
1. Die vollständige Neuentwicklung der Händler-
webseiten.
2. Ein Migrationsprojekt der bestehenden CMS
Anwendung und des bestehenden, bereinigten
Contents (Händlerdaten) auf das neue
strategische CMS.
Ziele (technische und fachliche)
• Es gilt “konfigurieren statt programmieren”
• Den Händler sichtbarer zu machen
• Inhalte auf Interessen der Händlernutzer
zuschneiden
• Überleitung von Händler auf Produktinformationen
Ausgangssituation
9
Basis für die Umsetzung
In einer vorgelagerten Phase wurden unter
Berücksichtigung des Status Quo der aktuellen
Lösung, Studien, Befragungen Online Trends eine
Analyse durchgeführt.
Daraus wurde das Grobkonzept durch eine Web-
Agentur erstellt welches schlussendlich die
Grundlage für das Pflichtenheft war.
Der Aufbau der Webseiten erfolgt hierarchisch und
modular nach CQ5 Standard. Dabei entstehen
vielschichtige Abhängigkeiten, die nicht einfach zu
verstehen sind.
Basis
10
Projektplanung – ist alles einkalkuliert?
Juli August Jan Feb März April Mai Juni Sept
2013
• Feinspezifikation
Entwicklung (CGI)
• Systemdesign
• Entwicklung
Stages
• Testfallerstellung
Test (CGI)
• Funktionale Tests
• DEV-Umgebung
Systemtest (Daimler)
• INT-Umgebung
• Abnahme Fachbereich
01
Abnahme (Daimler)
02 03 04
QG Req
01 02 03 04
01 02 03 04
QG Design
• Abnahme Tester
QG Go Live
QG Real
GoLive Termin
Deployment Meilenstein
Feinspezifikation
Testfallerstellung
Kalibrierung
GoLive
Termin
11
Projektplanung – Folgende Probleme konnten
nicht eingebplant werden … Rahmen für die Planung bildeten die vorgegeben Meilensteine
01 : Feinspezifikation - Theoretisch abgeschlossen
• Sprechen denn alle Beteiligten die gleiche Sprache oder
• werden x-Abstimmungsrunden notwendig sein?
• weiß jeder wie die Anforderungen zu definieren sind?
02 : Testfallerstellung • Einarbeitung : Wie schnell kann Tester sich einarbeiten ? (fachlich/ technisch) ?
• Nicht bekannt : Anzahl Testfälle und zeitlicher Aufwand
• TCs CGI <> TCs Daimler => zu unterschiedlich => lange Diskussionen
03 : Kalibrierung • Reicht die Zeit alleine für die Fehlerbehebung?
• Was passiert wenn Änderungen gefordert werden?
04 : Meilenstein GoLive • Vorgegebener Fertigstellungstermin (MUSS Termin)
• Reicht das enges Zeitkorsett?
12
Projektplanung – ist alles einkalkuliert?
Juli August Jan Feb März April Mai Juni Sept
2013
• Feinspezifikation
Entwicklung (CGI)
• Systemdesign
• Entwicklung
Stages
• Testfallerstellung
Test (CGI)
• Funktionale Tests
• DEV-Umgebung
Systemtest (Daimler)
• INT-Umgebung
• Abnahme Fachbereich
IT 01
Abnahme (Daimler)
IT 02 IT 03 IT 04
QG Req
IT 01 IT 02 IT 03 IT 04
IT 01 IT 02 IT 03 IT 04
QG Design
• Abnahme Tester
QG Go Live
QG Real
GoLive Termin
Kalibrierung
SW-Iterationen
Deployment Meilenstein
Feinspezifikation:
• Theoretisch abgeschlossen
• Weiß jeder wie Anforderungen zu
beschreiben sind?
• Sprechen alle Beteiligten die gleiche
Sprache?
Testfallerstellung:
• Einarbeitungszeit der Tester?
• Überarbeitungen eingeplant?
• Testfälle CGI und Daimler
unterschiedlich =>
Abstimmung nicht eingeplant.
Kalibrierung:
• Wie hoch ist die erwartete
offene Fehleranzahl ?
• Fixer Endtermin
• Reicht das enge Zeitkorsett?
GoLive Termin: • Nur theoretische zeitliche
Planung bis zum MUSS
Termin
• Reicht das enge Zeitkorsett?
13
Oje… das war anders geplant !
14
Probleme tauchen auf
• Abhängigkeiten ziehen sich über mehrere Iterationen.
• Änderungen werden in nachfolgenden Iterationen nicht
berücksichtig.
Auswirkung auf Entwicklung und Test
• Umgesetzte Anforderungen werden nicht mehr benötigt -
Neue sind plötzlich ein „Muss“.
• Nachträgliche Anpassung von Schnittstellen notwendig.
Anforderungen werden ständig überarbeitet
• Geblockte Ressourcen wegen permanenter
Auswertungen und Neuplanungen.
• Eingangskriterien für die Abnahme werden nie erreicht.
Testteam steht ständig unter Druck
Templates,
Komponenten und
Schnittstellen zu
Drittsystemen.
Abhängigkeiten
Nicht geplante
verlängerte
Projektlaufzeit.
Projektlaufzeit
Fehlerraten steigen
pro Iteration stetig an.
Testdurchführung
15
Probleme tauchen auf
Abhängigkeiten – Auswirkungen auf TEST : • Kein VOLLSTÄNDIGER TEST innerhalb einer Iteration möglich
• Keine BERÜCKSICHTUNG der Änderung in nachfolgenden Iterationen.
Projektlaufzeit – Änderung der Anforderungen : • Abnahmetests auf VERALTETEN Anforderungen
• Entwicklung & Test halten mit Anforderungsänderungen nicht mehr
Schritt.
• ANPASSUNG der SCHNITTSTELLEN wegen bereits neuerer
produktiver Releases (wegen fortgeschrittenem Zeitplan)
Testdurchführung – Änderung der Anforderungen : • Abnahmetests auf VERALTETEN Anforderungen > Anzahl Fehler steigt
• EINGANGSKRITERIEN (max. Fehleranzahl) für Abnahme NIE erreicht.
16
Probleme tauchen auf
• Abhängigkeiten ziehen sich über mehrere Iterationen Kein vollständiger
Test innerhalb einer Iteration möglich.
• Änderungen werden in nachfolgenden Iterationen nicht berücksichtig.
• Abnahmetests werden auf veralteten Anforderungen durchgeführt.
Auswirkung auf Entwicklung und Test
• Umgesetzte Anforderungen werden nicht mehr benötigt, Neue sind plötzlich
ein Muss.
• Entwicklung + Test halten mit Anforderungsänderungen nicht mehr Schritt.
• Schnittstellenänderungen wegen neuer Releases von Drittsystemen.
Anforderungen werden ständig überarbeitet
• Permanente Auswertungen und Neuplanungen binden die Ressource TM
• Neu Priorisierung von Fehlern, damit diese schneller behoben werden.
• Geforderte Eingangskriterien an max. Fehleranzahl für die Abnahme wird
nie erreicht.
Testteam steht ständig unter Druck
Templates, Komponenten
und Schnittstellen zu
Drittsystemen.
Abhängigkeiten
Nicht geplante längere
Projektlaufzeit.
Projektlaufzeit
Fehlerraten steigen pro
Iteration stetig an.
Testdurchführung
17
Willkommen im Hamsterrad
Iteration
01
Daimler Test Systemtest auf Staging-Umgebungen,
Fehler werden protokolliert.
3
Status Test / Abnahme Rückmeldung der Fehler an CGI,
Unzufrieden mit spezifizierten Funktionen => CRs
4
CGI Test Testfallerstellung, Testen,
nur Prio 1 Fehler werden gefixt
2 Projektplanung Basis sind die neuen KPIs aus
CGI Test und Daimler Test.
Nachjustierung
5
Iterative Implementierung Anforderungen als Basis
+ Fehler CGI + Fehler
Daimler + CR
+ Systemänderung
1 Go Live Termin Kommunikation an die Märkte
Neuer Termin wird
kommuniziert
Weiterer Termin wird
kommuniziert
6
Iteration
02
Iteration
03
Iteration
04
18
Willkommen im Hamsterrad
Daimler Test Systemtest der gelieferten Iteration auf
unterschiedlichen Umgebungen, Fehler
werden protokolliert.
3
Status Test / Abnahme Rückmeldung der Fehler an CGI (Anzahl
abnahmeverhindernder Fehler), Fehlerbehebung
muss eingeplant werden, Unzufrieden mit
spezifizierten Funktionen => CRs
4
CGI Test Testfallerstellung, Abgleich mit
Spezifikation, Testen, Fehler
protokollieren, nur Prio 1 Fehler werden
gefixt, Übergabe an Daimler Test
2 Projektplanung Basis sind die neuen KPIs aus CGI Test
und Daimler Test.
Nachjustierung
5
Iterative Implementierung Basis ist die Anforderung
+ Fehler CGI + Fehler Daimler + CR
+ Systemänderung
1 Go Live Termin Kommunikation an die Märkte
Neuer Termin wird kommuniziert
Weiterer Termin wird kommuniziert
6
Kreislauf wurde fundiert und intensiv gelebt, dauerte aber länger als es im Projekt geplant war
und es wurden zusätzliche Iterationen eingefügt um die Probleme in den Griff zu bekommen
ÄNDERUNGSBEDARF!
Iteration
01 - n
19
Wir ändern jetzt die Spielregeln
20
Neues Spiel – neues Glück?
Alle am Softwareprozess beteiligten Rollen
arbeiten gemeinsam an der Spezifikation.
Jetzt im agilen Vorgehen
Vom Managen von Fehlern machen wir den
Sprung zu einem lösungsorientierten Ansatz.
Bereits in der User-Story berücksichtigt
Keine Nachforderungen - sind Akzeptanz-
kriterien erfüllt, gilt der Sprint als erfolgreich!
Aufwendige Abnahmeprozeduren entfallen
Kunde verantwortlich für Akzeptanzkriterien
• Getrenntes Team für
Anforderung
• Entwicklung und Test
sind „außen vor“.
Anforderungen
• Ausführlichste KPIs
• aufwendige Planung
• “Jemand“ hat Fehler
gemacht.
Test
• Diskussionen bei
Abnahme
• Fachbereich bekommt
mit Zeitverzug die
Funktion
Abnahme
21
Neues Spiel – neues Glück?
Anforderungen – jetzt Agil:
• Bewusstsein für die Stabilität der Software (per Negativ-Testfälle durch
Tester) wird bei Entwicklern gestärkt.
• Schnelle Klärung: bei Bedarf erfolgt zum nächsten Refinement eine
Rückmeldung vom Kunden.
Test – Bereits berücksichtig in Story:
• Test entlang der Akzeptanzkriterien:
Der Kunde zeigt bereits was im wichtig ist (Fachabteilung, nicht
Testabteilung)
Fokus der Tests auf die Hauptfunktionalität.
Abnahme – Kunde verantwortlich für Akzeptanzkriterien:
• Sprint Review : Fachabteilung wird sofort die umgesetzte
Funktionalität. – inkl. offener Fehler präsentiert > offener Umgang !
22
Neues Spiel bei der Anforderung und
Entwicklung
Spezifikation
• Eigenständiges Team spezifiziert mit
Anforderungsteam des Kunden. Entwicklung
und Test sind „außen vor“.
• Lange Entscheidungswege bei Detailfragen.
• Fehler in Spezifikation werden durch Test
nicht aufgedeckt.
Entwicklung
• Entwickler sind in die Fachlichkeit nicht
involviert.
• Technische Probleme lassen sich nicht oder
nur schwer durch Spezifikationsänderungen
umgehen.
Wasserfall
Spezifikation
• Anforderunten werden in den Refinements
gemeinsam innerhalb des Scrum Team und
mit dem Product Owner besprochen.
• Schnelle Klärung: bei Klärungsbedarf erfolgt
zum nächsten Refinement eine Rückmeldung
vom Kunden.
Entwicklung
• Bewusstsein für die Stabilität der Software
(per Negativ-Testfälle durch Tester) wird bei
Entwicklern gestärkt.
• Technische Probleme werden früh
berücksichtigt.
Agile (Scrum)
Alle am Softwareprozess beteiligten Rollen arbeiten gemeinsam an der Spezifikation Alle am Softwareprozess beteiligten Rollen arbeiten
gemeinsam an der Spezifikation.
23
Neues Spiel im Test
Testmanagement
• Ausführlichste KPIs über:
• Testfallerstellung, -durchführung und
dessen Status.
• Fehler (interne und die des Kunden)
werden wöchentlich bis täglich
berichtet.
• Zeitaufwendige Steuerung der Tester
(Projektpläne, Abstimmung mit den
Schnittstellen)
• Negativ behaftet: “Jemand hat Fehler
gemacht”.
Wasserfall
Testen
• Keine KPIs mehr:
• Testfälle werden zu eigenen Sub-Story
Items und durchlaufen die Lines des
Scrum Boards.
• Fehler werden nur dokumentiert (im
Story Item) wenn sie nicht innerhalb
eines Tages behoben werden können.
• Das Team steuert sich selbst.
• Besseres Verständnis für die Technik und
Fachlichkeit.
• Test entlang der vom Kunden geforderten
Akzeptanzkriterien. Das gesamte Team ist
verantwortlich für die Qualität.
Agile (Scrum)
Vom managen von Fehlern machen wir den Sprung zu einem
lösungsorientierten Ansatz.
24
Neues Spiel für die Abnahme
Auslieferung
• Nach Auslieferung an Kunde und Staging-
Prozess bekommt Fachabteilung die
Umsetzung mit erheblichem Zeitverzug.
Abnahmekriterien
• Diskussion über die Abnahmekriterien.
• Fachabteilung hat nun doch andere
Vorstellungen oder nachträgliche
Änderungen werden gewünscht => dadurch
wird häufig die Abnahme verweigert.
Wasserfall
Auslieferung
• Während Sprint Review ist die Fachabteilung
vor Ort und sieht sofort die umgesetzte
Funktionalität.
Abnahmekriterien
• Bereits in der Story müssen die
Akzeptanzkriterien dokumentiert werden
(diese sind im Detail VOR der Umsetzung zu
dokumentieren).
• Nachforderungen gehen in neue Stories ein.
Agile (Scrum)
Keine Nachforderungen - sind Akzeptanzkriterien erfüllt, gilt der
Sprint als erfolgreich! Aufwendige Abnahmeprozeduren entfallen.
25
Und nun?
26
CGI : Mindset Change und in der Organisation
• Testmanager: bisher gemanagt – jetzt nur noch
coachende Rolle !
• Tester: bisher passive Rolle -> jetzt aktive Rolle
Eine Kopfsache !
• Das Team muss Verantwortung übernehmen (für
Schätzung, Planung, Lieferung und Eskalationen)
• Steuerung wird ins Team übertragen !
Was krempeln wir intern um?
• Extreme (introvertiert <> extrovertiert) vermeiden.
• Ausgebildete und erfahrene Tester einsetzen.
Mit Bedacht zusammenstellen
“Alte” Denkmuster bei
Testmanager & Tester
Neues Mindset
Projektmanager
steuerte und plante
die Aufgaben /
Releases.
Organisation
• Soft skills
• Hard Facts
Neues Team
27
CGI : Mindset Change und in der Organisation
NEUES MINDSET – Eine Kopfsache: • Klare Meilensteine wie Ready to Test, Release-Liefertermin mit denen
Tester planen nicht mehr existent.
Organisation – Was krempeln wir um ?
• Eskalationen werden direkt mit dem Kunden besprochen.
• Jetzt muss das Team Verantwortung (für Schätzung, Planung und
Lieferung) übernehmen.
Neues Team:
• KOMMUNIKATION ist elementar wichtig (DoD, Schätzen, Infos
einholen)
• „ALTE GEDIENTE“ haben Schwierigkeiten mit der neuen
Vorgehensweise.
28
CGI : Mindset Change und in der Organisation
Testmanager: bisher: Steuerung der Tester und Planung der Tests , jetzt : Test Lead,
unterstützt mit seinem Wissen die Anforderung, Entwicklung und Test.
Tester: bisher: Klare Meilensteine wie Ready to Test, Release-Liefertermin mit denen Tester
planen, jetzt:
Eine Kopfsache !
• Bisher hatte das Team keine Aufgaben im Management. Jetzt muss das
Team Verantwortung (für Schätzung, Planung und Lieferung) übernehmen.
• Eskalationen werden direkt mit dem Kunden besprochen.
• Steuerung wird ins Team übertragen !
Was krempeln wir intern um?
• Extreme (introvertiert <> extrovertiert) sind zu vermeiden.
• Kommunikation ist elementar wichtig (DoD, Schätzen, Infos einholen)
• „Alt Gediente“ haben Schwierigkeiten mit der neuen Vorgehensweise.
• Ausgebildete und erfahrene Tester einsetzen.
Mit Bedacht zusammenstellen
“Altes” Denkmuster bei
• Testmanager und der
• Disziplin der Tester
Neues Mindset
Die Projektleitung hatte bisher
die Aufgabe der Schätzung,
Planung, Steuerung und
Eskalation mit dem Kunden.
Organisation
• Soft skills
• Hard Facts
Neues Team
29
Kundenseite : Notwendige Änderungen
• kein “bis zum Zeitpunkt x erwarten wir die Funktionen A, B & C”.
• Wichtigkeit gemessen an Leitfragen - nicht an Kosten.
• „Finished is better than Perfect“
Erwartungshaltung Kunde
• Management überträgt Entscheidungskompetenz an PO
• Sauber definierte Anforderungen müssen im Refinement direkt
entschieden und dokumentiert werden.
• Betrieb muss alle 2 Wochen deployen können.
Die Gesamtkette muss funktionieren
• Vertrauen in eine bestimmte Person haben
• Kommunikation ist elementar wichtig (DoD, Schätzen, Infos
einholen)
• Ausgebildete und erfahrene Tester einsetzen.
Das Scrum Team mit Bedacht zusammenstellen
“Altes” Denkmuster:
• alles ist wichtig und
• Basis der Umsetzung
sind EUROS
Neues Mindset
• > Management
• > Anforderungen
• > Testen
• > Betrieb
Organisationskette
• Soft Skills
• Hard Facts
Neues Team
30
Kundenseite : Notwendige Änderungen
• kein “bis zum Zeitpunkt x erwarten wir die Funktionen A, B und C” mehr.
direktes Ranking der Funktionen nach Wichtigkeit
• Wichtigkeit gemessen an Leitfragen nicht an Kosten
• „Finished is better than Perfect“
Erwartungshaltung Kunde
• Management überträgt Entscheidungskompetenz an den Product Owner
• Sauber definierte Anforderungen müssen im Refinement direkt entschieden und
dokumentiert werden
• Tests müssen parallel eingeplant werden
• Betrieb muss in die Lage versetzt werden alle 2 Wochen zu deployen
Die Gesamtkette muss funktionieren
• Vertrauen in eine bestimmte Person haben
• Extreme (introvertiert <> extrovertiert) sind zu vermeiden.
• Kommunikation ist elementar wichtig (DoD, Schätzen, Infos einholen)
• „Alte Hasen“ haben Schwierigkeiten mit der neuen Vorgehensweise.
• Ausgebildete und erfahrene Tester einsetzen.
Das Scrum Team mit Bedacht zusammenstellen
Altes” Denkmuster:
• Viele Themen (Funktionen,
Änderungen, Fehler) waren wichtig
• Auf Basis von EURO wurde
entschieden was umgesetzt wird
Neues Mindset
• Management
• Anforderungen
• Testen
• Betrieb
Organisationskette
• Soft Skills
• Hard Facts
Neues Team
31
Benefit des Game Changers
Funktionalität &
Business Value (stehen im Vordergrund)
Fokus liegt auf der
Funktionalität.
Lösungsorientierter
Ansatz.
Jedes Add-On wird
hinterfragt: Bringt
es einen Mehrwert
für den Business
Value?
Schnelle
Reaktionszeit (auf Produktprobleme)
Der Fokus liegt auf
Problemlösungen.
Es erfolgt eine
dynamische
Anpassung der
Wichtigkeiten von
Items.
CRs intensiv
durchdacht (liefert Fachabteilung)
Welche Items sind
wichtiger?
Kann etwas
zurückgestellt
werden?
Funktioniert es
nicht einfacher?
Gemeinsames
Verständnis (von Kunde & Lieferant)
Das neue
Vorgehen fördert
ein besseres
gemeinsames
Verständnis.
Technische und
fachliche
Notwendigkeiten
werden im Dialog
ausgetauscht.
Team rückt
zusammen (Spez., Dev., Test)
Verständnis für die
Arbeitsweise und
Probleme der
jeweils anderen
Rolle wird
gefördert.
32
Sie wollen in Zukunft agil vorgehen ?
Behutsam mit EINER Änderung beginnen – in der
folgenden Reihenfolge:
N Team aufbauen und schulen 1
Neues Vorgehen etablieren 2
Einarbeitung in die Fachlichkeit 3
Gleichzeitige Einführung alle 3 Änderungen =>
Verständnis, dass die ersten Sprints nicht geschafft
werden!
33
Sie wollen in Zukunft agil vorgehen ?
Dann muss man sich von alten Gewohnheiten trennen,
neue Wege erkunden und immer wieder überprüfen, wie
man sich noch weiter verbessern kann.
34
Sie wollen in Zukunft agil vorgehen ?
Dann beginnen Sie behutsam und führen Sie am Anfang nur
eine neue Änderung ein. Überprüfen Sie danach immer wieder
wie weit Sie mit dieser Änderung kommen.
Ne Team aufbauen und schulen 1
Ne Neues Vorgehen etablieren 2
Ne Einarbeitung in die Fachlichkeit 3
Sollten alle 3 Veränderungen gleichzeitig eingeführt werden, ist
Verständnis für die ersten Sprints notwendig, dass diese
vermutlich nicht wie geplant geschafft werden können.
35
36
Die wichtigste Person in Scrum ist der
Product Owner.
Nicht die Methoden scheitern, sondern
das Mindset (weil die Menschen es
nicht wollen).
“Management of Change” ist kein
Selbstläufer.
37
FAZIT
Wichtigste Person, mit der Scrum steht und fällt :
Product Owner
Benötig „Standing“ im Unternehmen => kein PL darf
„dazwischenfunkten“ und den Prozess ändern oder eigene ihm wichtige
Themen hochpriorisieren
Nicht die Methoden scheitern
„Ich habe immer so gearbeitet“,
„Warum soll ich mich auch noch um die anderen und deren Probleme
kümmern?“
Management of Change :
Die Menschen müssen immer wieder eingeschworen werden :
durch einfaches TUN – und nicht ewig vorher planen und
konzeptionieren.
38
Die wichtigste Person in Scrum ist der Product Owner:
Benötig „Standing“ im Unternehmen => kein Projektleiter darf
„dazwischenfunken“ und den Prozess ändern oder eigene ihm
wichtige Themen hochpriorisieren.
Nicht die Methoden scheitern, sondern das Mindset (weil die
Menschen es nicht wollen):
„Ich habe immer so gearbeitet“, „Warum soll ich mich auch noch um
die anderen und deren Probleme kümmern?“
“Management of Change” ist kein Selbstläufer:
Die Menschen müssen immer wieder eingeschworen werden: durch
einfaches TUN – und nicht ewig vorher planen und konzeptionieren.
Vielen Dank.
40
Wir stehen zum
Gespräch für Sie
zur Verfügung!
Markus Schell
Senior Consultant
Mobile: +49 170 579 1369
E-Mail: [email protected]
41
Backup - Abhängigkeiten
42
Herausforderung auch in agilen Projekten
Wie gehen wir mit nicht agilen Projektteilen um, wie z.B.:
• Regressionstests?
• Spezialisten sind erforderlich (nicht über das Scrum
Team zu stemmen) diese zu erstellen.
• Eine permanente Pflege ist notwendig.
• Performance- oder Lasttests ? Sie machen nur Sinn:
• wenn diese auf fast vollständig entwickelten Systemen
durchgeführt werden, oder
• wenn sie auf produktionsnahen Umgebungen
durchgeführt werden.
Ein Versuch, diese Probleme in den agilen Prozess zu integrieren wird als
Hardening Iteration (nach iSQI - CAT) beschrieben.
ABER: man verlässt den Scrum Prozess und damit die Fundamentals.
