5. Workshop: Vorgehensmodelle in der Praxis Lösung oder Ursache aller Probleme?

Transkript

1 5. Wrkshp: Vrgehensmdelle in der Praxis Lösung der Ursache aller Prbleme? Marc Kuhrmann, Patrick Keil, André Schnackenburg, Oliver Linssen Abstract: Am fand der 5. Wrkshp Vrgehensmdelle in der Praxis zum Thema Lösung der Ursache aller Prbleme? statt. In den vier ausgewählten Beiträgen werden unterschiedliche Facetten dazu aufgegriffen: Im Bereich der Erfahrungen und Erflgsfaktren der Einführung vn Vrgehensmdellen stellen Wind und Schrödl eine Fallstudie zur Einführung agiler Prjektmanagementmethden vr. Auch Bmbsch et. al widmen sich der Einführung agiler Verfahren, legen den Fkus jedch nicht nur auf Entwicklungsprjekte sndern auch auf die ausführenden Organisatinen. Einen stärkeren Bezug zu Werkzeugen sucht der Beitrag vn Rmahn, in dem die Frage der Einführung eines Vrgehensmdells im Kntext der Werkzeugunterstützung als Akzeptanzkriterium diskutiert wird. Lewitz stellt ergänzend die grundsätzliche Frage, warum auch Prjekte einen Business Case benötigen und diskutiert diese Frage im Rahmen einer Gegenüberstellung verschiedener Vrgehensmdelle. 1. Prtkll des Wrkshps Die Fragestellung, b Vrgehensmdelle nun die Lösung der eher dch die Ursache der Prbleme im Prjektgeschäft sind, wurde durch die Redner vn unterschiedlichen Seiten beleuchtet. Dass es sich hierbei um ein kntrvers zu diskutierendes Thema handelt, zeigt die grße Anzahl der Redebeiträge, Fragen und Antwrten in den jeweiligen Vrträgen; beginnend mit der vn Patrick Keil aufgestellten These, dass die durch die Anwendung agiler Methden entstehende Przessanarchie zu einer erneuten Sftware-Krise führen kann. Im Flgenden werden die Kernaussagen der Vrträge und die Diskussinen zusammengefasst. Dabei steht F für Frage, A für Antwrt und D für Diskussinsbeiträge A. Rausch: Qu vadis IT-Vrgehensmdelle - am Beispiel des V-Mdell XT In seinem Beitrag thematisiert A. Rausch die Skepsis gegenüber Vrgehensmdellen und stellt die Fragen warum das s ist und was man besser machen könne. Insbesndere Rahmenbedingungen und überzgene Vrstellungen vn dem, was Vrgehensmdelle können (sllen), seien eine Ursache für nicht erflgreiche Prjekte. Es sllte klar herausgestellt werden, was ein Vrgehensmdell leisten kann und was nicht, z.b. das Thema Prjektkultur, das nicht zwingend als Vrgabe eines Vrgehensmdells betrachtet werden könne. Faktisch seien Vrgehensmdelle heute Schrankware. Dies gilt swhl für die reichhaltigen wie auch für die agilen Vrgehensmdelle (Stichwrt: Bücher zu agilen Methden). Vielmehr sllten Vrgehensmdelle als Werkzeuge angesehen werden.

