Business Analysis als Bestandteil eines Prozess-Modells bei IT-Projekten

Zusammenfassung
Allgemeines
Kein Modell - Entwicklung auf Zuruf
Lineare Modelle
Nichtlineare iterative Modelle

Vgl. hierzu Kosten und Aufwände mit einem Abschnitt über Prozessmodelle in der Praxis und deren scheitern

Auf dieser Seiten geht es nicht um die Grundlagen der Projektarbeit, sondern nur um die Einordnung der Analysephase in einem Projekt. Besuchen Sie für eine umfassende Einführung für Projektarbeit in der IT z.B. http://www.projekthandbuch.de/

Zusammenfassung

In diesem Kapitel wird die Einbindung der Business Analysis in verschiedenen gängigen Prozess-Modellen dargestellt. Dazu werden die Prozessmodelle und ihre Spezifika kurz dargestellt. Das Kapitel ist auch geeignet, um einen ersten Eindruck über Vorgehensmodelle für IT-Projekte zu erhalten, geht jedoch nicht tief genug, um auf weitere Studien zu verzichten. Unterteilt wird in Projekte ohne Vorgehensmodell, lineare Modelle, in denen nach einer Analysephase das fertige Produkt in einer einzigen Release fertig gestellt wird, und iterative Vorgehensmodelle, bei denen ein Produkt in mehreren Teilversionen erstellt wird und ggf. neue Anforderungen aus Rückkopplungen mit bereits fertig gestellten Teillösungen erwachsen. Auf die Eigenheiten objektorientierter Vorgehensmodelle (die nicht unbedingt etwas mit objektorientierter Programmierung zu tun haben müssen) und eXtrem Programming wird ebenfalls kurz eingegangen. Kritik an der Umsetzung von Prozess-Modellen findet sich im Abschnitt Kosten und Aufwände.

Allgemeines

Im Laufe der vergangenen Jahrzehnte gab es verschiedene Modell-Ansätze zur Durchführung von IT-Projekten. Das Spektrum ist weit gefächert und reicht von gar keinem strukturierten Ansatz über mehr oder weniger vage intuitive Ansätze bis hin zu standardisierten Prozess-Modellen. Im Moment ist der auch hier kurz dargestellte RUP modern.

Über die Notwendigkeit einer Analyse als Bestandteil eines IT-Projekts sollte nicht diskutiert werden müssen. Die Erfahrung zeigt jedoch, dass dieser Bestandteil regelmäßig unterschätzt und zu niedrig angesetzt wird, weswegen die Notwendigkeit einer ausführlichen Analyse immer wieder betont werden muss. Die Gründe dafür sind vielfältig. Charakteristisch ist, dass Fachanwender unausgesprochen davon ausgehen, dass ihre Probleme und Anforderungen klar sind und vom IT-Personal ohne weitere Erklärungen im Detail verstanden werden. Regelmäßig wird auch von Fachanwendern davon ausgegangen, dass nicht kommunizierte Anforderungen berücksichtigt werden, da sie ja ebenfalls klar oder offensichtlich sind. Anders herum werden jedoch IT-Prozesse von den Fachanwendern nicht verstanden. Dabei wird auch keine Notwendigkeit erkannt, dass sich Fachanwender zumindest im Rahmen der Anforderungsanalyse und des Abnahmetests in ein Prozess-Modell einfügen müssen. Software-Entwicklung wird nicht von Programmierung unterschieden und als einfach betrachtet, Aufwände für Design oder Test werden gar nicht in Betracht gezogen. - Realistisch ist eine Größenordnung von 30% bis 40% des gesamten IT-Projekts für die Analysephase.

Beispiel aus der Praxis

Ein Fachanwender insistierte auf einer anderen Darstellung eines Algorithmus in einem Anforderungsdokument, der verbal und durch ein Beispiel beschrieben war. Der Algorithmus war dem technischen Personal klar, es handelte sich lediglich um eine lineare Gleichung. Der Fachanwender konkretisierte seinen Wunsch jedoch nicht weiter. Zudem schrieb er das Wort Algorithmus mit einem y. Der technische Projektleiter lehnte den Änderungswunsch auf dem formalen Wege ab.

Gelegentlich und bevorzugt in kleineren Unternehmen kommt es auch vor, dass die Anwendung eines definierten Prozess-Modells, dabei insbesondere eine dokumentenorientierte Arbeitsweise, als graue Theorie und akademische Weltfremdheit betrachtet wird. Dokumentation generell, sowie Qualitätsmanagement, das über einen unstrukturierten Test hinaus geht, wird mit dieser Argumentation abgelehnt. Dokumentation und auch eine genaue Analyse wird ausschließlich als Kostenfaktor angesehen.

Man kann in zwei grundlegende Formen von Prozess-Modellen unterscheiden:

lineare Modelle
nichtlineare iterative Modelle

Bei linearen Modellen wird ein Produkt einmal geplant und dann realisiert. Das fertige Produkt wird in einer einzigen Release ausgeliefert.

Bei nicht-linearen Modellen wird ein Produkt in mehreren Teilversionen erstellt, es wächst in gewissem Sinne. Bereits die erste Version kann produktiv genutzt werden, erfüllt jedoch noch nicht alle Anforderungen, die langfristig realisiert werden müssen. Während die erste Version noch erstellt wird, wird die zweite Version häufig bereits geplant. Im Gegensatz zum linearen Modell, bei dem man von einer "perfekten Planung" ausgeht, nimmt man bei nicht linearen Modellen z.T. gravierende Änderungen am bereits fertig gestellten Produkt in Kauf.

Lineare Modelle findet man heute kaum noch. Begründet wird dies i.d.R. damit, dass das Geschäft zu dynamisch oder zu komplex ist, um es einmalig zu spezifizieren. In meiner eigenen Berufspraxis erlebe ich jedoch i.d.R. nicht eine zu hohe Dynamik oder Komplexität, sondern eher illusorische Terminvorstellungen und einen trägen Willensfindungsprozess beim Auftraggeber. Dadurch, dass häufig ein Liefertermin feststeht, ehe überhaupt die genauen und vollständigen Anforderungen an das Produkt definiert sind, bleibt meist gar nichts anderes übrig, als eine zunächst unbefriedigende oder halbfertige Lösung zu liefern, die später verfeinert wird, sofern das Budget noch nicht komplett verbraucht worden ist.

Im Rahmen einer ausführlichen Darstellung über Risikomanagement findet sich bei http://neon.airtime.co.uk/users/wysywig/risk_1.htm folgende kernige Aussage, die sich auch auf die Business Analysis übertragen lässt:

