Download - swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Transcript
Page 1: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

Requirements

Testing

Inn

ovat

ion

& C

hang

e

AcademyHandbuch 2020

Kursangebote mit Mehrwert

Page 2: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Inhalt

02

Über SwissQ

■ Weiterkommen mit der SwissQ Academy / Service Profil 05

■ Vorteile der SwissQ Kurse / Schulungspartner & Partnerprogramme 06

■ Academy Dozenten 08

■ Voucher System / Workshops 10

Kursangebote Agile 14

■ Agile Essentials (AE) 17

■ Agile Experience (AX) 17

■ Scrum Kickstarter (SKS) 20

■ Kanban Kickstarter (KKS) 20

■ Professional Scrum Master I (PSM) 21

■ SAFe® Scrum Master (SSM) 21

■ Agile Facilitation (AF) 22

■ Wirkungsvolle Retrospektiven (WR) 22

■ Professional Scrum Product Owner I (PSPO) 24

■ SAFe® Product Owner / Product Manager (POPM) 24

■ SAFe® for Teams (SFT) 25

■ Scrum mit Hermes (SH) 25

■ Professional Scrum Developer (PSD) 27

■ Agile Leadership (AL) 27

■ Leading SAFe® (SAFE)  30

■ Lean Portfolio Management (LPM) 30

■ Agile Workshops (AWS) 31

Kursangebote Requirements 34

■ IREB® CPRE Foundation Level (IREBFL) 37

■ Design Thinking (DETHI) 37

■ Digitale Produkte und Datenschutz (DSG) 40

■ UX / Usability Power Kurs (UURE) 40

■ RE Power Kurs (REP) 41

■ IREB® CPRE Advanced Level – Elicitation (ALEC) 41

■ IREB® CPRE RE@Agile Primer (IREBAP) 44

■ IREB® Advanced Level – RE@Agile (IREBALAG) 44

Inh

alt

Page 3: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

03

Inhalt

■ Agile Product Management (APM) 45

■ iSQI® Certified Agile Business Analysis (CABA) 45

■ IQBBA® Certified Foundation Level – Business Analyst (IQBBA FL) 48

■ Geschäftsprozesse analysieren (GPA) 48

■ Requirements Workshops (RWS) 49

Kursangebote Testing 50

■ ISTQB® Certified Tester Foundation Level (CTFL) 52

■ ISTQB® Agile Tester (CTAT) 52

■ ISTQB® Advanced Level – Test Manager (ALTM) 53

■ Agiles Testmanagement (ATMA) 53

■ ISTQB® Advanced Level – Test Analyst (ALTA) 56

■ Testdesign Power Kurs (TDES) 56

■ ISTQB® Usability Tester Foundation Level (CTUT) 57

■ Test Automation Insights (BPTA) 57

■ Performance Testing Insights (BPTI) 60

■ ISTQB® Advanced Level – Technical Test Analyst (ALTTA) 60

■ ISTQB® Advanced Level – Test Automation Engineer (ALTAE) 61

■ DevOps® Foundation (DOFL) 61

■ DevOps® Test Engineer (DOTE) 62

■ Testing Workshops (TWS) 62

Kursangebote Innovation & Change 66

■ Search Inside Yourself (SIY) 68

■ Lean Change Agent Workshop (LCA) 68

■ Selbstorganisierte Organisationen (SOR) 69

■ Collaboration & Communication (COCO) 69

■ Erfolgreiche Kommunikation im Team (EKT) 72

■ Out-of-the-Box Thinking (OOBTH) 72

■ Visual Facilitation (VF) 73

■ LEGO® Serious Play® Intro (LSP) 73

■ Team-Retrospektive (TR) 74

■ Lean IT Foundation (LIT) 74

Page 4: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

4

Page 5: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

05

Über SwissQ

Weiterkommen mit der SwissQ Academy

Bei unseren Mitarbeitenden setzen wir auf ein fundiertes, interdisziplänes Methoden-wissen, gepaart mit der Fähigkeit dieses in der Praxis pragmatisch und erfolgreich umzu-setzen. Dieses Credo wenden wir auch in unseren Kursen an. Unsere Referenten wenden das Wissen welches sie weitergeben tagtäglich in den Mandanten an und können daher die Theorie mit konkreten Beispielen aus der Praxis anreichern. Offenbar mit Erfolg, führen wir doch pro Jahr über 150 Kurse mit 1200 Teilnehmenden durch, sowohl öffent-lich wie auch firmenintern. Während die Zertifikatskurse streng nach den Vorgaben der jeweiligen Organisationen wie ISTQB®, IREB® und SAFe® erfolgen, können wir bei unseren eigenen Kursen auf Ihre Bedürfnisse eingehen und die Schwerpunkte individuell legen.

Ein grosses Thema ist und bleibt die Art wie wir Produkte und Dienstleistungen ent-werfen und bauen. Die Welt verändert sich, alles wird agiler. Doch was bedeutet «agil»? Das Verständnis darüber geht weit auseinander, oft sogar im gleichen Team. Ist es «nur» eine Methode, eine andere Denkweise oder eine neue Organisationsform? Damit Sie nicht aneinander vorbeireden oder gar in verschiedene Richtungen gehen, macht es Sinn Team und Stakeholder ins (gleiche) Boot zu holen. Unsere Weiterbildungen helfen dabei eine gemeinsame Sprache zu sprechen und sich das notwendige Rüstzeug anzueignen um einen grossen Schritt weiter in die richtige Richtung zu tun.

Dazu gehören nicht nur die agilen Prinzipien und Methoden. Auch ISTQB® und IREB® haben das Thema längst aufgegriffen und bieten Zertifikate für Agile Testing und Agile RE. Es gibt somit keine Ausreden, nicht auf dem neusten Stand zu sein. Und wenn die Umsetzung dennoch ins Stocken gerät, sind wir gern als Ihr Coaching Partner mit unseren Consultants an Ihrer Seite. Gemeinsam sind wir stark und bringen Sie ans Ziel!

Wir danken Ihnen für Ihre Treue und bleiben auch im 2020 mit einem aktuellen Academy-Angebot am Ball.

Ihre SwissQ AcademySilvio Moser (CTO) & Anja van Ackern (Training Manager)

Service Profil

Silvio Moser

[email protected]

Anja van Ackern

[email protected]

Community Events, Trends & Benchmarks, Stärkung der Berufsbilder

Consulting Agile Methoden und Management Kompetenz, Übernahme

von Test und RE Aufgaben, Assessment und Coaching

Academy Aus- und Weiterbildung, öffentlich und inhouse

Konferenzen Organisation von

Konferenzen

Page 6: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

06

Vorteile der SwissQ Kurse

Kurse der SwissQ Academy stehen für:

■ Verständliche Vermittlung von praxisrelevantem Wissen

■ Optimale Vorbereitung von Zertifizierungen (ISTQB® / IREB® / SCRUM / SAFe® / iSQI®)

■ Effektive Umsetzung des Gelernten in die Praxis

■ Kundenspezifische Anpassungen bei Firmenkursen möglich

■ Durchführung Firmenkurse grösstenteils auch auf Englisch möglich

Diese Ziele erreichen wir mit unseren erfahrenen Dozenten. SwissQ setzt ausschliesslich Trainer mit jahrelanger Projekterfahrung ein, welche täglich bei Mandanten im Einsatz sind. Somit kann die Brücke zwischen theoretischem Grundwissen und dessen Umsetzung im Alltag erfolgreich geschlagen werden.

Schulungspartner & Partnerprogramme

2020

Recognized Training Provider

2020

Page 7: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

07

Über SwissQ

Page 8: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

08

Academy Dozenten – Die Quelle unseres Wissens

Stephan Adler Ivan Aloisio

Peter Erne Ueli HartmannAdrian Häfeli

Armin Born Patrick Bucheli

Paul Boekhout

Beat Bourquin

Page 9: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

09

Über SwissQ

Dieter Prohammer

Chris WolfBjörn Schuster

Marcel Ruetschi

Janine Karbulka Kastriot Krasniqi Katarina Kubisova

Marcel Stoop

Katrin Lüthi

Page 10: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

10

Mit SwissQ weiterkommen

Bei uns kannst du …

Wir suchen lebenslang lernende, methodisch sattelfeste, pragmatisch umsetzende, Wissen weitergebende Persönlichkeiten. Oder solche, die es werden wollen.

dich kontinuierlich in unseren Disziplinen weiterbilden oder selber als Referent tätig sein

dich mit der Community an unseren Konferenzen und Events vernetzen

dein Fach- und Branchenwissen erweitern und span-nende Projekte bei unseren Kunden vorantreiben

dich mit deinen Kollegen austauschenund Spass haben!

Mehr zu uns und unseren Stellen

findest du auf:

www.SwissQ.it/KarriereZürich

SwissQ Consulting AGFraumünsterstrasse 16CH-8001 Zürich

Tel. +41 43 288 88 40

Bern

SwissQ Consulting AGSpitalgasse 37CH-3011 Bern

Tel. +41 31 972 73 53 SwissQ.it

Voucher System

SwissQ bietet mit dem Voucher-System attraktive Konditionen für die Teilnahme an öffentlichen Kursen. Das Prinzip bietet Ihnen die Möglichkeit, mehrere Kurstage in einem Paket zu kaufen und dadurch von Ermässigungen zu profitieren.

Staffelungen:

■ 25 Kurstage Schulungs-Voucher 25 5 %

■ 50 Kurstage Schulungs-Voucher 50 10 %

■ 100 Kurstage Schulungs-Voucher 100 20 %

Alle Kurse werden auch als Inhouse Kurse angeboten. Bitte kontaktieren Sie uns für eine Offerte: [email protected]

Workshops

Im Rahmen der von unseren erfahrenen Experten und Coaches geführten firmen-internen Workshops können Sie Themen erarbeiten und reflektieren. Unsere Moderatoren sorgen nicht nur für einen reibungslosen Ablauf, sondern bringen auch ihre methodische Expertise und breite Praxiserfahrung ein. Ausgangslage, Vorgehen und Ziele werden im Voraus in einem gemeinsamen Briefing besprochen. So werden Sie bei der Erreichung der Ziele des Workshops optimal unterstützt.

Nebst den hier im Handbuch aufgeführten Workshops sind auch weitere Themen und Formate möglich. Rufen Sie uns einfach unverbindlich an oder schicken Sie uns eine eMail mit Ihren Anforderungen.

Sie finden die Workshops jeweils am Ende der Kursangebote Agile, Requirements und Testing. Alle Workshops werden in Deutsch und Englisch abgehalten, die Dauer variiert je nach Thematik.

Staffelungen:

■ Erweiterter Lerneffekt durch direkten Einsatz des Gelernten im täglichen Arbeitsumfeld

■ Zielgeführte Massnahmen für Learning by doing

■ Optimierung des expliziten Wissens im Unternehmen durch gemeinsames Erarbeiten des Wis-sens

■ Befähigung der Mitarbeiter, Projektaufgaben selbstständig umzusetzen

■ Ein gemeinsames einheitliches Verständnis erarbeiten

Page 11: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

11

Über SwissQ

Mit SwissQ weiterkommen

Bei uns kannst du …

Wir suchen lebenslang lernende, methodisch sattelfeste, pragmatisch umsetzende, Wissen weitergebende Persönlichkeiten. Oder solche, die es werden wollen.

dich kontinuierlich in unseren Disziplinen weiterbilden oder selber als Referent tätig sein

dich mit der Community an unseren Konferenzen und Events vernetzen

dein Fach- und Branchenwissen erweitern und span-nende Projekte bei unseren Kunden vorantreiben

dich mit deinen Kollegen austauschenund Spass haben!

Mehr zu uns und unseren Stellen

findest du auf:

www.SwissQ.it/KarriereZürich

SwissQ Consulting AGFraumünsterstrasse 16CH-8001 Zürich

Tel. +41 43 288 88 40

Bern

SwissQ Consulting AGSpitalgasse 37CH-3011 Bern

Tel. +41 31 972 73 53 SwissQ.it

Page 12: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

12

businessagility day

businessagility day

21. Oktober 2020

24. Juni 2020

18. März 2020

November 2020

Europa

März April Mai Juni Juli August September Oktober November Dezember

Juni 2020

APAC

Januar Februar

Page 13: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

13

Über SwissQ

businessagility day

businessagility day

21. Oktober 2020

24. Juni 2020

18. März 2020

November 2020

Europa

März April Mai Juni Juli August September Oktober November Dezember

Juni 2020

APAC

Januar Februar

Page 14: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

14

Kursangebote

Inhalt

■ Agile Essentials (AE) 17

■ Agile Experience (AX) 17

■ Scrum Kickstarter (SKS) 20

■ Kanban Kickstarter (KKS) 20

■ Professional Scrum Master I (PSM) 21

■ SAFe® Scrum Master (SSM) 21

■ Agile Facilitation (AF) 22

■ Wirkungsvolle Retrospektiven (WR) 22

■ Professional Scrum Product Owner I (PSPO) 24

■ SAFe® Product Owner / Product Manager (POPM) 24

■ SAFe® for Teams (SFT) 25

■ Scrum mit Hermes (SH) 25

■ Professional Scrum Developer (PSD) 27

■ Agile Leadership (AL) 27

■ Leading SAFe® (SAFE)  30

■ Lean Portfolio Management (LPM) 30

■ Agile Workshops (AWS) 31

Agile

Page 15: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

15

Agile

Page 16: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

16

Page 17: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

17

Agile

Kurzbeschreibung

Agilität ist ein Schlagwort, das heute in aller Munde ist. Was steckt hinter dem Hype? Warum entstanden diese Methoden und warum sind sie so erfolgreich? Welche Prinzipien stecken dahinter? Wo eignet sich welches Modell und warum? Nach dem Kurs haben Sie selber anhand von Übungen und Spielen erfahren, wie Agilität den Business Value steigert, die Time-to-Market verkürzt, die Effizienz und Qualität steigert und das Mitarbeiterengagement erhöht. Sie kennen die gängigsten agilen Organisationsformen und wie man basierend auf ökonomischen Prinzipien Prioritäten setzt. Sie verstehen gängige Lean und Agile Begriffe, wie WIP-Limiten, Batch Sizes, Flow, Waste, User Stories, Story Points, Retrospektiven und vieles mehr.

Dieser Kurs richtet sich an Personen, welche Agilität zusammen-hängend verstehen möchten. Er vermittelt die Lean und Agile Prinzipien und das nötige Basiswissen, um agile Initiativen im Unternehmen zu unterstützen oder weiterzubringen.

Der Kurs lässt sich hervorragend mit einem Agile Workshop zu Ihrer spezifischen Fragestellung kombinieren.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: AX

Kurzbeschreibung

Agilität ist ein Schlagwort, das heute in aller Munde ist. Was steckt hinter dem Hype? Warum entstanden diese Methoden und warum sind sie so erfolgreich? Welche Prinzipien stecken dahinter? Wo eignet sich welches Modell und warum? Was verändert sich bei der Einführung von Agilität? Nach dem Kurs verstehen Sie die Prinzipien hinter Lean und Agile und wie diese helfen, bessere Resultate zu erzielen. Zudem können Sie beurteilen wann und wo ein agiler Ansatz zielführend ist und warum kontinuierliche Verbesserung ein Schlüssel zum Erfolg ist.

Dieser Kurs richtet sich an Personen, welche Agilität zusammen-hängend verstehen möchten. Er vermittelt die Lean und Agile Prinzipien und das nötige Basiswissen, um agile Initiativen im Unternehmen zu unterstützen oder weiterzubringen.

Der Kurs lässt sich hervorragend mit einem Agile Workshop zu Ihrer spezifischen Fragestellung kombinieren.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: AE

NEU Agile Experience (AX)

Inhalt

■ Die Grundlagen: Lean & agile Prinzipien

■ Wertfokus: Weshalb Value wichtiger ist als Vorhersagbarkeit

■ Wichtige agile Frameworks, z.B. Scrum und Kanban

■ Konzepte wie Flow und WIP-Limit selber erleben

■ Agile Praktiken selber ausprobieren (z.B. Schätzpoker, Retrospektive)

Agile Essentials (AE)

Inhalt

■ Die Grundlagen: Lean & agile Prinzipien

■ Kurzübersicht über die wichtigsten Frameworks Scrum und Kanban

■ Konzepte wie Flow und WIP-Limit selber erleben

Page 18: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

18

The Good, the Bad and the Ugly of Agile – oder die Wahrheit über AgilitätAgilität als solches (basierend auf dem Agilen Manifest) wird diesen Monat volljährig. Vor dem Agilen Manifest wurden verschiedenste agile Ansätze (XP, Crystal, verschiedene Vorgänger von Scrum) bereits 10 Jahre lang angewandt. Zeit ein kleines Fazit zu ziehen.

«Es geht darum den Benutzer zu verzücken»

The GoodKundenfokus – der Kunde steht im Mittelpunkt

Mit der Agilität kamen einige gute Aspekte. Der Fokus für das Entwicklungsteam änderte sich. Weg vom reinen Liefern der spezifizierten Funktionalität hin zur Lieferung echten Mehrwerts für den Benutzer der Software. War vorher in traditionellen Softwareentwicklungsvorhaben die Einhaltung von Zeit, Budget und besonders Scope zentral, geht es heute eher darum heraus-zufinden, was dem Benutzer wirklich einen Mehrwert bringt. Dieser wird geliefert und erneut wird geprüft, was als nächstes den meisten Mehrwert bringt. Es geht darum den Benutzer zu verzücken (How to make the whole organization agile?).

«Weg von den Ideen der Industrialisierung und hin zur Wissensarbeit»

Natürlich kann argumentiert werden, dass diese Veränderung nicht (alleine) aus der Agilität kam. Sondern die Art und Weise wie viele Firmen funktionieren, hat sich geändert: weg von den Ideen der Industrialisierung und hin zur Wissensarbeit.

«Einzelne, kleine, agile Teams liefern direkten Kundennutzen»

Ein anderer positiver Aspekt, den die Agilität mit sich brachte, war die Rückbesinnung auf einzelne, kleine, schlagkräftige Teams. Diese vereinen alle Eigenschaften, um ein Produkt von der Idee bis zur Optimierung für den Benutzer umzusetzen. Dies erfordert, dass das Team über die benötigten Skills verfügt, oft als «interdisziplinäres Team» oder auch «cross-funktionales Team» bezeichnet.

Interdisziplinäre Teams sind jedoch auch nur dann erfolg-reicher, wenn man ihnen den nötigen Freiraum lässt die

optimale Lösung für ein Kundenproblem zu finden und liefern zu können. Ein entsprechender gestalterischer Freiraum wird den agilen Teams gegeben. Da die Teams direkt im Kontakt mit dem Benutzer stehen, können sie aus erster Hand Feedback darüber erhalten, wie gut oder schlecht die gelieferte Lösung das ursprüngliche Problem löst und entsprechende Anpassungen vornehmen.

Dies alles ist jedoch nur möglich, weil nicht länger in langen Release-Zyklen, sondern möglichst früh und möglichst oft aus-geliefert wird. Somit besteht die Möglichkeit häufig Feedback von echten Benutzer zu sammeln. Das agile Team nähert sich schrittweise der optimalen Lösung und liefert kontinuierlich Mehrwert an den Benutzer.

The BadBei einem Fazit – und besonders bei einem das ein «voll-jähriges» Konstrukt betrachtet – sollten auch die negativen Aspekte berücksichtigt werden. Auch diese sind vorhanden bei der Auseinandersetzung mit Agilität.

Viele (besonders grössere) Firmen haben Mühe mit der Umstellung auf agile Entwicklung. Deshalb werden oft die bestehenden Frameworks zusammengestrichen und bestehende Methoden mit aufgenommen, bis das agile Framework recht schnell dem bisherigen Vorgehen ähnelt. Die Begründungen reichen dabei von kreativ bis skurril. «Wir sind in einem regulierten Markt, wir müssen das so machen», «wir machen das schon seit Jahren so und es funktioniert für uns», «das kann bei uns nicht funktionieren, wir sind anders als xyz», …

Happy Birthday Agilität

Page 19: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

19

Blog

«… das kann bei uns nicht funktionieren, wir sind anders …»

Die meisten Unternehmen, die diese oder ähnliche Aussagen treffen, haben oft nicht einmal die grundlegenden Ideen des Agile Manifesto verstanden.

Vielleicht aus diesem Grund (und dem Grund, dass das Agile Ma-nifesto eben doch recht viel offen lässt) kommen fast monatlich neue Frameworks oder Varianten von agilen Frameworks «auf den Markt». Das hat zur Folge, dass sich schlussendlich jeder irgendwo wiederfinden kann ohne sich gross ändern zu müssen.

Dieser Trend ist besonders dort auffällig, wo meist grössere Firmen ihre über die Jahre gewachsene und auf möglichst effizienten Betrieb optimierten Plattformen und Applikationen agil weiterentwickeln oder erneuern wollen. Die meisten gehen davon aus, dass die neue Version ähnlich aussehen muss wie die alte und somit mindestens so gross und kompliziert werden muss. Also braucht man auch viele Mitarbeiter dafür. Diese dann noch einigermassen koordinieren zu können ist mit der ursprünglichen Idee von kleinen, selbständigen Teams nicht möglich. Wahrscheinlich haben sich aus diesem Grund die Frameworks für die Skalierung von Agilität in den grösseren Firmen besonders durchgesetzt.

«Wir wählen das Framework, das ‹am besten zu uns passt› (bei dem wir uns am wenigsten ändern müssen)»

Somit steht noch mehr Auswahl zur Verfügung; vielleicht zu viel. Häufig wird das Framework gewählt, in dem sich das Unter- nehmen zum aktuellen Zeitpunkt am ehesten wiederfindet.

Bei Einführung eines agilen Frameworks in einem Unternehmen über die Teamebene hinaus, konzentriert sich der Fokus oft auf den Prozess. Zusätzlich wird hoher Aufwand für die folgenden zwei Punkte betrieben:

■ Offene Fragen müssen vor Anwendung des Frameworks beantwortet sein.

■ Es muss sichergestellt sein, sich bis ins kleinste Detail genau daran zu halten.

Es werden die entsprechenden Prozesse definiert und eine mehr oder weniger dazu passende Governance erstellt. Man tauscht den einen (traditionellen) Prozess gegen den nächsten (agilen) Prozess ein.

«Eintauschen des traditionellen Prozesses gegen den ‹agilen Prozess›»

Die Erfahrung zeigt, dass die Adaption von agilen Vorgehens- weisen auf Teamebene gut umsetzbar ist, solange die nötige Unterstützung und der Wille in der Organisation vorhanden ist. Die Adaption von Agilität oberhalb der Teamebene erweist sich als um einiges schwieriger. Die Praxis zeigt eine (wieder) zu starke Fokussierung auf die Prozesse, zumindest in den traditionellen Firmen.

The UglyJa, leider gibt es bei diesem Fazit auch einen unschönen Teil, der aus der Agilität resultiert.

Unternehmen investieren viel Zeit und grosse Anstrengungen um Agilität einzuführen. Dabei geht der Fokus von Agilität verloren: Den Kunden in den Mittelpunkt zu stellen. Der ur-sprüngliche positive Aspekt wird zugunsten von «wie Agilität geht», also dem Prozess, wieder vernachlässigt.

«Von der Kundenorientierung zurück zur Prozessorientierung?»

Ein anderer unschöner Teil der Agilität ist, wie vorher schon angesprochen, die Skalierung. Die Art und Weise wie ver- schiedene Skalierungs-Frameworks in den Unternehmen eingeführt werden, unterstützt die traditionelle Command and Control Struktur der Unternehmung. Die Intelligenz und Innovationskraft der Mitarbeiter wird dabei oft unterdrückt oder vergessen. Das Bestreben, doch den einen Prozess für die ganze Firma definieren zu wollen ist wichtiger, als dass der Benutzer der einzelnen Produkte zufrieden oder sogar entzückt ist. Auch hier beschäftigt sich das Unternehmen wieder mehr mit sich selbst, als mit dem Kunden.

FazitNachdem Agilität nun «volljährig» wird, ist es vielleicht so langsam an der Zeit, sich auf die echten Werte dahinter zu- rückzubesinnen. Den Fokus auf den Kunden legen und diesen verzücken. Um dies vollständig zu erreichen, ist es ebenfalls an der Zeit, Agilität ein für alle Mal aus der (verstaubten) IT-Ecke zu holen und in der gesamten Firma zu leben.

«Ihren Weg Dinge zu tun…»

Was haben die folgenden Firmen gemein: Google, Amazon, Zara, Zappos, Netflix, Spotify? Keine dieser Firmen würde sagen, dass sie dieses oder jenes Agile Framework verwenden. Sie verwenden «ihren Weg, Dinge zu tun».

Agilität heisst also nicht, das nächste Framework einzuführen, sondern einen Weg zu finden, als Unternehmen so agil zu wer-den, dass man seine Kunden immer wieder aufs neue entzücken kann. Darauf sollten wir uns fokussieren!

