Das Dokument beschreibt, wie agiles Projektmanagement die Erfolgsquote von IT-Projekten erhöht, indem es traditionelle Methoden durch Flexibilität und kontinuierliche Kommunikation ersetzt. Agilität gewährleistet eine enge Zusammenarbeit mit dem Kunden und ermöglicht schnelle Anpassungen an sich ändernde Anforderungen. Agile Techniken wie Scrum und Extreme Programming haben sich als besonders effektiv erwiesen, insbesondere in web-basierten Projekten, wo Kreativität und schnelle Reaktionen auf Änderungen entscheidend sind.

1. WHITE PAPER
Agiles Management
für erfolgreiche IT-
Projekte
1

2. Agiles Management für erfolgreiche IT-Projekte
Kurzfassung
Nur eins von drei IT-Projekten verläuft im Durchschnitt erfolgreich. Verspätungen,
Kostenexplosionen und ständige Anforderungsänderungen sind scheinbar normale
Rahmenbedingungen der Softwareentwicklung. Weder die Kunden noch die
Lieferanten sind damit zufrieden – aber lassen sich diese Mängel beseitigen?
Agiles Projektmanagement bietet neue Wege zur erfolgreichen Umsetzung von IT-
Projekten. Traditionelle Techniken des Projektmanagements wie detaillierte Planun–
gen und strenge Hierarchien werden durch Flexibilität, Kreativität und Kommuni–
kation abgelöst. Ziel ist es, den Kunden durch die Auslieferung werthaltiger Software
innerhalb möglichst kurzer Frist zufrieden zu stellen.
Die grundlegenden Prinzipien agiler Softwareentwicklung wurden Ende des vorigen
Jahrzehnts entwickelt. Darauf basierende Methoden wie Extreme Programming (XP)
oder Scrum wurden schnell populär und sind heute bei vielen Softwareherstellern im
Einsatz (beispielsweise Google, Sun Microsystems oder SAP).
Infopark wendet ebenfalls unterschiedliche Techniken agiler Softwareentwicklung
erfolgreich an. Die Praxis beweist deren besondere Eignung für Web-Projekte:
Erfolgsquote und Produktqualität werden deutlich gesteigert, Termine und Kosten
bleiben unter Kontrolle. Es lohnt, sich damit genauer zu beschäftigen.
2

3. 1. Geplant ins Chaos
Nur jedes dritte IT-Projekt
ist erfolgreich
Die Programmierung neuer Software wird in der Regel detailliert geplant.
Auftraggeber und Entwicklerteam legen vor Beginn der Arbeit exakt fest, welche
Funktionen in welcher Form realisiert werden sollen. Anschließend wird die
erarbeitete Spezifikation buchstabengetreu abgearbeitet. Dabei kann eigentlich
nichts schiefgehen, oder?
Die Praxis zeigt das Gegenteil. Nach Angaben der Standish Group (Chaos Report
2004) wird im Durchschnitt weniger als ein Drittel aller Projekte erfolgreich
abgewickelt. In jedem zweiten Fall dagegen wurden der Zeit- und/oder der
Kostenrahmen gesprengt. Etwa jedes fünfte Vorhaben scheiterte sogar komplett.
Dass dieses Verhältnis seit längerem besteht, unterstreichen die Auswertungs-
ergebnisse der Standish Group für die Jahre 1994-2004:
Erfolgsquote abgeschlossener Projekte in % (Standish Group, Chaos Report 2004)
Auch Umfragen im nationalen Rahmen bestätigen diese Tendenzen (siehe z.B.
www.gulp.de/kb/it/projekt/planungsmaengel_f.html). Immer wieder werden
folgende Symptome als typisch für IT-Projekte benannt:
• Projekt dauert länger als erwartet
• Kosten sind höher als erwartet
• Anforderungen ändern sich
• Inhaltliche Umsetzung erfolgt mangelhaft
• Technologieentwicklung überholt das laufende Projekt.
Welche Begründung gibt es dafür?
3