Another prejudice about this super role (gemeint ist der Risikomanager) is that today's systems are too complex for any one person to really understand at the level of professional competence. Remember the following as a hard and fast rule: Having an opinion is a far cry from understanding, but an opinion is closer to understanding than understanding is to professional competence, and professional competence is the starting point for solving difficulty problems. From this perspective, understanding is a relatively cheap commodity, but even understanding is almost impossible across the full span of today's systems.

Ich stelle hier für nicht IT-Spezialisten die gängigen Prozess-Modelle recht knapp vor, ohne sie im Detail zu vertiefen; auf das Spiralmodell wird verzichtet, da es lediglich ein Metamodell ist, das für einzelne Teilprojekte eine Auswahl eines geeigneten Prozess-Modells vorsieht, Prototyping existiert nicht für sich sondern ist stets Teil eines anderen Modells. Vom in Deutschland üblichen V-Modell abgesehen wird auch auf landesspezifische Vorgehensmodelle, die die jeweiligen Regierungen bei öffentlichen Projekten fordern (wie z.B. das britische SSADM ), verzichtet. In der Praxis werden diese Modelle unternehmensspezifisch und projektspezifisch angepasst, eine ultimate Wahrheit im Sinne eines auf jedes Problem anwendbaren Modells existiert m.E. nicht. Für eine gründlichere Einführung verweise ich auf das hervorragende "Lehrbuch der Software-Technik" (Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung) von Helmut Balzert (vgl. auch den Quellennachweis). Die Graphiken bei den einzelnen Modellen lehnen sich teilweise an diese Quelle an.

Kein Modell - Entwicklung auf Zuruf

Kein Modell bedeutet, dass das Projekt keinem definierten und strukturierten Ansatz folgt. Ein Produkt wird auf Zuruf entwickelt, übergeben, ausprobiert und, nachdem alle Reklamationen behoben wurden, in Betrieb genommen.

Hier interagiert der Endanwender unmittelbar mit dem Entwickler, Platz für einen Business Analysten ist hier nicht, eine Analyse als Teil des Gesamtprozesses findet auch nicht statt.

Gar keinen strukturierten Ansatz und intuitive Ansätze findet man i.d.R. in kleinen Organisationen, deren IT-Personal hauptsächlich aus Autodidakten, Anfängern oder Studienabbrechern besteht, die noch niemals Berührung mit einem standardisierten Prozess-Modell hatten und noch niemals etwas vom Software Development Life Cycle gehört haben. Dafür hat das technische Personal meist eine recht klare Vorstellung davon, was die Fachabteilung macht. Der Programmierer übernimmt die Analystenrolle nebenbei und testet i.d.R. auch selbst. Bei dieser Arbeitsweise wird jedes Problem ad hoc und auf Zuruf gelöst. Solch eine Vorgehensweise kann recht gut funktionieren, wenn die zu bearbeitenden Probleme sehr klein sind (wenige Personentage) und an die Lösungen keine Ansprüche bzgl. Änderungsfreundlichkeit gestellt werden. Bereits bei mittleren Projekten versagt das Fehlen einer strukturierten Arbeitsweise, und wachsende Unternehmen, die sich von der Garagenfirma zum Mittelständler bewegen, haben hier ein ernsthaftes Problem, wenn nicht rechtzeitig ein strukturierter Ansatz eingeführt wird. Erfahrungsgemäß ist sehr viel Überzeugungsarbeit notwendig, wenn erstmals Strukturen etabliert werden sollen, nicht zuletzt, da Privilegien einzelner Mitarbeiter beschnitten werden. So betrachtet kann man einen Business Analysten auch als Coach anheuern, er sollte allerdings auch von Software-Entwicklung und Projektmanagement eine Ahnung haben, da sich die Defizite nicht auf den reinen Spezifikationsprozess beschränken.

Ein anderer typischer Fall für solch ein Vorgehen sind Eigenentwicklungen von Fachanwendern. Die Fachanwender sind sich meist gar nicht darüber klar, dass sie Software entwickeln, wenn sie selbst mit Office-Produkten (Tabellenkalkulation und Datenbanken) kleine Lösungen schreiben, die im Laufe der Jahre weiter wachsen und produktionskritisch werden.

Offensichtlich finden im Rahmen der Produktentwicklung und -optimierung sehr viele Änderungen statt, die den Code im Laufe der Zeit kaum noch handhabbar machen. Es ist auch vollkommen unklar, gegen welche Anforderungen das Produkt getestet wird. Somit wird das Finden von Fehlern schwer und bleibt letztendlich häufig dem Zufall überlassen. Da keine definierten Anforderungen existieren, kann Qualität nicht gemessen werden. Die Abhängigkeit vom nicht zu ersetzenden Entwickler stellt ebenso ein nachhaltiges Risiko dar, wie die Unklarheit darüber, was das Produkt eigentlich genau macht.

Lineare Modelle

Wasserfallmodell

Das Wasserfallmodell sollte unbedingt verstanden werden. Es ist Basis für alle anderen Modelle.

Das Wasserfallmodell ist ein lineares Modell und kann historisch als ein sehr früher strukturierter Ansatz zur Umsetzung eines IT-Projekts betrachtet werden, der aus einer Zeit vor den "Mäuseschubsern" stammt (so nennen Host-Entwickler die PC-Entwickler und PC-Anwender). CPU-Zeit war teuer, Rechner waren langsam und das Denken stand im Vordergrund. Beim Wasserfallmodell muss jeder Prozessschritt vollständig und richtig abgeschlossen sein, ehe der nächste beginnt. Da jedoch Perfektion reine Theorie ist, findet vom jeweils nachfolgenden Prozessschritt eine Rückkopplung zum vorhergehenden Schritt statt, um vorhandene Lücken zu schließen. In der Praxis bedeutet dies, dass gelegentlich mehrere Schritte nach oben gewandert werden muss, und dann die nachfolgenden Ergebnisse nochmals modifiziert werden müssen; dies ist zwar weder vom theoretischen Ansatz noch aus Kostensicht erwünscht, jedoch eher die Regel als die Ausnahme. Je später in der Prozesskette ein Fehler erkannt wird, um so teurer ist dessen Behebung.

vgl. [Balzert2] S. 99
der wiederum Royce WW., Managing the development of large software systems zitiert.

Jeder einzelne Prozessschritt führt zu abgeschlossenen Ergebnissen in Form eines Dokuments bzw. Codes. Ein Folgeschritt wird erst begonnen, wenn der vorherige Schritt abgeschlossen ist.