Björn Schuster, Senior Consultant

Page 20: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

20

Kurzbeschreibung

Dieser Workshop bietet Starthilfe für den Einsatz von Kanban, für Teams und deren Stakeholder. Sie können ohne grosse Einstiegshürde das Einmaleins der Methodik auf praxis-orientierte und spielerische Weise kennenlernen. Kernstück bildet dabei die Kanban Simulation mit einem Brettspiel, gefolgt von einer Good Practices Session in der Ihre Fragen und offenen Punkte beantwortet werden.

Sie können am nächsten Tag mit einer einfachen Kanban Implementation beginnen. Für eine weitergehende Vertiefung der Methodik empfehlen wir unser «on-the-job» Coaching, z.B. für den Aufbau des Backlog, dessen Priorisierung, die Verbesserung des Prozesses (Flow, WIP-Limiten, Service-Klassen, Swim Lanes, ...), und so weiter.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: KKS

Kurzbeschreibung

Dieser Workshop bietet Starthilfe für den Einsatz von Scrum, für Teams und deren Stakeholder. Sie können ohne grosse Ein-stiegshürde das Einmaleins der Methodik auf praxisorientierte und spielerische Weise kennenlernen. Kernstück bildet dabei die Scrum Simulation mit LEGO, gefolgt von einer Good Practices Session in der Ihre Fragen und offenen Punkte beantwortet werden.

Sie können am nächsten Tag mit einer einfachen Scrum Implementation beginnen. Für eine weitergehende Vertiefung der Methodik empfehlen wir unser «on-the-job» Coaching, z.B. für den Aufbau des Backlog, dessen Priorisierung, die Durchführung der Zeremonien, den Umgang mit Impediments,und so weiter.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: SKS

Kanban Kickstarter (KKS)

Inhalt

■ Kurze Einführung in Kanban

■ Kanban Simulation mit Brettspiel

■ Austausch von Good Practices

Scrum Kickstarter (SKS)

Inhalt

■ Kurze Einführung in Scrum

■ Scrum Simulation mit LEGO

■ Austausch von Good Practices

Page 21: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

21

Agile

ZERTIFIZIERUNGZERTIFIZIERUNG

Kurzbeschreibung

Sie lernen alle Aspekte der Rolle eines Scrum Masters in einem SAFe®-Umfeld kennen. Im Gegensatz zum traditionellen Scrum Master Training, das sich auf die Grundlagen von Scrum auf Team-Ebene konzentriert, beleuchtet der SAFe® Scrum Master- Kurs die Rolle des Scrum Masters im Kontext eines Lean-Agile Unternehmens. Es bereitet Sie darauf vor, das SAFe® Program Increment (PI) erfolgreich zu planen und durchzuführen. Dazu gehört das Erlernen der Schlüsselkomponenten von skalierter Agilität, die Einbettung von Scrum im gesamten Unternehmen und die Planen und Durchführen der Iterationen. Sie werden auch erfahren, wie sie schlagkräftige Agile Teams aufbauen können, indem sie als «Servant Leader» und Coach agieren.

Die Teilnahme am Kurs bereitet Sie auf die Prüfung und die Zertifizierung zum SAFe® Scrum Master (SSM) vor.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: SSM

Kurzbeschreibung

Der Scrum Master ist für das Verständnis und die Durchführung von Scrum in seinem Team verantwortlich, er ist ein «Servant Leader». Er sorgt dafür, dass das Scrum Team die Theorie von Scrum kennt und die Praktiken und Regeln einhält. Ausserdem hilft er denjenigen, die kein Teil des Scrum Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team hilfreich sind und welche nicht. Der Scrum Master hilft dabei, die Zusammenarbeit so zu optimieren, dass der durch das Scrum Team generierte Wert maximiert wird.

In diesem Kurs lernen Sie, wieso sich Scrum für die Produkt-Entwicklung, z.B. in der IT, eignet, was den agilen vom klassischen Ansatz unterscheidet und mit welchen Regeln und Praktiken es in der Praxis funktioniert. Weiter behandelt der Kurs die Frage, mit welchen Veränderungen Sie im Team und im Umfeld rechnen müssen, wenn Sie Scrum einsetzen.

Der Kurs dient zur Vorbereitung auf die Zertifizierung als «Professional Scrum Master» (scrum.org).

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: PSM

SAFe® Scrum Master (SSM)

Inhalt

■ Einführung von Scrum in SAFe®

■ Rolle des Scrum Master

■ PI Planning erleben

■ Unterstützen der Ausführung von Iterationen

■ PI abschliessen

■ Coaching des Agile Teams

Professional Scrum Master I (PSM)

Inhalt

■ Scrum Framework: alle Regeln, Zeremonien, Rollen und Artefakte als konsistentes System, entlang dem Scrum Guide als Referenz.

■ Scrum-Theorie und Prinzipien: die empirische Prozesstheorie als Basis, ausgehend von der Annahme, dass Software-Entwicklung ein komplexer, kreativer Prozess ist.

■ Scrum Team: das agile Team, das aus Product Owner, Scrum Master und Development Team besteht.

■ Coaching und Facilitation: der Scrum Master als «Servant Leader» für das Team, den Product Owner und die Gesamtorganisation.

■ Skalierung: Team-Effektivität steigern durch Vermeiden von Ausschuss und Vereinfachungen.

Page 22: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

22

Kurzbeschreibung

Sie und Ihre Mitarbeitenden haben erste Erfahrungen mit Retrospektiven gemacht und haben die positiven Wirkungen schätzen gelernt. Aber es gibt nichts, was nicht noch verbessert werden könnte. Deshalb möchten Sie die Erfahrungen aus Ihrer Organisation sammeln, von den Erfahrungen Anderer profitieren und neue Impulse für Verbesserungen bekommen. Unter der Leitung eines erfahrenen Moderators führen Sie eine «Retro- spektive zu Retrospektiven» durch und reflektieren die gemachten Erfahrungen vor dem Hintergrund firmenexterner Good Practices.

Nach diesem Workshop haben Sie gemeinsam im Team firmen-spezifische, frische Ideen erarbeitet, wie sich Ihre Teams mit Hilfe wirkungsvoller Retrospektiven noch rascher verbessern können. Vorausgesetzt werden eigene Erfahrungen und Frage-stellungen zum Thema Retrospektiven.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: WR

Kurzbeschreibung

Was macht gute Zusammenarbeit aus? Offene Kommunikation, ein klares Ziel, gemeinsame Werte und Regeln, ein gewisses Mass an Unterschieden, Vertrauen, Wertschätzung, Fachkenntnisse - was noch? Agile Teams leben dafür, in einer dynamischen Umgebung maximalen Wert zu liefern und sich selbst kontinuierlich zu verbes-sern. Damit der Prozess zielgerichtet bleibt und aus Dynamik nicht Chaos wird, werden agile Teams meist von einem Facilitator beglei-tet, in Scrum vom Scrum Master. Er ist u.a. der Hüter des Prozesses und hilft dem Team, sich und die Zusammenarbeit mit der Um-gebung zu verbessern. Dieser Kurs richtet sich an Personen, welche ihre Erfahrungen als Facilitator und Team Coach reflektieren und ihr Methodenrepertoire erweitern möchten. Die Teilnehmenden klären Zusammenhänge und Erfolgsfaktoren erfolgreicher Teamarbeit, erweitern ihr Wissen über Modelle, Methoden und Tools in den Be-reichen Moderation, Coaching, kontinuierliche Weiterentwicklung und Kommunikation und sammeln neue praktische Erfahrungen. Ausserdem reflektieren sie ihre möglichen Rollen als Facilitator und können sich situationsgerecht verhalten, um ihr Team wirkungs-voll weiterzubringen. Erhalten Sie neue Inputs für Teambildung und Problemlösungstechniken, tauschen Sie sich mit Ihren Kollegen aus und nehmen Sie Ihren massgeschneiderten Aktionsplan zur An-wendung auf Ihren Kontext mit nach Hause.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: AF

Wirkungsvolle Retrospektiven (WR)

Inhalt

■ Retrospektiven als Werkzeuge für kontinuierliche Verbesserung

■ Analyse der bisherigen Vorgehensweise hinsichtlich Retrospektiven

■ die Rolle des Moderators

■ Ansätze für Retrospektiven

■ Praktische Tipps

Agile Facilitation (AF)

Inhalt

■ Rollen-Repertoire und Haltung des Facilitators unter Berücksichtigung des Kontexts (z.B. Team-Entwicklungsphasen, Einzel- vs. Multipersonen-Setting)

■ Agile Zeremonien begleiten

■ Selbstorganisation ermöglichen und fördern

■ Problemlösungs- und Entscheidungsfindungstechniken

■ Agile Teams aufbauen (Faktoren einer optimalen Zusammensetzung)

■ Spezialfokus: Remote Teams

■ Erstellen eines persönlichen Aktionsplans

Page 23: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

23

Agile

Retrospektiven – zurück zum ZweckBeobachten, messen, reflektieren und daraus lernen gehören für Teams, die nach agilen Prinzipien arbeiten, zur täglichen Routine. Sie stellen damit sicher, dass sich ihr Produkt wie auch ihre Zusammenarbeit laufend an eine sich ändernde Umwelt anpassen. Stolz auf das entstehende Produkt und das Team und dennoch unermüdlich auf der Suche nach Verbesserungen. Ein bekanntes Element des Verbesserungszyklus sind die Retro-spektiven. Populär wurden sie mit Scrum. Dort sind sie eines der offiziellen Ereignisse, durchzuführen an jedem Sprint-Ende. Aber auch in vielen anderen Teams haben sich Retrospektiven etabliert.

Das Teamwork reflektieren – In Retrospektiven geht es nicht um das Resultat der Arbeit, das Produkt, sondern um die Team-Zu-sammenarbeit. Typischerweise werden in einer Retrospektive folgende Fragen gestellt: Was ist in letzter Zeit geschehen? Welche positiven und negativen Ereignisse und Zustände sind eingetre-ten? Weshalb haben wir dies beobachtet? Was wollen wir un-bedingt beibehalten od. sogar noch verbessern, was müssen wir korrigieren? Wie wollen wir es verändern? Daraus sollten einige wenige Massnahmen entstehen, die das Team im nächsten Sprint umzusetzen vermag, oder Anpassungen an den Teamregeln, zu denen sich das Team verpflichtet.

Die Realität hält sich nicht immer an die Theorie – Eine der Her-ausforderungen bei der Einführung von Retrospektiven ist immer wieder deren Häufigkeit. Arbeitet das Team in zweiwöchigen Sprints, finden die Retrospektiven alle zwei Wochen statt. Kaum ist eine Team-Reflexion vorüber, steht schon die nächste vor der Tür. Und damit ist der Scrum-Master (der «Moderator») gefordert, ein passendes – inspirierendes – Format zu kreieren. Es gibt hier-für jede Menge Tipps & Tricks, gute Bücher und zahllose Blogs im Netz. Bewährt hat sich ein Ablauf mit fünf Schritten, basierend auf dem Buch «Agile Retrospectives: Making good teams great» von Derby/Larsen. Passt das in jedem Fall? Meine Erfahrung lehrt mich etwas Anderes. Der Scrum-Guide legt ein starkes Gewicht auf die Verbesserung der Entwicklungsprozesse und Werkzeuge – aber nicht nur. Ganz prominent werden die Beteiligten und ihre Beziehungen erwähnt. Und interessanterweise kommen gerade diese weichen Faktoren bei standardisierten Agenden zu kurz. Wieso? Es gibt unterschiedlichste Team-Konstellationen, Reifegra-de, spezifische Herausforderungen und Persönlichkeiten in Teams und deren Umfeld. Längst nicht alle Teams sind neu zusammen-gesetzt und entwickeln gemeinsam Software. Immer wieder begleite ich «untypische» agile Teams, z.B. Teams, die seit langem zusammen arbeiten, einfach bisher nicht agil und die vielleicht erstmals in kurzen Sprints vorgehen. Oder Teams, die keine SW entwickeln, aber dennoch die Transparenz und Resultate kurzer Zyklen schätzen. Häufig in traditionell strukturierten Umfeldern, vielfach auch mit Spezialisten die nur zu 40% mitarbeiten.

Mit Offenheit und Kreativität zurück zum Zweck – Retrospektiven mit strukturiertem Ablauf und klarem Fokus auf eine kurze Liste

von Massnahmen sind toll, wenn die Mehrheit der Teilnehmer ihren Wert schätzen. Das eigentliche Ziel ist immer, die Zusam-menarbeit im Team zu verbessern. Punkt. Langjährige Teams die recht offen über ihre Themen sprechen können, empfinden rigide Agenden oft unnatürlich oder das Kosten/Nutzen-Verhält-nis als gering. Entsprechend gerät die ganze Praktik in Misskredit. Andererseits schätzen sie es, einmal eine Plattform zu haben, um darüber zu sprechen, was sie gerade beschäftigt, ohne fixe Agenda. Und da haben kreative Ideen Platz. Wie wäre es, das Meeting ins Freie zu verlegen, oder das Team auf einen Spazier-gang mitzunehmen? Zum Beispiel mit dem Auftrag zu zweit oder zu dritt etwas übereinander zu lernen, ein (früheres) Hobby, seine Familie oder einen Lebenstraum. Oder ein bestimmtes Teamthema zu beleuchten. Da kommt häufig Überraschendes zum Vorschein. Zurück im Teamraum werden ggf. die Erkenntnisse gesammelt oder die Erkenntnisse einfach stehen gelassen. Auch ein Lean Coffee eignet sich als offenes Format, evtl. ergänzt mit einer Um-frage nach jedem Thema, ob das Team einen Follow-up wünscht. Auch die Häufigkeit von Retrospektiven darf kein Tabu sein. Wieso nicht: statt alle zwei Wochen ein belächeltes Meeting lieber alle vier Wochen eines mit Wirkung. Und noch ein Gestaltungsele-ment: das Team entscheidet sich für eine freiwillige Teilnahme. Wer nicht dabei war, muss mit den Resultaten leben.

Den agilen Prinzipien treu bleiben – Und was, wenn die Einfüh-rung von Retrospektiven auf Widerstand stösst? Müsste dann der Moderator bzw. Scrum-Master einfach härter verkaufen oder ist er ein Weichei? Ja und nein. Natürlich gehört Frustresistenz und Verkaufen zu den Tugenden eines guten Moderators. Eine Praktik auch gegen initialen Widerstand der Betroffenen einmal einzu-führen und sie eine Zeit lang auszutesten kann Augen öffnen, Probleme transparent machen, Erfahrungen verändern. Kultur-wandel funktioniert aber nicht auf Befehl, sondern über die Ver-änderung des Kontextes. Die Menschen müssen das Neue wollen, es muss ein «Pull» entstehen – und es soll auch Spass machen! Im Idealfall werden sie Fans des Neuen und verkaufen es dann gleich weiter. Dein Team ist noch kein Fan von Retrospektiven? Mache die tagtäglich auftauchenden Fragen doch einfach mal in einem sichtbaren Themenspeicher transparent. Die Sinnfrage beantwortet sich dann von selbst. «Transparency, Inspect & Adapt» – die agilen Prinzipen sind nicht verhandelbar.

Peter Erne, Principal Consultant

23

Blog

Page 24: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

24

ZERTIFIZIERUNGZERTIFIZIERUNG

Kurzbeschreibung

Entwickeln Sie die Fähigkeiten, die Sie benötigen, um als Product Owner die Wertschöpfung in einem skalierten Produkt-entwicklungsumfeld zu steuern. Lernen Sie die Aktivitäten, Praktiken und Tools zur Verwaltung von Backlogs und Steigerung des Kundennutzens kennen. Während dieses zweitägigen Kurses erhalten die Teilnehmer ein tiefes Verständnis für den Mehrwert eines Agile Release Trains (ART) und erlernen die nötigen Fähig-keiten um ihre Rolle effektiv auszufüllen. Bestandteil des Kurses sind die Anwendung von Lean Thinking für Epics, das Herunter-brechen von Epics in Features und Stories, sowie die Planung und Durchführen von Programm Increments (PI) und Iterationen.

Die Teilnahme am Kurs bereitet Sie auf die Prüfung und die Zertifizierung zum SAFe® Product Owner / Product Manager (POPM) vor.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: POPM

Kurzbeschreibung

Der Product Owner ist für den Erfolg seines Produkts ab- schliessend verantwortlich. Er verantwortet den wirtschaftlichen Erfolg gegenüber seinem Unternehmen, die Berücksichtigung der Erwartungen der Benutzer und die effiziente Bereitstellung des Produkts. Sein wichtigstes Arbeitsmittel in der Produktent-wicklung ist das «Product Backlog», welches alle Arbeitspakete enthält und zentral für die Releaseplanung und das Tracking ist.

In diesem Kurs lernen Sie, wieso sich Scrum für typische IT-Vorhaben eignet, was den agilen vom klassischen Ansatz unter-scheidet und mit welchen Regeln und Praktiken es in der Praxis funktioniert. Weiter behandelt der Kurs die Frage, mit welchen Veränderungen Sie im Team und im Umfeld rechnen müssen, wenn Sie Scrum einsetzen. Der Kurs dient zur Vorbereitung auf die Zertifizierung als «Professional Scrum Product Owner» (scrum.org).

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: PSPO

NEU SAFe® Product Owner / Product Manager (POPM)

Inhalt

■ Anwendung von SAFe® im Lean-Unternehmen

■ Zuordnung einer Lean-Agile Denkweise zu den Rollen Product Owner und Product Manager

■ Zusammenarbeit mit Lean Portfolio Management

■ Kontinuierliches Erforschen der Kundenbedürfnisse

■ Program Increment

■ Rollen und Verantwortlichkeiten des Product Owner / Produktmanagers

■ Erstellen eines Aktionsplans für Product Owner / Product Manager

Professional Scrum Product Owner I (PSPO)

Inhalt

■ Scrum Framework: alle Regeln, Zeremonien, Rollen und Artefakte als konsistentes System, entlang dem Scrum Guide als Referenz.

■ Scrum Theorie und Prinzipien: die empirische Prozesstheorie als Basis, ausgehend von der Annahme, dass die Produkt-Entwicklung ein komplexer, kreativer Prozess ist.

■ Scrum Team: das agile Team, das aus Product Owner, Scrum Master und Development Team besteht.

■ Produktwert maximieren: Der Product Owner wird allgemein auch als Value-Maximizer beschrieben.

■ Backlog-Management: Das Product Backlog als eine der Hauptaufga-ben des Scrum Product Owners & Arbeitsvorrat des Entwicklungsteam.

Page 25: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

25

Agile

ZERTIFIZIERUNG

Kurzbeschreibung

Damit die Komplexität von Entwicklungen beherrschbarer wird, setzen Entwicklungsteams auf agile Vorgehen, vor allem SCRUM. Zusammen mit der Projektmanagementmethodik HERMES bil-det sich ein interessantes Zusammenspiel von zwei Vorgehen, welche vor allem in der öffentlichen Hand vermehrt kombiniert eingesetzt werden. Das agile Vorgehen lässt sich aber genauso gut für nicht-Entwicklungsvorhaben anwenden - was Hermes ebenso mit dem Szenario Organisationsanpassung abdeckt.

In diesem Kurs lernen Sie, wieso sich Scrum zusammen mit Hermes für typische IT-Vorhaben eignet, was den agilen vom klassischen Ansatz unterscheidet und mit welchen Regeln und Praktiken es in der Praxis funktioniert. Weiter behandelt der Kurs die Frage, mit welchen Veränderungen Sie im Team und im Umfeld rechnen müssen, wenn Sie Scrum zusammen mit Hermes einsetzen - bereits ab Projektinitialisierung - und wie sie die geforderten, minimalen Lieferergebnisse trotz agilem Vorge-hen sicherstellen können. Weiter zeigt der Kurs auf, dass die Kombination von HERMES mit SCRUM ebenso für Vorhaben ohne Entwicklungsanteil eingesetzt werden kann.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: SH

Kurzbeschreibung

Entwickeln Sie die Fähigkeiten, die Sie benötigen, um ein leistungsstarkes Teammitglied eines Agile Release Trains (ART) zu werden und lernen Sie effektiv mit anderen Teams zusammenzuarbeiten. Während dieses zweitägigen Kurses erhalten Sie ein tiefes Verständnis für den Mehrwert eines ART und was sie tun können, um ihre Rolle mit Scrum, Kanban und XP effektiv auszufüllen.

Sie werden auch lernen, wie man ausgehend von Features User Stories schreibt sowie Iterationen und Program Increments plant und durchführt. Schliesslich erfahren Sie mehr über die Continuous Delivery Pipeline und die DevOps-Kultur, wie man sich effektiv mit anderen Teams des Programms synchronisieren kann und was erforderlich ist, um den ART kontinuierlich zu verbessern.

Die Teilnahme am Kurs bereitet Sie auf die Prüfung und die Zertifizierung zum SAFe® Practitioner (SP) vor.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: SFT

NEU Scrum mit Hermes (SH)

Inhalt

■ Scrum Zeremonien, Rollen und Artefakte als konsistentes System, entlang dem Scrum Guide.

■ Aspekte wie Time-boxing, Arbeit in Sprints, Vorhersagbarkeit und Fortschrittskontrolle.

■ Hermes Grundlagen: die 4 Phasen.

■ Überschneidungen Scrum mit Hermes: Theorie von Hermes und Praxis.

■ Vereinbarung und Besetzung der Rollen.

■ Wie stelle ich trotz Agilität die Lieferergebnisse von Hermes sicher.

■ Wie rapportiert man gegenüber dem Auftraggeber.

■ Agilität in Vorhaben ohne Entwicklungsanteil.

SAFe® for Teams (SFT)

Inhalt

■ Einführung des Scaled Agile Framework (SAFe®)

■ Aufbau eines agilen Teams

■ Planung der Iteration

■ Ausführung der Iteration

■ Ausführen des Programmschrittes

Page 26: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

26

Page 27: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

27

Agile

Kurzbeschreibung

Viele Unternehmen haben bereits positive Erfahrungen mit einzelnen agilen Teams gemacht. Die weitere Verbreitung der Agilität im Unternehmen stellt jedoch oft eine grosse Heraus-forderung dar. Eine erfolgreiche und nachhaltige Transformation verlangt starkes Leadership und Management of Change und erfordert Kenntnisse über die kritischen Erfolgsfaktoren. Agile ist nicht einfach eine weitere Methode oder Vorgehen, sondern eine neue Denkweise. Der Paradigmenwechsel hat weitreichende Konsequenzen auf die Aufbau- und Ablauforganisation und verlangt ein ganzheitliches und systematisches Vorgehen.

Sie kennen die Dimensionen und kritischen Erfolgsfaktoren einer erfolgreichen und nachhaltigen agilen Transformation. Sie verstehen die zentrale Rolle des Leaderships in einer Agilen Organisation und die dafür erforderlichen organisatorischen und kulturellen Veränderungen. Sie verstehen wie in einem Agilen Umfeld Portfolio, Ressourcen und Vorhaben effektiv geplant und gesteuert werden können.

Dieser Kurs richtet sich an Entscheidungsträger, welche ver-stehen wollen was eine agile Transformation für die Gesamt-organisation und Sie selbst bedeutet.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: AL

Kurzbeschreibung

Als Entwickler in einem Scrum Team ist es wichtig, mit den grundlegenden Werten und Praktiken von Scrum vertraut zu sein und diese auch praktisch in der Softwareentwicklung anwenden zu können. Auch die Zusammenarbeit in einem selbstorganisierten Scrum-Team unterscheidet sich von herkömmlichen Projekten.

In diesem Kurs lernen Sie, wieso sich Scrum für die emergente Entwicklung von Software eignet, was den agilen vom klassischen Ansatz unterscheidet und mit welchen Regeln und Praktiken es in der Praxis funktioniert. Weiter behandelt der Kurs die Fokusthemen Devops und Continuous Delivery. Der Kurs dient zur Vorbereitung auf die Zertifizierung als «Professional Scrum Developer» (scrum.org).

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: PSD

Agile Leadership (AL)

Inhalt

■ Treiber für Agilität: Welche Probleme sollen adressiert werden?

■ Auswirkungen der Agilität auf Ihre Organisation

■ Process: Do the right thing fast

■ Product: over Project

■ Place: New Ways of Working

■ People: Employee of the Future

■ Leadership & Culture – Führungstil im Agilen

NEU Professional Scrum Developer (PSD)

Inhalt

■ Scrum Framework: alle Regeln, Zeremonien, Rollen und Artefakte als konsistentes System, entlang dem Scrum Guide als Referenz.

■ Scrum-Theorie und Prinzipien: die empirische Prozesstheorie als Basis, ausgehend von der Annahme, dass Software-Entwicklung ein komplexer, kreativer Prozess ist.

■ Scrum Team: Wer hat welche Aufgaben und Verantwortlichkeiten und wie funktioniert eine erfolgreiche Zusammenarbeit?

