Extreme Programming

Hallo,

falls ihr mal etwas Zeit (1:42:14) übrig habt, empfehle ich euch folgenden Podcast "Extreme Programming". (Die anderen knapp 200 Podcasts sind auch alle super!)

Was meint ihr zu dem Thema? Wie gut ließe sich XP mit der Entwicklungsumgebung LabVIEW umsetzen? Oder hat gar jemand schon mal in so einem Team gearbeitet?

Ich persönlich arbeite erst seit wenigen Wochen in einem Team. Vorher immer alleine. Hab mir deswegen da nie Gedanken zu gemacht.


Gruß dimitri

Anzeige

Hallo,

ich habe gerade keine 1:42:14 Zeit und habe nur noch mal die Wikipediaseite in Erinnerung geholt. Ich hoffe die Ansätze sind vergleichbar.

Ich habe den Eindruck, dass viele Entwicklungen unter LabVIEW unter XP fallen auch wenn nur eine Person daran arbeitet. Insbesondere mit der Entwicklungsumgebung von LV geht das ja ganz leicht. Sobald das Main-VI gültig ist, kann ich starten, sehen was passiert und die VIs solange verbessern bis alles so läuft bis der Kunde (oder ich selbst zufrieden bin). Auch sich ändernde Spezifikationen sind schnell anghängt.

Ich sehe jedoch die Gefahr, dass der bei der XP erzeugte Code zu schnell nicht mehr wartbar ist, weil immer wieder etwas angeklebt wird, was ggf. zu unsauberen Workarounds führt. Hier muss man gut aufpassen, dass XP richtig durchgeführt, was mir nicht ganz einfach erscheint.

Ein gewisses Maß an Planung, finde ich, muss sein. Auch mögliche Eventualitäten und mögliche Erweiterungen sollten beim ersten Ansatz mit eingeplant werden.

Ich persönlich finde Scrum als agile Programmiermethode überzeugender; habe aber auch noch nicht wirklich im Team programmiert.

Gruß
Unicorn

Hallo Unicorn,

heute habe ich folgendes Bild entdeckt
   


zum Thema:

"Sobald das Main-VI gültig ist, kann ich starten, ..."
So ist das mit den Unit Tests nicht gemeint. Es geht nicht um Syntax-Fehler, sondern um gut überlegte zyklische Plausibilitätstests - jedes mal, wenn man beim Repository committet. An dieser Stelle finde ich eine Abwägung über Kosten/Nutzen sehr schwierig. Der Protagonist im Podcast spricht von einem ganz tollen Framework zum testen (C++), was die Abteilung extra entwickelt hat.

"auch wenn nur eine Person daran arbeitet"
Was da an Know-How-Transfer stattfindet, wenn ein Team alle paar Tage neue zweier Gruppen bildet und diese dann nur zu zweit programmieren, das hat doch riesig Potential.

"weil immer wieder etwas angeklebt wird, was ggf. zu unsauberen Workarounds führt"
Ich glaube gerade weil, jeder Einblick überall hat, und auch immer und überall etwas ändern darf, wird es sauberer.

"Scrum als agile Programmiermethode "
google ich mal



Gruß dimitri

Es gibt LVUnit, zum Unittesten von LabVIEW. Es ist mir aber zu umständlich.
Ich schreibe aber viel Algorithmen mit LV und habe da ein eigenes kleines Framework zum Testen. Also einen Satz (zB 1000 hand-"processte" Probebilder) an Samples, die dann zumindest einmal am Abend/nightly (je nach Laufzeit) durchlaufen, und mir per Email schicken, wie viel % richtig klassifiziert werden. Der Wert sollte natürlich bergauf gehen :-)
In der Regel aber öfter mit einem kleineren Samplesatz, denn es macht durchaus Spaß, seine "Highscores" zu knacken

Continous Integration ist auch so ein Stichwort, haben wir - ab einem gewissen Punkt. Mit viel Hardware ist das zT schwierig.

Ich kenne auch Cpp-Unit (ich bin auch viel in der Welt unterwegs), und mit TDD macht man viel richtig. Da kenne ich auch (echtes) Pair Programming (super!) und Scrum - das hat seine Vor-und Nachteile und kommt oft genau darauf an, wie gut der Kunde schon am Anfang weiß, was er will. (Und wie sehr man ihn einbeziehen kann/will). Es gibt durchaus genug Projekte, für die Wasserfall besser ist.

LabVIEW verleitet meiner Meinung nach gerade am Anfang zum "Cowboy-Coden", ohne jegliche Softwarearchitektur und Entwurfsmuster und vernünftig entworfene Datenstrukturen. Das sollte man nicht mit agiler Entwicklung verwechseln.