DevOps ist insbesondere ein Kulturwandel

Entwickler und Betriebsmitarbeiter haben heute in der Regel noch recht unterschiedliche Ziele. Von den Entwicklern erwarten die Produktverantwortlichen, möglichst viele Änderungen in kurzer Zeit auszuliefern. Der Anwendungsbetrieb wird daran gemessen, wie „stabil“ und fehlerfrei eine Anwendung im Produktivsystem läuft und bevorzugt deshalb möglichst seltene Änderungen. Wenn man DevOps konsequent interpretiert, müssen zunächst diese beiden Kulturen zusammengebracht werden. Außerdem bleibt es nicht bei Entwicklung und Betrieb, sondern wirkt sich auch Marketing, Support, Design, Security, Compliance usw. aus. Der Vortrag gibt Antworten auf die Fragen, wie eine DevOps-Organisation aussehen kann und auf welche neuen Herausforderungen man dort stößt.

Transcript

1. DevOps ist insbesondere ein Kulturwandel Konstantin Diener | cosee GmbH konstantin.diener@cosee.biz | @onkelkodi
2. Bilder eBooks Hörbücher Musik Videos Apps Web Desktop Auslieferung & Sicherung Smart TV
3. • Gründer & CTO cosee GmbH, Darmstadt • IT-Projekte seit 2004 • ca. 10 Jahre IT-Beratung • agile Methoden seit 2007 • Scrum Master, Product Owner, Agile Coach, Führungskraft, Konferenzsprecher, Entwickler
4. Warum DevOps?
5. Der Vorteil gegenüber der Konkurrenz, der durch DevOps entstehen kann, ist enorm – eine schnellere Auslieferung von Features, eine erhöhte Kundenzufriedenheit, mehr Marktanteile, eine bessere Mitarbeiterproduktivität und glücklichere Kollegen … The Phoenix Project
6. … Warum? Weil Technologie zum dominanten Wertschöpfungsprozess geworden ist und bei der Kundengewinnung in den meisten Unternehmen immer wichtiger (wenn nicht am wichtigsten) wird. The Phoenix Project
7. • Firmen werden zunehmend zu IT Companies • schnellere Time to Market • Reaktion auf Veränderungen am Markt • erhöhte Kundenzufriedenheit
8. Firma Auslieferungs- frequenz Code Deployment Lead Time Reaktion auf Kundenwunsch Amazon 23.000/Tag Minuten hoch Google 5.500/Tag Minuten hoch Netflix 500/Tag Minuten hoch Facebook 1/Tag Stunden hoch klassisch 1/alle 9 Monate Monate/Quartale niedrig/mittel The Phoenix Project
9. kein Selbstzweck
10. Warum Kultur bzw. Organisation?
11. “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Melvin E. Conway, How Do Committees Invent? Clayton M. Christensen, The Innovator’s Dilemma … When Tom West, Data General’s project leader and a former long- time Digital employee, removed the cover of the DEC minicomputer and examined its structure, he saw “Digital’s organization chart in the design of the product.” …
12. #1 Dev und Ops
13. • möglichst viele Features • schnelle Reaktion • Scrum: Shippable Product zum Sprint-Ende • stabile Anwendung • keine gravierenden Fehler • keine Downtimes >> häufige kleine Änderungen >> seltene große Änderungen
14. unterschiedliche Ziele
17. langsame Entscheidungen
18. »Was? 63 Stunden reine Wartezeit?«, sagt Wes ungläubig. »Das ist unmöglich!« Patty sagt süffisant lächelnd: »Oh, natürlich. Weil es doch nur 30 Sekunden tippen sind, oder?« The Phoenix Project
19. Übergaben = Wartezeiten
21. Business-Ziel „Marktführer im Segment X für digitale Videos werden“
22. technologisches Ziel Streben nach einem Software- Produkt, das easy to change ist.
23. #2 technologische Freiheit
24. You build it, you run it.
25. Team entscheidet autark über Technologie
26. Koordination zwischen Teams?
27. Communities of Practice • gemeinsame Standards („common baseline“) • Alltagsprobleme lösen • Wissen verteilen • Innovation treiben
28. #3 interne Services
29. Business-Ziel „Marktführer im Segment X für digitale Videos werden“
32. in Anlehnung an: N. Pfläging, Organisation für Komplexität
33. #4 Experimente und Risikobereitschaft
34. Business-Ziel „Marktführer im Segment X für digitale Videos werden“
35. keine „Anforderungslisten“!
36. Lean Startup Wie lerne ich möglichst schnell möglichst viele über meine potenziellen Kunden?
37. User Story Mapping Was ist der angestrebte Outcome und welchen minimalen Satz an Produktveränderungen brauche ich, um ihn zu erreichen?
38. Design Sprints Wie überprüfe ich eine Hypothese in der Praxis innerhalb von fünf Tagen?
39. Lean Experimentation Wie kann ich meine Hypothese mit dem kleinstmöglichen Experiment testen?
41. Endless game und #noprojects
42. • Verantwortung fürs Produkt • echte cross-funktionale Teams • technologische Freiheit • interne Services für die Produktteams • kontinuierliche Experimente • keine Projekte mehr DevOps in Orga und Kultur
43. Konstantin Diener | cosee GmbH konstantin.diener@cosee.biz | @onkelkodi Bildnachweise: Mainboard: http://www.shutterstock.com/gallery-2070245p1.html The Phoenix Project: https://www.safaribooksonline.com/library/view/the-phoenix-project/9781457191350/image/ cover.jpg The Lean Startup: https://dekwf27uis-flywheel.netdna-ssl.com/wp-content/uploads/2013/08/lean-startup_book-cover.jpg User Story Mapping: http://ebook-dl.com/pictures/books/user-story-mapping-jeff-patton-peter-economy(www.ebook- dl.com)_Large.jpg Sprint: http://www.gv.com/sprint/img/cover.png Lean Experimentation in Action: https://s3.amazonaws.com/titlepages.leanpub.com/leanexperimentation/hero? 1487678608 > blog.cosee.biz > jobs.cosee.biz > agile.cosee.biz Kolumne: DevOps Stories von Konstantin Diener