Wie plant man ein (größeres) Projekt richtig?
-
Wenn man beim "ständig alles Ändern" passend refactored, dann wird das gar kein übles Geflicke.
Wenn man sich natürlich zu sehr vom "wir müssen auch mal fertig werden" Druck vom Refactoring abhalten lässt, dann wird das Ergebnis vermutlich ziemlich miesBzw. auch von anderen Faktoren. Gibt Leute die nicht refactoren wollen weil sie das Gefühl haben sie würden damit alles wegwerfen was sie zuvor mühsam entwickelt haben. Und es gibt auch Leute die einfach nicht sehr gut darin sind. Wobei das Übungssache ist. Und je öfter man es gemacht hat, desto geringer wird normalerweise auch der innere Widerwille den man dabei empfindet.
-
Einmal das was hustbär sagte, aber mit der Zeit bekommt man auch Erfahrung dafür wo man die Software von vornherein flexibel auslegt um Änderungen einfach auffangen zu können. Kann man natürlich auch übertreiben, dann hat man overengineering. Außerdem muss natürlich auch der Vertrieb mithelfen, zB indem Änderungen auch mal kostenpflichtig werden. Da fangen die Kunden dann nämlich wirklich an zu überlegen was sie brauchen
-
bezahlen die kunden das denn?
also ich habe da mal was von fehlerkostenfaktoren oder so gelernt, wonach fehler, die bei der planung auf dem "reißbrett" auffallen, 10€ kosten, fehler die bei der planung bzw. umsetzung des prototyps auffallen, dann schon 1000€, und fehler, die bei der serienproduktion auffallen, 1 Mio €, und dass es deshalb eigentlich sinn macht, frühzeitig alles abzuklären.
jedenfalls so ungefähr, und ob jetzt fehler oder unklare anforderung: da entstehen doch (unnötige) kosten.
-
Wade1234 schrieb:
bezahlen die kunden das denn?
Klar, da muss ein Puffer bei der Angebotserstellung/Preiskalkulation mit eingerechnet werden. Ansonsten muss der Vertrieb das, wie geschrieben, als Änderung verkaufen können.
Und klar, in einer idealen Welt sind die Anforderungen klar und das Wasserfallmodell funktioniert. Theoretisch sind Theorie und Praxis auch identisch ...
-
Hi KlausB,
KlausB schrieb:
Hallo
das ist der Unterschied zwischen Theorie und PraxisDas ist wie in der DDR, Theorie war Marx und Praxis war Murks.
Ich vermute mal, dass ein großer Teil aller Projekte als Rucksackprojekte enden. Es muss ja immer nur die eine kleine Sache eingepflegt werden und die andere kleine Sache jetzt noch schnell geändert werden.
Zu einem richtigen Reenginiering/Refactoring ist nie Zeit, das können wir doch jetzt nicht alles wegschmeißen und noch mal neu stricken, das funktioniert doch schon fast. Was irgendwann mal als nettes kleines schlankes Programm angefangen hat endet in vielen Fällen zwangsläufig als überfetteter träger Dinosaurier, der nur mit täglichen Eigenblutspenden noch am Leben gehalten werden kann.Am besten, mann lässt sich nicht zusehr in die Karten gucken und entscheidet selber was nötig ist und was zu machen ist.
Gruß Mümmel
-
Nicht nur die Zeit fehlt fürs Refactoring, nein es steht auch immer die Frage im Raum wer das denn jetzt bezahlen soll. Aufgabe ist also das Refactoring irgendwie in einen Kundenauftrag zu quetschen damit der zahlt.
-
Ich finde das is irgendwie wie wenn man sagt es is alles so schlimm weil der Kunde will die Zeit für's Wegräumen vom Werkzeug nie zahlen. Die Zeit muss man halt einfach als ganz normale Arbeitszeit/Projektzeit einplanen.
Wirklich blöd wird's natürlich bei grösseren Refactorings die wegen einer grösseren Änderung welche der Kunde wünscht nötig wären.
-
Tyrdal schrieb:
Nicht nur die Zeit fehlt fürs Refactoring, nein es steht auch immer die Frage im Raum wer das denn jetzt bezahlen soll. Aufgabe ist also das Refactoring irgendwie in einen Kundenauftrag zu quetschen damit der zahlt.
Genau deswegen vertrat ich weiter vorn die Meinung, dass es eine schlechte Idee ist, mit alle Mann loszuentwickeln und Zeit zu verbrennen, solange der Auftraggeber erkennbar noch nicht genau weiß, was er haben will: Es ist absehbar, dass es zu aufwändigen Refactorings kommen wird inklusive Diskussionen darum, wer das bezahlen soll.
Aber nein, man musste mich belehren, dass genau das der Zweck von Scrum sei: Dass das Lastenheft erst in den Sprint-Reviews seine endgültige Form annimmt ...
hustbaer schrieb:
Wirklich blöd wird's natürlich bei grösseren Refactorings die wegen einer grösseren Änderung welche der Kunde wünscht nötig wären.
Eben. Deshalb lässt man, bevor man viel Zeit investiert, das Pflichtenheft vom Kunden unterschreiben, und das ist dann die Basis für die Entwicklung und der Punkt, an dem man mit Scrum oder ähnlichen Techniken loslegen kann. Will der Kunde nach diesem Zeitpunkt noch Änderungen, kann der Lieferant sich überlegen, ob er das per Goodwill im Vorbeigehen erledigen kann (mit sowas sammelt man Punkte) oder ob das so groß ist, dass dafür nachverhandelt und nachgezahlt werden muss (hierfür ist es gut, wenn man schon ein paar Goodwill-Punkte gesammelt hat).
-
Printe schrieb:
Eben. Deshalb lässt man, bevor man viel Zeit investiert, das Pflichtenheft vom Kunden unterschreiben, und das ist dann die Basis für die Entwicklung und der Punkt, an dem man mit Scrum oder ähnlichen Techniken loslegen kann.
Ja, die Situation ist ja eher noch einfach zu handhaben. Ich dachte eher an bestehende Programme wo der Kunde ne Änderung als eigenes Projekt haben möchte. Wenn man die dann mit dem Preis anbietet wo ne Woche Refactoring eingerechnet ist, dann bekommt den Auftrag halt vielleicht ne andere Firma deren Preis mit "wir frickeln das irgendwie dazu" kalkuliert ist.
-
Printe schrieb:
Tyrdal schrieb:
Nicht nur die Zeit fehlt fürs Refactoring, nein es steht auch immer die Frage im Raum wer das denn jetzt bezahlen soll. Aufgabe ist also das Refactoring irgendwie in einen Kundenauftrag zu quetschen damit der zahlt.
Genau deswegen vertrat ich weiter vorn die Meinung, dass es eine schlechte Idee ist, mit alle Mann loszuentwickeln und Zeit zu verbrennen, solange der Auftraggeber erkennbar noch nicht genau weiß, was er haben will: Es ist absehbar, dass es zu aufwändigen Refactorings kommen wird inklusive Diskussionen darum, wer das bezahlen soll.
Öhm, es gibt Programme die haben mehr als eine Version. Ich entwickle gerade an einer über 15jährigen Software mit. Glaubst du ernsthaft man hat damals alle heutigen Probleme mit berücksichtigen können?
Außerdem habe ich nie behauptet, daß Planung Unsinn sein. Die Grundlegende Architektur wird nur selten über Bord geworfen. Fakt ist aber, daß das Wasserfallmodell in der Praxis versagt. Deshalb wurden ja neue Methoden entwickelt.
-
Tyrdal schrieb:
Öhm, es gibt Programme die haben mehr als eine Version. Ich entwickle gerade an einer über 15jährigen Software mit. Glaubst du ernsthaft man hat damals alle heutigen Probleme mit berücksichtigen können?
Öhm, mir scheint, wir reden hier von ziemlich unterschiedlichen Dingen.
-
Hi,
die meisten Softwareersteller wollen lieber gut und sauber arbeiten. Aber meist gibt es zweie die das von Anfang an von Grund auf verhindern bzw. zu vehindern suchen. Der eine heist Chef, der andere Kunde.
Wenn statt den beiden nur einer subversiv tätig ist ist man ein Glückspilz und sollte sich jeden Tag über sein Glück freuen.Gruß Mümmel
-
hustbaer schrieb:
Wenn man die dann mit dem Preis anbietet wo ne Woche Refactoring eingerechnet ist, dann bekommt den Auftrag halt vielleicht ne andere Firma deren Preis mit "wir frickeln das irgendwie dazu" kalkuliert ist.
mein damaliger ausbildungsmeister hat mal eine witzige geschichte erzählt:
da gab es jemanden, der sich auf die planung von computernetzwerken spezialisiert hat. wenn dann irgendwie kundschaft zu ihm kam und wissen wollte, was er verlangt, hat er bisschen was in den taschenrechner eingetippt und dann "kostet 50000€" gesagt. wenn sich die kunden dann beschwert haben, dass fa. xy das ja für 35000€ machen würde, hat er dem kunden nur gesagt, dass er ja fa. xy beauftragen könne, wenn er meint. wenns dann nicht funktioniert, würde seine lösung dann aber 75000€ kosten, der kunde müsse dann also 110000€ für etwas bezahlen, das sonst 50000€ gekostet hätte.
soll sehr erfolgreich gewesen sein, diese strategie.
-
hustbaer schrieb:
Ja, die Situation ist ja eher noch einfach zu handhaben. Ich dachte eher an bestehende Programme wo der Kunde ne Änderung als eigenes Projekt haben möchte. Wenn man die dann mit dem Preis anbietet wo ne Woche Refactoring eingerechnet ist, dann bekommt den Auftrag halt vielleicht ne andere Firma deren Preis mit "wir frickeln das irgendwie dazu" kalkuliert ist.
Änderung an bestehender Software? Gibts denn das, dass sowas offen ausgeschrieben wird? Wieso macht das nicht der, der die Software ursprünglich geschrieben hat? Der müsste doch erster und quasi-einziger Ansprechpartner dafür sein.
Aber gesetzt den Fall, es wäre so: Natürlich kann man hier keine großen Umstülpungen einpreisen. Wenn der Auftraggeber dafür offen Angebote einholt, heißt das, dass er es prinzipiell jedem zutraut, und dann kann das keine große Sache sein, sondern eher nur eine kleine Anpassung. Und dann wird auch genau das kalkuliert, wenn man den Auftrag haben will, und eben kein großes Refactoring.
Refactoring würde man erst dann vorschlagen, wenn man schon einen Fuß in der Tür hat.
Kann natürlich auch sein, dass man einer renovierungsbedürftigen Software damit endgültig den Todesstoß versetzt und dass demnächst eine komplette Neuentwicklung ausgeschrieben wird.
-
Printe schrieb:
Änderung an bestehender Software? Gibts denn das, dass sowas offen ausgeschrieben wird? Wieso macht das nicht der, der die Software ursprünglich geschrieben hat? Der müsste doch erster und quasi-einziger Ansprechpartner dafür sein.
Ich würde fast Behaupten, dass die meisten Aufträge Änderungen bzw. Anpassungen an existierender Software sind.
Auch wenn man die Software ursprünglich selbst geschrieben hat, konnte man zu dem Zeitpunkt die neueren Änderungen nicht unbedingt absehen.
Aber auch, dass man an andere Leute Code weiterarbeiten muss ist keine Seltenheit. Selbst, wenn's in der gleichen Firma ist. Leute wechseln, sind in anderen Projekten etc.
Oder aber der ursprüngliche Dienstleister wird zu teuer, oder existiert evt. nicht mehr, oder oder oder.BTT: Wie ein Projekt genau geplant / gemanaged wird (Wasserfall, V-Modell, Scrum oder was auch immer) hängt vom Team und Projekt ab. Kann alles gut funktionieren oder auch schrecklich vor die Wand fahren.
Dem TE ging es, wenn ich das richtig gesehen habe, um eine Bachelor Arbeit. Da würde ich eventuell das V- Modell empfehlen. Da hat man zum einen jeden Teil der Softwareentwicklung mit abgedeckt und zum anderen ist in der Regel der Funktionsumfang am Anfang halbwegs genau abgesteckt. Außerdem ist man meistens ein 1 Mann Team in seinem (Teil-) Projekt.
-
Printe schrieb:
Änderung an bestehender Software? Gibts denn das, dass sowas offen ausgeschrieben wird?
Ausschreiben tun Behörden und Firmen die ausschreiben müssen. Bzw. vielleicht noch bei extrem grossen Projekten. Ansonsten viel zu aufwendig. Man holt sich einfach ein paar Angebote.
Printe schrieb:
Wieso macht das nicht der, der die Software ursprünglich geschrieben hat? Der müsste doch erster und quasi-einziger Ansprechpartner dafür sein.
Beide Varianten kommen in der Realität oft vor. Und speziell wenn der, der es ursprünglich geschrieben hat, auf einmal nen recht hohen Preis verlangt, kommen viele Firmen seltsamerweise dann auf die Idee auch mal ne andere Softwarebude zu fragen.
Printe schrieb:
Wenn der Auftraggeber dafür offen Angebote einholt, heißt das, dass er es prinzipiell jedem zutraut, und dann kann das keine große Sache sein, sondern eher nur eine kleine Anpassung.
Lol. Ja, klar, weil der Kunde ja immer voll viel Ahnung von seiner Software und Softwareentwicklung im Allgemeinen hat. Und natürlich auch immer voll vernünftig drauf ist und garantiert niemals von warmen Eislutschern träumt.
Ne, sorry. Wenn der Kunde selbst keine Softwareentwicklung macht, dann hat er keinen Plan.Aber selbst wenn der Kunde ein paar Mitarbeiter hat die die Sache korrekt einschätzen, gibt es oft Chefs/Manager die es halt "besser wissen".
Grundsätzlich kannst du davon ausgehen dass der Kunde immer ein (Fach-)Idiot ist. Ist etwas hart formuliert und gibt manchmal Ausnahmen, aber als erste Annäherung ist es korrekt. Und wenn sein Fach dann nicht Softwareentwicklung ist...
Printe schrieb:
Refactoring würde man erst dann vorschlagen, wenn man schon einen Fuß in der Tür hat.
Kann natürlich auch sein, dass man einer renovierungsbedürftigen Software damit endgültig den Todesstoß versetzt und dass demnächst eine komplette Neuentwicklung ausgeschrieben wird.
Würde man erst dann, soso. Dummerweise kommt der Kunde aber selbst dann oft auf die Idee die nächste Änderung doch lieber wieder bei nochmal wem anderem machen zu lassen. *Weil der Preis vom ersten Projekt war ja noch OK, funktioniert hat dann aber leider doch nicht alles so 1A wie man es sich gewünscht hätte, und jetzt der Vorschlag da Änderungen zu haben die nix bringen und bloss viel kosten ... also verarschen lassen wir uns auch nicht.
*
