IT works. Agile und modellgetriebene Projekte. Voraussetzungen für ein erfolgreiches Zusammenspiel im verteilten Projektumfeld

Transkript

1 Agile und modellgetriebene Voraussetzungen für ein erfolgreiches Zusammenspiel im verteilten Projektumfeld IT works. 17. GI-WIVM Workshop Stuttgart, 12./ Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

2 Agenda Einleitung Agilität im verteilten Team MDSD im verteilten, agilen Team Fazit Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

3 Einleitung Modellgetriebene Softwareentwicklung (MDSD) Modellierung in der Anwendungsentwicklung "state of the art" Ausreichend formale Modelle dienen der automatisierten Überführung in Quellcode Trend geht zu domänenspezifisch angepassten Modellierungssprachen (DSL) Modellgetriebener Softwareentwicklung wird ein Beschleunigungs- und Qualtitätsfaktor für die Softwareentwicklung zugeschrieben (Völter/Stahl) Problem: relativ hoher Initialaufwand für Definition der Domänenarchitektur, der DSL, Tansformationsregeln, etc. Agile Vorgehensmodelle Abstimmung lauffähiger Teilergebnisse steht im Vordergrund Kommunikation und Rückkopplung wichtiger Faktor für den rfolg Modellierung als Kommunikationsmittel spielt oft eine untergeordnete Rolle (nur bei FDD explizit beschrieben) Zunehmend verteilte/verstreute Teams Formale Vorgehensmodelle mit ausgeprägten Verwaltungsaspekten scheinen besser geeignet. Hier lässt sich auch MDSD gut integrieren. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

4 ABER: Agile und modellgetriebene Agilität im verteilten Team Verteilung von Mitarbeitern bedeutet Distanz zwischen den Mitarbeitern (räumlich, zeitlich, kulturell und sprachlich) Die meisten global agierenden Unternehmen sind auf mehrere Standorte verteilt, diese werden aber zentral kontrolliert und koordiniert (Stufe II nach E. Carmel) Auch verteilte Softwareprojekte werden oft zwar verteilt entwickelt, das Projektmanagement erfolgt jedoch zentral. Inkompatibilität zwischen Agilität und verteilten Teams? Herausforderung: Trotz Distanz Nähe und Vertrauen schaffen! Kritik: "Da hohe Aufgabenabhängigkeiten und Kommunikation von Angesicht zu Angesicht erforderlich sind, sind sie [die agilen Methoden] für Offshore- nicht geeignet. (Sakthivel) Team benötigt für den Erfolg ein gemeinsames Verständnis über eine Vision, Werte, Regeln In der Betonung der Kommunikation / Interaktion liegt der Vorteil der agilen Methoden im verteilten Projektumfeld! (J. Eckstein) Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

5 Agilität Prinzipien im verteilten Projekt Stelle den Kunden durch frühzeitige und regelmäßige Lieferungen nützlicher Software zufrieden Zusammenarbeit der Standorte wichtig Berücksichtigung der Anforderungen des Kunden Stehe veränderten Anforderungen positiv gegenüber, selbst wenn sie in der Entwicklung spät auftreten Hoher Koordinationsaufwand über die Standorte hinweg Fachexperten und Entwickler arbeiten zusammen Räumliche Distanz verhindert Zusammenarbeit (verstärkt durch Kultur und/oder Zeitzonen) Lauffähige Software ist das wichtigste Fortschrittsmaß Releasebündelung über Standorte hinweg oft schwieriger Herausforderung: nicht mehrere einzelne Systeme über Standorte hinweg zusammenbringen, sondern ein kohärentes System Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

6 Agilität Prinzipien im verteilten Projekt (Forts.) Ständiges Augenmerk auf technische Güte und Design Tendenz: Häufig wird das Qualitätsmanagement ebenso wie das Projektmanagement zentral an einem Standort angesiedelt Alle Standorte müssen für Qualität sorgen Teamreflektion und anpassung Gelegenheit zur Reflektion über die Arbeitsweise ist Bestandteil aller agilen Methoden Teamreflektionen über Standorte hinweg ermöglichen, damit auch die Zusammenarbeit verbessert werden kann. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