■ Product Value: Releaseplanung, Product Backlog Management und Einbezug von Stakeholdern.

■ DevOps und Praktiken in der agilen Softwareentwicklung.

ZERTIFIZIERUNG

Page 28: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

28

Knowledge Transfer in Agile Teams using User Stories

In agile organizations, team members work together closely, and team members are highly specialized. But there is hardly any overlap of knowledge and skills between team members; it is basically a team of specialists… sound familiar?In most teams, it is not possible to move work around. Only one or maximum two team members are able to implement the work planned. This often leads to stress in the team and results in not-done work items at the end of the Sprint.Team members might be interested in learning and ex-panding their skillsets beyond their areas of specialization; but usually there is no time available.

T-shaped to the rescueLine management is often interested in increasing the skillsets of their employees. The so-called T-sha-ped person refers to employees who not only increase their specialization, but also broaden their knowledge and skill-sets to become ge-neralizing specialists. There are two benefits to this approach: line management

can apply employees’ knowledge and skills in

a broader context and dependency on «Single Point of Failures» decreases. For employees, a wider knowledge base and skillset means increased market value and therefore a better market position.

Trying to broaden knowledge and skillsets with trainings can be a good starting point. Thereafter, it is critical that employees have a chance to gain practical experience to put the newly acquired skills to use. At this point, both line management and agile teams struggle to find sufficient time.

Knowledge Transfer is WorkAs an Agile Coach, I ran into this problem about a year ago. After discussions with all parties involved, I came to the conclu-sion that knowledge transfer means «work». In an Agile Team, work is described as Backlog Items and can be planned in e.g., Sprints. So, why not create Backlog Items for knowledge trans-fer?

In Agile Requirements Engineering, we often make use of so-called «User Stories». A User Story describes a functionality or customer wish in general from the perspective of the user. It describes the goal and the value of a particular requirement and

Figure 1. T-shaped employee

Page 29: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

29

Blog

includes Acceptance Criteria. These Acceptance Criteria facilitate the acceptance by e.g., a Product Owner (PO) once the User Story is done.

A Knowledge Transfer User StoryA User Story is the ideal medium to describe exactly what needs to be done in the case of knowledge transfer. A User Story for knowledge transfer has a clear description about the goal and the value of the Item. It also comes with Acceptance Criteria, which makes it easy to check whether the knowledge transfer has been accomplished.

Once planned into a Sprint, the Knowledge Transfer User Story is divided into Tasks, where Tasks are shorter than one working day. In this way, the knowledge transfer can be planned in very small, controllable steps. Two people work on these Tasks: an experienced team member and a «trainee» or newer team member.

Example of a Knowledge Transfer User StoryAs a team member I want to be able to configure file A,so that I can release the module myself without any support from B.Acceptance Criteria

■ Configuration of file A without support

■ Releasing the adapted configuration file with the adapted settings

How did this work in reality?In a concrete customer case, the Product Owner and the line manager wrote a Feature for knowledge transfer in the team for the last part of the project. In this particular case it was neces-sary to transfer the knowledge of an external party (supplier) to the team. The goal was to ensure enough knowledge and skill to maintain the component (and to thereby remove the depen-dency on the external party). The knowledge transfer Feature was divided into a set of very specific knowledge transfer User Stories which were put into the Product Backlog.

For each Sprint, knowledge transfer User Stories were selected with the PO and the team. The knowledge transfer User Story was treated as a «normal» Backlog Item throughout the Sprint and the outcome was presented during the Sprint Review Mee-ting at the end of the Sprint.

Knowledge transfer emerged from the shadows and was pro-moted to «normal» work which found a place in the Product Backlog. The knowledge transfer User Story had an estimated size, a clear description and precise acceptance criteria.

The pros and the cons of this approach:

Pros:Knowledge transfer became transparent and could be planned as «normal» work. The team liked this way of working, becau-se knowledge transfer was no longer a hidden item that team members had to do «on the side». It also became clear for ma-nagement that knowledge transfer has a cost.

Cons:As soon as the team came under pressure, the knowledge trans-fer User Stories were put on the bottom of the Sprint Backlog or even thrown out. This is a typical reaction when teams are under pressure to deliver. However, after a while the knowledge transfer User Story re-gained importance, in this particular case because the cooperation with the external party had an explicit end date.

Was it worth it?Generally speaking, applying User Stories to knowledge transfer works quite well. The main advantages are:

■ Full transparency about knowledge transfer (internal/exter-nal), no hidden work in the team

■ Full transparency for line management about who is broade-ning knowledge and skills

■ The goal and value of knowledge transfer are clear

■ Acceptance Criteria ensure that knowledge transfer User Sto-ries have a defined scope and completion can be verified

■ Knowledge transfer User Stories have an initial estimation and priority

■ The importance of knowledge transfer can be compared to the other work items in the Backlog

■ The concrete amount and rate of knowledge transfer are now measurable)

If you are interested in an agile way of working or using User Stories in your team, please do not hesitate to contact me or my colleagues in the Agile Unit of SwissQ.

Paul Boekhout, Principal Consultant / Enterprise Agile

Page 30: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

30

Kurzbeschreibung

In diesem Kurs erwerben Sie das notwendige Wissen, um eine agile Transformation in einem Unternehmen zu leiten, indem Sie das Scaled Agile Framework® und die zugrunde liegenden Prinzipien des Lean Thinking und des Produktentwicklungs-flusses nutzen. Sie werden verstehen, wie die Prinzipien und Praktiken des Frameworks Lean and Agile Development, Agile Release Train, Agile Portfolio Management, Agile Architecture und Scaling Leadership unterstützen.

Die Teilnahme am Kurs bereitet Sie auf die Prüfung und die Zertifizierung zum SAFe® Agilist (SA) vor.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: SAFE

Kurzbeschreibung

In diesem Kurs erlernen Sie die Praktiken und Hilfsmittel um ein Lean Portfolio Management (LPM) führen zu können. Sie lernen die drei wesentlichen LPM Funktionen kennen: Strategie- und Investmentplanung, LPM Betrieb und LPM Governance.

Sie haben die Möglichkeit, den aktuellen und zukünftigen Zu-stand ihres Portfolios mit dem Portfolio Canvas Tool zu erfassen und wichtige Geschäftsinitiativen zur Erreichung des zukünfti-gen Zustands zu identifizieren. Sie werden in der Lage sein, mit dem Portfolio-Kanban einen kontinuierlichen Wertfluss (Flow) aufzubauen und Initiativen zur Optimierung des wirtschaftlichen Nutzens zu priorisieren. Der Kurs vermittelt auch Einsichten in die Erstellung von Value Stream-Budgets und Lean Budget Guardrails sowie in die Messung der Lean Portfolio Performance mit geeigneten Metriken.

Der Kurs bereitet auf die Prüfung zum SAFe® Lean Portfolio Manager vor.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 3 Tage

■ Code: LPM

Leading SAFe® (SAFE)

Inhalt

■ Einführung in das Scaled Agile Framework (SAFe®)

■ Lean-Agile Mindset

■ SAFe®-Prinzipien

■ PI-Planning selbst erleben

■ Business-Wert: Entdecken, Implementation und Release

■ Lean Portfolio etablieren

NEU Lean Portfolio Management (LPM)

Inhalt

■ Einführung von Lean Portfolio Management (LPM)

■ Festlegung der Strategie und der Investitionsfinanzierung

■ Anwendung agiler Portfoliooperationen

■ Anwendung von Lean Governance

■ Implementierung der LPM-Funktion

ZERTIFIZIERUNGZERTIFIZIERUNG

Page 31: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

31

Agile

Agile Workshops (AWS)

Agile Transformation Kick-off

Haben Sie beschlossen, sich mit ihrer Organisation auf die Reise der Agilen Transformation zu begeben? Nun möchten Sie möglichst rasch die relevanten Fragen gemeinsam mit Ihrem Team klären: «The reason why?», die Vision, das Umfeld, die Risiken, etc. und anschliessend mit viel Energie starten. Dann unterstützen wir Sie gerne dabei, diese Aspekte zu beantworten und rasch in einer gut kommunizierbaren Form darzustellen. Dabei basieren wir auf der bewährten Methode des «Lean Change Canvas».

Im Idealfall haben Sie schon ein Kernteam von Personen zusammengestellt, welche gemeinsam die Transformation anstossen werden. Je ähnlicher deren Standpunkte aktuell sind, umso rascher lässt sich ein klares Bild entwerfen. Wenn nicht, machen wir die Handlungsfelder und offenen Fragen ge-meinsam transparent und formulieren erste Antworten bzw. Optionen dazu.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: ATK

Agile Verträge

Haben Sie sich auch schon gefragt, welche Vereinbarungen nötig sind, um mit einem Partner ein Produkt agil zu entwickeln? Ein Werkvertrag ist häufig nicht ideal - was dann? Wie verträgt sich ein agiler Mindset überhaupt mit den Erwartungen im juristi-schen Umfeld? Und wie könnte eine Lösung für Ihre Problem-stellung aussehen?

Mittlerweile gibt es interessante Lösungsansätze. Eine Subgrup-pe der swissICT-Fachgruppe «Lean, Agile, Scrum» beschäftigt sich seit 2013 kontinuierlich mit agiler Beschaffung der öffent-lichen Hand, da herkömmliche Ausschreibungsverfahren den Handlungsspielraum von IT-Projekten so stark einengen, dass eine flexible Umsetzung kaum mehr möglich ist. Sie hat einen Leitfaden «Beschaffung von agilen IT-Projekten» erarbeitet, das «agile.agreement», und stellt eine ausführliche Version davon zur Diskussion. Das agile.agreement basiert auf 3 Komponenten (agile.codex, agile.framework und agile.governance) welche die Grundsätze der Agilität konsequent umsetzen.

In diesem Workshop erhalten Sie einen Überblick über das The-ma, die Rahmenbedingungen und Eckwerte des agile.agreement und relevante Beispiele. Anschliessend erörtern wir gemeinsam Lösungsoptionen für Ihre spezifischen Fragen und Problemstel-lungen.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: AA

Value Stream Analyse

Sie haben erste Erfahrungen mit agilem Vorgehen in einzelnen Teams an verschiedenen Orten in Ihrer Organisation gemacht oder es gibt auch schon einige agile Teams, welche einigermas-sen aufeinander abgestimmt arbeiten. Nun möchten Sie einen nächsten, signifikanten Schritt auf dem Weg zur agilen Produkt-entwicklung machen. Die nötige Bereitschaft und Unterstützung hierfür ist in Ihrer Organisation vorhanden, Sie müssen nicht mehr vom Sinn agilen Vorgehens überzeugt werden. Nun suchen Sie ein klareres Bild, wie die Zielstruktur aussehen könnte. Ein wirkungsvoller Weg hierzu ist die Value Stream Analyse («Wert-stromanalyse»), welche aufzeigt, wie Unternehmung quer durch die vorhandene (Silo-)Organisation heute schon Ihren Kunden Wert liefert und Szenarien ermöglicht, wie sie in Zu-kunft aussehen könnte. In diesem Workshop positionieren wir zunächst Wertströme im Unternehmenskontext und deren Wert im Hinblick auf die agile Unternehmung. Anschliessend erarbei-ten wir mit Ihnen beispielhaft für einen von Ihnen definierten Ausschnitt Ihrer Organisation ein Bild der aktuellen operativen Wertströme und ihrer unterstützenden IT-Systeme. Daraus ent-wickeln wir gemeinsam für Ihre Situation eine exemplarische neue Lösung gemäss einem der möglichen Szenarien.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: WSA

Extreme Prioritisation

Die Priorisierung von Vorhaben (Anforderungen, Projekten, Pro-dukten, Releases) bzgl. der Frage «Wie generieren wir maximalen Wert?» ist in agilen Umfeldern absolut zentral. Doch wie kommen wir zu einer sinnvollen Priorisierung, umso mehr wenn zahlreiche Stakeholder mit unterschiedlichen Standpunkten daran beteiligt sind? Eine detaillierte Analyse ist meist viel zu zeitaufwändig - umso mehr als wi viel häufiger priorisieren als im herkömmlichen Vorgehen. Welche Alternativen gibt es? «Priority Poker» hat sich als sehr wirkungsvolles Instrument bewährt - verbunden mit ei-nem spielerischen Element, das von Teams auf allen Stufen meist sehr geschätzt wird. Es setzt Offenheit und Diskussionsbereit-schaft bei allen Beteiligten voraus und sorgt für grosse Transpa-renz der Entscheidungen und der relevanten Beurteilungsaspekte. Priority Poker lässt sich auch in der ganzheitlichen Priorisierung von Vorhaben sehr effektiv einsetzen. Wir basieren hierbei auf der Methode «Weighted Shortest Job First» mit mehreren Be-urteilungsdimensionen. Wir stellen im Workshop die Methode vor und wenden sie gleich konkret an, um die Wirkungen selbst zu erleben. Voraussetzung hierfür ist eine konkrete Priorisierungs-aufgabe von Vorhaben, Epics, Stories, etc. aus Ihrem Umfeld.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: EP

Page 32: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

32

?

Start Finishing. Stop starting.

Value StreamValue

simplecomplicated

technology

requirements

unclear

unclear

clear

clear

anarchyCOMPLEX

When Agile?

Vision

PEOP

LE

O R GANIZ

ATI

ON

The 12 Agile Principles

harnesschange

$

Business & Developers

Satisfy the Customer

DeliverSo�ware frequently

Face 2 FaceCommunication

trust

Technical

E xc e ll e n ce

Self-organized

Re�ect at regular Intervals

ValuableSo�ware

Keep itsimple!

SustainableDevelopment

over

over

overThe Agile Manifesto

over

TRUST

AgileTesting

Planning

Poker

Thinking

Design

SAFe

Agile RequirementsEngineering

MVP

Agile PortfolioManagement

??

Kanban

SoS

From Operationalto Strategic Agility

Scrum

LeSS

Take your pick!

FRAME-WORKS

TOOLS

Customer

SENSE OF URGENCY

SwissQ Consulting AG | Zurich | Bern | Phone: +41 43 288 88 40 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it CONTRIBUTORS: SwissQ Agile Guild | Simon Berg | Stefan Grätzer | Reto Kurmann | Martin Meier | Ariane Previtali | Martin Ravizza | Dirk Stockmann | Volker Vetter | Sabine Wettstein

Know yourCustomers

1001

0111

0010

10010011011010110100010110110010111001010010011

Globalization &available Information

MASTERY

WiP-Limit

125

8

Backlog Managem

ent

BUSIN

ESS VALUE

General Knowledgeand Skills

In-D

epth

Know

ledg

e

Co-locate! (Same place. Same Time.)

Network of agile and cross-functional Teams

PairWork

Delegate!

Desca

le!

P D

CA

Lean Change

Insights

Expe

rimen

ts

Optio

ns

Prepare

Introduce

Review

from

Product

Project to

Lean

Co£ee

Chan

ge & Tra

nsformation

Lean Change Canvas

Ride the Change.Explore Agile. For you.

© SwissQ, Version 0.9 (10.2019)

Jetzt bestellen!

Page 33: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

33

Agile

?

Start Finishing. Stop starting.

Value StreamValue

simplecomplicated

technology

requirements

unclear

unclear

clear

clear

anarchyCOMPLEX

When Agile?

Vision

PEOP

LE

O R GANIZ

ATI

ON

The 12 Agile Principles

harnesschange

$

Business & Developers

Satisfy the Customer

DeliverSo�ware frequently

Face 2 FaceCommunication

trust

Technical

E xc e ll e n ce

Self-organized

Re�ect at regular Intervals

ValuableSo�ware

Keep itsimple!

SustainableDevelopment

over

over

overThe Agile Manifesto

over

TRUST

AgileTesting

Planning

Poker

Thinking

Design

SAFe

Agile RequirementsEngineering

MVP

Agile PortfolioManagement

??

Kanban

SoS

From Operationalto Strategic Agility

Scrum

LeSS

Take your pick!

FRAME-WORKS

TOOLS

Customer

SENSE OF URGENCY

SwissQ Consulting AG | Zurich | Bern | Phone: +41 43 288 88 40 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it CONTRIBUTORS: SwissQ Agile Guild | Simon Berg | Stefan Grätzer | Reto Kurmann | Martin Meier | Ariane Previtali | Martin Ravizza | Dirk Stockmann | Volker Vetter | Sabine Wettstein

Know yourCustomers

1001

0111

0010

10010011011010110100010110110010111001010010011

Globalization &available Information

MASTERY

WiP-Limit

125

8

Backlog Managem

ent

BUSIN

ESS VALUE

General Knowledgeand Skills

In-D

epth

Know

ledg

e

Co-locate! (Same place. Same Time.)

Network of agile and cross-functional Teams

PairWork

Delegate!

Desca

le!

P D

CA

Lean Change

Insights

Expe

rimen

ts

Optio

ns

Prepare

Introduce

Review

from

Product

Project to

Lean

Co£ee

Chan

ge & Tra

nsformation

Lean Change Canvas

Ride the Change.Explore Agile. For you.

© SwissQ, Version 0.9 (10.2019)

Page 34: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Requirements

34

Req

uire

men

ts Kursangebote

Inhalt

■ IREB® CPRE Foundation Level (IREBFL) 37

■ Design Thinking (DETHI) 37

■ Digitale Produkte und Datenschutz (DSG) 40

■ UX / Usability Power Kurs (UURE) 40

■ RE Power Kurs (REP) 41

■ IREB® CPRE Advanced Level – Elicitation (ALEC) 41

■ IREB® CPRE RE@Agile Primer (IREBAP) 44

■ IREB® Advanced Level – RE@Agile (IREBALAG) 44

■ Agile Product Management (APM) 45

■ iSQI® Certified Agile Business Analysis (CABA) 45

■ IQBBA® Certified Foundation Level – Business Analyst (IQBBA FL) 48

■ Geschäftsprozesse analysieren (GPA) 48

■ Requirements Workshops (RWS) 49

Page 35: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

35

Requirements

Page 36: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Requirements

36

Page 37: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

37

Requirements

Kurzbeschreibung

Was braucht es für gutes Design Thinking? Genau, die methodi-schen Kenntnisse von SwissQ, eine Ideenanregende Umgebung und Ihr multidisziplinäres Team. Und schon geht‘s voran mit dem Lösen von «wicked» (weakly designed) Problems, also Problemen mit schlecht definierten Fragestellungen zu denBedürfnissen Ihrer Kunden. Der Workshop behandelt den gesamten Design Thinking Prozess von Empathize, Define, Ideate, Prototype bis hin zum Test. Natürlich auf Basis Ihrer spezifischen Fragestellung. So werden Sie nicht mehr das Gefühl haben, den Kunden nicht richtig verstanden oder gar an ihmvorbei entwickelt zu haben.

Nach dem Workshop, für welchen SwissQ die Räumlichkeiten, Kreativmaterial und ein Fotoprotokoll zur Verfügung stellt, sindSie und Ihr Team selbst in der Lage, geniale Design Thinking Workshops durchzuführen.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: DETHI

Kurzbeschreibung

IT-Lösungen erfolgreich einzuführen bedeutet, die Anforderungen der relevanten Stakeholder umzusetzen sowie geplante Termine und Budgets einzuhalten. Die Weichen für den Erfolg werden gestellt, indem die Anforderungen sorgfältig und möglichst voll-ständig erhoben werden. Um zu verhindern, dass verschiedene Stakeholder die Anforderungen unterschiedlich interpretieren, müssen diese möglichst eindeutig dokumentiert werden. Nur so lassen sich Ziel- und Anforderungskonflikte rechtzeitig erkennen und lösen. Damit wird zudem die Notwendigkeit nachträglicher kostenverursachender Änderungen deutlich reduziert.

Im Zertifikatslehrgang Requirements Engineering werden die grundlegenden Methoden und Prozesse vermittelt. Der Lehrgang ist abgestützt auf den Lehrplan des Zertifikats «IREB® CPRE Foundation Level» und schliesst mit der ent-sprechenden 75-minütigen Zertifikatsprüfung ab.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 3 Tage

■ Code: IREBFL

Design Thinking (DETHI)

Inhalt

■ Design Thinking Prozess

■ Verstehen (Design Challenge, Personas)

■ Beobachten (Contextual Inquiry, Interview)

■ Standpunkt definieren

■ Ideen generieren (Kreativitätstechniken)

■ Prototyp entwickeln

■ Testen (Hypothesen, A /B Testing)

IREB® CPRE Foundation Level (IREBFL)

Inhalt

■ Motivation und Grundlagen des Requirements Engineering

■ Abgrenzung des Systems und Systemkontexts

■ Erheben von Anforderungen

■ Dokumentation der Anforderungen

■ Use Case Formulierung und Darstellung

■ Use Case Diagramme, Aktivitäts- und Zustandsdiagramme in UML

■ Prüfung und Abstimmung der Anforderungen

■ Management der Anforderungen

■ Unterstützung der Werkzeuge

ZERTIFIZIERUNG

Recognized Training Provider

20202020

Page 38: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

38

Design Thinking – Innovation garantiert?Design Thinking als Ansatz zur Problemlösung und Entwicklung neuer Ideen wird immer populärer. Viele Unternehmen prakti-zieren Design Thinking. Es eignet sich nicht nur für die Ent-wicklung neuer Produkte, sondern auch für Dienstleistungen, Strategien, Geschäftsmodelle, Konzepte oder Prozesse. Doch wie funktioniert Design Thinking und liefert es wirklich die richtigen Ideen zur Lösung von Problemen?

«Unser Onboarding-Prozess ist nicht optimal.»

«Wir finden nicht genug neue Mitarbeiter in abgelegenen Tälern für den Betrieb unserer Wasserkraftwerke.»

Zwei sehr unterschiedliche Probleme, die die Personalabtei-lung eines Energiedienstleisters beschäftigen. Diese Probleme haben wir in einem eintägigen Schulungs-Workshop bearbeitet. «Schulung», weil die Mitarbeiter den Prozess des Design Thin-kings auch in der Theorie lernen, damit sie dies in Zukunft selbst anwenden können. «Workshop», weil wir Ideen zu echten Pro-blemen ihres Unternehmens finden und so direkt Mehrwert für die Teilnehmenden, in diesem Fall Mitarbeitende der Personal-abteilung, generieren.

Design-Thinking-Prozess und -MindsetIm Design Thinking gibt es keinen Standard-Prozess, vielmehr gehen verschiedene Firmen nach unterschiedlichen Phasen vor, die sich ähneln.

Wir sind nach dem iterativen Prozess der HPI School of Design Thinking vorgegangen:

Man sollte mindestens einen Tag für Design Thinking vorsehen.

Es kann auch schnell länger dauern, wenn man z.B. Nutzer oder Kunden befragen oder in ihrem normalen Umfeld beobachten möchte. Bei Design Sprints, die z.B. von Google eingesetzt wer-den, werden die Phasen Understand, Diverge, Decide, Prototype und Validate in vier oder fünf Tagen durchlaufen. Viel wichtiger als der Prozess ist allerdings das richtige Mindset. Wer sich auf Design Thinking einlässt sollte Herausforderungen lieben, neu-gierig sein, Lust auf Visualisieren und Experimentieren haben und den Fokus mit Empathie und Aufmerksamkeit auf den Nutzer bzw. Kunden setzen. Ausserdem sollte man bereit sein, nicht zielfüh-rende Ideen und Ergebnisse schnell wegzuwerfen (fail early).

Verstehen«Verbessere den Onboarding-Prozess.»

«Mache den Job im Betrieb von Wasserkraftwerken in Bergtälern für junge Leute attraktiver.»

Für diese Design Challenges suchten die HR-Mitarbeitenden im Workshop neue Ideen. Im ersten Schritt definierten die Teil-nehmenden Personas, d.h. typische Vertreter von Zielgruppen. Für die erste Problemstellung war das z.B. Anna, 32 Jahre alt, verheiratet mit einem Kind, Elektroingenieurin. Sie startet demnächst im Unternehmen. Im zweiten Fall haben wir Urs, 23, Elektroinstallateur vom Land mit etwas Berufserfahrung, der die Natur liebt und einen neue Job sucht. Die Verwendung von Personas kommt aus dem Human-Centered Design und erlauben eine starke Identifikation mit potentiellen Nutzern oder Kunden.

BeobachtenJetzt müssten Vertreter der Zielgruppen entweder interviewt oder bei ihrer relevanten Tätigkeit beobachtet werden. Schon bei der Problemstellung mit dem Onboarding-Prozess ist das im Rahmen des Workshops herausfordernd, da geeignete Vertreter nur ein-geschränkt zur Verfügung stehen. Der Workshop-Teilnehmer, der zuletzt im Unternehmen angefangen hatte, wurde als Interview-partner ausgewählt. Ein 23-jähriger naturliebender Elektroinstal-lateur aus einem Bergtal war aber zufällig beim Workshop nicht anwesend. So mussten wir ein Interview simulieren. Bei einem «richtigen» Design Thinking Prozess müsste man hier Vertreter der Zielgruppe besuchen, beobachten und befragen. Für das Ver-

