Please enable JavaScript.
Coggle requires JavaScript to display documents.
VL 12 - Projektmanagement - Abschluss und was ist Agile? (Bedeutung von…
VL 12 -
Projektmanagement
- Abschluss und was ist Agile?
Agile Methoden
Ursprünge
Kaizen
Nach 1945, japanisch für "Improvement"
Ziel: Verändern zum Besseren
Durch kontinuierlichen Veränderungsprozess Verbesserung erzielen
XP (extreme Programming)
ca 1999
Softwarequalität erhöhen durch
Kundenfokus
Änderungsorientiertes Vorgehen
Verbesserung der Software Praxis z.B. durch Pair Programming <3
Agile Methoden
XP
BDD - Behaviour Driven Development
Test Driven Development
Lean Software Development
Crystal
Projektmanagementmethoden
Scrum
Kanban
Bewertung
Wertesysteme Agile Manifesto und Manifesto for Software Craftmanship erinnern an einen Eid
Manifesto for Agile Software Development (2001)
Customer collaboration over contract negotiation
Responding to change over following a plan
Working software over comprehensive documentation
Individuals and interactions over processes and tools
Manifesto for Software Craftmanship (2003)
Not only working software but also well crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also community of professionals
Not only customer collaboration, but also productive partnerships
Nützt bei vielen Projekttypen und schadet zumindest nicht
Hoher Wer bei Projekten mit Änderungswahrscheinlichkeit
Projekte mit klarem statistischen Scope gewinnen durch Agile häufig nichts
Häufiges Feedback hilft
Optimalen Kundennutzen zu erreichen
Risiko durch Fehlentwicklung zu reduzieren
Proleme in Organisation und Aufgabe frühzeitig aufzuzeigen
Agiles Vorgehen häufig Motivations Booster für Teams!
SCRUM
Project-Managementrahmenwertk
Komplettiert und komplementiert SE-Methoden um Projektmanagementanteile
Hat wird mittlerweile häufig als Synonym agilen Vorgehens wahrgenommen
Ist Mainstream
Empirisches Management
Kernideen
Inspect and adapt
Selbstorganisation
Selbstmanagement
Eigenverantwortung
Autonome Teams
Fokus auf Erreichung des optimalen Nutzwertes für Kunden
Rollen
Scrum Team
Scrum Master
Repräsentiert Management gegenüber Projekt
Unterstützt Team und Product Owner, aber managed nicht
Team Coach
Schützt das Team vor Störungen
steigert Raum für Keeativität und Selbstorga
Verbessert engineering practices
Verantwortlich für Einhaltung von Scrum Werten und Techniken
Stellt sicher, dass das Team vollständig, funktional und produktiv ist
Unterstützt enge Zusammenarbeit zwischen allen Rollen und Funktionen
Kümmert sich um Hindernisse (Impediments)
Verantwortet Prozess ist aber kein Projektleiter!
Umsetzungsteam
Setzt das Projekt um (die armen Schweine)
Selbstorganisiert und selbst managend
Beurteilt ob Sprint leistbar ist
Wählt Einheiten aus dem Backlog aus
Schätzt die Einheiten
Commited sich
Aufbau
Größe 3 - 5 - 7 Leute
FUnktionsübergreifend, autonom (teilautonome Kleingruppen yey)
Vollzeitmitglieder bis auf Ausnahmen
Zusammensetzung ändert sich nicht - wenn, dann nur nach einem Sprint
Product Owner
Das richtige Produkt in der richtigen Reihenfolge bauen
Kundenwünsche kennen
Kundenbedürfnisse verstehen
den Markt kennen
Unternehmensziele in eine Produktvision übersetzen
definiert das Minimal Viable Product
hinterfragt gesetzte Wahrheiten
trifft Annahmen zum Produkt und validiert sie
Erkenntnisse
Definiert MVP
Beschreibt Product in Topics, Epics, User Stories
Entiwckelt Release Plan
plant und priorisiert PO zusammen mit Umsetzungs Team Produktentwicklung
begleitet PO Entwicklung und nimmt Ergebnisse gemäß Sprint Planung ab
passt Planungen an Erkenntnisse, Feedback, Ergebnisse an (Inspect & Adept)
kein Projektmanager und kein Architekt!, sondern Mittelsmann, repräsentiert Kunden, verantwortlich für finanzielles Ergebnis
gibt nur einen!
MVP
Minimum Viable Product
Nicht funktionale Produktqualitäten
Fokus
Konsistenz
Kohärenz
Erwartungskonformität
Projektorganisation
Kunden
Agile Coach
Management
Die Artefakte
Product Backlog
Priorisierte Liste von Product Backlog Items
Sammlung von Anforderungen
Unterschiedliche Granularität
Form
Epics, Topics, User Stories
In der Sprint-Planung wandern Priduct Backlog Items in das Sprint Backlog
Realisierungsaufwand wird in relativem abstraktem Maß geschätzt
Nur Owner priorisiert das Product Backlog!
Sprint Backlog
Definiert Aufgaben für einen Sprint
Um das Sprintziel zu erreichen
auf die sich das Team commited hat
User Stories werden auf Tasks heruntergebrochen
Tasks werden in Stunden geschätzt
Während eines Sprints wird der Scope von außen nicht mehr geändert
Anforderungen als User Stories
Shared documents
"Shared documents are not shared understaning"
Card
Whats on the Card
Conversation
Confirmation
Consequences
Construction
Vorgehen
Topics sammeln
In Epics aufbrechen
in User Stories zerlegen
User Stories mit Stakeholder validieren
Vor Sprint Refinement Meeting mit Umsetzungs-Team auf Umsetzbarkeit prüfen
WIederholen bis fertig
Burndown CHarts
Sprint Burndown
Y: Verbleibender Aufwand in Stunden
X: Fortschritt in Tagen
Release Burndown
X: Fortschritt in Sprints
Y: Verbleibende Aufgaben in Anzahl (Product Backlog)
Weitere
Scrum Board
Release Plan
Impediment List
Definition of Done
Definition of Ready
Prozess
Ziel: MVP
Vorgehen
Time Boxing
Zerteilen des Projekts in Sprints
Sprint zwischen 1 und 2 Wochen oder 2-4 Wochen? Folien widersprechen sich
Scope im Sprint ist Fix, richtet sich nach Team Geschwindigkeit (Velocity)
Ein Sprint kann ggf. abgebrochen werden
Am Ende eines Sprints steht ein potentiell lieferbares Produkt
Scrum im Überblick Grafik!!!!
Scrum Projekte schreiten in Serien von Sprints voran
Typische Dauer 2-4 Wochen
Sprintdauer sollte konstant bleiben für sinnvolle Messdaten
Jeder Sprint liefert potentiell lieferbares Inkrement des Produks
Neupriorisierung nach Sprint, während Sprint Scope fix
Product Backlog kontunierlich fortgeführt
Daily Scrum
Täglich 15 min stehend
Alle beantworten Fragen
Was gestern getan?
Was heute tun?
Was behindert mich?
kein Report, es geht um Commitment
Offen für alle, aber nur Scrum Team hat Rederecht
Scrum Master sammelt Impediments auf
Sprint Review
Team präsentiert Sprint Ergebnis und bekommt Feedback
Teilnehmer
Scrum Team
Kunden
"Welt"
Maximal 2h Vorbereitung
Dauer ca 2h
Stets das Projekt zeigen, keine Slideware oder Reports
Project Owner beurteilt das Ergebnis
anhand des Sprintziels
anhand der Definition of Done
Scrum Master organisiert und stellt den Prozess sicher
Sprint Retrospektive
Team prüft am Ende des Sprints, was gut und was nicht funktioniert
Dauer ca 15-30h
Teilnehmer: Team, Scrum Master
Scrum Master diskutiert, wie es sich verbessern möchte
Beginnen mit...
Aufhören mit...
Weitermachen mit...
Release Planning - User Story Maps
Planning
Input (strategisch)
Company Vision
Roadmap
Product Visions
Output (operativ)
Release Plan
Sprint Plan
Anforderungen
Beschreibung
User Activities - User Tasks
Topics - Epics - User Stories - Tasks
Planung/Beschreibung
User Story Map
Planung
Backlog
Sprint Backlog
Tools
Planning Board
Haptisch oder Trello
User Story Map
Haptisch oder Digital
Personas
Prototypen
Wireframes
Pen & Paper
Klick Dummy
Styleguide
Geschäftsprozessmodellierung
Ideen finden
Design Thinking
Open Spaces gemeinsam mit Kunden, Vertrieb, Fachbereich, Development..
Focus Groups gemeinsam und einzeln
Studenten Projekte
Interne Startups
Validieren
Tech
Messen
AB Tests
Friendly beta
beta-Test
Inkrementeller Rollout
Feedback Channel
No-Tech
User Tests
User Tests strukturiert
Usability Lab
Reviews mit Kunden
Schulterblicke
Interviews
Hospitieren
Diskussionen
Open Spaces
"Totschlagfloskeln"
alles wie im alten System
unsere Kunden verstehen das nicht
unsere Kunden wollen das nicht
wir wissen was unsere Kunden wollen
Zusammenfassung
Sprints
Sprintdauer 1-2Wochen
Sprintdauer konstant
Jeder sprint liefert lieferbares Inkrement
Zwischen Sprint Neupriorisierung
Fortführen des Product Backlogs
Was macht Scrum anders?
Vokabular schnell erlernt
Mächtig, einfach, aber nicht simpel
Wirkt einfach, erfordert aber viel Disziplin
Agiles Vorgehen
Gut bei explorativen Projekten mit hoher Änderungswahrscheinlichkeit
Erfordert i.a. Haltungsänderung
Agil und nicht agil lassen sich zu
hybridem Vorgehen
kombinieren. Bedeutet aber viel Erfahrung zu haben und Kompromisse einzugehen
Unterschied zu klassischem PM liegt im zugrundeliegenden Wertesystem!
Bedeutung von IXD
macht Geschäftsprozesse sichtbar
Design Sichten prägen agiles Verhalten
Design Thinking
Domain Driven Design
Software Design und Entwicklung
Interaktionsdesign
Graphisches Design
Agiles Mindset
Kundenzentriert
Feedbackorientiert
kurze Iterationen mit jederzeit greifbaren Ergebnissen
Begriff
IXD
beschäftigt sich mit der Gestaltung von Mensch Maschine Schnittstellen
Informationsdesign
Selektion, Organisation und Präsentation von Informationen -
Informationsarchitektur
IA -Sinnvolle Unterteilung der INhalte, die Navigationswege und Suchmöglichkeiten innerhalb des Angebots und die gebrauchstaugliche Gestaltung des Zugangs zu den Informationen
User Experience - UX
erlebte und gefühlte Qualität der Interaktion eines Nutzers mit z.B. digitalen Medien
Spiegelt Erfahrungen, Empfindungen, Gefühle während der Nutzung wider
Usability
Gebrauchstauglichkeit bzw. Software Ergonomie
Der Weg zum UI
UI entwerfen ist Aufgabe der Anforderungsermittlung
Mein Verständnis der Fachlichkeiten
meine Annahmen über Nutzen
mein Wissen über Kontext
Ich kann
Technologieauswahl vom IXD bestimmen lassen
Technologie bestimmen lassen und darauf IXD limitieren
Fachlichkeiten
Gedanken über Randfälle machen
Entscheiden um Nutzer zu führen /lenken
Farben
Kontraste
Abstände
Typographie
UI Elemente
Animationen etc.