![© by oose GmbH Agilität im starren Umfeld „ Hart, aber agil“ Open Change, Stuttgart 13. Juli 2011 Tim Weilkiens Geschäftsführer [email_address]](https://image.slidesharecdn.com/hartagil-weilkiens-openchange2011-110716033514-phpapp01/85/Agilitat-im-starren-Umfeld-1-320.jpg)
![© by oose GmbH Agilität im starren Umfeld „ Hart, aber agil“ Open Change, Stuttgart 13. Juli 2011 Tim Weilkiens Geschäftsführer [email_address]](https://image.slidesharecdn.com/hartagil-weilkiens-openchange2011-110716033514-phpapp01/75/Agilitat-im-starren-Umfeld-1-2048.jpg)
Hochgeladen vonoose
Agilität im starren Umfeld
Das Dokument beschreibt die Herausforderungen und Chancen der Agilität im regulierten Umfeld, insbesondere in der Softwareentwicklung. Es hebt hervor, dass agile Methoden wie Scrum und Kanban, obwohl sie ursprünglich außerhalb der Softwaredisziplin entwickelt wurden, in starren, regulierten Projekten erfolgreich eingesetzt werden können. Die Analyse von Widerständen und die Bedeutung direkten Kundenkontakts sind entscheidend für den Projekterfolg.
Weitere ähnliche Inhalte
Ähnlich wie Agilität im starren Umfeld
Agilität im starren Umfeld
- 1. © by ooseGmbH Agilität im starren Umfeld „ Hart, aber agil“ Open Change, Stuttgart 13. Juli 2011 Tim Weilkiens Geschäftsführer [email_address]
- 2. oose Innovative InformatikGmbH – Erfahrung nutzen. Ziele erreichen. Gründung: 1998 durch Bernd Oestereich 35 Mitarbeiter International anerkannte Experten und Buchautoren kundenspezifisch Firmensitz: Hamburg Beratung, Coaching, Workshops, Training Maßgeblich an der Entwicklung führender Standards beteiligt Erfahrung nutzen. Ziele erreichen.
- 3. „ Hart undstarr“ © by oose GmbH „ Hart“ = Nicht nur Software „ Starr“ = Viele Regulatorien
- 4. Hart und starr......und agil? © by oose GmbH
- 5. © by ooseGmbH
- 6. © by ooseGmbH
- 7. © by ooseGmbH
- 8. Widerspruch? Engel? Teufel?© by oose GmbH
- 9. Entwicklungstechniken müssen derKomplexitätssteigerung folgen © by oose GmbH Zeit Komplexität, Time-to-Market, Qualität, Kostenreduktion Systeme Markt Agilität Modellierung Hebel: Innovation der Entwicklungstechniken Entwicklungstechniken
- 10. © by ooseGmbH Quelle: agilemanifesto.org !
- 11. Scrum – einagiles Vorgehen im Überblick © by oose GmbH Sprint (timeboxed) Daily-Scrum Review Retrospektive Sprint-Planung
- 12. Agile Techniken im4-Schichtenmodell © by oose GmbH
- 13. Antipattern: 4-Iterationen-Modell ©by oose GmbH Analyse Design Implementierung Test
- 14. Phasen iterativer Entwicklung© by oose GmbH Architektur Durchstich Architektur-rahmen Teamausbau, Realisierungs-rahmen klar Realisierung Maximaler Nutzen hergestellt Nutzen-bewertung Iterative Realisierung von Features Realisierungs-optionen erarbeiten Bewältigung von Risiken Teststrategie Vorbereitung Entwicklung Produktvision / Big Picture Stakeholder Risiken Makro-schätzung / Wirtschaft-lichkeit Release-planung Entscheidung über Projekt-durchführung Abschluss Lernende Organisation Formaler Abschluß Schlußpunkt im Teamprozess Projekt abgeschlossen
- 15. Iterative Systementwicklung –Beispiel Zeitstrahl © by oose GmbH Die Iterationen müssen nicht gleich lang sein und können auch innerhalt einer Disziplin zeitlich variieren.
- 16. Problem: Das IterationsergebnisAm Ende eines Sprints steht immer eine lauffähige, getestete, inkrementell verbesserte Software (Quelle: Wikipedia). © by oose GmbH Am Ende eines Sprints steht immer ein lauffähiges, getestetes, inkrementell verbessertes System. ? Zweck: Feedbackfähigkeit (nicht Lauffähigkeit) Am Ende einer Iteration steht immer ein getestetes, inkrementell verbessertes System, das dem Kunden ermöglicht, Feedback zu geben.
- 17. Urspr ünge vonScrum und Kanban liegen außerhalb der Softwaredisziplin Scrum (1986): Methode zur Produkt-Entwicklung Kanban (1947): Methode zur Produktionsablaufsteuerung (Serienproduktion) Scrum in der IT: Peter DeGrace, Leslie Hulet Stahl (1990) Ken Schwaber, Mike Beedle, Jeff Sutherland Kanban in der IT: David Anderson 2007 © by oose GmbH Rückweg der agilen Vorgehen in die Systementwicklung ist schwierig.
- 18. „ Agile Projektedokumentieren nicht“ © by oose GmbH Dokumentation in agilen Projekten ist kein Widerspruch!
- 19. Das Produkt ©by oose GmbH Die Dokumentation ist Teil des Produkts und wird ebenso entwickelt wie die Software und Hardware. Produkt
- 20. Agilität und Projekterfolghängen stark zusammen! © by oose GmbH Agile Projekte Klassische Projekte Erfolgreich Nicht erfolgreich Erfolgreich Nicht erfolgreich Quelle: oose-Projektmanagementstudie, http://www.oose.de/pm-studie, 2009
- 21. Stärkster Einfluss aufProjekterfolg: Direkter Kundenkontakt © by oose GmbH mehrmals wöchentlich oder kontinuierlich wöchentlich monatlich bei Lieferungen/Planungsaktualisierungen bei Lieferungen zu Projektbeginn/-ende oder seltener
- 22. Woher kommt derWiderstand? © by oose GmbH Skeptiker (ca. 40%) Gegner (ca. 15%) Bremser (ca. 40%) Befürworter (ca. 5%) Befürworter ins Boot holen Skeptiker/Bremser überzeugen Gegner ignorieren Akzeptanzmatrix (nach Mohr, Woehe, Diebold, 1998) Einschätzung persönlicher Risiken hoch niedrig Einschätzung sachlicher Risiken niedrig
- 23. Veränderung bewegt ©by oose GmbH Schock Eigene Erwartungen scheinen nicht erfüllbar Verneinung Selbstschutz durch Verleugnung und/oder Selbstüberschätzung Einsicht Veränderung betrifft mich, Unsicherheit Akzeptanz Veränderung ist da, alte Muster aufgeben „ Tal der Tränen“ Ausprobieren Neue Muster bringen Erfolg und Misserfolg Bewusstsein Ursache-Wirkung von Mustern und Erfolgen Integration Erfolgsmuster werden unbewusst ausgeführt Wahrgenommene Kompetenz Zeit
- 24. Agiles Projektmanagement fürSysteme im reguliertem Umfeld (APS) Ziel der Arbeitsgruppe APS ist es sich über Erfahrungen aus der Praxis zum agilen Projektmanagement für Systeme im regulierten Umfeld auszutauschen. Geplante Ergebnisse sind Best-Practices , um Hindernisse zu beseitigen und agile Techniken erfolgreich im reguliertem Systementwicklungsumfeld einzusetzen. © by oose GmbH Webseite: http://www.gfse.de | Arbeitsgruppen | APS
- 25. (Be-)Merkenswertes Gängige agileVorgehen haben ihren Ursprung außerhalb der Software-Welt. Agilität und „harte und starre Projekte“ sind kein Widerspruch. Einzelne agile Techniken machen Projekte erfolgreicher. Agilität erfüllt keinen Selbstzweck. Agilität wird die Projektmanagementlandschaft nachhaltig verändern. Widerstände verstehen und aushalten (Veränderungskurve, Akzeptanzmatrix) © by oose GmbH
- 26. © by ooseGmbH www.oose.de – Vom Wissen zum Können Beratung und Training Kontakt: Tim.Weilkiens@oose.de
Hinweis der Redaktion
- #2 Kürzere Entwicklungszeiten, höhere Kundenzufriedenheit, mehr Transparenz sind nur einige Ziele, die agile Entwicklungsmethoden versprechen. Scrum, Kanban, XP & Co. werden erfolgreich verbreitet eingesetzt. Aber starre Rahmenbedingungen wie sie häufig im Embedded-Umfeld auftreten, wie z.B. Hardware-Entwicklung mit langen Entwicklungszeiten, Auflagen von Regulierungsbehörden wie der FDA in der Medizintechnik oder hoher Dokumentationszwang sind schnell K.o.-Argumente gegen die Einführung agiler Methoden. Scheinbar sind sie nur für gewöhnliche Softwareprojekte geeignet. Ich zeige Ihnen, dass Agilität und starre Rahmenbedingungen kein Widerspruch sind und kläre Missverständnisse auf. Biographie Tim Weilkiens Als Geschäftsführer der oose Innovative Informatik GmbH schaffe ich unseren Mitarbeitern Raum, Ihre innovativen Ideen umzusetzen. Ich entleere meinen Kopf, indem ich mein Wissen in Büchern, Artikeln und Vorträgen festhalte. Das schafft mir Freiraum, mich mit neuen Ideen und Konzepten auseinanderzusetzen. Best Practices manifestiere ich in Standards bei der OMG, wo ich aktiv z.B. die SysML, die UML oder die Zertifizierungsprogramme OCEB und OCSMP mitgestalte. Privat motivieren mich 42,195 km, Ziele zu erreichen.
- #3 Erfahrung nutzen. Ziele erreichen. Als unseren Kunden bef ä higen wir Sie zur selbst ä ndigen Entwicklung guter und innovativer Systeme, Gesch ä ftsprozesse, Organisationen und Managementverfahren. Wir unterst ü tzen, beraten und begleiten Sie und Ihre Mitarbeiter, transferieren dabei Know-how und Erfahrungswissen und bef ä higen Sie auf diese Weise, systematisch eine eigenst ä ndige Verbesserung Ihrer Arbeit zu erzielen. Wir sto ß en Ver ä nderungen in Ihrem Unternehmen oder Projekt an, geben Impulse, zeigen Ihnen bew ä hrte L ö sungsans ä tze, w ü rdigen die bei Ihnen vorhandene Situation und leiten Sie zu einer erfolgreichen Weiterentwicklung an. Wir machen es einfach. Projekte scheitern nicht an einzelnen oder nur rein technischen Problemen, sondern an der Verstrickung von technischen, organisatorischen, personellen, sozialen, kommunikativen, wirtschaftlichen und interessenspolitischen Herausforderungen und Risiken. Was Sie hier wahrscheinlich nicht w ü nschen, sind Scheuklappen und Fachidioten. Wer nur den Hammer kennt, f ü r den sieht bekanntlich alles nach Nagel aus. Erfolgreiches Handeln bedarf in diesem Kontext einer ü bergreifenden und umfassenden Qualifikation, jedoch ebenso der F ä higkeit, die entscheidenden und erfolgreich ver ä nderbaren Aspekte zu erkennen. Viele Standards sind ausufernd und ihre praktische Anwendung ist h ä ufig unn ö tig kompliziert. Wir kennen die typischen Situationen und M ö glichkeiten Ihres gesch ä ftlichen Alltages und verdichten neue Standards gleich auf die praxisrelevante Essenz. Eine Herausforderung, die uns auch noch Spa ß macht. Erg ä nzen Sie Ihr Know-how mit unseren Experten. Nutzen Sie unsere Erfahrung und Kompetenz, um komplexe Sachverhalte auf die f ü r die Praxis wirklich wichtigen Faktoren zu reduzieren. Es ist nicht einfach, etwas einfach zu machen - es bedarf der geschickten Abstraktion vom Komplexen zum Wesentlichen.
- #16 Bei der Systementwicklung ist die Systemebene der Auftraggeber für Segmente, Hardware- und Software-Einheiten. Mit den Einheiten werden Funktionalitäts-Ziele abgestimmt, die die Einheiten bis zu dem Zeitpunkt der geplanten Integration der verschiedenen Einheiten-Ergebnisse auf Systemebene erreichen sollen. Hierzu dienen Analysevorgaben, die immer im voraus erarbeitet werden. Dabei ist für die Mitarbeiter auf Systemebene wichtig, auf der Abstraktionsebene des Systems mit der Analyse aufzuhören, und die Detailanalysen den jeweiligen Einheiten zu überlassen. Auf Systemebene sollte möglichst häufig integriert werden. Da es hier um die Integration von Mechanik, Hardware und Software geht, wird dies meistens nicht so häufig möglich sein, wie bei reinen Softwareprojekten, bei denen nach jeder Software-Iteration auch auf Gesamtprojektebene integriert wird.