Extreme Programming - Wer macht es?
-
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