4. Grenzen konventionellen
Projektmanagements
Die Ursachen für diese unbefriedigenden Resultate liegen in der „Sucht“, alle
Arbeitsschritte und Ergebnisse so exakt wie nur möglich vorzugeben. Diese
sogenannte „Wasserfall-Methode“ des Projektmanagements überzeugt auf den
ersten Blick durch ihre Logik und Organisation. Die Praxis beweist allerdings, dass der
Mensch nicht besonders dafür geeignet ist. Eine Erhebung des OFFIS e. V.
(Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und
-Systeme, www.offis.de) aus dem Jahr 2005 bestätigt sogar die Aussage, dass
Projekte ohne spezielle Vorgaben eine höhere Erfolgsquote aufweisen als Projekte
mit konkreten Vorgehensmodellen.
Der Grund ist einfach: Wir können nicht in die Zukunft sehen. Es ist schlicht
unmöglich, vor Beginn einer Softwareentwicklung alle Anforderungen
vorherzusehen und den Aufwand für die Arbeitsschritte genau zu prognostizieren.
Jeder Versuch, das zu tun, gerät entweder zu allgemein oder zu detailliert und ist
unausweichlich mit Fehlern behaftet. Während des Projekts gewonnene Erkenntnisse
werden viel zu selten genutzt – denn dafür müsste die Spezifikation geändert
werden.
Durch die starke Arbeitsteilung im Team konzentriert sich jeder Mitarbeiter nur auf
„Kein Plan überlebt die vorgegebenen Aufgaben und ist nicht bereit, darüber hinaus Verantwortung zu
die erste Feindberührung.“ übernehmen. Die Kommunikation im Team wird negativ beeinflusst, der Blick „über
Helmuth Graf von den Tellerrand“ für die ganzheitlichen Anforderungen geht verloren. Ein weiterer
Moltke
Nachteil ist der große Dokumentationsaufwand, der enorme Ressourcen bindet.
Offensichtlich wird ein anderer, mehr der menschlichen Natur entsprechender
Ansatz benötigt, um IT-Projekte zur allseitigen Zufriedenheit abzuwickeln. Infopark
nutzt dazu mit Erfolg unterschiedliche Techniken agiler Softwareentwicklung, die in
den nächsten Kapiteln näher erläutert werden.
4

5. 2. Das Konzept agiler Softwareentwicklung
Freiräume für
kreatives Handeln
Die grundlegenden Ideen agiler Softwareentwicklung entstanden in den 1990er
Jahren. Die Entwicklung von Software sollte durch Verschlankung und Entbüro-
kratisierung verbessert und beschleunigt werden. Ziel ist es, das konventionelle
Anforderungskorsett aufzubrechen und die kreativen Potenziale aller Beteiligten zu
erschließen.
Dafür werden neue Denkansätze und Werte benötigt. Im „Manifest der Agilen
Softwareentwicklung“ sind diese wie folgt formuliert:
Menschen und Kommunikation sind wichtiger als Methoden und Werkzeuge.
Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
Lauffähige Software ist wichtiger als umfangreiche Dokumentation.
Reagieren auf Veränderung ist wichtiger als Planerfüllung.
„Manifest der Agilen Softwareentwicklung“ (www.agilemanifesto.org)
Die rechts stehenden Kriterien werden dabei nicht vernachlässigt, aber im
Zweifelsfall bekommen die links genannten Werte den Vorzug. Dabei ist Agilität
nicht zu verwechseln mit Anarchie. Im Gegenteil, aufgrund der gesteigerten
Verantwortung jedes Einzelnen sind Disziplin und Initiative besonders gefragt.
Priorität hat generell die Erfüllung der Kundenbedürfnisse. Es ist nicht entscheidend,
mit welchen Mitteln das Vorhaben umgesetzt wird. Wichtig ist, welcher Endzustand
zu einem bestimmten Zeitpunkt erreicht ist und welcher konkrete Nutzen damit
verbunden ist.
Wichtige Prinzipien
Ein Projekt wird nicht einfach dadurch „agil“, indem man es so bezeichnet. Alle
Beteiligten müssen bestimmte Prinzipien akzeptieren und auch bereit sein, danach
zu arbeiten. Solche Prinzipien sind beispielsweise
• Kundennähe
• Transparenz
• Flexibilität und
• Teamfähigkeit.
Auf den genannten Werten und Prinzipien basieren alle agilen Softwareentwick-
lungsprozesse. Sehr oft wird das Scrum-Modell angewendet, daneben haben
Extreme Programming (XP), Adaptive Software Development oder Crystal weite
Verbreitung erfahren.
Infopark setzt bei IT-Projekten verschiedene agile Techniken aus diesen populären
Modellen ein. Diese werden durch eigene Erfahrungen und State-of-the-Art-
Methoden erweitert. Was das konkret bedeutet, erläutert der nächste Abschnitt.
5

