geplant und geführt werden?

Größe: px

Ab Seite anzeigen:

Download "geplant und geführt werden?"

Walter Färber
vor 8 Jahren
Abrufe

1 Orbit-iEX 2008 Konferenz Können Software-Innovationsprojekte gefördert, geplant und geführt werden? Marcello Leonardi, Senior Project Manager Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich 1

2 Agenda

3 Agenda» Zielsetzungen für erfolgreiche Produktinnovationen» Agile Management Methoden Lean Project Management» Planung und Kontrolle» Offene Diskussion 3

4 Zi l t fü f l i h Zielsetzungen für erfolgreiche Produktinnovationen

5 Einige Fakten Fakten für den Start» CHAOS-Studie der Standish Group sagt aus, dass 84% der IT- Projekte teilweise erfolgreich oder nicht erfolgreich sind Quelle: Wujec and Muscat

6 Einige Fakten Fakten für den Start Value Expected Target Value for Business Minimal Accepted Value Version 1.0 (Traditional Waterfall Project) Time 6

7 Zielsetzungen für erfolgreiche Produktinnovationen Vision klären Planung erstellen Requirements erheben Requirements Requirements spezifizieren modellieren Realistische Benutzungsszenarien Kontext beachten Klare Zielgruppe vor Augen Simulation Benutzungserlebnis anhand konzeptioneller Prototpyen Konsequent Feedback einbauen Leicht änderbare Prototypen Requirements evaluieren Requirements visualisieren 7

Klare Zielgruppe vor Augen Simulation Benutzungserlebnis anhand konzeptioneller Prototpyen Konsequent

8 Zielsetzungen für erfolgreiche Produktinnovationen» Kontinuierliche Innovation» Anpassungsfähige Produkte» Anpassungsfähige Personen und Prozesse» Verlässliche Resultate Messgrössen Qualität Umfang Kosten Zeit 8

Anpassungsfähige Personen und Prozesse» Verlässliche

9 A il M t M th d Agile Management Methoden Lean Project Management

10 Agile Software-Entwicklung Das agile Manifest Menschen und Interaktion Prozesse und Werkzeuge Funktionierende Software Ausführliche Dokumentation Zusammenarbeit mit dem Kunden Vertragsverhandlungen Auf Änderungen reagieren Einen Plan befolgen 10

Ausführliche Dokumentation Zusammenarbeit mit dem Kunden

11 Agile Methodologien» Scrum Start Here Lean Management Methode» XP (extreme Programming) Engineering Practices Communication, Simplicity, Feedback Werte: Mut, Respekt» Weitere Methoden & Frameworks ADS Crystal DSDM FDD (RUP). Quelle: conchango.comcom 12

Simplicity, Feedback Werte: Mut, Respekt» Weitere Methoden &

12 Scrum Container & Rollen 13

13 Was ist Scrum? Improve Plan Do Review 14

14 Scrum in Innovationensprojekten Envision Feature List Release Plan Speculate Adaptive Action Release Plan Scrum Adapt Explore Completed Features Close 15

15 Agiler Projektansatz t (Zusammenfassung)» Ein Team» Kurze Iterationen» Nach jeder Iteration wird etwas geliefert» Feedback fliesst in nächste Iteration und Planung ein» Fokussierung auf Business Ziele (Value) 16

geliefert» Feedback fliesst in nächste Iteration und

16 Agiler Projektansatz Value Added Value asked from Business Expected Target Value for Business Minimal Accepted Value Version 1.0 (Agile Project) Version 1.0 (Traditional Waterfall Project) Time 17

Accepted Value Version 1.0 (Agile Project) Version 1.

17 Planung und Kontrolle

18 Try Another Way 19

19 Unterschiedliche Ebenen der Planung Strategy Portfolio Produkt Release Iteration Tag 20

20 Wieso plant man überhaupt?» Risiken zu reduzieren» Ungewissheit zu reduzieren» Entscheidungen zu unterstützen» Vertrauen aufzubauen» Informationen zu übermitteln Was macht die Planung agil?» Fokussierung auf die Planung, anstatt auf den Plan» Bereitschaft zur Änderung» Pläne sind einfach zu ändern» Planung ist im gesamten Projekt verbreitet 21

Vertrauen aufzubauen» Informationen zu übermitteln Was macht die Planung agil?

21 Von der Grösse zur Dauer Features Grösse Dauer Planung Geschwindigkeit (Velocity)» Anzahl Story Points / Idealer Tagen welche in einer Iteration erledigt werden Dauer = Grösse / Geschwindigkeit 22

22 Pi Priorisierung i i von Themen (Szenarien)» Finanzieller Wert der Funktionalitäten eines Themas» Entwicklungskosten (und Betriebskosten)» Die Menge und Bedeutsamkeit von Wissensaufbau» Risiko Eliminierung Hoch Risiko Gering Hohes Risiko Geringer Wert Geringes Risiko Geringer Wert Hohes Risiko Hoher Wert Geringes Risiko Hoher Wert Hoch Risiko Gering Vermeiden Prio 1 Prio 3 Prio 2 Gering Wert Hoch Gering Wert Hoch 23

23 R l Release und d It Iteration ti Pl Planung Release Bestimmen Bedingungen der Zufriedenheit (User Stories, Budget Zeit) Feedback Release Planung Iteration Bestimmen Bedingungen der Zufriedenheit (User Stories, Abnahme Test) Iteration Planung 26 Feedback Entwicklung Produkt Inkrement