7 Rollen im verteilten Team Architekt Hauptaufgabe: Konzeptionelle Integrität der Anwendung Zentrale Rolle in der Umsetzung der agilen Prinzipien Konzeptionelle Integrität ermöglicht geordnete Reaktion auf Veränderungen, stellt ein lieferbares kohärentes System sicher Product Owner (vgl. Scrum) Stellvertreter des Kunden, Ansprechpartner für Featureteams Product Owner-Team, das an den verteilten Standorten als Ansprechpartner fungiert Projektleiter In großen und verteilten n für die organisatorischen Aspekte notwendig Politik und Unterstützung des Teams innerhalb und außerhalb des Unternehmens Ansprechpartner für persönliche Belange der Projektmitarbeiter Budget-Verantwortung und Controlling Wichtig: Projektleitung und Team müssen Teile der gleichen Projektkultur sein! Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

8 Standorte verbinden Je mehr Standorte zusammenarbeiten, desto schwieriger wird es, die Teams in Verbindung zu halten und das Projekt zum Erfolg zu führen. J.Eckstein: Ein Projekt sollte nie über mehr als drei Standorte verteilt sein. E. Carmel: Reduzieren Sie die Zahl der Projektstandorte so weit wie möglich. Strategien Projektmitglieder als Kommunikationsvermittler (bei S. Ambler "Reisende") verbreiten Informationen unter den Projektteams Botschafter in jedem Projektteam etablieren. Hierdurch ist jeder Standort überall vertreten. Pflege sozialer Kontakte fördern (gemeinsame Projektfeiern, Vorstellung von Teammitgliedern im Projekt-Wiki, etc.) Kommunikationsinfrastruktur mit unterschiedlichen Werkzeugen bereitstellen (Audio/Video, Instant Messaging, Wikis und andere Kollaborationsplattformen) Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

9 Release-Lieferungen "Liefere Software häufig, alle 2 Wochen bis alle 2 Monate, aus, wobei die Präferenz auf kürzeren Zeitabständen liegen sollte. " (Agiles Manifest) Iteration ist der "Herzschlag" des Projekts (J. Eckstein) Im verteilten Projekt gleicher Rhythmus für das ganze Projekt Erfordert Synchronisation der Iterationen über alle Standorte hinweg Evtl. Release-Interation notwendig Erstellung des Release an einem Standort bündeln Stellvertreter der Standorte hinzuziehen Voraussetzung für Release-Lieferung: die Integration Integration sollte zunächst an einem Standort funktionieren. Erst danach das Team verteilen. Grund: Infrastrukturprobleme erhöhen die Komplexität zusätzlich Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

10 MDSD und agile Prinzipien Stelle den Kunden durch frühzeitige und regelmäßige Lieferungen nützlicher Software zufrieden MDSD startet i.d.r. mit der Definition der Domänenarchitektur und der Ableitung der Transformationsregeln zeitlicher Vorlauf notwendig Domänenarchitektur wird aus Referenzimplementierung abgeleitet Referenzimplementierung als erste Lieferung verstehen und für Feedback nutzen Stehe veränderten Anforderungen positiv gegenüber, selbst wenn sie in der Entwicklung spät auftreten Refactoring kann auf Modelle, Plattformen, Transformationen und den manuell erstellten Code angewendet werden. Fachliche Änderungen können schneller und konsistent umgesetzt werden. Optimale Unterstützung auch für Architektur-Refactoring. Fachexperten und Entwickler arbeiten zusammen Kann durch die Verwendung einer fachlich motivierten Modellierungssprache (DSL) noch intensiviert werden Fehler werden schneller erkannt, da sich Fachexperte und Entwickler auf dem selben Abstraktionsniveau befinden Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

11 MDSD und agile Prinzipien (Forts.) Lauffähige Software ist das wichtigste Fortschrittsmaß Grundsätzlich wird das Erstellen von lauffähiger Software durch MDSD beschleunigt (Stahl/Völter), da wiederkehrende Implementierungsaufgaben automatisiert sind. Verzahnt man die Entwicklung der Domänenarchitektur mit der Anwendungsentwicklung, kann auch das Ziel früher lauffähiger Lieferungen erreicht werden. Ständiges Augenmerk auf technische Güte und Design Modellierungsvorgaben und standardisierte Implementierung = Einschränkung der Freiheit? MDSD stellt durch die Lenkung der Entwicklung hohe Qualität sicher Teamreflektion und anpassung Keine Auswirkung durch MDSD Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

