“Parallelen zwischen Ironman-Training und Softwareentwicklung”.

Es ist mir schon seit längerem und öfter aufgefallen, das die Vorbereitung für einen Langdistanztriathlon (oder auch für jedes andere sportliche Großereignis) und der Entwicklungsprozess einer Software sich in vielen Aspekten sehr gleichen.

Ich werde hier nun versuchen, die Gemeinsamkeiten und Unterschiede dieser beiden “Disziplinen” dar zu stellen.

Wie bei der Erstellung einer Software, sagen wir mal einer Web 2.0-Plattform, steht auch beim Sport ganz zu Beginn die Frage: “Was will ich ?”. Möchte man “nur” ins Ziel kommen oder möchte man, das die ganze Aktion ein voller Erfolg wird ?

Das Business-Model bzw. das Konzept muss stehen.

Ich gehe jetzt mal davon aus, das sich bei unserer Software das Konzept bereits in einem fast fertigen Zustand befindet.

Auch die Fragen nach dem “Warum ?” und “soll ich wirklich ?” zu Beginn unseres Trainingsplans sind weitesgehest geklärt.
Nun gilt es die Ressourcen zu planen. Bei der Auswahl des Teams bei unserer Software spielen viele Faktoren eine Rolle, Aufwand, Fähigkeiten und nicht zuletzt der Lanuch-Termin.

Bei unserem Projekt “Ironman” ist das “Team” überschaubarer. In der Regel macht mach man das ja alleine, klar, hin und wieder “verschleißt” man ein paar Sparrings-Partner, aber im Großen und Ganzen macht man den Großteil als one-(wo)man-show.

Entscheidner ist auch hier die Ressource Zeit.

Hat man nun alles beisammen: Idee, Ziel, Zeit, Konzept, Team etc. geht es an die Planung. Unsere Software kann nun anhand der unterschiedlichsten Vorgehensmodelle erstellt werden. Es gibt aber immer einen Projektplan der die einzelnen Phasen der Entwicklung abbildet.

Nun gibt es auch in der Trainngssteuerung zum Ironman einen Trainingsplan.

Hier nun ein paar Beispiele für die einzelnen Phasen :

Softwareentwicklung – ganz grob:

- Konzeption – Proof-Of-Conzept – Entwicklung – Testing – Bugfixing – Retesting – Lasttest – Abnahme – Launch

Training – ganz grob:

- Zielsetzung – Training : Grundlagentraining – Aufbautraining – Geschwindigkeit – LD – Testwettkämpfe – Trainingsanpassung auf Grund der Ergebnisse – Tapering  - Wettkampf

Diese einzelnen Phasen werden im Laufe dieser Serie genauer beschrieben.

Teil II : Konzeption/Zielsetzung

Code/Train On

Stephan

Share on Facebook

“Soll ein neues Theme her ?”

Viele sagten : “Nein – so lassen !”

Einige aber auch “JA, weg mit dem alten Zeug “

Letztendlich ist es an mir diese Entscheidung zu treffen – und es gibt auch wichtigere Entscheidungen.

Ich hab mich jetzt dafür entscheiden für einige Zeit  das Theme zu ändern.

Was sagt Ihr ?

Aufgeräumter ?

Oder war das alte Theme doch besser ?

Ach ja die neuen Features gibt es natürlich auf der Startseite von http://slowtwitch.de

Es ist Übrigens das freie Magazine Theme von RichWP.com.

Share on Facebook

Das geht übrigens nicht nur in Perl :)

Share on Facebook

Alles sehr schön und komfortabel.
Plus: Hudson schickt seine Erfolgs und Misserfolgs-Meldungen auf unseren Nabaztag-Hasen :)

Der “neuste Schrei” ist aber das Hudson CI Game Plugin.
Hier wird nach folgenden Regeln :

The rules of the game are:
* -10 for breaking a build
* +1 for doing a build with no failures
* -1 for each new test failures
* +1 for each new test that passes

eine Rangliste erzeugt.

Ziel soll sein, das alle Entwickler bemüht sind den nächsten Build nicht “brechen” zu lassen.
Das führt allerdings auch zu recht “seltsamen” Verhalten.

“Ich führe jetzt nach jedem Commit erstmal ein Hudson Build aus.”

oder

“Mach ja nix kaputt, sonst geht mein Score kaputt ! ”

In der nächsten Version des Plugins sollen sich nun auch Änderungen an den Violations auf die einzelnen Punkte auswirken – das ist mal cool oder was :)

Spass muss sein :)

Share on Facebook