Projekt 1. HAW Hamburg, MS1, WiSe 2013/ All rights reserved. Copyright 2010.

Transkript

3 Erfolgreiche Abnahme Projekt 1 Bearbeitung des Projektes in einem Team von mindestens 2 Personen Größe Abgabe des funktionierenden Quellcodes Abgabe der Projektdokumentation als Projekttagebuch inkl. Persona(s) User Stories Wireframes Clickflow Rollen- & Aufgabenverteilung der Projektmitarbeiter Dokumentation der Art und Weise, wie zusammengearbeitet wurde Dokumentation der Dinge, die gut funktionierten im Team inkl. Begründung Dokumentation der Dinge, die im Team nicht so gut funktioniert haben inkl. Begründung Dokumentation der Dinge, die man im Team mehr machen sollte inkl. Begründung Dokumentation der Dinge, die man im Team weniger machen sollte inkl. Begründung Dokumentation der Dinge, die man im Team ausprobieren sollte inkl. Begründung Demo des Projektes agile@silpion.de All rights reserved. Copyright 2010.

5

6 Analyse & Konzeption Implementierung Test Laufzeit t Traditionelles Arbeiten

7 Analyse & Konzeption Implementierung Test Laufzeit $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ Investition t

8 Analyse & Konzeption Implementierung Test Laufzeit $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ t Dilemma Alte Ideen!

9 (Traditionelle) Software Projekte sollen die Bedürfnisse der Nutzer decken sollen termingerecht abgewickelt werden sollen im veranschlagten Budget sein sollen die richtige Qualität liefern Quelle: The Standish Group Chaos Report, 2006

10 (Traditionelle) Software Projekte sollen die Bedürfnisse der Nutzer decken Quelle: The Standish Group Chaos Report, 2006

18

19 Analyse & Konzeption Implementierung Test Geschäftswert Kundenbedürfnis Laufzeit Ergebnis (traditionell) t $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ Bewegung des Marktes

20 Would you tell me, please, which way I ought to go from here? That depends a good deal on where you want to get to, said the Cat. I don t much care where said Alice. Then it doesn t matter which way you go, said the Cat.

21 bridging the gap: think beta!

22 where do you want to go? and why?

23 status quo vs. desired goals

26 the elevator pitch template & the idea behind it For <customer> who <needs/is disappointed with> <product name> is a <product category> that <USP>. Unlike <main competitor(s)> it delivers <3-4 additional benefits>

27

28 persona who is he/she? age, gender, other info... what are his/her goals? focus! what s his behaviour? be descriptive! => what are the key goals for us? > what s a must? > what s to avoid?

29 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Implementierung Implementierung Implementierung Implementierung Implementierung Implementierung Test Test Test Test Test Test Geschäftswert Kundenbedürfnis Agiles Ergebnis Laufzeit Ergebnis (traditionell) t $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ Iterative & inkrementelle Entwicklung

30 Valuable, high-quality features Sprints Iterative & incremental development

31 Analyse & Konzeption Implementierung Test Risiko Traditionell Laufzeit $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ Risikobewertung t

32 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Analyse & Konzeption Implementierung Implementierung Implementierung Implementierung Implementierung Implementierung Test Test Test Test Test Test Risiko Traditionell Laufzeit $ $$ $$$ $$$$ $$$$$ $$$$$$ $$$$$$$ Risikobewertung Agile t

33 Planung & Transparenz Vorgehen nach Phasen vs. Anzahl vollständiger, getesteter, produktionsreifer Features Quelle: The Business Value of Agile Software Development by Brad Swanson (Propero Solutions LLC) 2009

34 Besseres ROI Quelle: The Business Value of Agile Software Development by Brad Swanson (Propero Solutions LLC) 2009

35 Qualitätsverbesserung Quelle: The Business Value of Agile Software Development by Brad Swanson (Propero Solutions LLC) 2009

36 Fokus durch klare Verantwortlichkeiten Product Owner Scrum Master (Development) Team Scrum Team

37 The Development Team has to... create & maintain track attend & participate Sprint Backlog Sprint Progress Sprint Meetings

38 Four phases of a team (Bruce Tuckman 1965) Forming Performing Storming Norming

39 Product Owner Product Backlog

40 The Product Backlog Owned by the Product Owner Absolutely ordered List of unplanned Backlog Items (User Stories, Bugs, etc.) Every item must fulfill the Product Vision DEEP Detailed appropriately Estimated Emergent Prioritized

41 Backlog Items avoid horizontal slices! high Detail low

42 Backlog Items tend to vertical slices! high Detail low

43 The Product Backlog should be refined periodically. Use Backlog Grooming Meetings in order to do that. could be refined by the Scrum Team stakeholders Everybody can contribute to the Product Backlog, but it s owned by the Product Owner. He is responsible for state content

44 INVEST in Backlog Items Independent Negotiable Valuable Estimable Small (or sized approprietaly) Testable

45 SMART Backlog Items Simple Measurable Achievable Relevant Traceable

46 Non-functional Requirements could be added as notes to the Product Backlog Items you can also set up some kind of document which should be highly visible that could be refered from the related Backlog Items

47

48

49 Der Product Owner

50 Der PO ist hauptverantwortlich für die Optimierung des ROI

51 Der PO ist hauptverantwortlich für den Erfolg des Produkts

52 Werkzeuge... Product Vision User Stories Product Backlog Release plan/ Roadmap...wenn nötig auch andere...