2 Insbesndere im Kntext lernender Organisatinen sllten Vrgehensmdelle das bewährte Wissen zusammenfassen und den Prjekten als Unterstützung zur Verfügung stellen. A. Rausch argumentiert auch, dass die Menge und Granularität der Inhalte kritisch betrachtet werden müssen. Fein granulare und detaillierte Vrgaben, die glbal für alle Prjekte definiert werden, machen keinen Sinn. Fragen: F: Thema Erfahrungen mit IT-Cntrlling-Artefakten: Ist es praktisch, dass Freiheiten erkannt/eingeräumt werden? A: Das sei kulturabhängig; je klarer die Messinstrumente, dest besser geht es Cntllern. Aber Menschen lückenls zu kntrllieren ist eine Illusin. Die Plemik zwischen Agil und reichhaltig spielt in Unternehmen eher keine Rlle mehr. F: Wie sieht das Änderungsmanagement im V-Mdell aus? A: Es gibt Verfahren, Zustandsautmaten, frmales Prblem- und Änderungsmanagement. Für welche Prdukte ein slches Verfahren etabliert wird, ist eine prjektspezifische Festlegung. (Zwischenfrage) Als funktiniert das V-Mdell nicht nur für grße Prjekte, insbesndere grße mit hher Änderungsrate? Vielleicht ist die Knstellatin grßes Prjekt und viele Änderungen Quatsch? Sind die nicht zu kritisch? An vielen Stellen machen es sich die Agilen Verfahren zu leicht... Überspritzt: Management wird für das Gesamtprjekt aufgegeben (Gesamtblick und nicht nur eine Iteratin) S. Wind und H. Schrödl: Einführung agiler Prjektmanagementmethden für Sftwareentwicklung in der IuK-Industrie In ihrem Beitrag diskutieren die Autren die These, dass klassische Vrgehensmdelle insbesndere in verteilten Szenarien an ihre Grenzen stßen. Im Rahmen des Vrtrags wurde ein Piltprjekt vrgestellt, das selbst zwar nicht verteilt ablief, jedch in einer verteilt arbeitenden Organisatin durchgeführt wurde. Dieses Thema stieß auf grßes Interesse, sdass bereits während des Vrtrags eine rege Diskussin entstand: F: [Kntext: Pr Prjekt wird eine Methdenauswahl für das Vrgehen gemacht.] Wird das wirklich pr Prjekt gemacht? Ist das nicht fahrlässig? F: Was war die Mtivatin der Mitarbeiter im Prjekt? War ihnen klar, dass sie Versuchskaninchen sind? Haben sie es als Chance gesehen? A: Hier war alles dabei. F: [Kntext: Das Piltprjekt wurde erflgreich abgeschlssen.] Nach welchem Maßstab wurde das Prjekt erflgreich abgeschlssen? à Geschben auf Bewertung. F: [Kntext: Unterbinden vn Gerüchten] Was ist mit Gerüchten gemeint?

3 A: Gemeint ist: Es gibt eine Prjektinfseite hne Geheimnisse. F: [nachgefragt] Hat das die Gerüchte unterbunden und wran misst man, dass es weniger gibt? F: [Kntext: Setting der Studie] Was war die Rlle begleitend, beratend? A: Wissenschaftliche Begleitung, um Änderungsbedarf aufzeigen, die Methden auszuwählen. Die Begleitung wurde im Wesentlichen durch Anwesenheit /Bebachtung gemacht. Zwischenbemerkung: Wir müssen slche Studien ernsthaft(er) machen und knkrete Aussagen machen. Allgemeingültige Aussagen sind i.d.r. nicht valide. Es sind mehr brauchbare/gültige Aussagen nötig. Es sllte nicht jedes Mal eine neue Sau durchs Drf getrieben werden O. Lewitz: Warum Prjekte einen Business Case brauchen In seinem Beitrag argumentiert O. Lewitz, warum Prjekte einen Business Case brauchen und stellt zur Diskussin, warum dieses wichtige Element vn vielen Vrgehensmdellen, aber auch den verantwrtlichen Prjektleitern nur unzureichend der gar nicht betrachtet wird. Ein Business Case sei im Wesentlichen eine in Zahlen gegssene Visin für das Prjekt. Gleichzeitig müsse man sich in diesem Kntext auch auf eine Definitin einigen, wann ein Prjekt als erflgreich angesehen werden sll. F: Wie sieht die Wertschöpfung z.b. bei Umsetzung rechtlicher Nrmen aus? A: Einige Bereiche sind mnetär eher nicht s relevant (z.b. Fluthilfe); andere existenziell... Sllte ein Business Case gerechnet werden? Kmmt darauf an, wie Ergebnisse gemessen werden... F: Warum scheitert Sftware Engineering an grundlegenden Fragestellungen? D: Siehe BWL in der Therie (Knferenzen etc.) wird das gemacht und als Prblem erkannt und entsprechend behandelt. In der Praxis wird es Grßteils ignriert. Dieses Prblem hat auch das Sftware Engineering. D: IT-Business Cases sind schwer, da IT die Organisatinsumstellung unterstützen sll. Kann man rechnen, aber b es sich rechnet ist aber eine andere Frage. In der Prduktentwicklung wird schn gerechnet. D: IT sllte genau gerechnet werden (siehe Outsurcing etc.). Man kann leicht einen Business Case rechnen fragt sich nur, b der valide ist. D: Weniger das Rechnen als slches ist wichtig, sndern ein Umdenken hin zum Verständnis, dass jede Investitin eine Begründung und ein nachvllziehbares Ergebnis benötigt.

