Organisationskomplexität bei der Einführung von agilen ... · Use Case TAV38| 16/10/2015 | DR. ANDREAS WÜBBEKE Hilft die Idee des „One-Piece-Flow“ ... • braucht man einen

Organisationskomplexität bei der Einführung von agilen Methoden

Dr. Andreas Wübbeke Head of Research and Development Quality Assurance

GI TAV 38 in Paderborn

© Wincor Nixdorf International GmbH

Organisation

2

Organisation

Aufbauorganisation

Standortorganisation

Ablauforganisation

…

Leiter F&E

Entwicklung Qualitätssicherung Projektmanagement

Office

Zentrale Funktionen

TAV38| 16/10/2015 | DR. ANDREAS WÜBBEKE


Komplexität

3

Komplexitätsmanagement

Mensch

Prozesse

Systeme

…



Einführung agiler Methoden…

4 TAV38| 16/10/2015 | DR. ANDREAS WÜBBEKE


Wir kreieren einen typischen Startzustand…

5

Organisation Komplexitätsmanagement

Aufbauorganisation Mensch

Standortorganisation Prozesse

Ablauforganisation Systeme

… …



Aufbauorganisation

6

Leiter F&E


Office

Zentrale Funktionen






Ablauforganisation



Mensch

9

Quelle: Google

Entwickler und Qualitätssicherer • kennen die Organisation • kennen die Prozesse • sind Experten in ihrem technischen

und fachlichen Gebiet • … • arbeiten schon seit Jahren genau so



Prozesse

• Entwicklungsprozess

• Fehlermanagementprozess

• Qualitätskennzahlen

• Guidelines • UI Design

• Coding Regeln

• Architektur

• …

• …



Systeme


HW


und jetzt…



Typische Ziele der Einführung agiler Methoden

• Ausrichtung am Business Value von Features • Häufig fertige Software liefern können

(vor allem im Cloud-Kontext) • Frühes Feedback des Produktmanagements • Steigerung der Software Qualität • Mehr Flexibilität bei Änderungen der Anforderungen • Bessere Planbarkeit, da kürzere Planungszyklen



Organisation

14

Quelle: Google

Quelle: Google

Dev Phase

QA Phase

Dev Phase

QA Phase

Sprint Phase



Aufbauorganisation

15

Leiter F&E


Office

Zentrale Funktionen



Aufbauorganisation

16

Leiter F&E

Sprint Team 1

Entwickler

Tester

Sprint Team 2

Entwickler

Tester

Sprint Team 3

Entwickler

Tester

Sprint Team 4

Entwickler

Tester

Zentrale Funktionen

SCRUM Master

Product Owner




17

Sprint Team 1

Sprint Team 2

Sprint Team 3

Sprint Team 4



Ablauforganisation: Beispiel Definition of Done

18

Example: Definition of Done (DoD) • Implementation is done • Developer tests are defined and

passed • Acceptance criteria must be met • QA Test Cases that cover the

acceptance criteria must pass 100% • Regression test cases are identified • All related change requests and Prio

1 and 2 errors have to be closed • A list of integration test topics must

exist • Translations: everything is translated

to German and English • Technical documentation is available • It is checked if something needs to be

mentioned in the release notes/functional overview

• Effort hours are booked in the checklist for the story



Was fällt bei der Umstellung auf?

• Tester haben zu Beginn des Sprints nichts zum testen

• Testbare (lauffähige) Features gibt es meist erst gegen Ende des Sprints (Miniwasserfall)

• Spezialisten sind keine Generalisten im Team (das Ranking der Features wird gerne ignoriert)

• Für die Integrationstests (End2End) fehlt im Sprint die Zeit



Continuous Integration (CI)

Daily? Weekly? Sprintly?

JUnit

Source Code Management Build Deploy Test

TAV38| 16/10/2015 | DR. ANDREAS WÜBBEKE 20


Vermeide!

21

Quelle: http://s.mlkshk.com/r/UQLC



Was können wir machen?

Einführung von Metriken um die CI Prozess Qualität zu überprüfen

Wie oft integrieren wir erfolgreich?

Weitere mögliche Metriken: • Wie lange dauert die Integration? • Wie oft sind Deployment und Smoke Test erfolgreich?

Es gibt große Unterschiede zu entdecken zwischen verschiedenen Projekten!!!