12 Domänenarchitektur Aggregation des Metamodells einer Domäne, einer Plattform und der dazu passenden Transformationsregeln und Werkzeuge (Stahl/Völter) Entwicklung der Domänenarchitektur parallel zur Anwendungsentwicklung Teilprodukt "Referenzimplementierung" als Basis für die Ableitung der Transformationen Referenzimplementierung hat höheren Anspruch als ein reiner Prototyp Referenzimplementierung und Referenzmodell zeigen die Umsetzung der zur Domäne gehörenden Modellierungssprache Überwachung der konzeptionellen Integrität muss auf die Domänenarchitektur (und abgeleitete Artefakte) ausgedeht werden. Ggf. eigenes Team von Architekten (spezialisiert auf Metamodelle und Transformationen) Arbeiten in Abstimmung mit den Architekten der Anwendung Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

13 Aufgabenverteilung Entfernte Teams / ohne direkten Kundenkontakt Entwicklung von Domänenarchitektur und Transformationsregeln sind als Aufgabe gut separierbar. Kundennahe Teams Fachlich motivierte Modellierungssprachen erhöhen die Qualität in der Aufnahme der Anforderungen. Unabhängig von der Lokation Referenzimplementierung und Referenzdesign tragen zum allgemeinen Verständnis der Anwendungsarchitektur bei. Höhere Abstraktion der fachlich motivierten Modellierungssprache ist geeignet, durch das Modell bei allen Projektteams das Gesamtbild besser zu vermitteln. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

14 Release und Integration MDSD bringt zusätzliche Komplexität in den Prozess der Abstimmung der Iterationen in die Integration in die Bereitstellung der Releases Zusätzliche Komplexität durch die Verteilung von Aufgaben erschwert das Ziel des "gemeinsamen Herzschlags" Integration wird durch zusätzliche Artefakte der modell-getriebenen Softwareentwicklung komplexer. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

15 Fazit 40% der in einer Studie befragten Unternehmen setzen eine oder mehrere agile Methoden ein (Parsons). Als agile Techniken mit dem größten Nutzen hinsichtlich Qualität, Kundenzufriedenheit und Produktivität wurden genannt: Die enge Zusammenarbeit mit dem Kunden Refactoring Zusammenarbeit mit dem Kunden kann durch die Konzepte einer fachlich motivierten Modellierungssprache zusätzlich unterstützt werden. Die Produktivität und Qualität wird durch die automatisierte Erzeugung von Quellcode erhöht. Sie ist Garant für eine einheitliche und nachvollziehbare Implementierung. Refactoring wird durch MDSD wirksam unterstützt und bringt zusätzliche Effektivität. Modellgetriebene Softwareentwicklung kann dabei helfen, agile Techniken zu skalieren. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

16 Vielen Dank für Ihre Aufmerksamkeit. Haben Sie noch Fragen? Kontakt M.Sc. Dipl. Wirtschaftsinformatiker (FH) Klaus Mairon Deißlinger Str Villingen-Schwenningen IT works. Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

17 Literatur (1) Ambler, S.: Bridging the Distance. In Dr. Dobb s Portal, (2) Ambler, S.: Agile Modeling. Effective Practices for extreme Programming and the Unified Process. Wiley Computer Publishing, (3) Ambler, S.: THE OBJECT PRIMER, 3rd Edition: Agile Model-Driven Development with UML 2.0. Cambridge University Press, (4) Bleek, W., Wolf, H.: Agile Softwareentwicklung. Werte, Konzepte und Methoden. dpunkt.verlag, (5) Carmel, E.: Global Software Teams. Collaborating across Borders and Time Zones. Prentice Hall, (6) Carmel, E., Tjia, P.: Offshoring Information Technology. Sourcing and Outsourcing to a Global Workforce. Cambridge University Press, (7) Coad, P., et. al: Java Modeling in Color with UML. Enterprise Components and Process. Prentice Hall International, (8) Eckstein, J.: Agile Softwareentwicklung mit verteilten Teams. dpunkt.verlag, (9) Frankel, D.: Model Driven Architecture. Applying MDA to Enterprise Computing. John Wiley & Sons, Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./

18 Literatur (Forts.) (10) Parsons, D., et. al.: The Impact of Methods and Techniques on Outcomes from Agile Software Development Projects. In IFIP International Federation for Information Processing, Volume 235. Organizational Dynamics of Technology- Based Innovation: Diversifying the Research Agenda, S (11) Stahl, T., Völter, M.: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management. dpunkt.verlag, (12) Sakthivel, S.: Managing Risk in Offshore Systems Development. In Communications of the ACM, Vol. 50, S , (13) Yourdon, E.: Outsource. Competing in the Global Productivity Race. Prentice Hall, Klaus Mairon 17. GI-WIVM Workshop Stuttgart, 12./