4 F: Man sllte die Grundprbleme bedenken nicht alle Aspekte sind mnetärer Natur. Es gehört nicht nur Geld in einen Business Case. 2. Punkt: Wie rechne ich Effekte in Geld um? Direkte vs. indirekte Effekte/Wirkung? A: Prblem sind die Budgets: Vrhandene Budgets sind eher interessensgetrieben. [Diskussin an Beispielen, z.b. Militärjet A-10, US-Authersteller etc.] F: Immer Zahlen zu haben ist nicht gut (nicht alles ist messbar). A: Man sllte versuchen, Dinge transparent zu halten, irgendwie sind die Ziele transparent zu halten, um die Wertmaßstäbe festzustellen. Schlussendlich läuft es dann aber wieder auf $ und hinaus. F: Wie bewertet man am besten einen Business Case? A: Häufig A. Rmahn: Einführung eines agilen Vrgehensmdells auf der Basis vn Werkzeugen und eines Leitbildes A. Rmahn präsentiert die Einführung eines agilen Vrgehensmdells über Leitbilder und Werkzeuge. Er thematisiert insbesndere die Frage, b alle, die sagen, sie seien agil, auch wirklich agil sind. Oder b nicht viel mehr die Vrstellung vrherrsche, dass jeder macht, was er will? F: [Kntext: Anzahl der Rllen ist wichtig.] Können Sie die Rllen kurz nennen? A: Prjektmanager, Entwicklungsleiter, Entwickler, Tester, Anfrderungsmanager F: Was heißt Ändern einer Iteratin? à geschben auf Diskussin F: [Kntext: Regeln] Was ist s eine Regel und wie sieht die aus? [rege Diskussin, Ergebnis der Diskussin: Abbildung in einem Tl] F: Wie viele Regeln gibt es? A: Pragmatisch: 6 F: Wie sieht die Werkzeugumgebung aus? Welche Werkzeuge werden bspw. für die Iteratinsplanung verwendet? A: Für die Iteratinsplanung wird Target Prcess verwendet. F: Haben Sie schn über Bni als Incentives nachgedacht? A: Nein.

5 F: Sie als Unternehmen bilden aus? Sllte das nicht der Jb der Hchschulen sein? [rege Diskussin] 1.5. U. Bmbsch, S. Bente, M. Hesselmann und G. Seifert: Applying SCRUM and XP in An Enterprise Cntext Im abschließenden Vrtrag stellte G. Seifert die Herausfrderungen der Einführung/Anwendung vn Scrum und XP im Unternehmensumfeld an. Dabei stellte er direkt die flgende Kernfragestellung auf: Was sind eigentlich die Prbleme? Zu späte Lieferungen, genervte Leute... das seien die Prbleme! D: [Kntext: Inaktivität in verteilten Prjekten.] Inaktivitäten [in Indien] hat was mit hhen CMMI-Level zu tun. F: [Kntext: Änderungen in Prjekten?] Verstehen Sie Prblem- und Änderungsmanagement wirklich als Blckadetaktik? [rege Diskussin] 2. Prtkll der Fishbwl-Diskussin Mit diesem Wrkshp wurde eine Neuerung eingeführt. Anstelle einer einfachen Pdiumsdiskussin wurde diesmal eine Fishbwl-Diskussin durchgeführt. Die thematische Einführung in die Fishbwl-Diskussin wurde vn André Schnackenburg (in Vertretung für Christian Lange) durchgeführt. Er wies darauf hin, dass ca. 30% des Umsatzvlumens im IT-Markt durch Mittel der öffentlichen Hand entstehen. Hinzu käme auch, dass es zusätzlich zum Business Case hier auch einen Plitical Case gebe. In diesem Kntext kmmt den Vrgehensmdellen eine weitere Rlle zu: Rechtssicherheit, Verlässlichkeit und Gleichbehandlung in Vergabeverfahren. Zusätzlich sei im Behördenumfeld zu bedenken, dass Prjekte sehr lange laufen und auch pausieren können. Ein nachvllziehbares und dkumentiertes Vrgehen sei hier unerlässlich. Weiterhin führte er aus, dass man Vrgehensmdell auch in den Bereich der Industrialisierung einrdnen sllte (Metapher: Kunst à Handwerk à Industrialisierung à Autmatisierung). Mit der reinen Anwendung vn Agilen Methden würden wir über den Bereich Kunst nicht hinauskmmen. Auf dieser Grundlage wurde die Fischbwl-Diskussin eröffnet und durch Oliver Linssen mderiert. Durch die rege Beteiligung an der Diskussin sind viele Aspekte der Themenbereiche Vrgehensmdelle, Prjektmanagement und Sftwareindustrialisierung diskutiert. Im flgenden Abschnitt sind die Ergebnisse dieser Diskussin strukturiert und zusammengefasst. Einstieg in die Diskussin ist die Metapher vn André Schnackenburg: Kunst à Handwerk à Industrialisierung à Autmatisierung Vllständige Umsetzung = vllendetes Vrgehensmdell