Der Business Analyst ist vor allem mit den System- und Software-Anforderungen zu Gange, übernimmt auch den nicht-technischen Teil der Analyse und sollte für den technischen Teil der Analyse und den Entwurf der Software beratend bereit stehen. Da der Test letztendlich gegen die Anforderungsdokumente stattfindet, kann er auch mit dem Tester kooperieren. Anforderungsdokumente müssen generell gut genug sein, um Testdokumente zu schreiben, jedoch sind es nicht selten die Autoren von Testdokumenten die noch vor der Codierung nachweisen, dass eine Anforderung gar nicht testbar und widersprüchlich ist.

Idealtypisch betrachtet benötigt man den Fachanwender nur während der Definitionsphase des Produkts, dann hört er einige Zeit nichts mehr, und bekommt am Ende das von ihm bestellte Produkt komplett geliefert.

Rückkopplungen sollten immer nur zum benachbarten Prozessschritt stattfinden, sonst entsteht kostentreibender Wildwuchs. In der Praxis überspringen jedoch Mitarbeiter gerne Zwischenschritte. Das Verfahren setzt also Disziplin voraus. Gerade diese geforderte Disziplin macht das Modell bei Fachanwendern unbeliebt, die sich nicht verbindlich festlegen wollen bzw. nicht genügend Zeit und Engagement mitbringen, um ihre Anforderungen fest zu schreiben.

Das Verfahren ist sehr einsichtig und mit geringem Managementaufwand verbunden. Ein wesentlicher Vorteil ist, dass Personalressourcen nach Abschluss eines Prozessschrittes wieder frei gesetzt werden können und die Mitarbeiter zumindest eine gewisse Sicherheit haben, sich nicht weiter um das Projekt kümmern zu müssen. Nachteilig ist eine gewisse Unflexibilität. Sollten sich also die Anforderungen tatsächlich bewegen, ohne dass dies der Fachanwender vorhersehen konnte, dann bleibt nichts anderes, als die Fertigstellung des Produkts abzuwarten und dann einen Änderungsantrag (Change Request) zu stellen. In solchen Geschäftsumgebungen ist allerdings ein lineares Prozess-Modell nicht die Vorgehensweise der Wahl. Wichtig ist, dass sich der mit dem Modell verbundene Dokumentationsprozess nicht verselbstständigt und somit der Qualitätsmanager zum Bürokraten degeneriert.

Ein Prototyp kann in das Wasserfallmodell integriert werden. Während die Anforderungen definiert werden, kann unterstützend ein funktionsloser Prototyp gebaut werden, der die Benutzeroberfläche darstellt, gegen Ende der Spezifikationsphase kann auch ein funktionsreduzierter Prototyp eingeschoben werden um die Spezifikation zu verifizieren.

V-Modell

Das V-Modell ist ebenfalls ein lineares Modell und stellt eine Erweiterung des Wasserfallmodells um die Qualitätssicherung (Testfälle) parallel zu den Entwicklungs-Prozessschritten dar. Wird im Wasserfallmodell der Test nur recht vage als abschließender Entwicklungsschritt nach der Codierung gesehen, definiert das V-Modell sehr klar die technischen Tests (Modultest bzw. unit test, Integrationstest, Systemtest) und den fachlichen Test (Abnahmetest bzw. acceptance test). Dieses Vorgehensmodell ist Standard im deutschen öffentlichen Dienst, wird auch außerhalb der IT verwendet, und es wurde auch von der Industrie übernommen.

Beim Malen war ich noch nie gut, aber das V ist ungefähr sichtbar.

Die Rolle des Business Analysten ist analog zu der beim Wasserfallmodell, jedoch ist hier seine Mitwirkung an der Entwicklung des Abnahmetests sehr klar sichtbar. Natürlich muss der Kunde das Produkt abnehmen und zeichnet auch für den Abnahmetest verantwortlich. Aufgrund der Konfliktsituation zwischen Auftraggeber und Auftragnehmer kann der Business Analyst also nur dann den Testplan schreiben, wenn er auch vom Auftraggeber dazu beauftragt wurde und dem Auftragnehmer keine Rechenschaft schuldig ist. Arbeitet der Analytiker für den Auftragnehmer, so sollte der Auftraggeber einen unabhängigen Tester anheuern, der auch den Testplan selbst schreibt. In dieser Konstellation nimmt der Analytiker lediglich eine beratende Rolle ein und hat kein Mitwirkungsrecht an der Erstellung der Testpläne. Sehr wohl wird er jedoch die Testpläne prüfen und ggf. nachweisen, dass nicht gegen die Spezifikation getestet wird.

Die Tests gehen von unten nach oben. Jedes Programmstück, das vom Entwickler fertig geschrieben wurde, wird zunächst von ihm getestet. Einzelne Module oder Klassen werden - vereinfacht gesagt - dann im Rahmen des Integrationstests dahingehend überprüft, ob sie auch wirklich korrekt miteinander kommunizieren. Der Systemtest weist nach, dass das gesamte Produkt korrekt läuft und auch nicht abstürzt. Der Abnahmetest weist nach, dass das Produkt auch das tut, was im Anforderungsdokument beschrieben worden ist.

Soweit die Theorie. Die Wahrheit ist leider, dass sehr häufig Produkte schlecht oder gar ungetestet ausgeliefert werden und in den ersten Produktionsstunden Abstürze nachgewiesen werden.

Beispiel aus der Praxis

Ein Tester sollte ein Produkt testen, das schon deutlich hinter dem Zeitplan geliefert wurde. Bereits im look and feel - Test (also nur unstrukturiertes herum tippen und herum klicken in der Anwendung) konnte er binnen zwei Tagen über 100 Fehler nachweisen, darunter Verletzungen der Constraints der Datenbank und Abstürze der Anwendung. Der Tester brach den Test ab. In einer hitzigen Diskussion mit dem Auftraggeber erklärte der Tester, dass er keine strukturierten Tests der eigentlichen Verarbeitungsprozesse vornehmen würde, wenn nicht einmal der Geradeausflug bei Eingaben in die Bildschirmmasken funktionierte und dass er davon ausgeht, dass das Produkt vor Auslieferung nicht getestet worden sei. Weder seine Aufgabe noch die des Business Analysten sei es, die Arbeit der Entwicklungsmannschaft zu machen. Der Entwicklungschef des Software-Hauses erklärte allen Ernstes, dass kein Produkt ungetestet das Haus verlassen würde. Monate später traf der Tester einen früheren Mitarbeiter des Software-Hauses wieder, der ihm bestätigte, dass die fragliche Software ohne Test ausgeliefert worden war.

