Jean-Pierre König. Senior Software Engineer.

Transkript

1 ScrumBreakfast Live - Rapid Development. Eine lauffähige Applikation in nur 3 Tagen. Jean-Pierre König. Senior Software Engineer. 07. Oktober 2009

2 Scrum Breakfast. Agenda. Namics & Adhoco vorgestellt Ausgangslage Rapid Development

3 Namics vorgestellt

4 Namics vorgestellt. Zahlen und Fakten gegründet 280 Mitarbeiter 39.2 Mio. CHF Umsatz 2008 Frankfurt Hamburg München St.Gallen Zürich Zug

5 Namics vorgestellt. Kompetenzen. Webdienstleister für hochwertige, professionelle E-Business Dienstleistungen Commerce & Conversion Intranet & Collaboration Online Strategie Web Content Management Social Applications Online Marketing Markenkommunikation

6 Namics vorgestellt. Interdisziplinäre Teams. Technologie Projekt Management Consulting Kreation

7 Person vorgestellt. Jean-Pierre König. Seit 2004 bei Namics Senior Software Engineer Certified ScrumMaster Verantwortlich für agile Software Entwicklung am Standort Zürich. Leidenschaft. Dynamik. Open Source. Gadgets. Mac. Blog. Agil. Vertrauen. Vollgas. Ruby. Menschen

8 Adhoco vorgestellt

9 Adhoco vorgestellt. Zahlen und Fakten. Start Up 2003 gegründet 15 Mitarbeiter 1/4 Mio. CHF Umsatz Installationen Winterthur

10 Adhoco vorgestellt. Produkte. Hersteller von Automationssystemen Steuerung für Haustechnik im Wohnumfeld Automatisierte Funktionen selbstlernend nach den Bedürfnissen der Bewohner System bestehend aus verschiedene Komponenten Kabellose kommunizieren der Komponenten Einfache Installation Für die Nachrüstung geeignet Dank Internet ist Fernzugriff und Alarmierung möglich

11 Ausgangslage

12 Ausgangslage. Die Ausgangslage. Wir haben eine tolle Idee mehr nicht. Wir haben ein fixes Budget. Wir wollen Software, die funktioniert. Wir haben keine fixen technologischen Rahmenbedingungen. Wir wollen in 3 Tagen live sein. Wir wollen eine enge und intensive Zusammenarbeit mit einem schlagkräftigen Team

13 Rapid Development

14 Rapid Development. Mit Rapid Development schnell zum Erfolg. Wir haben eine tolle Idee mehr nicht. Wir haben ein fixes Budget. Wir wollen Software, die funktioniert. Wir haben keine fixen technologischen Rahmenbedingungen. Wir wollen in 3 Tagen live sein. Wir wollen eine enge und intensive Zusammenarbeit mit einem schlagkräftigen Team

15 Rapid Development. Fünf Fragen, die beantworten werden sollen. 1 Wie kommt man von einer Idee zur Vision? 3 Wie stellt man den ersten Release zusammen 4 Wie geht man bei der Umsetzung vor? 5 Wie geht man erfolgreich live? 2 Wie sammelt man benutzerorientierte Anforderungen?

16 Wie kommt man von der Idee zur Vision

17 Fallbeispiel. Adhoco, eine Idee und die Messe. CEO Adhoco AG Lernen sich im Zug kennen CTO Namics AG Thomas Schuhmann Marcel Albertin Thomas erzählt von Marcel seinem Unternehmen, den Produkten, dem Erfolg Marcel, ein Fan sämtlicher Gadgets, ist interessiert und hackt nach: Wie funktioniert das über das Internet? Thomas erläutert. Marcel fragt: Kann ich das über s Natel steuern? Noch nicht, aber

18 Fallbeispiel. Adhoco, eine Idee und die Messe. Thomas erzählt von der Vision Man könne alles vom Natel steuern. Begeistert schildert er, wie man sich das vorstellen muss Thomas meint, er wüsste nicht genau, wie man eine Mobile Applikation baut, wie mein ein einfaches User Inteface baut, wie man die Usability berücksichtigt, wie man vorgeht, was das kosten kann Marcel schlägt vor: Lass uns doch ein unverbindliches Meeting organisieren

19 Fallbeispiel. Adhoco, eine Idee und die Messe. Namics trifft Adoco Adhoco erläutert die Produkte und ihre Idee Gemeinsam schärfen wir die Vision Mit einer mobilen Anwendung soll man schnell, einfach und spielerisch Funktionen im Haus steuern können. Namics stellt Rapid Development vor Namics offeriert. Es kommt zum Auftrag Marcel Albertin CTO Namics AG Consultant Namics AG David Nydegger Engineer Namics AG Jean-Pierre König