6 Begriff der Industrialisierung nicht klar à wenn industrielle Fertigung das Leitbild ist, ist das ein Rückschritt. Die Idee ist dch Trennung vn Handund Kpfarbeit à Es ist keine Fertigung. Sftware develpment is a game f... (Cburn) Fertigung ist Quatsch, wir erfinden. Fertigung i.s.v. Vervielfältigung ist keine Industrialisierung. Die ganze Metapher passt nicht. Reibungsverluste an Schnittstellen sind hch. Bei der Industrialisierung vn Kpfarbeit muss ich dafür srgen, dass Leute austauschbar sind usw. Industrielle Fertigung (Leitbild) hat sich für Kpfarbeit selbst überlebt. Direkte Übertragbarkeit ist wahrscheinlich nicht gegeben, aber: die Industrie hat Methdenbaukasten auf Basis eines Erfahrungsschatzes. Ähnliche Dinge sind wiederhlbar durch ähnliche Aktivitäten. In der Sftwareentwicklung fangen wir immer wieder vn Vrne an... Wir haben Methden und fangen dch nicht immer wieder vn Vrne an. Siehe SAP: Nebenbei nch einmal die kmplette Entwicklungsumgebung nch mal hchgezgen, aber schlechter als vrher à vrhandene Biblitheken nutzen und nur behutsam ändern wäre drt besser gewesen. Zum Thema Industrialisierung: Wie häufig haben wir ähnliche Aufgabenstellungen? Im Vergleich zum Autbau ich kann bei der Sftwareentwicklung nicht immer reprduzieren. Der Aufwand steckt immer in den Punkten drin, die neu sind. Die Erfahrung ist in den letzten Jahren gewachsen. Siehe früher Assembler, heute Applicatin Server im Internet. Was heißt denn eigentlich industrielle Fertigung? Außen vr: Prduzieren. Wichtig ist die hchgradige Arbeitsteilung. Die Ausbildung ist auch wichtig. Das ist ein Aspekt industrieller Fertigung: Austauschbarkeit vn Persnen durch einheitliche Ausbildung-/Fähigkeitsprfile. Industrialisierung heißt aber auch: Leute sinnvll an einer Sache arbeiten zu lassen Leute Kpfarbeit beschäftigt man anders als Bandarbeiter. Interessanter ist dch die Frage, wzu überhaupt industrialisiert? Landläufig ist die Vrstellung: Dampfmaschien + Fließband. Für Sftwareentwicklung gilt das nicht, sndern eher die Vrstellung der Zünfte: es wird festgelegt, wie was geht. Aus mehr Bedarf und mehr Abnahme flgt dann mehr Wachstum Mehr Wachstum als Industrialisierungstreiber macht keinen Sinn. Beispiel Frd T- Mdel: Mehr Bedarf? Was muss man tun, um einen Arbeiter nach 5 Minuten ans Fließband zu stellen können? Wie schaffe ich es, die Leute zu rekrutieren, die das machen, und wenn das klappt, warum nehme ich mir dann nicht die ganze Fabrik und stell sie nach Indien? Ist der Transfer auf die Sftwarenentwicklung möglich? Die Arbeit wird nicht weggenmmen, sndern lediglich die Arbeitsteilung ändert sich. Offshring funktiniert nicht. Das zeigt die Erfahrung mit der verlängerten Werkbank. Aufgabenteilung und Perspektiven sind wichtig. Die verlängerte Werkbank taugt nicht als Paradigma. Wichtiger ist, wie sieht die Kperatin aus, wie viel verdienen die Leute, kmmen die her etc. Bei-