Das V-Modell in Reinkultur ist eher für sehr große Projekte geeignet, jedoch kann es an mittlere und kleinere Projekte angepasst werden. Routinemäßiges schreiben von Testklassen (und zwar noch bevor die zu testende Klasse gebaut wird) und regelmäßige automatisierte Integrationstests sollten grundsätzlich stattfinden, egal, welches Prozess-Modell verwendet wird. Eine konsequente Anwendung solch einer Test-Vorgehensweise verspricht eine hohe Produktqualität. Auch hier muss darauf geachtet werden, dass sich der Dokumentationsprozess nicht verselbstständigt und Dokumente zum Selbstzweck werden. Im schlimmsten Fall werden Zentimeter dicke Papierstapel nur deshalb ausgefüllt, weil dies vom Qualitätsmanagement so gefordert ist und eine Anpassung des Modells an die jeweiligen konkreten Projekte nicht möglich bzw. gewünscht ist.

Beispiel aus der Praxis

Ein Gruppenleiter einer IT-Abteilung eines großen Unternehmens aus dem Finanzbereich erklärte einmal, dass alle Aufgaben, die sich in weniger als sechs bis zwölf Wochen erledigen lassen, von ihm selbst bei Neuentwicklungen nicht als Projekt deklariert würden, da sonst der bürokratische Aufwand nur auf Grund der Bezeichnung "Projekt" in keiner Relation mehr zur tatsächlich zu leistenden Arbeit stünde. Statt dessen sprach er von Wartung und Pflege vorhandener Produkte, obwohl genau betrachtet komplett neue (Teil-) Produkte entwickelt wurde.

Seite der IABG zum V-Modell: http://www.v-modell.iabg.de/

Nichtlineare iterative Modelle

Inkrementelles Modell

Beim inkrementellen Modell werden zwar im Sinne des Wasserfallmodells oder V-Modells die Benutzeranforderungen zunächst vollständig aufgenommen, jedoch wird die Spezifikation nicht in einem Schritt umgesetzt. Statt dessen werden die Anforderungen priorisiert. Zunächst wird ein Rumpfsystem (eine Version 1 des Produkts) definiert, das die minimalen Anforderungen erfüllt, die abgedeckt sein müssen, damit der Fachanwender seine Arbeit machen kann. Dieses System wird in Betrieb genommen und anschließend werden weniger wichtige Anforderungen in einer Folgeversion implementiert, die die Vorgängerversion ablöst. Abhängig von der Projektgröße kann man i.d.R. mit mindestens drei und höchstens sechs Versionen rechnen, selten mehr.

Da die Anforderungen vollständig sind und nur nicht rasch genug umgesetzt werden können, haben die IT-Leute einen entscheidenden Vorteil gegenüber anderen nichtlinearen Modellen: Sie kennen bereits die Änderungen, die sie noch realisieren müssen, sie haben sie nur noch nicht realisiert. Dieses Wissen hat nachhaltige Auswirkungen auf die Kosten, denn es ist sicher gestellt, dass keine grundlegend falschen Ansätze in Architektur und Design des Systems gewählt werden. Das Refactoring von Version zu Version kann klein gehalten werden.

Die Rolle des Analysten ist analog zum Wasserfall- bzw. V-Modell, u.U. kann er sich bereits im Laufe der Erstellung der Version 1 aus dem Projekt ganz oder doch weitgehend zurück ziehen. In Ansätzen gilt dies auch für Architekt und Designer, da ja auch die technische Planung für alle Versionen vollständig abgeschlossen werden kann, bevor sie implementiert und getestet werden.

Geeignet ist das Modell vor allem dann, wenn die Anforderungen klar definiert sind, klare Prioritäten gesetzt werden können und eine schrittweise Einführung einen Zeitvorteil gegenüber einer einmal erstellten "all singing all dancing" - Version verspricht.

Evolutionäres Modell

Abweichend vom inkrementellen Modell sind beim evolutionären Modell die Anforderungen des Gesamtprodukts noch nicht bekannt. Spezifiziert, implementiert und in Produktion genommen wird Version für Version.

Der Analytiker muss hier mehrfach ans Werk, hat aber zwischendurch u.U. größere Pausen. Dadurch, dass der Analytiker jedoch zwischendurch nicht in Winterschlaf verfällt, sondern sich anderen Aufgaben widmet, kann es für die nächste Produktversion zu Verfügbarkeitsengpässen kommen. Zwar sagt man, dass niemand unersetzlich ist, jedoch misst niemand die Kosten für diese Unabhängigkeit. Wechselt man den Analytiker aus, so muss der Nachfolger u.U. das vollständige und sehr produktspezifische Know How seines Vorgängers nochmals aufbauen. Herrscht großer Zeitdruck, so sollte der Auftraggeber dafür sorgen, dass der Analytiker verfügbar bleibt und in anderen Projekten lediglich nieder priore Arbeiten übernimmt. Sofern möglich kann auch ein nebenläufiges Prozessmodell gewählt werden, bei dem der Analytiker kontinuierlich beschäftigt bleibt.

Augenscheinlich für IT-Spezialisten kann dieses Vorgehensmodell teuer werden, eine Einsicht, die Nicht-IT-Spezialisten nur schwer vermittelbar ist: Stellt sich heraus, dass nachfolgende Versionen mit neuen Anforderungen zu technischen Konzeptbrüchen bzgl. der Vorgängerversion führen, so sind umfangreiche technische Arbeiten, insbesondere beim Refactoring des Codes, und die damit verbundenen Kosten unvermeidbar. Diese technischen Konzeptbrüche sind an der Benutzeroberfläche u.U. gar nicht richtig sichtbar bzw. schlagen sich nur in kleinen optischen Änderungen nieder. Noch teurer wird es, wenn sich herausstellt, dass die spezifizierten Anforderungen zwar korrekt umgesetzt wurden, sich jedoch in der Praxis zeigt, dass der Fachanwender Forderungen gestellt hat, die falsch oder unnötig waren. Als Faustregel kann gelten, dass Unwissenheit der teuerste, Unentschlossenheit der zweit teuerste und Zeitdruck der dritt teuerste Kostenfaktor ist.

