Extreme Programming - lightweight?



  • Hallo,

    und zwar hab ich mich in den letzen paar Tagen ein wenig in Bücher eingelesen, die das Thema "Extreme Programming" behandeln. Jetzt wird es komischerweise in allen diesen Büchern, die ich habe, als "leichtgewichtig" bezeichnet. Ist das in dem Fall einfach nur ein Buzzword, oder was macht "Extreme Programming" so leichtgewichtig?

    grüße
    ein interessierter Leser

    P.S: Hier wär übrigens auch ein idealer Ort um weiterführende Links zum Thema "Extreme Programming" einzubringen 🙂



  • Ausführlicher Entwurf? Dokumentation? gibts pe XP net => daher leichtgewichtig



  • Leichgewichtig dürfte wohl den Entwurfsprozess kennzeichnen (vgl. Wassefallmodell ;))



  • Ich versteh dieses "leichtgewichtig" eher so, dass XP sehr flexibel ist. Ein Projekte, das nach dieser Methode entwickelt wird, ist sehr leicht änderbar, kann also z.B. auch noch während der Entwicklung gut an veränderte Anforderungen angepasst werden. Bei anderen Modellen hingegen ist es so, dass ein Projekt umso träger wird, je weiter es fortgeschritten ist. XP ist also leichtgewichtig, weil es wenig Masse hat und leicht seine Richgung ändern kann.

    @Vertexwahn:
    Wie kommst du darauf, dass es in XP-Projekten keine Dokumentation gäbe? Oder meintest du keine überflüssige Dokumentation 😉 ?



  • Danke, die Antworten klingen allesamt relativ plausibel.



  • Wie kommst du darauf, dass es in XP-Projekten keine Dokumentation gäbe? Oder meintest du keine überflüssige Dokumentation 😉 ?

    ich mein überflüssige Dokumentation 😉
    kommt auf den Kunden an - wenn er das eh nicht will/braucht kann man ja darauf verzichten - aber es gibt Kunden die darauf bestehen und dann hat man mit XP ein Problem - würd mich mal interessieren wie viele Softwareprojekte prozentual mit XP derzeit entwickelt werden...



  • ist die Dokumentation nicht der Sourcecode - es gibt doch bei XP keine Doku!

    zum Thema warum Lightweight: Es gibt nur wenig Vorschriften (keine Trenung in Phasen, keine Artefakte, usw.)

    Fokusierung auf: Testen, Coden, Coden und Coden, kurze Iterationszyklen - nochmal zum Thema Dokumentation: Es gibt bei XP keine!
    folgende Dokument fehlen: Lastenheft, Pflichtenheft, Softwarearchitektur Dokument, ... usw.



  • Man geht ja davon aus das Änderungkosten exponentiell mit dem Fortschreiten der Zeit steigen - z. B. eine Änderung die in der Anforderungsphase 1 Euro kostet, kostet in der entwurfsphase 3 Euro, in der Codierungsphase 20 Euro, in der Testphase 50 Euro in der Produktionsphase 100 Euro

    bei XP versucht man diese Kurve zu drücken und sie konstant zu halten - daher ist die Erklärung von DStefan erst einmal einleuchtent aber meiner Meinung nach falsch.

    Das Leichtgewichtig bezieht sich auf wenig Vorschriften



  • Vertexwahn schrieb:

    ich mein überflüssige Dokumentation 😉
    kommt auf den Kunden an - wenn er das eh nicht will/braucht kann man ja darauf verzichten - aber es gibt Kunden die darauf bestehen und dann hat man mit XP ein Problem

    Vorab: Ich habe selbst noch kein Projekt mit XP durchgeführt. Bloß eins, das sich wenigstens in diese Richtung bewegte.

    Ich nehme an, wir sprechen über die technische Doku? Da würde ich die Entscheidung höchst ungern dem Kunden überlassen! Es sei denn, vielleicht, bei solchen Ex-Und-Hopp-Projekten 😉 Ansonsten widerspricht XP nach meiner Auffassung keineswegs einer anständigen Dokumentation. Nur dass sie vielleicht anders ausfällt, als bei anderen Vorgehensweisen. Ich würde sagen: Sie ist weniger text- und diagrammlastig. Gut dokumentierter Quelltext beispielsweise muss sein! Ganz gleich, nach welchem Modell man sein Projekt durchführt. Und aus der Quelltext-Doku lässt sich sehr leicht eine HTML-Doku erstellen, beispielsweise mit Doxygen. Unit-Tests sind ebenfalls eine Art der Dokumentation. Wenn man den Code liest, sieht man, wie die Klassen verwendet werden sollen. Undsoweiter.

    In einem Projekt, an dem ich mitgearbeitet habe, beschloß das Team, dass wir außer der Quelltext-Doku (und den daraus generierten HTML-Seiten) lediglich eine kurze Darstellung der wichtigsten Konzepte schreiben wollten. Kurz heißt hier, höchstens zehn Seiten pro Konzept. Und die Unit-Tests. Und nichts weiter! Das hat hervorragend funktioniert. Insbesondere wurde die Doku wirklich sowohl gepflegt, als auch gelesen. Was man nach meiner Erfahrung von anders dokumentierten Projekten gerade nicht sagen kann.

    Ein konventionelles Projekt, bei dem ich einstieg war zu diesem Zeitpunkt knapp zwei Jahre alt. Tonnen von Dokumentation, aber alles schon jetzt total veraltet. Die Kollegen sagten mir gleich zu Anfang, ich könne die Doku ja lesen, aber wenn ich wirklich wissen wolle, was los sei, müsse ich im Quelltext nachsehen - oder jemanden fragen, der sich damit auskennt. Ich glaube, das ist typisch. Eine ausführliche Dokumentation wird von denen verlangt, die keine Software-Entwickler sind. Eine Art Beruhigungspille, nichts weiter. Und wenns auf eine Deadline zugeht, sind diese Leute die ersten, die sich aufregen, wenn die Pflege der Doku die "eigentliche" Arbeit aufhält...

    Vertexwahn schrieb:

    würd mich mal interessieren wie viele Softwareprojekte prozentual mit XP derzeit entwickelt werden...

    Ich würde schätzen, sehr, sehr wenige. Ohne nähres zu wissen selbstverständlich 😉 XP widerspricht der Mentalität der Deutschen. Wir brauchen "handfeste" Planung und wir brauchen Hierarchien. Unsere "Führungskräfte" wollen auf dem Feldherrenhügel stehen und mit großen Gesten ihre Truppen lenken. XP macht das schwierig, da muss jeder tendenziell eher dienen als befehlen, sich in seine Rolle fügen, sozusagen dem Projekt untertan sein.

    In Vorbereitung auf das oben angesprochene Projekt hatten wir genau das Problem. Das Team wollte soviel XP wie möglich. Weil wir Erfolg haben und es wirklich gut machen wollten. Keine Chance! Über manche Aspekte wollte man nicht einmal diskutieren. Es stellte sich heraus, dass eine kurze, schriftliche Diskussion der wichtigsten XP-Komponenten von den "Führungskräften" nicht einmal gelesen worden war. Obwohl sie das Dokument selbst angefordert hatten. Und der Totschläger war immer wieder die (angeblich) mangelnde Führungsfähigkeit. Man könnte es auch so sagen: Die Leute hatten einfach Angst. Lies bei Herrn Beck nach: Eine der Tugenden, die er aufführt ist Mut. Eine weitere, dem Projekt oberste Priorität einzuräumen, also für den Kunden den maximalen Wert zu schaffen. Beides findet man in Deutschland selten.

    Stefan.


Anmelden zum Antworten