Menü

Entwicklung & Beratung
Workshops & Seminare
- Workshops
  - Kostentreiber bei der App Programmierung
- Seminare
  - Agiles Projektmanagement Seminar
Über uns
- Unternehmen
- Menschen
  - Team
  - Kunden
Karriere
- - - Durchstarten bei moguru
Werkzeuge & Fachartikel
- Werkzeuge
  - Agile Assessment
  - App Kostenrechner
- Fachartikel
Kontakt

Industrie 4.0

IoT Industrie 4.0 am Beispiel Oncite

23. Dezember 2020Kategorie: Industrie 4.0

Die Zusammenarbeit mit dem moguru Team war von Beginn an von Professionalität, sowohl technisch als auch menschlich, geprägt. Dies hat die Zusammenarbeit im Projekt insgesamt sehr positiv beeinflusst und so den oft schwierigen und kostspieligen Teambildungsprozess enorm verkürzt. Michael Cornel, Head of Software Development Die moguru GmbH unterstützt GEC bei…

Mehr erfahren

Industrie 4.0 Digitalisierung am Beispiel der Gesipa iOS App

23. Dezember 2020Kategorie: Industrie 4.0

Bei der Entwicklung der iBird Pro App übernahm die moguru GmbH die Implementierung der iOS universal App, d.h. die App läuft auf iPhone und iPad. Mit einem kleinen Entwicklerteam wurde eine Nutzerzentrierte, visuell ansprechende und vor allem hoch funktionale App bereitgestellt. Das Akku-Setzgerät iBird Pro wird per QR-Code gekoppelt und…

Mehr erfahren

Industrie 4.0: moguru vernetzt Mensch und Maschine

31. März 2020Kategorie: Business

Industrielle Werkzeuge und ihre Anwender nutzbringend miteinander zu vernetzen – das ist das Kernziel der Industrie 4.0. Für eine gelingende Mensch-Maschine-Interaktion sorgen zum Beispiel ausgeklügelte Apps von moguru. Im Auftrag eines führenden deutschen Werkzeugherstellers portiert die moguru GmbH derzeit eine App von Android auf iOS, die eine direkte Schnittstelle zwischen…

Mehr erfahren

Kontakt

Sie haben Fragen?

Wir freuen uns über Ihre Kontaktaufnahme!

Alena Walk
Managerin Project Onboarding
+49 6151 6292715
hallo@moguru.de

Neuste Beiträge

Smart unterwegs, auch im Office

moguru stärkt B2B-Geschäft mit optischer Datenaufbereitung

E-Mobilität: moguru an Entwicklung von komfortabler Lade-App beteiligt

Im Fokus: Googles Cross Platform Framework Flutter!

Guiding through Elster: moguru entwickelt eine Quiz-App!

Archiv

moguru

Havelstraße 16
64295 Darmstadt
Anfahrt

Impressum | Datenschutz | Blog

Anfragen

+49 6151 6292715

hallo@moguru.de

moguru im Web

XING

Instagram

facebook

Registrieren Sie sich für unseren kostenfreien Newsletter

Ihre Daten werden nur zur gewünschten Kontaktaufnahme per Newsletter gespeichert.

Screenr parallax theme von FameThemes

Product Owner

Der Product Owner (PO) ist für die Ausgestaltung und somit den wirtschaftlichen Erfolg (ROI) des Produktes verantwortlich. Der Product Owner schützt das Entwicklungsteam durch seine Funktion (neben dem Scrum Master) gegenüber störenden Eingriffen weiterer Stakeholder.

Der PO ist bevollmächtigt endgültige Entscheidungen über das Produkt, seine Merkmale und die Reihenfolge der Implementierung zu treffen.

Der PO ist somit der Ansprechpartner für das Entwicklungsteam bei der Frage, welche Produkteigenschaften in welcher Reihenfolge entwickelt werden sollen. Um diese Funktion optimal wahrzunehmen, arbeitet der PO co-located beim Scrum Team und plant mindestens 60% seiner Zeit für die Arbeit am Produkt ein.

Zu diesem Zweck erstellt, priorisiert und managt er die Anforderungen im Product Backlog.

Der Product Owner überprüft, ob die Arbeiten des Teams der Definition of Done entsprechen und somit als erledigt betrachtet werden können.

User Stories

User Stories sind eine umgangssprachliche Beschreibung der vom Markt gewünschten Funktionen. Die vom Product Owner zu schreibenden und zu priorisierenden User Stories sind üblicherweise in folgender Form geschrieben:

Als <Nutzer Rolle> will ich <gewünschtes Ziel> damit <Nutzen/Grund>

Beispiel einer User Story eines fiktiven Online Shops:
Als Kunde möchte ich in meiner Rechnung alle die von mir bestellten Produkte sehen, so dass ich eine Quittung über den Kauf zur möglichen Regulierung von Garantiefällen habe.

Neben dieser Beschreibung brauchen User Stories sogenannte Akzeptanzkriterien. Hier am Beispiel des Online Shops:

Rechnungen sind internationalisiert (Sprachen sind zunächst Deutsch und Englisch)
Die Rechnung enthält die Rechnungsnummer
Die Rechnung wird als PDF bereitgestellt
…

Beim schreiben guter User Stories kann man sich an das Wort INVEST anlehnen. Gute User Stories sind Independent, Negotiable, Valueable, Estimable, Small and Testable.

Burndown Chart, Sprint Backlog, Improvement Backlog

Das Burndown Chart veranschaulicht den Fortschritt eines Sprints. Ein Burndown Chart stellt die noch zu bearbeitenden Items, z.B. als Story Points, im Verhältnis zur Zeit grafisch dar. Die Story Points sind dabei normalerweise auf der Y-Achse und die Zeit auf der X-Achse aufgetragen (siehe auch Burn-up Chart). Mit Hilfe des Burndown Charts lassen sich Abweichungen im Verlauf eines Sprints frühzeitig erkennen und angemessene Lösungsmaßnahmen können rechtzeitig begonnen werden.

Im Sprint Backlog befinden sich die im aktuellen oder kommenden Sprint zu bearbeitenden User Stories und Aufgaben. Die Lieferung der im Sprint Backlog befindlichen User Stories im Sprint wurde vom Team prognostiziert. Ziel eines Sprints ist die Fertigstellung eines nutzbaren und releasefähigen Inkrements.

Das Improvement Backlog ist eine nach Priorität geordnete Liste mit Maßnahmen zur Verbesserung der Zusammenarbeit. Die Improvements sind Ergebnisse der Sprint Retrospektiven und werden im Improvement Backlog als Stories abgebildet und zusammengefasst. Für die Pflege des Improvement Backlog ist nicht der PO sondern das Team verantwortlich.

Planning 1

Im Rahmen des Planning 1 (Sprint Planung) werden die priorisierten Backlog Einträge geschätzt und die im nächsten Sprint zu bearbeitenden Items ausgewählt.

Je nachdem wie häufig ein Backlog Refinement stattfindet, kann eine Sprint Planung für einen zweiwöchigen Sprint zwei bis sechs Stunden als angemessen betrachtet werden.

Sprint

Sprints (Kurze Entwicklungszyklen von zwei bis vier Wochen) bilden die Grundlage für schnelles Feedback und Anpassungen am Produkt. Während des Sprints fokussiert sich das Entwicklungsteam auf die Erstellung fertiger Software Inkremente. So wie alle regelmäßigen Aktivitäten verändern Sprints ihre Dauer optimalerweise nicht.

Produktinkrement

Das Produktinkrement besteht aus allen bisher fertig gestellt Backlog-Einträgen (frühere und aktueller Sprint), die der Definition of Done entsprechen.

Entwicklungsteam

“Ein Scrum Team besteht optimalerweise aus 4,6 Personen.”
Jeff Sutherland, in seinem Buch “SCRUM, The Art of Doing Twice the Work in Half the Time”

Ein Scrum Entwicklungsteam besteht heute dennoch meist aus 6-9 selbstorganisiert arbeitenden Personen.

Die Mitglieder eines Entwicklungsteams haben gemeinsam das Know-how, alle Aufgaben zur Produkterstellung durchzuführen. Dabei achten die Teammitglieder darauf, dass sich die jeweiligen Spezialisten (z.B. Frontend Entwickler) sich auch in anderen Bereichen (z.B. Test und Backend Entwicklung) mindestens oberflächlich auskennen (T Shape).

Definition of Done

Die Definition of Done ist eine Auflistung von Vorbedingungen welche erfüllt sein müssen, damit ein Backlog Item als fertig bezeichnet werden darf. Mit wachsender Erfahrung des Teams verändert sie sich im Laufe der Zeit. Die Definition of Done enthält unter anderen:

funktionale Anforderungen (“Die bereitgestellten Funktionen arbeiten wie gewünscht”)
nicht funktionale Anforderungen (“Die Antwortzeit muss unter einer Sekunde liegen”)
Prozessuale Bestandteile (“Freigabe durch den Product Owner ist erfolgt”)
Qualitätskriterien (“Code Review wurde durchgeführt”, “Test wurde erfolgreich durchgeführt” etc.)

Planning Poker

Planning Poker ist eine Technik zur “Größenabschätzung” von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning I Anwendung findet.

Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Planning Poker führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.

Bereits nach ca. 4-5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.

Definition of Ready

In der Definition of Ready (DoR) werden all die Kriterien gesammelt, die erfüllt sein müssen damit eine Story in den Sprint aufgenommen werden kann. In der DoR werden zum Beispiel folgende Punkte geprüft:

Die Story ist klar und verständlich geschrieben
Alle Teilaspekte der Story wurden mit dem Team besprochen und von diesem verstanden
Der Product Owner hat eine Priorisierung der Story vorgenommen
Das Team hat eine Schätzung abgegeben
Es wurden Akzeptanzkriterien (z.B. mindestens drei) genannt
Externe Abhängigkeiten wurden diskutiert

Product Backlog

