Mit SCRUM und CMMI effizient Software entwickeln Scrum-Workshop, Kaleidos, 20.5.2014 P. Sprenger Demix AG www.demix.org Capability Maturity Model, Capability Maturity Modeling, CMM and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University SM CMM Integration, IDEAL, Personal Software Process, PSP, SCAMPI, SCAMPI Lead Appraiser, SEPG and TSP are service marks of Carnegie Mellon University demix ag, www.demix.org 2013, License CC-BY-SA 3.0 1
Begrüßung Wenn man in der Menge mitschwimmt, wird man üblicherweise nicht weiter kommen, als die Menge auch. Wenn man alleine geht, kommt man wahrscheinlich an Stellen, an denen noch nie jemand vor einem war. -- Alan Ashley-Pitt The man who follows the crowd will usually get no further than the crowd. The man who walks alone is likely to find himself in places no one has ever been. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 2
Vorstellung Peter Sprenger Seit 1993 Mitarbeit in und Leitung von Business-, Integrations- und Applikationsentwicklungs-Projekten. Seit 2008 Prozessverbesserungsinitiativen von Hard- und Software- Entwicklungen, hauptsächlich in den Branchen Banken und Energie. Studium: MS BIS Fachhochschule Nordwestschweiz (CH) MBA City University of Seattle (USA) BSc BA City University of Seattle (USA) Trainings: PMI-ACP (Agile Certified Practitioner; PMI-Scrummaster) Zertifizierungen: Instruktor CMMI for Services / CMMI for Development PMP (Projektmanagement Professional; PMI) demix ag, www.demix.org 2013, License CC-BY-SA 3.0 3
Vorstellungsrunde Bitte stellen Sie sich vor: Name Aufgabenbereich Warum sind Sie im Tutorial? Was erwarten Sie vom Tutorial? Themen zu denen Sie unbedingt etwas erfahren wollen demix ag, www.demix.org 2013, License CC-BY-SA 3.0 4
Regeln Nr. 1 Wir sind für die Inhalte verantwortlich, Sie für den Erfolg des Tutorials Nr. 2 Welche Regeln wollen wir befolgen? - Handys - E-Mails -... demix ag, www.demix.org 2013, License CC-BY-SA 3.0 5
Inside Paradeplatz: CMMI vs. Agile Methoden? Die beiden führenden Helvetier in der CS-IT hätten am längst überholten Konzept der prozessorientierten Entwicklung festgehalten, sagt die Quelle. Der Trend geht heute in Richtung Agile Programming. Kleine Schritte schnell ausgeführt lautet das Schlagwort; eine Strategie der IT-Nadelstiche quasi. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 6
Inside Paradeplatz: CMMI vs. Agile Methoden? Bild: Wikimedia Commons, Public Domain demix ag, www.demix.org 2013, License CC-BY-SA 3.0 7
More importantly, Systematic has transformed over twenty years of experience into a unified set of processes used by all software projects. Historical data are systematically collected and analyzed to continuously provide insight into the capability and performance of the organization. The use of a shared common process makes it easier for people to move from project to project and share experiences and lessons learned between projects. Insight into the capability and Kernidee Beide Ansätze zusammenbringen performance of processes makes it possible to evaluate performance of new processes to performance of existing processes. And this forms the foundation for continuous improvement. CMMI 1 Project effort 100% 100 % Rework Work 90% 80% 70% 60% 50% 50 % CMMI 69 % 9 % a SCRUM Proces focus 40% 30% 20% 50 % 50 % 35 % 4 % 25 % 10% 10 % CMMI 1 CMMI 5 Systematics Dänemark Mit Prozessverbesserung wurden die Nachbesserungen reduziert Mit Einsatz von Scrum wurde zusätzlich die Produktivität verbessert Nachbesserung weiter reduziert Figure 1: CMMI and Scrum Productivity Gains CMMI 5 SCRUM In short, Systematic is able to deliver what the customer has ordered on schedule, cost and quality using 69% effort compared to a CMMI Level 1 company [80, 81]. This benefit comes at the minimal cost of 9% process focus in project management and engineering. CMMI Level 5 is increasingly a requirement from customers and key to obtaining large contracts, especially within defence and healthcare. Customers recognize that CMMI Level 5 gives high predictability and better-engineered product for scalability, maintainability, adaptability, and reliability. Early results indicate that when CMMI traditional processes are optimized using Scrum, the productivity for large projects is doubled and the amount of rework is reduced an additional 40% over that of CMMI Level 5 companies. It is important to note that the optimized process is a mixed process, using traditional CMMI processes to establish a project baseline expressed as a product backlog combined with Scrum as the preferred way to implement the project in iterations 6 % 2 SM Capability Maturity Model Integration, and SCAMPI are service marks of Carnegie Mellon University demix ag, www.demix.org 2013, License CC-BY-SA 3.0 8
Grundlegendes Ziel von CMMI Bessere Produkte - Jede Bedeutung von "besser"! demix ag, www.demix.org 2013, License CC-BY-SA 3.0 9
Um was geht es bei CMMI? CMMI adressiert die Arbeitsabläufe einer Organisation "Prozesslandschaft" Grunderkenntnis Die Qualität eines Produkts oder einer Dienstleistung wird überwiegend durch die Qualität der maßgeblichen Prozesse bestimmt Gilt für Dienstleistung, Entwicklung, Beschaffung usw.! Idee: SEI, Mastering Process Improvement demix ag, www.demix.org 2013, License CC-BY-SA 3.0 10
CMMI - Konstellationen Drei Varianten von CMMI ("Konstellationen") CMMI for Services Erbringung von Dienstleistungen CMMI for Development Entwicklung von Produkten und Dienstleistungen CMMI for Acquisition Beschaffung von Produkten und Dienstleistungen SVC Tun Kern Bauen Beschaffen Gleiche Terminologie, gemeinsamer Kern demix ag, www.demix.org 2013, License CC-BY-SA 3.0 11
CMMI Anwendung: Beispiel von Institutionalisieren Was müssen Eltern tun, dass ihre Kinder auch dann ihre Zähne putzen, wenn sie nicht mehr unter direktem Einfluss ihrer Eltern stehen? In der CMMI Terminologie Was müssen Eltern tun um bei ihren Kindern das Zähneputzen zu institutionalisieren? demix ag, www.demix.org 2013, License CC-BY-SA 3.0 12
CMMI Generische Ziele und Praktiken GG 1 Spezifische Ziele erreichen GP 1.1 Spezifische Praktiken durchführen GG 2 Geführte Prozesse institutionalisieren GP 2.1 Organisationsweite Leitlinien etablieren (Policies) GP 2.2 Arbeitsabläufe planen GP 2.3 Ressourcen bereitstellen GP 2.4 Rechte und Pflichten zuweisen GP 2.5 Aus- und weiterbilden GP 2.6 Arbeitsergebnisse verwalten GP 2.7 Relevante Stakeholder identifizieren und beteiligen GP 2.8 Arbeitsabläufe überwachen und steuern GP 2.9 Prozesseinhaltung objektiv bewerten GP 2.10 Umsetzung mit dem höheren Management prüfen GG 3 Definierte Prozesse institutionalisieren GP 3.1 Definierte Prozesse etablieren GP 3.2 Prozessbezogene Erfahrungen sammeln Quelle: SEI-sanktionierte Übersetzung von CMMI for Development 1.3 demix ag, www.demix.org 2013, License CC-BY-SA 3.0 13
Wirkungsweise von CMMI Anforderungen an die Existenz von Prozess- funktionalität Bewährte Praktiken CMMI Arbeitsabläufe der Organisation demix ag, www.demix.org 2013, License CC-BY-SA 3.0 14
Wirkungsweise von CMMI: GP 2.1 und 2.10 Anforderungen an die Existenz von Prozess- funktionalität Bewährte Praktiken Forderungen an "Güte" und Qualität von Arbeitsabläufen Policies Management- Reviews CMMI Arbeitsabläufe der Organisation demix ag, www.demix.org 2013, License CC-BY-SA 3.0 15
Wirkungsweise von CMMI: GP 2.1, 2.10, 3.1 und 3.2 Anforderungen an die Existenz von Prozess- funktionalität Bewährte Praktiken Forderungen an "Güte" und Qualität von Arbeitsabläufen Policies Management- Reviews CMMI Arbeitsabläufe der Organisation Erfahrung und Wissen aus den Aktivitäten Bereitstellung von Wissen an die Aktivitäten Systematische Aufarbeitung demix ag, www.demix.org 2013, License CC-BY-SA 3.0 16
CMMI ist... CMMI ist...... ein Framework, um die Fähigkeiten einer Organisation zu erkennen und verbessern... weder eine Norm noch eine Methode... ein wissenschaftliches Modell, das mit wissenschaftlichen Methoden erstellt und dessen Wirksamkeit nachgewiesen wurde... ein Framework zur dauerhaften Verbesse-rung der Arbeitsabläufe einer Organisation... ein Ansatz zur Prozessverbesserung, der eine Organisation auf wichtige Elemente effektiver Arbeitsabläufe hinweist... ein Satz von Praktiken, zusammengestellt für eine systematische und schrittweise Verbesserung von Fähigkeiten und Reife einer Organisation... gemacht zur Leistungssteigerung von Arbeitsabläufen... nicht die Zusammenstellung der Meinun-gen von Einzelnen oder einer Gruppe... weder ein Prozess noch eine Prozessbeschreibungssprache... kein Wundermittel... keine Prozessbeschreibung... keine Compliance-Checkliste demix ag, www.demix.org 2013, License CC-BY-SA 3.0 17
Zusammenfassung CMMI ist ein Prozessverbesserungsmodell mächtig komplex pragmatisch ziemlich vollständig CMMI hilft einer Organisation ihre spezifischen Ziele und Notwendigkeiten zu erfüllen und dabei performant zu bleiben/werden CMMI -Kernziel: Kontinuierliche, systematische und nachweisbare Verbesserung der Abläufe CMMI ist in einer Vielzahl von Organisationen und Organisationstypen anwendbar, hilfreich und nützlich demix ag, www.demix.org 2013, License CC-BY-SA 3.0 18
Warum scheitern SW-Projekte? Nicht genügend Zeit Nicht genügend Budget Unklare Anforderungen Unzureichendes Risikomanagement Unzureichende Kommunikation demix ag, www.demix.org 2013, License CC-BY-SA 3.0 19
Fehlentwicklungen Vorgehensmodell wird als Vorschrift verstanden Kreativitätseinschränkung, demotivierte Mitarbeiter, Bürokratismus Zu hoher Dokumentationsaufwand Die Vorgabe steht im Vordergrund, nicht der Mensch demix ag, www.demix.org 2013, License CC-BY-SA 3.0 20
Das agile Manifest Individuen und Interaktionen Funktionierende Programme gelten mehr als gelten mehr als Prozesse und Tools Ausführliche Dokumentation Die Zusammenarbeit mit dem Kunden steht über Vertragsverhandlungen Das Eingehen auf Änderungen stehen über Dem Befolgen eines festgelegten Plans Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 21
Das dunkle agile Manifest Individuen und Interaktionen und keine Prozesse und Tools Funktionierende Programme und keine Ausführliche Dokumentation Die Zusammenarbeit mit dem Kunden und keine Vertragsverhandlungen Das Eingehen auf Änderungen und kein Dem Befolgen eines festgelegten Plans Wir erkennen dabei keinen Wert der Dinge auf der rechten Seite, und sehen nur den Wert auf der linken Seite. Quelle: http://darkagilemanifesto.org/ demix ag, www.demix.org 2013, License CC-BY-SA 3.0 22
Scrum-Übersicht: Historie Erstes Scrum-Projekt 1993" Väter: Ken Schwaber, Mike Beedle, Jeff Sutherland" Wurzeln im Ingenieurbereich" Lean Production / Management Vorreiter: u.a. Toyota o Zum Begriff Scrum! Scrum ist kein Acronym" Scrum = Gedränge" Begriff aus dem Rugby" Komplizierter Spielzug, der disziplinierte Teamarbeit erfordert " demix ag, www.demix.org 2013, License CC-BY-SA 3.0 23
Scrum Charakteristika Selbstverantwortliche Teams Produkt wird inkrementell in einer Abfolge von Sprints entwickelt Anforderungen sind als priorisierte Einträge im Product Backlog festgehalten Keine spezifische Entwicklungvorgehensweise vorgeschrieben Generative Regeln um ein agiles Umfeld für die Auslieferung von Produkten zu schaffen demix ag, www.demix.org 2013, License CC-BY-SA 3.0 24
Scrum Das Konzept Standup Meeting alle 24 Stunden Sprint Backlog Sprint 2-6 Wochen In Tasks heruntergebrochen Potentiell auslieferbares Produkt-Inkrement Product Backlog demix ag, www.demix.org 2013, License CC-BY-SA 3.0 25
Scrum Übersicht Rollen Produkt-Owner ScrumMaster Team Artefakte Product Backlog Sprint Backlog Burndown-Diagramm Meetings Sprint Planung Sprint Review Sprint Retrospektive Standup Meeting demix ag, www.demix.org 2013, License CC-BY-SA 3.0 26
Drei Rollen Scrum Master Team Entwickler und Tester Product Owner demix ag, www.demix.org 2013, License CC-BY-SA 3.0 27
Der Product Owner Aufgaben: Erfassen, priorisieren und dokumentieren der Anforderungen Planen der Releases und der Releaseziele Kommunikation und Abstimmung mit den verschiedenen Stakeholdern Festlegen von Inhalten und Zielen für die Iterationen mit dem Team Prüfen und Abnehmen der Sprintergebnisse demix ag, www.demix.org 2013, License CC-BY-SA 3.0 28
Der Scrum Master Aufgaben: Ansprechpartner für die Teammitglieder bei Problemen Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken Beseitigt Hindernisse für das Team Schützt das Team vor äußeren Störungen Organisation und Moderation von Besprechungen und Reviews Repräsentiert das Team gegenüber dem Management demix ag, www.demix.org 2013, License CC-BY-SA 3.0 29
Das Team Aufgaben: Entwickler und Tester Typischerweise 5 9 Personen Interdisziplinär und funktionsübergreifend Erstellen die Sprintergebnisse (Analyse, Design, Implementierung,Test) Selbstorganisierend und selbstverpflichtend Teamzugehörigkeit darf sich nur zwischen den Sprints ändern demix ag, www.demix.org 2013, License CC-BY-SA 3.0 30
Scrum Artefakte Rollen Produkt-Owner ScrumMaster Team Artefakte Product Backlog Sprint Backlog Burndown-Diagramm Meetings Sprint Planung Sprint Review Sprint Retrospektive demix ag, www.demix.org 2013, License CC-BY-SA 3.0 31
Das Product Backlog Enthält die Produktanforderungen aus Benutzersicht Idealerweise so formuliert, das jeder Eintrag einen Nutzen für einen Benutzer oder den Kunden hat Product Owner priorisiert Team schätzt Aufwand (Komplexität usw.) Unterschiedlicher Detaillierungsgrad Kann zu Beginn eines jeden Sprints neu priorisiert werden demix ag, www.demix.org 2013, License CC-BY-SA 3.0 32
Der Product Backlog-Eisberg Sprint High Future Releases Release Priority Value Cost Risk Knowledge Low demix ag, www.demix.org 2013, License CC-BY-SA 3.0 33
Beispiel des Product Backlog demix ag, www.demix.org 2013, License CC-BY-SA 3.0 34
Planning Poker 1 Team schätzt gemeinsam die Komplexität von Backlog Items Jedes Backlog Item wird durch den Product Owner erläutert Jeder Teilnehmer schätzt den Aufwand für die Umsetzung der Aufgabe und legt entsprechende Karte Sobald alle Teilnehmer ihre Schätzung hingelegt haben, werden die Karten aufgedeckt Abweichungen werden besprochen Das Team nähert sich in weiteren Runden einem Konsens an. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 35
Planning Poker 2 demix ag, www.demix.org 2013, License CC-BY-SA 3.0 36
Was interessiert den Product Owner (PO)? Wie weit sind wir im Vergleich zur ursprünglichen Planung? Wann sind wir voraussichtlich fertig? Wie schnell ist das Team? Wie entwickelt sich die Geschwindigkeit (Velocity) des Teams? Einfluss geänderter, zusätzlicher oder nicht benötigter Anforderungen demix ag, www.demix.org 2013, License CC-BY-SA 3.0 37
Der Release Burndown Chart Diagramm, das den Projektfortschritt des Releases visualisiert Wieviel Arbeit ist nach aktueller Schätzung noch übrig? Mittels einer Trendlinie lässt sich das Ende des Projektes vorhersagen demix ag, www.demix.org 2013, License CC-BY-SA 3.0 38
Release Burndown Chart 600 500 400 User Story Points 300 200 100 0-100 -200-300 Sprints demix ag, www.demix.org 2013, License CC-BY-SA 3.0 39
Organisation des Sprint im Team Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen) Die geschätzte restliche Arbeit wird täglich aktualisiert Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern Wenn eine Arbeit unklar ist, wird ein Task mit einer größeren Zeitschätzung definiert und später detailliert demix ag, www.demix.org 2013, License CC-BY-SA 3.0 40
Das Sprint Backlog Eine Liste von Tasks, welche den Arbeitsumfang des Teams für den Sprint festlegt Die Liste präzisiert sich während des Sprints und wird täglich von allen Teammitgliedern gepflegt, so dass sie immer den aktuellen Bearbeitungsstand reflektiert Der Sprint Backlog ermöglicht es dem Team, jederzeit zu erkennen, wo das Team steht und ggf. steuernd einzugreifen, damit das Sprint-Ziel nicht in Gefahr gerät demix ag, www.demix.org 2013, License CC-BY-SA 3.0 41
Sprint Backlog Task Mon. Tues. Wed. Thurs. Jump Input Control 8 3 0 0 Jump Tuning 16 16 10 4 Jump Animation 8 16 16 4 Double Jump Option 8 8 0 demix ag, www.demix.org 2013, License CC-BY-SA 3.0 42
Das Sprint Board in der Realität User Stories Tasks Burndown Chart Completed Tasks demix ag, www.demix.org 2013, License CC-BY-SA 3.0 43
Sprint Burndown Chart demix ag, www.demix.org 2013, License CC-BY-SA 3.0 44
Weitere Artefakte Projekt Konzept / Vision Release Plan Team Backlog ( bei mehreren Team ) Architektur Dokument Imdediment List System Test Spezifikation System Test Report Design-/Code Reviews Acceptance Tests Iteration Dokumentation Design Dokumente / Modelle Datenmodell Benutzerdokumentation. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 45
Meetings Rollen Produkt-Owner ScrumMaster Team Artefakte Product Backlog Sprint Backlog Burndown-Diagramm Meetings Sprint Planung Sprint Review Sprint Retrospektive demix ag, www.demix.org 2013, License CC-BY-SA 3.0 46
Ablauf eines Sprints demix ag, www.demix.org 2013, License CC-BY-SA 3.0 47
Sprint Planung Der Product-Owner legt fest in welcher Reihenfolge die Anforderungen umgesetzt werden (durch Priorisierung im Product-Backlog) Das Team entscheidet, wieviele Anforderungen es im nächsten Sprint umsetzen kann und verpflichtet sich zu deren Fertigstellung Sprint-Backlog wird erstellt Tasks werden identifiziert und geschätzt Entscheidung erfolgt gemeinschaftlich durch das Team Architektur wird berücksichtigt demix ag, www.demix.org 2013, License CC-BY-SA 3.0 48
Sprint Planung As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4) demix ag, www.demix.org 2013, License CC-BY-SA 3.0 49
Einflüsse bei der Sprintplanung demix ag, www.demix.org 2013, License CC-BY-SA 3.0 50
Das Sprint Ziel Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren sollen Life Sciences Database Application Make the application run on SQL Server in addition to Oracle. Support features necessary for population genetics studies. Financial Services Support more technical indicators than company ABC with real-time, streaming data. demix ag, www.demix.org 2013, License CC-BY-SA 3.0 51
Daily Standup-Meeting - 1 Parameter Täglich 15 Minuten lang Stand-up Nicht zur Problemlösung Alle sind eingeladen Aber nur Team-Mitglieder und Scrum-Master dürfen reden der Produkt-Owner darf nur zuhören demix ag, www.demix.org 2013, License CC-BY-SA 3.0 52
Daily Standup-Meeting 2 Was habe ich gestern getan? 1 Was werde ich heute tun? 2 Was behindert mich bei meiner Arbeit? 3 demix ag, www.demix.org 2013, License CC-BY-SA 3.0 53
Daily Standup-Meeting 3 demix ag, www.demix.org 2013, License CC-BY-SA 3.0 54
Sprint Review Meeting Das Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo der neuen Features Informell Vorbereitung nicht länger als 2 Stunden Keine Folien Das ganze Team nimmt teil Laden Sie alle interessierten Parteien ein! demix ag, www.demix.org 2013, License CC-BY-SA 3.0 55
Was ist ein Produktinkrement? Umgesetzte Anforderungen für diesen Sprint aus dem Product Backlog Ausführlich getestet Adäquat dokumentiert Benutzerdokumentation Entwicklungsdokumentation Designdokumentation Wartungsdokumentation Definition der Done -Kriterien zu Beginn des Projektes festlegen demix ag, www.demix.org 2013, License CC-BY-SA 3.0 56
Sprint Restrospektive Prüfen Sie regelmäßig, was gut und nicht so gut funktioniert Typischerweise ungefähr 30 Minuten lang Nach jedem Sprint Das ganze Team nimmt teil Scrum-Master + Team + Product-Owner Vielleicht Endkunden und andere Personen (aber Vorsicht!) demix ag, www.demix.org 2013, License CC-BY-SA 3.0 57
Sprint Retrospektive Teamsitzung Lesson learned Was / wie verbessern Was wollen wir beginnen Diese ist eine von vielen Methoden um Retrospektiven durchzuführen Womit wollen wir aufhören... Womit wollen wir weitermachen... demix ag, www.demix.org 2013, License CC-BY-SA 3.0 58
Eine Start/Stop/Continue List Mache. mit der fertiggestellten User Story mit dem Product- Owner eine Demnonstration. Daily Builds um Fitness zu beweisen Meide parallel zu viele User Stories zu haben Continue Code Reviews demix ag, www.demix.org 2013, License CC-BY-SA 3.0 59
Scrum Übersicht demix ag, www.demix.org 2013, License CC-BY-SA 3.0 60
Eine Scrum-Leseliste Agile and Iterative Development: A Manager s Guide von Craig Larman Agile Estimating and Planning von Mike Cohn Agiles Projektmanagement mit Scrum von Ken Schwaber Scrum - Agiles Projektmanagement erfolgreich einsetzen von Roman Pichler Agile Retrospectives von Esther Derby und Diana Larsen Agile Software Development Ecosystems von Jim Highsmith Agile Software Development with Scrum von Ken Schwaber und Mike Beedle User Stories Applied von Mike Cohn demix ag, www.demix.org 2013, License CC-BY-SA 3.0 61
Fragen? Anmerkungen? Jetzt oder später unter gerhard.fessler@demix.org +49 173 98 97 544 XING peter.sprenger@demix.org +41 (0)76 349 0120 XING demix ag, www.demix.org 2013, License CC-BY-SA 3.0 62
Lizenz CC-BY-SA 3.0 Sie dürfen: Teilen das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten Bearbeiten das Material remixen, verändern und darauf aufbauen und zwar für beliebige Zwecke, sogar kommerziell. Der Lizenzgeber kann diese Freiheiten nicht widerrufen solange Sie sich an die Lizenzbedingungen halten. Unter folgenden Bedingungen: Angabe der Quelle und Link zur Lizenz Änderungen müssen angemessen gemeldet werden aber nicht so, dass die Quelle Rückverweise machen muss (You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.) Weitergabe unter gleichen Bedingungen Wenn Sie das Material remixen, verändern oder anderweitig direkt darauf aufbauen, dürfen Sie Ihre Beiträge nur unter derselben Lizenz wie das Original verbreiten. Keine weiteren Einschränkungen Sie dürfen keine zusätzlichen Klauseln oder technische Verfahren einsetzen, die anderen rechtlich irgendetwas untersagen, was die Lizenz erlaubt. Quelle: https://creativecommons.org/licenses/by-sa/3.0/de/ demix ag, www.demix.org 2013, License CC-BY-SA 3.0 63