Page 39: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

39

Blog

ständnis der Bedürfnisse der Nutzer oder Kunden ist es äusserst hilfreich, eine User Journey bzw. Customer Journey zu erstellen – welche Erfahrungen und Erlebnisse wurden vor, während und nach der Nutzung des Produktes oder Services gemacht. Alter-nativ könnte man auch einen Tag im Leben der Persona detail-liert beschreiben.

Standpunkt definierenAusgehend von den Personas und den Erkenntnissen aus den Interviews definierten wir den Standpunkt. Ziel in dieser Phase ist es, in der Gruppe ein gemeinsames Verständnis zu entwi-ckeln, in welchem Rahmen eine Lösung gefunden werden kann.Bezüglich Onboarding neuer Mitarbeitenden haben die Teilneh-menden erkannt, dass der Onboarding-Prozess nicht gut genug unterstützt wird und sowohl die neuen Mitarbeitenden als auch ihre Vorgesetzten nicht immer wussten, was als nächstes erledigt werden müsste. Bei potentiellen jungen Betriebsmit-arbeitenden in Wasserkraftwerken war ein wichtiger Punkt, dass die Aufstiegschancen gering sind, weil langjährige Mitarbeiter in Führungsfunktionen kein Grund sehen, diese abzugeben.

Ideen findenFür die Ideenfindung gibt es verschiedene Kreativitätstechniken. Wir probierten die 6-3-5 Methode aus: 6 Teilnehmende (es können aber auch mehr oder weniger sein) erhalten jeweils ein Blatt, auf das sie je drei Ideen zur Lösung des Problems schreiben und geben das Blatt weiter. Der nächste Teilnehmende entwickelt dann die Ideen der vorhergehenden Teilnehmenden weiter. Das geht weiter, bis jeder jedes Blatt einmal bearbeitet hat. Im Anschluss hat jede Gruppe eine Idee ausgewählt und diese visualisiert: auf einem Flipchart wurde hierzu die Idee mit einem Slogan, den adressierten Bedürfnissen, der Lösung und dem Nutzen dargestellt.

Prototyp entwickelnDies war der Teil, der den Teilnehmern am meisten Spass ge-macht hat, da sie ihre Kreativität frei entfalten konnten. Die Onboarding-Gruppe entschied sich, eine App zu entwickeln, die den neuen Mitarbeitenden beim Start unterstützt. Schon mit der Einladung für den ersten Arbeitstag erhält er die Informationen, mit denen er sich die App herunterladen und sich registrieren kann. Er hat dann schon die Informationen zu seinem ersten

Arbeitstag inklusive z.B. Bilder von den Mitarbeitenden in seinem Team zur Verfügung. Die App führt ihn dann interaktiv durch die komplette Probe-zeit. Dazu haben die Teilnehmenden Mockups auf Flip-charts erstellt. Die Gruppe für bessere Perspektiven für junge Betriebsmit-

arbeiter hatte es schon etwas schwerer, da hier kein konkretes Produkt, sondern ein Konzept dargestellt werden musste. Sie entschied sich, ein «Generationenhaus» aus Lego zu bauen, mit dem sie wichtige Punkte des Konzepts, z.B. die Übergabe von Verantwortung von erfahrenen an junge Mitarbeitende visuali-sierte und so erfahrbar machte.

TestenUm schnell Feedback zum Produkt bzw. Konzept zu erhalten, haben die Gruppen ihre Prototypen getestet. Dabei wurde der Prototyp dem Interview-Partner aus der Beobachten-Phase vorgestellt. Dieser konnte dann sagen, was ihm gefällt, welche Wünsche oder Ideen er noch hat und wo noch Fragen sind. Die Erkenntnisse hieraus haben die Gruppen dann in einer weiteren Iteration in den Prototyp einfliessen lassen.

FazitDesign Thinking ist eine Möglichkeit, verhältnismässig schnell Ideen und Lösungen zu entwickeln, die die wirklichen Bedürf-nisse von Nutzer oder Kunden adressieren. Es ist spannend zu beobachten, welche Dynamik die Teilnehmer entwickeln und wie engagiert sie zu Werke gehen, wenn es um echte Probleme aus ihrem Bereich geht – und natürlich, wie viel Spass sie dabei haben. Auch wenn keine «echten» Vertreter der Zielgruppen zur Verfügung stehen, wie in unserem Schulungs-Workshop, können sich die Ergebnisse wirklich sehen lassen, sind aber sicherlich nicht optimal. Für Design Thinking, das nicht im Rahmen einer Schulung stattfindet, müssten Nutzer oder Kunden zwingend involviert werden.

Design Thinking erlebenFalls ihr Lust habt, selbst Design Thinking durchzuführen, bieten wir in unserer SwissQ-Academy einen eintägigen Schulungs-Workshop wie hier beschrieben an. Für alle, die zuerst einmal einen kurzen Einblick in Design Thinking bekommen wollen, halte ich zusammen mit Daniela Maag-Biri von ewz zwei Workshops «Design Thinking erleben» am European Product Owner & Requirements Engineering Day am 24. Juni 2019 – eine intensive Stunde mit viel Spass ist garantiert.

LiteraturEine gute Einführung in Design Thinking gibt Das Design Thinking Playbook (M.Lewrick, P. Link, 2018).

Christoph Wolf, Principal Consultant

Die Teilnehmenden beim Protoyping. Das Generationenhaus wird im Vordergrund gebaut und

die Onboarding-App im Hintergrund visualisiert.

Page 40: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Requirements

40

Kurzbeschreibung

Eine gute User Experience (UX) eines Produkts basiert auf der benutzerzentrierten Anforderungserhebung, wie sie das Vorge-hen nach User Centered Design vorsieht. Ein wichtiges Teilgebiet von UX ist Usability, welche sich mit der benutzerfreundlichen Bedienung beschäftigt. Dazu gehört die Zielsetzung, dass das Produkt den Benutzer in seiner Arbeit zufriedenstellend unter-stützt. Um für ein Produkt eine gute UX und Usability zu errei-chen muss das Entwicklungsteam die Bedürfnisse, die Aufgabe und das Arbeitsumfeld des Benutzers verstehen.

Dieser Power Kurs bietet eine praxisbezogene Einführung in User Centered Design mit kurzen Theorieinputs und Fokus auf praxis-bezogenen Übungen. Diese zeigen auf, wie der Benutzer bei der Erhebung und Validierung von Anforderungen in klassischen und agilen Vorgehensweisen einbezogen wird: ein Schlüsselfaktor bei der Investition in eine gute UX und Usability.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: UURE

Kurzbeschreibung

«Every Business will be a digital Business» - befeuert durch Daten. In diesem Kontext wird auch Datenschutz für alle zu einem Must. Das Europäische Datenschutz-Gesetz (DSGVO) hat seit seiner Einführung das Eigentum von persönlichen Daten explizit umgedreht: von den Unternehmungen zu den «Daten-Subjekten». Wenn ein neues Produkt kreiert oder ein Bestehendes weiterentwickelt wird, müssen die neuen Compliance-Anforderungen des DSGVO respektiert werden. Für Schweizer Firmen hat dies ebenso in manchem Kontext eine Relevanz und auch für das Schweizerische Datenschutz Gesetz (DSG) ist eine nächste Revision in Arbeit, welche dem DSGVO materiell sehr ähnlich sein soll.

Dieses Training vermittelt Ihnen das nötige Verständnis und die Kenntnisse, um digitale Produkte zu entwickeln, welche den gesetzlichen Datenschutz-Anforderungen entsprechen (DSGVO & zukünftiges DSG). Das Ziel ist es, dass Teilnehmer die zentrale Rolle von Datenschutz besonders im Kontext der digi-talen Innovation verstehen. Der Kurs zeigt zudem auf, wie sich «Datenschutz-by-Design» auch zu einem Verkaufsargument, wenn nicht gar zu einem Wettbewerbsvorteil einsetzen lässt.

Weitere Details

■ Sprache: DE

■ Typ: öffentlich / firmenintern

■ Dauer: 1 Tag

■ Code: DSG

UX / Usability Power Kurs (UURE)

Inhalt

■ Begriffe UX und Usability

■ Contextual Inquiry, Apprenticing, Beobachtung

■ Prototyping

■ Personas, Szenarien, User Journey, Storyboards

■ Walkthrough vs. Test

■ Grundsätze der Dialoggestaltung (User Centered Design)

NEU Digitale Produkte und Datenschutz (DSG)

Inhalt

■ Kennenlernen der zentralen Datenschutz-Anforderungen gemäss DSGVO

■ Methodologie & digitale Werkzeuge zu sicherem Datenschutz

■ Übersicht über das Anwendungsspektrum von DSGVO

■ Aktuellste Perspektiven zum Schweizer DSG

■ Risiko-Management (basierend auf existierendem DSGVO Fallrecht)

■ Datenschutz als Opportunity

Page 41: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

41

Requirements

Kurzbeschreibung

Anforderungserhebung ohne Tränen! Wie kitzle ich die wich- tigsten Anforderungen aus den Stakeholdern? Welche Ermitt-lungstechniken stehen mir zur Verfügung, und welche Technik passt zu welcher Situation? Wie gehe ich vor, wenn mehrere Anforderungen miteinander in Konflikt stehen?

Aufbauend auf den erworbenen Kenntnissen der CPRE (Foundation Level) Zertifizierung, vertiefen und erweitern Sie ihre Fähigkeiten zur Ermittlung von Anforderungen. Der Fokus liegt auf der Anwendung der erlernten Fähigkeiten. Sie vertiefen Ihre Kenntnisse im Bereich der Stakeholderanalyse und sonstiger Anforderungsquellen. Sie erweitern Ihr Know-how über Ermittlungstechniken und deren sinnvollen Einsatz. Sie er-fahren, wie Sie Konflikte in der Anforderungsanalyse erkennen, bewerten und bearbeiten können.

Zum Erlangen des Zertifikates legen Sie am Nachmittag des dritten Tages einen schriftlichen Multiple-Choice-Test ab. Zusätzlich muss innerhalb von 12 Monaten eine Hausarbeit ausgearbeitet werden.

Weitere Details

■ Sprache: DE

■ Typ: öffentlich / firmenintern

■ Dauer: 3 Tage

■ Code: ALEC

Kurzbeschreibung

Ein professionelles Requirements Engineering trägt wesentlich dazu bei, die Qualität der zu bauenden IT Lösung zu verbes-sern und Fehler in der Analyse zu vermeiden. Es umfasst das methodische Vorgehen von der (Projekt-)Idee bis hin zu den Anforderungen. Haben Sie bereits Erfahrung im Prozess- oder Projektumfeld und wünschen sich einen Einblick in das Gebiet des Requirements Engineering? Haben Sie als Stakeholder oder Vorgesetzter Mitarbeitende die sich mit dem Thema befassen und wollen sich selbst mehr Wissen aneignen? Dann ermöglicht Ihnen dieser Kurs eine praxisorientierte Vertiefung des Themas.

Mit kurzen Einführungen in die Theorie und Fokus auf prakti-schen Übungen, vermittelt Ihnen der Kurs einen praxisbezogenen Einblick in die Anwendung von Methoden und Techniken im klassischen und agilen Requirements Engineering. Der Kurs ist komplementär zu IREB® CPRE Foundation Level und agile@RE konzipiert und ersetzt diese nicht.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: REP

IREB® CPRE Advanced Level – Elicitation (ALEC)

Inhalt

■ Konzepte der Anforderungsermittlung und Konfliktlösung

■ Anforderungsquellen

■ Ermittlungstechniken

■ Konfliktlösung

■ Fähigkeiten eines Requirements Engineers

RE Power Kurs (REP)

Inhalt

■ Abgrenzung Scope, Kontext und Schnittstellen

■ Dokumentieren/Modellieren von funktionalen und nicht-funktionalen Anforderungen

■ Erstellen von Abnahmekriterien

■ Qualitätsmerkmale der Anforderungen / Definition of Ready (DoR)

■ Verwalten der Anforderungen in Wasserfall und Agilen Vorhaben

Recognized Training Provider

20202020

ZERTIFIZIERUNG

Page 42: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Agile

42

Agile Requirements Engineering

EPIC TO TASK

RELEASE BACKLOG

Product Manager

PRODUCT BACKLOG PRODUCT ROADMAP

D.E.E.P.

etailedstimatedmergentrioritized

DEEP

FEATURE GROOMING

DoR

PRODUCT

PORTFOLIO

Management

S.M.A.R.T. GOALS

easurablechievableelevantimely

SMART

PORTFOLIO

ITERATION

POsREsBAs

I.N.V.E.S.T.

ndependentegotiablealuableestimablemallestable

INVEST

TEAM BACKLOGS

internal / external Customers

Teams & Product Owner

RELEASE ROADMAP

n

STORY GROOMING

DoR

RELEASE

TEAM BOARDS

ToDo In Work Verify Done

DoD

ROLLOUT

DoD

Product Increment

RELEASES

PO PO PO PO

BIG PICTURE

BUGS

MVP

VISION

TEAM n

Epic Feature User Story Task

DoRDoRDoR

Vision

Context Diagram

Glossary Personas

Tech Spec

Business ObjectModel

Process Model UI Model Wireframes

User JourneyData ModelBusiness Process

Choose what you need. Less is more.

Uncertainty / Scribble Clarity / Focus

What?Why? How?

BACKLOG MANAGEMENT

© SwissQ, Version 1.0

MINIMAL VIABLE NOT THIS THIS

MVP

PRIORITY POKER

Possible criteria (consider at least 2):· Business value· · Risk· Cost of delay / urgency· · · Technical debt· Political weather situation

EE

E

FF

FF

F

USUSUSUSUSUSUS

SPRINTTIME

LEVE

L OF

DET

AIL

RELEASE

DoR

DoR

DoR DoR

DoR

VISION

Business Value

System Boundaries / Dependencies

Key Stakeholders

FOR (target customer)WHO (statement of the need or opportunity)THE (product name) IS A (product category)THATUNLIKE (primary competitive alternative)OUR PRODUCT

VISION

ACCEPTANCE

Business ValueWhat must / must not happen to deliver the business value(in / out of scope)

EPIC· Description· Feature

Business ScenarioWhich personas with which business scenarios deliver the business value

Feature· Description· · Scenarios

User ScenarioAcceptance criteria and/or test cases required to move thestory to a state of complete.

User Story· As a (role)· I want (requirement)·

E

F

US

Vision

Epics

Features

Tasks

User Stories

EPIC TO TASK…

· Identify relevant backlog items· Clarify items with business stakeholders · Socialize and validate with the team· Estimate · Assess relative priority of the items· Split items · Repeat the above

CONTINOUS BACKLOG GROOMING

· Select the items according to the given priority· Clarify and reestimate the items· Commit to the items ·

PLANNING I

· Break down epics into features, features into user stories and / or user stories into tasks · Split further if needed (on the same level)· Create product, release or sprint backlog·

PLANNING II

Release 3Release 2Release 1

Prio

Backbone

STORY MAPPING DEPENDENCY MAPPING

UX?

ARCH?

Needs Sys Arch HelpNeeds UX Help

Sprint 1 Sprint 2 Sprint 3

F

F

F

F

F

F

F

F

F

F

F

F

F

FF

F

F

= DependencyFeaturesProduct Increments

ROADMAPPING

HighClarity

MiddleClarity

Scribble

31 2Analyse epic / features

Product Focus

Team Focus Sprint Sprint Sprint

Manage dependency

Split feature / story

Prioritize stories

Communicate user stories (planning I and II)

Backlog magic

Clarify user stories

Release

RE ACTIVITIES

LEGENDLEGENDLEGENDLEGENDLEGEND

Grooming SplittingSplittingSplittingSplittingSplitting Clean UpClean UpClean UpClean Up Prioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & Estimate Business GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness Goals User InvolvementUser InvolvementUser InvolvementUser InvolvementUser Involvement/////FeedbackFeedbackFeedbackFeedback………

KPIsKPIsKPIs

SPLITTING

Business Process

Business Rules

Data Variants

Interface

Business Value

Simple / Complex

Non–Functional Requirements

TIME

EFFO

RTLO

WH

IGH

STOPFeature A

Feature B

Feature C

Feature D

WHEN TO ADD DETAIL?

· (technical) Complexity· Existing domain knowledge · Number of dependencies· Level of risk in the domain · Past issues and bugs· Number of unknowns

DISC

OVER

DELIV

ER

BACKLOG MAGIC

Source: Ellen Gottesdiener, «Discover to Deliver»

VIEW OF THE ORGANISATION

Skills

Knowledge

Mindset

Org Structure

Process

Infrastructure & Tools

INDIVIDUAL UNLEARNING

INDIVIDUAL LEARNING

ORGANISATIONAL UNLEARNING

ORGANISATIONAL LEARNING

Culture

BehaviorNEED FOR CHANGE

CHAOS STRUCTUREEDGE OF CHAOS

HOW MUCH STRUCTURE DO WE NEED?

THE ADAPTIVE WALK

Inno

vato

rs

Early

Ado

pter

s

Early

Majo

rity

Late

Majo

rity

Lagg

ards

2,5 % 13,

5 %

34 % 34 %

16 %

INNOVATION ADAPTION CURV

E

Source: based on Jurgen Appelo, «Management 3.0»

AGILE REQUIREMENTS ENGINEERING PRINCIPLES AND VALUES

Focus on business value

High customer involvementSlice and prioritize continuouslyMaster the art of simplicityPractice continous improvementRespond to changeSelf-organizeFocus on peopleEnjoy

ROLES NEW

Agile Requirements EngineerAgile Business AnalystUX ExpertRelease Train EngineerProduct OwnerProduct Manager

······

ROLES OLD

Requirements EngineerSystem EngineerBusiness AnalystSolution DesignerProject ManagerProduct Manager

······

= Business expertise

PRODUCT FOCUS

HIG

H

PO as part-time job[Expert PO]

3 Amigos

Agile RE tasks are distributed among team members

Proxy PO

dedicated BA / REin the team

BA Team

PO Team

Product Manager

dedicated PO

TEAM FOCUS PRODUCT FOCUS

LOW

HIG

HM

ETH

ODIC

AL E

XPER

TISE

RE ROLES AND COMPETENCES

SwissQ Consulting AG | Zürich | Bern | Fon: + 41 43 288 88 40 | Fax: + 41 43 288 88 39 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it

Jetzt bestellen!

Page 43: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

43

Agile

Agile Requirements Engineering

EPIC TO TASK

RELEASE BACKLOG

Product Manager

PRODUCT BACKLOG PRODUCT ROADMAP

D.E.E.P.

etailedstimatedmergentrioritized

DEEP

FEATURE GROOMING

DoR

PRODUCT

PORTFOLIO

Management

S.M.A.R.T. GOALS

easurablechievableelevantimely

SMART

PORTFOLIO

ITERATION

POsREsBAs

I.N.V.E.S.T.

ndependentegotiablealuableestimablemallestable

INVEST

TEAM BACKLOGS

internal / external Customers

Teams & Product Owner

RELEASE ROADMAP

n

STORY GROOMING

DoR

RELEASE

TEAM BOARDS

ToDo In Work Verify Done

DoD

ROLLOUT

DoD

Product Increment

RELEASES

PO PO PO PO

BIG PICTURE

BUGS

MVP

VISION

TEAM n

Epic Feature User Story Task

DoRDoRDoR

Vision

Context Diagram

Glossary Personas

Tech Spec

Business ObjectModel

Process Model UI Model Wireframes

User JourneyData ModelBusiness Process

Choose what you need. Less is more.

Uncertainty / Scribble Clarity / Focus

What?Why? How?

BACKLOG MANAGEMENT

© SwissQ, Version 1.0

MINIMAL VIABLE NOT THIS THIS

MVP

PRIORITY POKER

Possible criteria (consider at least 2):· Business value· · Risk· Cost of delay / urgency· · · Technical debt· Political weather situation

EE

E

FF

FF

F

USUSUSUSUSUSUS

SPRINTTIME

LEVE

L OF

DET

AIL

RELEASE

DoR

DoR

DoR DoR

DoR

VISION

Business Value

System Boundaries / Dependencies

Key Stakeholders

FOR (target customer)WHO (statement of the need or opportunity)THE (product name) IS A (product category)THATUNLIKE (primary competitive alternative)OUR PRODUCT

VISION

ACCEPTANCE

Business ValueWhat must / must not happen to deliver the business value(in / out of scope)

EPIC· Description· Feature

Business ScenarioWhich personas with which business scenarios deliver the business value

Feature· Description· · Scenarios

User ScenarioAcceptance criteria and/or test cases required to move thestory to a state of complete.

User Story· As a (role)· I want (requirement)·

E

F

US

Vision

Epics

Features

Tasks

User Stories

EPIC TO TASK…

· Identify relevant backlog items· Clarify items with business stakeholders · Socialize and validate with the team· Estimate · Assess relative priority of the items· Split items · Repeat the above

CONTINOUS BACKLOG GROOMING

· Select the items according to the given priority· Clarify and reestimate the items· Commit to the items ·

PLANNING I

· Break down epics into features, features into user stories and / or user stories into tasks · Split further if needed (on the same level)· Create product, release or sprint backlog·

PLANNING II

Release 3Release 2Release 1

Prio

Backbone

STORY MAPPING DEPENDENCY MAPPING

UX?

ARCH?

Needs Sys Arch HelpNeeds UX Help

Sprint 1 Sprint 2 Sprint 3

F

F

F

F

F

F

F

F

F

F

F

F

F

FF

F

F

= DependencyFeaturesProduct Increments

ROADMAPPING

HighClarity

MiddleClarity

Scribble

31 2Analyse epic / features

Product Focus

Team Focus Sprint Sprint Sprint

Manage dependency

Split feature / story

Prioritize stories

Communicate user stories (planning I and II)

Backlog magic

Clarify user stories

Release

RE ACTIVITIES

LEGENDLEGENDLEGENDLEGENDLEGEND

Grooming SplittingSplittingSplittingSplittingSplitting Clean UpClean UpClean UpClean Up Prioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & EstimatePrioritize & Estimate Business GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness GoalsBusiness Goals User InvolvementUser InvolvementUser InvolvementUser InvolvementUser Involvement/////FeedbackFeedbackFeedbackFeedback………

KPIsKPIsKPIs

SPLITTING

Business Process

Business Rules

Data Variants

Interface

Business Value

Simple / Complex

Non–Functional Requirements

TIME

EFFO

RTLO

WH

IGH

STOPFeature A

Feature B

Feature C

Feature D

WHEN TO ADD DETAIL?

· (technical) Complexity· Existing domain knowledge · Number of dependencies· Level of risk in the domain · Past issues and bugs· Number of unknowns

DISC

OVER

DELIV

ER

BACKLOG MAGIC

Source: Ellen Gottesdiener, «Discover to Deliver»

VIEW OF THE ORGANISATION

Skills

Knowledge

Mindset

Org Structure

Process

Infrastructure & Tools

INDIVIDUAL UNLEARNING

INDIVIDUAL LEARNING

ORGANISATIONAL UNLEARNING

ORGANISATIONAL LEARNING

Culture

BehaviorNEED FOR CHANGE

CHAOS STRUCTUREEDGE OF CHAOS

HOW MUCH STRUCTURE DO WE NEED?

THE ADAPTIVE WALK

Inno

vato

rs

Early

Ado

pter

s

Early

Majo

rity

Late

Majo

rity

Lagg

ards

2,5 % 13,

5 %

34 % 34 %

16 %

INNOVATION ADAPTION CURV

E

Source: based on Jurgen Appelo, «Management 3.0»

AGILE REQUIREMENTS ENGINEERING PRINCIPLES AND VALUES

Focus on business value

High customer involvementSlice and prioritize continuouslyMaster the art of simplicityPractice continous improvementRespond to changeSelf-organizeFocus on peopleEnjoy

ROLES NEW

Agile Requirements EngineerAgile Business AnalystUX ExpertRelease Train EngineerProduct OwnerProduct Manager

······

ROLES OLD

Requirements EngineerSystem EngineerBusiness AnalystSolution DesignerProject ManagerProduct Manager

······

= Business expertise

PRODUCT FOCUS

HIG

H

PO as part-time job[Expert PO]

3 Amigos

Agile RE tasks are distributed among team members

Proxy PO

dedicated BA / REin the team

BA Team

PO Team

Product Manager

dedicated PO

TEAM FOCUS PRODUCT FOCUS

LOW

HIG

HM

ETH

ODIC

AL E

XPER

TISE

RE ROLES AND COMPETENCES

SwissQ Consulting AG | Zürich | Bern | Fon: + 41 43 288 88 40 | Fax: + 41 43 288 88 39 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it

Page 44: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Requirements

44

Kurzbeschreibung

