10-mal heruntergeladen
Hochgeladen vonJohann-Peter Hartmann
Php und das lean startup
Das Dokument behandelt die Herausforderungen und Strategien im Softwareentwicklungsprozess, insbesondere im Kontext von PHP und Lean Startup. Es diskutiert die Bedeutung eines minimum viable product (MVP), kontinuierlicher Kundeninteraktion und agiler Entwicklung, um schnelle und kosteneffiziente Verbesserungen zu ermöglichen. Zudem werden Erkenntnisse über häufige Fehler in Projekten und die Notwendigkeit von Nutzerfeedback hervorgehoben.
Weitere ähnliche Inhalte
Php und das lean startup
- 1. PHP & LEANSTARTUP
- 2.
- 5. All the PHPcode 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/
- 8. OPA ERZÄHLT VOMKRIEG ...
- 10. Der Pitch istin drei Tagen ... Hmmm .... 3 Tage ... da können wir es ja gleich ganz implementieren ...
- 12. Ich rufe nuran, 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 einPortal mit Einbindung der Stellenbörse, wie lange braucht Ihr?
- 14. Wir brauchen einPortal mit Einbindung der Stellenbörse, wie lange braucht Ihr? Bis 18:00 sind wir fertig
- 15. Wir brauchen einPortal 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 einPortal mit Einbindung der Stellenbörse, wie lange braucht Ihr? Bis 18:00 sind wir fertig Ich brauche es aber bis 16:00 Ok, Captain
- 18.
- 19. Enterprise ContentManagement Multichannel SelfService CRM Solution!
- 20. Unternehmensberatung: 500.000 € Softwarelizenz: 100.000 € Customization: 1.000.000 € Einrichtung: 500.000 €
- 21. Unternehmensberatung: 500.000 € Softwarelizenz: 100.000 € Customization: 1.000.000 € Einrichtung: 500.000 € 2.100.000 €
- 22. Initialer Vorschlag: 2 Monate Konzept: 6 Monate Durchführung: 12 Monate Einarbeitung/Workshops: 2 Monate
- 23. Initialer Vorschlag: 2 Monate Konzept: 6 Monate Durchführung: 12 Monate Einarbeitung/Workshops: 2 Monate 24 Monate
- 24.
- 25. Pageviews/Tag: 1000 davon Suchmaschine: 950 Aktive Nutzer/Tag: 20 davon intern: 15
- 26. Pageviews/Tag: 1000 davon Suchmaschine: 950 Aktive Nutzer/Tag: 20 davon intern: 15 Ooops.
- 27.
- 28. Successfull Challenged Failed Projekte 24% 32% 44%
- 29. Never Used Rarely Sometimes Always Often Features Often 13% Always 7% Never Used Sometimes 45% 16% Rarely 19%
- 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.
- 36. Fail early andfail cheap - you just can‘t do that in C.
- 37. I believe thebest way to convince Zuck that something is a bad idea is to build it and let him use it. Facebook, Working with Zuck
- 38.
- 42. Low Burndown byDesign not Crisis
- 43. Customer Development Agile ProductDevelopment
- 46. • Kontinuierliche Kundeninteraktion: • Schnelle Prüfung von Märkten, Kundengruppen,Pricing • Minimierung der Kosten für diese Prüfungen • Mess- und nachweisbare Fortschritte
- 47.
- 48. MINIMUM MARKETABLE FEATURESET
- 49.
- 50. Minimum Viable Product Idea Creation Customer Feature Analysis Collect Feedback Implement & Data Feature Test Different Pivot Feature Base Product
- 51. Initial MVP Feature 1 Feature 2 Feature 3 Registration 5 % 17 % 17 % 17 % Aktivierung 17 % 90 % 90 % 90 % Wiederkehrer Zu niedrig 5 % 8 % 10 % Weiterempfehlu Zu niedrig 4 % 6 % 6 % ng
- 52. Kanban Rollout 1 Review & Interal & A/B- Customer Theme Feature Develop- Rollout / Story External Testing, Analysis Definition Definition ment Rollback Points Testing Business Monitoring Schnelle Geschäfte I Mayflower GmbH I 2011 I
- 54.
- 55. • Feature Durchlaufzeit •Feature Definition Cycle Time
- 56. • Feature Durchlaufzeit •Feature Definition Cycle Time • Feature Implementation Cycle Time
- 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
- 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
- 71. If we knewwhat it was we were doing, it would not be called research, would it?
Hinweis der Redaktion
- #2 \n
- #3 Ich sehe unter den Zuhörern einige Namen, die schon eine Weile in der PHP-Welt zugange sind. Hallo alte Leute!\n
- #4 Damals brauchten wir noch kein Ajax, und wie man sieht war Design auch eher zweitrangig.\n
- #5 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
- #6 Dementsprechend haben wir von jeder Seite viel Respekt bekommen.\n
- #7 Und uns unseren festen Platz in der IT-Welt geschaffen.\n
- #8 \n
- #9 Im Jahr 2000 hatten wir inzwischen thinkPHP gegründet, und wollten damit PHP mehr in das Unternehmensumfeld bringen.\n
- #10 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
- #11 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
- #12 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
- #13 Aber die Irritation blieb erhalten. Ein paar Verhaltensmuster waren auf einmal anders, wenn man mit PHP zu tun hatte.\n
- #14 Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
- #15 Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
- #16 Die Life-Instanz wurde direkt aus dem CVS bedient, und jeder Bugfix war ein CVS comit und ein CVS up.\n
- #17 Unsere Kunden waren ziemlich begeistert davon, einen persönlichen Scotty zu haben. Das hatte einen Grund. Sie waren es nämlich anders gewohnt. \n
- #18 Aber warum fanden die Unternehmen das so super? Weil sie vorher anders gearbeitet haben, und auch das hatte mit Enterprise zu tun.\n
- #19 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
- #20 Nur dass hier die Kosten ein wenig höher lagen ... \n
- #21 ... und die Umsetzungsgeschwindigkeit geringfügig höher war...\n
- #22 Dann gab es den Big Bang Release \n
- #23 ... und am Ende hat es niemand benutzt. \n
- #24 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
- #25 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
- #26 Werte von XP 2002, auch standish group\n
- #27 Aber zurück zu unserem anonymen Kunden ... \n
- #28 Das war die Information, die der anonyme Kunde aus München über PHP mitgenommen hatte.\n
- #29 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
- #30 ... und am Ende hat es niemand benutzt. \n
- #31 Aber warum funktionieren solche Dinge mit PHP?\n
- #32 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
- #33 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
- #34 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
- #35 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
- #36 Ebenfalls im Jahr 2004 wurde IMVU gegründet, eine Plattform für Avatare, die chatten können. \n
- #37 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
- #38 \n
- #39 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
- #40 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
- #41 Customer Discovery: Ideen sammeln\nCustomer validation: Sichern, dass sie wirklich funktionieren\nCustomer Creation: Implementieren der realen Strecke\nCompany Building: Skalieren\n
- #42 \n
- #43 Man beginnt mit dem kleinsten anzunehmenden Produkt - dem Mininum Viable Product. \nGeschichte von Zappos mit Schuster\nGeschichte von unseren Kunden\n
- #44 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
- #45 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
- #46 \n
- #47 \n
- #48 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
- #49 \n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 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
- #58 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
- #59 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
- #60 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
- #61 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
- #62 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
- #63 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
- #64 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
- #65 \n
- #66 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