@BjoernSchotte | bjoern.schotte@mayflower.de | 0931 / 35 96 5 - 15

Bessere Software schnellerliefern.

Webinar - 14. Mai 2013

MAYFLOWER

Leidenschaft fürerfolgreiche Softwareprojekte.

Zu Ihrem Nutzen.

Agilität im E-Commerce I Mayflower GmbH I Nov 19, 2012 I

Alte Welt der Software-Entwicklung

Langwieriges Pflichtenheftoder Visionsdokumente

Lange Entwicklungszeiten(viele Monate, Jahre)

Umständliche UmsetzungBusiness-Anforderungenin der Plattform

CHAOS REPORT 2011klassisch Wasserfall

14%

57%

29%

SuccessfulChallengedFailed

Quelle: Standish Group Chaos Report 2011

Kaum genutzte Funktionen in Software

Never Used45%

Rarely19%

Sometimes16%

Often13%

Always7%

Agilität im E-Commerce I Mayflower GmbH I Nov 19, 2012 I

Passt nicht mehr zur heutigen Zeit

Go Agileor Die

Agile Methoden (Scrum, XP) haben den Mainstream erreicht.

Agile Methoden erzeugen Herausforderungen auf Kunden- wie auf Dienstleisterseite.

Fragestellungen für Kunden

Lieber Kunde,kennen Sie Ihre Produkt-/Projektvision?

Lieber Kunde,haben Sie Vollzeit Zeit für das Projekt?

Lieber Kunde,haben Sie Zeit, sich mit Ihren internen Stakeholdern abzustimmen?

Lieber Kunde,wissen Sie, was Sie mit dem Projekt überhaupt erreichen wollen?

Lieber Kunde,konnten Sie schon erste Anforderungen definieren?

Lieber Kunde,was ist wichtiger?Budgettreue oder fixer Funktionsumfang oder Einhaltung des Zeitrahmens?

Fragestellungen fürDienstleister

Lieber Dienstleister,sind die Team Mitglieder dem Projekt Vollzeit zugeordnet?

Lieber Dienstleister,besteht das Team aus mehr als 1 bis 2 Personen?

Lieber Dienstleister,ist das Team cross-funktional aufgestellt?

Lieber Dienstleister,stellst du einen Product Owner (Assistant)?

Lieber Dienstleister,ist ein sauberer Vertrag aufgesetzt, der agiles Arbeiten ermöglicht und fördert?

Lieber Dienstleister,wurde der Vertrag mit dem Kunden durchgesprochen und beidseitig verstanden?

Lieber Dienstleister,wie ermöglichst du Gewerke in deinem Projekt?Macht das überhaupt Sinn?

Vertrauen zwischenKunde & Dienstleister.

Best Practices Softwareprojekt

Konzeption

Wir erinnern uns:

Lieber Kunde,kennen Sie Ihre Produkt-/Projektvision?

Für Hobby-Handwerkerdie in Eigenregie ihr Haus modernisierenist EsIstDeinProjekt.de ein Online-Shopder den einfachen Einkauf von Handwerksmaterialien ermöglicht.Anders als OBI/HORNBACH/PRAKTIKERbietet unser Online-Shop- den bequemen Einkauf per Tablet- die Online-Konfiguration von Fenstern- die größte Auswahl an Bohrern- eine 100 Tage Geld-zurück-Garantie

Personas.Beschreiben Sie Ihre Nutzergruppen. So ausführlich wie nötig. So schlank wie möglich.

Name + Bild.Was sind die für das Projekt relevanten Charakteristiken der Persona? Zum Beispiel Job, Alter, Position bei sich im Unternehmen.Bedarf. Welchen Bedarf stillt diese Person auf Ihrer Fachanwendung?

http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-management/

Product Canvas.Ähnlich Business Canvas. Beschreibt auf einen Blick die wichtigsten Personas, Customer Journeys, EPICs, Constraints (zB Performance der Anwendung) und Ready Stories.

http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-management/ (Product Canvas (C) by Roman Pichler, licensed CC-BY-SA)

Definition von Anforderungen

Keine große Einmalplanung.

Grobe Einmalplanung & kontinuierliche Planung im Projekt

(Einmal)planung:Themen, Epics, Stories

Händler-Backend Produktverwaltung Produkt anlegen

Produkt ändern

Produkt löschen

Produkte importieren

Produkttext übersetzen

Fakturierung Meinen Umsatz anzeigen

Profildaten Mein Logo anlegen

Mein Logo ändern

Meine Adresse anlegen

Meine Adresse löschen

Thema EPIC Stories

