Laden...

Woran erkenne ich einen guten Softwareentwickler?

Erstellt von Bini vor 17 Jahren Letzter Beitrag vor 17 Jahren 11.613 Views
Bini Themenstarter:in
195 Beiträge seit 2004
vor 17 Jahren
Woran erkenne ich einen guten Softwareentwickler?

Die Frage im Betreff stellt sich derzeit, weil wir einen solchen einstellen wollen/müssen. Wenn ich die Chance bekomme, bei der Auswahl des künftigen Kollegen mitwirken zu können, würde ich die gern sinnvoll nutzen.

Nun lagen hier etliche Bewerbungen auf meinem Schreibtisch, größtenteils Stepstone-Profile, in denen ich schon mal das Vorhandensein oder Nichtsein von C-Kenntnissen checken konnte.

Aber:
Wie unterscheide ich konkret, ob einer den gesamten Softwareerstellungsprozeß beherrscht, inkl. Lieferung bis zum Kunden, oder ob der Bewerber nur gut ist im direkten Coden?

Hintergrund: die meisten in meiner Firma haben akademischen Hintergrund und wenig bis keine Industrieerfahrung. Wir brauchen also unbedingt jemanden, der nicht nur Algorithmen in Quellcode umsetzen kann, sondern dem bewußt ist, daß der Softwareerstellungsprozeß wesentlich mehr umfaßt und der das möglichst auch drauf hat...

Welche Fragen könnte man einem Bewerber stellen? Ich bin da völlig unerfahren (akademischer Hintergrund eben 😉) Eine Personalabteilung gibt es bei uns nicht, dazu sind wir zu klein.

Umwege erhöhen die Ortskenntnis.

E
109 Beiträge seit 2006
vor 17 Jahren

hi bini,
führ doch mit ihm ein "beratungsgespräch". gib ihm kurze einarbeitungszeit für das thema und dann soll er dich beraten über xxx. (sollte schon themenspezifisch sein 😉)

dann kannste ihn ja fragen wie er ein projekt planen würde. also angefangen mit den umrissen und wünschen des kunden, sachmittel-, kosten-, personal-, zeitplanung...

wie er die durchführungsphase beim kunden gestalten würde.

das auftreten is wichtig - smart, not casual

hoffe konnte dir etwas helfen

gruß,
emmi

Es gibt keine Probleme - nur Herausforderungen!

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Bini
Hintergrund: die meisten in meiner Firma haben akademischen Hintergrund und wenig bis keine Industrieerfahrung. Wir brauchen also unbedingt jemanden, der nicht nur Algorithmen in Quellcode umsetzen kann, sondern dem bewußt ist, daß der Softwareerstellungsprozeß wesentlich mehr umfaßt und der das möglichst auch drauf hat...

Gegenfrage: Welchen SW-Prozess setzt ihr ein?

Wenn die Antwort lautet: "Keinen", dann sucht ihr einen Wunder-Heiler und keinen Entwickler. SW-Prozesse etabliert man nur von oben, nicht von unten. Wenn Chefs glauben, sie könnten ihr SW-Problem lösen, indem sie kompetente Mitarbeiter einstellen, dann haben sie sich geschnitten. Prozessverantwortung liegt beim Management.

Ansonsten würde ich nach folgenden Erfahrungen fragen:

* Konfig-Management
* Unit-Tests
* vielleicht noch UML

Aber ehrlich: In 90% aller Buden wird sowieso gefrickelt. Daher wirst du schwer einen finden....

S
281 Beiträge seit 2004
vor 17 Jahren

wenn ich bewerber aussuchen dürfte, würde ich schonmal bei den bewerbungen richtig aussortieren

stepstoneprofile sind ok, aber ich finde man sollte trotzdem immernoch nen persönlich verfassten text mitschicken daran kann man auch schon bisschen interesse ableiten.

vorstellungsgespräch ist auch ein muss

