Marco Kisperth, Jörg Müller | Hypoport
Continuous Delivery ist keine Technologie
Marco Kisperth
der Product Owner
@kisperth
Jörg Müller
der Techniker
@joergm
Unser Product Owner hatte
eine Vision!
Update der Anwendung mindestens

einmal pro Stunde möglich
Features werden während der Umsetzung
laufend ausgerollt
Ein System für Produktion, Akzeptanz,
Preview und Schulung
Wir hatten erstmal
gewaltige Zweifel!
„Jeder Commit automatisch auf
Produktion!“
Wer bezahlt den Aufwand für die
automatisierte Testabdeckung?
Wie soll so ein automatisches
Deployment funktionieren?
Jetzt sollen If-Bedingungen für neue
Features in den Code?
Warum wollte der Product
Owner so etwas?
Nur ein genutztes Feature

ist ein gutes Feature
Keine goldenen Wasserhähne
Features in kleinen Schritten zur
Verfügung stellen
Weniger Komplexität
Mehr Zufriedenheit
Was mussten wir tun,
damit es funktioniert?
Kein extra QA
Operations im Team
Support durch Business Analysten
und Developer
Alle Verantwortung und Fähigkeiten
mussten in ein Team
Technologisch brauchten wir eine
Deployment Pipeline
Automatisierte Test-Stages aber nur
ein Stage für Menschen
Der Test-Modus ersetzt das Preview-
System
test
Feature Switches sind nötig, aber
seltener, als man denkt
Kanban statt Scrum
pull
Commanders Intent

Acceptance Tests
Kommunikation
!
keine detaillierte Spezifikation
!#?
Community mit Anwendern und
Entscheidern aufbauen
Anwendungs-Controlling
Die Anwendung informiert selber

über Änderungen
neu
Wie weit sind wir damit
gekommen?
> 500.000 Zeilen Code

(Java, Javascript, Groovy, XML, HTML)
23.000 Unit Tests & 400 Selenium Test
Fehler schnell beheben ist wichtiger als
vermeiden
17 „Entwickler“, 3 BA, 1 UX, 1 PO
Klassische Rollenbilder gemischt
Was hat es in uns
verändert?
„Das ist mein Produkt“
Test Driven Development
Refactoring in small steps
Agile Methoden und Continous Delivery
greifen perfekt ineinander!
Keine Abstimmung zum Rollout
nur Freischalten ist Entscheidung des
Product Owners
Feature oder Bugfix
Wo ist der Unterschied?
Neue Prioritäten für Bugfixes/Findings
Quickwins first
Hard-Coded ist die neue
Konfigurierbarkeit
Was sind die
Voraussetzungen?
„Einfach“ beginnen
Es gibt kein „Fertig“
„Seniore“ Teammitglieder
Ohne Disziplin geht es nicht
Nein sagen!
Der Sog zum klassischen
Vorgehen wird stark sein
Eigenverantwortung muss gewollt
und möglich sein
Haben sich die
Erwartungen erfüllt?
JA!
Themen können technisch und fachlich
fertiggestellt werden!
Continuous Delivery ist ein Mindshift
Marco Kisperth
marco@kisperth.de
@kisperth
Jörg Müller
joerg.mueller@hypoport.de
@joergm
blog-it.hypoport.de
Vielen Dank a...
Continuous delivery ist keine Technologie
Nächste SlideShare
Wird geladen in …5
×

Continuous delivery ist keine Technologie

159 Aufrufe

Veröffentlicht am

[German]