Kontinuierliche Verbesserung ist bei den Requirements Engineering Skills, insbesondere im agilen Entwicklungsumfeld, essentiell. Im Advanced Level (AL) RE@Agile werden die dafür notwendigen Verfahren, Konzepte & Techniken vertieft. Anhand von Praxisbeispielen unserer Dozenten, Übungen und dem Lehrplan des RE@Agile AL, erfahren Sie wie Sie ihre Pro-duktentwicklung zielgerichtet vorantreiben können. Sie lernen wie Sie Visionen & Ziele sauber formulieren und diese in Epics, Features & User Stories zum richtigen Zeitpunkt, in der richtigen Qualität herunter brechen, formulieren & schneiden. Dabei geht es nicht nur um die funktionalen sondern auch um die - oft ver-nachlässigten - Qualitätsanforderungen. Desweiteren verstehen Sie wie sich Business Value zusammen setzen kann und wie die Backlog Items mit Hilfe von verschiedenen Techniken nach agi-len Prinzipien priorisiert werden. Schlussendlich wird das Thema agile Skalierung angegangen und sie lernen die verschiedene Frameworks etwas näher kennen.

Zum Erlangen des Zertifikates legen Sie am Nachmittag des zweiten Tages einen schriftlichen Multiple Choice Test ab. Zusätzlich muss innerhalb von 12 Monaten einer Hausarbeit ausgearbeitet werden.

Weitere Details

■ Sprache: DE

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: IREBALAG

Kurzbeschreibung

Dieser Kurs vermittelt, wie Methoden und Techniken des Requirements Engineerings gewinnbringend in agile Ent-wicklungsprozesse eingebracht werden können, und wie Techniken aus dem agilen Vorgehen die Requirements-Engineering-Praxis verbessern können. Sie werden mithilfe vieler Praxisübungen die Unterschiede im Vorgehen, in den Methoden und der Dokumenation hautnah erleben.

Am Nachmittag des zweiten Schulungstages können Sie die Zertifizierungsprüfung zum IREB® CPRE RE@Agile Primer ablegen.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: IREBAP

IREB® Advanced Level – RE@Agile (IREBALAG)

Inhalt

■ Ziele & Vorteile von Requirements-Engineering im agilen Umfeld.

■ Techniken zur Formulierung von Vision & Zielen

■ Sauberen Abgrenzung des Kontext mit Use Cases, Prosa & Story Maps

■ Unterschiedliche Granularitäten von Anforderungen: Epics, Features, User Stories

■ Arbeiten mit User Stories: 3 C‘s, INVEST, Akzeptanzkriterien, Schneidetechniken, Story Maps

■ Richtiger Umgang mit Qualitätsanforderungen

■ Techniken zur Geschäftswertorientierter Priorisierung

■ Team-Organisationsformen bei komplexeren Problemstellungen

IREB® CPRE RE@Agile Primer (IREBAP)

Inhalt

■ Grundlagen für Requirements-Engineering im agilen Umfeld.

■ Ein beispielhafter High-Level Durchlauf durch die Require-ments-Engineering-Aktivitäten auf Produkt-, und Teamebene.

■ Artefakte im agilen Requirements Engineering: Epics, Features, User Story, Akzeptanzkriterien und Definition of Ready.

■ Backlog Management: Artefakte detaillieren, schneiden u. priorisieren.

■ Events im agilen Requirements Engineering.

■ Organisationssicht: Rollen und die notwendigen Kompetenzen im agilen Requirements Engineering.

■ Skalierung von Agile in grösseren Organsationen.

ZERTIFIZIERUNGZERTIFIZIERUNG

Recognized Training Provider

2020

Recognized Training Provider

20202020 2020

Page 45: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

45

Requirements

Kurzbeschreibung

Die Aufgabe eines Business Analysten ist sicherzustellen, dass Projekte, bzw. Investionen für das Unternehmen einen Mehr-wert erzeugen. Dies gilt um so mehr im agilen Umfeld. Die Rolle des BA ist aber in den meisten agilen Frameworks nicht klar. Es existiert keine weitestgehend akzeptierte Rollendefinition, kein Framework für den Agile BA – bis jetzt. Die agile Erweiterung des BABOK Guide v1.0 wurde in Zusammenarbeit mit der «Agile Alliance» entwickelt, eine der Mitgründer des Agile Manifesto. Die Erweiterung liefert einen akzeptierten Industrie Standard für die Business Analyse im agilen Umfeld.

Sie sind in der Lage, die Rolle des Business Analysten in agilen Vorhaben zu identifizieren. Sie können in agilen Entwicklungs-teams partizipieren und die Verantwortung des Business Ana-lysten sowohl zum Unternehmen als auch zum Team artikulie-ren. Das Agile Business Analysis Framework und seine Prinzipien werden verstanden und angewendet.

Der Kurs schliesst mit der 60-minütigen Prüfung zum Erlangen des Zertifikates «iSQI® Certified Agile Business Analysis» ab.

Weitere Details

■ Sprache: EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: CABA

Kurzbeschreibung

Sie befinden sich ein einem agilen Umfeld oder wollen auf ein agiles Vorgehen wechseln und möchten verstehen wie Product Management im Agilen eingesetzt werden kann. In diesem Kurs lernen Sie die agile Methoden und Tools kennen und wie diese erfolgreich eingesetzt werden können. Diese erlauben es Ihnen Produkte und neue Features zu lancieren und gleichzeitig kon-tinuierlich Kunden- und Marktfeedback einzuholen und in die Entwicklung einfliessen zu lassen.

Mit dem erlernten Basiswissen sind die Kursteilnehmer in der Lage in ihrer Organisation ein agiles Product Management auf-zusetzen oder konstruktiv weiterzuentwickeln. Sie wissen wie die gängigsten agilen Methoden mit dem Product Management verzahnt sind und verstehen die Abgrenzung der Rollen von Pro-dukt Manager und Product Owner. Ausserdem wissen sie wie aus einer Vision über Epics und Features eine Product Roadmap ent-steht, verstehen das Konzept vom Business Value und können Epics und Features priorisieren.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: APM

iSQI® Certified Agile Business Analysis (CABA)

Inhalt

■ Agile Ansätze

■ Business Analyse Methoden in agilen Projekten

■ Agile Business Analysis Discovery Framework

■ Review

Agile Product Management (APM)

Inhalt

■ Agile Methoden: Gemeinsamkeiten und Unterschiedee aus Sicht PM

■ Rollen, Product Manager vs. Product Owner

■ Lean Startup/Product-Market Fit

■ Business Model Canvas

■ Agile Requirements Engineering: Epic to Task

■ Business Value, Priorisierung

■ Personas und Minimum Viable Product (MVP)

■ A/B Testing, KPIs

ZERTIFIZIERUNG

Page 46: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

46

Business Architecture for Product Owners – Modellieren Sie Ihr Produkt!Auch wenn Scrum diverse Rollen, Events oder auch Werte emp-fiehlt, lässt die Vorgehensweise Spielraum für die konkrete Wahl von Tools und Methoden. Während sich Kanban-Boards und User Stories etabliert haben, ist der Einsatz von Enterprise- oder Business Architecture auf Team-Ebene bisher weniger verbreitet. Zu Unrecht, denn Business Architecture kann den Product Owner dabei unterstützen, über den Sprint hinaus die Weiterentwick-lung zu planen und dabei die Produkt-Vision und die Einflüsse sowie die Struktur der Backlog Items stets im Auge zu behalten.Die Visualisierungen helfen zudem dabei, Zusammenhänge zu verstehen und Anpassungen zu kommunizieren.

Der Paradigmenwechsel durch die Agilität hat bei vielen ent-wickelnden Teams Einzug gehalten. Scrum hat neue Massstäbe gesetzt: Die kurzen Entwicklungszyklen, direkte Kommunikation und kontinuierliche Verbesserungen sind heutzutage kaum mehr wegzudenken. Doch manche Aspekte gingen im Gerangel um Wichtigkeit etwas unter.Dazu gehören:

■ Die (nachhaltige) Dokumentation

■ Der Übergang von der Idee zur Implementierung

■ Die Planung über einen einzigen Sprint hinaus

Wenn nun Unternehmen sich nicht ganzheitlich zur Agilität bekennen und nur auf Team-Ebene mit Scrum arbeiten, kann zwischen der Unternehmensstrategie und dem Sprint Plan leicht eine Kluft entstehen: McGreal & Jocham nennen diese Kluft das «Product Management Vacuum». Dieses Vakuum führt dazu, dass die beiden Welten kaum ein gegenseitiges Verständnis ent-

wickeln kön-nen: Während Business-Sta-keholder die Auswirkungen ihrer Wünsche nicht ganzheit-lich verstehen, ist es für die Ent-wickler oft nicht klar, warum sie eine bestimmte Funktionalität überhaupt ent-wickeln.

Mitten in diesem Vakuum befindet sich der Product Owner, der diese Kluft schliessen will. Zur Verständigung zwischen diesen beiden Welten sagt jedoch ein Bild mehr als tausend Worte. Komplexe Zusammenhänge lassen sich in der Software Entwick-lung leichter mit «Boxes & Arrows» darstellen und besprechen als vergleichsweise in reiner Textform. Auch bei den Aufgaben eines Product Owners können Visualisierungen helfen, sei es zur Kommunikation, Planung oder Dokumentation.

Mit «Enterprise Architecture» lässt sich grundsätzlich das ganze Unternehmen abbilden und beinhaltet eine Vielzahl von Mo-dellen und Techniken. Ein Teilbereich der Enterprise Architectu-re – die «Business Architecture» (nach TOGAF) – fokussiert sich auf Elemente wie Geschäftsprozesse, Stakeholder oder Ziele. Entsprechend decken sich diese Elemente mit der Sprache des Product Owners, und überlässt das Solution Design bewusst den Entwicklern. Für den Product Owner ist es fundamental zu verstehen, wie etwas aktuell funktioniert, um den Wert und die Risiken einer Veränderung abschätzen zu können.

Um den Wert eines Produkts zu maximieren und den inkrementellen Weg zur Vision zu planen, braucht es Übersicht und Weitsicht – auch in einer agilen Welt und trotz Zeitdruck. Viele Aspekte und Abhän-gigkeiten beeinflussen die Weiterentwicklung des Produkts über einen Sprint hinaus. Die Anwendung von «User Story Maps» mag dabei zwar eine mittelfristige Perspektive aufzeigen, bedingt aber einerseits thematisch kohärente User Stories und zeigt zudem nur ungenügend den Einfluss auf das bereits bestehende Produkt auf. Durch die Modellierungstechniken der Business Architecture lässt sich ein individualisiertes Modell erstellen, welches die Bedürfnisse des Product Owners und die Ausprägungen des Produkts ideal abdeckt.

Um beispielhaft die Möglichkeiten dieser Modellierungstechni-ken aufzuzeigen, wurde eine Grundstruktur definiert, welche insbesondere dem Product Owner hilft, bei einem sich stetig ändernden Umfeld und Produkt nachhaltig die Übersicht zu behalten. Im folgenden Diagramm sieht man eine mögliche Struktur mit vier miteinander verbundenen Schichten:

■ «Product Management»: Hier wird die Vision des Produkts beschrieben, sowie Faktoren, welche diese beeinflussen sowie Ziele, die sich daraus ableiten.

■ «Users»: In der zweiten Schicht werden unterschiedliche Be-nutzer (-Gruppen) beschrieben, sowie ihre Charakteristiken und Berechtigungen.Product Management Vacuum zwischen Business

Strategie und Sprint Plan (McGreal & Jocham, 2018)

Page 47: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

47

Blog

■ «Channels»: In der nächsten Schicht wird beschrieben, über welche Kanäle die Benutzer mit dem Produkt interagieren und wie diese Kanäle ausgestaltet sind.

■ «Capabilities»: In der letzten Schicht wird das eigentliche Produkt und seine Funktionen beschrieben. Dazu gehören auch Abhängigkeiten oder Business Rules.

Die Grundstruktur sowie deren benötigte Komplexität ist na-türlich je nach Produkt individuell. Die Elemente der Struktur können dann in angemessener Flughöhe beschrieben und als nachhaltige Dokumentation verwaltet werden. Wie es Pro-dukt-Entwicklungen so an sich haben, wird das Produkt nicht so bleiben. Aber auch für Veränderungen ist die beschriebene Grundstruktur gewappnet:«Epics» oder andere Backlog Items lassen sich gut auf die Struktur legen (sozusagen als «Overlay»)um die Prioritäten und Impacts aufdie Roadmap transparent zu machen. Sobald ein Epic die «Definition of Done» erreicht, wird das darunterliegende Element angepasst.

Durch den präsentierten Ansatz lassen sich diverse Herausforde-rungen eines Product Owners auf einmal angehen:

■ Big Picture: Alle inhaltlich relevanten Aspekte für den Product Owner sind abgedeckt. Zudem ermöglicht die Ver-bindung des Produkts mit der Vision und Zielen (oberste der vier Schichten) den Mehrwert der einzelnen Entwicklungen transparenter zu machen.

■ Roadmap: Das Overlay der Backlog Items visualisiert welche Elemente des bestehenden Produkts betroffen sind. Dadurch können Prioritäten, Abhängigkeiten und Zusammenhänge identifiziert werden.

■ Slicing: Durch die Struktur des Ansatzes lassen sich Backlog Items ideal darauf platzieren und zerteilen («slicen»), ohne dass unnötige Abhängigkeiten geschaffen werden

■ Nachhaltige Dokumentation: Die Struktur gibt die Flughöhe vor und zeigt an, wann («Definition of Done») die Beschrei-bung für ein Element anzupassen ist

■ Visualisierung: Die visuelle Natur der gezeigten Struktur er-leichtert die Kommunikation mit Business-Stakeholdern oder Entwicklern

Diese Vorteile werden bei bestehenden Tools und Methoden zum Backlog-Management oft vernachlässigt, weswegen der dar-gelegte Ansatz diese bestehenden Instrumente ideal ergänzt. Die hochgradige Individualisierbarkeit ermöglicht es Ihnen, Ihr Produkt nach Ihren Bedürfnissen zu gestalten. Modellieren Sie ihr Produkt!

Stefan Durrer, Senior Consultant

Mögliche 4-schichtige Grundstruktur der Business Architecture für Product Owner’s

Backlog Items der Roadmap werden als Overlay über die Struktur gelegt

Page 48: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Requirements

48

Geschäftsprozesse analysieren (GPA)

Inhalt

■ Die Unterschiede zwischen Modellen und der Realität kennen

■ Zweck der Prozessmodellierung verstehen

■ Übersicht über den BPM Lifecycle erhalten

■ Mit BPMN modellieren können

■ Strategische und operative Prozessmodelle modellieren können (mit BPMN)

IQBBA® Certified Foundation Level – Business Analyst (IQBBA FL)

Inhalt

■ Grundlagen

■ Geschäftsanalyse und Prozessplanung

■ Anforderungserhebung

■ Anforderungsanalyse

■ Lösungsvalidierung

■ Werkzeuge und Techniken

■ Kompetenzen

■ Prozessverbesserung

■ Innovation, Design und Kunde

Kurzbeschreibung

Am Anfang eines jeden IT Projekts stehen immer die geschäft-liche Anforderung oder der Bedarf nach einem Produkt. Verbesserung oder Automatisierung von Geschäftsprozessen, Ausweitung der Software-System Funktionalität, Eröffnung neuer Einstiegskanäle für Kunden – das sind Beispiele für unter-schiedliche geschäftliche Anforderungen. Jede geschäftliche Anforderung muss dabei genau erforscht, analysiert und an eine bestimmte Situation angepasst werden. Genau das ist das Feld des Business Analysten. Der Erfolg eines Projekts hängt dabei von den Fähigkeiten und der Erfahrung des Business Analysten ab. Dazu sind spezifische Kompetenzen und standardisiertes Wissen notwendig.

Sie erlangen Kenntnisse von Definitionen und Hintergründen für die Geschäftsprozessmodellierung, Anforderungssammlung und Anforderungsanalyse sicher. Ausserdem vermittelt der Kurs grundlegendes Wissen für die Bereiche Design von Geschäfts-lösungen und der Arbeit im Bereich von Innovation.

Der Kurs schliesst mit der Zertifizierungsprüfung ab.

Weitere Details

■ Sprache: DE

■ Typ: öffentlich / firmenintern

■ Dauer: 3 Tage

■ Code: IQBBA FL

Kurzbeschreibung

scout [engl.] /skaut/ Nomen 1. Englische Bezeichnung für Pfadfinder 2. Jemand der Etwas aufspüren soll 3. Kundschafter Verb 1. Etwas oder jemanden an verschiedenen Plätzen suchen

Sind Sie ein Business Value Scout? Also stetig auf der Suche nach Möglichkeiten, um die Abläufe Ihres Unternehmens, Arbeitgebers oder Kunden zu verbessern und somit den Business Value zu erhöhen? Wenn ja, dann ist dieses Praxismodul für Sie!

Sie vertiefen Ihre Business Value Scouting Skills und lernen dabei gezielt «Waste» in Geschäftsprozessen zu identifizieren und zu vermeiden. Sie verstehen welchen Einfluss der Mensch und die Unternehmenskultur auf den Erfolg der Prozessverbes-serungs-initiativen hat und schärfen dabei Ihr Verständnis für kulturelle Erfolgsfaktoren. Sie kennen die Do’s and Don’ts der Prozessanalyse und können die Essentials der Modellierung mit BPMN anwenden.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: GPAV

ZERTIFIZIERUNG

Page 49: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

49

Requirements

Requirements Workshops (RWS)

Minimal Viable Product – MVP

Die Teilnehmer dieses Praxismoduls lernen das Konzept des agilen Requirements Engineerings mit Fokus auf MVPs (Minimal Viable Products) kennen. Ein MVP ist eine Produktversion oder eine Erweiterung eines Produktes, mit welcher man versucht, mit möglichst wenig Aufwand einen maximalen Lerneffekt bezüglich Kunde und Markt zu erzielen. Kern des Workshops bildet dabei das Thema, wie MVPs unter Berücksichtigung der Produkte-Vision bis in die einzelnen User Stories nachvollziehbar definiert werden können.

An mehreren Praxisbeispielen lernen die Teilnehmer nicht nur die agilen Artefakte Vision, Epic, Features und User Stories kennen, sondern auch wie diese mit Hilfe einer Product Roadmap, Product Backlog und Sprint Backlogs priorisert und eingeplant werden.

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: MVP

Stakeholderanalyse

Zwei Fliegen mit einer Klappe schlagen, so könnte man den Stakeholderanalyse Workshop am besten bezeichnen. Zum Einen hat jeder Teilnehmer am Ende des Workshops eine Stakeholder-analyse für sein Projekt oder Produkt durchgeführt, welche er direkt in den Arbeitsalltag mitnehmen kann. Zum Anderen teilen unsere Experten ihr Praxiswissen zum Thema Stakeholder-analyse gepaart mit wichtigen Punkten aus der Theorie. Sie zeigen auf, wie die Begriffe Stakeholder, Stakeholder Analyse und -Management zusammenhängen und welchen Mehrwert sie erzeugen können, wenn sie in Zukunft mehr als nur eine Liste von Personen als Resultat der Stakeholder Analyse erzeugen.

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: SHA

User Stories definieren & schneiden

Das beste an diesem Workshop ist das Resultat: Jeder Teilneh-mende nimmt zurechtgeschnittene User Stories für sein Produkt mit nach Hause. Die Stories sind priorisiert für die nächsten Sprints und perfekt abgestimmt mit der Roadmap des Produk-te- und Portfoliolevels. Wir wären aber nicht SwissQ, würden wir es beim Resultat belassen. In diesem Workshop schulen wir die Theorie und wenden diese gleich an, damit die Teilnehmenden zu eigenständigen Wiederholungstätern werden. Der Fokus liegt in diesem Praxismodul nicht ausschliesslich auf den User Sto-ries. So erfahren die Teilnehmenden auch den Zusammenhang zwischen der Portfolio-Sicht bis hin zu einzelnen Vorhaben und Produkt. Das Schneiden von User Stories, die in einer Iteration (Sprint) umgesetzt werden können, steht dabei ebenso im Vor-dergrund, wie die Betrachtung von unterschiedlichen Architek-turen und die Berücksichtigung von Akzeptanzkriterien.

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: USDS

Story Mapping

Sie haben ein ziemlich klares und stabiles Bild Ihres neuen Produkts erarbeitet und als Produkt-Vision dokumentiert. Daraus haben Sie Arbeitspakete abgeleitet (Epics) und evtl. auch schon eine grosse Zahl an Stories. Nun stellt sich Ihnen das Pro-blem, die vielen Arbeitspakete (Epics & Stories) in eine sinnvolle Reihenfolge zu bringen, um das Produkt in kleinen Schritten, ausgehend von einem MVP («Minimal Viable Product») zu er-stellen. Und natürlich möchten Sie mit jedem Release messbaren Business-Nutzen liefern. Die Story Map hat sich als wirkungsvol-les Mittel bewährt, ausgehend vom Businessnutzen, ein einfach verständliches Modell des zu bauenden Systems zu erstellen und funktionale Lücken zu identifizieren. In diesem Workshop gehen wir von Ihren vorhandenen Artefakten (Vision, Epics, Stories) aus und erstellen gemeinsam eine Story Map als Basis für den Releaseplan.

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: STM

Page 50: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Testing

50

Test

ing Kursangebote

Inhalt

■ ISTQB® Certified Tester Foundation Level (CTFL) 52

■ ISTQB® Agile Tester (CTAT) 52

■ ISTQB® Advanced Level – Test Manager (ALTM) 53

■ Agiles Testmanagement (ATMA) 53

■ ISTQB® Advanced Level – Test Analyst (ALTA) 56

■ Testdesign Power Kurs (TDES) 56

■ ISTQB® Usability Tester Foundation Level (CTUT) 57

■ Test Automation Insights (BPTA) 57

■ Performance Testing Insights (BPTI) 60

■ ISTQB® Advanced Level – Technical Test Analyst (ALTTA) 60

■ ISTQB® Advanced Level – Test Automation Engineer (ALTAE) 61

■ DevOps® Foundation (DOFL) 61

■ DevOps® Test Engineer (DOTE) 62

■ Testing Workshops (TWS) 62

Page 51: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

51

Testing

Page 52: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Testing

52

Kurzbeschreibung

In diesem Kurs werden Testern und Testmanagern die Grund-sätze des Testens in Agilen Projekten vermittelt. Sie erfahren, wie agile Vorhaben organisiert sind und lernen die verbrei-tetsten agilen Methoden kennen. Sie verstehen, wie sich agile Entwicklung sich von herkömmlichen Vorgehen unterscheidet, welche Position der Tester in der agilen Organisation einnimmt sowie die grundsätzlichen Agilen Testing Prinzipien, Praktiken, Prozesse und Tools.

Nach Abschluss dieses Kurses sind Sie in der Lage, sich in agilen Projekten zurecht zu finden. Sie können ihre bisherige Erfahrung in Testing Projekten an agile Projekte anpassen und agile Testmethoden und -techniken anwenden. Sie unterstützen agile Teams in der Planung testbezogener Aktivitäten. Nach dem Kurs sind Sie in der Lage, effizient in einem agilen Team und Projekt zu arbeiten und dieses kommunikativ zu unterstützen.

Der Kurs schliesst mit einer 60-minütigen Prüfung zum Erlangen des Zertifikates «ISTQB® Agile Tester» ab.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: CTAT

Kurzbeschreibung

Als wichtiger Bestandteil des Software-Entwicklungsprozesses ist Testen heute eine Daueraufgabe, die qualifizierte Fach- leute erfordert. Die Kenntnis anerkannter und etablierter Software-Testmethoden sowie die Verwendung einheitlich definierter Begriffe sind hierbei wichtige Voraussetzungen. DasCertified-Tester-Programm implementiert das weltweit standardisierte und anerkannte Certified Tester Qualifikations-schema.

Dieses Grundlagentraining behandelt Aufgaben, Methoden und Techniken des Softwaretestens. Sie lernen alle Schritte des Software-Testprozesses kennen, von der Planung über die Spezifikation bis zur Durchführung und Protokollierung von Tests.

Das Seminar schliesst mit einer 60-minütigen Prüfung zum Erlangen des Zertifikates «ISTQB® Certified Tester Foundation Level» ab.

Weitere Details

■ Sprache: DE / EN / FR

■ Typ: öffentlich / firmenintern

■ Dauer: 4 Tage

■ Code: CTFL

ISTQB® Agile Tester (CTAT)

Inhalt

■ Anpassung der Konzepte des ISTQB Foundation Level in agilen Projekten

■ Vorteile einer agilen Projektführung

■ Methoden und Prozesse

■ User Stories und Test Cases

■ Retrospektive, Continuous Integration

■ Iteration und Release Planning

■ Testaktivitäten in agilen und nicht agilen Projekten

■ Die Rolle unabhängigen Testens

■ Die Skills/die Rolle des agilen Testers in einem Scrum Team

ISTQB® Certified Tester Foundation Level (CTFL)

Inhalt

■ Grundlagen des Softwaretestens

■ Testen im Softwarelebenszyklus

■ Statischer Test