20 Rapid Development. Von der Idee zur Vision. Am Anfang vieler Webprojekte steht eine einfache Idee. Wichtig ist es, diese Idee zu schärfen. Dazu dient die Vision. Eine Vision soll kurz, sinnstiftend und ambitioniert sein. Und warum machen wir das? Eine klare Vision zu Beginn hilft dabei, spätere Entscheidungen über die Software einfacher fällen zu können!

21 Wie sammelt man benutzerorientierte Anforderungen. Tag

22 Fallbeispiel. Tag 1. Warm up. Kurze persönliche Vorstellung, 5 min Adhoco & Produkt Vorstellung, 15 min Die erste Aufgabe fürs Team: Wir gehen an den Hauptbahnhof Zürich und machen ein Interview mit potenziellen Nutzern der Mobile Applikation. 20 min, 2-er Teams, eine Frage: Wenn Sie eine Funktion bei Ihnen zu Hause von ihrem Natel aus steuern könnten, welche wäre das? Los! Anschliessend: 30 min Erkenntnisse austauschen Vorgehensmodell vorstellen, 30 min Tagesziel festlegen, 15 min

23 Fallbeispiel. Tag 1. Benutzer Rollen und Personas definieren. Das Team definiert Benutzer Rollen und kreiert Personas, 1.5 h Der Product Owner bringt seine Perspektive ein Das Team arbeitet mit den Erkenntnissen des Interviews Kurt, 52 Verheiratet ETW Besitzer Kurt hat eine pflegebedürftig Mutter. Er würde gern die letzte Aktivität im Haus feststellen. Jakob, 35 Alleinstehend Mieter Jakob ist beruflich viel unterwegs. Er möchte gern über das Natel den Stromsparmodus aktivieren

24 Rapid Development. User Rollen definieren. User Rollen bestimmen die primären Nutzer der Software. Beschreibung orientiert sich an Aktivitäten. Existieren im Frontend und Backend einer Applikation. Lieber weniger als mehr User Rollen!

25 Rapid Development. Personas erstellen. Personas geben den User Rollen ein Gesicht. Reale Software für reale Menschen Ermöglichen eine nutzerzentrierte Sichtweise auf die Software

26 Fallbeispiel. Tag 1. User Stories entdecken. Aufgabe fürs Team: Jeder, 30 min: Schreibe je eine User Stories auf eine Karte so viel wie möglich, pro Persona. Alle User Stories aufs Backlog- Board heften, 1.5 h Jeder erläutert seine Stories 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! Kurt! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! Duplikate eliminieren und/oder zusammenfassen, splitten

27 Rapid Development. User Stories entdecken. Entdecken statt Sammeln Kreativer Prozess User Stories sind immer aus der Sicht der Persona geschrieben Masse geht (noch) über Klasse Testfälle für die Abnahme werden schon jetzt definiert

28 Wie stellt man den ersten Release zusammen. Tag

29 Fallbeispiel. Tag 1. Was ist wichtig. Estimation, 30 min Anzahl Story Points auf jede Karte Sprint Backlog zusammenstellen, 45 min Was ist in 3 Tagen machbar? Was unterstützt die Vision? Was will der Product Owner? Was wollen die Kunden? 2) Kurtkann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! Kurt! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! 2) Kurt kann! sich als! User registrieren.! Welche Stories sind riskant?

30 Rapid Development. Priorisieren von User Stories. Es gibt viele Möglichkeiten der Priorisierung. Welche Stories gefallen den Usern? Was stiftet Wert? Was ist riskant? Unterstützt eine Story die Vision? Ist eine Story jetzt schon relevant? Versteht man die Story überhaupt? Es gibt viele Möglichkeiten der Priorisierung. Wichtig ist, dass man ein Gefühl dafür bekommt, was wichtig ist

31 Fallbeispiel. Tag 1. Tag 1. Done. Prioriseren, 30 min Must be in: #8 PT s Should be in: #7 PT s Could be in: #17 PT s Rest vom Tag Entwicklungsumgebung aufbauen Haus aufbauen Scribbles, Wireframes Commitment

32 Fallbeispiel. Tag 1. Wireframing. Release Backlog Live in 3 Tagen? Reicht das Budget? Kriegen wir hin?

33 Rapid Development. Den ersten Release bestimmen. Aus den User Stories soll nun ein erstes Paket geschnürt werden. Rahmenbedingungen verstehen Auf die Priorisierung aufbauen Eher nein statt ja sagen Ergibt das überhaupt ein tolles Paket? Take whatever your product should be and cut it in half. (37signals)