aber bevor ich jetzt vom thema abkomme bzw ich war noch garnet dabei 😁
es ist immer ein risiko jemanden unbekannten einzustellen. aber das risiko lässt sich durch ein praktikum mindern. so kann man zumindest live sehen ob er was taugt.

89 Beiträge seit 2006
vor 17 Jahren

Original von svenson
Aber ehrlich: In 90% aller Buden wird sowieso gefrickelt. Daher wirst du schwer einen finden....

Wenn es doch nur 36 Std. Tage gaebe... und ich trotzdem nur 5 Std. schlafen muesste....

Nichtsdestotrotz wuerde ich auch nach Projekterfahrung fragen, also ob er irgendwas von a (kundenanforderungen analysieren, loesungen ausdenken) ueber m (entwicklung, tests, design) bis z (rollout, kundeneinweisung, support) gemacht hat, bzw. beteiligt war.

4.207 Beiträge seit 2003
vor 17 Jahren

Kriterien für gute Softwareentwicklung (es ging ja nicht um Projektmanagement oder Softwarearchitektur) sind zum Beispiel:

  • Kenntnis von Code Conventions
  • Wie oft wird kompiliert
  • Welche Kenntnisse bezüglich des Aufbaus von Buildprozessen sind vorhanden
  • Wie (und vor allem WAS) würde er kommentieren und dokumentieren?

Kurzum - lass Dir das ganze "Drumherum" erklären, wie er daran gehen würde ... stell vielleicht ein paar gezielte Fragen mit dem Hintergrund, in welche Richtung ihr wollt ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

6.862 Beiträge seit 2003
vor 17 Jahren

Was ich auch ne ganz nette Idee finde ist dem Bewerber ein Programm entwerfen zu lassen im Bewerbungsgespräch. Also nichts fertiges natürlich, aber halt ne Aufgabe wo der Bewerber erklären soll wie er vorgehen würde, was für Technologien er dabei benutzen würde(siehe svensons Punkte), was für Risiken er sieht, etc. Und das am besten zusammen im Gespräch mit dem Entscheidungsträger des Arbeitgebers. So sieht der nämlich wie der Bewerber denkt, was er kann, und wie kommunikativ er ist.

Baka wa shinanakya naoranai.

Mein XING Profil.

89 Beiträge seit 2006
vor 17 Jahren

Original von Golo Haas

  • Wie oft wird kompiliert
  • Welche Kenntnisse bezüglich des Aufbaus von Buildprozessen sind vorhanden
    ...

Wuerde mich freuen wenn du darauf etwas naeher eingehst, bzw. erklaerungen gibst

4.207 Beiträge seit 2003
vor 17 Jahren

Wenn jemand alle drei Minuten kompiliert, spricht das nicht dafür, dass er nachdenkt, was er macht, sondern dass er mit Trial and Error vorgeht.

Interessanterweise gibt es inzwischen von Microsoft ein Tool, das misst, wie oft kompiliert wird, und gegebenfalls die Kompilierzeiten künstlich verlängert, so dass man seltener kompiliert. Der Name ist "Marvin" oder ähnlich, in einer der letzten dotnetpro-Ausgaben stand ein Artikel darüber.

Bezüglich der Buildprozesse - was weiß derjenige über Buildserver, über den Einsatz von Buildtools wie NAnt, CruiseControl.NET, wird so etwas wie FxCop eingesetzt (wobei das eher Codequalität ist), hat er Erfahrung mit der Eskalation des Builds über mehrere Server (Buildserver, Testserver, Prodserver, ...), wie sieht es gegebenfalls mit dem Einsatz von UnitTests und Code Coverage aus, ...

Etwas klarer, was ich meine?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

89 Beiträge seit 2006
vor 17 Jahren

Jepp, Danke. Ich weiss jetzt schon, was ich heute Abend lesen werde 😉

Bini Themenstarter:in
195 Beiträge seit 2004
vor 17 Jahren