■ Dynamischer Test

■ Testmanagement

■ Testwerkzeuge

ZERTIFIZIERUNGZERTIFIZIERUNG

Page 53: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

53

Testing

Kurzbeschreibung

Dieser Kurs zeigt anhand von Good Practices und Beispielen auf, wie das Testmanagement im agilen Umfeld angepasst werden kann, um auf die veränderten Bedürfnisse reagieren zu können. Ausgehend von den Herausforderungen bei agilen Vorgehen wird aufgezeigt, was agiles Testen im Allgemeinen und agiles Testmanagement im Speziellen ausmacht. Es wird die Rolle des Test Masters in Abgrenzung zum klassischen Testmanagervorgestellt.

Sie lernen die Grundlagen und Vorgehensweisen des agilen Test-managements kennen und verstehen die Rolle des Test Masters.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: ATMA

Kurzbeschreibung

Im Fokus des Advanced Level Modul Test Manager stehen die speziellen Aufgaben und Aktivitäten, die ein Test Manager im Rahmen seiner täglichen Aufgaben planen und durchführen muss. Das Modul bietet eine spezielle Weiterführung in den Themen des Test Managements.

Aufbauend auf der Foundation Level Ausbildung vermittelt der Kurs vertiefte Kenntnisse im Bereich des Testmanagements, die sich für die tägliche Arbeit nutzen und integrieren lassen. Die praktische Umsetzung mit Hilfe von Übungen steht im Vordergrund.

Der Kurs schliesst mit einer 180-minütigen Prüfung zum Erlangen des Zertifikates «ISTQB® Certified Tester Advanced Level - Testmanager» ab.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 5 Tage

■ Code: ALTM

Agiles Testmanagement (ATMA)

Inhalt

■ Herausforderungen

■ Agiles Testen

■ Integration mehrerer Teams

■ Agiles Testmanagement

■ Test Master

ISTQB® Advanced Level – Test Manager (ALTM)

Inhalt

■ Grundlegende Aspekte des Softwaretestens

■ Testprozess

■ Testmanagement

■ Review

■ Fehler und Abweichungsmanagement

■ Standards im Testverbesserungs-Prozess

■ Soziale Aspekte und Teamzusammensetzung

ZERTIFIZIERUNG

Page 54: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

54

Tester sein ist nicht einfach

Wer kennt sie nicht, die alltäglichen Probleme, die uns als Software Tester begegnen? Zu wenig Zeit oder ungenaue oder fehlende Spezifikationen? Testdaten, die nicht zur Verfügung stehen oder veraltete Testfälle? In diesem Blog möchte ich dar-auf eingehen, welche Probleme uns immer wieder beschäftigen, wo der Ursprung dafür liegen und Lösungansätze aufzeigen, wie diese verhindert werden könnten.

Typische ProblemeDen folgenden 4 Problemen, begegnen wir Tester häufig und sie bereiten uns immer wieder Sorgen.

Problem der fehlenden Zeit – Probleme werden verursacht, weil bereits bei der Planung zu wenig Zeit für das Testen eingerech-net worden ist – oder es steht durch verschiedene Abklärungen oder Verzögerungen weniger Zeit für die Tests zur Verfügung als ursprünglich eingeplant war. Problematisch kann es insbesondere in traditionell geführten Projekten werden, wenn ein neues Sys-tem zu einem bestimmten Zeitpunkt fertiggestellt sein muss und dabei die Entwicklung länger dauert als geplant. Leider kommt es häufig vor, dass während der Tests sehr viele Fehler gefunden werden, welche korrigiert und neu geprüft werden müssen. Durch diese vielen Fehler und die dadurch notwendigen Fehlernach-tests, steht dann am Ende womöglich nicht mehr genügend Zeit für die Regressionstests zur Verfügung. Dies hat zur Folge, dass die Qualität darunter leiden kann.

Problem Spezifikationen – Spezifikationen führen zu Problemen, wenn:

■ diese ungenau oder unvollständig beschrieben sind

■ sie nicht verständlich sind

■ sie Interpretationsspielraum zulassen

■ sie nicht vorhanden sind

■ Änderungen daran während des Projekts ohne Information an die Beteiligten erfolgen

Bei nicht vorhandenen oder zu ungenau beschriebenen Spezi-fikationen (Requirements, User Stories etc.) ist nicht klar, auf was beim Testen geachtet werden muss, und ob ein bestimmtes

Verhalten korrekt ist oder nicht. Wie es sich im positiven Fall verhalten soll, ist meistens noch ausreichend beschrieben und verständlich. Aber wie sich das System beispielsweise verhalten soll, wenn Fehleingaben gemacht werden, wird meistens verges-sen. In klassisch geführten Projekten werden die Anforderungen zu Beginn detailliert erhoben. Diese müssen vor Entwicklungsan-fang vollständig und stabil sein. Wenn sich diese Anforderungen jetzt während der Entwicklung ändern, entsteht die Gefahr, dass die Tester nicht darüber informiert werden. Diese Gefahr sollte in agilen Projekten eher nicht auftreten, da dort eine enge Zusam-menarbeit zwischen Tester, Entwickler und Requirement Engineer erfolgen sollte.

Problem Testdaten – Ein weiteres Problem ist, dass benötigte Testdaten gar nicht, oder so unstrukturiert vorliegen, dass sie für Testfälle nicht verwendet werden können. Wenn Testdaten nicht vorhanden sind, müssen diese vom Tester zuerst zeitaufwändig erfasst werden. Ohne valide Testdaten ist auch die Testautomati-sierung unmöglich.

Problem ungenaue Testfälle – Wurden Testfälle von jemandem erstellt, der das System sehr gut kennt, wurde möglicherweise implizites Wissen zur Testausführung weggelassen. Diese In-formationen sind jedoch für Tester, die das System weniger gut oder gar nicht kennen, notwendig, um die entsprechenden Tests korrekt ausführen zu können. Wenn man mitten im Test fest-stellt, dass andere Daten hätten verwendet, oder eine bestimmte Vorbedingung hätte erfüllt sein müssen, wird durch ein erneutes Beginnen wieder Zeit benötigt. Durch ungenaue oder schlecht spezifizierte Testfälle wird die Organisation bezüglich neuer Tester auch sehr inflexibel. Man wird immer auf bestimmte Tester ange-wiesen sein, und zwar auf diejenigen die das System gut kennen. Die Einarbeitung neuer Test-Mitarbeiter lässt sich dadurch eher schwieriger gestalten. Dieses Problem wird noch verstärkt, wenn die Spezifikationen ungenau oder nicht vorhanden sind.

AuswirkungenEine nächste Frage die man sich stellen kann, ist, welche Auswir-kungen durch die beschriebenen Probleme entstehen können. Die oben beschriebenen Probleme machen nicht nur das Leben der Tester schwierig, sondern haben natürlich auch Auswirkung auf andere Stakeholder. Die Nachfolgende Tabelle zeigt auf, welche Auswirkungen die oben ausgeführten Probleme auf die einzelnen Projekt- resp. Organisationsrollen haben können.

Page 55: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

55

Blog

Projekt-Sponsor – Die Probleme führen dazu, dass die Kosten steigen, die geforderte Qualität nicht erreicht wird oder die Ein-führung mit einer Verzögerung erfolgt. Dies alles wird folgen für das Budget haben. Will man das Ruder umwerfen, muss das Budget wahrscheinlich erhöht werden.

Tester – Muss seine Arbeit unter erschwerten Bedingungen durchführen. So können möglicherweise am Ende bei einem Re-lease die manuellen Regressionstestfälle nicht mehr durchgeführt werden, weil es dafür keine Zeit mehr gibt. Dadurch können noch unentdeckte Probleme im System vorhanden sein, die sich dann im produktiven System negativ bemerkbar machen. Eine mögliche Demotivierung der Tester sollte man nicht unterschätzen.

Projektleiter – Werden mehr Test-Ressourcen benötigt, um zur geforderten Zeit fertig zu sein, entsteht die Frage für den Projekt-leiter wo er diese zusätzlichen Ressourcen herholen soll. Gute Tester findet man bekanntlich nicht wie Sand am Meer. Auch eine verspätete Einführung oder eine ungenügende Qualität, wird auch den Projektleiter nicht glücklich machen. In der heutigen Zeit, wo Zeitdruck und Konkurrenzdruck enorm sind, muss auf die Time-to-Market geschaut werden. Eine verzögerte Einführung im Markt hat eine Benachteiligung gegenüber der Konkurrenz zur Folge. Ein frühzeitiger Einbezug der Tester und dadurch ein frühe-res Entdecken und Beheben von Fehlern, kann ein wesentlicher Wettbewerbsvorteil sein.

Endbenutzer – Die Endbenutzer sind schlussendlich die Leidtra-genden, wenn die Qualität des Produktes zu wünschen übriglässt. Durch fehlende Zeit oder ungenaue Spezifikationen könnte der Endbenutzer ein fehlerhaftes Produkt erhalten oder sogar ein Pro-dukt, dass er in der ausgelieferten Form so nicht gewünscht hat.

LösungenSchlussendlich kann man sich fragen, wie die oben erwähnten Probleme verhindert werden können.

Genaue Planung und gute Kommunikation – Häufig liegt der Ursprung in der mangelhaften Planung oder ungenügenden Kommunikation. Wenn beispielsweise die Planung der benötig-ten Ressourcen (Tester, Zeit) nicht exakt genug gemacht wird, Terminverschiebungen nicht genug früh mitgeteilt werden, kann es dazu kommen, dass ursprünglich eingeplante Tester nicht mehr ausreichend oder gar nicht mehr zur Verfügung stehen. Eine gute Aufwandschätzung kann helfen, die benötigten Ressourcen möglichst genau festzulegen. Änderungen zur ursprünglichen Planung, wie z.B. Terminverschiebungen oder Änderungen an An-forderungen sind, wenn diese nicht verhindert werden können, möglichst rasch allen Beteiligten mitzuteilen. Wenn sich Spezi-fikationen während des Projektes ändern und dies entsprechend und frühzeitig kommuniziert wird, ist dies weniger problematisch, als wenn man dies erfährt, nachdem die geänderten Anforderun-gen schon implementiert wurden.

Review der Spezifikation – Um unvollständigen oder unklaren Spezifikationen vorzubeugen, sollte man diese zu einem frühen Zeitpunkt im Projekt reviewen lassen. Damit die Testbarkeit der Anforderungen gegeben ist, müssen die Tester unbedingt in das Review involviert werden. Die Spezifikationen können dann an-hand des Feedbacks angepasst und verbessert werden. Im agilen

Bereich kommt hier das Tres Amigos Prinzip oder auch Power of Three Konzept zum Zug, bei dem durch den gemeinsamen Ein-bezug der Tester, Entwickler und Fachvertreter die Spezifikationen verfeinert werden und eine frühe und regelmässige Rückmeldung erfolgen kann. Dadurch können Missverständnisse bezüglich der Anforderungen vermieden werden, die ansonsten erst im Laufe des Entwicklungs-Zyklus erkannt würden.

Gute Testdaten – Die für die Tests benötigten Testdaten stehen spätestens zu Beginn der Testausführung zur Verfügung. Hier-durch können Verzögerungen des Testanfangs verhindert werden.

Gute Testfälle – Bei der Erstellung von Testfällen ist darauf zu achten, die relevanten Informationen, wie beispielsweise die Vor-bedingungen, die Nachbedingungen, die einzelnen Schritte, die einzugebenden Daten zu beschreiben und keine wichtigen Infor-mationen zu vergessen resp. wegzulassen. Es darf nicht vergessen werden, bei Änderungen am System, die vorhandenen Testfälle und Regressionstestfälle entsprechend anzupassen.

Agiles Vorgehen – In traditionell geführten Projekten, wo spät mit dem Black Box Testing begonnen wird, erhalten die Entwickler spät ein Feedback über die Qualität der Software. Entsprechend spät können die Fehler behoben und erneute Tests durchgeführt werden. Hierdurch wird das Risiko auf Projekt Verzögerungen er-höht. Diese Problematik wird in agilen Projekten entschärft, da sich der Testaufwand durch die Aufteilung in jeweilige Sprints mehr über das gesamte Projekt verteilt. Dadurch erhalten die Entwickler früher ein Feedback und Bugs können frühzeitig korrigiert werden.

FazitIn vielen Projekten wird das Leben der Tester durch die oben er-wähnten Probleme unangenehmer gemacht. Dass Tester dadurch nach einer gewissen Zeit womöglich demotiviert werden, ist nicht auszuschliessen. Logischerweise führt dies zu abnehmender Testqualität. Wenn man dann nicht aufpasst, setzt eine Negativ-spirale ein. Unabhängig davon, ob diese Projekte klassisch oder agil geführt werden Es ist also wichtig, die Probleme frühzeitig aufzudecken und entsprechende Massnahmen einzuleiten. Durch einfache Änderungen oder Anpassungen an der Vorgehensweise kann uns das Testen angenehmer gemacht und somit die Qualität relativ einfach gesteigert werden. Wichtig ist dabei, die aufge-deckten Probleme als tatsächliche Probleme anzuerkennen. Das bedingt eine Offenheit gegenüber Fehlern und Problemen. Also eine Fehlerkultur mit einem Klima des Problemlösens. Nur so ist man in der Lage, das Testing und damit die Produktqualität zu verbessern.

Regina Meyer, Test Consultant

Page 56: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Testing

56

Kurzbeschreibung

Beim Testdesign hat der Tester im Grunde eine ähnliche Aufgabe wie die Systemarchitekten und Entwickler: aus Anforderungen vollständige und eindeutige Testfälle zu ermitteln. In der Theorie mittels Black-Box Techniken eine einfache Sache, in der Praxis kommen diese aber (zu) selten zum Einsatz. In diesem Kurs wird einerseits darauf eingegangen wie durch eine frühzeitige und systematische Testvorbereitung die Qualität der Anforderungen und somit des Tests gesteigert werden. Andererseits werden - jenseits der bekannten Black Box Techniken - diverse Methoden und Techniken eingesetzt um aus unterschiedlichen Arten von Anforderungen effizient Testfälle abzuleiten und zu dokumen-tieren.

In diesem Kurs wird aufgezeigt, wie auf effiziente Art und Weise Testfälle abgeleitet werden können, die systematisch die wichtigen Aspekte des Systems abdecken. Sie erweitern Ihren Werkzeugkoffer mit einfachen Methoden und Techniken für die Praxis.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: TDES

Kurzbeschreibung

Neben einer starken praktischen Auslegung auf die Inhalte, liegt der Schwerpunkt des Modul Test Analyst auf der fachlichen Analyse von Spezifikationen und Testfallerstellung im Black-Box-Testen. Im Fokus stehen die speziellen Aufgaben und Aktivtäten, die ein fachlicher Tester täglich durchführen und planen muss. Das Modul bietet eine spezielle Weiterführung der genannten Themen. Ziel ist es, Ihnen eine qualifizierte Ausbildung zu ver-mitteln, deren Inhalte die tägliche Testarbeit unterstützen.

Aufbauend auf der Foundation Level Ausbildung vermittelt der Kurs vertiefte Kenntnisse zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests auf Black-Box Ebene und zum Review.

Der Kurs schliesst mit einer 180-minütigen Prüfung zum Erlangen des Zertifikates «ISTQB® Certified Tester Advanced Level - Test Analyst» ab.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 4 Tage

■ Code: ALTA

Testdesign Power Kurs (TDES)

Inhalt

■ Identifizieren von Testobjekten (z.B. mit Story Mapping)

■ Anforderungen an Anforderungen

■ Risikobasiertes Vorgehen

■ Arbeiten mit Abnahmekriterien

■ Ableiten von Testfällen

ISTQB® Advanced Level – Test Analyst (ALTA)

Inhalt

■ Testprozess

■ Testmanagement

■ Testverfahren

■ Softwarequalitätsmerkmale

■ Reviews

■ Fehlermanagement

■ Testwerkzeuge

ZERTIFIZIERUNG

Page 57: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

57

Testing

Kurzbeschreibung

Möchten Sie erfolgreich Testautomatisierung in Ihrer Organisation einführen, wollen Sie die bestehende Testautomatisierung auf ein höheres Niveau bringen oder haben Sie Schwierigkeiten mit einer stabilen und zuverlässigen Testautomatisierung? Dann ist dieser Kurs genau das richtige für Sie. Es werden die Voraus-setzungen, das Vorgehen als auch die Herausforderungen der Testautomatisierung aufgezeigt und detailliert besprochen.

Nach dem Kurs können Sie die verschiedenen Arten der Test-automatisierung unterscheiden. Sie kennen das Best Practice Vorgehen der Testautomatisierung und sind sich den Stolper- steinen bei der Testautomatisierung bewusst.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: BPTA

Kurzbeschreibung

Eine gute User Experience (UX) eines Produkts ist ein wesent-licher Aspekt für dessen Erfolg. Damit Benutzer ein Produkt akzeptieren und weiterempfehlen genügt reine Funktionalität nicht: sie muss benutzerfreundlich umgesetzt sein und beim Benutzer nach dem Gebrauch ein gutes Gefühl hinterlassen. Der Bereich Testing kann einen wesentlichen Beitrag zur guten UX beitragen, indem entsprechende Testaktivitäten vorgesehen und von qualifizierten Fachleuten vorbereitet und durchgeführt wer-den. Dieser Kurs vermittelt das Grundwissen und die wichtigsten Methoden um UX und Usability zu testen sowie die notwendigen Entscheidungskriterien, um die verfügbaren Methoden auf das Projekt hin adäquat auszuwählen.

Der Kurs vermittelt vertiefte Kenntnisse zu Usability und Usa- bility Testing. Nach Abschluss dieses Kurses können SIe die UX und Usability von Softwareprodukten mit den gängigsten Methoden testen und verfügen über das dazu nötige Grund- lagenwissen.

Der Kurs schliesst mit einer 60-minütigen Prüfung zum Erlangen des Zertifikats «ISTQB® Usability Tester Foundation Level» ab.

Weitere Details

■ Sprache: DE

■ Typ: öffentlich / firmenintern

■ Dauer: 2 Tage

■ Code: CTUT

Test Automation Insights (BPTA)

Inhalt

■ Grundlagen Testautomatisierung

■ Best-Practice Ansatz in der Testautomatisierung

■ Voraussetzungen und Vorgehen / Methode der Testautomatisierung

■ Stolpersteine der Testautomatisierung

ISTQB® Usability Tester Foundation Level (CTUT)

Inhalt

■ Grundlegende Aspekte der User Experience (UX) und Usability

■ Prozess zur Gestaltung gebrauchstauglicher Systeme ISO 9241-210

■ Usability und Accessibility Standards

■ Usability Reviews

■ Usability Tests

■ Fragebogen

ZERTIFIZIERUNG

Page 58: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Blog

58