7 spiel SAP: Pr/Kpf-Prduktivität ist gefallen: Ich kann Verbindungen schaffen... Grundgedanke Amazn: Die IT unterstützt den Menschen, weniger Fehler zu machen... Beispiel: Warum erflgt die Paketierung nicht gleich kmplett durch Srtieranlage? Amazns Psitin: Nein, weil wir durch Persnal kmpensieren und mit Unterstützung durch IT eine sanfte Frm der Mitarbeiterkntrlle haben. Geht das auch für die IT à naja, ja, z.b. Cde Quality Werkzeuge, aber würden wir es uns trauen, einem Mitarbeiter eine rte Ampel auf dem Mnitr anzuzeigen? Ja, s etwas gibt es es ist jedch nch in den Arbeitsablauf integriert [die Leute sind ausgebildet?] Möglich wäre es. Knsequenz: Mehr Arbeit mit weniger Leuten; Kunden wllen aber mehr. Man braucht Werkzeuge. Da ist eine Abhängigkeit (Aktivitäten/Techniken etc.). Ein Glaubenskrieg ist irrelevant. Ein Link zu den Werkzeugen ist wichtig. Ein Methdenbaukasten ist wichtig. Und die Kntinuität der Methden ist wichtig. Unterschiedliche Wahrnehmung vn Qualität: Einerseits Naja, aber auch Falsch Es gibt nun mal unterschiedliche Auffassung vn was ist ein Fehler und was sind die Flgen. Naja, bei Sftware: Einen Bug kann ich beheben der einen Wrkarund machen. Die Aussage: Die Qualität ist nicht gut ist aber falsch, die Wahrnehmung unterscheidet sich. These: Reichhaltige Vrgehensmdelle rientieren sich am Ideal der Industriellen Fertigung. Flgt daraus: Agile Mdelle rientieren sich nicht daran? W ist der Gegensatz, wenn alle sagen, das können wir in einem reichhaltigen Vrgehensmdell machen der, dass kann auch mit einem agilen scheitern... W ist der Unterschied? Möglicherweise ist der Unterschied in Art und Umfang der zu erstellenden Dkumente. Das Menschenbild ist essenziell. Ein taylristisches Mdell passt nicht für die Sftwareentwicklung. Die Prduktivität leidet, wenn man zu stark arbeitsteilig wird. Der Manchester-Kapitalismus hat nicht funktiniert wg. szialen Schwierigkeiten à wir sind aber schn einen Schritt weiter... Wir reden dch aber eigentlich über die R&D-Abteilung und nicht über das Fließband... Ist das wirklich klar? Was wäre denn da mit Schiff- der Hchbau? S einfach ist das nicht und es ist auch nicht allen klar... Drt gestaltet sich das in etwa s: Ähnlichkeit der Prdukte = Ähnlichkeit des Vrgehens. Geht das auch für die Sftwareentwicklung? Suchen wir an der richtigen Stelle? Interessant ist dch wirklich R&D. Man sllte mal schauen, wie R&D-Abteilungen z.b. in Pharmaindustrie arbeiten. Machen die immer alles neu? Es liegt auch am Gegenstand: Kperatin ist erfrderlich und die Strukturen sind viel enger gewrden. Wichtiges Stichwrt: Skalierung. Werde grß und werde effizienter Aber bei der Sftwareentwicklung gilt dch: Werde nicht zu grß, snst wirst du schlechter...

