Embed Size (px)
Agile
Requirements
Testing
Inn
ovat
ion
& C
hang
e
AcademyHandbuch 2020
Kursangebote mit Mehrwert
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
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
Über SwissQ
4
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
Anja van Ackern
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
Ü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
07
Über SwissQ
Ü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
09
Über SwissQ
Dieter Prohammer
Chris WolfBjörn Schuster
Marcel Ruetschi
Janine Karbulka Kastriot Krasniqi Katarina Kubisova
Marcel Stoop
Katrin Lüthi
Ü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
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
Ü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
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
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
15
Agile
Agile
16
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
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
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
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
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.
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
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
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.
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
Agile
26
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
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
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
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
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
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!
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)
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
35
Requirements
Requirements
36
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
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-
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.
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
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
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!
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
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
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
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)
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
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
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
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
51
Testing
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
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
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.
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
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
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
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?
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
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
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
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
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
Ü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!
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
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
67
Innovation & Change
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
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?
Ü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
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
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
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
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.
75
Innovation & Change
© 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!
