5. All the PHP code I’ve seen in that
experience has been messy,
unmaintainable crap. Spaghetti
SQL wrapped in spaghetti PHP
wrapped in spaghetti HTML.
http://www.codinghorror.com/blog/
10. Der Pitch ist in drei Tagen ...
Hmmm ....
3 Tage ...
da können wir es ja gleich ganz
implementieren ...
11.
12. Ich rufe nur an, weil wir einen Bug
in der Registrierung gefunden
haben...
Ah, ich sehe es, Moment. ... Ok, gefixt.
... und ich wollte wissen, ob ich
einen Change Request ... ... „gefixt“?
Jepp.
13. Wir brauchen ein Portal mit
Einbindung der Stellenbörse, wie
lange braucht Ihr?
14. Wir brauchen ein Portal mit
Einbindung der Stellenbörse, wie
lange braucht Ihr?
Bis 18:00 sind wir fertig
15. Wir brauchen ein Portal mit
Einbindung der Stellenbörse, wie
lange braucht Ihr?
Bis 18:00 sind wir fertig
Ich brauche es aber bis 16:00
16. Wir brauchen ein Portal mit
Einbindung der Stellenbörse, wie
lange braucht Ihr?
Bis 18:00 sind wir fertig
Ich brauche es aber bis 16:00
Ok, Captain
29. Never Used Rarely Sometimes Always Often
Features
Often
13%
Always
7%
Never Used
Sometimes 45%
16%
Rarely
19%
30.
31. • Ein erster Prototyp ist schnell und preiswert
• Der Prototyp ist per Definition live
• Nutzerfeedback kommt von der ersten Minute
• Bugfixes / neue Features sind innerhalb von kurzer Zeit zu
machen
32. Business-Go
Idee
Kleine Lösung
Launch
als Demo
Modifikation/
Validierung
Abschalten Erweiterung
33. Portale / Jahr: 10
davon erfolgreich: 6
Wissen, wie man es
besser macht: unbezahlbar
34. Portale / Jahr: 10
davon erfolgreich: 6
Wissen, wie man es
besser macht: unbezahlbar
Guter Plan.
35.
36. Fail early and fail cheap - you just
can‘t do that in C.
37. I believe the best way to convince
Zuck that something is a bad idea is
to build it and let him use it.
Facebook, Working with
Zuck
46. • Kontinuierliche Kundeninteraktion:
• Schnelle
Prüfung von Märkten,
Kundengruppen,Pricing
• Minimierung der Kosten für diese Prüfungen
• Mess- und nachweisbare Fortschritte
57. • Feature Durchlaufzeit
• Feature Definition Cycle Time
• Feature Implementation Cycle Time
• Anzahl Defekte
58. • Feature Durchlaufzeit
• Feature Definition Cycle Time
• Feature Implementation Cycle Time
• Anzahl Defekte
• Anteil Waste
59. VORAUSSETZUNGEN
• funktionierender Agiler Prozess im Development
• funktionierendes Continuous Deployment etc
• mächtiges Realtime Business Monitoring
• OpenSource-Stack
60. • Plattform ist Commodity
• Engineered für schnellen Deploy
• Webapplikationsfeedback ist unmittelbar
• „Fail Fast and Fail Cheap“ - Kultur
61.
62. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Regelmässige Nutzertreffen
•Feature Voting
•Nutzer-Feedback
•Business-Metriken
•Wettbewerberanalyse
•internes Brainstorming
•Development
Schnelle Geschäfte I Mayflower GmbH I 2011 I
63. A/B-
Review & Interal &
Kunden- Epic Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Kondensierung
•Epics
•Bewertung
Schnelle Geschäfte I Mayflower GmbH I 2011 I
64. A/B-
Review & Interal &
Kunden- Epic Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•User Stories
•„Mininum Marketable Features“
•Akzeptanzkriterien
•Readyness
•Erwartete Wirkung auf Business-Metriken
Schnelle Geschäfte I Mayflower GmbH I 2011 I
65. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Machbarkeit und Abhängigkeiten
•Story Point Schätzung durch das Development
•Verfeinerung der Anforderungen
•erwarteter Business impact
•Priorisierung
Schnelle Geschäfte I Mayflower GmbH I 2011 I
66. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Bearbeitung nach Priorität
•Realisierung über Feature Flags
•Definition of Done
•Minimum Marketable Featureset
Schnelle Geschäfte I Mayflower GmbH I 2011 I
67. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•internal Review
•internal Usability Testing
•external Usability Testing
•Customer Review
Schnelle Geschäfte I Mayflower GmbH I 2011 I
68. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Teilrollout in Produktion
•A/B-Testing
•Realtime Business Monitoring
•vollautomatischer Rollout / Rollback
Schnelle Geschäfte I Mayflower GmbH I 2011 I
69. A/B-
Review & Interal &
Kunden- Themen Feature Develop- Testing,
Story External Rollout
analyse Definition Definition ment Business
Points Testing
Monitoring
•Voller Rollout bei Erfolg
•Modifikation des Features
•Verwerfen des Features
•Reduzieren von „Feature-Waste“
Schnelle Geschäfte I Mayflower GmbH I 2011 I
70.
71. If we knew what it was we were
doing, it would not be called
research, would it?
Notas do Editor
\n
Ich sehe unter den Zuhörern einige Namen, die schon eine Weile in der PHP-Welt zugange sind. Hallo alte Leute!\n
Damals brauchten wir noch kein Ajax, und wie man sieht war Design auch eher zweitrangig.\n
Und es war das sogenannte Dark Age on PHP. Da haben wir an unserem guten Image gearbeitet, und waren nicht nur in Security, sondern überhaupt als die besten Programmierer der Welt bekannt.\n
Dementsprechend haben wir von jeder Seite viel Respekt bekommen.\n
Und uns unseren festen Platz in der IT-Welt geschaffen.\n
\n
Im Jahr 2000 hatten wir inzwischen thinkPHP gegründet, und wollten damit PHP mehr in das Unternehmensumfeld bringen.\n
Und eines Tages bekamen wir eine Anfrage von einem anonymisierten Unternehmen aus München (Siemens kann in München praktisch jeder sein), die ein Portal haben wollten.\n
Also haben wir das ganze implementiert. In der Präsentation selbst stellte sich heraus, dass sie uns eigentlich mehr auf Verdacht eingeladen hatten und keineswegs die Absicht hatten, uns zu beauftragen. So lief die Präsentation auch ganz normale, bis wir dann die Demo kurz online - bereits mit allen Kernfeatures und im Siemens-Layout - zeigten. Die Kollegen von Siemens meinten dann, dass wir uns mit dem Klick-Dummie nicht so viel Arbeit hätten machen sollen, und wir hatten wirkliche Mühe deutlich zu machen dass wir die Applikation einfach programmiert haben.\n
Nachdem die Kollegen begriffen hatten, dass die Applikation tatsächlich echt war, waren sie auch mit unserem Angebot einverstanden - schliesslich war es nur halb so teuer wie die nächstbillige Konkurrenz, und Faktor 20 preiswerter als andere Mitbieter.\n
Aber die Irritation blieb erhalten. Ein paar Verhaltensmuster waren auf einmal anders, wenn man mit PHP zu tun hatte.\n
Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
Unsere Kunden waren ziemlich begeistert davon, einen persönlichen Scotty zu haben. Das hatte einen Grund. Sie waren es nämlich anders gewohnt. \n
Aber warum fanden die Unternehmen das so super? Weil sie vorher anders gearbeitet haben, und auch das hatte mit Enterprise zu tun.\n
Sie hatten sich von einer bekannten Unternehmensberatung bzw. einem grossen Softwarehaus die professionelle Lösung für Ihr Problem andienen lassen, die für Enterprise geeignet ist.\n
Nur dass hier die Kosten ein wenig höher lagen ... \n
... und die Umsetzungsgeschwindigkeit geringfügig höher war...\n
Dann gab es den Big Bang Release \n
... und am Ende hat es niemand benutzt. \n
Jetzt könnte man natürlich sagen, dass es immer noch nicht genug Planung ist. Das man nicht genug Consulting hatte, und dass das CMS nicht Enterprise genug war. Aber die Kollegen beim Kunden haben noch einmal nachgedacht ... \n
Chaos Report 2009\n32 % Successfull: in Time, in Budget, all features\n44% Challenged: Late, over Budget, less functionality\n24% Failed: Canceled or never used.\n
Werte von XP 2002, auch standish group\n
Aber zurück zu unserem anonymen Kunden ... \n
Das war die Information, die der anonyme Kunde aus München über PHP mitgenommen hatte.\n
Eine neue kleine Lösung kostet 5-10.000 EuroBugs und neue Features können jeweils in Stunden geliefert werden nach drei Monaten wusste man ob die Idee funktioniert oder nicht\n
... und am Ende hat es niemand benutzt. \n
Aber warum funktionieren solche Dinge mit PHP?\n
Die Sprache wurde genau designed, um schnell und preiswert zu wissen, was funktioniert und was nicht funktioniert. Und das hat sich nicht nur in der Architektur, sondern auch in der Kultur niedergeschlagen\n
Eines dieser Unternehmen, das aus dieser Kultur heraus enstanden ist ist Facebook - und genau dort findet man folgenes Beispiel (übrigens auch agil, „architectural Spike“, nur eben als komplettes feature)\n
Facebook wurde im Jahr 2004 gelaunched. Eigentlich war 2004 eine sehr beschissene Zeit. Die Dotcombubble war bereits in 2000 geplatzt, und so war bei den VCs Pessimismus angesagt. \n
Trotzdem hat Facebook erheblich VC bekommen. Weil man nachweisen konnte, dass die Nutzerzahlen nicht nur exponentiell stiegen, sondern die die Nutzer auch deutlich Zeit auf der Plattform verbrachten.\n
Ebenfalls im Jahr 2004 wurde IMVU gegründet, eine Plattform für Avatare, die chatten können. \n
Gegründet wurde es von Eric Ries, ohne Fremdkapital. Es wurde in 6 Monaten entwickelt (das hätten wir schneller gekonnt), und hat vom ersten Tag an Geld verdient. 2007 wurde es für 10 Millionen US$ verkauft. Das, was er in diesem Kontext gelernt und gemacht hat hat er als Lean Startup weiterentwickelt - und als Marke eingetragen.\n
\n
Hinter Lean Startup verbirgt sich die Idee, schnelle Kundenentwicklung mit agiler Softwareentwicklung zu kombinieren. Die agile Softwareentwicklung sollten die meisten der Zuhörer kennen, bei der Produktentwicklung sieht es anders aus.\n
Die Kernideen stammen aus dem Buch „Four Steps to Epiphany“ von Steven Blank, der selbst als Silicon-Valley-Entrepreneur 5 IPOs - und auch ein paar gescheiterte Unternehmen hinterlassen hat.\n
Customer Discovery: Ideen sammeln\nCustomer validation: Sichern, dass sie wirklich funktionieren\nCustomer Creation: Implementieren der realen Strecke\nCompany Building: Skalieren\n
\n
Man beginnt mit dem kleinsten anzunehmenden Produkt - dem Mininum Viable Product. \nGeschichte von Zappos mit Schuster\nGeschichte von unseren Kunden\n
Wenn ich das MVP habe, bewege ich mich über das MMF weiter. Jeder der Schritte wird durch Monitoring geprüft, und ich sichere damit ab, dass meine Annahmen tatsächlich stimmen.\n
Wenn ich merke, dass ich dem Ziel nicht näherkomme, habe ich die Möglichkeit zu pivoten - also mein aktuelles Unternehmensziel nicht weiterzuverfolgen. Instagram: 4square-Clone\n Flickr: Multiplayer-Game (2002-2004)\n Twitter: Podcasting / Audio Sharing Service\n Paypal: Crypto für Micromoney auf PDAs\n Gowalla: Social Network Game Development\n Microsoft: Basic für Heimcomputer\n Youtube: Video Dating Site\n
\n
\n
Konkret wird das in der Praxis meist durch einen Kanban gelöst. An die Stelle eines klassischen oder eine Scrum-Prozesses tritt eine gemeinsame, alle Bereiche der Software übergreifende Kanban-Wand - oder ersatzweise eine Softwarelösung, wie etwa Atlassians Greenhopper oder der Pivotal Tracker (der von den meisten Lean Startups genutzt wird). \n
\n
\n
\n
\n
\n
\n
\n
\n
Der erste Schritt ist die Analyse der Kunden und der Kundenbedürfnisse. Hier wird ein ganzer Katalog von Massnahmen durchgeführt, um einen permanenten Strom von neuen potentiellen Features zu erzeugen.\nRegelmässige Nutzertreffen mit Brainstorming-Sessions \nFeature Voting, Umfragen und Get-Togethers mit den Nutzern\nNutzer-Feedback per E-Mail oder Kommentarfunktion\nBusiness-Metriken und - Reports - das, was aus dem Development geliefert wird. Diese Daten sind btw. im ganzen Unternehmen permanent präsent. \nWettbewerberanalyse\ninternes Brainstorming\nFeedback aus dem Development\n
Im nächsten Schritt werden die gesammelten Ideen konsolidiert, und die wichtigsten Themen - Epics in Scrum-Deutsch - herausgearbeitet. Die Bewertung der Epics passiert zB nach Kano-Verfahren, um zum Beispiel gezielt Basis, Leistungs- und Begeisterungsmerkmale in die Applikation zu holen.\n
Im nächsten Schritt werden die Epics für das Development aufbereitet. Dazu gehört - wie hoffentlich jeder hier Anwesende weiss - \nUser Stories definieren\n„Mininum Marketable Features“ - das minimale Set von Features, das für den Kunden reicht\nAkzeptanzkriterien - Was braucht das Entwicklerteam um zu wissen, dass das Feature implementiert wurde\nReadyness - Die User Storys sollten ready sein, dh. alles enthalten, was zur Entwicklung gebraucht wird - Layouts, externe Systeme etc \nErwartete Wirkung auf Business-Metriken ist definiert, inkl. Low Water Mark, bei der das Feature nicht global ausgerollt wird.\n\n
In Folge werden die User Stories aber nicht unmittelbar in das Development geworfen, sondern zunächst gemeinsam mit dem Development bewertet, Abhängigkeiten und Kosten - und damit ist nicht nur Zeit und Geld, sondern zB auch Technical Debt gemeint - evaluiert. \nHier entstehen auch die Akzeptanzkriterien, und es wird ebenfalls eine Erwartungshaltung bezüglich der Nutzung des neuen Features definiert - und auch dessen untere Grenze definiert, um auch an dieser Stelle die Entstehung von Waste zu vermeiden.\n
Die Tasks mit der höchsten Bewertung werden dann direkt in die Entwicklung gegeben, und durchlaufen da den gleichen Prozess, wie sie es heute etwa schon in agilen Scrum-Environments tun. Für die Anwesenden aus der Software-Entwicklung: da es keine Releases mehr gibt, und die Features dann ausgerollt werden, wenn sie fertig sind, kann hier nicht mit Release-Versionen etc gearbeitet werden. An die Stelle treten Feature-Flags in der Software selbst. Es sind immer alle Features in der Software enthalten, sie werden jedoch nur teilweise - zum Teil auch nur pro Nutzergruppe - in Staging oder Produktion aktiviert. Ganz agil ist das Feature erst dann fertig, wenn die Definition of Done erfüllt ist, wenn also Code, Tests und Akzeptanztests der gesamten Applikation im grünen Bereich sind. Sobald ein Mininum Marketable Feature Set für eine Epic implementiert ist, wandert es in die nächste Kanban-Spalte.\n
Hier wird mit deutlich anderen Grenzen gearbeitet als wir es normalerweise gewohnt sind. Wahlweise auf einem klassische Staging - oder auch als pro Nutzer aktivierte Featureflag in Produktion - werden die Features aktiviert. Dann wandern sie in den internen Review - etwa durch das Product Management - in den internen Usability Test - weil an dieser Stelle auch viele gute Features zu den 45% ungenutzter Features werden - oder auch, und das ist wieder speziell für Lean Startup, in den externen, aber preiswerten Usability Test mit gekauften Testnutzern aus dem Internet. Bei enger Zusammenarbeit mit den Kunden wird das Feature direkt in den Customer Review gegeben. \n
Normalerweise würde man erwarten, dass das Feature damit schon fertig wäre, in Produktion zu gehen- aber auch das ist in der Lean Startup Welt anders, denn, ich erinnere daran, man weiss um die bescheidenen 36% Features, die man tatsächlich haben möchte. Also wird es nicht für die ganze Nutzerbasis freigeschaltet, sondern nur, in einem Facebook-Beispiel „Für 1 Prozent von Nebraska, dh. 100.000 Nutzer“. für diese Nutzer wird im Rahmen von A/B-Testing im Business-Monitoring gemessen, ob die erwartete Änderung der Geschäftsmetriken tatsächlich eintrifft, nicht erreicht wird oder sogar übertroffen wird. Nur wenn hier der erhoffte Mehr wert tatsächlich eintrifft, wird das Feature ausgerollt. Das kann nur funktionieren, wenn man einen automatischen Rollout/ Rollback hat - hier kommen die Devops-Tools ins Spiel - und Features über Feature-Flags bequem deaktivieren kann.\n
Wenn ein Feature die Erwartungen trifft oder übertrifft, wird es für alle Nutzer ausgerollt. Damit hört das Business Monitoring aus der Applikation aber nicht auf - es wird weitergesammelt, und geprüft, ob aus dem Nutzerverhalten eventuell verbesserungen oder neue Features entstehen. Es werden in Produktion aber nicht nur neue Features gemonitored, sondern auch die alten. Und wenn ein altes Feature nicht mehr oder nur noch wenig genutzt wird, dann wird es auch bereitwillig verworfen, um einen nicht zu grossen Beitrag zu den 45% Waste zu liefern. (Das ganze ist, wie viele vermutlich schon bemerkt haben, durchaus von der Idee des Muda aus KaiZen beeinflusst)\n
\n
Und genau das haben die Kollegen beim Kunden gelernt - faktisch konnte man nicht wirklich vorhersagen, was funktionieren und was nicht funktionieren würde. Also brauchte es eine Infrastruktur, mit der man feststellen konnte was funktioniert und was nicht funktioniert, und das möglichst billig.\n