Original von svenson
Gegenfrage: Welchen SW-Prozess setzt ihr ein?
Wenn die Antwort lautet: "Keinen", dann sucht ihr einen Wunder-Heiler und keinen Entwickler. SW-Prozesse etabliert man nur von oben, nicht von unten. Wenn Chefs glauben, sie könnten ihr SW-Problem lösen, indem sie kompetente Mitarbeiter einstellen, dann haben sie sich geschnitten. Prozessverantwortung liegt beim Management.

Da stimme ich völlig zu. Leider nützt diese Erkenntnis nicht viel, wenn sie sich nur bei mir befindet 😉
Die EDV führt ein nicht sonderlich geschätztes Dasein bei uns und der neue wird auf jeden Fall einen schweren Stand haben, an dem Projekt haben schon zwei Leute gebastelt, der zuletzt verantwortliche ist bereits entlassen, so daß es auch keine persönliche Übergabe mehr geben kann...
Genau deshalb brauche ICH einen Kollegen, der mehr als coden kann - aber ein Wunderheiler muß es nicht gleich sein 🙂

Danke für die genannten Punkte!

Original von Golo Haas
Kriterien für gute Softwareentwicklung (es ging ja nicht um Projektmanagement oder Softwarearchitektur) ...

Hm, da hab ich mich vielleicht zu kurz ausgedrückt 🤔

Doch, es geht auch um das Management, wenn man so will. Das wird ein Ein-Mann-Projekt sein, d.h. derjenige muß ALLES abdecken, von der Anforderungsanalyse mit manchmal sehr sperrigen Usern 🙁 über die Programmierung bis zur Lizenzierung und Betreuung beim Kunden.