6. 3. Mittel und Methoden agilen Projektmanagements
Kontinuierlicher
Prozess
Klassische Softwareentwicklung unterscheidet verschiedene Phasen (Anforderungs-
analyse, Entwurf, Test, Programmierung), die gewöhnlich in chronologischer Folge
abgearbeitet werden. Auch bei agilen Methoden spielen diese Phasen eine wichtige
Rolle, nur folgen sie hier nicht zeitlich nacheinander. Statt dessen wird die Software
kontinuierlich geplant, getestet und entwickelt („adaptiver Prozess“).
Dabei wird angestrebt, möglichst früh zu einer ausführbaren Version der Software zu
gelangen. Diese wird dann in regelmäßiger Abstimmung mit dem Kunden erweitert
und verfeinert, bis ein allseits befriedigender Stand erreicht ist.
Natürlich entsteht so ein Prototyp nicht von selbst. Auch agile Softwareentwicklung
benötigt ein bestimmtes Maß an Organisation.
Angestrebten Nutzen
klar definieren
Am Beginn des Projektes werden in einer Anforderungsanalyse die grundlegenden
Projektziele und der damit verbundene Nutzen bestimmt. Dabei wird berücksichtigt,
dass der Funktionsumfang einer Software von der überwiegenden Zahl der An-
wender nur zu etwa einem Drittel ausgeschöpft wird. Zwei Drittel der verfügbaren
Möglichkeiten werden dagegen selten oder gar nicht benötigt. Der unverhältnis-
mäßig große Aufwand für deren Realisierung bringt selten einen entsprechenden
Mehrwert.
Aufwand-Nutzen-Relation in IT-Projekten
Daraus ergibt sich die logische Folge, bei der Softwareentwicklung zuerst die
Anforderungen umzusetzen, die mit möglichst geringem Erstellungsaufwand
den höchsten Nutzen erbringen.
6

7. Unterteilung
in Stories
Um den Planungsaufwand niedrig zu halten, wird bei agiler Softwareentwicklung
keine detaillierte Spezifikation erstellt. Für die Beschreibung der Ziele werden
sogenannte „Stories“ genutzt. Jede Anforderung wird in einer Story nach dem
Muster „Als XXX kann ich XXX, um XXX“ festgehalten. Dabei kann der Teil „um
XXX“ auch entfallen, wenn der Zweck deutlich genug bestimmt ist. Die
Formulierung der Story ist situationsabhängig änderbar.
Für die Protokollierung gibt es keine Vorgaben, es genügen formlose, aber präzise
Beschreibungen auf einfachen Karten („Story Cards“). Diese Story Cards werden für
alle Beteiligten gut sichtbar an einer zentralen Stelle platziert. Sie dienen im
gesamten Projektablauf als wichtiges Kommunikationsmedium zwischen Kunde und
Entwickler.
Beispiele für Story Cards bei Infopark
7

8. Abstrakte Aufwands- und
Risikobewertung
Die Abschätzung des zeitlichen und personellen Aufwands für die Realisierung einer
Story ist auch für erfahrene Mitarbeiter problematisch. In der agilen Software-
entwicklung werden dafür keine konkreten Größen (Zeit, Geld) genutzt. Die
Aufwandsbewertung erfolgt statt dessen in abstrakten Einheiten, beispielsweise
unter Verwendung einer nicht-linearen Punkteskala. Die verwendeten Abstufungen
sollten einfache Vergleichsabschätzungen zwischen den Stories zulassen,
beispielsweise (nach Mark Cohn):
• eine Skala mit den Werten 1, 2, 3, 5, 8:
für Story C (Aufwand = 3) benötigen wir genau so lange wie für
Story A (Aufwand = 1) und Story B (Aufwand = 2) zusammen oder
• eine Skala mit den Werten 1, 2, 4, 8:
für Story C (Aufwand = 4) benötigen wir doppelt so lange wie für
Story B (Aufwand = 2).
Ergibt die Abschätzung in diesen Fällen einen Wert größer als 8, muss die Story
weiter untergliedert werden. Im Projektverlauf werden die Aufwandsabschätzungen
mit den tatsächlichen Ergebnissen verglichen und bei Bedarf korrigiert. Dadurch sind
zunehmend genauere Schätzungen über die verbleibenden Aufwände möglich.
Für die Risikobewertung bezüglich Zeitplan, Kosten und Funktionalität genügen
zwei (gering – hoch), maximal drei Stufen.
Sprints und Planning Game
Ein grundlegendes Prinzip agilen Projektmanagements ist das Vorgehen in kurzen
überschaubaren Etappen konstanter Länge (maximal zwei bis vier Wochen). Statt
eines langen Projektmarathons wird eine Reihe kurzer Sprints absolviert. Diese
Sprints (auch „Iterationen“ genannt) sind das zentrale Element vieler Modelle agiler
Softwareentwicklung, unter anderem auch des Scrum-Modells.
Zu Beginn jedes Sprints sind die Anforderungen zu bestimmen, die innerhalb des
festgelegten Zeitraums umgesetzt werden sollen. Dazu werden innerhalb eines
sogenannten „Planning Game“ den einzelnen Stories Prioritäten zugeordnet. Das
erfolgt durch den Kunden und die Entwickler gemeinsam. Die Prioritäten werden
dabei nach folgenden Kriterien vergeben:
Risiko Nutzen Priorität
Hoch Hoch 1
Gering Hoch 2
Gering Gering 3
Hoch Gering Diese Kombination ist möglichst
zu vermeiden
8

