close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

extreme Programming Was ist xP Wie wird heute - Fischer Software

EinbettenHerunterladen
extreme Programming
eine Einführung von
Hannes Fischer
Fischer Software
Elfenstr. 64
70567 Stuttgart
Deutschland
Copyright © 2000 Hannes Fischer
Was ist xP
Wie wird heute gearbeitet ?
Ein durchgehend geplanter Ablauf
Marktanalyse der Kundensituation
Erteilen des Entwicklungsauftrags
? Festlegen des Entwicklungsprozesses
? InformationstechnischeAnalyse und Design
? Implementierungder Ergebnisse
? Entwicklung von Systemtests
? Testen
? Erstellen der Kundendokumentation
? Auslieferung an die Kunden
?
xP ist eine Entwicklungsstrategie,die einen Weg
und die dazu verwendeten Methoden beschreibt,
um mit geringerem Aufwand bessere Software in
kürzerer Zeit zu erstellen.
?
Die Vorteile
Die Vorteile
Alle Aspekte sind bereits vorher bekannt
Kundensituation
Lösung der Kundenprobleme
? Architektur der Software
? Genaue Vorschrift zur Implementierung
? genau bekannter Aufwand der Realisierung
? gesicherte Qualität
? alle erstellten Features werden dokumentiert
? festgelegter Einführungstermin
Der Personalaufwandist bekannt
Der Zeitaufwand ist bekannt
? Der Auslieferungsterminist bekannt
? Die Kosten sind bekannt
?
?
?
?
Die Realität
Im
Im Gegensatz
Gegensatz zur
zur industriellen
industriellen Fertigung
Fertigung
von
sind»Hardware«
die Entwicklungsprozesse
sind die Risiken
in bei
der der
Produktion
Informationstechnik
nicht genau
nicht
abschätzbar.
abschätzbar.
Die
Anzahl
Die Anzahl
der Variablen
der Variablen
im Entwicklungsund Risiken ist
prozess
um vieles
ist höher,
sehr viel
dasgrößer,
Systemdas
neigt
System
zu niegt
dazu
chaotischem
»chaotisch
Verhalten.
zu werden.
Der wirtschaftlicheErfolg des Projekts ist planbar
Die Erkenntnis ...
Entwicklungsprozesse in der
Informationstechnologie sind
nicht nur schwer planbar, sie
sind nicht komplett beherrschbar
... und die Folgen
Es treten zwangsläufig nicht vorhersehbare
Probleme auf, die zu Verzögerungen und
Verteuerungen führen und nicht selten ein ITProjekt vor der Fertigstellung scheitern
lassen.
... und die Folgen
das Produkt entspricht nicht den Erwartungen
die Markteinführungerfolgt zu spät
? die Kunden sind unzufrieden
? der Kostenrahmen wird gesprengt
? der Markt hat sich bereits wieder geändert
Die Probleme ...
zu ungenaue Spezifikationen
zu langsame Entwicklung
? zu viele Fehler
? zu teuer
? zu träge um auf Änderungen zu reagieren
?
?
Die Folge
?
?
Das Produkt scheitert!
Warum ?
Diese Probleme resultieren aus der, Entwicklungsstrategien,die bisher angewandt werden.
Sie sind nicht für den heute existierenden Markt
in der IT Branche entwickelt worden.
Die Lösung
Die Strategien müssen den heutigen
Gegebenheiten angepaßt werden.
Anforderung an eine neue Strategie
xP
enge Kommunikationzwischen den Parteien
reduzierter Aufwand
? einfache und effektive Qualitätssicherung
? effektive und damit günstige Entwicklung
? agil, um schnell auf Änderungen zu reagieren
?
?
extreme
Programming
Übersicht
Abschnitt 1: Das Problem
Abschnitt 2: Die Lösung
Die 4 Variablen
Kosten
? Zeit
? Qualität
? Umfang
?
Abschnitt 1
Das Problem
Kosten
Die Finanzierung des Projekts muß
gesichert sein. Mit einem zu geringen
Budget können die Probleme nicht gelöst
werden. Bei einem Zuviel an Geld wird
leicht das Ziel aus den Augen verloren.
Zeit
Qualität
Zuwenig Zeit hat einen negativen Einfluß
auf die Qualität. Zuviel Zeit verzögert die
Rückmeldung.
Die Qualität eines IT-Produktes steht in
direktem Zusammenhang mit den Kosten
und der Zeit. Hier muß ein optimale
Abstimmung für jedes Projekt gefunden
werden.
Umfang
Der Zusammenhang
Der Umfang bestimmt die Faktoren
Kosten, Zeit und Qualität direkt. Für
eine Problemlösung sollte der geringste
mögliche Umfang gewählt werden.
Alle vier Variablen Kosten, Zeit, Qualität und
Umfang hängen direkt voneinander ab. Diese
Verhältnisse sind sehr komplex und können nicht
auf eine einfache Formel gebracht werden. Um
einem Projekt gut einzustellen muß ein Optimum im Zusammenspieldieser Faktoren gefunden werden.
Die Änderungskosten
Angenommene Änderungskosten
1000
900
800
Direkt im Zusammenhang mit den
Gesamtkosten stehen die Kosten von
Änderungen im Zusammenhang mit dem
Änderungszeitpunkt.
700
600
500
400
300
200
100
0
Zeit 0
Reale Änderungskosten
Zeit 1
Zeit 2
Zeit 3
Zeit 4
Zeit 5
Zeit 6
Zeit 7
Zeit 8
Zeit 9
Zeit 10 Zeit 11
Die Auswertung
1000
900
800
700
Aus diesen von Kent Beck erhobenen Daten
läßt sich ersehen, daß die Kosten für eine
Änderung sehr schnell stabil sind und sich
auch später nicht mehr stark ändern.
600
500
400
300
200
100
0
Zeit 0
Zeit 1
Zeit 2
Zeit 3
Zeit 4
Zeit 5
Zeit 6
Zeit 7
Zeit 8
Zeit 9
Zeit 10 Zeit 11
Das Ergebnis
Dadurch, daß späte Änderungen nicht teurer sind,
und der Umfang des Produktes klein gehalten
werden soll, ergibt sich als logische Folgerung,
daß nur das implementiertwird, was im Moment
benötigt wird.
Die 4 Grundwerte
Kommunikation
? Einfach
? Feedback
? Mut
?
Das Ergebnis
Der Code kann ohne große Kosten immer wieder
verändert und verbessert werden. Eine einmal
festgelegte Vorgehensweisekann durch eine
einfachere oder schnellere ersetzt werden.
Kommunikation
Durch eine enge Kommunikation werden
alle nötigen Fragen gestellt, die beantwortet werden müssen, um alle Informationen auszutauschen.
Einfachheit
Feedback
Die einfachste Lösung eines Problems ist
die beste. Wenn diese Lösung irgendwann
nicht mehr ausreicht, muß sie erweitert
werden, bis Sie genau die neuen Anforderungen erfüllt.
Eine schnelles Feedback ist nötig damit
dieses Wissen in die weitere Entwicklung
einfließen kann. Das kann eine Fehlermeldung oder die schnelle Antwort auf
eine Frage sein. Das zeitnahe Reagieren
ist wichtig.
Mut
Die 5 Hauptprinzipien
Mutig sollen die bereits fertigen
Programmteile untersucht und wenn
möglich verbessert werden. Es muß mit
alten Gewohnheiten gebrochen werden,
auch dies verlangt Mut.
schnelles Feedback
? einfaches Denken
? kleine Änderungen
? Änderungen annehmen
? Qualitätsarbeit
?
Schnelles Feedback
Der Abstand zwischen einer Handlung
und den Auswirkungen bestimmt den
Lerneffekt.
Einfaches Denken
Nur das Notwendige implementieren.
Klassische Methoden legen Wert auf
Wiederverwendbarkeit und planen weit im
voraus.
Kleine Änderungen
Änderungen annehmen
Mit kleinen Änderungen werden Systeme
stabil gehalten. Kleine Änderungen werden
verstanden und können korrigiert werden.
»Die beste Strategie ist die, welche einem
die meisten Möglichkeiten offen hält,
während man das dringendste Problem
löst.«
Qualitätsarbeit
Die weiteren Prinzipien
Lernen lehren
kleiner Anfang
? Spielen um zu gewinnen
? zielgerichtete Experimente
? offene, ernsthafte Kommunikation
? mit den »Instinkten« arbeiten
? erklärte Verantwortung
? alles Anpassen
? leicht Reisen
? ehrliche Meßgrößen
?
Das zentrale Kriterium ist die Qualität der
Arbeit. Dieser Wert ist nicht frei änderbar,
wie die anderen Variablen, die einen
Entwicklungsprozeß bestimmen.
Die Qualität muß so hoch wie möglich sein.
Die weiteren Prinzipien
Lernen lehren
Es werden keine Vorschriften oder Worthülsen verwendet. Der
Zweck einer Tätigkeit muß gelernt und verstanden werden.
Kleiner Anfang
Ein kleiner Anfang, der schnell ein verwertbares Resultat liefert
ist für den Kunden und das Team wichtig.
Spielen um zu gewinnen
Das zu tun, was getan werden muß, um gute Arbeit zu leisten.
?
Die weiteren Prinzipien
Zielgerichtete Experimente
Bei jeder Entscheidung, die getroffen aber nicht getestet wird,
entsteht eine potentielle Fehlerquelle. Entscheidungen sollten
daher nach Experimenten getroffen werden, die alle offenen
Fragen zu einer Entscheidung klären.
Offene, ernsthafte Kommunikation
Probleme müssen offen angesprochen werden. Kritik ist erlaubt.
Die Folgen eines Fehlers müssen geklärt und die Korrektur erleichtert werden.
Die weiteren Prinzipien
Mit den Instinkten arbeiten
Mitarbeiter wollen gewinnen, lernen, mit anderen kommunizieren,
sie wollen Vertrauen, sie wollen einen ordentlichen Job machen.
Ein Prozeß, der diese kurzfristigen Ziele unterstützt wird auch den
langfristigen Zielen eines Projektes gerecht.
Erklärte Verantwortlichkeit
Es ist einfacher, sich für eine Tätigkeit zu entscheiden als eine
zugewiesen Pflicht zu erfüllen. Wird der Sinn einer Tätigkeit
erkannt, werden auch unangenehme Pflichten freiwillig übernommen.
Die weiteren Prinzipien
ehrliche Meßgrößen
Der Zwang, einen Entwicklungsprozeß zu verfolgen und zu
kontrollieren, erfordert ehrliche Meßgrößen. Wenn eine wahre
Aussage erst im Projektablauf getroffen werden kann, muß dies
mit einer wahrheitsgemäßen Schätzung aufgrund der bisher
bekannten Werte einhergehen.
Die weiteren Prinzipien
alles Anpassen
Der Prozeß muß auf das Team und die Aufgabe angepaßt werden.
Er soll nicht beengen, sondern die Möglichkeit geben eine gute
Arbeit zu leisten.
leicht Reisen
Leichte Einheiten extrahieren. Kein Beiwerk erzeugen, das nicht
unbedingt zum Projekt gehört. Dazu muß man einfach arbeiten
und gradlinig denken.
Die Arbeit
Kodieren
Testen
? Zuhören
? Entwerfen
?
?
Kodieren
Die Kodierung löst das Problem. Mit dem
Programmcode kann etwas erklärt werden.
Der Code erlaubt die Kommunikation. Der
Code ist das Ziel der täglichen Arbeit.
Zuhören
?
?
Testen
Jeder vorstellbare Test muß durchgeführt
werden. Es werden nicht nur die Ergebnisse
sondern auch der Weg dahin getestet. Die
Test müssen automatisch ablaufen. Diese
Tests geben dem Entwickler die Sicherheit
richtig zu arbeiten.
Entwerfen
Entwickler wissen nicht alles.
Kunden wissen nicht alles
Ist dies erkannt, können die Wissenslücken
nur durch zuhören beseitigt werden.
Kommunikation muß zielgerichtet sein.
Die Antworten müssen gehört werden.
Alle Bestandteile die kodiert werden,
müssen zusammenpassen. Ein gutes Design
macht dies möglich. Ein gutes Design ist
einfach und vermeidet Komplexität.
Abschnitt 2
Die Lösung
Entscheidungen
–
Kunden
–
–
–
Umfang
Prioritäten
Zusammenstellung
Termin
Software-Entwicklung ist immer eine
evolutionäre Tätigkeit. Es muß entschieden
werden zwischen dem, was möglich ist und
dem was nötig ist. Dazu müssen die Entwickler und ihre Kunden Entscheidungen
treffen.
Entscheidungen des Kunden
Entwickler
–
–
»Planning Game«-Planungsspiel
?
Schätzungen
?
Konsequenzen
?
Fortschritt
?
detaillierte Planung
Umfang
Wieviel Prozent eines großen Problems müssen gelöst werden,
damit sich die Produktion einer Software rentiert?
Priorität
Wenn zwischen mehreren Alternativen entschieden werden muß,
was ist am wichtigsten?
Entscheidungen des Kunden
Zusammenstellung
Was ist genug für eine neue Version und was ist zu viel?
Termin
Was sind wichtige Termine für das Erscheinen der Software?
Entscheidungen des Entwicklers
Prozeß
Wie wird die Arbeit organisiert? Wann ist das Team produktiv?
Paßt das Team in die Unternehmenskultur?
detaillierte Planung
Welche Kundenwünsche werden in einer Version zuerst realisiert?
Können die riskantesten Teile zuerst realisiert werden?
Entscheidungen des Entwicklers
Schätzungen
Wie lange dauert es?
Konsequenzen
Welche Entscheidungen wirken sich wie auf die Abschätzungen
der Entwickler aus? Welche Risiken bestehen?
Phasen des »Planning Game«
Exploration Phase
Herausfinden, welche neuen Dinge das System tun könnte.
Commitment Phase
Entscheiden, welche Untermenge aller Möglichkeiten genutzt
werden.
Steering Phase
Die Realität der Entwicklung steuern.
Planning Game - Exploration Phase
Stories schreiben
Eine Story wird vom Kunden beschrieben. In der Regel werden
Karteikarten dazu benutzt, auf der alle wichtigen Daten
festgehalten werden.
Story abschätzen
Die Entwickler schätzen wie lange die Implementierung dauern
kann. Wenn die Abschätzung unmöglich ist wird die Story
aufgeteilt oder genauer beschrieben.
Story aufteilen
Wenn der Entwickler nicht die gesamte Story abschätzen kann,
wird sie aufgeteilt. Das gleiche geschieht, wenn Teile der Story
wichtiger sind als andere.
Planning Game - Steering Phase
Iteration
Zu jeder Iteration sucht sich der Kunde die wertvollsten Stories
heraus, die implementiert werden müssen. Die erste Iteration muß
zu einem nutzbaren Ergebnis führen.
Recovery
Wenn die Entwickler ihre Geschwindigkeit überschätzt haben,
wird der Kunde nach den wertvollsten Stories gefragt, die mit der
neuen Geschwindigkeit implementiert werden können.
Planning Game - Commitment Phase
Nach Wert sortieren
Der Kunde sortiert die Stories nach Wichtigkeit für das Produkt.
Nach Risiko sortieren
Der Entwickler sortiert die Stories nach den Risiken, die die
Entwicklung mit sich bringen kann.
Entwicklungsgeschwindigkeit bestimmen
Das Entwicklerteam informiert den Kunden über die echten
Entwicklerstunden, die pro Monat möglich sind.
Umfang bestimmen
Der Kunde stellt die Karten zusammen, die die nächste Version
beschreiben.
Planning Game - Steering Phase
New Story
Wenn der Kunde eine neue Story gefunden hat, die implementiert
werden muß, wird sie von den Entwicklern geschätzt, und es
werden gleichwertige Stories mit der neuen ausgetauscht.
Reestimate
Wenn der Entwicklungsplan aufgrund neuer Erkenntnisse hinfällig
ist, wird eine neue Abschätzung durchgeführt.
Phasen der »Iteration Planning«
Exploration Phase
Die Entwickler zerteilen die Kundenstories in Tasks, die
Entwickleraufgaben. Diese Entwickleraufgaben werden wie die
Stories in einem mehrstufigen Prozeß optimiert.
Commiment Phase
In dieser Phase werden die Stories von einzelnen Entwicklern
übernommen und mit einer eigenen Zeitschätzung versehen.
Steering Phase
Hier findet die eigentliche Kodierung statt. Die Entwickler melden
Ihren Fortschritt und eine eventuelle Über- oder Unterlastung wird
festgestellt.
Iteration Planning - Commitment Phase
Aufgabe heraussuchen
Jeder Entwickler sucht sich seine Aufgabe selbst.
»Load Factor« setzen
Der »Load Factor« ist der Faktor mit dem die reale
Programmierzeit multipliziert werden muß um dafür benötigte
Arbeitszeit zu bestimmen. Die ist ein persönlicher Wert jedes
Entwicklers.
Balancing
Die Benötigte Zeit für Aufgaben jedes Entwickler wird
aufsummiert und die Arbeitszeit dafür bestimmt. Die Aufgaben
werden bei Über- oder Unterlastung neu verteilt.
Iteration Planning - Exploration Phase
Aufgabe schreiben
Der Entwickler erarbeitet sich aus der Kundenstory mehrere
Programmieraufgaben, die ausgeführt werden sollen. Dabei wird
die benötigte Zeit abgeschätzt.
Aufgabe aufteilen
Läst sich die Zeit nicht schätzen oder sind die Aufgaben zu groß,
(sie dauern länger als ein paar Tage) wird die Aufgabe in
Teilaufgaben zerteilt.
Aufgaben zusammenfassen
Sind Aufgaben ähnlich oder sehr schnell zu realisieren, werden sie
zusammengefaßt.
Iteration Planning - Steering Phase
Aufgabe implementieren
Ein Entwickler nimmt sich eine Aufgabe, sucht seinen Partner,
implementiert die Aufgabe, testet sie und integriert sie in das
Gesamtsystem.
Fortschritt aufzeichnen
Alle 2 oder 3 Tage wird die bisher benötigte Zeit abgefragt und die
noch verbleibende Zeit bestimmt.
Iteration Planning - Steering Phase
Iteration Planning - Steering Phase
Recovery
Wenn ein Entwickler überlastet ist, können folgende Punkte
helfen:
•
•
•
•
•
Umfang einer Aufgaben reduzieren.
den Kunden fragen, ob der Umfang einiger Stories verkleinert
werden kann.
Unwichtige Aufgaben zurückstellen
besser Hilfe bekommen
den Kunden Fragen, ob einige Stories erst in der nächsten
Version kommen können
Story überprüfen
Wenn alle zugehörigen Aufgaben durchgeführt sind, wird die
Story überprüft, ob sie mit den realisierten Aufgaben läuft.
Die Werkzeuge von xP
Planning Game - Iteration Planning
Planning Game
das Team übernimmt die gemeinsame Verantwortung für alle
Stories.
Iteration Planning
Der Entwickler entscheidet sich erst für eine Aufgabe und
bestimmt dann die benötigte Zeit. Nicht alle implementierten
Aufgaben sind einer Story zugeordnet. Diese Aufgaben müssen
identifiziert werden.
Kleine Releases
Metaphore
? einfaches Design
? Testen
? Pair Programming
? kein Codebesitz
? tägliche Integration
? keine Überstunden
? Kundenmitarbeiter im Projekt
? gültige Kodierungs-Richtlinien
?
?
Kleine Releases
Jede Version sollte so klein wie möglich
sein ohne dabei sinnlos zu werden.
Einfaches Design
Für ein einfaches Design gelten folgende Regeln:
jeder Test wird bestanden
keine doppelte Logik
? erfüllt alle Erwartungen des Programmierers
? hat die geringste Anzahl von Klassen und Methoden
?
?
Vorgaben
Jedes Projekt hat eine globale Vorgabe, die
erfüllt werden muß. Sie ist mehr oder
weniger eine bildliche Beschreibung des
Produktes. Diese Vorgabe ersetzt das, was
in anderen Prozessen die Architektur ist
Sie ist das, was die großen Teile miteinander verbindet.
Testen
Alles was sich nicht automatisch Testen
läßt, existiert nicht! Nur durch integrierte
Tests für alle Geschäftsvorfälle wird ein
Programm änderbar und kann weiter
entwickelt werden.
Pair Programming
Alles was entwickelt wird, wird von zwei
Personen bearbeitet, dem Entwickler und
seinem Partner, der die Arbeit kritisch überwacht:
wird es so funktionieren ?
welche Tests funktionieren so nicht
? kann es einfacher gemacht werden
?
?
Gemeinsamer Codebesitz
Jeder darf jeden Code ändern, wenn er
fehlerhaft ist oder verbessert werden kann.
Durch die gemeinsamen Richtlinien wird
bald keiner mehr den ursprünglichen Autor
erkennen.
Pair Programming
Die Zusammensetzungder Paare ist dynamisch
und wird immer wieder neu geregelt. Sie wirkt
sich nicht auf die Zuständigkeit eines Teammitgliedes für seine Programmteileaus, aber die
unterschiedlichenErfahrungen der Entwickler
bieten sich für fachlich orientierte Zusammenarbeit an.
Kontinuierliche Integration
Jeden Tag wird das komplette Projekt auf
den dafür bestimmten Maschinen neu
gebaut. Danach werden alle Tests absolviert
und die eventuell auftretenden Fehler
beseitigt. Erst nach dieser Tätigkeit ist die
Entwicklung für diesen Tag fertig.
40-Stunden Woche
Es werden keine Überstunden gemacht. Ist
die Abschätzung korrekt, kann in der
geplanten Zeit der Teilabschnitt realisiert
werden. Überstunden sind ein deutliches
Zeichen für bestehende Probleme.
Kundenmitarbeiter im Projekt
Um schnell alle anfallenden Fragen zu
klären, wird dem Projekt ein Mitarbeiter des
Kunden zugeteilt, der das Umfeld des zu
entwickelnden Programmes kennt.
Richtlinien
Management
Da jeder in allen Teilen des Codes ändern
darf, sind Richtlinien nötig, die das
Aussehen und die Methode der Codierung
einheitlich regeln. Sie müssen von allen
Teammitgliedern freiwillig akzeptiert
werden.
XP für Manager
Management Strategie
Der größte Fehler, den ein Manager machen
kann, ist es in alte, nicht funktionierende
Mechanismen und Strategien zurückzufallen. Die xP Methoden helfen dagegen.
Hilfen für den Manager
Kleine Änderungen
Der Manager führt andauernd. Er ist nicht auf die Vorgabe am
Anfang eines Projekts beschränkt.
Alles Anpassen
Es ist die Aufgabe des Managers den Einsatz von xP zu
beaufsichtigen und Unterschiede zwischen neuer und alter
Methode zu überbrücken und die entstandenen Konflikte zu
lösen.
Hilfen für den Manager
Erklärte Verantwortlichkeit
Der Manager soll zeigen was getan werden muß. Er soll nicht die
Arbeit verteilen.
Qualitätsarbeit
Die Zusammenarbeit ist von Vertrauen geprägt. Der Manager kann
helfen eine noch bessere Arbeit zu leisten.
Hilfen für den Manager
leicht Reisen
Es werden keine »großen« Entscheidungen verlangt. Alles was zu
tun ist, kann in kurzer Zeit erledigt werden.
ehrliche Meßgrößen
Die Überwachung soll auf realistischen Werten beruhen. In
Sekunden kann kein Projektfortschritt ausgedrückt werden.
Tracking
Tracking ist die zweite Managementkomponente
im xP Prozeß. Das Tracking vergleicht die
Planung mit den real erreichten Werten und
verbessert im nächsten Planungsspiel die
Abschätzung der benötigten Zeiten für die
Implementierungder Kundenwünsche.
Coaching
Der Coach hat nach dem Manager die wichtigste
Funktion im Team. Während der Manager das
Team nach außen hin vertritt, regelt der Coach
die Beziehungen im inneren.
Coaching
Seine Aufgaben sind:
Partner für den Entwickler
? Hilfe für den Neueinsteiger im Team
? Langfristige Neuorganisationenerkennen
? Kurzfristige Neuorganisationenanstoßen
? Programmierernmit eigenem Wissen helfen
? xP in den oberen Management Ebenen erklären
?
Coaching
Weitere wichtige Tätigkeiten sind:
?
?
Spielzeuge beschaffen
Essen beschaffen
Die Entwickler freuen sich über kleine
Spielzeuge, die ihnen die Arbeit »versüßen«.
Damit wird die Kommunikationszoneauf Dauer
interessant gehalten.
... die Gummibärchen
Intervention
Nicht immer läuft alles planmäßig. In diesem Fall
muß der Manager manchmal auch unliebsame
Entscheidungen treffen :
Personalentscheidungen
Prozeßänderungen
? Projektende
?
?
Räume
?
Großraumbüros
Besprechungstisch
Entwicklerarbeitsplätze
? Integrationsarbeitsplätze
? eventuell zusätzliche private Arbeitsplätze
? Kommunaler Bereich
?
?
Verfügung über die Räume
Das xP Team beansprucht die volle Kontrolle
über die Räumlichkeiten.Die Platzaufteilung
wird oft geändert und optimiert werden, bis die
Arbeitsumgebungstimmt.
Rechner
Ein xP Team benötigt schnelle Rechner. Da
täglich integriert werden soll und die gesamte
Codebasis im Zugriff jedes Entwicklers stehen
muß, werden besondere Anforderungen an
Netzwert und Server gestellt.
Impressum
Dieser Vortrag kann im Internet unter
www.fischer-software.de
herunter geladen werden. Er liegt als Star-Office
und als Microsoft-OfficeDokument vor. Bitte
beachten Sie die Copyrights.
Verfügung über die Rechner
Um ein optimales Arbeitsergebniszu erreichen,
darf der Entwickler keiner Einschränkung
unterworfen sein. Er braucht vollen Zugriff auf
seine Ressourcen.
Impressum
Der Autor ist unter folgender Adresse erreichbar:
Hannes Fischer
Fischer Software
Elfenstr. 64
70567 Stuttgart
Tel.: +49 711 9977390
Fax.: +49 711 9977391
Email: Hannes.Fischer@fischer-software.de
Ende
Document
Kategorie
Kunst und Fotos
Seitenansichten
8
Dateigröße
351 KB
Tags
1/--Seiten
melden