Ja, er muß eine eierlegende Wollmilchsau sein, ich weiß. Aber so ist es, wir müssen den finden, der das am besten hinkriegen kann und da denke ich, daß genau das, was Du aufführst, zu wenig ist.
Ich merk schon, ich weiß nicht, was ich fragen soll, weil ich es selbst nicht so gut kann X( (Buildprozesse)

Umwege erhöhen die Ortskenntnis.

4.207 Beiträge seit 2003
vor 17 Jahren

Hmmm, ohne Dir da jetzt zu Nahe treten zu wollen, aber es gibt zig verschiedene Varianten, wie man Software entwickelt, auch MIT Prozessen ...

Jemand, der gut in XP und Agilen Methoden ist, kann trotzdem null Erfahrung mit dem klassischen Wasserfallmodell haben und umgekehrt. Es gibt hierbei ja auch nicht DEN goldenen Weg.

Da es bei Euch in dieser Hinsicht wohl auch keine großen Vorgaben gibt, würde ich mir exemplarisch erklären lassen, wie er ein Projekt an sich planen und durchführen würde. Inwieweit sich darin dann Praxiserfahrung wiederspiegelt, ist aber wohl nur noch sehr subjektiv zu beurteilen.

Für konkrete Fragen an ihn müsstet Ihr auch konkret wissen, was Ihr wollt ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Golo,

Wenn jemand alle drei Minuten kompiliert, spricht das nicht dafür, dass er nachdenkt, was er macht, sondern dass er mit Trial and Error vorgeht.

das kann man so pauschal wohl nicht gelten lassen. Zum Beispiel bei Test-Driven-Development ergibt es sich zwangsläufig, dass man hunderte von Malen täglich kompiliert.

herbivore

4.207 Beiträge seit 2003
vor 17 Jahren

Wieso?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Golo Haas,

das gehört zu der Entwicklungsmethode. Siehe z.B. Testgetriebene Entwicklung

herbivore

4.207 Beiträge seit 2003
vor 17 Jahren

Sehe ich nicht ganz so ... wer hindert mich denn daran, erst einmal zwanzig Tests zu schreiben, dann die zugehörigen Methoden und dann nach drei Stunden das erste Mal zu kompilieren in der Hoffnung, dass alles grün ist?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Golo,

dich hintert keiner daran, nur ist das dann nicht mehr das klassische Test-Driven-Development. Beim Test-Driven-Developmenti wird gerade der schnelle Wechsel zwischen codieren und testen zum Prinzip erhoben. Man kann also jemand, der diese Entwicklungsmethode einsetzt, keinen Vorwurf machen, dass er dauernd compliliert. Das gehört dann einfach mit dazu.

herbivore

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Golo Haas
Sehe ich nicht ganz so ... wer hindert mich denn daran, erst einmal zwanzig Tests zu schreiben, dann die zugehörigen Methoden und dann nach drei Stunden das erste Mal zu kompilieren in der Hoffnung, dass alles grün ist?

Ich weiss nicht. Das erinnert mich an Mainframe-Zeiten, wo man angehalten war, am (Papier-) Listing zu debuggen.

Ich finde Herbis Einwand berechtigt, denn "Complieren" alleine kann ja kein Qualitätsmerkmal sein. Compilierung stellt nur sicher, dass der Code syntaktisch korrekt ist. Wenn ich 100 Fehler in einer Stunde machen, dann spielt es keine Rolle, ob ich das einmal nach einer Stunde feststelle, sondern 6 mal alle 10 Minuten. Zudem wird durch Hintergrund-Syntax-Check eine solche "Regel" völlig konterkariert. Im Gegenteil: Wenn ich Code habe, der "durchseucht" mit Syntax-Fehlern ist, dann sind viele Fehlermeldungen schlicht irreführend, weil der Parser die eigentliche Fehlerursache kaum noch ermitteln kann. Immer schön wenig Fehler zu haben heisst auch neue Fehler schnell beseitigen zu können. Daraus würde sich ableiten, so häufig wie möglich zu Compilieren. Eine Philosophie, der Studio ja auch folgt.

Wenn ich Test-Driven arbeite, dann gehört häufiges Laufen (!) der Tests durchaus dazu. Auch hier gilt, dass die Fehlerfindung einfacher ist, wenn ich weiss, dass die Suite eben noch erfolgreich durchlief, weil man Seiteneffekte bei der Benutzung anderer Funktion mit ziemlicher Sicherheit ausschließen kann, der Fehler also vermutlich direkt in der getesteten Methode liegt.

Aus meiner Sicht sagt daher die Zahl der Compilate pro Stunde mehr über den Compiler und die Maschine aus, als über den Entwickler....

Bini Themenstarter:in
195 Beiträge seit 2004
vor 17 Jahren

So - ich darf an den Bewerbungsgesprächen teilnehmen.

Aber mein persönlicher Favorit ist vom Chef schon mal aussortiert worden 🙄

Danke für die Anregungen, ich werde mir eine Checkliste machen.

Umwege erhöhen die Ortskenntnis.

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo zusammen,

ich würde komplett von Softwareerstellungspraktiken abweichen, und den Bewerber mit etwas völlig neuem konfrontieren.

Man lernt am Schnellsten Leute kennen, wenn man sie in Situationen bringt, mit denen nicht gerechnet wurden, und sich dann akribisch anschaut, wie sie sich verhalten.

Z.B.: Gib einem Bewerber einen Zettel und einen Stift. Dann stelle ihn vor folgende Aufgabe (alles Beispielzahlen):

  • Er soll Reisetickets bei der Deutschen Bahn buchen
  • Es gibt eine Reise von München nach Köln, und ein einfaches Ticket soll 30 Euro kosten
  • Es gibt aber die Möglichkeit eine Bahncard 25 oder 50 zu kaufen (100 bzw. 175 Euro)
  • Er soll nun in einer Rechnung darstellen, ab wieviel Fahrten (Hin als auch zurück), sich
    welche Bahncard rechnen würde

Es ist hier eine einfache Rechenaufgabe, und der Bewerber soll laut seine Herangehensweise an dieses Problem demonstrieren. Als Rechenhilfe hat er Zettel und Stift (oder vielleicht fürs Strukturieren?)

Jetzt kann man folgendes Beobachten:

  • Wie "cool" bleibt er unter Streßsituationen, denn damit hat er definitiv nicht gerechnet
  • Wie strukturiert geht er an das Problem heran
  • Wie kann er diese Art und Weise artikulieren
  • Schafft er es schnell solche "Geschäftsprozesse" zu erfassen, und kann er diese auch auf Papier fassen (bzw. verfasst er es schon von sich aus auf Papier?)
  • Denkt er an alles? (Sind Rückfahrten auch mit drinnen?)

Ich denke das lässt auch viel neben seiner Fachkompetenz zum Hervorschein bringen.

Das krasseste was ich real mal in einem Bewerbungsgespräch erlebt hatte, war die Frage nach 10 Gemeinsamkeiten bei einer Kaffeemaschine, einem Menschen und Wasser (hier ging es nicht um die Antworten an sich, sondern wie ausdauernd ich an einem Problem sitzen kann, und vor allem wie kreativ ich diesbezüglich bin). Oder direkt im Anschluss sollte ich eine allgemeingültige Definition von einem Tisch geben. (Dabei wurde immer wieder auf besondere Tische verwiesen, z.B. muss ein Tisch keine 4 Beine haben, ebenso, dass ein Tisch nicht immer auf dem Boden stehen muss, es könnte ja auch mit 4 Seilen an der Decke befestigt sein...)

All das sind solch, ich nenne sie mal "Psychotricks", mit denen man viel über den Bewerber erfahren kann...

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

H
704 Beiträge seit 2003
vor 17 Jahren

_Original von Golo Haas_Jemand, der gut in XP und Agilen Methoden ist, kann trotzdem null Erfahrung mit dem klassischen Wasserfallmodell haben und umgekehrt.

Naja, jemand der bisher nur oder zum Großteil Software nach dem Wasserfallmodell entworfen hat würde ich nicht einstellen. Schließlich ist das Wasserfallmodell sehr unrealistisch und imho ungeeignet für Softwareentwicklung.

[last.fm](http://www.last.fm/user/hauptmanAlpha/)
S
8.746 Beiträge seit 2005
vor 17 Jahren

Ob Wasserfall oder nicht bestimmt ja oft der Kunde...

S
1.047 Beiträge seit 2005
vor 17 Jahren

Schließlich ist das Wasserfallmodell sehr unrealistisch und imho ungeeignet für Softwareentwicklung. Warum ungeeignet und realitätsfremd? Was wäre deiner Meinung nach besser geeignet?

1.373 Beiträge seit 2004
vor 17 Jahren

Ich vermute er meint iterative/inkrementelle Prozesse (bsp. Spiralmodell), in denen die Software "organisch wächst", bereits in frühen Stadien dem Kunden präsentiert wird und u.a. mit Hilfe von Feedback seitens des Kunden stetig verbessert/erweitert wird. In jedem Fall verhindern (oder reduzieren) solche Prozesse böse Überraschungen am Schluss des Entwicklungsprozesses, falls dem Kunden bei der Übergabe auffällt, dass er das Produkt "ganz anders" haben wollte.

Grüße,
Andre

S
285 Beiträge seit 2005
vor 17 Jahren

Original von sheitman

Schließlich ist das Wasserfallmodell sehr unrealistisch und imho ungeeignet für Softwareentwicklung.
Warum ungeeignet und realitätsfremd? Was wäre deiner Meinung nach besser geeignet?

Iterative Softwareentwicklung!!!
Keine Business Applikation wird mehr nach Wasserfallmodell realisiert, da ständig Anforderungen umgewälzt werden.

S
285 Beiträge seit 2005
vor 17 Jahren

Übrigens, finde ich die Frage des Threaderstellers bedeutungslos. Was bedeutet Softwareentwickler? Nur ein reiner Coder oder doch in die Richtung eines Organisationsproggers?

Bis dato bin ich ständig als "Coder" angestellt. Softwareprozesse und die darin verbundenen Aufgaben sind mehr für das Projektmanagement gedacht. Spezifikation, Design, Evaluierung .... brauch ich nicht. Wenn ich "Softwareentwickler" spielen soll, dann bin ich Chef in meinem Reich und es pfuscht mir kein Projektleiter rein, es sei denn, der Kunde will das so.

Sucht aber ein Unternehmen ganz wichtig einen Softwareentwickler, so ist es immer auf einen "Coder" aus. Der Chef will immer Chef bleiben und meistens stur obendrein. Das ist das Hauptproblem und der Grund, warum viele gute Leute auf der Strecke bleiben. Jene, die wirklich eine Ahnung haben. Sie haben natürlich ihren Preis, den keiner bezahlen will.

Was das Thema betrifft:

  1. Kann man den Mann bezahlen, dann bekommt man auch jene, die mit mehr Fähigkeiten außer reines Coden ausgestattet sind. Kein Hochschulabsolvent -> weg, außer es ist ein Genie oder studiert gerade.

2)Dem Mann einfach eine kleine Aufgabe geben, die er ganztägig im Unternehmen löst. Mehr braucht man nicht. Lebenslauf, Zeugnisse ... alles in dieser Richtung sagt heute nichts mehr aus.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Sera,

Übrigens, finde ich die Frage des Threaderstellers bedeutungslos.

du hattest heute Nacht eine leicht destruktive Ader, was? 🙂

Sie ist ja alleine schon deshalb nicht bedeutungslos, weil es einen konkreten Anlass gab, sie zu stellen und die Antworten scheinbar genutzt haben. Es verlangt auch keiner, dass hier nur Fragen gestellt werden, die noch für jemand anderen als den Fragesteller eine Bedeutung haben.

Und das es hier nicht um einen reinen Codierer ging, ergibt sich m.E. ebenfalls direkt aus der Frage.

Kann man den Mann bezahlen ...

Ich glaube das Geschlecht spielt hier keine Rolle. 🙂

herbivore

S
285 Beiträge seit 2005
vor 17 Jahren

Da triffst du voll ins Schwarze 😁

Irgendwie hat das Thema in die letzten 2 Arbeitstage reingepasst. Am Feiertag zu arbeiten ist ja auch irgendwie ein Schmäh. Doch wie bringt man einem Unternehmer in der Softwareentwicklungsbranche "Software Engineering" bei? Daß er das bezahlt hilft mir nicht viel.

H
704 Beiträge seit 2003
vor 17 Jahren

Original von sheitman

Schließlich ist das Wasserfallmodell sehr unrealistisch und imho ungeeignet für Softwareentwicklung.
Warum ungeeignet und realitätsfremd? Was wäre deiner Meinung nach besser geeignet?

Ja, wie schon oben erwähnt meine ich iterative und inkrementelle Entwicklung ...
Das Wasserfallmodell hat mehrere Probleme:
-> Anforderungen müssen sehr früh im Entwicklungsprozess eingefroren werden
-> Anforderungen werden erst viel zu spät wirklich getestet
-> Eine wirkliche Entwciklung folgt niemals dem sequentiellen Fluß des Wasserfallmodells sondern ist iterativ.
-> Es dauert zu lange bis der Kunde ein funktionierendes Produkt in der Hand hält
Sind nur einige Probleme mit dem Wasserfallmodell.

[last.fm](http://www.last.fm/user/hauptmanAlpha/)
S
1.047 Beiträge seit 2005
vor 17 Jahren

iterative und inkrementelle Entwicklung

gibts auch irgendwie ein wenig literatur oder webseiten - die euch spontan dazu einfallen - die sich mit dem thema befassen?

wenn das wasserfallmodell so schlecht ist bzw. ungeeignet, wieso wird es dann noch an hochschulen vorrangig geleehrt?
was jedenfalls bei mri damals so...

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Sera
Keine Business Applikation wird mehr nach Wasserfallmodell realisiert, da ständig Anforderungen umgewälzt werden.

Na, dann mach mal ein Projekt für den öffentlichen Dienst. Da wirst du dich wundern. Mit agiler SW-Entwicklung kommst du da leider an kein Projekt. Muss aber nicht schlecht sein. Man kann als Firma auch in diesem Umfeld gut Geld machen, wenn man es versteht, jeden Änderungswunsch als Zusatzauftrag zu verkaufen. Ich hatte schonmal eibn Projekt, da haben wir den Umsatz damit glatt verdoppelt.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo sheitman,

war jedenfalls bei mir damals so...

Wann ist damals? 🙂

wieso wird es dann noch an hochschulen vorrangig geleehrt?

würde mich wunden, wenn das immer noch so wäre. Ich habe gerade mal in mein Script von SS 86(!) geguckt. Da wurde zwar erstmal (vermutlich aus didaktischen Gründen) das Wasserfallmodell in seiner reinen Form vorgestellt, aber anschließend sofort problematisiert und ein "Schleifenmodell" eingeführt, bei dem man quasi das Wasserfallmodell in Schleifen wieder und wieder durchläuft, um erstmal schnell zu einem Prototyp zu kommen und dann bei jedem Schleifendurchlauf den Prototyp bis zum "fertigen" Programm weiterzuentwickeln.

herbivore

S
1.047 Beiträge seit 2005
vor 17 Jahren

aber anschließend sofort problematisiert und ein "Schleifenmodell" eingeführt, bei dem man quasi das Wasserfallmodell in Schleifen wieder und wieder durchläuft, um erstmal schnell zu einem Prototyp zu kommen und dann bei jedem Schleifendurchlauf den Prototyp bis zum "fertigen" Programm weiterzuentwickeln

ja sicherlich so wurde mir das auch gezeigt... dynamisches wasserfallmodell oder wie sic hdas chimpft

entspricht das dann wieder eher der iterativen und inkrementellen entwicklung?

dann müßte man ja um korrekt zu sein sagen, das klassische wasserfallmodell is unsinn, sonst verwirrt das ja weil es auch angepaßte wasserfallmodelle gibt wo das statische verhalten versucht wird weg zu bekommen^^

p.s. damals war so 2002/2003

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von sheitman
gibts auch irgendwie ein wenig literatur oder webseiten - die euch spontan dazu einfallen - die sich mit dem thema befassen?

Einer der besten Autoren zum Thema ist m.E. Jens Coldewey. Der hatte mal eine längere Kolumne in der ObjektSpektrum zum Thema. Hier kostenlos nachzulesen (extrem unterhaltsam und fabelhaft argumentiert):

http://www.coldewey.com/index.en.html

S
285 Beiträge seit 2005
vor 17 Jahren

Original von svenson

Original von Sera
Keine Business Applikation wird mehr nach Wasserfallmodell realisiert, da ständig Anforderungen umgewälzt werden.

Na, dann mach mal ein Projekt für den öffentlichen Dienst. Da wirst du dich wundern. Mit agiler SW-Entwicklung kommst du da leider an kein Projekt. Muss aber nicht schlecht sein. Man kann als Firma auch in diesem Umfeld gut Geld machen, wenn man es versteht, jeden Änderungswunsch als Zusatzauftrag zu verkaufen. Ich hatte schonmal eibn Projekt, da haben wir den Umsatz damit glatt verdoppelt.

Bei uns läuft ein ÖD Projekt, und dieses ist zu groß, um die Vorteile eines Wasserfall Models nutzen zu können. Auch der ÖD muss sich damit abgeben, sonst wird kein externes Unternehmen sich einem Risiko aussetzen. Auch für agile Softwaremethodik gibt es plausible Vertragsformen. Aber eines stimmt, der ÖD will sich generell absichern. Die haben über ein Jahr für die endgültige Vertragsaufsetzung gebraucht, da iterative Softwareentwicklung ZUERST nicht in Frage kam.

Mann, hat der ÖD einen schlechten Ruf 😁

S
8.746 Beiträge seit 2005
vor 17 Jahren

Naja, man muss den ÖD, bzw. die Beschäftigten verstehen. Dort wirst du nicht belobigt, wenn ein Projekt früher fertig wird oder möglichst optimal den Geschäftsablauf abbildet. Dir wird aber der Kopf abgerissen, wenn das Projekt nicht wie geplant (!) abläuft.

Die gesamte Energie geht beim ÖD dahin sich abzusichern (das Waserfallmodell ist die Absicherungsmethode schlechthin). Niemand will später schuld sein. Agile Prozesse erfordern aber kein Klima der Angst sondern des Vertrauen und vor allem Mut. Es ist wie mit Fussball. Wenn man nur hinten drin steht, kann man keine Tore schiessen.

Unternehmen sind da oft ein wenig klarer, weil für sie Kosten/Nutzen viel wichtiger sind. Der Trick beim ÖD ist einfach die Angst der Entscheidungsträger zu nutzen. Man muss immer "vorne" liegen. Am besten, indem man Beistellungstermine vereinbart, die bei Nicht-Erfüllung zum Verzug führen (der positive Aspekt des Wasserfalls für den Auftragnehmer). So kann man den Kunden schön vor sich hertreiben und hat imemr genug Munition um bei eigener Nicht-Erfüllung (z.B. Terminverzögerung) dealen zu können.

C
156 Beiträge seit 2004
vor 17 Jahren

Hallo Zusammen,

ganz am Anfang der Diskussion wollte Bini eigentlich nur wissen woran man einen guten Softwareentwickler erkennt... 😁

Vieleicht, ist ja ein guter Softwareentwickler jemand, der sich nicht auf eine Methode der Softwareentwicklung einschwört sondern die Vor und Nachteile verschiedener Modelle auf Projektgröße usw. richtig anwenden kann.

M 8)

Mal nur so am Rande

Gruß

Chaossurfer

Bini Themenstarter:in
195 Beiträge seit 2004
vor 17 Jahren

Original von chaossurfer
Vieleicht, ist ja ein guter Softwareentwickler jemand, der sich nicht auf eine Methode der Softwareentwicklung einschwört sondern die Vor und Nachteile verschiedener Modelle auf Projektgröße usw. richtig anwenden kann.

Höhöhö... ja richtig 🙂 Deshalb ist eine meiner gemeinen Fragen im Bewerbungsgespräch auch, welches Datenbanksystem der Herr Kandidat für ein neues Projekt einsetzen würde. Da möchte ich dann am liebsten hören: "das, welches den konkreten Projekt-Anforderungen gerecht wird" oder so was in der Art 8)

