Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

SCRUM: Hardware

Teleseminar alpha-board
by

Gregor Gross

on 26 August 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM: Hardware

Teleseminar
26. August 2014

Gregor Groß

Hardware: SCRUM
Warum SCRUM?
10 Regeln
SCRUM: Hardware-Spezifisches
Iterativ die optimale Lösung finden:
Selbstorganisation durchs Team
Pull-Prinzip: Kontrolliere den Input
Lernen beim Abarbeiten
Timebox: Grenzen
nutzbare Business-Funktionalität bei jedem Schritt
Vorteile von SCRUM
Fokus
Ständiges Abarbeiten von Problemen
Timeboxed
Selbst-Organisation der Teams
Multidisziplinär, fachübergreifend
Diszipliniertes Arbeiten an einer Sache
ständiges Testen / Lernen WÄHREND der Entwicklung
Das Produkt hat eine klare und fesselnde Vision.
Das Product Backlog ist gepflegt und besteht aus gut beschriebenen Backlog Items.
Das Product Backlog ist sortiert anhand des Business Values.
Backlog Items schätzt das Team selber ein.
Es gibt täglich Daily SCRUMs.
Das Team erzeugt einen Burndown-Chart.
Der Sprint wird nicht von außen gestört.
Hardware, die das Team übergibt, ist verwendbar und erfüllt qualitative Anforderungen (DoD)
Am Ende eines Sprints gibt's einen gemeinschaftlichen Sprint Review.
Sprint Retros helfen, das Team zu verbessern.
Code lässt sich leichter ändern als Hardware
Hardware ist wie Software, aber nur mit 2x Kompilieren
Software kostet nur Zeit, Hardware auch Geld
shippable code - was ist damit gemeint?
Wir sollen für 30 Leute Kürbissuppe kochen!
- Kürbis
- Ingwer
- Möhren
- Hirschsalami
- Sahne
- Mango-Chutney
- Gemüsefond
- Kartoffeln
Gemüse schälen, waschen, hacken, anbraten. Fond und Chutney dazu, 20 min kochen lassen. Sahne rein, pürieren. Salami in Scheiben anbraten, abschmecken, anrichten: FERTIG!
Wir sollen für 30 Leute deren jeweiliges Lieblingsrezept kochen!
Wer will was?
Was einkaufen?
Was wird wann gebraucht?
Wann womit anfangen?
SCRUM: Der Aufbau
3 Rollen
3 Meetings
3 Artefakte
Die Rollen
Product Owner (PO: der Autor)
Team (die Darsteller)
SCRUM Master (SM: der Regisseur)
Die Meetings
Sprint Planning (PO):
präsentiert User Stories für 1-2 Sprints
ordnet User Stories nach Wert
Schätzen, Auswahl, Task Breakdown (durchs Team)
Daily SCRUM (SM, Timebox: 15 min):
Inspektion und Anpassen
was erreicht, was vor, was hindert?
Sprint Review & Retrospektive (Team):
Review & Akzeptanz (durch PO)
Review gegen Vision & Sprint-Ziele
Produktivitätsverbesserung (Team, SM)
Die Artefakte
Product Backlog (PO)
Stories nach Wert, Risiko, Sequenz geordnet
Why (Anforderung), What (User Stories)
Akzeptanz-Kriterien nicht vergessen
Sprint Backlog (Team)
User Stories für den Sprint
Aufgaben zum Erreichen der User Stories
nur soviel, wie für paar Tage benötigt
Burn-Down-Chart (SM)
Visualisiert erledigte Aufgaben (in h)
Fragen?
Vor dem ersten Sprint
Vision erstellen
durch Product Owner
Vision erzeugt emotionale Reaktion aufs Ziel
z.B. durch Storytelling, Freewriting, Elevator Pitch
Beispiel:

Für (Kunden), die (Bedarf oder Gelegenheit beschreiben), ist das (Produktname) eine (Kategorie), die (Hauptvorteil). Anders als (Alternative/Wettbewerb) kann unser Produkt (Hauptunterschied).
Product Backlog Items als Stories
Product Backlog erstellen
sowas wie Einkaufsliste für das Projekt
keine Anforderungen
keine Spezifikationen
ist niemals vollständig
nicht alleine vom Product Owner zu schreiben
es gibt keine technischen Backlogs (sondern nur funktionelle)
Priorisieren
durch Product Owner
anhand des Business Werts
Must Could Wish
1000 Ping-Pong-Bälle
oder andere Methoden
Items schätzen
Team, Product Owner, Scrum Master
Aufwand und Größe schätzen
mit Story Points relativ zueinander
z.B. mit Planning Poker:

http://www.alpha-board.de/elektronik-design/entwicklungsaufwand-schatzen-mit-planning-poker/
Wertigkeit berechnen
Viel Bumms für wenig Aufwand!

sprich:
Höchste Business-Werte mit wenigstem Aufwand zuerst!

(z.B. durch Rückfrage des PO beim Kunden!)
1. Sprint befüllen
Team, Product Owner, Scrum Master
Team verpflichtet sich, welche Stories im Sprint abgearbeitet werden
Sprintdauer 2 Wochen
Zum Arbeiten verfügbare Zeit berechnen:
Meetings, Grooming, Urlaub abziehen
Backlog Items in Aufgaben verwandeln
Designworkshop: Skizzen, Architektur
ergibt Aufgabenliste fürs Team
Sprint Backlog entsteht
Team, Scrum Master
Problem bekannt / Lösung unbekannt (entw)
Problem bekannt / Lösung bekannt (pcbd)
SCRUM: Projektablauf
Sprint Review
Sprint Retrospective
Sprint Planning
Sprint II
usw.
während des Sprints:
Daily SCRUM:
am Task-Board mit Haftnotizen und Marker
gesamtes Team und SCRUM Master
(öffentlich, aber nur Team spricht)
max. 15 Minuten, gleiche Zeit
Was habe ich erreicht?
(-> Burn Down Chart)
Was will ich heute erreichen?
Was hindert mich?
(Impediment)
als Stories formulieren:

Als Anwender mit der Rolle benötige ich diese Funktionalität, damit ich diesen Nutzen bekomme.
am Task-Board mit Haftnotizen und Marker
90 Minuten, am Ende eines Sprints
Team, SM, Owner, User
"testable product" wird gezeigt
im Sprint: Pre-Akzeptanz!
alle können neue Funktionalität testen
Ziel und Erreichtes werden verglichen
Output
Feedback vom User
Impediment Backlog Items
Team Backlog Itens
Product Backlog Items
Output
Wer macht was?
Impediment Backlog Items
Team Backlog Items
Flipchart, Marker
max. 60 Minuten, nach Sprint Review
Team, Scrum Master
Was lief gut?
Was könnte besser werden?
KEIN MANAGER DABEI!
Output
Impediment Backlog Items
Team Backlog Itens
(SPRINT Planning)
Sprint Planning
Sprint Planning
Bleiben Sie auf dem Laufenden:
twitter.com/pcbdesign
alpha-board.de
alpha-board.de/kontakt/newsletter/
Danke!
Weiterführende Info:
Im Web:
SCRUM Atlas: http://agileatlas.org/atlas/scrum
Bücher:
Mike Cohn: Agile Software-Entwicklung
Boris Gloger: SCRUM
Shippable Code?
nicht unbedingt: Hardware zum Kunden liefern
(wegen Produktionszeiträumen)
aber:
auf jeden Fall Feedback (z.B. Stromplaufplan)
testable User Stories?
modulare Funktionen?
Breadboard?
Listen, Schaltpläne?
Gehäuse, Preise?
User Story: EMV?
Modular denken!
Modular aufbauen
einfaches Testen
wiederverwendbar (aus früheren Projekten)
schnell anpassbar
paralleles Entwickeln/Testen möglich
Testen, testen,
testen!
Module erst testen, dann verwenden
so oft wie möglich: Kunde und User einbeziehen
Tester sind Teil des Teams (ACHTUNG: Do 254)
vom ersten Sprint an
für jede User Story und Aufgabe
nicht nur im Sprint Review: Pre-Akzeptanz!
Kunde (der Produzent)
Anwender (das Publikum)
Manager (der Studioboss)
Akzeptanz-Kriterien
nicht vergessen!
Daily SCRUMs
Pre-Akzeptanz
SM auch im Team (weil kleine Firma)
Pflichtenheft <-> User Stories
farbige Post-Its für versch. Stories
einzelne Module in einzelnen Sprints
ständig testen - wie?
modular entwickeln?
Was ist mit Fertigungsläufen?
Was ist mit der Dokumentation?
alpha-board Spezifisches
Definition of Done
User Stories nicht mehr anfassen
das beinhaltet: Dokumentation
Akzeptanz-Kriterien mit Kunden abstimmen und von Anfang an berücksichtigen
Für Tasks: 4-Augen, Testumfang schätzen
Für Stories: Pre-Akzeptanz!
Full transcript