Best Practice
Management
Seminar
Softwareentwicklung (Programmierstil), WS2002/2003
Johannes Kepler Universität Linz, System Software Group
Betreuer: Prof. Hanspeter Mössenböck
Autor: Arnold Schneeberger
In dieser
Seminararbeit werden Themen aus dem Bereich
„Best Practice Management“ behandelt.
Es werden zu jedem Themenbereich die diesem
zugrunde liegenden Problematiken erläutert.
Weiters wird versucht, die in der Literatur vorgeschlagenen
Lösungsansätze aufzuzeigen und zu bewerten.
Da „Best Practice Management“ ein sehr breites
Spektrum an Themen bietet,
beschränkt sich diese Seminararbeit auf die Problematiken
der Softwareentwicklung.
Einführung
Abb. 1:
behandelter Themenbereich
Das Managen von
Softwareprojekten ist aufgrund der wachsenden Komplexität sowohl in der
verwendeten Hardware, als auch in der Verwendung der einzelnen Technologien
eine große Herausforderung geworden. Durch die immer größer werdenden Projekte,
die ein Team bewältigen muss, haben sich die Schwerpunkte bei der Softwareentwicklung
von der reinen „Codierung“ in Richtung Design und Management verschoben.
Nicht
unwesentlich bei der Entwicklung von Software ist die Tatsache, dass die
einzelnen Projekte meist Individuallösungen sind und auf Erfahrungswerte nicht
direkt zurückgegriffen werden kann.
Wohl als
wichtigster Faktor bei der Entwicklung von Software ist der Mensch bzw. das
Team zu sehen. Daher sollte man diesem „Faktor“ auch besonderes Augenmerk
schenken.
In Abb.1 sind die
einzelnen Themenbereiche aufgelistet. Da diese Themen ein großes Maß an
menschlicher Intuition und Erfahrung erfordern, ist es sicherlich hilfreich,
sich auf bereits bewährte Praktiken zu stützen.
Guten Programmierstil forcieren
Problematik
Bevor die
Problematik erläutert wird, sollte noch erwähnt werden, dass es hier nicht um die Frage geht „Was ist guter
Programmierstil?“, sondern „Wie kann ich einen guten Stil erreichen?“.
Grundsätzlich hat
sich gezeigt, dass die Einführung von strikten Standards nicht unbedingt die
beste aller Lösungen ist. Zum einen ist die Erstellung und die Handhabung
kompliziert, zum anderen birgt die Einführung gewisse Probleme im Team.
Es kann durch
formalisierte Standards nur ein Teil von dem abgedeckt werden, was man unter
gutem Programmierstil versteht. Wie man Probleme elegant löst, ist eher schwer
formal zu beschreiben bzw. zu vermitteln.
Auch sollte man
sich bewusst sein, dass die Einführung eines Standards Reibungen im Team
hervorrufen kann. Wobei etwaige Konflikte wohl eher „religiöser“ Natur sind und
man solchen aus dem Weg gehen sollte. Grundlegende stilistische Fragen wie
„Klammer in der selben oder eigener Zeile“, sind immer eine Frage des
Geschmacks und über diesen lässt sich bekannterweise nicht streiten.
Daher sollten bei
der Einführung eines Standards folgende Fragen berücksichtig werden:
¨
Wird
der Standard von allen im Team akzeptiert?
¨
Wird
die Person (Vorgesetzter), die den Standard einführt, akzeptiert?
¨
Welche
negativen Auswirkungen kann die Einführung eines Standards im Team hervorrufen?
¨
Gibt
es Alternativen?
Lösungsansätze
Die hier
angeführten Lösungen schließen sich nicht gegenseitig aus, jedoch sind sie je
nach den Gegebenheiten mehr oder weniger gut geeignet.
Zwei Personen arbeiten gemeinsam
am Bildschirm
Bei diesem Ansatz
wird jede Codezeile immer von zwei Personen bearbeitet. Das hat den nahe
liegenden Vorteil, dass eben zwei Personen mehr sehen als eine. Außerdem ist es
positiv, wenn zumindest zwei Personen mit den jeweiligen Codesequenzen vertraut
sind. Man hat dadurch einen gewisse „Ausfallsicherheit“ erreicht.
Wesentlicher
Vorteil ist aber, dass Fähigkeiten ausgetauscht werden und somit auch ein
gemeinsamer Programmierstil erarbeitet wird. Weiters eignet sich diese Methode
zum Anlernen neuer Teammitglieder.
Kontrolle des Programmcodes im
Team
Jede Codezeile
wird in einem kleinen Team von jeweils drei Personen inklusive dem
Programmierer kontrolliert und beurteilt. Die Vorteile sind gleich dem ersten
Ansatz. Außerdem kann sich, bei einem häufig wechselnden Kontrollteam, ein so
genannter „Gruppenstandard“ entwickeln.
Codesequenzen abzeichnen lassen
In anderen
technischen Disziplinen ist es durchaus üblich sich seine Arbeit von einer
erfahrenen Person (Vorgesetzten) abzeichnen zu lassen. Bei Programmsequenzen
ist dies auch möglich und wird von mehreren Firmen so gehandhabt.
Gute Beispiele sammeln
Ein anderer
interessanter Ansatz ist, verschiedene besonders herzeigwürdige Codesequenzen zu
sammeln und zu präsentieren bzw. dem Team als Beispielsammlung zugänglich zu
machen. Der Vorteil dieses „visuellen“ Standards ist die Einfachheit, mit der
man dem Team mitteilen kann, was man unter gutem Programmierstil versteht. Es ist möglich, sehr genau klarzumachen, was
guter Programmierstil ist, ohne dabei auf lästige Formalismen zurückgreifen zu
müssen.
Klarmachen, dass Codesequenzen
„öffentliches Eigentum“ sind
Programmierer tendieren eher dazu, ihre Codesequenzen als
persönliches Eigentum zu sehen. Trotz
allem sollte der Code als öffentliches und für alle zugängliches Eigentum
gesehen werden, mit dem Ziel, den Code zu bewerten und auch kritisieren zu
können. Dieser Ansatz sollte jedoch mit dem nötigen Fingerspitzengefühl
durchgeführt werden. Programmiercodes
sind eben das Ergebnis einer persönlichen Arbeit.
Änderungskontrolle (SCM =
Software Configuration Management)
Problematik
In den einzelnen
Phasen des Projekts können Änderungen auftreten. Diese machen je nach
Projektphase weitere Änderungen notwendig. Änderungen in der Anforderung haben
Auswirkung auf das Design. Dies wiederum beeinflusst die Codeerzeugung und Dokumentation.
Bei größeren Projekten kann ein Änderungsvorgang durchaus ein sehr komplexer
Prozess sein. Je komplexer ein Prozess, umso schwieriger die Durchführung und
umso eher treten Fehler auf.
Abb. 2:
Auswirkung von Änderungen
Unsystematische
Änderungen im Design können dazu führen, dass gewisse Komponenten entwickelt
werden, die im aktuellen Design gar nicht mehr vorhanden sind. Dies führt zu
unnötigem Arbeitsaufwand und Kosten. Je nach Häufigkeit der Integration der
einzelnen Komponenten kann auch die Entdeckung des Fehlers entsprechend lange
dauern.
Des weiteren ist es denkbar, dass einzelne ältere/überflüssige
Programmteile getestet werden und eine anscheinend getestete Komponente
ungetestet weiterverarbeitet wird. Wobei hier auch noch der Grundsatz
berücksichtig werden sollte: je später ein Fehler entdeckt wird, umso kostenintensiver
wird die Fehlerbehebung.
Auch der
gleichzeitigen Änderungen von Codesequenzen durch unterschiedliche Personen ist
vorzubeugen.
Änderungskontrolle
umfasst:
¨
Die
Bewertung von Änderungen (Wünschen)
¨
Die
Kontrolle der Durchführung
¨
Die
Aufbewahrung der einzelnen Zustände des zu ändernden Systems (Projekts)
Spezielles
Augenmerk wird dabei auf
¨
Sourcecode
¨
Dokumentation
¨
Testfälle
gelegt.
Hierbei wird
zwischen
¨
Designänderungen
¨
Codeänderungen
unterschieden.
Im Allgemeinen
ist das Bestreben der Änderungskontrolle bei Projekten, sie immer konsistent zu
halten.
Lösungsansätze bei Designänderungen
Formale Änderungsprozedur
erstellen
Ziel ist es, die
unterschiedlichen Änderungsprozesse formal zu beschreiben und bereits im
Vorfeld die betroffenen Bereiche festzulegen.
Am Ende sollte
jedem Beteiligten der notwendige „Amtsweg“ bei einer Änderung verständlich und
nachvollziehbar sein.
Wandtafel mit Änderungswünschen
Bei Verwendung
einer Wandtafel hat jedes Teammitglied die Möglichkeit, Änderungswünsche
einzubringen. Diese Wünsche werden dann im Team bewertet und nach deren
Wichtigkeit gereiht. Etwaige Wünsche können von reinen Verbesserungsvorschlägen
bis zu offensichtlichen Fehlern im Design reichen. Anhand der Priorität werden
diese Wünsche dann abgearbeitet. Durch die Vergabe von Prioritäten wird vermieden,
dass immer nur die leicht machbaren Änderungen zuerst gemacht werden. Dies kann
nämlich bei Terminproblemen dazu führen, dass zwar sämtliche unwichtigen
Änderungen gemacht werden, aber die eigentlich wichtigen und komplexen
Änderungen aufgrund der Terminprobleme nicht mehr berücksichtig werden.
Aufwand abschätzen / Kosten
bestimmen
Ein Grundsatz
sollte sein, bei jeder Änderung die Kosten zu bestimmen. Zum einen um sich selbst
über den Änderungsaufwand klar zu werden, und zum anderen, um dem Kunden klar zu machen, dass unter Umständen auch
„kleine“ Änderungen einen sehr massiven Aufwand mit sich ziehen können.
Bei aufwändigen Änderungen hellhörig
werden
Kommen vermehrt
Änderungswünsche von Seiten des Kunden, sollten diese
eine Warnung sein. Dies ist ein Indiz dafür, dass die Anforderungen eventuell
noch nicht ausgereift definiert sind. Hier ist es ratsam, die Designphase zu
stoppen.
Jede Änderung bedeutet
einen Aufwand an Zeit und Geld, dies ist auch dem Kunden unmissverständlich
klar zu machen.
Lösungsansatz bei Änderung des
Programmcodes
Version-Control Software
Zur Unterstützung
bei Änderungen an einem Code eignen sich so genannte „Version-Control
Systeme“. Der zugrunde liegende Mechanismus ist sehr einfach. Will man ein File
(Sourcecode) bearbeiten/ändern, wird dieses File als
„in Bearbeitung“ markiert (check out) und ist somit für andere nicht verfügbar.
Ist man mit der Bearbeitung fertig, wird die Markierung aufgehoben (check in).
Zusätzlich bieten die meisten Softwareprodukte auch die Möglichkeit, zu den
jeweiligen Änderungen einen Erklärungstext anzufügen. Bei jedem „Check in“ wird
der alte Zustand jedoch nicht überschrieben sondern separat gespeichert. Dadurch ist die gesamte Änderungshistorie
verfügbar.
Folgende Vorteile
ergeben sich dadurch:
¨
Gleichzeitige
Änderungen nicht mehr möglich.
¨
Alle
Änderungsschritte sind verfügbar.
¨
Da
die meisten Systeme als Server-Client-Architektur fungieren, braucht man sich
hinsichtlich Backups keine Gedanken zu machen. Daten werden direkt am Server
gesichert.
¨
Immer
ein eindeutig „letzter Stand“ ist verfügbar.
Zeitplan
Problematik
„Im Durchschnitt
ist ein Softwareprojekt ein Jahr verspätet und das Budget um 100 Prozent
überzogen“. Diesem ist als Warnung eigentlich nichts mehr hinzuzufügen. Es
zeigt auch, wie schwierig es ist, einen Zeitplan und die damit verbundenen Kosten
zu bestimmen.
Die Ursache für
die falsch eingeschätzten Projekte ist nicht mangelnde/fehlerhafte Entwicklung,
sondern beruht auf zu wenig Erfahrung und daraus resultierende falsche
Abschätzungen.
Einige überspitzte
aber durchaus realistische Ansätze wie man Kosten und Zeit nicht schätzen sollte:
¨
„Für
das Projekt stehen uns 12 Monate zur Verfügung, also wird es 12 Monate dauern“.
¨
„Der
Mitbewerber hat ein Angebot über 1 Mio. Euro abgegeben, dann geben eben wir
eines über 0,9 Mio. ab“.
¨
„Das
Produkt soll auf der nächsten Messe präsentiert werden, also muss die Software
in den nächsten 9 Monaten geschrieben und getestet werden“.
¨
„Das
Projekt wird wahrscheinlich 12 Monate brauchen, das Management wird aber wohl
nur 10 Monate akzeptieren. Dann geben wir eben 10 Monate als Schätzung
bekannt“.
Lösungsansätze
Allgemeiner Überblick
Die Lösungsansätze
zur eben genannten Problematik sind vielfältig.
¨
Algorithmen
wie z.B. COCOMO verwenden
¨
Software
- basierend auf diese Algorithmen - verwenden
¨
Experten
befragen
¨
Projekt
in mehrere Teile aufteilen und diese einzeln bewerten
¨
Projektbeteiligte
befragen
¨
Auf
Erfahrungswerte ähnlicher Projekte zurückgreifen
Algorithmen bzw. Kostenschätzungsmodelle
COCOMO (Constructive Cost Model) ist ein
algorithmisches Kostenschätzungsverfahren. Das Modell basiert auf der Analyse
von Daten aus vergangenen Projekten. Das Modell stellt eine Beziehung zwischen
der Größe des zu erzeugenden Software-Produktes und dem Aufwand in
Personen-Monaten dar.
E = b* KLOCC
E geschätzter Aufwand
KLOC Kilo Lines of Code
b,c Konstanten, die von der Art des betrachteten
Projekts abhängen.
Bei einer
erweiterten Version berücksichtig COCOMO noch 16 Kostenfaktoren (i.e. Cost Drivers) aus 4
Kategorien (i.e. Produkt, Hardware, Personal,
Projekt), die auf einer Nominalskala beschrieben werden.
Die
Kostenfaktoren gehen multiplikativ in die Berechnung des Aufwandes ein
Eneu = E * cdriven
Mögliche
Kostenfaktoren:
¨
geforderte
Verlässlichkeit des Produktes
¨
Komplexität
des Produktes
¨
Beschränkungen
der Laufzeit
¨
Beschränkungen
des Speicherbedarfs
¨
Fähigkeit
der Programmierer
¨
Erfahrung
mit der Programmiersprache
¨
Verwendung
moderner Programmiertechniken
¨
Verwendung
von Software-Tools
Kostenschätzmodelle
beruhen generell auf Erfahrungen der Vergangenheit. Somit ist es zur
Durchführung von Kostenschätzungen essentiell, dass Daten über vergangene
Projekte erhoben werden. COCOMO beruht auf einer Schätzung des Umfanges eines
Produktes und leitet daraus den Zeitbedarf zur Durchführung ab.
Experten befragen
Ein möglicher
Ansatz ist Experten zu befragen. In diversen Fachzeitschriften wird oft die
Vorgangsweise, Durchführung sowie der Aufwand von bekannten Projekten gezeigt.
Bedenkt man, dass
die Angaben nicht immer 100% der Wahrheit entsprechen (welche Firma gibt schon
gern bekannt, welche Probleme sie hatte), so kann man trotz allem die einen oder
anderen nicht bedachten Dinge für das eigene Projekt berücksichtigen. Auch ist
es oft nützlich zu wissen, dass die verwendete Technologie oder die geplante
Vorgehensweise bereits erfolgreich war.
Teile bestimmen und separat
bewerten
Ein Gesetz der
Mathematik besagt, dass der Fehler der Summe größer ist als die Summe der
Fehler.
Es ist also
erstrebenswert, das Projekt in kleinere Teile zu zerlegen und diese einzeln zu
werten. Impliziert natürlich einen gewissen Aufwand an Zeit, da man bereits
wissen sollte, in welche Teile das Projekt zerlegt werden kann. Was aber meist
bei Projektbeginn noch gar nicht so genau spezifiziert ist.
Je genauer die
Zerlegung, umso genauer wird die Abschätzung, jedoch auch umso aufwändiger. Es
sollte also bereits in der Projektplanung der Aufwand der Kosten- bzw. der Aufwandsabschätzung
berücksichtig werden.
Projektbeteiligte fragen
Ein ähnlicher
Ansatz, wie der zuvor beschriebene, ist, die Projektbeteiligten schätzen selbst
ihren Aufwand für die ihnen zugeteilten Projektteile.
Auf Erfahrungswerte
zurückgreifen
Dies setzt
natürlich voraus, dass diese zuvor auch gesammelt wurden. Denkbare Werte können
von Stunden/Projekt bis zu LOC/Projekte reichen. LOC ist für sich alleine
wahrscheinlich nicht sehr aussagekräftig, aber in Kombination mit anderen
Werten durchaus sehr sinnvoll. Grundsätzlich stellt sich die Frage, welche
Werte möchte ich sammeln, ohne dabei den Aufwand ins bodenlose zu treiben und
schlussendlich den Wald vor lauter Bäumen nicht mehr zu sehen (Daten müssen
auch dann noch analysierbar sein).
Fazit
Die hier
gezeigten Ansätze sind für sich alleine eher unbefriedigend, es ist also ratsam,
mehrere dieser Ansätze zu verwenden, um Vergleichswerte zu haben.
Weiters hilfreich
ist, das Projekt laufend zu beurteilen. Je weiter ein Projekt fortgeschritten
ist, umso leichter kann von der Vergangenheit auf die Zukunft geschlossen
werden.
Ein nicht
unwesentlicher Punkt ist auch die Projektgröße selbst. Die hier gezeigte Grafik
soll verdeutlichen, dass der Aufwand für die einzelnen Phasen nicht proportional
zur Projektgröße ist. Es zeigt sich, je größer ein Projekt, umso mehr Zeit
steckt im Design, Architektur und Testen und umso weniger in der eigentlichen
Implementierung.
Abb. 3:
Abhängigkeit des Aufwands für die Projektphasen von der Projektgröße
Eine Zusammenfassung
der Dinge, die sich als besonders erachtenswert erwiesen haben:
¨
Sich
Zeit nehmen (und auch einplanen) für die Aufwandsabschätzung.
¨
Anforderungen
genau formulieren (formalisieren). „Ein schönes, großes Haus“ bietet ein sehr
breites Spektrum an Interpretation.
¨
Verschiedene
Techniken zur Abschätzung verwenden.
¨
Abschätzungen
für das Projekt laufend wiederholen.
¨
Auf
höchstmöglicher Detailebene die Abschätzung vornehmen.
¨
Projektgröße
berücksichtigen.
Terminprobleme
Problematik
Die Problematik
steckt hierbei in der richtigen Handhabung von Terminproblemen. Es hat sich
gezeigt, dass die zuvor erklärten Abschätzungen immer noch um 30% zu
optimistisch sind.
Lösungsansätze
Also was tun,
wenn das Projekt offensichtlich nicht termingerecht fertig wird.
Hoffen, dass es sich ausgeht
Ist hier eher
ironischerweise angeführt, aber in der Praxis durchaus üblich. Projekte tendieren
gerade in der Endphase dazu, dass sie sich in die Länge ziehen. Was wohl eher
darauf beruht, dass die Projekte sich noch nicht in der Endphase befunden
haben.
Das Team erweitern
Brooks´s law besagt: „Adding people to a late software
project makes it later (1975)“. Dies
kann auch sehr leicht veranschaulicht werden. Fügt man zu einem guten Team
weitere Personen hinzu, so steigt unweigerlich der Kommunikationsaufwand.
Weiters kann ein Projekt nicht in beliebig kleine Teile zerlegt und unabhängig
entwickelt werden.
Die typische
Rechnung „Ein Arbeiter produziert 1 Produkt – 10 Arbeiter produzieren 10
Produkte“ ist bei der Softwareentwicklung also komplett fehl am Platz.
Reduktion der Funktionalität
Bleibt also als
letzter Ausweg nur mehr, die Funktionalität zu reduzieren. Sofern dies
überhaupt möglich ist.
Fazit
Die hier
angeführten Ansätze sind nicht gerade befriedigend. Daher ist es ratsam, durch
andere, bereits erwähnte Ansätze, Terminprobleme bereits im Vorfeld zu vermeiden.
Faktor Mensch
Problematik
Software wird
von Menschen gemacht. Die
Software-Leute sind daher neben der Software-Mehrfachverwendung der
entscheidende Produktivitätsfaktor in der Software-Entwicklung. Aspekte der
Psychologie und der Menschenführung spielen somit eine wichtige Rolle in der Software-Entwicklung.
Wesentliche Gedanken dazu enthalten die Bücher von Brooks (1995), DeMarco und Lister (1991) und
Weinberg (1971). In diesem Kapitel werden nur wenige Grundsätze und Regeln
beschrieben.
Menschen
variieren stark in Leistung und Qualität. Da in unseren Breitengraden die
Personalkosten, gerade in der Softwarebranche, den Hauptanteil der
Entwicklungskosten ausmachen, ist es natürlich von Vorteil, dem Faktor Mensch
besonderes Augenmerk zu schenken. Gerade die richtige „Auswahl“ des Teams ist
essenziell für das Gelingen eines Projekts.
Durch den großen
Personalmangel in der Softwarebranche ist die Bindung an eine Firma nicht so ausgeprägt
(eben durch die vorhandenen Jobmöglichkeiten). Starke personelle Veränderungen
der Teams erleichtern das Managen von Projekten auch nicht gerade.
Lösungsansätze
Die hier
angeführten Punkte sind eher als Denkanstöße für die richtige Personalauswahl
denn als direkte Lösungsansätze zu verstehen.
Top 20% Prozent erledigen 50%
der Arbeit
Eine breit
angelegte Studie über mehrere stark unterschiedliche Branchen ergab, dass die
Top 20% der jeweiligen Branche 50% der Arbeit erledigen (Augustine 1979).
Studien im Bereich Softwareentwicklung ergaben ähnliche Resultate.
Starke Variation in
Programmierzeit, Programmgröße, …
Weiters ergab
eine Studie, dass die Programmierzeit zur Lösung eines bestimmten Problems
zwischen 20 zu 1 variierte.
Das Verhältnis
der Debug-Zeit variierte zwischen 25 zu 1 und die
Programmgröße zwischen 5 zu 1.
Arbeitsverteilung
Software-Entwickler
schreiben nicht nur Programme. Eine Studie der Bell Labs ergab, dass der im
Hinblick auf Codeerzeugung produktive Anteil an der Arbeit eines Programmierers
nur 13% beträgt (Bild 10.1).
Abb. 3: Verteilung
der Arbeitszeit eines Programmierers
Gruppengröße
Jede
Entwicklergruppe benötigt einen Teil ihrer Zeit für Organisation und
Kommunikation innerhalb der Gruppe. Mit zunehmender Personenzahl nimmt dieser
nicht produktive Aufwand überproportional zu.
Disponibilität
Personal ist kein
beliebig disponierbarer Produktionsfaktor. Drei Regeln sind zu beachten:
¨
Personalbestände
in einem Projekt können nur langsam auf- oder abgebaut werden. Es ist nicht ohne
Schaden möglich, kurzfristig massive Veränderungen im Personalbestand eines
Projekts vorzunehmen.
¨
Zu
einem gegebenen Entwicklungsaufwand gibt es eine optimale Gruppengröße für die
Bearbeitung und damit eine optimale Durchlaufzeit. Die Rechnung, die Durchlaufzeit
durch den Einsatz von mehr Entwicklern zu verkürzen, geht nur in sehr engen
Grenzen auf.
¨
Das
Aufstocken des Personalbestands in einem verspäteten Projekt führt zu noch mehr
Verspätung (Gesetz von Brooks; Brooks 1995).
Emotionales und rationales in
der Softwareentwicklung
Emotionale
Einstellungen der an Softwareentwicklung Beteiligten haben erhebliche Einflüsse
auf das, was in einer Entwicklungsabteilung tatsächlich geschieht. Der Einfluss
des emotionalen ist umso stärker, je weniger er den Beteiligten bewusst ist. (Glinz 1988).
Arbeitsumgebung
Da Software von
Menschen gemacht wird, haben Ausbildung und Arbeitsumgebung dieser Menschen
einen erheblichen Einfluss auf den Produktionsprozess. Im Buch von DeMarco und Lister (1991) werden
verschiedene Aspekte dieses Problems betrachtet.
Fazit
Wenn sich die
Chance ergibt, einen guten Programmierer einzustellen, sollte man dies auch „um
fast jeden Preis“ machen.
Extreme Programming
(xProgramming)
Seit 1996 wurde
eine neuartige Variante des Software-Engineering, das
Extreme Programming (XP) durch Kent Beck und Ward
Cunningham für Daimler Chrysler entwickelt. Kernpunkte dieser neuartigen
Methode sind die vier Grundpfeiler Kommunikation (communication),
Einfachheit (simplicity), Rückmeldung (feedback) und Mut (courage).
Kommunikation
Die Kommunikation
soll dadurch verbessert werden, dass einheitliche Bezeichnungen, einheitliche
Formatierungskonventionen und einheitliche Kodierungsstandards eingehalten
werden. Benennungen erfolgen danach, was berechnet wird und nicht wie berechnet
wird.
Einfachheit
Diese wird
dadurch erreicht, dass versucht wird, die einfachste Lösung die das gegebene
Problem löst, gesucht wird und nicht für „mögliche“ Szenarien entwickelt wird.
Rückmeldung
Durch frühes
Einbinden des späteren Users können Fehler schon früh erkannt und beseitigt
werden. Auch intensives Testen, z.B. durch Testklassen bei objektorientierter
Entwicklung, bietet ein solches Feedback.
Mut
Es gehört schon
eine ganze Menge Mut dazu, einen Teil der Software während der Entwicklung
einfach auszutauschen. Wenn es nötig ist, soll dies ohne Zögern erfolgen.
Ein wesentlicher
Grund, der zur Entwicklung von xProgramming geführt
hat, ist die Problematik, dass sich die Anforderung an die Software während des
Entwicklungszyklus` oft ändert. Klassische Vorgehensmodelle sind darauf nicht
ausgelegt und verlangen schlimmstenfalls einen Neubeginn der Entwicklung mit
einer erneuten Anforderungsanalyse. Ein wesentlicher Nachteil des xProgramming ist, dass die Methode nur in kleinen Teams von
bis zu 30 Programmierern einsetzbar ist und damit für große Projekte nicht
geeignet ist.
Literatur und Quellen
Brooks, F.P. (1995). The Mythical Man Month. Essays on
Software Engineering. Anniversary Edition Reading, Mass., etc.:
Addison-Wesley. (Neuausgabe des
Originals von 1975)
DeMarco, T., T. Lister (1991). Wien wartet auf Dich! Der Faktor Mensch
im DV-Management. München-Wien: Hanser.
Glinz, M. (1990). Warte
nicht auf bessere Zeiten - Methoden und Werkzeuge in der Software-Entwicklung.
Technische Rundschau 35/90, 70-75
Kent Beck (2000). Extreme
programming explained. Addison Wesley.
Steve McConnell (1993). Code
Complete. Microsoft Press.