Einer der Herren antwortete doch tatsächlich: "SQL". X( Aha. Sehr aussagekräftig. Ironieoff Aber das war auch derjenige, der eine Software aus frei verfügbaren Tools zusammenstückeln würde...

Alles in allem gestaltet es sich sehr zäh. Es ist noch keiner dabeigewesen, der uns vom Hocker gerissen hätte 🙁

Umwege erhöhen die Ortskenntnis.

T
512 Beiträge seit 2006
vor 17 Jahren

Ja die Sorte kenn ich auch.
Erst letztens bei uns in der Mensa. Einer dieser "Linux rulez"-Typen der 3. Art ist fleißig am Schimpfen, dass Ebay zu komerziell geworden ist 😁

e.f.q.

Aus Falschem folgt Beliebiges

H
704 Beiträge seit 2003
vor 17 Jahren

_Original von Bini_Aber das war auch derjenige, der eine Software aus frei verfügbaren Tools zusammenstückeln würde...

Und wo ist das Problem dabei? Imho lassen sich die meisten Anwendungen auch mit freien Tools und Libraries programmieren ... -.-
So eine Einstellung ist sogar eher besser, denn je weniger properitärer Code in einer Anwendung vorhanden ist desto besser.

[last.fm](http://www.last.fm/user/hauptmanAlpha/)
Bini Themenstarter:in
195 Beiträge seit 2004
vor 17 Jahren

Original von hauptmann
Und wo ist das Problem dabei?

Das Problem ist, daß in unserem Verfahren etliche Patente stecken und die zugehörige Software alles andere als frei ist. Und das wurde wenige Minuten vorher auch lang und breit in dem Gespräch erörtert 🙂

Umwege erhöhen die Ortskenntnis.