Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS)
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS)
Consanis - die Nr. 1 für Agile Methoden in der Medizintechnik
http://www.consanis.de
Semelhante a Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS)
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?René Spengler
Semelhante a Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS) (20)
Warum sie mit Scrum keinen Erfolg haben werden - Agile Med 2014 (CONSANIS)
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS)
1. Wir erledigen alles sofort
Warum Qualität, Risikomanagement,
Gebrauchstauglichkeit und Dokumentation
nach jeder Iteration fertig sind.
2. Marc Bless
Coach und Berater für
Agile Methoden in der Medizintechnik
3. Frage
Wer hat Scr um schon einmal
in der Software-Entwicklung
eingeführ t,
ohne dass sich
echte Verbesser ungen
eingestellt haben?
4. Klassische Produktentwicklung wird durch
Phasenmodelle gesteuert
Anforderungen
Analyse
Architektur
Validierung
Verifikation
Entwicklung
Risikomanagement
Usability
Deployment
Dokumentation
5. Klassische Produktentwicklung wird durch
Phasenmodelle gesteuert
Anforderungen
Analyse
Architektur
Risikomanagement
Usability
Entwicklung
Verifikation
Dokumentation
Validierung
Deployment
6. Klassische Produktentwicklung wird durch
Phasenmodelle gesteuert
Anforderungen
Analyse
Architektur
Risikomanagement
Usability
Entwicklung
Verifikation
Dokumentation
Validierung
Deployment
7. Problem: Projekte werden nicht
in time und budget fertig
Anforderungen
Anforderungen
Analyse
Architektur
Risikomanagement
Risikomanagement
Usability
Entwicklung
Verifikation
Dokumentation
Validierung
Dokumentation
Deployment
Analyse
Architektur
Entwicklung
Verifikation
Usability
Validierung
Deployment
8. Entwicklungsleiter:
„Wir müssen effizienter
werden!“
Wichtigstes Ziel von
Scrum: wir wollen schnell
liefern!
Entscheidung:
Scrum wird
eingeführt
9. Entwicklungsleiter:
„Wir müssen effizienter
werden!“
Wichtigstes Ziel von
Scrum: wir wollen schnell
liefern!
Entscheidung:
Scrum wird
eingeführt
falsch
10. Lokale Optimierung
Anforderungen
Analyse
Architektur
Validierung
Verifikation
Entwicklung
Risikomanagement
Usability
Deployment
Dokumentation
11. Lokale Optimierung
Anforderungen
Analyse
Architektur
Validierung
Dokumentation
Verifikation
Entwicklung
Risikomanagement
Usability
Deployment
Der Value Stream der gesamten Produktentwicklung wird in vielen Fällen durch
den Einsatz agiler Methoden an nur einer einzigen Stelle (Entwicklung) optimiert,
in der Hoffnung, dadurch zu einer schnelleren Markteinführung zu gelangen.
12. Ursachen für lokale Optimierung
Unternehmensbereiche verfolgen
kein gemeinsames Ziel
Bereichsleiter werden an
abgekapselten Bereichszielen gemessen
„Agil ist nur ein Thema für die Software“
„die IEC 62304 fordert ein V-Modell“
13. Auswirkung lokaler Optimierung
Entwicklungs-Teams versuchen,
nach jeder Iteration liefern zu können
Vorgelagerte Phasen noch ohne Ergebnis
(„ja, aber fangt schon mal an, zu entwickeln“)
Nachgelagerte Phasen sind sowieso noch ergebnislos
Ansammlung von „undone work“
16. Aber...
Scrum ist ein Management-Framework
für die gesamte Produktentwicklungskette.
Der reine Einsatz in der Software-Entwicklung
bringt nie den gewünschten Effekt!
17. Ja, aber...
...wie soll das in der Medizintechnik
funktionieren bei all den regulatorischen
und normativen Rahmenbedingungen?
19. Fragestellung in der Medizintechnik
Was können wir tun, um
normkonform nach jeder Iteration zu
liefern?
Risikomanagement
Usability
Dokumentation
Architektur
Verifikation
Validierung
Lösung:
Transition der
„Definition of
Done“
20. Transition der Definition of Done
vereinfachte Darstellung
vor den Sprints in den Sprints nach den Sprints
Anforderungen
Analyse
Architektur
Entwicklung
Verifikation
Risikomanagement
Usability
Dokumentation
Validierung
Deployment
21. Risikomanagement
14971
Risikoanalyse iterativ-inkrementell
während des Sprints
zu jeder Anforderung bzw. User
Story durchführen
abgeleitete
Risikominderungsmaßnahmen
durch den Product Owner in das
Product Backlog aufnehmen
umgesetzte
Risikominderungsmaßnahmen
während des Sprints verifizieren
Erstellung einer initialen
Risikomanagementakte kann im
ersten Sprint durchgeführt
werden (oder kurz davor)
22. Qualitätsmanagement
13485
Die gesamte Einführung eines
QM-Systems kann mit Scrum
bzw. parallel zu einer Scrum-
Einführung geschehen.
Die Beschreibung des
auditierbaren, dokumentierten
Entwicklungsprozesses kann
während der Sprints
vervollständigt werden.
„Repräsentiert die Erfordernisse
für ein umfassendes
Managementsystem für das
Design und die Herstellung von
Medizinprodukten.“ *
Erstellung einer initialen Scrum-
Prozessbeschreibung kann vor
dem ersten Sprint durchgeführt
werden
http://de.wikipedia.org/wiki/ISO_13485
23. Software-Life-Cycle
62304
Architektur- und SW-Design-
Dokumentation kann während
des Sprints entstehen (erste
Artefakte bereits im Sprint
Planning 2)
Verifikation/Validierung
geschieht im Sprint durch
Abnahme über User
Acceptance Criterias
Anforderungen und User
Stories entstehen kurz vor
dem Sprint, in dem sie
umgesetzt werden.
Verifikation geschieht im Sprint
durch automatisierte und
manuelle Tests
24. Usability
62366
Übersetzungen und
Lokalisierung von Inhalten
können während des Sprints
durchgeführt werden.
Der Nutzen für den
Anwender wird im Sprint
Review Meeting bewertet und
erzeugt schnelles Feedback.
Die Norm empfiehlt ein agiles,
interativ-inkrementelles
Vorgehen, um hohe
Gebrauchstauglichkeit für den
Anwender zu erreichen.
Der Anwender kann direkt im
Sprint Planning Meeting seine
Wünsche an das Produkt
einbringen.
25. Transition der Definition of Done
erweiterte Darstellung
vor den Sprints in den Sprints nach den Sprints
Anforderungen
Analyse
Architektur
Entwicklung
Verifikation
Risikomanagement
Usability
Dokumentation
Deployment
Validierung
26. Fazit
Schnelle Lieferung ist durch agile Methoden
auch in der Medizintechnik realisierbar.
anwendbare Methode:
Transition der Definition-of-Done
dafür notwendig:
✓
✓
!
Umdenken in der gesamten Organisation.
Weg von lokaler Optimierung und Abteilungsgrenzen,
hin zu „Optimize the Whole“ und gemeinsamen Zielen.
27. Vielen Dank!
Marc Bless
Coach und Berater für
Agile Methoden in der Medizintechnik
marc.bless@consanis.de