Ein Austausch mit dem Test Lead Luca(Aus Trends & Benchmarks Studie Schweiz: https://report.swissq.it)

«Ich kann mich noch ganz gut dran erinnern, als ich von einer neuen Mitarbeiterin nach meiner Rolle gefragt wurde und sie mit meiner Antwort ‹Ich bin Tester› nichts anfangen konnte: ‹Ich meine beruf-lich!?›. Dieses Gespräch hat mir damals klar gemacht, wie jung meine Rolle als Tester noch ist , und dass sie vielleicht noch nicht so richtig akzeptiert ist. Ich war gespannt, was die Zukunft mit sich bringt und wie sich die Tester-Rolle ändern wird.»

Das Testen ist heute ein wichtiger anerkannter Baustein der Software Entwicklung. Bei einer Befragung zum Thema der Ver-änderung der Tester-Rolle, hat sich gezeigt, dass es um 4.7% mehr Personen gibt, welche von einer Veränderung überzeugt sind, als Befragte, die nicht an eine Veränderung glauben. Nur 10.5% der gesamten Anzahl der Befragten, haben keine Mei-nung dazu.

Shift Left: eine Notwendige Entwicklung

«Als Tester habe ich während meiner 10-jähriger Er-fahrung gelernt, mich immer wieder an die neuen Entwicklungen anzupassen und neue Fähigkeiten zu erlernen – zuerst in den Phasen der Professionalisie-rung und Standardisierung, zuletzt bei der Zentrali-sierung in Test Factories. Jetzt heisst es: Agil! Ich freue mich zwar bereits darauf, jedoch zwingen Verände-rungen immer dazu, Neues zu erlernen und sich tech-nisches Wissen anzueignen.»

Definitiv! Es reicht nicht mehr nur ein Chamäleon zu sein! Die kurzen Release-Zyklen und die damit verbundenen kurzen Zeit-räume für das Testing fordern von den Testern nicht nur eine enge Zusammenarbeit mit den Entwicklern, sondern auch eine geistige Flexibilität. Zuerst geht es darum, Agilität in bisher traditionell geführten Projekte einzubringen. Dies erlaubt es, die Komplexität von Software Produkten herunterzubrechen. Die kleine Softwarepakete werden in kurzen iterative Zyklen umge-setzt, getestet und deployed. In einem typischen traditionellen Setup, wird zu wenig Zeit für Testing oder die Implementierung der Features durch die Entwickler eingeplant. Dies führt meis-tens dazu, dass die Tester ungenügend Zeit für Testdurchfüh-rung, Fehlernachtest und Regressionstest zur Verfügung haben. Die Qualität wird dadurch negativ beeinflusst. Durch Agilität erhalten Entwickler früher Feedback über die Qualität. Dadurch sind die Entwickler in der Lage, Fehler frühzeitig zu korrigieren. Dann gibt es nur noch eine Testphase, die als isolierter eigen-ständiger Schritt am Ende des Entwicklungszyklus stattfindet: der Abnahmetest. Dieser findet nach dem Abschluss des letzten Sprints statt und kann selbständig vom Kunden oder mit Hilfe der Spint-Tester ausgeführt werden. Mit anderen Worten, das Testen fällt nicht komplett aus, sondern es wird verteilt über die einzelnen Iterationen (Sprints). Ein weiterer Vorteil der Agili-tät ist, dass die Tester schon bei Design-Meetings anwesend sind. Sie sind dadurch in der Lage in einer sehr frühen Phase, noch bevor die Implementierung anfängt, Fragen zu stellen und Testideen sowie mögliche Test-Szenarien zu kreieren. Dadurch fühlen sich die Tester vertrauter mit dem Projekt und entwickeln ein früheres Verständnis für die Software und Technologien. Wir sprechen hier von der «Linksverschiebung» des Testings oder auch vom «Shift-Left»-Testing.

Rolle des Chamäleons – Vergangenheit und Zukunft

Verändert sich die Tester Rolle?

Page 59: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

59

Blog

Die unten stehende Grafik verdeutlicht das «Shift-Left»-Testing: Das Business Risiko wird so früh wie möglich durch Testfälle abgedeckt. Dies wird erreicht indem die meisten Testfälle auf der zuunterst liegenden Test-Stufe entsprechend der Testpyra-mide erstellt werden. Kurz gesagt, findet das Testing näher bei der Entwicklung statt. Durch dieses «Shift-Left»-Testing wird ein konstantes, schnelles und frühes Feedback über die Qualität eines Produkts ermöglicht. Fehler werden somit viel früher gefunden und verbleiben weniger lang in der Applikation.

Shift Left: eine Notwendige Entwicklung

«Der neuste Hype ist nun DevOps. In Zukunft soll alles automatisch gehen. Da frag ich mich, was das in mei-ner Welt ändern würde. Die Investitionen verschieben sich jedenfalls weg von Testing, hin zu DevOps.»

Mehr als die Hälfte der Unternehmen in unserer Studie, erhöhten ihre Investitionen in DevOps signifikant (23.6%) oder leicht (28.1%).

Bei dem oben beschriebenen traditionellen Setup, wo die Tester meistens ungenügend Zeit für ihre Tests haben, entspricht das End-Ergebnis sehr oft fehlerhaften Software und einem schlechten Ruf der Entwickler. Um diese Situation zu vermeiden, sollte im ersten Schritt, ein agiles Konzept eingeführt werden. Als Nächstes wird der agile Prozess mit DevOps (Development & Operation) einen Schritt weiter geführt. Die agile Software-entwicklung ändert die Art und Weise wie in den Teams pro-grammiert wird. DevOps hingegen stellt einen Wandel in der Unternehmenskultur dar und beschreibt einen Prozess-Verbes-serungsansatz und zwar die Art, wie Software in Betrieb genom-men und betrieben wird. DevOps soll durch gemeinsame Prozes-se eine effektivere und effizientere Zusammenarbeit der DevOps Bereiche ermöglichen. DevOps entspricht in diesem Fall der logischen Weiterentwicklung von Agilität. Dabei ist anzumerken,

dass Agilität keine notwendige Voraussetzung für DevOps ist. Um die Vorteile von DevOps vollumfänglich zu nutzen, sollte die Agilität in gewissem Masse in der Organisation etabliert sein.

Neue HerausforderungenSoftware Firmen sind vermehrt folgender Herausforderung ge-stellt: dem Gegensatz zwischen der Time-To-Market und dem Wunsch des Kunden nach einem schnelleren Releasezyklus. Defects sollen schneller behoben und die Korrekturen schneller dem Kunden zur Verfügung gestellt werden. Die Firmen müssen also vermehrt in DevOps Prozesse investieren. Mit DevOps sollen die Qualität der Software, die Geschwindigkeit der Entwicklung und der Auslieferung sowie die Zusammenarbeit der Beteiligten im DevOps-Team (Design, Development, Test und Operations) verbessert werden. Auf der Business-Ebene sollten die Umsätze durch zufriedenere Kunden erhöht werden. Diese Steigerung der Kunden-Zufriedenheit verlangt wiederum das Liefern hochqua-litativer Funktionen. Das ganze kann nur erreicht werden, wenn das DevOps-Team in jeder Phase des gesamten DevOps-Prozes-ses testet und damit die Probleme effizienter angeht. Deswegen ist das kontinuierliches Testen (Continuous Testing) nicht von DevOps zu trennen. Dabei muss angemerkt werden, dass das «Continuous Testing» nur mittels einer Automatisierung der Testausführung gestaltet werden kann. Continuous Testen bedingt also den Aufbau der Testautomatisierung.

Folgende Grafik veranschaulicht, dass das Continuous Testing während des gesamten DevOps Prozesses integriert werden muss.

Es ist spannend, was die Zukunft für die Tester-Rolle mit sich bringt. Wir sind jedoch davon überzeugt, dass der Software- Tester Job auf jeden Fall genauso spannend bleibt. Haben Sie Probleme bei der Umsetzung von Agilität oder DevOps, zögern Sie bitte nicht uns zu kontaktieren. Ihr Erfolg ist auch unser Erfolg!

Taiab El Berkhami, Test Consultant

Shift-Left-Testing

Investitionen in DevOps

DevOps: Continuous Testing

Page 60: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Testing

60

Kurzbeschreibung

Schwerpunkte des Modul Technical Test Analyst sind die praktische Anwendung der Inhalte und die Vermittlung von weiterführendem Wissen im White-Box-Testen. Themen sind u.a. die Kontroll- und Datenflussanalyse sowie Metriken und Kodierungsrichtlinien. Der Fokus dieses Moduls liegt somit auf der technischen Arbeit eines Testers und den von ihm zu testenden Testobjekten.

Aufbauend auf der Foundation Level Ausbildung vermittelt der Kurs vertiefte Kenntnisse zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests auf White-Box Ebene.

Der Kurs schliesst mit einer 120-minütigen Prüfung zum Erlangen des Zertifikates «ISTQB® Certified Tester Advanced Level - Technical Test Analyst» ab.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 3 Tage

■ Code: ALTTA

Kurzbeschreibung

Jeder Tester wird früher oder später mit Last- und Performance- Tests (LuP-Tests) konfrontiert. Was in der Theorie unproblematisch erscheint, wird in praktisch jedem Projekt zu einem langwierigen und komplizierten Thema. Jeder Stakeholder versteht unter Performanz eines Systems etwas anderes. Darum ist eine an-gemessene Strategie und das passende Vorgehen der Schlüssel zum Erfolg.

Nach diesem Kurs können Sie nicht funktionale Anforderungen für Last und Performance bewerten und notwendige Verbesserungen identifizieren. Anhand des Vorgehensmodells (für klassische und agile Vorgehen), dessen einzelne Phasen detailliert behandelt werden, lernen Sie das prinzipielle Vorgehen bei Last- und Per-formance-Tests kennen. Die Planung, Toolauswahl und ange-messene Umsetzung der LuP-Tests ist ein wichtiger Bestandteil dieses Trainings.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: BPTI

ISTQB® Advanced Level – Technical Test Analyst (ALTTA)

Inhalt

■ Risikobasiertes Testen

■ Strukturbasiertes Testen

■ Analytische Techniken

■ Qualitätsmerkmale

■ Technical Testing Reviews

■ Test Tools und Automation

Performance Testing Insights (BPTI)

Inhalt

■ Grundlagen Performance Testing

■ Nicht funktionale Anforderungen LuP

■ LuP Vorgehensmodell

■ Tools, Lasttestprofile, Performance KPI

■ Baselining, Lego-Bauweise, Service Virtualisierung

ZERTIFIZIERUNG

Page 61: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

61

Testing

Kurzbeschreibung

DevOps® verspricht kürzere Entwicklungs- und Releasezyklen und eine verbesserte Zusammenarbeit zwischen der Entwicklung und dem Betrieb. DevOps® ist dabei mehr als eine Methode oder Organisationsform, sondern ein Mindset basierend auf agilen Vorgehen. Dabei stehen die Kommunikation, Zusammenarbeit, Integration als auch die Automatisierung im Zentrum des DevOps® Foundation Kurses, damit ein verbesserter Arbeitsfluss («flow of work») zwischen der Entwicklung und dem Betrieb entstehen kann.

Mit der Hilfe von DevOps® Konzepten, «real-life» Fallstudien, Gruppendiskussionen und Übungen erwerben Sie das DevOps® Grundwissen, als Vorbereitung für die DevOps® Foundation Zertifizierung.

Im Anschluss zum Kurs kann eine 60-minütige Online-Prüfung zum Erlangen des Zertifikats abgelegt werden.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: DOFL

Kurzbeschreibung

A Test Automation Engineer (TAE) is one who has broad know-ledge of testing in general, and an in-depth understanding in the special area of test automation. An in-depth understanding is defined as having sufficient knowledge of test automation theory and practice to be able to influence the direction that an organization and/or project takes when designing, developing and maintaining test automation solutions for functional tests.

You will learn to evaluate tools and technology for test auto-mation and what to consider when building a test automation architecture. The course covers the transition of testing from manual to an automated approach, the creation of automated test reporting and metrics collection. The facilitation of main-tainability and addressing of evolving (test) systems is also included.

The course concludes with a 90-minute examination to obtain the certificate «ISTQB® Certified Tester Advanced Level - Test Automation Engineer».

Weitere Details

■ Sprache: DE / EN, Kursunterlagen und Prüfung auf Englisch

■ Typ: öffentlich / firmenintern

■ Dauer: 3 Tage

■ Code: ALTAE

DevOps® Foundation (DOFL)

Inhalt

■ DevOps® Ziele und Vokabular

■ Aufzeigen der Benefits von Business und IT

■ Prinzipien und Praktiken von Continuous Integration, Continuous Delivery, Testing und Security

■ DevOps® und deren Beziehung zu Agile, Lean und ITSM

■ Verbesserte Workflows, Kommunikation- und Feedbackschleifen

■ Automatisierungspraktiken inklusive Deployment Pipeline und DevOps® Toolchain

■ Kritische Erfolgsfaktoren und KPIs

ISTQB® Advanced Level – Test Automation Engineer (ALTAE)

Inhalt

■ Test Automation

■ Preparing for test automation

■ The generic test automation architecture

■ Deployment risks and contingencies

■ Test automation reporting and metrics

■ Transitioning manual testing to an automated environment

■ Verifying the test automation solution

■ Continuous improvement

ZERTIFIZIERUNGZERTIFIZIERUNG

Page 62: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Testing

62

Kurzbeschreibung

Mit DevOps® werden nicht nur die Organisations-Silos zwischen Entwicklung und Betrieb, sondern auch zum Test aufgebrochen. Aufbauend auf dem DevOps® Foundation legt dieser Kurs den Schwerpunkt auf das Testing innerhalb einer DevOps® Umgebung. Dabei werden Aspekte wie Teststrategien und -management, Testtools und Testautomatisierung sowie deren Integration in die DevOps® Toolchain, Testinfrastruktur und zugehörige Best Practices behandelt.

Mit Hilfe von Beispielen, Übungen und Gruppendiskussionen erfolgt eine vertiefte Auseinandersetzung mit Testing in DevOps®, als Vorbereitung für die DevOps® Test Engineer Zertifizierung.

Im Anschluss zum Kurs kann eine 90-minütige Online-Prüfung zum Erlangen des Zertifikats abgelegt werden.

Weitere Details

■ Sprache: DE / EN, Kursunterlagen und Prüfung auf Englisch

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: DOTE

DevOps® Test Engineer (DOTE)

Inhalt

■ Die Vorteile, Konzepte und Vokabular von Testing in DevOps

■ Wie sich DevOps® Testing von anderen Testvorgehen unterscheidet

■ DevOps Teststrategie und -Management

■ Vorgehen bei der Toolauswahl

■ Implementierung von Testautomatisierung

■ Integration von DevOps® Testing in Continuous Integration und Continuous Delivery

■ Wie DevOps® Tester in eine DevOps Kultur und Organisation passen

ZERTIFIZIERUNG

Testing Workshops (TWS)

Abnahmeprozess erfolgreich gestalten

Moderne Software Systeme kosten in der Entwicklung sehr viel. Umso wichtiger ist es den Abnahmeprozess und die voran-gehenden Aktivitäten so zu gestalten, dass eine erfolgreiche Abnahme gemacht werden kann, respektive das Produkt anhand objektiver Kriterien zurückgewiesen werden kann. Der Kunde muss dabei den Ersteller (ob dieser intern oder extern ist) in die Pflicht nehmen und auf die Einhaltung der Prozesse und die zeitgerechte Lieferung der vereinbarten Testdokumente und -Nachweise bestehen.

In diesem Workshop unterstützen wir Sie in der Gestaltung eines erfolgreichen Abnahmeprozess. Unter der Moderation eines erfahrenen Test Coaches werden gemeinsam die Aus- prägung, Gestaltung und die wichtigste Elemente des Ab- nahmeprozess definiert. Hierbei orientieren wir uns am SwissQ 4 Phasen Abnahme-Model.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: ABN

Testkonzept in 1 Tag

Sie benötigen ein Testkonzept bzw. eine Teststrategie für ihr Projekt oder Produkt. An diesem Workshop erarbeiten Sie gemeinsam mit einem unserer erfahrenen Testmanager die wichtigsten Grundlagen. Das Ziel ist nicht ein 50-seitiges Dokument zu erstellen, sondern konkrete Inhalte welche in ein Testkonzept eingearbeitet werden können. Unter Anwendung des V-Modells bzw. der Testpyramide wird das Testvorgehen definiert.

Wer testet was, wie, auf welcher Umgebung. Vollständiges Testen ist nicht möglich. Daher erfolgt die Festlegung der Test-ziele pro Teststufe unter Berücksichtigung der Ressourcen Zeit und Qualitätsrisiken, die Festlegung der Testziele pro Teststufe. Zuletzt erfolgt eine erste grobe Testplanung.

Die Resultate werden auf Flipchart dokumentiert und können dann in ein Testkonzept eingearbeitet werden. Die Vorlage dazu stellen wir Ihnen gerne zur Verfügung.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: TKO

Page 63: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

63

Testing

Testprozess Optimierung

Testen ist nicht umsonst. Umso wichtiger ist es die Testaktivitäten effizient zu gestalten. Sie spüren aber, dass in Ihrem Projekt oder in Ihrer Organisation das Testmanagement, Testdesign und die Testausführung nicht effektiv und effizient gestaltet sind. Sie sind sich nur nicht sicher wo die Probleme bzw. Ursachen genau liegen und wo Sie mit den Verbesserungsmassnahmen ansetzen sollen.

Unter der Moderation eines erfahrenen Test Coaches, werden zusammen mit Ihren Stakeholdern die «Pain-Points» aufgenom-men, analysiert und priorisiert. Am Ende des Workshops haben Sie einen Konsens über die Massnahmen die notwendig sind um Ihre Testvorgehen spürbar zu verbessern.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: TPO

Test Transformations Kickoff

Sie möchten von einer traditionellen Testorganisation in eine agile Organisation wechseln? Leider geht das meist nicht von heute auf morgen. Wenn Sie eine Transformation, egal ob klein oder gross, anstossen wollen, sollten Sie sich deshalb vorgängig einige Gedanken zur Zielsetzung machen und den Rahmen ab-stecken. Wir unterstützen Sie dabei mit diesem Workshop unter der Moderation eines erfahrenen, agilen Test Coaches und der Verwendung des Lean Change Canvas. Gemeinsam erarbeiten wir die Haupttreiber für die Veränderung, die Vision des Soll- zustandes, die richtigen Messgrössen und die nächsten Schritte um den Veränderungsprozess anzugehen.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: TTK

JIRA mit Test Add-on

Testfall-Management mit JIRA: geht das? Mit einem geeigneten Test Add-On ist es möglich, mit JIRA Testdesign- und Testaus- führungsaktivitäten zu planen und gestalten, ohne ein zusätz-liches Tool für das Testmanagement benutzen zu müssen.

Wir zeigen Ihnen, wie Sie mit einem JIRA Test Add-On, die System-, Abnahme- und Regressionstestfälle erfassen können. Auch wird anschaulich gezeigt, wie Testpläne, Testausführungen und die notwendigen statistischen Auswertungen gestaltet werden. Ein Test Coach mit JIRA Erfahrung zeigt Ihnen, wie ein für Sie passender Setup aussehen könnte. Sie lernen Hands-On, wie das Testfall-Management in JIRA aufgebaut werden kann. Am Ende des Workshops sind Sie in der Lage, in Ihrer Organisation JIRA mit einem Test Add-On erfolgreich einzuführen und so Ihre Testaktivitäten mit JIRA erfolgreich zu gestalten.

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: JTA

Page 64: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

64

Agile Testing Framework

ORGANIZATIONAL OPTIONS

Each Team Member

Embedded TesterSeparate Test Team (tester assigned to team)

Separate Test Team

ITERATION

RELEASE

BIG PICTURE AGILE TESTING

© SwissQ, Version 2.2 (10.2019)

ISO 25010 SW QUALITY CHARACTERISTICS

Functional completenessFunctional correctnessFunctional appropriateness

FunctionalSuitability

Time behaviourResource utilizationCapacity

Performancee�ciency

System/So�ware Product Quality

Co-existenceInteroperability

Compatibility

AppropriatenessrecognizabilityLearnabilityOperabilityUser error protectionUser interface aestheticsAccessibility

Usability

MaturityAvailabilityFault toleranceRecoverability

ReliabilityCon�dentiality

Integrity

Non-repudiation

Accountability

Authenticity

Security ModularityReusabilityAnalysabilityModi�abilityTestability

Maintainability

AdaptabilityInstallabilityReplaceability

Portability

TEST PYRAMID

Business Relevance

Business Relevance

Bug �nding and �xing costsBug �nding and �xing costsBusiness Process

System of Systems

System

Interfaces

Code

Test CoverageTest Coverage

VIEW OF THE ORGANISATION

Skills

Knowledge

Mindset

Org Structure

Process

Infrastructure & Tools

INDIVIDUAL UNLEARNING

INDIVIDUAL LEARNING

ORGANISATIONAL UNLEARNING

ORGANISATIONAL LEARNING

Culture

BehaviourNEED FOR CHANGE

CHAOS STRUCTUREEDGE OF CHAOS

HOW MUCH STRUCTURE DO WE NEED?

THE ADAPTIVE WALK

Inno

vato

rs

Early

Ado

pter

s

Early

Majo

rity

Late

Majo

rity

Lagg

ards

2,5 % 13,5 %

34 % 34 %

16 %

INNOVATION ADAPTION CURV

E

Source: based on Jurgen Appelo, «Management 3.0»

ROLES OLD

Test ManagerTest DesignerTesterTest CoordinatorHead of XY

·····

AGILE TESTING PRINCIPLES & VALUES

Provide Continuous FeedbackLeverage the Power of the 3 AmigosClearly de�ne Acceptance CriteriaValue Code QualityConsider Quality RisksAutomate, automate, automateUse Metrics for TransparencyPractice Continuous ImprovementRespond to ChangeEnjoy

12345678910

ROLES NEW

Test MasterEmbedded TesterSo�ware Engineer in TestDigital TesterMobile Tester…

······

FEATURE TO TEST

F1 F2 F3

F4 F5

F6 F7 F8 F9

US1 T1 T2 T3

US3 T1 T2

US7 T1 T2 T3 T4

US1 US2

US3 US4 US5

US7 US8 US9

US6

Feature User Story Test

DoRDoR

Personas

Test Charter

Test Case

UI Model

User JourneyData Model

Choose whatyou need.Less is more.

Exploratory Testing

System under Test (SUT)

Equivalence partitioning,

Boundary value analysis,

Decision tables,

State transition testing,…

Story Mapping

DISTRIBUTION OF ACTIVITIES WITHIN SPRINT (EXEMPLARY)

Test Housekeeping

Automate Tests

Update Regression Test Set

Story Grooming (Re�nement)

Prepare next sprint

Story Testing

Test Preparation

Testing

Regression Testing

Q1

Q3

FUNC

TION

AL TE

STS ACCEPTANCE TESTS

-ILITY

TES

TS

DEVELOPER TESTS

RealWorld

Feature

Story

Code

Q2Em

bedded Testing (ET)

Story Tests

Feature Tests

Regression Tests

Continuous Testing (CT)

User

Acce

ptan

ce Te

st (U

AT)

End-

to-E

nd Te

st (E2

E)

Final

Inte

grat

ion

Test

(FIT)

Alpha

/Bet

a Tes

t

Usab

ility

Test

Reliability

SecurityE�

ciency

Compatibility

Maintainability

PortabilityUn

it Te

st (U

T)

Test

Drive

n

Deve

lopm

ent (

TDD)

Pair

Prog

ram

min

g

Cont

inuo

us In

tegr

ation

(CI)

Q4

Q2

Q4

SUPP

ORTI

NG

TH

E TE

AM

BUSINESS FACING

CRITIQUE THE PRODUCT

TECHNOLOGY FACING

AGILE TESTING «COMPASS»

based on Test Pyramid concept by Mike Cohn and Agile Testing Quadrants by Lisa Crispin et al.

Feature DoD(example)• All stories done• Regression tests• Acceptance criteria passed

User Story DoD

(example)

• Unit tests done

• Integration tests

• Acceptance

Criteria passed

US US US US US

1

2

3

Prob

abili

ty

Impact

US US USUS US

ndependentegotiablealuablestimablemallestable

INVESTI.N.V.E.S.T.

FEATURE

USER STORY

USER STORY

USER STORY

USER STORY

Feature· Personas· Scenarios· Descriptions

F

User Story As a <role> want <requirement> so that <bene�t>.

US

AcceptanceCriteria

° ––––––

° ––––––° –––––

Acceptance

Criteria

Given …

then …when …

TEST BASIS QUALITY RISK ANALYSIS RISK-BASED STRATEGY

Risk HappyFlow Alternatives Negative

Test

1

2

3

Alternatives

Negative Test

Happy Flow

DoR

DoR

T2 T3 T4T1

1

2

3

Mixed

1

2

3

Breadth �rst

1

2

3

Depth �rst

Typical Testing Priorities:

SPRINTSPRINTSPRINTSPRINTSPRINTSPRINTSPRINT

TESTDESIGNANALYSIS IMPLEMENTATION

RELEASE

SPRINTSPRINTSPRINTSPRINTSPRINTSPRINTSPRINT

ITERATIVE ITERATIVE ITERATIVE ITERATIVE ITERATIVE

Sync Point Sync Point Sync PointSync PointSync Point

DoDDoD DoD DoDDoD

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

SwissQ Consulting AG | Zürich | Bern | Phone: +41 43 288 88 40 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it

TEST

CT

CI

ET FIT

CDDEV OPS

BIZ

PE TIP

Embedded Testing

All testing activities performed within the

team by the whole team to ensure quality and achieve the De�nition

of Done, with or without the help of a dedicated

tester.

Continuous Testing

Executing automated functional and -ility tests as the so�ware

is checked in, to obtain continuous feedback on the quality risks associated with a release candidate.

Continuous Delivery

Automatic release of so�ware to a test

environment when all tests pass. Release into production remains a human decision, e.g. based on results of FIT.

Continuous Integration

Integrating, building and testing code within

the development environment regularly,

at least once a day. Includes static code analysis, unit tests,

checking code coverage.

ProductEngineering

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Final Integration

Testing All tests - such as

System Integration, End-to-End and User

Acceptance Tests - required to ensure that

a release candidate is �t for production.

Testing inProduction

Building con�dence by safely deploying and testing (select)

features in the produc-tion environment.

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Just-in-time discovery of product ideas, design of new

and improved features, writing and

splitting of user stories for delivery.

« SHIFT LEFT SHIFT RIGHT »

DEVOPS TESTING

Inte

grat

e

DeliverPlanCo

de

Deplo

y

MonitorBuild

ON

FeatureFlag

Chaos Engineering

Blue-GreenDeployment

A/B Testing

Canary

STORY GROOMING (REFINEMENT)

Re�ne user stories andacceptance criteria from

testing perspective

WIP

PRODUCT BACKLOG

531

D.E.E.P.

etailedstimatedmergentrioritized

DEEP

531

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Don‘t forget testing!

Present test result

Explain known bugs

Con�rm that acceptance

criteria have been met

Keep testing

perspective in mind

Add test tasks

Estimate testing e³ortContribute test stories

Test Housekeeping:

Update documentation

Maintain test data

and infrastructure

Update test cases

Maintain automated tests

Bug tracking

Test / re-test new stories

against acceptance criteria

Execute smoke and

regression tests

Execute -ility tests

RETR

OS

PECTI

VE SPRI

NT W

ORK

REVIEW

PLANNING I PLANNING

II

DAILY SCRUM

TEAM

ROLLOUT

Product Increment

CO

NVERSATIO

N

CARDS

CONFIRM

ATION

Build(Complexity)

Test(Quality Risk)

De�ne(Value)

TRES AMIGOS PRINCIPLE

FEATURES & STORIES

ACCEPTANCE CRITERIA

AcceptanceCriteria

° ––––––

° ––––––° –––––

Acceptance

Criteria

Given …

then …when …

Feature

• Personae

• Descriptions• Scenarios

User Story

As a …

so that …

I want …

DoR DoD

TEST MASTER

(Re-)De�ne agile testing strategyRemove impediments from a testing perspectiveCheck De�nition-of-Done over all levelsEnsure communication about test within and across all teamsPlan and coordinate �nal integration tests

AGILE TESTING STRATEGY

Agile TestingCompass

System underTest (SUT)

Quality RiskAnalysis

Jetzt bestellen!

Page 65: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

65

Über SwissQ

Agile Testing Framework

ORGANIZATIONAL OPTIONS

Each Team Member

Embedded TesterSeparate Test Team (tester assigned to team)

Separate Test Team

ITERATION

RELEASE

BIG PICTURE AGILE TESTING

© SwissQ, Version 2.2 (10.2019)

ISO 25010 SW QUALITY CHARACTERISTICS

Functional completenessFunctional correctnessFunctional appropriateness

FunctionalSuitability

Time behaviourResource utilizationCapacity

Performancee�ciency

System/So�ware Product Quality

Co-existenceInteroperability

Compatibility

AppropriatenessrecognizabilityLearnabilityOperabilityUser error protectionUser interface aestheticsAccessibility

Usability

MaturityAvailabilityFault toleranceRecoverability

ReliabilityCon�dentiality

Integrity

Non-repudiation

Accountability

Authenticity

Security ModularityReusabilityAnalysabilityModi�abilityTestability

Maintainability

AdaptabilityInstallabilityReplaceability

Portability

TEST PYRAMID

Business Relevance

Business Relevance

Bug �nding and �xing costsBug �nding and �xing costsBusiness Process

System of Systems

System

Interfaces

Code

Test CoverageTest Coverage

VIEW OF THE ORGANISATION

Skills

Knowledge

Mindset

Org Structure

Process

Infrastructure & Tools

INDIVIDUAL UNLEARNING

INDIVIDUAL LEARNING

ORGANISATIONAL UNLEARNING

ORGANISATIONAL LEARNING

Culture

BehaviourNEED FOR CHANGE

CHAOS STRUCTUREEDGE OF CHAOS

HOW MUCH STRUCTURE DO WE NEED?

THE ADAPTIVE WALK

Inno

vato

rs

Early

Ado

pter

s

Early

Majo

rity

Late

Majo

rity

Lagg

ards

2,5 % 13,5 %

34 % 34 %

16 %

INNOVATION ADAPTION CURV

E

Source: based on Jurgen Appelo, «Management 3.0»

ROLES OLD

Test ManagerTest DesignerTesterTest CoordinatorHead of XY

·····

AGILE TESTING PRINCIPLES & VALUES

Provide Continuous FeedbackLeverage the Power of the 3 AmigosClearly de�ne Acceptance CriteriaValue Code QualityConsider Quality RisksAutomate, automate, automateUse Metrics for TransparencyPractice Continuous ImprovementRespond to ChangeEnjoy

12345678910

ROLES NEW

Test MasterEmbedded TesterSo�ware Engineer in TestDigital TesterMobile Tester…

······

FEATURE TO TEST

F1 F2 F3

F4 F5

F6 F7 F8 F9

US1 T1 T2 T3

US3 T1 T2

US7 T1 T2 T3 T4

US1 US2

US3 US4 US5

US7 US8 US9

US6

Feature User Story Test

DoRDoR

Personas

Test Charter

Test Case

UI Model

User JourneyData Model

Choose whatyou need.Less is more.

Exploratory Testing

System under Test (SUT)

Equivalence partitioning,

Boundary value analysis,

Decision tables,

State transition testing,…

Story Mapping

DISTRIBUTION OF ACTIVITIES WITHIN SPRINT (EXEMPLARY)

Test Housekeeping

Automate Tests

Update Regression Test Set

Story Grooming (Re�nement)

Prepare next sprint

Story Testing

Test Preparation

Testing

Regression Testing

Q1

Q3

FUNC

TION

AL TE

STS ACCEPTANCE TESTS

-ILITY

TES

TS

DEVELOPER TESTS

RealWorld

Feature

Story

Code

Q2Em

bedded Testing (ET)

Story Tests

Feature Tests

Regression Tests

Continuous Testing (CT)

User

Acce

ptan

ce Te

st (U

AT)

End-

to-E

nd Te

st (E2

E)

Final

Inte

grat

ion

Test

(FIT)

Alpha

/Bet

a Tes

t

Usab

ility

Test

Reliability

SecurityE�

ciency

Compatibility

Maintainability

PortabilityUn

it Te

st (U

T)

Test

Drive

n

Deve

lopm

ent (

TDD)

Pair

Prog

ram

min

g

Cont

inuo

us In

tegr

ation

(CI)

Q4

Q2

Q4

SUPP

ORTI

NG

TH

E TE

AM

BUSINESS FACING

CRITIQUE THE PRODUCT

TECHNOLOGY FACING

AGILE TESTING «COMPASS»

based on Test Pyramid concept by Mike Cohn and Agile Testing Quadrants by Lisa Crispin et al.

Feature DoD(example)• All stories done• Regression tests• Acceptance criteria passed

User Story DoD

(example)

• Unit tests done

• Integration tests

• Acceptance

Criteria passed

US US US US US

1

2

3

Prob

abili

ty

Impact

US US USUS US

ndependentegotiablealuablestimablemallestable

INVESTI.N.V.E.S.T.

FEATURE

USER STORY

USER STORY

USER STORY

USER STORY

Feature· Personas· Scenarios· Descriptions

F

User Story As a <role> want <requirement> so that <bene�t>.

US

AcceptanceCriteria

° ––––––

° ––––––° –––––

Acceptance

Criteria

Given …

then …when …

TEST BASIS QUALITY RISK ANALYSIS RISK-BASED STRATEGY

Risk HappyFlow Alternatives Negative

Test

1

2

3

Alternatives

Negative Test

Happy Flow

DoR

DoR

T2 T3 T4T1

1

2

3

Mixed

1

2

3

Breadth �rst

1

2

3

Depth �rst

Typical Testing Priorities:

SPRINTSPRINTSPRINTSPRINTSPRINTSPRINTSPRINT

TESTDESIGNANALYSIS IMPLEMENTATION

RELEASE

SPRINTSPRINTSPRINTSPRINTSPRINTSPRINTSPRINT

ITERATIVE ITERATIVE ITERATIVE ITERATIVE ITERATIVE

Sync Point Sync Point Sync PointSync PointSync Point

DoDDoD DoD DoDDoD

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

SwissQ Consulting AG | Zürich | Bern | Phone: +41 43 288 88 40 | Twitter: @SwissQ | eMail: [email protected] | www.SwissQ.it

TEST

CT

CI

ET FIT

CDDEV OPS

BIZ

PE TIP

Embedded Testing

All testing activities performed within the

team by the whole team to ensure quality and achieve the De�nition

of Done, with or without the help of a dedicated

tester.

Continuous Testing

Executing automated functional and -ility tests as the so�ware

is checked in, to obtain continuous feedback on the quality risks associated with a release candidate.

Continuous Delivery

Automatic release of so�ware to a test

environment when all tests pass. Release into production remains a human decision, e.g. based on results of FIT.

Continuous Integration

Integrating, building and testing code within

the development environment regularly,

at least once a day. Includes static code analysis, unit tests,

checking code coverage.

ProductEngineering

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Final Integration

Testing All tests - such as

System Integration, End-to-End and User

Acceptance Tests - required to ensure that

a release candidate is �t for production.

Testing inProduction

Building con�dence by safely deploying and testing (select)

features in the produc-tion environment.

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Just-in-time discovery of product ideas, design of new

and improved features, writing and

splitting of user stories for delivery.

« SHIFT LEFT SHIFT RIGHT »

DEVOPS TESTING

Inte

grat

e

DeliverPlanCo

de

Deplo

y

MonitorBuild

ON

FeatureFlag

Chaos Engineering

Blue-GreenDeployment

A/B Testing

Canary

STORY GROOMING (REFINEMENT)

Re�ne user stories andacceptance criteria from

testing perspective

WIP

PRODUCT BACKLOG

531

D.E.E.P.

etailedstimatedmergentrioritized

DEEP

531

TEST

CT

CI

ET FIT

CD

DEV OPSPE TIP

BIZ

TIP

BIZ

PE

Don‘t forget testing!

Present test result

Explain known bugs

Con�rm that acceptance

criteria have been met

Keep testing

perspective in mind

Add test tasks

Estimate testing e³ortContribute test stories

Test Housekeeping:

Update documentation

Maintain test data

and infrastructure

Update test cases

Maintain automated tests

Bug tracking

Test / re-test new stories

against acceptance criteria

Execute smoke and

regression tests

Execute -ility tests

RETR

OS

PECTI

VE SPRI

NT

WORK

REVIEW

PLANNING I PLANNING

II

DAILY SCRUM

TEAM

ROLLOUT

Product Increment

CO

NVERSATIO

N

CARDS

CONFIRM

ATION

Build(Complexity)

Test(Quality Risk)

De�ne(Value)

TRES AMIGOS PRINCIPLE

FEATURES & STORIES

ACCEPTANCE CRITERIA

AcceptanceCriteria

° ––––––

° ––––––° –––––

Acceptance

Criteria

Given …

then …when …

Feature

• Personae

• Descriptions• Scenarios

User Story

As a …

so that …

I want …

DoR DoD

TEST MASTER

(Re-)De�ne agile testing strategyRemove impediments from a testing perspectiveCheck De�nition-of-Done over all levelsEnsure communication about test within and across all teamsPlan and coordinate �nal integration tests

AGILE TESTING STRATEGY

Agile TestingCompass

System underTest (SUT)

Quality RiskAnalysis

Page 66: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Innovation & Change

66

Inn

ovat

ion

& C

han

ge

Kursangebote

Inhalt

■ Search Inside Yourself (SIY) 68

■ Lean Change Agent Workshop (LCA) 68

■ Selbstorganisierte Organisationen (SOR) 69

■ Collaboration & Communication (COCO) 69

■ Erfolgreiche Kommunikation im Team (EKT) 72

■ Out-of-the-Box Thinking (OOBTH) 72

■ Visual Facilitation (VF) 73

■ LEGO® Serious Play® Intro (LSP) 73

■ Team-Retrospektive (TR) 74

■ Lean IT Foundation (LIT) 74

Page 67: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

67

Innovation & Change

Page 68: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Innovation & Change

68

Kurzbeschreibung

Organisationen befinden sich in einem stetigen Wandel. Veränderungen in Unternehmen und Organisationen sind oft komplex und die Erfahrung zeigt, dass viele Change Vorhaben nicht erfolgreich abgeschlossen werden. Wäre es also nicht besser Change Vorhaben iterativ und inkrementell, also agil, umzusetzen, um der Komplexität besser gerecht zu werden? Lean Change Management ist ein agiler feedbackbasierter Ansatz, der Organisationen auf ihrem Weg durch den Wandel leitet. Das Modell implementiert die schnelle Feedback-Schleife aus dem Lean Start-Up und kombiniert Praktiken, Methoden und Tools aus Agile und Change Management. Der Fokus liegt nicht auf ausgiebiger und detaillierte Vorausplanung, sondern auf iterativer und inkrementeller Umsetzung und stetiger An-passung. In diesen 2 Tagen werden die erforderlichen Kennt-nisse in einem interaktivem Workshop vermittelt, um das Lean Change Management Modell in Veränderungsprozessen erfolg-reich anwenden zu können.

Weitere Details

■ Sprache: DE / EN, Unterlagen EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: LCA

Kurzbeschreibung

Search Inside Yourself ist das weltweit renommierteste Training für Achtsamkeit und emotionale Intelligenz im Business. Das ergebnisorientierte, interaktive Programm wurde bei Google entwickelt und ist dort eines der meistbesuchten Seminare. Mit Hilfe von businesstauglichen und weltanschaulich neutralen, kurzen Achtsamkeitsübungen lernen die Teilnehmenden, besser mit Stress und emotionalen Belastungen umzugehen (Resilienz), steigern ihre mentale Fitness, entwickeln Fokus und innere Klarheit. Dank grösserer Gelassenheit und Empathie pflegen sie eine vertrauensvolle Zusammenarbeit mit anderen. Sie ver-bessern ihr Kommunikationsvermögen und führen authentisch. Sie wissen, was sie antreibt und wie sie Erfüllung im Beruf und im Privaten finden.

Dem zweitägigen Kurs folgt ein vierwöchiger online-Transfer (28 Day Meditation Challenge). Den Abschluss bildet ein einstündiges Follow–up Webinar.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 2 Tage

■ Code: SIY

Lean Change Agent Workshop (LCA)

Inhalt

■ Was ist Lean Change Management?

■ Wie können agile Prinzipien im Change Management angewandt werden?

■ Wie können Praktiken wie zum Beispiel Lean Coffee eingesetzt werden, Feedback zu ermöglichen und Einsichten zu gewinnen?

■ Wie können Werkzeuge wie Change Canvases eingesetzt werden, um gemeinsames Verständnis zu erreichen und Transparenz zu fördern?

■ Wie können Veränderungen als Experimente unter Einbezug der Betroffenen gestaltet werden?

■ Wie können Sie Widerstände in Veränderungsprozessen erkennen und mit ihnen umgehen?

Search Inside Yourself (SIY)

Inhalt

■ Grundlagen von Achtsamkeit am Arbeitsplatz und Emotionaler Intelligenz

■ Neurowissenschaftliche Forschungsergebnisse zur Wirksamkeit

■ Resilienz: Mit belastende Emotionen umgehen lernen

■ Motivation, Flow und bessere Performance durch weniger Tun

■ Beeinflussen und führen: authentisch und achtsam

■ Business-taugliche Achtsamkeitsübungen kennenlernen und in den Arbeitsalltag integrieren

Page 69: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

69

Innovation & Change

Kurzbeschreibung

Collaboration & Communication ist ein Praxismodul für bessere Workshops und somit alles andere als graue Theorie. In diesem Praxisseminar wird aufgezeigt, welche Formen von Meetings es gibt und wie Meetings als produktive Workshops durchgeführt werden können.

Sie lernen, wie Sie Workshops vorbereiten und moderieren, welche Formen der Kommunikation es gibt und wie diese ziel-gerichtet eingesetzt werden. Das ganze natürlich an ausgewähl-ten Praxisbeispielen oder direkt als Vorbereitung bevorstehender Workshops der Kursteilnehmenden.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: COCO

Kurzbeschreibung

Agilität ist in aller Munde und wird in Organisationen vermehrt angewendet. Ein Aspekt von Agilität ist Selbstorganisation. Salonfähig wurde Selbstorganisation durch das Framework Scrum, wo von einem selbstorganisierten Team gesprochen wird. Darüber hinaus stellt sich jedoch zwangsläufig die Frage wie Selbstorganisation auf Organisations-Ebene funktioniert. Auf dieser Ebene gibt es verschiedene Ansätze wie Holocracy, Soziocracy das Spotify Modell und Laloux’s Teal Modell. Diese liefern einen Vorschlag zu selbstorganisierten Organisationen. Jedes Unternehmen befindet sich jedoch in seinem eigenen Kontext, daher ist eine eigene Herangehensweise an dieses Thema erforderlich, welche sich an den Good Practice Ansätzen orientieren kann.

In diesem Workshop werden die Elemente von Selbstorgani-sation vorgestellt, um eine fundierte Grundlage zu legen die eigene Organisation hin zur Selbstorganisation zu entwickeln.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: SOR

Collaboration & Communication (COCO)

Inhalt

■ Was bedeutet Zusammenarbeit und Kommunikation?

■ Stakeholder identifizieren und einbeziehen

■ Kommunikation zielgerichtet einsetzen

■ Vorbereitung & Moderation von Workshops

■ Kreativitätstechniken

■ Konfliktarten und Konsolidierungstechniken

■ Abschluss und Nachbereitung

Selbstorganisierte Organisationen (SOR)

Inhalt

■ Einführung Selbstorganisation

■ Organisationstypen

■ Analyse: Meine eigene Organisation: Wo stehen wir?

■ Modelle und Beispiele von Selbstorganisation

■ Agilität und Selbstorganisation – ein Widerspruch?

■ Die Prinzipien der Selbstorganisation

■ Veränderung zur Selbstorganisation, Voraussetzungen, Vorgehen und erste Schritte

■ Lessons Learned für den einzelnen und die Gruppe, Welche Punkte sind wichtig? Was haben wir gelernt von anderen?

Page 70: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Über SwissQ

70

13%8% 5%

Bestehende Unternehmens-

kultur u

nd / oder H

ierarchien

Übergreifende Prozesse

nicht angepasst

Fehlender Gesamt-

überblick / Produktvi

sion

Kunde nicht genug

involvie

rt / engagiert

Hohe Spezialisi

erung

der Mita

rbeiter

4 %

Priorisi

erung von Aufgaben /

Work Items s

chwierig

5 %

Starre / z

u wenige Release

und Deployment Zyklen

5 %

51 %

7 %8 %13 %OPSDEVTST

Team

DEV

TSTOPS

Unterwegs (oft bimodal)

Team

DEV

TSTOPS

Team

DEV

TSTOPS

Team

DEV

TSTOPS

Agile (Value streams)

51

Das transformierteUnternehmenTSTTST

GL

Das etablierte Unternehmen

IT

?

?

VR

Etabliert

RE/BADEV

TST OPS

BIZ

?

report.SwissQ.it

Trends & Benchmarks Report

CEO Celina CIO Thomas Head Agile Nino Executive Anna Test Lead Luca Reto„BA/ RE/ PO“ Beat DevOps Lead Johanna

Page 71: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

71

Über SwissQ

13%8% 5%

Bestehende Unternehmens-

kultur u

nd / oder H

ierarchien

Übergreifende Prozesse

nicht angepasst

Fehlender Gesamt-

überblick / Produktvi

sion

Kunde nicht genug

involvie

rt / engagiert

Hohe Spezialisi

erung

der Mita

rbeiter

4 %

Priorisi

erung von Aufgaben /

Work Items s

chwierig

5 %

Starre / z

u wenige Release

und Deployment Zyklen

5 %

51 %

7 %8 %13 %OPSDEVTST

Team

DEV

TSTOPS

Unterwegs (oft bimodal)

Team

DEV

TSTOPS

Team

DEV

TSTOPS

Team

DEV

TSTOPS

Agile (Value streams)

51

Das transformierteUnternehmenTSTTST

GL

Das etablierte Unternehmen

IT

?

?

VR

Etabliert

RE/BADEV

TST OPS

BIZ

?

report.SwissQ.it

Trends & Benchmarks Report

CEO Celina CIO Thomas Head Agile Nino Executive Anna Test Lead Luca Reto„BA/ RE/ PO“ Beat DevOps Lead Johanna

Page 72: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Innovation & Change

72

Kurzbeschreibung

Ein Workshop mit Einführung in Kreativitätstechniken und laterales Denken mit vielen Übungen, basierend auf dem De-sign Thinking Prozess. Was braucht es dazu? Die methodischen Kenntnisse von SwissQ, eine Ideenanregende Umgebung und Ihr multidisziplinäres Team. Und schon geht‘s voran mit demLösen von „wicked“ (weakly designed) Problems, also Proble-men mit schlecht definierten Fragestellungen zu den Bedürf-nissen Ihrer Kunden. Der Workshop behandelt den gesamten Design Thinking Prozess von Empathize, Define, Ideate, Proto-type bis hin zum Test. Natürlich auf Basis Ihrer spezifischen Fragestellung. So werden Sie nicht mehr das Gefühl haben, den Kunden nicht richtig verstanden oder gar an ihm vorbei entwickelt zu haben.

Nach dem Workshop, für welchen SwissQ die Räumlichkeiten, Kreativmaterial und ein Fotoprotokoll zur Verfügung stellt, sind Sie und Ihr Team selbst in der Lage, Out-of-the-Box zu denken.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: OOBTH

NEU Out-of-the-Box Thinking (OOBTH)

Inhalt

■ Design Thinking Prozess

■ Verstehen (Design Challenge, Personas)

■ Beobachten (Contextual Inquiry, Interview)

■ Standpunkt definieren

■ Ideen generieren (Kreativitätstechniken)

■ Prototyp entwickeln

■ Testen (Hypothesen, A/B Testing)

Erfolgreiche Kommunikation im Team (EKT)

Inhalt

■ Was sind persönliche Präferenzen? – Definition und Einführung

■ Mein Präferenzprofil – eine Statusbestimmung

■ Wie Präferenzen erkennbar sind – die Show

■ Auswirkung im Alltag / im Team

■ Umgang mit Widerstand anhand der persönlichen Präferenzen

■ Kommunikation – ein Refresher.

■ Gewaltfreie, wertschätzende Kommunikation (theor. & praktisch)

■ Alltagssituation zum Üben

■ Lessons Learned fürs Team – woran wollen wir arbeiten?

Kurzbeschreibung

«Projekte scheitern nicht an der Technik, sondern am Menschen.» Diese oft gehörte Aussage macht deutlich, dass der mensch-liche Faktor in der Zusammenarbeit eine erhebliche Rolle spielt und oftmals das Zünglein an der Waage ist, wenn es um Erfolg oder Misserfolg gemeinsamer Arbeit geht. Zentraler Bestand-teil von Kommunikation in einem Team sind die Präferenzen der einzelnen Teammitglieder. Jeder Mensch hat seine eigene Art zu kommunizieren. Um eine erfolgreiche Kommunikation und somit Zusammenarbeit zu gewährleisten, gilt es die verschiedenen Präferenzen transparent zu machen und einen gemeinsamen Nenner im Team zu finden. Hilfreiche Leitplanken bietet die gewaltfreie Kommunikation, die zum Ziel hat mit dem/den Gegenüber/n in Verbindung zu kommen und einen Umgang zu finden, der zum gegenseitigen Wohlergehen beiträgt. Dieser Workshop bietet eine einfache und effiziente Möglichkeit, dieses komplexe Thema mit Leichtigkeit und Spass zu erleben und zu verinnerlichen.

Weitere Details

■ Sprache: DE

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: EKT

Page 73: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

73

Innovation & Change

Kurzbeschreibung

Du begleitest Veränderungen in Teams und Organisationen mit Leidenschaft und hast Erfahrung mit den üblichen Work-shop-Formaten und Übungen. Nun bist du auf der Suche nach noch mehr Inspiration und Kreativität in der Lösungsfindung und bist davon überzeugt, dass sich unser Denken signifikant verändert, wenn wir neben dem Kopf buchstäblich auch die Hände ins Spiel bringen. Du hast von den faszinierenden Möglichkeiten von LEGO® Serious Play® (LSP) gehört und willst diese nun kennenlernen.

LSP ist ein moderierter Prozess, der die Vorzüge des spielerischen Modellierens von Ideen und Inhalten mittels Legosteinen mit «seriösen» Themen der Geschäftswelt verbindet. LSP soll die Kreativität und neue Ideen durch die Modellierung mit den Händen fördern, die Kommunikation über begreifbare Modelle verbessern und die wertvollen Beiträge aller Teilnehmer besser integrieren. In LSP-Workshops erarbeiten die Teilnehmer zum Beispiel Strategien, Systeme oder Lösungskonzepte unter An-leitung eines LSP-Moderators.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: LSP

Kurzbeschreibung

Ein Bild sagt mehr als tausend Worte. Visual Facilitation kommt ursprünglich aus der Welt der Bauvorhaben und der Architektur und wurde dort als «Problem Seeking» Methode etabliert. Prinzipiell geht es darum, komplexe Systeme mit einfachen Symbolen schnell und verständlich zu erklären. Die Kernaussage steht im Mittelpunkt und wird entsprechend in Szene gesetzt. Genau diese Methode haben wir übernommen, verfeinert und wenden sie erfolgreich in unseren Trainings, Anforderungs- und Testworkshops an. Wir machen dies also nicht zum Selbstzweck, sondern um unsere eigene Kommunikation um eine wichtige Dimension zu erweitern und Nachrichtenempfänger visuell zu unterstützen.

Inklusive: 1 Starter Paket mit Stiften pro Teilnehmer.

Weitere Details

■ Sprache: DE / EN

■ Typ: öffentlich / firmenintern

■ Dauer: 1 Tag

■ Code: VF

LEGO® Serious Play® Intro (LSP)

Inhalt

■ Einführung LEGO® Serious Play® (LSP) Prozess

■ LSP Basic Skills

■ Individual Model Building

■ Shared Model Building

Visual Facilitation (VF)

Inhalt

■ Erste Schritte

■ Basis Elemente

■ Aufbau Visual Facilitation

■ Plakate erzählen Geschichten

■ Hilfsmittel

■ Spezifischer Einsatz von Visual Facilitation in den Tätigkeiten

Page 74: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

Innovation & Change

74

Kurzbeschreibung

Lean ist eine systematische Methode zur Minimierung von Verschwendung («Muda») innerhalb eines Wertstroms (Value Stream), ohne die Produktivität zu beeinträchtigen. Mit der starken Verbreitung von Agile stossen die Lean Konzepte, ins-besondere innerhalb der IT, auf erneuertes Interesse. Im Kurs lernen Sie, nebst der Lean Philosophie & Prinzipien, eine Vielzahl von Methoden und Tools kennen wie Sie Ihre (IT) Prozesse konti-nuierlich verbessern können. Als Fallstudie verwenden wir dabei einen Ihrer Prozesse. Die Ergebnisse können gleich in die Praxis überführt werden. Alternativ stellen wie ein Übungsbeispiel zur Verfügung.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 1 Tag

■ Code: LIT

Kurzbeschreibung

Die Retrospektive bietet die Gelegenheit in einem geschützten Rahmen einen Blick zurück zu werfen, um sich als Team zu über-prüfen. Die positiven wie auch negativen Dinge werden trans-parent gemacht und konstruktiv-kritisch besprochen. Durch die gewonnen Erkenntnisse werden gemeinsam Massnahmen erarbeitet, die die Produktivität des Teams steigern sollen.

Sie planen eine Retrospektive mit Ihrem Team und wünschen sich neue Ideen und Inspirationen von aussen? Egal, ob Ihr Team schon Erfahrungen mit Retrospektiven gesammelt hat oder zum ersten Mal in der aktuellen Konstellation eine solche plant, ein externer Facilitator kann helfen frischen Wind ins Team zu brin-gen und dem Team eine neutrale Sicht von aussen zu spiegeln. Nach einer Vorbesprechung über den Kontext und die aktuellen Herausforderungen moderieren wir Ihre Team-Retrospektive und dokumentieren die Resultate gemeinsam mit dem Team.

Weitere Details

■ Sprache: DE / EN

■ Typ: firmenintern

■ Dauer: 0,5 Tag

■ Code: TR

NEU Lean IT Foundation (LIT)

Inhalt

■ Einführung in die Lean Philosophie & Prinzipien

■ Value Stream Analyse (Value-Add, Non-Value-Add, Muda)

■ Lean in der IT

■ Unterschied Agile und Lean

■ Kontinuierliche Verbesserung (PDCA, Kaizen, DMAIC)

Team-Retrospektive (TR)

Inhalt

■ Gemeinsamer Rückblick als Team, indem Erlebtes transparent ge-macht wird.

■ Positive wie negative Punkte werden offen kommuniziert.

■ Gemeinsam erarbeitete Massnahmen und Vorschläge zur verbesserten Zusammenarbeit im Team.

■ Ein gemeinsam erarbeiteter Plan zur Umsetzung der Massnahmen.

Page 75: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

75

Innovation & Change

Page 76: swissq.it · 2020-04-16 · Agile Essentials (AE) 17 Agile Experience (AX) 17 Scrum Kickstarter (SKS) 20 Kanban Kickstarter (KKS) 20 Professional Scrum Master I (PSM) 21 SAFe® Scrum

© by SwissQ Consulting AG Zürich | Bern www.SwissQ.it [email protected] Tel +41 43 288 88 40 Fax +41 43 288 88 39 Twitter: @SwissQ Facebook: swissqconsulting

Fragen? Bitte kontaktieren Sie uns!