Rockn roll statt enterprise

560 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
560
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • Endlich mal eine Konferenz in Hamburg!\n
  • Wie gehts Euch? Wer hat gestern noch ein Konferenzbier getrunken?\n
  • \n
  • \n
  • Ich komme aus München. \n
  • Und wenn ich gefragt werde wo ich herkomme sag ich immer Hamburg. Doof wird es, wenn die Leute sich auskennen und dann fragen: Wo in Hamburg?\n
  • Dann erzähl ich Ihnen, dass ich aus Lüneburg bin. Wenns dumm läuft kennen die sich da aus und fragen, wo genau.\n
  • Und dann muss ich immer zugeben dass ich aus nem kleinen Kaff in der Nähe von Lüneburg komme :-).\n
  • Das ist vermutlich auch der Grund warum ich nach Bayern geschickt wurde, als Entwicklungshelfer, um den Jungs so Dinge wie IT, Internet und so beizubringen.\n
  • Deshalb - schön, wieder in Hamburg zu sein.\n
  • Das letzte Mal war ich vor 4 Jahren für Heise Security hier, und zwar wirklich genau hier.\n
  • Ich gehe mal davon aus, dass es nicht schlimm ist wenn ich das erwähne.\n
  • , und habe was über Security bei Web 2.0 erzählt. \n
  • Web 2.0 Security hat sich nie so wirklich durchgesetzt, deshalb heute was über hippere Themen wie Lean Startup, DevOps und so.\n
  • \n
  • \n
  • Wer ist Management? Wer ist im agilen Kontext Management, also Scrum Master oder PO? \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 1991 das erste mal software verkauft, papa von zwillingen, opensource-fan. noch vor apple und so. \n
  • \n
  • Scrum seit 2005 \nBei Mayflower arbeiten 65 Entwickler und 10 Leute, die entweder komische unnütze Dinge machen oder stören, sprich managen. Früher hätte man gesagt „Die arbeiten für mich“, in agilen Unternehmen ists aber faktisch anders herum - ich arbeite für sie. Konkret gibt es bei uns ein Kanban für die Geschäftsführer, in das jeder öffentlich oder nicht-öffentlich Aufgaben reinstellen kann, und gemeinsam ausgehandelte Akzeptanzkriterien, ab wann die Aufgabe als abgenommen gilt, und Communities of Practice dürfen in jedem Gremium mitentscheiden. Wie bei den meisten inzwischen gibt es bei uns Slacktime, Communities of Practice, DevOps-Meetings etc.\n
  • Scrum seit 2005 \nBei Mayflower arbeiten 65 Entwickler und 10 Leute, die entweder komische unnütze Dinge machen oder stören, sprich managen. Früher hätte man gesagt „Die arbeiten für mich“, in agilen Unternehmen ists aber faktisch anders herum - ich arbeite für sie. Konkret gibt es bei uns ein Kanban für die Geschäftsführer, in das jeder öffentlich oder nicht-öffentlich Aufgaben reinstellen kann, und gemeinsam ausgehandelte Akzeptanzkriterien, ab wann die Aufgabe als abgenommen gilt, und Communities of Practice dürfen in jedem Gremium mitentscheiden. Wie bei den meisten inzwischen gibt es bei uns Slacktime, Communities of Practice, DevOps-Meetings etc.\n
  • Scrum seit 2005 \nBei Mayflower arbeiten 65 Entwickler und 10 Leute, die entweder komische unnütze Dinge machen oder stören, sprich managen. Früher hätte man gesagt „Die arbeiten für mich“, in agilen Unternehmen ists aber faktisch anders herum - ich arbeite für sie. Konkret gibt es bei uns ein Kanban für die Geschäftsführer, in das jeder öffentlich oder nicht-öffentlich Aufgaben reinstellen kann, und gemeinsam ausgehandelte Akzeptanzkriterien, ab wann die Aufgabe als abgenommen gilt, und Communities of Practice dürfen in jedem Gremium mitentscheiden. Wie bei den meisten inzwischen gibt es bei uns Slacktime, Communities of Practice, DevOps-Meetings etc.\n
  • Unsere typischen Projekte dauern zwischen 3 Monaten und 5 Jahren\n
  • An einem Projekt arbeiten im Regelfall 2 bis maximal 12 Personen. Kunden sind Firmen wie MAN, Vaillant, Siemens, Nintendo, Sixt, OBI, wir sind aber auch an der Telekom Cloud beteiligt und haben Sevengames / Sat 1 Spiele vollständig entwickelt. \nVermutlich sind wir von der Größenordnung der Projekte her etwa da, wo auch die meisten Teilnehmer hier sind. \n
  • \n
  • - Nils langner: lass uns mal den Talk koordinieren.\n- Eingereicht ohne den Talk von Bastian und Lars zu kennen\n- Lars erzählt schon die hälfte von dem was ich mache\n- zu alt um noch dinge zu ändern\nAber: wer hätte gerne alle die dinge, die lars erzählt hat? \nWer glaubt, dass er seinen chef überzeugen kann?\n- also hab ich die dinge, die noch fehlen hier drin. \n- _und_ harte zahlen um euern chef zu überzeugen.\n
  • Ich gehe mal davon aus, dass jeder diese Stichworte schon mal gesehen hat und kennt. Und zwar weil er Hackernews liest. Deshalb mal die einfache Frage: wer kennt HackerNews nicht? \nUnd wer bei Hackernews nicht nur die penetrante Eigenwerbung von Y-Combinator verfolgt, dem sollten die folgenden Fragen bekannt vorkommen: \n
  • Wie oft deployed Facebook? \nKorrekt, einen neuen Release gibt es einmal die Woche - und ein Set von festen Zwischenreleases mit Bugfixes ebenfalls. \n
  • Aber man muss gar nicht in das Ausland gucken, das gleiche gibts auch ein paar Hundert Meter weiter. Dort gibt es schon seit 2009 - iirc - einen fixen wochenrhythmus. \n
  • Und die Frage nach der wohl bekanntesten Continuous Deployment-Story, direkt von John Allspaw persönlich.\n
  • Als ich das 2009 gelesen habe habe ich nur gedacht „10 mal am Tag? Welchen Sinn soll das haben.“. „Weil sie es können?“ - ok, gibt Punkte auf der Coolness-Skala, verstehen tue ich es trotzdem nicht. \n
  • \n
  • Schauen wir uns mal Enterprise an ... \n
  • Aber was heisst Enterprise? Dass man erst mal ein Big Design Upfront macht.\n
  • Zunächst findet man raus wer überhaupt irgendwas will\n
  • Dann kommt ein 23jähriger Frischinformatiker, den die meisten hier Junior genannt hätten, Cap Gemini aber „Business Analyst“ und redet mit den Stakeholdern. \n
  • Was er macht ist dann jede Menge toter Baum, und es gibt eine Requirements Liste mit funktionalen und nonfunktionalen Requirements.\n
  • Am Ende gibt es 500 Seiten Anforderungsdokumentation und Rahmenbedingungen.\n
  • \n
  • \n
  • \n
  • \n
  • Und die Softwareentwickung verschwindet in ein schwarzes Loch.\n
  • \n
  • Wer kennt den Standish Group Chaos Report? \nWer glaubt die Daten? Es ist ein echtes Phänomen, dass man im praktischen Arbeiten nur Leuten begegnet, die die Ausnahme zu dieser Regel bilden :-).\nDer Report bildet ziemlich gut die Realität ab und wird auch von anderen Quellen (Larry Putnam / QSM) bestätigt. \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Feature creep\n
  • Dark Matter - wer kennt die? \n
  • Auswertung über 150 Projekte von Agilemanagement, der Firma des Kanban-Papstes David J Anderson. Es handelt sich um Projekte der Größenordnung um 180 Tage. \nDavid J Anderson sagt: „Es ist ein Fakt, lern damit zu leben“, wörtlich „Embrace Dark Matter“\nPraktisch ist das die empirische Grundlage für das „pi“, das in unsere Daumen/Buffer-Kalkulation der Projekte einfliesst. \nMit klassischem Projektmanagement geht man hier dann in den Changemanagement Prozess, und man streitet sich darüber was Feature und was Bug ist. \n
  • Wenn das Budget aber fix ist, dann wir auch nur 100% der Arbeitszeit eingesetzt - und nicht 150% . Weil ich die Dark Matter aber brauche ich, um das Projekt überhaupt machen zu können. Wenn ich nicht in Mehrarbeit gehe, dann bekomme ich nur einen Teil der initialen Features.\n
  • Betrachtet man jetzt noch die Features, die in Wahrheit gar nicht gebraucht werden, dann sieht das Ergebnis noch mal eins schlechter aus: am Ende haben wir 66% der ursprünglichen Features realisiert.\n
  • Genau das erklärt aber, warum Projekte so aussehen. \n
  • Wenn man jetzt noch die Verteilung der Features anguckt, haben wir sogar nur 37% sinnvolle Features geliefert. \n
  • \n
  • \n
  • Schauen wir uns mal an, was wir daran machen können. Ihr macht ein neues Projekt in 2013. Gelaunched wird Ende Juni, Lifegang zum 1.7. (in Wahrheit natürlich am Freitag, dem 28.6 - dann können die Entwickler das noch über das Wochende fixen :-) ) \nIn klassischen Modellen bin ich ein halbes Jahr im Tauchmodus, und pünktlich zum 28.6 gibt es den ersten wirklichen Release, der dann auch vor Kunde sichtbar ist. \n
  • Wenn wir den Pointy haired boss fragen, läuft das projekt so: \n
  • Im Gehirn des Pointy Haired Boss sieht unsere Arbeit so aus - wir arbeiten, und in jedem der 12 Sprints erzeugen wir 1/12 des Business-Values. \nMilestones dann jeweils 1/6tel\n\n
  • Faktisch wissen wir aber von Software, dass hier meistens das Pareto-Prinzip gilt. \nUnd normalerweise versucht man den hohen Business-value anzugehen sobald die Basisstruktur steht. Wir produzieren also nicht linear Business-Value, sondern erzeugen am Anfang mehr. \n
  • Und weil wir so priorisiert arbeiten, haben wir recht früh die wichtigsten 80% von Business-Value realisiert. Trotzdem arbeiten wir noch weiter, schliesslich will die Gesamtheit aller geplanter Features umgesetzt werden.\n
  • Und genau an der Stelle setzt agil an. Ursprünglich aus der Praxiserfahrung heraus, dass man ohnehin immer etwas übersieht so gebaut, wird es hier zum anfassbaren Vorteil. \n
  • Zu Beginn unseres Projektes im Januar haben wir einen Product Backlog - kennt den jeder? - der mit den Epics unseres Produktes gefüllt ist. Die wichtigen Epics haben wir bereits in User-Stories zerlegt, so dass wir direkt anfangen können. Und genau das machen wir *klick* und ziehen die ersten Stories in den Sprint.\n
  • Zu Beginn unseres Projektes im Januar haben wir einen Product Backlog - kennt den jeder? - der mit den Epics unseres Produktes gefüllt ist. Die wichtigen Epics haben wir bereits in User-Stories zerlegt, so dass wir direkt anfangen können. Und genau das machen wir *klick* und ziehen die ersten Stories in den Sprint.\n
  • Zu Beginn unseres Projektes im Januar haben wir einen Product Backlog - kennt den jeder? - der mit den Epics unseres Produktes gefüllt ist. Die wichtigen Epics haben wir bereits in User-Stories zerlegt, so dass wir direkt anfangen können. Und genau das machen wir *klick* und ziehen die ersten Stories in den Sprint.\n
  • Zu Beginn unseres Projektes im Januar haben wir einen Product Backlog - kennt den jeder? - der mit den Epics unseres Produktes gefüllt ist. Die wichtigen Epics haben wir bereits in User-Stories zerlegt, so dass wir direkt anfangen können. Und genau das machen wir *klick* und ziehen die ersten Stories in den Sprint.\n
  • Zu Beginn unseres Projektes im Januar haben wir einen Product Backlog - kennt den jeder? - der mit den Epics unseres Produktes gefüllt ist. Die wichtigen Epics haben wir bereits in User-Stories zerlegt, so dass wir direkt anfangen können. Und genau das machen wir *klick* und ziehen die ersten Stories in den Sprint.\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Jetzt haben wir den ersten Sprint zu Ende gearbeitet, und würden jetzt eigentlich mit Story 3, 4 und 5 weitermachen. In der Zwischenzeit hat der Kunde aber nachgedacht und gemerkt, dass eine andere Sache eigentlich total gut wäre, und die auch mit in den Backlog aufgenommen. Und weil sie so wertvoll ist, nehmen wir sie auch gleich auf. Und genau hier wird es spannend\n
  • Wenn ich in jedem Sprint neue Dinge mit dazubekomme, die einen höheren Wert haben als die initial geplanten User Stories, dann erzeuge ich recht schnell einen höheren Business-Value. In diesem Beispiel haben wir schon nach 3 Sprints den ROI des initialen Budgets an Business-Value erzeugt. Und am Ende haben wir sogar 140% des ursprünglichen Businessvalues erreicht, wie geil ist das denn?\n
  • Und hier haben wir den Grund, warum Agil im Projekterfolg besser ist - weil hier durch permanentes drauflegen von Businessvalue mehr Value generiert werden kann. \n
  • Trotzdem haben wir noch ein Problem - wir erzeugen jetzt zwar 140% des initial geplanten Business-Values, aber trotzden nur 77% sinnvolle Features. Wie können wir das aufbrechen? \n
  • \n
  • Das Problem geht eigentlich die beiden an. Die Kommunikation erfolgt gerne über lustige Marktbefragungen, Friends- & Family-Kunden, eigene Visionen und Kundenbeschwerden :-).\n
  • Das Problem geht eigentlich die beiden an. Die Kommunikation erfolgt gerne über lustige Marktbefragungen, Friends- & Family-Kunden, eigene Visionen und Kundenbeschwerden :-).\n
  • Das Problem geht eigentlich die beiden an. Die Kommunikation erfolgt gerne über lustige Marktbefragungen, Friends- & Family-Kunden, eigene Visionen und Kundenbeschwerden :-).\n
  • Das Problem geht eigentlich die beiden an. Die Kommunikation erfolgt gerne über lustige Marktbefragungen, Friends- & Family-Kunden, eigene Visionen und Kundenbeschwerden :-).\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Faktisch reden die beiden auch gar nicht miteinander, sondern dazwischen finden noch mal andere Leute statt. Der Product Manager redet mit den Entwicklern, die werfen Pakete zu den Leute im Betrieb, die spielen es ein und der Kunde darf es dann benutzen. \n\n
  • Und genau da sind sie wieder, unsere Probleme: \nDie Zusammenarbeit Product Management und Development klappte klassischerweise nicht. Das Problem haben wir mit agil gelöst. \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Als zweites ist die Strecke Development zu Operations defekt - das wird über DevOps gelöst. \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Die Strecke vom Admin zum Kunden wird im Regelfall durch Monitoring und Fehlermeldungen gelöst, da gibt es im Regelfall nicht so viele Probleme. \n\n
  • Damit ich zu brauchbaren Features komme, brauche ich aber eigentlich die Strecke zwischen Product Entwicklung und Kunde.\n
  • Das Problem ist ebenfalls, dass der Kunde nicht weiss, was er wirklich will. Henry Ford hat das so ausgedrückt. Wenn man mich gefragt Hätte ob ich ein Handy ohne Tasten will, hätte ich Nein gesagt. Wenn man mich gefragt hätte, ob ich meine Softwareapplikationen in einem Store kaufen will, das vom Plattformhersteller kontrolliert wird, hätte ich ebenfalls nein gesagt. \n
  • \n
  • \n
  • Das erste was ich brauche ist Monitoring. Da werde ich ein bischen doppelt zu Lars, ich mache es aber schnell. Im Gegensatz zu Lars will ich aber völlig flexibel sein und nicht alle Daten mit Google und Econda Teilen, und ausserdem habe ich auch ein paar Prozesse, die völlig Endkundenfrei stattfinden. Rechts ist ein Screenshot von graphene, einem Aufsatz auf graphite.\n
  • Das Monitoring sieht dann hier am Beispiel einer Partnerbörse zB so aus dass von 100 Leuten auf der Seite 90% auf der Startseite landen, und 70% auf einer Profilseite - sich allerdings nur 20% registrieren. Das ist mir zu wenig. Jetzt würde ich normalerweise hingehen zB ein Popup machen, um die Leute mehr auf die Registration hinzuweisen. Der Schuss kann aber auch nach hinten losgehen.\n
  • Ausserdem weiss ich ja von oben, dass ich in Wahrheit keine Ahnung habe, was funktioniert und was nicht funktioniert. Die Lösung dazu sind Feature Flags bzw. Feature Flippers, auch Buckets habe ich schon gehört. \nEin Featureflag aktiviert ein Feature pro Nutzer. Auf die Weise kann ich messen, ob es was gebracht hat oder nicht. Technisch ist das trivial - ich setze schlicht eine Flag in der Nutzerdatenbank für dieses Feature, und prüfe zB vor Anzeige des Features ab, ob sie gesetzt ist. Das hier ist ein Beispiel aus dem FeatureFlag-Modul von FuelPHP - generell ist das Thema aber so einfach, dass man es bequem in 2 Stunden selbst bauen kann.\n
  • Im Resultat sehe ich, dass mein Funnel sich in diesem Fall nicht verbessert, sondern verschlechtert hat - und ich nehme das Feature dementsprechend wieder heraus.\nDas Feature darf nur dann bleiben, wenn ich nachweisen kann, dass es gebraucht wird.\n
  • Diese Metriken kommen aus dem Lean Startup Bereich, und wir haben sie gerade für eine Entscheidung genutzt - nämlich ob das Feature bleiben darf oder nicht. Die Jungs dort nennen das „Actionable Metrics“, im Gegensatz zu den „Convenience Metrics“ wie zB Logins heute und Funnel. Sie sagen: eine gute Metric ist eine, die eine Entscheidung erzwingt. Und eigentlich will ich nur Metriken haben, die Entscheidungen erzwingen. \n
  • \n
  • Aber zurück zu den Features und den Feature Flags: Früher war die Welt einfach, da gab es deployte Features. Die wollte zwar zu 45% niemand, aber die waren alle aktiv.\n
  • Heute sieht das anders aus. Der größte Block sind immer noch die Features, die aktiv sind, daneben gibt es aber auch welche die nicht mehr aktiv sind. Das ist Feature Waste, den man wie Technical Debt beseitigen sollte. Aber Achtung: diese ungenutzten Features gibt es ja überall, hier sind sie nur explizit ausgeschaltet. Daneben gibt es natürlich die Features, die gerade getestet werden, und Features, die noch nicht aktiv sind - weil sie etwa getestet werden müssen.\n
  • Und genau aus den letzten ergibt sich eine weitere nützliche Opportunity. Dark launches sind der Launch von Features, die nicht zum Nutzer sichtbar gemacht werden. Damit kann man zwei Dinge machen - zum einen kann man sie testen, ohne dass der Nutzer es weiss (indem man die Zugriffe per JavaScript simuliert), zum anderen kann man bei schwierigen Load-Situationen die Nutzer Stück für Stück freischalten. \n
  • \n
  • Es wird zunächst intern ausgerollt, und danach für ein sehr kleines Subset von Nutzern ausgerollt - und wieder deaktiviert. Für Tests, die grössere Netzwerke betreffen kann das auch mal für ein ganzes Land passieren. Das beinhaltet natürlich auch, dass der Test fehlschlagen kann, und der Nutzer einen Fehler sieht. Facebook sagt, dass jeder von uns vermutlich schon einmal ein solcher Tester war. \n
  • Dem Pointy Haired Boss leuchtet natürlich ein, dass Facebook das macht. Aber taugt das auch für uns, die im Regelfall nicht für einige Hundert Millionen Nutzer deployen? \n
  • Womit er sich anfreunden muss ist die Tatsache, dass sein ganzes Business-Modell auf genutzten Features basiert, und nicht auf ungenutzten Features. Das ist ja noch ganz einleuchtend. \n
  • Schwerer mit dem Einleuchten wird es mit der Tatsache, das man vermutlich schlecht geraten hat, als man die Features entwickelt hat. Warum macht die Product Development Abteilung keine besseren Features? Weil es nicht geht. Wenn weder Facebook noch Google in der Lage sind, aus dem Stand brauchbare Features zu entwickeln, warum sollte Dein Product manager das können? \n
  • Damit dreht sich unser Job. Bislang wurden wir dafür bezahlt, ein bestimmtes Set Features preiswert zu implementieren - und zwar nachhaltig preiswert, Qualität durfte also ruhig mit drin sein. \nDurch das Wissen, dass unsere Features vermutlich nichts taugen, ändert sich das. Eigentlich will man nur validierte Features - denn nur die generieren Business Value. Und weil schon weiss, dass man einige Features nur zum Test produziert, möchte man sie schnell haben - um zu wissen, ob sie funktionieren - und preiswert, denn wir generieren eine grössere Menge von Features.\n
  • Damit dreht sich unser Job. Bislang wurden wir dafür bezahlt, ein bestimmtes Set Features preiswert zu implementieren - und zwar nachhaltig preiswert, Qualität durfte also ruhig mit drin sein. \nDurch das Wissen, dass unsere Features vermutlich nichts taugen, ändert sich das. Eigentlich will man nur validierte Features - denn nur die generieren Business Value. Und weil schon weiss, dass man einige Features nur zum Test produziert, möchte man sie schnell haben - um zu wissen, ob sie funktionieren - und preiswert, denn wir generieren eine grössere Menge von Features.\n
  • Aber wie bekomme ich die Features preiswert und schnell? Zunächst einmal mache ich den Prozess schnell und preiswert - das Zauberwort hier heisst Continuous Deployment. Und zwar nicht im Sinne „wir könnten permanent one-click-releasen“, sondern als fixen Rhythmus.\nWichtig: das dreht Release-Management um, weil man weder weiss noch plant, was genau dabei sein wird. \n
  • Es wird nicht mit Branches gearbeitet, sondern die main line ist immer stabil. Jeder Developer darf jedes Feature committen, trotzdem ist Trunk stabil. Der Trick: Push-Karma - beginnend mit 4 Sternen, mit jedem Push, den er versaut hat, gibt es einen Karma-Punkt weniger. Wenn ein eigenes Feature ausgerollt wird muss man dabei sein, und im Zweifelsfall sehr schnell einen Bugfix liefern. Wenn man was kaputt gemacht hat, ist das öffentlich - genauso wie das Karma - sichtbar, und man sieht auch, welche Zeile Code von Dir es kaputt gemacht hat. \n
  • \n
  • Echte Tests heisst: validierung, nicht unit, nicht selenium. Es ist dann getestet, wenn es vor Nutzer mehr geld verdient hat.\n
  • \n
  • Was PHP für die Serverseite war - nämlich der Glue, der die C-Libraries einfach verknotbar machte, ist heute JavaScript auf der Client-Seite. Und der Client ist nicht mehr nur eine Device, sondern gleiche mehrere, die jeweils anders ticken und einen anderen Workflow haben. \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Yagni! KISS! Vereinfachung! Billige Refactorings\n
  • Wirklich wegwerfen, und die features auch so entwerfen, dass man sie billig wegwerfen muss.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Rockn roll statt enterprise

    1. 1. Hi!
    2. 2. Wie gehts Euch?
    3. 3. Wer ist aus Hamburg?
    4. 4. Ehrlich? Oder Pinneberg, Wedel, Harburg oder so?
    5. 5. Web 2.0 Security
    6. 6. Darf ich Euch kurz vorstellen?
    7. 7. Software Developer?
    8. 8. Manager?
    9. 9. Welcher Softwaredeveloper hätte gerne, dass die Manager besser verstehen wie Software tickt?
    10. 10. Scrum mit 2-Wochen-Sprints?
    11. 11. Test Driven Development?
    12. 12. Pair Programming
    13. 13. Wer macht es mehr als 80% seiner Zeit?
    14. 14. Continuous Integration?
    15. 15. Continous Deployment?
    16. 16. DevOps?
    17. 17. Puppet?
    18. 18. Chef?
    19. 19. Business-Reporting?
    20. 20. {Platzhalter: aufdringliche Eigen- und Firmenwerbung}
    21. 21. Für mich arbeiten 65 Entwickler
    22. 22. Für mich arbeiten 65 Entwickler
    23. 23. Für mich arbeiten 65 Entwickler Ich arbeite für 65 Entwickler
    24. 24. Für mich arbeiten 65 Entwickler Ich arbeite für 65 Entwickler Agil
    25. 25. 3 Monate - 5 Jahre
    26. 26. 2-12 Personen
    27. 27. (35 Slides, langsam sollte ich mal anfangen)
    28. 28. Rock n‘ Roll statt Enterprise
    29. 29. Wie oft deployed Facebook?
    30. 30. Xing: jede Woche
    31. 31. Flickr: 10 Deploys a Day
    32. 32. Warum machen die das?
    33. 33. BIGBig Design Upfront
    34. 34. Stakeholder Analysis
    35. 35. Business Analyst
    36. 36. Requirements Analysis
    37. 37. Der Enterprise Architect macht auf der Basis die Vorgaben ..
    38. 38. .. und im Rahmen der IT Governance ...
    39. 39. wird die Requirements List mit Use Cases dokumentiert.
    40. 40. Das wird dann im Tool modelliert ...
    41. 41. in here
    42. 42. Und am Ende ...
    43. 43. CHAOS REPORT 2011KLASSISCHE IT/WASSERFALL 14% 29% Successful Challenged 57% Failed Quelle: Standish Group Chaos Report 2011
    44. 44. FEATURENUTZUNG Always 7% Often 13% Never UsedSometimes 45% 16% Rarely 19% Quelle: Standish Group XPDAYS 2002
    45. 45. CHAOS REPORT 2011 AGILE 9% 42%49% Successful Challenged Failed Quelle: Standish Group Chaos Report 2011
    46. 46. Ok, schon besser, aber immer noch fies.
    47. 47. Feature/Scope Creep Dark Matter
    48. 48. SCOPE CREEP DARK MATTER Feature Creep Initiale Features 150 113 75 38Januar Februar 0 März April Mai Juni Juli Quelle: Agilemanagement.net 2012
    49. 49. SCOPE CREEP (OHNE ÜBERSTUNDEN) Dark Matter Initiale Features 100 75 50 25Januar Februar März 0 April Mai Juni Juli Quelle: Agilemanagement.net 2012
    50. 50. AM RELEASETAG 33%67% Scope Creep Features Quelle: Agilemanagement.net 2012
    51. 51. CHAOS REPORT 2011KLASSISCHE IT/WASSERFALL 14% 29% Successful Challenged 57% Failed Quelle: Standish Group Chaos Report 2011
    52. 52. + FEATUREWASTE30% 33% Scope Creep 37% Sinnvolle Features Sinnlose Features Quelle: Agilemanagement.net 2012
    53. 53. 37% brauchbar? WTF?
    54. 54. FIXHOW TO
    55. 55. Neues Projekt, 2013, Launch zum 1.7
    56. 56. BUSINESS VALUE100 100 91.7 83.3 75 75 66.7 58.3 50 50 41.7 33.3 25 25 16.7 8.3 0 0 7.1.2013 04.02.13 04.03.13 01.04.13 29.04.13 27.05.13 24.06.13
    57. 57. In 20% der Zeit80% der Lösung
    58. 58. BUSINESS VALUE NACH PARETO100 97.6 98.5 99.1 99.6 100 94.5 96.3 91.7 87.4 75 80.3 68.1 50 45.5 25 0 0 7.1.2013 04.02.13 04.03.13 01.04.13 29.04.13 27.05.13 24.06.13
    59. 59. Agil
    60. 60. Sprint Product Backlog User Story 1 User Story 2 User Story 3 User Story 4 User Story 5
    61. 61. Sprint Product BacklogUser Story 1 User Story 3User Story 2 User Story 4 User Story 5
    62. 62. Sprint Product Backlog User Story 3 User Story 4 User Story 5
    63. 63. Sprint Product Backlog User Story 6 User Story 3 User Story 4 User Story 5
    64. 64. Sprint Product BacklogUser Story 6 User Story 4User Story 3 User Story 5
    65. 65. BUSINESS VALUE MIT AGIL Klassisches Vorgehen Agil150 136.1 137.5 138.5 139.2 139.8 131.2 134.1 126.7113 119.5 107.5 96.3 97.6 98.5 99.1 99.6 100 91.7 94.5 86.2 87.4 75 80.3 68.1 38 45.5 0 0 7.1.2013 04.02.13 04.03.13 01.04.13 29.04.13 27.05.13 24.06.13
    66. 66. 140% Business-Value!
    67. 67. ABER AM ENDE ...63 % 77 % Nützliche Features Nutzlose Features
    68. 68. Warum?
    69. 69. Product Kundemanager
    70. 70. Brilliante Idee!Product Kundemanager
    71. 71. WTF?! Brilliante Idee!Product Kundemanager
    72. 72. Product Kundemanager
    73. 73. Product Developer Operations Kundemanager
    74. 74. Product Developer Operations Kundemanager
    75. 75. Product Developer Operations Kundemanager
    76. 76. Product Developer Operations Kundemanager
    77. 77. AGILProduct Developermanager
    78. 78. Product Developer managerIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
    79. 79. KooperationProduct Developermanager
    80. 80. Kooperation Backlog GroomingProduct Developermanager
    81. 81. Kooperation Backlog Grooming Sprint EstimationProduct Developermanager
    82. 82. Kooperation Backlog Grooming Sprint Estimation Sprint ReviewProduct Developermanager
    83. 83. Kooperation Backlog Grooming Sprint Estimation Sprint Review RetrospektiveProduct Developermanager
    84. 84. Kooperation Backlog Grooming Sprint Estimation Sprint Review RetrospektiveProduct Developermanager User Stories
    85. 85. Kooperation Backlog Grooming Sprint Estimation Sprint Review RetrospektiveProduct Developermanager User Stories Akzeptanzkriterien
    86. 86. Kooperation Backlog Grooming Sprint Estimation Sprint Review RetrospektiveProduct Developermanager User Stories Akzeptanzkriterien Regelmässige Demos
    87. 87. Product Developer Operations Kundemanager
    88. 88. Product Developer Operations Kundemanager
    89. 89. DevOps!Developer Operations
    90. 90. Sharing Culture DevOps!Automation Measurement
    91. 91. Developer Operations
    92. 92. Gemeinsame PlanungDeveloper Operations
    93. 93. Gemeinsame Planung KooperationDeveloper Operations
    94. 94. Gemeinsame Planung Kooperation Gemeinsame DeploysDeveloper Operations
    95. 95. Gemeinsame Planung Kooperation Gemeinsame Deploys Shared CodebaseDeveloper Operations
    96. 96. Gemeinsame Planung Kooperation Gemeinsame Deploys Shared CodebaseDeveloper Operations Shared Knowledge
    97. 97. Product Developer Operations Kundemanager
    98. 98. Product Developer Operations Kundemanager
    99. 99. Wenn ich die Menschengefragt hätte, was sie Kundewollen, hätten sie gesagtschnellere Pferde Henry Ford
    100. 100. Wie finde ich heraus, was die Kunden tatsächlich wollen?
    101. 101. Wenn Sie es nutzen.
    102. 102. Monitoring
    103. 103. 100 100% 90% 75 70% 50 25 20% 18% 10% 0 5% Einstieg Startseite Profilseite Registration Opt-In Mitteilung Forenposting
    104. 104. Feature-Flags (Feature Flipping)if (Feature::flag(profilpage)->popup($userId)) { PopUps::showRegistrationPopUp();}
    105. 105. Ohne Popup Mit Popup100 100% 90% 75 70% 50 25 20% 18% 10% 0 5% Einstieg Startseite Profilseite Registration Opt-In Mitteilung Forenposting
    106. 106. Actionable Metrics
    107. 107. Früher war die Welt einfacher ...
    108. 108. FEATURES aktiv
    109. 109. AKTIVE FEATURES nicht mehr aktivnoch nicht aktiv zum Teil aktiv aktiv
    110. 110. Dark Launches
    111. 111. Die Produktion ist die Testplattform
    112. 112. Jehova!
    113. 113. Wir können uns das nicht leisten!
    114. 114. Business Value = genutzte Features.
    115. 115. Deine Features taugen zur Hälfte nichts.
    116. 116. Funktionalität billig implementieren.
    117. 117. Funktionalität billig implementieren.
    118. 118. Funktionalität billig implementieren.Preiswert und schnell validierte Features liefern.
    119. 119. Continuous Deployment
    120. 120. Verlässliche Mainline
    121. 121. KEINE BRANCHES!
    122. 122. Echte Tests
    123. 123. Einfache und Bewegliche APIs!
    124. 124. Viele Devices, viele Workflows ...
    125. 125. REST/JSON in der Mitte
    126. 126. JavaScript als Glue Language im Client
    127. 127. HTML5 als Infrastruktur im Client
    128. 128. Fazit
    129. 129. Agil nur der Anfang ist
    130. 130. Deine Features Dubilliger machen musst
    131. 131. Schlechte Features Du wegwirfst
    132. 132. Lesen:Eric Ries The Lean StartupJez Humble Continuous DeliveryFacebook Developer Notes Danke! hartmann@mayflower.de @johannhartmann Ich habe noch ca 200 Folien zu Lean Startup & DevOps etc, also sprecht mich einfach an :-)
    133. 133. Addon Slides! For Free!
    134. 134. BEKANNTE PIVOTS• Instagram: 4square-Clone• Flickr: Multiplayer-Game (2002-2004)• Twitter: Podcasting / Audio Sharing Service• Paypal: Crypto für Micromoney auf PDAs• Gowalla: Social Network Game Development
    135. 135. LEAN STARTUPKPIS• Kanban Gesamtlaufzeit
    136. 136. LEAN STARTUPKPIS• Kanban Gesamtlaufzeit• Feature Definition Cycle Time
    137. 137. LEAN STARTUPKPIS• Kanban Gesamtlaufzeit• Feature Definition Cycle Time• Feature Implementation Cycle Time
    138. 138. LEAN STARTUPKPIS• Kanban Gesamtlaufzeit• Feature Definition Cycle Time• Feature Implementation Cycle Time• Anzahl Defekte
    139. 139. LEAN STARTUPKPIS• Kanban Gesamtlaufzeit• Feature Definition Cycle Time• Feature Implementation Cycle Time• Anzahl Defekte• Anteil Waste
    140. 140. Quelle: http://www.charlesconway.com/
    141. 141. REALES BEISPIEL• Feature-Pipeline mit 33 neuen Features/Woche• 10 Programmierteams a 3 Features/ Woche• 90 Features parallel im Multivariantentest• Messung in Erlös(Mit Feature - Ohne Feature)• 10% der Features bleiben erhalten
    142. 142. Minimum ViableProduct Idea Creation Customer Feature Analysis Collect Feedback Implement & Data feature Test Feature
    143. 143. Minimum Viable Product Idea Creation Customer Feature Analysis Collect Feedback Implement & Data Feature TestDifferent Pivot Feature BaseProduct
    144. 144. Rollout 1 Review & Interal & A/B-Customer Theme Feature Develop- Rollout / Story External Testing,Analysis Definition Definition ment Rollback Points Testing Business Monitoring
    145. 145. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Regelmässige Nutzertreffen •Feature Voting •Nutzer-Feedback •Business-Metriken •Wettbewerberanalyse •internes Brainstorming •Development
    146. 146. A/B- Review & Interal &Kunden- Epic Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Kondensierung •Epics •Bewertung
    147. 147. A/B- Review & Interal &Kunden- Epic Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •User Stories •„Mininum Marketable Features“ •Akzeptanzkriterien •Readyness •Erwartete Wirkung auf Business-Metriken
    148. 148. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Machbarkeit und Abhängigkeiten •Story Point Schätzung durch das Development •Verfeinerung der Anforderungen •Priorisierung
    149. 149. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Bearbeitung nach Priorität •Realisierung über Feature Flags •Gateway: Definition of Done Minimum Marketable Featureset
    150. 150. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •internal Review •internal Usability Testing •external Usability Testing •Customer Review
    151. 151. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Teilrollout in Produktion •A/B-Testing •Realtime Business Monitoring •vollautomatischer Rollout / Rollback
    152. 152. A/B- Review & Interal &Kunden- Themen Feature Develop- Testing, Story External Rolloutanalyse Definition Definition ment Business Points Testing Monitoring •Voller Rollout bei Erfolg •Modifikation des Features •Verwerfen des Features •Reduzieren von „Feature-Waste“

    ×