- Produktname, Kategorie, Preis und Text können gepflegt werden- das Produkt kann aktiviert und deaktiviert werden- ein deaktiviertes Produkt ist im Shop-Frontend nicht sichtbar

Nutzergeschichte:

Akzeptanzkriterien:

Als Händler möchte ich ein Produkt anlegen, um es im Shop EsIstDeinProjekt anzeigbar zu

machen

Der Dienstleister unterstützt beim Schreiben der Nutzergeschichten.

ProjektvergabeGeschichten aus dem

Projektalltag

„Tragen Sie mal in das Excel-Dokument die Aufwände der einzelnen Positionen ein.“

(Lies: „Ich will die Einzelaufwände vergleichen und suche mir den Dienstleister mit dem günstigsten Preis. Ich habe noch nicht verstanden, worauf es eigentlich ankommt.“)

„Wir behalten uns vor, einzelne Bestandteile an andere Auftragnehmer zu vergeben.“

(Lies: „Wir glauben, dadurch Risikostreuung zu betreiben. Wir sind uns nicht bewusst, dass das die Komplexität im Projekt erhöht, Vertrauen minimiert und häufig nicht funktioniert.“)

„Jetzt sagen Sie doch: was kostet‘s und garantieren Sie, dass es bis zum <UTOPIEDATUM> fertig wird?“

(Lies: „Wir haben mit dem 3-seitigen Konzeptdokument ein halbes Jahr lang verdaddelt. Der Dienstleister soll es bitteschön bis zum Messetermin in vier Wochen richten. Der, der das Konzept begonnen hatte, ist übrigens nicht mehr bei uns beschäftigt.“)

„Wir wollen unbedingt Gewährleistung auf das Projekt. Das muss definitiv sein.“

(Lies: „Wir haben zwar nicht definiert was wir wollen, und daher gehen wir [scheinbar] auf Nummer sicher und wälzen das Risiko komplett auf dich ab. Wir haben noch nicht verstanden, dass es doch darum geht, möglichst schnell Nutzen zum kleinen Preis zu realisieren. Und dass Software per se nie fehlerfrei sein kann.“)

Tipps für die Projektvergabe

Folgen Sie Ihrem Herzen. Wählen Sie einen Dienstleister besonders nach diesen Kriterien.

Kompetenz. Vertrauen. Der Sie führt & geleitet. Der sagt, was nicht passt. Die Zeitlinie möglicherweise nicht zu halten ist. Darauf achtet, wichtige & Funktionen, die Nutzen stiften, zuerst zu implementieren. Sie und Ihre Kunden im Blick hat. Auch mal NEIN sagt. Den Sie als Partner betrachten. Der Sie auf Augenhöhe betrachtet.

Gemeinsam. Erfolgreich.

Anforderungsworkshop mit einem Dienstleister.Definition erster EPICs & Stories.Ergebnis: erste Annäherung an das WAS.

Descoping von: unwichtigen Funktionen, Anforderungen die jetzt noch nicht wichtig sind. Ganz unten rein ins Backlog.Priorisierung der Anforderungen. Definition eines „Walking Skeleton“ für einen Überblick, der schärft.Ergebnis: Reihenfolge der wichtig(st)en Anforderungen. Klarheit für den Projektstart.

Aufwandsschätzung eines Beispiel-EPICs mit seinen User Stories. Näherungsweise Extrapolation auf die anderen, noch nicht definierten EPICs.Ergebnis: Korridor für mögliche Aufwände und damit auch ein Budgethorizont.

Vertragsgestaltung

Disclaimer:I Am Not A Lawyer.Dies ist keine Rechtsberatung.

Dienstleistungsvertragvs

Werkvertragvs

Agil mit Festpreis

Ist ein Dienstleistungsvertrag in solchen Projekten überhaupt sinnig?

Ja. Wenn die Kosten nach oben gedeckelt sind (Projektdauer x Teamkapazität x Teamkosten/Sprint). Natürlich sind dann die Features variabel.

Projekt“kontrolle“? Sprint-Rhythmus. Scope-Änderung nach jedem Sprint möglich. Nutzwertgenerierung.Und: Projektabbruch möglich. Wie? Das zeige ich später.

Ist ein Werkvertrag in solchen Projekten überhaupt möglich?

Ja. Das Gewerk ist nicht das Gesamtprojekt, denn das kennen Kunde & Dienstleister zu Projektbeginn nicht vollständig.

Ein Gewerk kann vielmehr eine einzelne User Story sein. Auf dieser Basis ist dann eine Realisierung nach Werkvertrag, zB agil mit Festpreis, möglich.