9. Im Ergebnis entsteht ein „Sprint Backlog“, das beschreibt, welche Stories im
aktuellen Sprint realisiert werden. Dann kann mit der Umsetzung begonnen werden.
Die Entwickler zerlegen dazu jede Story in einzelne Arbeitspakete und schätzen
deren Aufwand ab. In täglichen kurzen Besprechungen („Daily Scrum“) werden
diese Arbeitspakete innerhalb des Teams aufgeteilt. Weiterhin teilt jeder Entwickler
mit, was er am Vortag fertiggestellt hat und welche Probleme oder neue Ideen dabei
aufgetreten sind.
Abschluss eines Sprints
Erweist sich der geschätzte Aufwand für eine Story als zu gering, wird die Story
entweder aufgeteilt oder komplett auf den nächsten Sprint verschoben. Auch die
Repriorisierung von Stories während eines Sprints ist möglich.
Am Ende jedes Sprints steht eine neue ausführbare Version der Software. Diese ist
Gegenstand eines Akzeptanztests (des „Sprint-Reviews“). Gemeinsam mit dem
Kunden wird im Review bestimmt, wie weit die Anforderungen erfüllt wurden und
welche Leistungsmerkmale im nächsten Sprint realisiert werden sollen.
Änderungen gegenüber bisherigen Planungen sind dabei willkommene Chancen zur
Verbesserung der Produkteigenschaften („Feedback-Loops“). Nicht selten erweist
sich im Verlaufe des Projektfortschritts, dass die Realisierung ursprünglich
vorgesehener Ziele einen zu geringen Nutzen erbringen würde. Es wird dann
gemeinschaftlich entschieden, ob diese Funktionen trotzdem zur Verfügung gestellt
werden oder ob auf sie verzichtet werden kann, ohne dass Einschränkungen in der
Benutzbarkeit der Software entstehen.
Veränderungen sind willkommen – Projektfortschritt mit Sprints
Wenn alle auf diese Weise gemeinsam festgelegten Ziele korrekt implementiert sind,
ist das Projekt fertiggestellt. Der Kunde erhält auf diese Weise ein Produkt, an dessen
Entstehung er aktiv beteiligt war und das genau seinen Anforderungen entspricht.
9