Dieses Vorgehensmodell wird i.d.R. dann gewählt, wenn einerseits von Anfang an Zeitdruck herrscht, andererseits der Willensfindungsprozess des Fachanwenders nicht abgeschlossen ist oder sich das Geschäft tatsächlich bewegt. Charakteristisch ist, dass die Fachabteilung zuerst die Version im Einsatz sehen muss, und erst dann entscheiden kann, was sie davon wirklich gebrauchen kann und welche weiteren Anforderungen gestellt werden können. Helmut Balzert zitiert hier in seinem Lehrbuch der Software-Technik [Balzert2] S. 120 den netten Spruch: "I can't tell you what I want, but I'll know it when I see it." - Der Schritt zum so-habe-ich-es-mir-nicht-vorgestellt-Syndrom ist nicht weit.

Dieses Modell gilt auch dann, wenn ein erfolgreich eingesetztes Altprodukt weiter entwickelt wird.

Nebenläufiges Modell

Das nebenläufige Modell ähnelt dem evolutionären Modell insofern, als die Anforderungen an das Gesamtsysten nicht bekannt sind, wenn die erste Produktversion in Betrieb geht. Jedoch findet eine Parallelisierung der Weiterentwicklung statt. Anstatt auf den Betrieb der ersten Version zu warten und damit Erfahrungen zu sammeln, um dann die zweite Version zu spezifizieren, wird die zweite Version dann spezifiziert, wenn die erste noch in Entwicklung ist. Dies erfordert natürlich, dass der Willensfindungsprozess des Fachanwenders wie auch beim Wasserfall- oder V-Modell nicht voraussetzt, dass er eine Version sieht, ehe er neue Anforderungen stellen kann. Sofern die Spezifikationsphase für die Folgeversion noch nicht abgeschlossen ist, wenn die Vorgängerversion in Betrieb geht, wird natürlich wie beim evolutionären Modell Feedback berücksichtigt.

Parallelisierung ist stets eine Folge des Wunsches nach Zeitgewinn, so auch hier.

Der Business Analyst spielt bei diesem Modell eine zentrale Rolle und er wird auch kontinuierlich in Anspruch genommen. Wesentlich ist, dass die Kommunikationswege kurz und die einzelnen Team-Teile nicht voneinander isoliert sind. Der Fachanwender definiert zuerst ein Rumpfsystem, das für sich implementiert werden kann. Noch während der Implementierung kann der Fachanwender weitere Anforderungen formulieren. Ein wahrer Wust von neuen Anforderungen steht i.d.R. ins Haus, wenn man eine halb fertige Version des Produkts vorstellt, bei der der Anwender schon etwas sehen kann. Soweit die Anforderungen klar genug sind, kann noch bei der Erstellung der aktuellen Version darauf geachtet werden, dass die Software dahingehend erweiterbar bleibt, allerdings sollte davon abgesehen werden, die laufende Produktentwicklung on the fly zu ändern. Die Designer und Entwickler geben selbst Feedback, das ebenfalls dem Fachanwender als Anregung dienen kann. Schließlich geht die erste Version in Betrieb und die Fachanwender können ihre Erfahrungen auswerten.

Das Verfahren arbeitet zügiger als das evolutionäre Modell, kann jedoch in Aktionismus enden. Die Fachanwender müssen zur Disziplin gerufen werden. Erfahrungsgemäß existiert eine Erwartungshaltung dahingehend, dass ausgesprochene Anforderungen noch in die aktuelle Version mit aufgenommen werden sollen. Weiterhin setzt die Parallelisierung voraus, dass der Auftraggeber entscheidungsfreudig und verläßlich in seinen Entscheidungen ist. Verzögert er eine Entscheidung, so steht der gesamte Prozess. Revidiert er eine Entscheidung, so müssen abhängig vom Projektfortschritt nicht nur einige Seiten im Anforderungsdokument modifiziert werden, sondern auch Teile des Software-Designs. Aus Sicht des Entwicklerteams wird damit das Ziel bewegt (vgl. hierzu die Tücken der Anforderungsanalyse). Der Projektleiter muss mit Unterstützung des Analytikers also strikt darauf achten, dass es abgeschlossene Versionen der Anforderungsdokumente gibt, die zu vollständigen neuen Produktversionen führen; und nicht, dass während der Spezifikation für eine neue Version Anforderungen zusätzlich als Change Request in die aktuell laufende Version eingehen.

Ein nebenläufiges Modell handzuhaben stellt hinsichtlich der Anforderungen an das Management den Gegenpol zum Wasserfallmodell dar und es ist nicht für einen Junior-Projektleiter geeignet, der gerade einen zweiwöchigen Crash-Kurs in Projektmanagement absolviert hat. Zwar gibt es nach wie vor dieselben klar abgegrenzten Prozessschritte wie bei den linearen Modellen, jedoch nur in Bezug auf die jeweils aktuell in Arbeit befindliche Version. Zeitversetzt wird i.d.R. nicht nur die unmittelbare Folgeversion, sondern auch schon deren Folgeversion vorbereitet, indem Anforderungen sortiert und priorisiert werden. Nicht nur die Produktversionen müssen klar voneinander abgegrenzt werden, auch die Teammitglieder sind damit beschäftigt, sich hinsichtlich Ideen, Wünschen und Forderungen abzugrenzen. Da alle Teammitglieder i.d.R. an wenigstens zwei Versionen desselben Produkte parallel arbeiten, ist Stress und Verwirrung abzusehen.

Das Modell ist m.E. vor allem bei bewegten Zielen geeignet sowie bei klar definierten Produkten, die laufend fort entwickelt und mit neuen Features ausgestattet werden. Sehr gut fährt man mit diesem Modell, wenn man einen klar umrissenen Auftrag für eine erste Version hat, der Auftraggeber jedoch noch während der Entwicklung von Version 1 über eine Version 2 nachzudenken beginnt und sich damit einverstanden erklärt, die Anforderungen bereits sammeln zu lassen. Damit wird für einen ohnehin früher oder später angestrebten Produkt-Relaunch bereits ein Fundament geschaffen und das übliche Chaos im Relauch-Vorfeld eingedämmt. Ideen, die nicht notiert werden, gehen außerdem gerne verloren, oder aber sie werden einseitig und wenig durchdacht weiter verfolgt. Eine optimale Ausnutzung der Zeit, wie sie bei industriellen Fertigungsprozessen im Rahmen der "just in time delivery" angestrebt wird, habe ich bislang noch in keinem IT-Projekt erlebt, sollte also auch nicht nur deshalb erwartet werden, weil dieses Modell diese Idee verfolgt.

RUP - Rational Unified Process

