Open Source Jahrbuch 2008 - Business Linux Hanse Network

�������������������� � ��� ������ ��� ������������������� ����������� ������
Wenn der Anwender zur Entwicklung und P ege individueller Lösungen mit einem
Dienstleister zusammenarbeitet, begibt er sich in eine gewisse Abhängigkeit. Sein
Geschäftserfolg ist von dem Know-how eines Dienstleisters abhängig. Will er den
Dienstleister wechseln, muss dieser sich zuerst einmal in das System einarbeiten. Selbst
wenn man die Abhängigkeit durch eine gute Dokumentation, die strikte Einhaltung
von Standards und die Veröffentlichung des Codes in der Community reduziert, ist
der Wechsel eines Dienstleisters mit Unsicherheiten verbunden.
Bei gröÿeren Projekten kann es daher sinnvoll sein, mit mehreren Dienstleistern
zusammenzuarbeiten. Dies reduziert die Abhängigkeiten und kann die Qualität
der Lösungen durch eine kollaborative Entwicklung erhöhen. Allerdings entstehen
Schnittstellen zwischen Auftraggeber und Dienstleister einerseits und zwischen den
einzelnen Dienstleistern andererseits. Um diese Schnittstellen zu überbrücken, installiert
man für gewöhnlich ein kompetentes Projektmanagement. Das Projektmanagement
organisiert den Entwicklungsprozess und fungiert als Übersetzer. Es ermittelt
die Bedürfnisse des Anwenders sowie den Ablauf der internen Prozesse und übersetzt
diese in konkrete Spezi kationen eines Programms, die dann von den Entwicklern
implementiert werden.
4 Sprints
Das Konzept der agilen Entwicklung hat den Sprint als besonders intensive Kollaborationsmethode
hervorgebracht. Sprints ergänzen die Zusammenarbeit via Internet, sie
sind zumeist mehrtägige Treffen von Entwicklern, bei denen vorher festgelegte Ziele
durch eine intensive Zusammenarbeit erreicht werden. In der Python-Community
können dies ���� sein, in der Plone-Community �����. In Barcellini, Détienne und
Burkhardt (2006) wird beispielsweise die Implementierung von ��� 327 während
Sprints untersucht. Sprints sind in der Plone- und Zope-Community sehr beliebt.
Groÿe Teile des CMS Plone sind bei Sprints entstanden.
Bei vielen Sprints werden aber keine formalisierten Aufgabenstellungen abgearbeitet,
weil die Entwickler, die freiwillig zusammenkommen, ihren eigenen Interessen
nachgehen. Besonders fruchtbar sind Sprints, um neue Softwareprojekte überhaupt
erst einmal auf den Weg zu bringen. So entstanden beispielsweise die ersten Versionen
von ����, einem System, das das Arbeiten mit Zope drastisch vereinfacht, bei
mehreren Sprints im kleinen Kreis. 4
Sprints, bei denen ���� oder ����� auf der Agenda stehen, können als anwendergetriebene
Entwicklung betrachtet werden, insofern oft Wünsche der Anwender
in die ���� oder ����� einge ossen sind. Bei anderen Sprints hängt die Anwenderorientierung
vom Zufall beziehungsweise der Neigung der anwesenden Entwickler
ab.
4 Vgl. hierzu die Blogeinträge von zwei Beteiligten in Faassen (2006), Kolman (2007) und Faassen (2007)
11
Partizipieren