53 Transparenz

54 Hindernisse transparent machen und aktiv angehen

55 Scrum in einem Satz... Scrum ist ein einfaches "beobachte und adaptiere" Framework mit drei Rollen, drei Zeremonien und drei Artefakten, das entwickelt wurde, funktionsfähige Software in Sprints, üblicherweise 30-Tage Iterationen, zu liefern. (1. Scotland, A. the BBC. in JAOO Aarhus, Denmark: EOS.)

64 INVESTiere in User Stories Independent: Stories sind am einfachsten zu bearbeiten, wenn sie unabhängig sind Negotiable Eine gute Story ist verhandelbar. Sie ist kein expliziter Vertrag für Funktionalität Valuable Eine Story liefert Mehrwert für den Kunden Estimable Eine gute Story ist schätzbar Small or Sized appropriately Gute Stories tendieren dazu, klein zu sein: meist wenige Personenwochen Testable "Ich verstehe, was gewünscht ist, gut genug, um einen Test dafür zu schreiben" All rights reserved. Copyright 2010.

65 User Story Priorities Mandatory: all stories that are needed in order to fulfil a user need. Linear: The more you get the better it is... (Mike Cohn) Exciter: the user doesn t know that he needs it until he sees it... (Mike Cohn)

67 Wann weißt Du, dass Du fertig bist? Ein Release ist fertig, wenn es alle Kriterien erfüllt, die der Product Owner, der alle Stakeholder repräsentiert, um die Software Richtung Produktion auszuliefern Eine User Story ist fertig, wenn es die zur Story gehörenden Akzeptanzkriterien, die Definition of Done und die Qualitätskriterien des Teams erfüllt, um potentiell auslieferbar zu sein All rights reserved. Copyright 2010.

68 Beispiel Definition of Done Code ist kommentiert, unter Versionskontrolle und gegen die aktuelle Version des Versionskontrolle getestet Peer reviewed (oder durch Pair programming erstellt) und erfüllt die Entwicklungsstandards Erstellt ohne Fehler Unit tests sind geschrieben und bestanden Auf der Testumgebung installiert und alle Systemtests erfüllt Passiert UAT (User Acceptance Testing) und verläßt diese als Anforderung erfüllt Jede Änderungen am Bau/Auslieferunf/Konfiguration ist implementiert/dokumentiert/ kommuniziert Relevante Dokumentation/Diagramme sind erstellt und/oder aktualisiert Verbleibende Stunden für die Tasks sind auf Null gesetzt und die Tasks sind geschlossen All rights reserved. Copyright 2010.

69 Akzeptanz Kriterien Beantworten die Frage: Wie weiß ich das wir fertig sind? High-level Kriterien aus der Sicht eines Nutzers oder eines Stakeholders Es gibt positive und negative Kriterien Arbeite mit Testern zusammen, um gute Akzeptanz Kriterien zu schreiben All rights reserved. Copyright 2010.

70 Beispiel User Story As a Returning Customer I want the system to remember my details so I can purchase goods quicker. Acceptance criteria: The details are presented for review before I make the purchase I can edit the details directly in that view I can make the system forget my details agile@silpion.de All rights reserved. Copyright 2010.

71 Beispiel User Story As a Returning Customer I want the system to remember my details so I can purchase goods more quickly. Acceptance criteria: Scenario: Review Details Before Purchase Given I m on the Amazon website And I m logged in as a returning customer When I click the 1-Click button Then I should see my order details agile@silpion.de All rights reserved. Copyright 2010.

72 User Stories bearbeiten Minimallösungen - was ist das Mindeste, was ausgeliefert werden kann? Bells and whistles Lösungen Minimiere das Risiko - maximiere das Return on Investment! Starte mit der Minimallösung Bewege Dich iterativ zu einer vollfunktionsfähigen Lösung agile@silpion.de All rights reserved. Copyright 2010.

73 User Story Workshops Der PO muss nicht mit allen User Stories kommen Nutze die Möglichkeiten der Personen um Dich herum Es wird empfohlen, einen User Story Workshop mit dem Entwicklungsteam mindestens zu Beginn eines jeden Releasezyklus abzuhalten Präsentiere das Ziel für den nächsten Releasezyklus und stelle die zugehörigen Anforderungen vor Benutze Kreativitätstechniken, um so viele User Stories wie möglich mit dem Team herzuleiten Versuche, Top-MMFs zu identifizieren und diese in User Stories herunterzubrechen oder User Stories in MMFs zu clustern All rights reserved. Copyright 2010.

83 Das Agile Manifest Wir entdecken bessere Wege, Software zu entwickeln, indem wir es machen und anderen helfen, es zu machen. Aus dieser Arbeit kommen wir zu folgenden Werten: Individuen und Interaktionen über Prozesse und Werkzeuge Arbeitsfähige Software über umfangreiche Dokumentation Enge Zusammenarbeit mit dem Kunden über Vertragsverhandlungen Offenheit und Eingehen auf Änderungen über dem strikten Folgen eines Plans All rights reserved. Copyright 2010.

84 Prinzipien des Agilen Manifests (1/2) 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. 2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. 3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzeren Zeitspannen. 4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. 5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. All rights reserved. Copyright

85 Prinzipien des Agilen Manifests (2/2) 7. Funktionierende Software ist das wichtigste Fortschrittsmaß. 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. 9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. 10.Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. 11.Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. 12.In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. All rights reserved. Copyright