Modellierung im Spannungsfeld von agilen Vorgehensweisen (z.B. SCRUM)

2.927 Aufrufe

Veröffentlicht am

Agile Projekte modellieren nicht! Modellierung ist nicht agil! Äpfel sind keine Orangen!

In meinem Vortrag beleuchte ich die unterschiedlichen Facetten dieser These, um den Kern des Widerspruchs aufzudecken.

Ich höre häufig, dass Modellierung nicht zum agilen Vorgehen passt. Aber ist das wirklich so? Was ist im Kontext dieser These mit Modellierung gemeint und was ist der Konflikt mit der Agilität? Geht es um Scrum und UML oder um Agilität und Modellierung im allgemeinen?

Viele Fragen, die ich mit Ihnen diskutieren möchte. Natürlich erfahren Sie auch meine Meinung dazu und ich möchte Sie in die Lage versetzen, nach dem Vortrag eine klare Stellung zu der These beziehen zu können.

Veröffentlicht in: Technologie, Business
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.927
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
324
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Agile Projekte modellieren nicht! Modellierung ist nicht agil! Äpfel sind keine Orangen! In meinem Vortrag beleuchte ich die unterschiedlichen Facetten dieser These, um den Kern des Widerspruchs aufzudecken. Ich höre häufig, dass Modellierung nicht zum agilen Vorgehen passt. Aber ist das wirklich so? Was ist im Kontext dieser These mit Modellierung gemeint und was ist der Konflikt mit der Agilität? Geht es um Scrum und UML oder um Agilität und Modellierung im allgemeinen? Viele Fragen, die ich mit Ihnen diskutieren möchte. Natürlich erfahren Sie auch meine Meinung dazu und ich möchte Sie in die Lage versetzen, nach dem Vortrag eine klare Stellung zu der These beziehen zu können.
  • 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.
  • Werte, z.B.: Mut Unmittelbare Rückmeldung Einfachheit Praktiken, z.B.: Timeboxing Kunde im Team integrieren Retrospektiven Stehungen Teamräume Kontinuierliche Integration ... Die Werte unterstreichen die Bedeutung der Eigenschaft „agil“. Beispielsweise steht der Wert „Mut“ für den Mut, unbrauchbare Artefakte zu verwerfen statt immer wieder um das Defizit herumzuarbeiten. Oder den Mut auch in einer späten Projektphase, Änderungen zuzulassen. Beides bedeutet ein hohes Maß an Beweglichkeit.
  • „ Agile Projekte dokumentieren nicht!“ Einige verwenden es als Vorwurf und sehen darin ein Defizit, für andere ist es das Gute an agilen Prozessen: „Agile Projekte dokumentieren nicht!“. Oder zumindest nicht richtig. Statt echte Dokumente mit Versionshistorie und Freigaben, werden gelbe Zettel beschriftet und an Wänden im Raum verteilt. Verlassen wir die subjektive Ebene. In der Tat werden in agilen Projekten meist weniger Dokumente erstellt und gerne Aufgaben- und Featurelisten mit gelben Zetteln an Planungswänden verwaltet. Einfachheit und ständige Visualisierung des Projektfortschritts sind die agilen Werte und Techniken, die hinter der Gelben-Zettel-Technik stehen.
  • MBSE-Online-Summit Proceeding II 2009
  • Modellierung im Spannungsfeld von agilen Vorgehensweisen (z.B. SCRUM)

    1. 1. © by oose GmbH Modellierung im Spannungsfeld von agilen Vorgehensweisen FG Modellierung, Erlangen 05. Mai 2011 Tim Weilkiens Geschäftsführer [email_address]
    2. 2. oose Innovative Informatik GmbH – 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 © by oose GmbH Erfahrung nutzen. Ziele erreichen.
    3. 3. Und wer sind Sie? <ul><li>IT-Entwicklungsprojekte oder andere? </li></ul>© by oose innovative Informatik GmbH Eher agil oder eher klassisch?
    4. 4. © by oose GmbH Gibt es einen Konflikt zwischen Modellierung und Agilität? Welche Konflikte sehen Sie? Konflikt: Agile Projekte modellieren nicht!
    5. 5. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    6. 6. © by oose GmbH
    7. 7. Die Sorgen der Projekte… <ul><li>Der Markt fordert immer komplexere Systeme und gleichzeitig kürzere Time-to-Market-Zeiten, hohe Qualität und abnehmende Kosten . </li></ul>© by oose GmbH
    8. 8. Entwicklungstechniken müssen der Komplexitätssteigerung folgen © by oose GmbH Zeit Komplexität, Time-to-Market, Qualitä, Kostenreduktion Systeme Markt Hebel: Innovation der Entwicklungstechniken Entwicklungstechniken
    9. 9. Agilität und Modellierung sind Schlüsseltechnologien <ul><li>Komplexität </li></ul><ul><li>Modellierung adressiert die Komplexität des Produkts </li></ul><ul><li>Agilität adressiert die Komplexität der Entwicklung </li></ul>© by oose GmbH <ul><li>Qualität </li></ul><ul><li>Richtig angewendet führen Modellierung und Agilität zu besserer Qualität </li></ul><ul><li>Time-to-Market </li></ul><ul><li>Richtig angewendet bewirken Modellierung und Agilität kürzere Entwicklungszeiten </li></ul><ul><li>Kostenreduktion </li></ul><ul><li>Richtig angewendet führen Modellierung und Agilität zu geringeren Entwicklungskosten. </li></ul>
    10. 10. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    11. 11. © by oose GmbH <ul><li>Wann ist ein Projekt agil? </li></ul><ul><li>Ist Agilität = SCRUM? </li></ul><ul><li>oder steckt da mehr dahinter? </li></ul><ul><li>… </li></ul>
    12. 12. © by oose GmbH Quelle: agilemanifesto.org
    13. 13. Scrum – ein agiles Vorgehen im Überblick © by oose GmbH Sprint (timeboxed) Daily-Scrum Review Retrospektive Sprint-Planung
    14. 14. Agile Techniken im 4-Schichtenmodell © by oose GmbH
    15. 15. oose-Projektmanagementstudie <ul><li>212 vollständig abgegebene Fragebögen </li></ul><ul><li>Laufzeit: Dezember 2008 – Januar 2009 </li></ul><ul><li>Jeder Fragebogen enthält 108 Fragen und bewertet ein erfolgreiches und ein nicht-erfolgreiches Projekt </li></ul><ul><li>Nach Plausibilitätsprüfungen sind 130 Fragebögen mit 260 bewerteten Projekten in die Auswertung eingeflossen. </li></ul>© by oose innovative Informatik GmbH <ul><ul><li>www.oose.de/pm-studie </li></ul></ul><ul><li>Was können agile und klassische Projekte voneinander lernen? </li></ul><ul><li>Welche Verfahren tragen wirklich zum Projekterfolg bei? </li></ul>Project Management Insitute Munich Chapter Project Management Insitute Frankfurt Chapter Local Group Hamburg
    16. 16. Was ist in dieser Studie mit Agilität gemeint? <ul><li>Selbsteinschätzung der Teilnehmer  98 agile Projekte </li></ul><ul><li>Unsere Kriterien für Agilität im Rahmen der Auswertung der Studie  53 agile Projekte (Gegenprobe) </li></ul><ul><ul><li>Teamgrößen von 2 bis max. 12 Personen </li></ul></ul><ul><ul><li>Iteratives Vorgehen mit einer max. Iterationsdauer von 8 Wochen </li></ul></ul><ul><ul><li>Mindestens bei den Lieferungen bestand direkter Kundenkontakt </li></ul></ul><ul><ul><li>Mindestens zu jeder Lieferung wurde lauffähige Software erstellt </li></ul></ul><ul><ul><li>Refactoring fand explizit statt </li></ul></ul><ul><ul><li>Das Vorgehensmodell war weder Wasserfall noch V-Modell-97 oder älter </li></ul></ul>© by oose innovative Informatik GmbH
    17. 17. Agilität und Projekterfolg hängen stark zusammen! © by oose GmbH Agile Projekte Klassische Projekte Erfolgreich Nicht erfolgreich Erfolgreich Nicht erfolgreich Doch kaum ein agiles Projekt hat das entsprechende Lehrbuch weitgehend vollständig umgesetzt!
    18. 18. Stärkster Einfluss auf Projekterfolg: Direkter Kundenkontakt © by oose GmbH mehrmals wöchentlich oder kontinuierlich wöchentlich monatlich bei Lieferungen/Planungsaktualisierungen bei Lieferungen zu Projektbeginn/-ende oder seltener
    19. 19. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    20. 20. © by oose GmbH <ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Ist Modellierung = UML? </li></ul><ul><li>… </li></ul>
    21. 21. Definition Modellbasiertes Systems Engineering (MBSE) Modellbasiertes Systems Engineering (MBSE) ist der Entwurf, die Spezifikation und die Verifikation und Validierung von komplexen Systemen mit einem Systemmodell , das den gesamten Entwicklungsprozess begleitet und die Quelle der wesentlichen Entwicklungsartefakte zu Anforderungen, Architektur und Test ist. Basierend auf einer Diskussion „Was ist ein Modell“ in der syng-Gruppe: http://www.xing.com/net/syng
    22. 22. Definition Systemmodell <ul><li>Das Systemmodell im Kontext des MBSE ist das Abbild eines realen oder noch zu entwickelnden Systems, wobei mittels Abstraktion nur die für einen definierten Zweck relevanten Attribute berücksichtigt werden. Das Systemmodell ist gekennzeichnet durch die folgenden Eigenschaften: </li></ul><ul><li>Das Modell darf sich aus mehreren Modellen zusammensetzen, muss aber in sich konsistent sein und sich nach außen wie ein einzelnes Modell verhalten. </li></ul><ul><li>Das Modell erlaubt unterschiedliche Sichten auf die Informationen insbesondere grafische Visualisierungen. </li></ul><ul><li>Das Modell ist maschinell auswertbar und liegt in einer abstrakten Syntax vor, die explizit MBSE-Konzepte wie Anforderungen oder System-architekturen unterstützt. </li></ul>Basierend auf einer Diskussion „Was ist ein Modell“ in der syng-Gruppe: http://www.xing.com/net/syng
    23. 23. Intensität der Modellierung Visualisierung der groben Strukturen und Abläufe Ausführbare Modelle MDx Spezifikation des Systems (Analyse und Design) MBSE
    24. 24. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    25. 25. <ul><li>Modellierung und Agilität </li></ul><ul><li>passen gut zusammen! </li></ul>© by oose GmbH
    26. 26. © by oose GmbH Gemeinsame Betrachtung von Modellierung & Agilität macht Defizite in ihrer jeweiligen Anwendung sichtbar.
    27. 27. © by oose GmbH Konflikt? Agile Projekte dokumentieren nicht! Modellierung ist Dokumentation.
    28. 28. „ Agile Projekte dokumentieren nicht“ © by oose GmbH Dokumentation in agilen Projekten ist kein Widerspruch!
    29. 29. Dokumentation ist Teil des Produkts © by oose GmbH Software Hardware Dokumentation Agile Projekte beziehen sich nicht nur auf Software.
    30. 30. Das Iterationsergebnis ohne Software <ul><li>Am Ende eines Sprints steht immer eine lauffähige, getestete, inkrementell verbesserte Software. </li></ul>© 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 stehen immer getestete, inkrementell verbesserte Artefakte, die es dem Kunden ermöglichen, Feedback zu geben.
    31. 31. © by oose GmbH Konflikt? Modellierung führt zu nutzlosen Dokumentenbergen.
    32. 32. Agiles Prinzip: Nicht auf Vorrat produzieren… © by oose innovative Informatik GmbH Erstellen Sie ausschließlich die Artefakte welche unmittelbar verwendet werden in der Menge in der Sie auch verbraucht werden können. Alles andere ist zu diesem Zeitpunkt überflüssig , muss verwaltet und gepflegt werden und wird vielleicht nie gebraucht .
    33. 33. Agiles Requirements Engineering… mit Modellierung © by oose GmbH <ul><li>ARE-Regeln </li></ul><ul><li>Wähle für jede einzelne Anforderung die passende RE-Technik, um sie zu beschreiben. </li></ul><ul><li>Wähle für jede einzelne Anforderung die angemessene Beschreibungstiefe. </li></ul><ul><li>Im Umkehrschluss zu 1) und 2): Verwende kein einheitliches Beschreibungsverfahren für alle Anforderungen. </li></ul><ul><li>Erstelle ausschließlich nur Anforderungsartefakte, die unmittelbar verwendet werden. Alles andere ist zu diesem Zeitpunkt überflüssig, kostet Verwaltungsaufwand und wird in Zukunft vielleicht nie benötigt. </li></ul><ul><li>Priorisiere die Anforderungen nach ihrem Geschäftswert. Die hochprioren Anforderungen werden zuerst umgesetzt. Die Priorität hat keinen Einfluss auf die einzusetzende RE-Technik und Beschreibungstiefe. </li></ul>
    34. 34. TOP-Risiko: Übermodellierung © by oose GmbH 1:1 - Syndrom
    35. 35. <ul><li>&quot;What a useful thing a pocket-map is!&quot; I remarked. </li></ul><ul><li>&quot;That's another thing we have learned from your nation,&quot; </li></ul><ul><li>said Mein Herr, &quot;map-making. But we've carried it much further </li></ul><ul><li>than you. What do you consider the largest map that would be </li></ul><ul><li>really useful?„ </li></ul><ul><li>&quot;About six inches to the mile&quot;. </li></ul><ul><li>&quot;Only six inches!&quot; exclaimed Mein Herr. &quot;We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all! We actually made a map of the country, on the scale of a mile to the mile!&quot; </li></ul><ul><li>&quot;Have you used it much?&quot; I enquired. </li></ul><ul><li>&quot;It has never been spread out, yet,&quot; said Mein Herr: &quot;the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.„ </li></ul><ul><li>- Lewis Carroll, &quot;Sylvie and Bruno Concluded&quot;, chapter XI, The Man in the Moon. </li></ul>© 2009 by oose GmbH „ Und dann kam die beste Idee von allen: Wir haben eine Karte im Maßstab 1:1 erstellt!“ „ Wie nützlich doch Karten sind!&quot; bemerkte ich. „ Was glauben Sie, welches ist der größte, brauchbare Maßstab für eine Karte?“ „ Die Bauern haben sich aber beschwert, da die Karte das Land bedecken und es kein Sonnenlicht mehr geben würde.“ Bauer „ Daher nutzen wir jetzt das Land selbst als Karte und das funktioniert ziemlich gut.“ &quot;What a useful thing a pocket-map is!&quot; I remarked. &quot;That's another thing we have learned from your nation,&quot; said Mein Herr, &quot;map-making. But we've carried it much further than you. What do you consider the largest map that would be really useful?„ &quot;About six inches to the mile&quot;. &quot;Only six inches!&quot; exclaimed Mein Herr. &quot;We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all! We actually made a map of the country, on the scale of a mile to the mile!&quot; &quot;Have you used it much?&quot; I enquired. &quot;It has never been spread out, yet,&quot; said Mein Herr: &quot;the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.„ - Lewis Carroll, &quot;Sylvie and Bruno Concluded&quot;, chapter XI, The Man in the Moon.
    36. 36. TOP-Risiko: Übermodellierung © by oose GmbH 1:1 - Syndrom Reiz - Syndrom
    37. 37. © by oose GmbH
    38. 38. TOP-Risiko: Übermodellierung © by oose GmbH 1:1 - Syndrom Reiz - Syndrom Mutlosigkeit - Syndrom
    39. 39. © by oose GmbH Analyse - Paralyse
    40. 40. © by oose GmbH Konflikt? Agil bedeutet „ohne Prozesse“. Modellierung erfordert Prozesse.
    41. 41. Agiles Software-Projektmanagement © by oose GmbH www.oose.de/apm
    42. 42. © by oose GmbH Konflikt? Modellierung bedeutet Wasserfall.
    43. 43. <ul><li>Modellierung und Agilität </li></ul><ul><li>passen gut zusammen! </li></ul>© by oose GmbH
    44. 44. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    45. 45. Beispiel: Ausschreibungsfähiges Lastenheft für einen Hafenleitstand <ul><li>Unser Kunde </li></ul><ul><li>mittelgroßer europäischer Fährhafen </li></ul><ul><li>viele verschiedene Partner </li></ul><ul><ul><li>Hafen </li></ul></ul><ul><ul><li>Stauereien </li></ul></ul><ul><ul><li>Reedereien </li></ul></ul><ul><ul><li>Terminal für kombinierten Verkehr </li></ul></ul><ul><ul><li>Operateure für kombinierten Verkehr </li></ul></ul><ul><li>IT-Insellösungen </li></ul>© by oose innovative Informatik GmbH 90 Personentage 6 Monate <ul><li>Unser MBRE-Ansatz </li></ul><ul><li>Modellierung aller Anforderungen in einem UML-Werkzeug </li></ul><ul><li>Vollständige Generierung des Lastenhefts als PDF-Dokument </li></ul><ul><li>Umfeld </li></ul><ul><li>Häufiger direkter Kundenkontakt </li></ul><ul><li>Viele unterschiedliche Stakeholder </li></ul><ul><li>Häufige Änderungen der Anforderungen </li></ul>
    46. 46. Beispiel: Angepasster Tool-Dialog © by oose innovative Informatik GmbH
    47. 47. Beispiel: Geschäftsprozesse und Systemanwendungsfälle <ul><li>Akteur entspricht der Bahn im BPMN-Pool </li></ul><ul><li>Nachvollziehbarkeit mittels Trace-Beziehung </li></ul>© by oose innovative Informatik GmbH «trace »
    48. 48. Beispiel: Nichtfunktionale Anforderungen und Rahmenbedingungen © by oose innovative Informatik GmbH
    49. 49. Beispiel: Nichtfunktionale Anforderungen versus Anwendungsfälle © by oose innovative Informatik GmbH
    50. 50. Beispiel: Ergebnis… © by oose innovative Informatik GmbH
    51. 51. Beispiel: Teilsystem APE des E-ELT Images on this slide were produced by ESO Präsentationen und Modell: http://mbse.gfse.de
    52. 52. Modellierungsaufwände <ul><li>Resource usage (1.12.2007 – 9.6.2008) </li></ul><ul><ul><li>four persons </li></ul></ul><ul><ul><li>about 60h administration </li></ul></ul><ul><ul><li>about 150h modeling </li></ul></ul><ul><li>Model </li></ul><ul><ul><li>about 13000 model elements </li></ul></ul><ul><ul><li>about 700 symbols </li></ul></ul><ul><ul><li>about 150 diagrams </li></ul></ul>Die Modellierung ist nicht besonders aufwändig. 150h / 8h = 18 PT
    53. 53. Agenda <ul><li>Warum reden wir über Modellierung & Agilität? </li></ul><ul><li>Was bedeutet Agilität? </li></ul><ul><li>Was bedeutet Modellierung? </li></ul><ul><li>Der Konflikt zwischen Modellierung und Agilität </li></ul><ul><li>Beispiele aus der Praxis </li></ul><ul><li>Diskussion </li></ul>© by oose GmbH
    54. 54. © by oose GmbH Gibt es einen Konflikt zwischen Modellierung und Agilität? Welche Konflikte sehen Sie? Agile Projekte modellieren nicht!
    55. 55. Haben Sie noch Fragen, ... © by oose innovative Informatik GmbH
    56. 56. © by oose GmbH Modellierung im Spannungsfeld von agilen Vorgehensweisen FG Modellierung, Erlangen 05. Mai 2011 Tim Weilkiens Geschäftsführer [email_address]

    ×