34 Wie geht man bei der Umsetzung vor

35 Fallbeispiel. Vorgehensmodell. Agiles Arbeiten nach Prinzipien von Scrum & XP Morgens: Tagesziele definieren 2x täglich Stand-up Meeting, 5 min. um 11:00h, 16:00h 1x täglich Deployment Arbeitszeit: 9:00h 17:00h Ein Raum, für alle 3 Tage Infrastuktur wird von Namics gestellt, Adhoco bringt ein Haus mit Gemeinsames Mittagessen Keine Natels, kein Facebook, Twitter, Yammer,

36 Rapid Development. Auswahl eines passenden Vorgehensmodells. Kein plangetriebenes Projekt, wählen Sie ein agiles Vorgehen: Scrum Die 3 Tage in starre Slots unterteilen Klare Tagesziele definieren Kein Überstunden Interdisziplinäres Arbeiten Regelmässiges Zeigen, was man bereits hat Fokussiertes Arbeiten Höchste Flexibilität bei Änderungen Regelmässige Kommunikation

37 Fallbeispiel. Technologisiche Rahmenbedingungen. Web Applikation, keine iphone App Optimierung für iphone, ausschliesslich Javabasiert auf Basis von Spring Roo Keine Dokumentation, wenn doch - Wiki Keine (automatisierten) Tests Reliability ist weniger Wert als Funktionen Nur ein Deployment auf die Infrastruktur von Adhoco zählt am Ende

38 Rapid Development. Auswahl der geeigneten Technologie. Am besten geeignete Programmiersprache, Framework(s) und Tools Setzen Sie auf eine effiziente Technologie Neueste Technologien vs. vorhandenes Know How Kein Continuous Integration, z.b. Automatisierte Tests Minimieren Sie Infrastruktur und # Systeme Reliability und Coding Conventions spielen eine untergeordnete Rolle

39 Fallbeispiel. Das Team. Adhoco Dr. Thomas Schumann. Geschäftsführer von Adhoco. Rolle im Projekt: Product Owner. René Huber. Java Entwickler bei Adhoco. Rolle im Projekt: Teammitglied. MHDE (Adhoco Haus-Designagentur) Karin Streng. UI Designerin. Rolle im Projekt: Teammitglied. Namics Jean-Pierre König. Senior Software Engineer. Rolle im Projekt: Teammitglied. Daniel Schlegel. Software Engineer. Rolle im Projekt: Teammitglied. David Nydegger. Consultant. Rolle im Projekt: Scrum Master

40 Rapid Development. Auswahl eines passenden Teams. Professional Teamplayer, Globalplayer & Stars Alle Kompetenzen, die notwendig sind Bevorzugtes Arbeiten nach agilen Prinzipien Selbstorganisierendes und regulierendes Arbeiten Geographisch, räumliche Nähe, Sit together Eine Person gibt die Richtung vor, eine Person wahrt die Regeln

41 Wie geht man erfolgreich Live. Tag

42 Fallbeispiel. Tag Live. Tag 3. 16:00h letztes Stand-up Thomas ist nervös Das Team ist zuversichtlich Nur noch ein Deployment - Live! Project Review, 30 min

43 Rapid Development. Der erfolgreiche Launch. Kein Bing-Bang Delivery! Streuen Sie schon vor und während der Entwicklung Hinweise Erlauben Sie bald einmal einen Blick hinter die Kulissen (closed alpha / beta) Stabiliersieren Sie die Software in den nächsten Iterationen Legen Sie am Ende nur noch den Schalter um

44 Fallbeispiel. Ergebnis

45 Dos and Don ts

46 Rapid Development. Dos and Don ts. Dos Don ts Eine klare Vision haben Plausibles Zeitfenster Mit Personas und User Stories arbeiten Entscheiden. Nein sagen Interdisziplinär arbeiten und kommunizieren Agilität waren Alle Kompetenzen involvieren Grüne Wiese Fixe Vorstellungen vom Scope haben Technologie im Voraus festlegen Deployment durchführen Infrastrukturprobleme lösen Funktionale Spezifikationen schreiben Starre Pläne erstellen Big-bang delivery

47 Vielen Dank. Namics

48 Rapid Development. Literatur. Bücher Getting Real by 37signals (gettingreal.37signals.com) User Stories Applied by Mike Cohn (2004) Agile Software Development with Scrum by Ken Schwaber & Mike Beedle (2001) Links blog.namics.com inside-scrum.blogspot.com

49 Adhoco. Produkte. Zentrale Sensoren Aktoren

50