Tipps für die Vertragsverhandlung:

Anwalt involvieren. Vertragsgrundlagen auf Basis gegenseitigen Vertrauens schaffen. Den Vertrag so einfach wie möglich, so kompliziert wie nötig gestalten.

Herausforderung: Entkopplung von Legal und Einkauf-Abteilungen zur operativen Ebene und damit Verständnis über die Projektziele. Alle an einen Tisch bringen.

Projektverlauf

Sprint: regelmäßiger Rhythmus.Jede 14 Tage Planung. Jede 14 Tage Review. Was haben wir geschafft? Wo gab es Schwierigkeiten? Was muss in den nächsten Sprint noch mal rein?Ziel: Nutzen generieren. Fehleranfälligkeit durch kurze Rhythmen minimieren. Möglichkeiten zur Kursänderung schaffen. Einen weiteren Teil des Großen Ganzen fertig stellen.

Kostenkontrolle: weg von der Frage „Was kostet mich das Gesamte?“ (kann vorher nicht exakt beziffert werden)Hin zu: „wieviel vom Gesamtbudget habe ich noch und was könnte ich mit diesem Rest noch an Funktionen erreichen?“Herausforderung: zu Beginn dieses Projekts ist die Frage schwer zu beantworten. Nach jedem Sprint schärft sich jedoch der Blick.Wichtig: Stakeholder und Projekt-Sponsoren kontinuierlich über den Verlauf des Projekts informieren.

Abbruchszenarien. Sie brechen das Projekt nicht aus Mangel an Vertrauen ab. Sie brechen das Projekt gemeinsam dann ab, wenn genügend Business Value geliefert wurde.

Beispielprojekt:Projektvolumen nach erster Schätzung 600kEUR.Ein Sprint von 14 Tagen Dauer kostet etwa 30kEUR.

Variante 1: fixer Werkvertrag & Upfront Design.Dienstleister wird auf Erfüllung und Realisierung der 600kEUR bestehen, obwohl nach 10 Sprints (=300kEUR) schon alles realisiert wurde, was Ihnen Nutzen bringt. Denn während der Projektlaufzeit haben sich Anforderungen, die ursprünglich geplant gewesen sind, als nicht mehr sinnvoll erwiesen.

Die verbleibenden 300kEUR müssen in Funktionen realisiert werden, die nicht viel weiteren Nutzen für Sie und Ihr Business bringen.Weiteres Geld muss über Change Requests investiert werden, um den veränderten Anforderungen des Business gerecht zu werden.

Gesamtkosten steigen erheblich, der Gesamtnutzen sinkt.

Variante 2:Nach 9 Sprints (=270kEUR) beendet man das Projekt mit einem Sprint (=30kEUR) Vorlauf. Weil alles realisiert wurde, was Nutzen bringt. Gesamtkosten 300kEUR statt geplanter 600kEUR.

Variante 3:Nach 10 Sprints (=300kEUR) stellt man fest, dass das Business noch weitere Anforderungen hat. Diese werden nach Nutz-Wert priorisiert und noch 3 weitere Sprints (=90kEUR) nachgeschoben. Danach wird das Projekt beendet, da alle wichtigen Anforderungen erfüllt sind. Gesamtkosten: 390kEUR. Der Gesamtnutzen ist deutlich höher, weil viel effektiver darauf geachtet wurde, Nutzen zu generieren.

Der Wert ist bei kleinerer Geldmenge deutlich höher als das, was durch komplettes Upfront-Design realisiert werden konnte. Auch, weil sich die Anforderungen Ihres Marktes während der Projektlaufzeit verändert haben und nur das realisiert wurde, was wichtig ist.

Wie können Sie weiteren zusätzlichen Nutzen im Projekt generieren?

Kaum genutzte Funktionen in Software

Never Used45%

Rarely19%

Sometimes16%

Often13%

Always7%

Releasen Sie neue Versionen frühzeitig.Messen Sie direkt in der Software, wie Ihre Kunden die Software nutzen.Ziel: möglichst günstig & schnell neue Funktionen releasen, Akzeptanz messen und Verhalten validieren. Funktionen, die keinen Wert für Sie & Ihre Kunden bringen, wieder wegwerfen.Ergebnis: auf Nutzwert fokussierte Funktionen in der Software. Hebelwirkung durch massive Wertsteigerung. Damit zufriedenere Kunden - und letztlich mehr Revenue für Sie.

Zusammenfassung&

wie geht es weiter?

Und jetzt?

Fragen & Antworten.