10. 4. Vorteile und Anforderungen
Nutzen für beide Seiten
Das im vorigen Abschnitt beschriebene iterative Vorgehen in enger Kommunikation
mit dem Kunden – ein grundlegendes Element agiler Softwareentwicklung – erweist
sich in der Praxis aus vielen Gründen vorteilhaft:
• Die Orientierung auf den maximalen Nutzen führt zu schnellen Erfolgen.
• Es gibt schnelles Feedback speziell zur Umsetzung der wichtigsten Funktionen.
• Fehler in der Konzeption bzw. Umsetzung werden schnell erkannt und können
sofort beseitigt werden.
• Das Risiko von Fehlentwicklungen wird minimiert.
• Eine gleichmäßige Auslastung des Projektteams wird gesichert.
• Zeitplan und Kosten bleiben unter Kontrolle – der typische fehlerbehaftete
Finalstress wird vermieden.
• Neu gewonnene Erkenntnisse fließen ständig in die Entwicklung ein.
• Durch die intensive Kommunikation kann der Umfang der Dokumentation auf
ein vernünftiges Maß reduziert werden.
Das Team entscheidet
Auch die agile Softwareentwicklung kann keine hundertprozentige Erfolgsgarantie
bieten. Die Bereitschaft zur Flexibilität, Offenheit und intensiver Kommunikation
muss bei allen Projektbeteiligten vorhanden sein. Nur dann werden die
beschriebenen Methoden ihre positive Wirkung voll entfalten.
Die richtige Zusammensetzung der Teams und deren uneingeschränkte Unter-
stützung durch Auftraggeber und Management spielen ebenfalls eine wichtige Rolle.
Statt komplizierter Hierarchien gibt es beispielsweise im Scrum-Modell lediglich drei
klar definierte Rollen:
Product Owner Trägt die Gesamtverantwortung, definiert die
(in der Regel der Kunde) Zielsetzungen und aktuell wichtigsten Features
Team Ist für die Umsetzung der Ziele verantwortlich
Scrum Master Überwacht die Aufteilung der Rollen und sorgt für
optimale Arbeitsbedingungen
Reihenfolge und Ablauf der Arbeit werden vollständig vom Team bestimmt. Dazu
dient das tägliche Meeting, in dem die Prioritäten gesetzt, Hindernisse aufgezeigt
und Mittel und Wege zur Zielerfüllung ausgewählt werden. All das erfolgt unter
Einbeziehung möglichst vieler Teammitglieder. Der Scrum Master sorgt für optimale
Arbeitsbedingungen.
Diese Organisation erfordert ein gewisses Umdenken im Vergleich zur gewohnten
Arbeitsweise. Wichtig ist, dass die Methoden nicht aufgezwungen werden, sondern
Agilität als Kultur verstanden wird. Dann wird sich die neue Arbeitsweise schnell
vorteilhaft auf die Stimmung und die Produktivität auswirken.
10

11. Vertrauen statt Kontrolle, Motivation statt Gängelei, Risikoorientierung statt
Sicherheitsfanatismus bewirken eine Steigerung des Selbstbewusstseins und erhöhen
die Motivation der Mitarbeiter. Die Erfahrung zeigt, dass trotz anfangs oft
geäußerter Skepsis der Mut zur Veränderung durch termingerecht fertiggestellte und
funktionierende Software belohnt wird.
11

12. 5. Agile Methoden bei Infopark
Besondere Eignung für
Web-Projekte
IT-Projekte im Web-Bereich weisen einige Besonderheiten auf. Dazu gehören:
• Am Projektbeginn existieren gewöhnlich seitens des Kunden sehr unscharfe
Vorstellungen von den Möglichkeiten des Mediums Internet. Daraus folgt ein
hohes Änderungspotenzial.
• Die Projektlaufzeiten sind kurz.
• Im Web gibt es besonders kurze Innovationszyklen.
• Die Projektteams sind klein, aber in der Zusammensetzung sehr heterogen
(Programmierer, Grafiker, Redakteure, Usability-Tester, Marketing-Experten).
• Die Ergebnisse müssen sehr oft auf ihre Brauchbarkeit getestet werden.
• Die Ergebnisbewertung ist häufig subjektiv.
Unter diesen Rahmenbedingungen kommen die Stärken agiler Entwicklungsprozesse
besonders zum Tragen. Das unkomplizierte Reagieren auf geänderte Anforderungen,
die kurzen Release-Zyklen und die ständige Kommunikation zwischen Kunden und
Entwicklerteam führen nach den Erfahrungen von Infopark in Web-Projekten zu
sehr guten Resultaten. Als Beispiele seien Portal-Projekte der AIR LIQUIDE
Deutschland GmbH und der Max-Planck-Gesellschaft erwähnt.
Workshops und Consulting
Das in diesem White Paper beschriebene Vorgehensmodell stellt nur eine kleine
Auswahl aus vielen Techniken agiler Softwareentwicklung dar. In der Praxis wird es
immer erforderlich sein, in enger Kooperation mit dem Kunden die passenden
Methoden auszuwählen und zu verfeinern.
Wir vermitteln unsere Erfahrungen im Rahmen von Intensiv-Workshops und beraten
Sie auch gern individuell bei der Einführung und Anwendung agilen Projekt-
managements. Das betrifft beispielsweise folgende Methoden und Techniken:
• Ziele formulieren
• Nutzen berechnen
• Prioritäten setzen
• Projekte steuern.
Bitte verwenden Sie bei Interesse unser Online-Formular: www.infopark.de/anfrage
12

