- prosunt inter se boni -
 
abc Campus GmbH

Agiles Projektmanagement für Open Source Projekte

Agile Konzepte für kommerzielle Open Source Projekte

Insbesondere Open Source Teams empfinden die Konzeptansätze und Prinzipien von agilen Konzepten instinktiv als sympathisch – den Grundlagen der Open Source Welt sehr nahe und damit offenbar perfekt geeignet für eigene Projekte und Vorhaben.
Eine Lektion wird oft erst unter Schmerzen gelernt: „Agil ist nicht einfach SCRUM!“
Häufig beginnen Open Source Teams spontan damit, agile Methoden auszuprobieren – leider in der Regel mit enttäuschenden Ergebnissen. Ein simples Mapping von Scrum-Rollen und Ritualen auf die eigenen Mitarbeiter und Prozesse funktioniert in der Regel noch nicht …
ABER – es lohnt sich! Agile Konzepte und Open Source Projekte passen hervorragend zusammen.

Workshop: „Agiles Projektmanagement für Open Source Projekte“

Agile Konzepte für kommerzielle Open Source Projekte

Inhalt:

Der Workshop orientiert sich an der soliden Vermittlung agiler Konzepte und Arbeitsweisen und nimmt dabei Bezug auf „Standard“-SCRUM Kurse, berücksichtigt aber die Besonderheiten im Umfeld von Open Source. 
(Der
Workshop kann im Kontext aber durchaus als Zertifizierungsvorbereitung genutzt werden.)
Erfahrene Trainer aus „beiden Welten“ vermitteln die Grundlagen für die Nutzung agiler Methoden im Kontext von Open Source Projekten.

  • Dieser Workshop vermittelt die agile Methodik –  orientiert an Unternehmen und Teams, die regelmässig Open Source Projekte betreiben
    (Entwicklung, Implementierung, Anpassung, Pflege und Betrieb etc.).
  • Eine solide Basis an Wissen und Können für die Einführung und Anwendung agiler Methoden im eigenen Umfeld wird vermittelt.
  • Die Grundlagen und Konzepte von SCRUM werden eingebunden (Zertifizierung möglich) – es erfolgt dabei jedoch eine klare Abgrenzung bezüglich Übertragbarkeit und eigenen Pfaden.
  • Die Besonderheiten im Kontext Open Source werden beleuchtet und Übergange, Brücken, Dos & Don`ts dargestellt.
  • Konzepte für die erfolgreiche Einführung der Methoden in das eigene Team werden vorgestellt und vermittelt.

Umfang: 16 Lektionen (a 45 min)

Aktuell wird dieses Seminar auch online als „Virtual Interactual Lecture“ durchgeführt.


Agenda Schwerpunkte
  • Ausgangsbestimmung: Open Source und Agil – Historie, Visionen, Ethik, Leitbilder und Leitfiguren
  • Agile Vorgehensmodelle – Definition und Begriffsbestimmungen
  • Das Scrum Framework
    Rollen, Meetings, Artefakte,
    Developer-Team und Selbstorganisation,
    Scrum Rollen: Aufgaben und Rollenverständnis,
    Scrum Meetings, Planning Meeting, Daily Scrum,
    Sprint Backlog, Burndown Chart, Ready and Done
  • Abgeleitete Varianten und Konzepte im Markt
  • Release Planungen, Milestones etc. – „Hybride Vorgehensweisen“
  • Wege zur Zertifizierungen und Vorbereitungshilfen
  • Agile Best Practices
  • Agile Leadership
  • Agile Transformation – pragmatische Modelle und Konzepte
  • Gemeinsamkeiten, Abweichungen, Kompromisse: Agil und Open Source
  • Einführung von Agilen Konzepten in Open Source Teams
  • Verträge im Agilen Projekt

… ein paar Anregungen und Gedanken, wie sie im Kurs diskutiert werden:

„Agile Methoden und Open Source scheinen radikal anders zu sein.“

  • Agile Teams arbeiten als kleine kollaborierte Teams, am besten in einer zentralen Lokalisation – Open Source Teams sind oft grosse, verteilte Teams
  • Agile Methoden orientieren sich am Nutzen für den (zahlenden) Kunden – Open Source Projekte haben den Nutzer im Fokus
  • Die Entstehung von Open Source ist ein soziales Phänomen – Das Agile Konzept ist im kommerziellen Entwickler- und Beraterumfeld entstanden

„Agile Prinzipien und Open Source Prinzipien sind oft ähnlich, aber nicht immer einfach übertragbar!“
(… aus der Diskussion: Agile Principles vs. Open Source Philosophy – im Kontext nicht vordergründig kommerziell ausgerichteteter OSS Projekte …)

  • „Unsere oberste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.“ 
    Open Source spricht nicht über den Kunden, aber im Allgemeinen bauen Open-Source-Projekte allnächtlich Builds und häufig benannte Releases auf, meist zum Zweck von In-Situ-Tests.
  • „Veränderte Anforderungen, auch spät in der Entwicklung, willkommen heissen. Agile Prozesse nutzen Wandel für den Wettbewerbsvorteil des Kunden.“
    Open-Source-Projekte widerstehen im Laufe der Zeit grossen Veränderungen, aber es gibt immer die Möglichkeit, ein Projekt zu forken, wenn eine ausreichende Zahl an Entwicklern eine solche Änderung als lohnend empfindet.
  • „Liefern Sie häufig Arbeitssoftware, von ein paar Wochen bis zu ein paar Monaten, mit einer Bevorzugung der kürzeren Zeitskala.“ 
    Open Source liefert normalerweise jeden Abend Arbeitscode, und ein Open-Source-Motto lautet „Release early, release often“.
  • „Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.“
    Open-Source-Projekte haben kein Konzept eines Geschäftspartners, mit dem sie arbeiten, aber Benutzer, die am Projekt teilnehmen, haben dieselbe Rolle.
  • „Bauen Sie Projekte mit motivierten Personen auf. Geben Sie ihnen die Umgebung und die Unterstützung, die sie brauchen, und vertrauen Sie ihnen, dass sie ihre Arbeit erledigen.“
    Alle Open-Source-Projekte tun dies fast per Definition. Wenn es keine persönliche Motivation gibt, an einem Projekt zu arbeiten, wird ein Entwickler dies oft nicht tun. Das heisst, Open-Source-Projekte basieren oft auf  nicht oder nicht direkt kommerziell orientierten Vorhaben. Das bedeutet, dass die persönliche Motivation Vorraussetzung ist. Open-Source-Projekte verwenden eine Reihe von vereinbarten Tools für Versionskontrolle, Kompilierung, Debugging, Bug- und Issue-Tracking und Diskussion.
  • „Die effizienteste und effektivste Methode, um Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, sind persönliche Gespräche.“
    Open Source unterscheidet sich hier am meisten von agilen Methoden. Open-Source-Projekte favorisieren oft die schriftliche Kommunikation gegenüber der persönlichen Kommunikation. Auf der anderen Seite können Open-Source-Projekte weit verbreitet sein und erfordern keine Kollokation.
  • „Arbeitssoftware ist das primäre Maß für den Fortschritt.“
    Dies stimmt perfekt mit Open Source überein.
  • „Agile Prozesse fördern die nachhaltige Entwicklung. Die Sponsoren, Entwickler und Nutzer sollten in der Lage sein, auf Dauer ein konstantes Tempo zu halten.“
    Obwohl ein Vokabular verwendet wird, das Open-Source-Entwickler nicht verwenden würden, wird der Geist des Prinzips von Open Source übernommen.
  • „Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design steigern die Agilität.“
    Open Source basiert auf technischer Exzellenz und gutem Design.
  • „Einfachheit – die Kunst, den Arbeitsaufwand zu maximieren – ist essentiell.“
    Open-Source-Entwickler würden zustimmen, dass Einfachheit essentiell ist, aber Open-Source-Projekte müssen sich meist weniger Sorgen um Knappheit machen als agile Projekte. Es gibt selten vertraglich engagierte Leute in Open-Source-Projekten so dass die Menge der zu leistenden Arbeit von den Überzeugungen der einzelnen Entwickler abhängt.
  • „Die besten Architekturen, Anforderungen und Designs entstehen aus selbstorganisierenden Teams.“
    Möglicherweise würden Open-Source-Entwickler das nicht so sagen, aber die Natur von Open-Source-Projekten hängt davon ab.
  • „In regelmäßigen Abständen reflektiert das Team, wie man effektiver wird und stimmt sein Verhalten entsprechend ab.“
    Dies ist in Open-Source-Projekten wahrscheinlich nicht besonders häufig der Fall, obwohl Open-Source-Projekte in der Regel eine größere Anzahl von Governance-Mechanismen entwickeln.
Translate »