Seit 2010 entwickeln wir ein Produkt unter Einsatz von Continuous Delivery und einigen anderen "neuen" Methoden. Viele Impulse zu neuen Vorgehensweisen kamen überraschenderweise aus dem Produktmanagement. Von Seiten der Techniker gab es anfangs durchaus auch Skepsis. Kommend aus einer klassischen Scrum-Welt wurde unserer tägliches Denken und Arbeiten stark verändert. Warum wollen wir heute auf keinen Fall mehr zurück?


Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
159
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Continuous delivery ist keine Technologie

  1. 1. Marco Kisperth, Jörg Müller | Hypoport Continuous Delivery ist keine Technologie
  2. 2. Marco Kisperth der Product Owner @kisperth Jörg Müller der Techniker @joergm
  3. 3. Unser Product Owner hatte eine Vision!
  4. 4. Update der Anwendung mindestens
 einmal pro Stunde möglich
  5. 5. Features werden während der Umsetzung laufend ausgerollt
  6. 6. Ein System für Produktion, Akzeptanz, Preview und Schulung
  7. 7. Wir hatten erstmal gewaltige Zweifel!
  8. 8. „Jeder Commit automatisch auf Produktion!“
  9. 9. Wer bezahlt den Aufwand für die automatisierte Testabdeckung?
  10. 10. Wie soll so ein automatisches Deployment funktionieren?
  11. 11. Jetzt sollen If-Bedingungen für neue Features in den Code?
  12. 12. Warum wollte der Product Owner so etwas?
  13. 13. Nur ein genutztes Feature
 ist ein gutes Feature
  14. 14. Keine goldenen Wasserhähne
  15. 15. Features in kleinen Schritten zur Verfügung stellen
  16. 16. Weniger Komplexität
  17. 17. Mehr Zufriedenheit
  18. 18. Was mussten wir tun, damit es funktioniert?
  19. 19. Kein extra QA
  20. 20. Operations im Team
  21. 21. Support durch Business Analysten und Developer
  22. 22. Alle Verantwortung und Fähigkeiten mussten in ein Team
  23. 23. Technologisch brauchten wir eine Deployment Pipeline
  24. 24. Automatisierte Test-Stages aber nur ein Stage für Menschen
  25. 25. Der Test-Modus ersetzt das Preview- System test
  26. 26. Feature Switches sind nötig, aber seltener, als man denkt
  27. 27. Kanban statt Scrum pull
  28. 28. Commanders Intent
 Acceptance Tests Kommunikation ! keine detaillierte Spezifikation !#?
  29. 29. Community mit Anwendern und Entscheidern aufbauen
  30. 30. Anwendungs-Controlling
  31. 31. Die Anwendung informiert selber
 über Änderungen neu
  32. 32. Wie weit sind wir damit gekommen?
  33. 33. > 500.000 Zeilen Code
 (Java, Javascript, Groovy, XML, HTML)
  34. 34. 23.000 Unit Tests & 400 Selenium Test
  35. 35. Fehler schnell beheben ist wichtiger als vermeiden
  36. 36. 17 „Entwickler“, 3 BA, 1 UX, 1 PO
  37. 37. Klassische Rollenbilder gemischt
  38. 38. Was hat es in uns verändert?
  39. 39. „Das ist mein Produkt“
  40. 40. Test Driven Development
  41. 41. Refactoring in small steps
  42. 42. Agile Methoden und Continous Delivery greifen perfekt ineinander!
  43. 43. Keine Abstimmung zum Rollout nur Freischalten ist Entscheidung des Product Owners
  44. 44. Feature oder Bugfix Wo ist der Unterschied?
  45. 45. Neue Prioritäten für Bugfixes/Findings Quickwins first
  46. 46. Hard-Coded ist die neue Konfigurierbarkeit
  47. 47. Was sind die Voraussetzungen?
  48. 48. „Einfach“ beginnen Es gibt kein „Fertig“
  49. 49. „Seniore“ Teammitglieder
  50. 50. Ohne Disziplin geht es nicht
  51. 51. Nein sagen! Der Sog zum klassischen Vorgehen wird stark sein
  52. 52. Eigenverantwortung muss gewollt und möglich sein
  53. 53. Haben sich die Erwartungen erfüllt?
  54. 54. JA!
  55. 55. Themen können technisch und fachlich fertiggestellt werden!
  56. 56. Continuous Delivery ist ein Mindshift
  57. 57. Marco Kisperth marco@kisperth.de @kisperth Jörg Müller joerg.mueller@hypoport.de @joergm blog-it.hypoport.de Vielen Dank an Verena Würfel für die Erstellung der Grafiken

×