13. 6. Weiterführende Informationen
Checkliste „Agiles
Management für
erfolgreiche IT-Projekte“
Die folgende Liste gibt Ihnen einen Überblick darüber, welche Kriterien im
Zusammenhang mit dem Thema „Agiles Management für erfolgreiche IT-Projekte“
interessant sein können. Wenn die Mehrzahl der Aussagen zutrifft, stellt die
Einführung und Anwendung agiler Methoden eine vielversprechende Alternative dar.
Entscheidungskriterien
Nutzer und Entwickler sprechen nicht immer eine Sprache und haben
unterschiedliche Vorstellungen vom Projektziel.
Wir arbeiten bei IT-Projekten regelmäßig mit externen Beratern zusammen.
Die Erarbeitung und Aktualisierung der Projektspezifikationen ist sehr
aufwendig und bindet viele Ressourcen.
Während eines Projektes entstehende neue Anforderungen werden selten
oder nicht ausreichend berücksichtigt.
Neue Technologien können wegen starrer Rahmenbedingungen nicht im
Laufe der Entwicklung genutzt werden.
Eine starke Arbeitsteilung erschwert den Wissenstransfer innerhalb des
Entwicklerteams.
Projekte werden mitunter nicht zum geplanten Endtermin fertig gestellt
und/oder überschreiten das vorgesehene Budget.
Das Produkt wird erst zur Projektabnahme dem Kunden vorgestellt.
Bei der Projektabnahme gibt es oft unterschiedliche Meinungen über den
Erfüllungsstand der Anforderungen.
Raum für eigene Kriterien
13

14. Literatur
Natürlich können wir an dieser Stelle das Thema „Agiles Management für
erfolgreiche IT-Projekte“ nur ansatzweise beleuchten.
Diese Links und Bücher bieten Ihnen weitere Informationen zum Thema:
Links • „Manifest der agilen Softwareentwicklung“:
www.agilemanifesto.org
• Agile Alliance: www.agilealliance.org
• Scrum: www.controlchaos.com
• Extreme Programming:
www.extremeprogramming.org
Bücher • „Agile Software Development with Scrum“
Ken Schwaber, Mike Beedle, PEARSON STUDIUM
2008
• „Extreme Programming - Das Manifest“
Kent Beck, Addison-Wesley 2004
• „User Stories Applied.
For Agile Software Development.“
Mike Cohn, Addison-Wesley Professional 2004
• „Der Pragmatische Programmierer“
Andrew Hunt & David Thomas,
Hanser Fachbuch 2003
14

15. Kontakt
Sollten Sie weitere Fragen oder Anregungen haben, dann freuen wir uns über Ihre
Nachricht. Bitte wenden Sie sich an unser Communication Center:
Infopark AG
Communication Center
Kitzingstraße 15, 12277 Berlin, Deutschland
Tel. +49 30 747993-0, Fax +49 30 747993-93
www.infopark.de
cc@infopark.de
Rechtliche Hinweise
Die Infopark AG ist bemüht, die dargestellten Informationen zu Produkteigenschaften immer korrekt
und fehlerfrei zu halten. Die Komplexität einiger Produkteigenschaften und der technische Fortschritt in
der Produktentwicklung machen jedoch laufende Änderungen notwendig, die nicht immer in allen
Veröffentlichungen von Infopark gleichzeitig gepflegt sind.
Der rechtlich verbindliche Lieferumfang eines Produkts in einer bestimmten Version von Infopark wird
ausschließlich durch die Angaben in den offiziellen Handbüchern zu dem Produkt wiedergegeben.
Infopark behält sich das Recht vor, in späteren Versionen des Produkts Funktionen zu ändern, zu
ergänzen oder nicht mehr zu liefern.
Alle Warennamen oder Herstellernamen werden ohne Gewährleistung der freien Verwendbarkeit
benutzt und sind möglicherweise eingetragene Warenzeichen. Wir richten uns im Wesentlichen nach
den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich
geschützt. Alle Rechte vorbehalten, einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung
sowie Einspeicherung und Verarbeitung in elektronischen Systemen.
© Infopark AG, Berlin 2007-2009, Agiles Management für erfolgreiche IT-Projekte
15