Im Product Backlog werden alle Anforderungen an das Produkt vom Product Owner in Form von User Stories aufgelistet und priorisiert. Durch kontinuierliche Weiterentwicklung dieser Stories und aufgrund neuer Erkenntnisse bleibt das entwickelte Produkt stets nahe an den Anforderungen des Marktes.

Sprint Retrospektive

Im Rahmen der Sprint Retrospektive identifiziert das Team die Stellschrauben zur Optismierung des nächsten Sprints. Unter Anleitung des Scrum Masters deckt das Team positive und negative Aspekte der Arbeit im letzten Sprint auf. Aus dieser Diskussion werden Maßnahmen zur Verbesserung der Zusammenarbeit für den nächsten Sprint definiert. Die Ergebnisse finden Eingang in das Impediment- oder Improvementbacklog.

Sprint Review

Im Sprint Review, am Ende eines jeden Sprints, präsentiert das Entwicklungsteam das fertiggestellte Produkt Inkrement.

Das Ziel des Sprint Reviews ist die Synchronisation aller Beteiligten über den aktuellen Stand der Arbeiten (keine Folien). Somit wird eine Entscheidungsgrundlage über die folgenden Produkterweiterungen für das Planning I gelegt.

Der Sprint Review kann für einen zweiwöchigen Sprint innerhalb von 30-60 Minuten durchgeführt werden. Eine detaillierte Vorbereitung und Abstimmung im Entwicklungsteam von maximal einer Stunde ist dabei angeraten.

Planning 2

Im Planning 2 werden die User Stories vom Entwicklungsteam in Tasks zur Entwicklung und zur Erfüllung der Definition of Done zerlegt.

Product Backlog Refinement

Das Product Backlog Refinement ist neben dem Planning 1 und dem Sprint Review die wichtigste Schnittstelle zwischen Entwicklungsteam und Product Owner. Im Product Backlog Refinement werden vom Product Owner regelmäßig (z.B. jede Woche mindestens eine Stunden) neue User Stories vorgestellt, Fragen des Teams beantwortet und wenn möglich vom Team geschätzt. Ist eine Schätzung nicht möglich (Definition of Ready nicht erfüllt), klärt der Product Owner offenen Fragen und stellt die Story im nächsten Refinement erneut vor.

Scrum Master

Die Verantwortlichkeit für die Integration der Scrum Arbeitsweisen und Verfahren liegt beim Scrum Master. Er coacht dafür sowohl die Organisation, den Product Owner als auch die Team Mitglieder.

Der Scrum Master achtet auf die Durchführung der Aktivitäten im Rahmen der vereinbarten Zeiten (Timeboxing). Er stellt sicher, dass sich alle Team Mitglieder an die selbst getroffen Vereinbarungen halten. Er hilft dem Team erkannte Hindernisse zu beseitigen.

Der Scrum Master ist der Coach am Spielfeldrand. Er ist weder Mitspieler noch gibt er konkrete Vorgaben wie und welche Arbeiten erledigt werden sollen.

Er coacht die Team Mitglieder, verantwortet die Dokumentation des Fortschritts (Burn Down Chart) und hilft so dem Team qualitativ hochwertige Produkte zu erstellen.

Daily

Durch das Daily wird der kontinuierliche Informationsaustausch zwischen den Teammitgliedern gefördert. Ziel des Dailys ist es, vorrangig einen Überblick darüber zu erhalten was die Teammitglieder am vorigen Tag getan haben, woran sie heute arbeiten werden und was sie in ihrer Arbeit behindert. So sorgt das Daily für Transparenz und die Möglichkeit für die Teammitglieder sich optimal zu unterstützen und Abhängigkeiten zu erkennen. Das Daily ist insbesondere kein Statusmeeting für den Product Owner oder gar den Scrum Master. Es ist streng darauf zu achten, dass Dailys die vereinbarte Zeit, optimalerweise 15 Minuten, nicht überschreiten.

Stakeholder

Stakeholder sind zum Beispiel Kunden, Investoren, Anwender, Partner, Aktionäre, andere Mitarbeiter oder das Management. Die Stakeholder sind direkt oder indirekt von den Projektergebnissen betroffen und haben ein (wirtschaftliches) Interesse an dem Produkt. Sie sind jedoch nicht Teil eines Scrum-Teams. Die Stakeholder teilen dem Product Owner ihre Anforderungen und Wünsche an das Produkt mit und beeinflussen auf diese Weise die Produktentwicklung. Der Kontakt mit dem Scrum-Team während eines Sprints erfolgt ausschließlich über den Product Owner.

Vision

Die Vision ist eine ganzheitliche Betrachtung der Projektziele oder des Produkts und wird vom Product Owner entwickelt. Er erzeugt (ggf. zusammen mit dem Scrum-Team, Stakeholdern, Marketing) ein Zukunftsbild der Idee / des Projekts. Die Vision soll die Stakeholder und das Team von dem Produkt überzeugen, sie motivieren und begeistern.

Search for:

Diese Website benutzt Cookies. Wenn du die Website weiter nutzt, gehen wir von deinem Einverständnis aus.OK Datenschutzerklärung

Industrie 4.0

Kontakt

Sie haben Fragen?

Neuste Beiträge

Kategorien

Archiv