Continuous delivery ist keine Technologie

179 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
179
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
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

×