Das RUP ist eine Weiterentwicklung des recht vage formulierten nebenläufigen Modells und stellt analog zum V-Modell bei linearen Prozessmodellen bei den nichtlinearen Modellen einen gewissen Standard dar. Rational hat hierzu ein white paper ins Netz gestellt. In diesem Papier bzw. auch bei http://www.rational.com/products/rup/prodinfo.jsp findet sich folgendes Bild, das die einzelnen parallelisierten Projektphasen darstellt:

Der Business Analyst ist bei den Disziplinen Business Modeling und Requirements aktiv und sollte beratend bei Analysis & Design mitwirken. Da UML beim RUP die Standardmethodik zur Beschreibung der Anwendung ist, ist der Analytiker vorwiegend damit beschäftigt, Anwendungsfälle zu modellieren. Es liegt nahe, dass der Analytiker aus den Anwendungsfällen auch die Testfälle herleitet. Das Bild zeigt recht gut die sinkende Belastung des Analytikers, wogegen die Testvorbereitung langsam mehr Kapazitäten verlangt.

Im RUP nähert man sich dem "perfekten" Endprodukt iterativ an. Ebenfalls bei http://www.rational.com/products/rup/prodinfo.jsp findet sich diese Darstellung, die unterm Stich nur eine andere Form der Darstellung für das Wasserfallmodell ist, jedoch noch eine Evaluierungsphase für das freigegebene Produkt enthält:

Anfangs liegt der Schwerpunkt wie bei allen anderen Prozess-Modellen auch in der Anforderungsanalyse bzw. dem Modellieren von Geschäftsprozessen. Dem Business Analysten fällt in diesem Prozess-Modell eine wesentliche Rolle zu, die auch auf die Testvorbereitung ausgedehnt werden kann, aber nicht muss. Wie bei jedem nichtlinearen Modell begleitet er das Projekt bis zum Ende.

Objektorientiertes Modell

Sofern Sie keine relevanten IT-Kenntnisse haben, werden Sie sich mit diesem Abschnitt schwer tun. Er ist dennoch für nicht-ITler geschrieben. Unter einem Objekt kann man sich ein Stück fertiger Software vorstellen, das bestimmte Funktionen erfüllt. Dieses Stück Software kann man in einem anderen Stück Software verwenden oder es erweitern, man ruft es auf und bekommt Ergebnisse.

Ich benutze den Begriff objektorientiertes Modell in Anlehnung an die Aufzählung von Helmut Balzert ([Balzert2] S. 98 ff). Beim objektorientierten Modell kommt es darauf an, was man will:

Man will das Rad nicht neu erfinden sondern vorhandene Objekte verwenden, z.B. eine Klassenbibliothek oder ein ganzes Produkt einkaufen, und sie soweit anpassen und erweitern, dass sie den eigenen Anforderungen genügen. - Diese Sicht bietet sich meist für den Auftraggeber.
Man will zwar ein Produkt bauen, die dazu angefertigten Komponenten (Objekte) sollen jedoch wiederverwendbar für andere Produkte sein. - Diese Sicht bietet sich meist für den Auftragnehmer, also ein Software-Haus oder eine Entwicklungsabteilung.

Beide Ansätze sind sehr Technik-getrieben, die Fachabteilung bekommt davon i.d.R. nichts mit. So gesehen ist aus Sicht der Anforderungsanalyse das objektorientierte Modell kein Modell für (fachabteilungslastiges) IT-Projektmanagement. Hier ist der Software-Architekt und Software-Designer gefragt. Wenn sich der Business Analyst auf den Standpunkt stellt, dass das fertige Produkt eine Black Box ist, kümmert er sich um diesen Ansatz nicht. Er erstellt seine Anforderungsanalyse analog zum Wasserfallmodell, drückt sie den Technikern in die Hand und überlässt es ihnen, eine geeignete technische Lösung zu finden.

Im Rahmen einer Gap-Analysis ist der Business Analyst jedoch beim ersten Fall gefragt. Nachdem die Anforderungen durch die Fachabteilung festgelegt worden sind, muss zunächst festgestellt werden, ob das anvisierte Produkt (oder auch die Klassenbibliothek) als Rumpf für eine Weiterentwicklung ausreichend und auch geeignet ist. Anschließend muss die Lücke zwischen dem einzukaufenden Produkt und dem gewünschten Resultat ermittelt und ein Weg dorthin ausgearbeitet werden. Man nähert sich hier der Lösung sowohl von der technischen als auch von der fachlichen Seite her an. Ein wie auch immer geartetes Produkt verarbeitet Daten und bildet Prozesse ab. Der Business Analyst muss nun zur Anforderungsanalyse der Fachanwender noch herausarbeiten, wie die Geschäftsdaten ggf. konvertiert werden müssen, welche Funktionen des eingekauften Produktes genutzt und welche wie zu modifizieren sind. Die technischen Leute müssen daraus ein brauchbares Design schaffen, das auf dem vorhandenen Produkt aufsetzt. - Vom Auftraggeber zu beachten, für den Business Analysten aber irrelevant, ist, dass die Modifikation einer vorhandenen Lösung u.U. teuerer werden kann, als eine komplette Neuentwicklung.

Beim zweiten Fall obliegt es dem Business Analysten, konkrete Teilprozesse zu definieren, die unabhängig vom Gesamtsystem gekapselt werden können und von denen abzusehen ist, dass sie anderweitig verwendet werden können. Gemeint sind hier tatsächlich fachliche Abläufe, nicht technische.

Beispiel aus der Praxis

Im Rahmen des Baus verschiedener finanznaher Web-Produkte konnte eine Reihe finanzmathematischer Berechnungsvorschriften erkannt werden, die in einer Klassenbibliothek gesammelt wurden. Manche dieser Vorschriften waren in den Vorjahren bereits mehrfach und in verschiedenen Programmiersprachen von verschiedenen Entwicklern implementiert worden.

Jedes Unternehmen, das selbst Software entwickelt, wird objektorientierte Ansätze berücksichtigen müssen. Wurde die Erzeugung von wiederverwendbaren Komponenten in den achtziger Jahren noch explizit gefördert und von vielen Unternehmen gegenüber den Mitarbeitern auch finanziell honoriert, wird dies heute vorausgesetzt.

In meiner Praxis habe ich drei wesentliche Gründe kennen gelernt, die die Einführung einer Firmenphilosophie wiederverwendbarer Komponenten erheblich behindern, wovon die ersten zwei vor allem Überzeugungsarbeit notwendig machen:

