[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?

1. Marco Kisperth, Jörg Müller | Hypoport
Continuous Delivery ist keine Technologie

2. Marco Kisperth
der Product Owner
@kisperth
Jörg Müller
der Techniker
@joergm

3. Unser Product Owner hatte
eine Vision!

4. Update der Anwendung mindestens
einmal pro Stunde möglich

5. Features werden während der Umsetzung
laufend ausgerollt

6. Ein System für Produktion, Akzeptanz,
Preview und Schulung

7. Wir hatten erstmal
gewaltige Zweifel!

8. „Jeder Commit automatisch auf
Produktion!“

10. Wer bezahlt den Aufwand für die
automatisierte Testabdeckung?

11. Wie soll so ein automatisches
Deployment funktionieren?

12. Jetzt sollen If-Bedingungen für neue
Features in den Code?

13. Warum wollte der Product
Owner so etwas?

14. Nur ein genutztes Feature
ist ein gutes Feature

15. Keine goldenen Wasserhähne

16. Features in kleinen Schritten zur
Verfügung stellen

17. Weniger Komplexität

18. Mehr Zufriedenheit

19. Was mussten wir tun,
damit es funktioniert?

20. Kein extra QA

21. Operations im Team

22. Support durch Business Analysten
und Developer

23. Alle Verantwortung und Fähigkeiten
mussten in ein Team

24. Technologisch brauchten wir eine
Deployment Pipeline

25. Automatisierte Test-Stages aber nur
ein Stage für Menschen

26. Der Test-Modus ersetzt das Preview-
System
test

27. Feature Switches sind nötig, aber
seltener, als man denkt

28. Kanban statt Scrum
pull

29. Commanders Intent
Acceptance Tests
Kommunikation
!
keine detaillierte Spezifikation
!#?

30. Community mit Anwendern und
Entscheidern aufbauen

31. Anwendungs-Controlling

32. Die Anwendung informiert selber
über Änderungen
neu

33. Wie weit sind wir damit
gekommen?

34. > 500.000 Zeilen Code
(Java, Javascript, Groovy, XML, HTML)

35. 23.000 Unit Tests & 400 Selenium Test

36. Fehler schnell beheben ist wichtiger als
vermeiden

37. 17 „Entwickler“, 3 BA, 1 UX, 1 PO

38. Klassische Rollenbilder gemischt

39. Was hat es in uns
verändert?

40. „Das ist mein Produkt“

41. Test Driven Development

42. Refactoring in small steps

43. Agile Methoden und Continous Delivery
greifen perfekt ineinander!

44. Keine Abstimmung zum Rollout
nur Freischalten ist Entscheidung des
Product Owners

45. Feature oder Bugfix
Wo ist der Unterschied?

46. Neue Prioritäten für Bugfixes/Findings
Quickwins first

47. Hard-Coded ist die neue
Konfigurierbarkeit

48. Was sind die
Voraussetzungen?

49. „Einfach“ beginnen
Es gibt kein „Fertig“

50. „Seniore“ Teammitglieder

51. Ohne Disziplin geht es nicht

52. Nein sagen!
Der Sog zum klassischen
Vorgehen wird stark sein

53. Eigenverantwortung muss gewollt
und möglich sein

54. Haben sich die
Erwartungen erfüllt?

55. JA!

56. Themen können technisch und fachlich
fertiggestellt werden!

57. Continuous Delivery ist ein Mindshift

58. 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