Extreme Programming - Wer macht es?



  • Bei uns wird so gearbeitet (nicht ganz aber so ähnlich). Die Software wird immer um weitere Funktionen erweitert, was sich der Kunde (oder Chef) meint, dass er es braucht, kommt rein. Nur fehlt irgendwie einer der den Überblick über alles hat. Es gibt einige Features die asynchron ablaufen, aber weil oft nicht an alles gedacht wird kommt es vor, dass sich die Features unter bestimmten umständen gegenseitig beeinflussen. Was irgendwann in kaum reproduzierbaren Fehlern endet. Liegt das am Extreme Programming oder am zu fahrlässigen umgang mit Threads bei uns?
    Was habt ihr sonst für Erfahrungen mit XP gemacht? Wie behält man den Überblick über alles?



  • ZuExtrem schrieb:

    Nur fehlt irgendwie einer der den Überblick über alles hat.

    Den sollten eigentlich alle haben. Dafuer gibt's doch Stand-Up-Meetings und Wechsel der Aufgaben.



  • Hm... Das mit dem wechsel der Aufgaben fehlt bei uns oder findet nur zufällig statt, weil irgendwo mehr zu tun ist.



    1. Eine Regel von XP lautet: "Mut!" - Bereit zu sein wieder stellenweise von Vorne anzufangen.

    2. Wenn mit Multi-Threading gearbeitet wird sind Performance- und Lasttests unabdingbar. Vor Allem würde ich mich nicht ohne Referenzmuster vorwagen Z.B.: http://www.amazon.de/Pattern-Oriented-Software-Architecture-Concurrent-Networked/dp/0471606952/sr=1-10

    3. Der Kunde muss in XP Bestandteil des Entwicklungsteams sein, wenn er mal kurz die Nase reinsteckt und sagt ich brauche das und das und danach für zwei Wochen verschwindet kannst Du XP nicht betreiben.

    4. Kontinuierliches Refactoring ist ein Muss in XP. Also einfach Feature reinsetzen ist nicht.

    5. Ein Change Request innerhalb einer Iteration kann dazu führen, dass die ganze Iteration flöten geht.

    6. Manchmal hilft es auch den Anteil von Dokumentionen und Modellen zu erhöhen. Dabei werden die Anzahl der Features in der Iteration gesenkt.

    7. Unit Tests, Unit Tests und noch mehr Unit Tests
      Empfehlenswert: http://www.amazon.de/Testgetriebene-Entwicklung-Software-änderbar-bleibt/dp/3898642208/sr=1-1/

    8. Oder die Iteration verlängern und in der Entwicklung keine CR mehr zulassen.

    9. Pair Programming reduziert Fehler durch gleichzeitige High- und Low-Level Betrachtungen.



  • Prof84 schrieb:

    1. Ein Change Request innerhalb einer Iteration kann dazu führen, dass die ganze Iteration flöten geht.

    😮 Wenn es nur einer wäre, wäre das bei uns schon ein riesen Fortschritt.



  • ZuExtrem schrieb:

    Prof84 schrieb:

    1. Ein Change Request innerhalb einer Iteration kann dazu führen, dass die ganze Iteration flöten geht.

    😮 Wenn es nur einer wäre, wäre das bei uns schon ein riesen Fortschritt.

    Dutch this:
    http://www.incose.org/practice/guidetosebodyofknow.aspx
    http://www.incose.org/practice/fellowsconsensus.aspx
    http://g2sebok.incose.org/





  • ZuExtrem schrieb:

    Bei uns wird so gearbeitet (nicht ganz aber so ähnlich). Die Software wird immer um weitere Funktionen erweitert, was sich der Kunde (oder Chef) meint, dass er es braucht, kommt rein. Nur fehlt irgendwie einer der den Überblick über alles hat. Es gibt einige Features die asynchron ablaufen, aber weil oft nicht an alles gedacht wird kommt es vor, dass sich die Features unter bestimmten umständen gegenseitig beeinflussen. Was irgendwann in kaum reproduzierbaren Fehlern endet. Liegt das am Extreme Programming oder am zu fahrlässigen umgang mit Threads bei uns?
    Was habt ihr sonst für Erfahrungen mit XP gemacht? Wie behält man den Überblick über alles?

    Sowas ähnliches wird bei uns auch gemacht. Man kann dazu auch sagen "Evolutionäres Prototyping" mit XP. Im Grunde hab ich die gleichen Erfahrungen gemacht wie du. Seltsame Fehler die auftreten weil sich "Features" gegenseitig beeinflussen (merkmal für Design Fehler). Es gibt kein allumfassenden Überblick und eine schlechte Doku...

    Naja im Grunde das gleiche wie bei dir. Das ist die schlimmste Art der Softwareentwicklung!

    Schau dir am besten die Antworten in meinem Thread dazu an

    http://www.c-plusplus.net/forum/viewtopic-var-t-is-173446.html



  • Prof84 schrieb:

    ...
    Dutch this:
    ...

    Was haben denn nun wieder die Käsköppe damit zu tun ? 😉

    Gruß,

    Simon2.



  • Meiner bescheidenen Meinung nach besteht doch ein deutlicher Unterschied zwischen XP und "einfach drauf los programmieren"... das kommt hier aber etwas anders rüber. Nicht jeder der chaotisch und ohne großes Lastenheft/Pflichtenheft programmiert, wendet auch XP an. (Wobei das natürlich schicker klingt.)



  • Marc++us schrieb:

    Meiner bescheidenen Meinung nach besteht doch ein deutlicher Unterschied zwischen XP und "einfach drauf los programmieren"... das kommt hier aber etwas anders rüber. Nicht jeder der chaotisch und ohne großes Lastenheft/Pflichtenheft programmiert, wendet auch XP an. (Wobei das natürlich schicker klingt.)

    Japp, das Gefühl habe ich nämlich auch. Wichtig ist auch, dass es nicht wirklich möglich ist einzelne Techniken aus XP zu übernehmen. Wer agil entwickeln will, der muß auch regelmäßig Refactoring betreiben. Wer Refactoring vernünftig betreiben will braucht Unit-Tests usw. So gesehen XP ist mehr als die Summe seiner Teile. Es ist keine Kiste von tools aus denen man einfach so ein paar einsetzen kann, die einem spaß machen und andere weglässt, weil sie anstrengend sind. Bei XP lautet die Devise: ganz oder garnicht.

    Ich verstehe nicht wirklich wie man dann solche Berge von Fehlern erzeugen kann. Bemerkt man einen Fehler, so schreibt man einen Unit-Test dafür. Erst anschließend behebt man ihn. Dadurch ist sichergestellt, dass der Fehler auch nie wieder auftaucht.



  • Marc++us schrieb:

    Meiner bescheidenen Meinung nach besteht doch ein deutlicher Unterschied zwischen XP und "einfach drauf los programmieren"... [...]

    Soweit ich ja weiß (allerdings auch nur aus der Theorie) muss ja sowieso zuerst mal die Summe der gewünschten Features erfasst werden und diese werden dann nacheinander (abhängig von der Priorität) abgearbeitet, bzw. implementiert, damit der Kunde, selbst wenn das Projekt nicht fertiggestellt wird, eine Anwendung geliefert bekommt, mit der er halbwegs arbeiten kann. Ich kann mich jetzt aber auch täuschen, nachdem die Theorie dazu schon wieder eine Zeit lang her ist.



  • ... schrieb:

    Marc++us schrieb:

    Meiner bescheidenen Meinung nach besteht doch ein deutlicher Unterschied zwischen XP und "einfach drauf los programmieren"... [...]

    Soweit ich ja weiß (allerdings auch nur aus der Theorie) muss ja sowieso zuerst mal die Summe der gewünschten Features erfasst werden und diese werden dann nacheinander (abhängig von der Priorität) abgearbeitet, bzw. implementiert, damit der Kunde, selbst wenn das Projekt nicht fertiggestellt wird, eine Anwendung geliefert bekommt, mit der er halbwegs arbeiten kann. Ich kann mich jetzt aber auch täuschen, nachdem die Theorie dazu schon wieder eine Zeit lang her ist.

    Nicht nur nach Priorität. Man bewertet die Features mit Punkten, die den Aufwand darstellen sollen. Dann legt man die Anzahl an Punkten fest, die man pro Iteration schafft. Der Kunde darf dann sagen welche Features er in dieser Iteration haben möchte, muß sich dabei aber an das Punktelimit (und eventuelle Abhängigkeiten der Features) halten. Nach Abschluß der Iteration wird dann ein Soll/Ist-Vergleich gemacht und daraus ergibt sich dann die Anzahl der Punkte für die nächste Iteration, nämlich die Anzahl der geschafften Punkte. Außerdem wird eventuell der Aufwand für einige Features neu geschätzt.



  • @Jester: XP hört sich an wie Balaced Scorecards... 🤡

    Greetz, Swordfish



  • Jester schrieb:

    Ich verstehe nicht wirklich wie man dann solche Berge von Fehlern erzeugen kann. Bemerkt man einen Fehler, so schreibt man einen Unit-Test dafür. Erst anschließend behebt man ihn. Dadurch ist sichergestellt, dass der Fehler auch nie wieder auftaucht.

    Das reicht nicht. Unit-Tests haben wir, wenn es auch mehr sein könnten.
    Das Problem ist mehr die Integration der einzelnen Sachen. Wenn man einen Prozess hat, der im Hintergrund aufwendigere Sachen macht und dann die Ergebnisdaten speichert, dann läuft der auch und der Test ist erfolgreich, wenn er allein läuft. Das einfache speichern von eingegebenen Daten und funktioniert auch (auch im Test). Wenn man dann beides kombiniert, dann kann es passieren, dass der User Daten eingibt und diese erfolgreich speichert. Kurz darauf ist der Hintergrundprozess fertig und überschreibt die Daten mit seinen Ergebnissen, diese können möglicherweise wieder (fast) genauso aussehen, wie die vor der User gespeichert hat. Vom User bekommt man dann die Nachricht, dass er was eingegeben hat, aber das nicht gespeichert wurde, weil er nicht weiß, dass es einfach nur überschreiben wurde. Bis man sowas rausfindet, ist man lange am Suchen.
    Ich bin mir sicher, dass wir nicht wirklich richtiges XP betreiben, aber Unit-Tests reichen da nicht aus. Ob es da reicht, immer wieder die Aufgaben zu tauschen, bin ich mir nicht sicher, möglicherweise wird etwas besser. Es fehlt einfach jemand der den gesammten Prozess im Detail überblickt.



  • Dann fehlt Euch vielleicht noch der berühmte "Software Architect (TM)".



  • Swordfish schrieb:

    @Jester: XP hört sich an wie Balaced Scorecards... 🤡

    Auch das ist wieder nur *eine* Technik. Die Kombination macht's.



  • Marc++us schrieb:

    Dann fehlt Euch vielleicht noch der berühmte "Software Architect (TM)".

    Ich glaub unser Chef versucht sich in der Rolle, aber drauf hat er es nicht. Irgendwie sollen es wohl alle ein bisschen sein, aber ein bisschen geht halt nicht.



  • Das lässt sich aber grundsätzlich lösen. Wenn Ihr eine Gruppe von n Leuten sind, und alle n programmieren, dann kann das nicht funktionieren. Irgendeiner von Euch darf höchstens 50% aktiv in der Programmierung arbeiten, und muß die Koordination und Planung der Zusammenarbeit der Module übernehmen. Das muß nicht zwangsläufig der Chef sein, da dieser vermutlich auch noch Verwaltungsaufgaben und anderes Geraffel zu erledigen hat. Der zunächst sichtbare Produktivitätsverlust sollte sich rasch amortisieren. Zudem ist eine solche geänderte Rollenverteilung auch rasch und eher unauffällig umsetzbar.



  • Jester schrieb:

    Swordfish schrieb:

    @Jester: XP hört sich an wie Balaced Scorecards... 🤡

    Auch das ist wieder nur *eine* Technik. Die Kombination macht's.

    Ja, genau das wollte ich mit meinem schon zynisch gemeinem Kommentar ausdrücken. Das Schlimme: Wenn man sich einer solchen Ideologie (und jede für sich genommen IST eine) hingibt wird man realitätsfern (Automatismus).

    greetz, Swordfish


Log in to reply