24 Projekt Fortschrittskontrolle Story Points Sprint = Velocity Points Remaining Velocity = Sprints Remaining 27

25 Zusammenfassung» Qualitätsstandard vereinbaren Definition of Done» Umfang definieren Beschrieben durch User Stories Gemessen in Story Points» Zeit und Aufwand berechnen Story Points / geschätzte Geschwindigkeit = Sprints = Aufwand» Fortschritt kontrollieren Story Points / aktuelle Geschwindigkeit = Geschätzte Ankunftszeit (ETA) 28

26 Ihre Fragen, unsere Antworten? Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich 29

27 Besten Dank für Ihre Aufmerksamkeit! Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich 30

28 Anhang I: Eckdaten zu namics 31

29 Ekdt Eckdaten zu namics.» Marktführender Schweizer Berater für Internet-Anwendungen und E-Business, starke Präsenz in Deutschland» Fokus Strategieberatung für Internet Konzeption und Implementierung nutzergerechter, effizienter und begeisternder Internet-Anwendungen Vermarktung und Lancierung von Online Aktivitäten werblich orientierte Markenkommunikation» Zahlen und Fakten gegründet 1995 als Spinoff der Universität St. Gallen 240 Mitarbeiter, Umsatz 2007 CHF 34,2 Mio. Standorte: Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich PubliGroupe SA, Minderheit beim Management (15 Partner) 32

30 Eine Auswahl unserer Kunden 33

31 Alle namics Referate auf eine Blick» Top 10 Internet-Standards der Zukunft» Flash vs. Silverlight: Das grosse Duell» Können Software-Innovationsprojekte gefördert, geplant und geführt werden?» CMS-Shoot-out: Content-Management-Systeme im Vergleich» Internet für alle Virtuelle Grenzen überwinden» Web Analytics in der Praxis» Effiziente Rezepte für die Online-Kundengewinnung» CMS-Migration Best Practices» Enterprise Search: Google vs. Microsoft» Weblogs und Wikis im Firmeneinsatz» TV 2.0 im Business-Einsatz» Die Handouts stehen als Download zur Verfügung:

32 Besuchen Sie uns» Besuchen Sie uns auf dem namics Stand in der Halle 4/A

33 Anhang II: Zusätzliche Informationen 36

34 Wieso scheitern Projekte?» Scheitern im Markt Falsches Produkt wurde gebaut Produkt wurde zu spät ausgeliefert -> Konkurrent war schneller» Kunde ist unzufrieden Zeit (ok) + Price (ok) + Umfang (ok) = zufriedener Kunde?» Ziele nicht erreicht Vision wird nicht erfüllt Hauptziele wurden nicht erfüllt Gab es überhaupt eine Vision oder Ziele zu Beginn? Sind die zu Beginn festgehaltenen Ziele überhaupt noch aktuell/relevant? 37

35 Wieso scheitern Projekte?» Team» Management Personen und Gruppen Dynamics Planung ist nicht mit der Ausführung integriert Rivalitäten Skills, Motivation, usw.» Kunde Weiss nicht was er will Ändert ständig seine Meinung Mikromanagement des Budget Nicht genug Zeit Umfang und Abnahme Kriterien sind nicht genügend definiert Zielkonflikte zwischen Sponsoren Keine oder mangelnde Managmentunterstützung Unrealistische Erwartungen Zu wenig Planung Keine Fortschrittskontrolle Langsame Entscheidungsfindung d» All Kummunikation -> Was wird wirklich benötigt/gewünscht? Ungenügende Lernprozesse -> Keine Veränderung» Die Liste geht hier weiter. 38

36 Leitende Prinzipien agiler Softwareprojekte Deliver Custmer Value Ch i Champion Technical Excellence Employ Iterative Feature Delivery Product Delivery y Ladership-Collaboration Build Adaptive Teams Simplify p y Encourage E l Exploration ti 39

37 Envision i Practices Product Vision Box and Elevator Test Vision Product Architecture Scope Project Data Sheet Envision Get the Right People Community Participant Indentification Customer Team Developer Team Interface Approach Process/Practice Tailoring 40

38 Speculate Practices Product Feature List Feature Breakdown Structure Feature Card Speculate Performance Requirements Iterative Plan Iteration 0 Release, Milestone, Iteration Plan Project Risk Analysis Next Iteration Plan 41

39 Practices Explore Deliver on Objectives Workload Management Technical Practices Low-Cost Change Explore Coaching and Team Development Project Community Daily Team Integration Meetings Participatory Decision Making Daily Interaction with Customer 42

40 Adapt and Close Practices Adapt Review Product Review Project Review Team Review Close 43

41 Wie werden Features wahrgenommen? Kunden zufrieden Bezaubert & begeistert Linear je mehr, desto besser nicht implementiert voll implementiert Voraussetzungen Quelle: Kano-Modell Kunden unzufrieden 44

42 Wie gewährleisten wir Qualität?» Was soll heissen Ich bin» weitere mögliche Faktoren: fertig?» Ein Beispiel : getestet (UnitTests und Acceptance Tests ausgeführt) deployed auf Abnahmetestumgebung dokumentiert (JavaDoc) eingecheckt im Subversion erfolgreicher Build erfolgreicher CheckStyle durchgeführter CodeReview Code Refactored 99% automatisch getestet W3C-konformes HTML 45

Ähnliche Dokumente

Internet Briefing Agile SW-Entwicklung

1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com