Eine kurzsichtige betriebswirtschaftliche Betrachtungsweise blockiert diesen Ansatz. Wenn die Sicht auf die Kosten nur kurzfristig ist, werden die höheren Kosten für wiederverwendbare Komponenten nicht akzeptiert. [Balzert2] S. 651 veranschlagt auf Basis verschiedener Quellen ca. 30% bis 60% Mehrkosten für die Entwicklung wiederverwendbarer Komponenten, die nach der dritten Wiederverwendung wieder eingespielt sind. Eine zitierte Studie geht von 60% Mehrkosten aus, wovon 25% auf zusätzliche Verallgemeinerung und 15% auf zusätzliche Dokumentation fallen. Langfristig lassen sich erhebliche Produktivitätssteigerungen nachweisen.
Die Entwickler blockieren diesen Ansatz, da er nicht in ihre persönliche Philosophie und ihr Selbstverständnis passt. Sie wollen lieber Lösungen entwicklen, als auf vorhandenen Lösungen aufbauen und diese weiter entwickeln. Ein Grund dafür ist, dass ein prinzipielles Misstrauen gegenüber third party Produkten besteht, deren Qualität nicht bekannt ist.
Das notwendige Know How zur Erstellung wiederverwendbarer Komponenten ist gar nicht vorhanden.

Beispiele aus der Praxis

Ein Entwickler reklamierte, dass er bereits wiederverwendbare Komponenten für bestimmte Aufgabenstellungen hätte, als der Aufbau einer entsprechenden Klassenbibliothek beauftragt wurde. Weder waren diese Komponenten dokumentiert, noch waren sie den anderen Entwicklern bekannt, noch waren sie tatsächlich wiederverwendbar im Sinne eines objektorientierten Ansatzes. Der Entwickler passte den Code jeweils an seine aktuellen Bedürfnisse an, anstatt tatsächlich eine Klassenbibliothek zu verwalten und fallabhängig neue Klassen von denen seiner Klassenbibliothek abzuleiten. Zudem war der Code nicht sonderlich stabil, weder existierte ein Anforderungsdokument noch war der Code systematisch getestet worden.

Im Rahmen eines Projekts von ca. zwei bis drei Personenjahren wurde ein Mitarbeiter von der Geschäftsführung gebeten, sich um die Wiederverwendbarkeit des zu erstellenden Codes zu kümmern. Der Mitarbeiter wies die Aufgabe zurück, da er bereits anderweitig vollständig eingebunden war. Der Geschäftsführer sagte etwas verwundert, dass er davon ausgegangen sei, dass sich dieser Auftrag mit einem Aufwand von ca. einer Stunde pro Woche erledigen ließe. (Hinweis für Nicht-IT-Spezialisten: Das ist ein Vollzeitjob im Rahmen des Designs.)

Die fortwährende Wiederverwendung von Komponenten bringt mittelfristig nicht nur einen Kosten- und Effizienzvorteil, sondern auch einen Qualitätsvorteil. Komponenten die einmalig entwickelt werden, müssen nicht wiederholt getestet werden. Fehler, die sich im laufenden Betrieb in einem Produkt finden, in dem die Komponente eingebaut ist, werden implizit auch für alle anderen Produkte behoben, die diese Komponente verwenden.

Bewegt man sich von der Software-Entwicklung weg und hin zu Geschäftsprozessen im tatsächlichen Sinne von betrieblichen Abläufen, dann kann ein Informatiker als Informations-Technologe in des Wortes wahrsten Sinne arbeiten. Seit einigen Jahren gibt es eine spürbare Tendenz dahingehend, dass die IT nicht mehr als reiner Erfüllungsgehilfe des Business verstanden wird, sondern selbst eine aktive Rolle in der Gestaltung und Optimierung von Geschäftsprozessen zugebilligt bekommt. Bereits in den achtziger Jahren wurden Witze dahingehend gemacht, dass es nicht die Umstellung eines Betriebes oder einer Abteilung auf EDV sei, die zu mehr Effizienz führe. Die Effizienzsteigerung basiere vielmehr auf dem Umstand, dass durch das implementierte System erstmals vorhandene Regeln nicht nur in Form von häufig ignrierten Arbeitsanweisungen dokumentiert würden, sondern zunächst in der Analysephase die Regelwerke entrümpelt und vereinfacht und schließlich die Einhaltung der Regeln durch die relative Starrheit des Systems erzwungen würde.

Die Aufgabe eines Analytikers in solch einem Umfeld besteht nicht darin, Software zu planen. Er soll allerdings mit ähnlicher Methodik fachliche Objekte identifizieren und bei deren Verwendung mithelfen. In der echten Geschäftswelt neigen Fachanwender und ganze Abteilungen dazu, anstehende Probleme zu lösen, ohne zuvor Ausschau zu halten, ob nicht irgendwo im Hause bereits eine vergleichbare Lösung exisitert oder eine Lösung (ein Objekt) existiert, von der die gewünschte Lösung abgeleitet werden kann. Die Entstehung von Redundanzen, sich überschneidenden Lösungen ohne wirkliche Schnittstelle und nur teilwiese verträglichen Forderungen verschiedener Abteilungen ist die Folge. Der Analytiker sucht bei solch einer Aufgabenstellung einen Ansatz, um tatsächlich die fachlichen Abläufe reibungs- und redundanzfreier zu gestalten. - Ein Beispiel: Ein auf diesen Seiten bereits anonym zitierter Informatiker spottete einmal: Der exzessive Einsatz von Tabellenkalkulationssystemen ist der sicherste Weg zur Ineffizienz. Da dieselben i.d.R. in Eigenregie und ohne Rücksicht auf die tatsächlichen Notwendigkeiten der gegebenen betrieblichen Abläufe über die unmittelbare persönliche Umgebung hinaus erstellt werden, führt dies nicht selten dazu, dass Ergebnisse eines Sheets nochmals umgeformt und in ein anderes abgetippt werden müssen. Bei optimierten Prozessen sollte so etwas unnötig sein.

Extreme Programming

Die übliche Schreibweise für Extreme Programming ist eXtreme Programming, woher auch die Abkürzung XP rührt.

