Jun 262008
 

Gestern Nachmittag war ich an diesem Event. Das war mal wieder was
spannendes.

Vor allem die Geschichte mit der Agilen Softwareentwicklung interessierte
mich. Diese Technik würde mich, ehrlich gesagt, mehr ansprechen als die
jetzige Lösung.

Ich fragte mal nach, ob es eine Mindestgrösse von Projekten braucht
um so was zu betreiben. Müssten das Projekte von > 100 Manntage sein,
muss das Team eine Mindestgrösse haben?

Die Antwort von Marcel Baumann (Dipl.-Ing. Inf. EPFL, MBA, Gründer und CTO
der bbv Software Services AG
) war eindeutig.
Nach unten gibt es keine Mindestgrösse an Projekt oder Team. Es kann
im extrem Fall ein 1 Mann Projekt sein das 1 Tag dauert. 🙂 Na ja.
Ab das wirklich Sinn macht weiss ich nicht.

Aber nach oben gibt es Grenzen. Vor allem bei der Teamgrösse. Ein Team,
wo alle Mitglieder im selben Raum sind und NUR diesem Projekt nachgehen,
sollte nicht grösser als 10 Personen werden.

Auch so Techniken wie Test Driven Development (TDD) und Mocking (NMock2)
würden mich als Entwickler auch sehr interessieren. Aber dabei sehe
ich immer wieder das Problem, dass kein Kunde den Mehraufwand bezahlen
will. Der Kunde will einfach eine funktionierende Software. Er will
nicht gleich viel Test-Code wie Produktiv-Code.

Bei mir ist es vielfach so, dass ich ein Projekt in 20-50 Manntage fertig stelle,
ausliefere, und wenn es dann läuft wird es “vergessen”. In der Regel hört man
da nichts mehr von der Software. Was soll ich da also noch viel Test-Code schreiben?

Das sind aber durchaus Themen wo man Stundenlang diskutieren könnte.

Aber cool wäre es trotzdem.

Tags: , , ,

  3 Responses to “bbv – System Event 2008 – Agile Softwareentwicklung im Praxistest!”

Comments (3)
  1. TDD wird dir nur ganz am Anfang mehr Aufwand bescheren… du wirst sehr schnell wohl eher Zeit sparen.
    Der Punkt ist ja, dass du den Code den du schreibst, so oder so irgendwie auf seine Funktion prüfen musst – und der UnitTest liefert da eine sehr einfache und schnelle Möglichkeit zu.
    Zweiter Punkt ist auch, dass du dir beim Schreiben vom Test erst richtig über die eigentliche Funktion im Klaren wirst (hängt natürlich von der Komplexität ab) – mit steigender Qualität deiner Tests wirst du quasi als "Bonus" sinkende Zeit bei der Implementation erfahren. Und auch die Schlusstests werden wesentlich entspannter werden.

  2. Arbeitest du bei bbv? 🙂

    Die kritischen Fragen kamen natürlich auch. Vor allem die Sache mit dem mehr an Code schreiben.

    Die Antwort war genau die Selbe wie von dir.

    Ich glaube, man muss es einfach mal gemacht haben um es zu beurteilen.

    Ich könnte es mir gut vorstellen so zu arbeiten. Aber dafür muss natürlich die Unterstützung der Firmenleitung da sein. Und das ist dann ein anderes Thema.

  3. Nein tu ich nicht 😉

    Aber ich habe auf dieselben Fragen auch immer diese Antwort gehört, bis ich es wirklich mal ernsthaft ausprobierte – dann glaubte ich es auch 🙂

    Schlussendlich profitieren alle… da kann nicht mal die Firmenleitung was dagegen haben 🙂

Sorry, the comment form is closed at this time.