8 Die Markteintrittsbarrieren sind auch ganz andere. Kperatin betrifft nicht nur einzelne Entwickler, sndern auch grße Firmen. Die Generierung vn Mehrwert durch Nachnutzung vn vrhandener (freier) Sftware spielt da auch eine Rlle. Kmplexität ist prblematisch à Das Ziel sllte es sein, die Kmplexität zu reduzieren. Man wird vn der Realität zur iterativen Vrgehensweise gezwungen (bei bestimmter Kmplexität, man macht Erfahrungen und es gibt auch natürliche Iteratinen). Das heißt aber, die klassischen Industrien sind auch nicht besser. ABER: in dem Mment, in dem man weiß, wie es geht, wird in hhem Maße standardisiert und die Effizienz gesteigert Standardisieren, wfür, für wen à Naja, eigentlich sind das [die Standards/Nrmen, Anm. d. Prtkllanten] Halbfabrikate... Schlusswrt: Die Diskussin über Vrgehensmdelle ist Antwrt auf das Versagen der Industrialisierung vn Kpfarbeit. Zusammenfassung Die Fishbwl-Diskussin wurde durch André Schnackenburg eingeleitet. Seine aufgestellte Metapher: Kunst à Handwerk à Industrialisierung à Autmatisierung lieferte den Einstieg. Er stellte weiterhin die These auf, man könne bei blßer Verwendung agiler Methden nicht über die Kunst hinauskmmen. Inflge wurde diskutiert, (1) was eigentlich genau unter Industrialisierung zu verstehen sei. Insbesndere, b Industrialisierung (2) für die Sftwareentwicklung überhaupt umsetzbar sei, der b das nicht vielmehr in den Bereichen stattfinden sllte, in denen klassische Frschung und Entwicklung betrieben werde (R&D). Im Kntext der Diskussin wurden dabei verschiedene Aspekte der Industrialisierung angesprchen, wie z.b. Fließbandfertigung, Menschenbilder der Markt- bzw. Geschäftsmdelle swie Kperatin. Diese vielfältigen Facetten, die in der regen Diskussin vrgetragen wurden, zeigen den Bedarf zum Dialg in diesem Bereich. Das Schlusswrt zur Fishbwl-Diskussin gibt auch einen Hinweis darauf, wie Vrgehensmdelle hier psitiniert werden können. Sind sie nun Lösung der Ursache der Prbleme in der Sftwareentwicklung. Das Schlusswrt legt nahe, dass Vrgehensmdelle als Medikamente dienen, um Prbleme zu kurieren, deren Ursache wir aber nch nicht vllständig verstehen. In diesem Sinne gilt wie bei allen Medikamenten: auf die richtige Anwendung und Dsis kmmt es an. 3. Abschließendes Dieser Wrkshp wäre hne die Hilfe vn vielen Seiten nicht durchführbar gewesen. Allen Beteiligten am Wrkshp gilt unser Dank. Selbstverständlich sind hier die Beitragenden zu nennen und insbesndere Prf. Dr. Rausch für die freundliche Übernahme der

9 Keynte zum Wrkshp. Ebens wllen wir uns bei den Organisatren der Jahrestagung der Gesellschaft für Infrmatik für den Rahmen in Leipzig bedanken. Weiterhin möchten wir uns bei Prgrammkmitee für die reibungslse Durchführung des Reviewprzesses bedanken. Dem Prgrammkmitee gehörten flgende Persnen an: Prf. Dr. Dr. h.c. Manfred Bry Dr. Jens Calamé Jens Cldewey Dr. Christf Ebert Jan Friedrich Dr. Thmas Greb Patrick Keil Dr. Marc Kuhrmann Dr. Ralf Kneuper Dr. Christian Lange Dr. Oliver Linssen Dr. Jürgen Münch Prf. Dr. Rland Petrasch Prf. Dr. Andreas Rausch Dr. André Schnackenburg Thmas Ternité TU München Hamburg it-agile GmbH, München Vectr, Stuttgart 4Sft GmbH, München freiberuflicher Berater, Bremen TU München TU München freiberuflicher Berater, Darmstadt BVA/BIT, Köln Liantis GmbH & C. KG Fraunhfer IESE, Kaiserslautern TFH Berlin TU Clausthal BIT, Köln TU Clausthal Wir bedanken uns bei allen Beteiligten des Wrkshps und der Tagungsleitung vr Ort in Leipzig. Marc Kuhrmann, Patrick Keil, André Schnackenburg und Oliver Linssen