An keinem anderen Modell scheiden sich die Geister mehr als am Extreme Programming, der Glaubenskrieg hierzu ist noch in vollem Gange. Im weiteren Sinne kann Extreme Programming als evolutionäres Modell in sehr kleinen Schritten angesehen werden. Extreme Programming ist sehr Code-getrieben und wird von den Entwicklern dominiert. Die Kernidee besteht darin, dass die vom Fachanwender gestellten Anforderungen in kleinste Pakete umgesetzt werden, die ohne weiteres und sehr zügig realisiert werden können. Dabei geht der Auftraggeber bzw. Fachanwender oberflächen-getrieben vor, erstellt zunächst gewünschte Leistungsmerkmale die strukturiert und zusammen gefasst werden, um sie anschließend sofort zu implementieren. Eine eigene Software-Designphase entfällt, da die Pakete so klein sind, dass ein umfangreiches Design gar nicht notwendig ist. Dafür wird in Kauf genommen, dass die Entwickler das Design immer wieder ändern. Durch die Kleinheit der Iterationsschritte von Version zu Version sieht der Kunde das Produkt organisch wachsen und kann Fehlsteuerungen erkennen und korrigierend eingreifen. Beispielsweise kann zunächst nur mit einer Login/Logout-Funktionalität begonnen werden. In der zweiten Version funktioniert dann das Erfassen und Anzeigen eines Stammdatensatzes, in der dritten das Ändern und Löschen.

Ein wesentliches Charakteristikum des Extrem Programing ist das pair programming (bzw. tandem programming). Dabei sitzen zwei Entwickler vor einem Rechner, wobei einer eher tippt und programmiert, der andere eher hinterfragt und konstruktiv kritisiert. Dadurch, dass paarweise nach einem vier-Augen-Prinzip gearbeitet wird, werden komplizierte und unverständliche Entwicklungsansätze vermieden. Ebenso werden Überseher minimiert und die Entwickler verirren sich nicht in Denk-Sackgassen, aus denen sie nicht mehr heraus finden. Die gegenseitige Überwachung unterstützt auch sehr ausführliche Programmierertests, sodass die nachfolgenden strukturierten Tests meist nur noch wenige Fehler finden und der Abnahmetest sofort bestanden wird. Nachteilig ist dabei, dass die vielen kleinen Iterationen häufige Regressionstests erfordern, die in der Praxis jedoch nicht durchgeführt werden. Das macht aber auch nichts, da noch immer am Ende ein vollständiger Abnahmetest des fertigen Produkts die Pflicht des Auftraggebers bleibt. Das pair programming führt dazu, dass sich die Entwickler immer weiter antreiben, da sie sehr ergebnisorientiert arbeiten und nur ungern mitten in der Arbeit aufhören. Aus diesem Grund muss strikt die 40-Stunden-Woche eingehalten werden, um Ermüdung zu vermeiden..

Beim Extreme Programming sollte der Business Analyst selbst Progammiererfahrung haben, er muss aber die Entwicklungsumgebung nicht im Detail kennen. Seine Rolle besteht zunächst darin, vom Fachanwender die nötigen Informationen zu erfragen, um die nächste Produktversion vollenden zu können. Da er der wesentliche Wissensträger im Projekt ist, liegt es nahe, dass er anschließend als pair programmer als der hinterfragende Partner arbeitet. Dabei reicht es vollkommen aus, wenn er die Programmiersprache passiv beherrscht, den Code also gut lesen kann. Er leitet seinen technisch versierten Partner an und baut Schritt für Schritt die Lösung auf. Anstatt komplexe Algorithmen zeitraubend zu dokumentieren, dem Entwickler mühsam zu erklären und schließlich am gelieferten Produkt zu verifizieren, baut er den Algorithmus zusammen mit dem Entwickler, der ihn während der Entwicklung auch verstehen lernt. Aus demselben Grund liegt pair programming auch nahe, wenn funktionsreduzierte Prototypen gebaut werden sollen.

Beispiel aus der Praxis

In einem Kleinprojekt mussten numerisch nicht ganz triviale Algorithmen umgesetzt werden. Ich hatte damals die Rolle des Analytikers und betrieb pair programming mit einer sehr talentierten Entwicklerin, der allerdings noch die Erfahrung für Algorithmik fehlte und die keine höhere mathematische Ausbildung hatte. Zwar hatte ich noch nie Java programmiert, konnte aber auf Grund meiner C++-Erfahrung den Code ohne Schwierigkeiten lesen. Die umgesetzten Algorithmen waren bereits in der ersten Version nach der Implementierung fehlerfrei. Leider hielten wir uns nicht konsequent an die 40-Stunden-Woche und wir schoben mehrere zwölf-Stunden-Schichten ein, die letztendlich nur ermüdend waren.

Bei den Paarungen muss natürlich die Chemie stimmen. Sitzen zwei etwa gleich qualifizierte Leute vor dem Rechner, kann im Zweifelsfall rasch die Rolle gewechselt werden, d.h. der Kritiker wechselt mit dem Hacker ab. Ein Analytiker, der die verwendete Plattform nur passiv beherrscht und dann auch noch wichtigtuerisch seinem technischen Kollegen vorzugeben versucht, wie er einen technischen Ansatz realisieren soll (den der Analytiker alleine gar nicht realisieren könnte) ist eindeutig nicht für solch ein Vorgehen geeignet.

Ein Business Analyst, der keine Ahnung von der Programmierung hat, ist im Extreme Programming m.E. deplatziert. Das Verfahren ist u.a. dann geeignet, wenn der Willensfindungsprozess des Fachanwenders noch im vollen Gange ist und er tatsächlich nur dann sagen kann, was er braucht, wenn er ein konkretes Produkt sieht, das er kritisieren kann. Pair programming führt im Regelfall zu hoher Software-Qualität. Beim Extreme Programming wird postuliert, dass der Code auf Grund seiner klaren Struktur und Einfachheit selbst dokumentierend ist, dass also umfangreiche technische Dokumentation nicht notwendig ist. Dieser dokumentationssparende Ansatz ist aber auch einer der härtesten Kritikpunkte der Gegner des Extreme Programming. Der Analytiker ist in keinem Fall davon befreit, eine vollständige Analyse parallel zur Entwicklung mitzuschleifen, jedoch kann die Analyse letztendlich auch ein umfangreiches Benutzerhandbuch sein, wobei im Handbuch nicht transparente Vorgänge und Daten noch anderweitig dokumentiert werden müssen.

Das Prinzip des pair programming kann ungeachtet des Prozessmodells eingesetzt werden.

Leuten, die selbst keine relevante Erfahrung als Software-Entwickler haben, verstehen häufig nicht, weshalb zwei Leute (scheinbar) dieselbe Arbeit machen und klassifizieren dies als eine Verschwendung von Ressourcen. Das Schlimmste, was beim Extreme Programming passieren kann, ist, dass während des Entwicklungsprozesses befohlen wird, das pair programming zu beenden, um so "doppelt so schnell" fertig zu werden. Da die Gründe dafür Nicht-IT-Spezialisten nicht vermittelbar sind und IT-Spezialisten wissen, was gemeint ist, wird das Thema hier nicht weiter ausgeführt.