Experten und Generalisten

24

Feat

ure

Technische Anforderung



Use Case


Hilft die Idee des „One-Piece-Flow“

durchzusetzen

Transformation von Experten in

Generalisten wird unterstützt


Eines der wichtigsten Meetings – Die Retrospektive










Test Automation

27

http://cdn.softwaretestinghelp.com/ wp-content/qa/uploads/2007/08/ regression-testing.jpg



Metriken

Reicht das klassische Burn-Down-Chart aus?


Feature Status Number

of TCs

Run

Rate

Pass

Rate

Number of

issues Prio 1 Prio 2 Prio 3 Prio 4 CR

FR0001 – Version Information Under test 9 100% 89% 1 - - 1 - -

FR0004 – Journal Under test 9 - - - - - - - -

FR0006 – Screen Integration In development 20 95% 100% 0 - - - - 0

FR0012 – Format and Placeholder resolver Under test 16 31% 80% 1 - - 1 - -

FR0014 – Show Feature Name or Alias Feature Complete 22 100% 68% 3 0 0 1 2 0

FR0017 – Context support Not started 0 - - - - - - - -

FR0018 – Grammar Under Test 0 - - - - - - - -

FR0027 – Return Code Feature Complete 7 100% 100% 0 - - - - 0

FR0042 – Host Protocol Fix to be provided 16 100% 81% 2 0 0 2 0 0

FR0057 – Flow Usability Feature Complete 6 100% 100% 0 - - - - 0

FR0062 – ProTopas Properties Feature Complete 54 98% 96% 2 0 0 2 0 0

FR0063 – Card Class Editor Under Test 56 93% 88% 6 0 1 4 1 0

FR0064 – Properties Runtime Data In development 0 - - - - - - - -

FR0065 – Card Class Under test 6 67% 50% 3 - - 1 2 -

FR0070 – Screen Data Download Viewer Under test 4 - - 1 1 - - - -

FR0077 – Properties Integration In development 0 - - - - - - - -


Retrospektive

• Wenn man häufig liefern möchte, • braucht man einen hohen Grad an Testautomatisierung im Regressionskontext

• müssen aus Experten (teilweise) Generalisten werden

• muss man den „One-Piece-Flow“ Gedanken in den Teams ernst nehmen

• Wenn die QA in das Sprintteam integriert werden soll, • braucht man eine funktionierende CI mit hoher Build-Stabilität

• sollte die Aufbauorganisation sich an Features und Standorten orientieren und weniger an technischen Aspekten

• müssen auch Entwickler lernen QA Aufgaben zu übernehmen



Retrospektive

Organisation • Aufbauorganisation: Teams sind interdisziplinär • Standortorganisation: Schneide die Aufgaben nach Möglichkeit passend zu den

Standorten • Ablauforganisation: Passe den agilen Prozess an das Unternehmen an und

entwickele ihn weiter (Retrospektiven!) Komplexität • Menschen: Müssen die agilen Grundsätze verstehen und an deren

Implementierung beteiligt werden. Transformation vom Spezialisten zum Generalisten ist erforderlich

• Prozesse: CI Prozess und Test-Automatisierung sind Kernelemente • Systeme: Brauchen automatisierte Testbarkeit


Danke für Ihre Aufmerksamkeit! Fragen?

AGILE - STATUS QUO ET QUO VADIS | 26/03/2015 | WÜBBEKE 31

Dr. Andreas Wübbeke Head of Research and Development Quality Assurance


Key Factors for Success

• The employees need the will to change Why Change Workshop

VOM WASSERFALL ZUM SCRUM-WASSERFALL - EINE PROZESS DESIGN UNTERSTÜTZUNG | 07/11/2014 | URBAN, WÜBBEKE 32

R&D Delivery

We create software we can be proud of For us that means: We delight our customers by providing the right solution with high quality and we have a reputation for doing so To achieve this • We collaborate and act with trust as one team – end to end • We make facts visible • We maintain a flexible and understandable software architecture • We use capable tools and integrate our software often and effortlessly • We innovate to lead • We quest for purpose, autonomy and mastery

Documents

Organisationskomplexität bei der Einführung von agilen ... · Use Case TAV38| 16/10/2015 | DR. ANDREAS WÜBBEKE Hilft die Idee des „One-Piece-Flow“ ... • braucht man einen