Wie plant man ein (größeres) Projekt richtig?
-
also ich arbeite gerade an meiner bachelorarbeit und habe mir eigentlich vorgenommen, die nicht nur mit 4,0 zu bestehen, sondern eher so mit 1,0.
jedenfalls habe ich diese aufgabe, von einigen unbedeutenden erweiterungen einmal abgesehen, schon einmal gemacht, dabei jedoch weitestgehend darauf verzichtet, vorher alles durchzuplanen. das resultat war ein riesengroßes programm praktisch ohne fehlerbehandlung bzw. fehlermeldungen, weil ich für jede noch so kleine aufgabe eine eigene funktion geschrieben bzw. direkt "ge-inlined" habe, da ja gar nicht absehbar war, ob und wo ähnliche programmteile auftreten, die dann von der gleichen funktion abgearbeitet werden können, aber vielleicht noch einen parameter mehr brauchen.
jetzt habe ich mir dann erst einmal überlegt, welche funktionen ich haben möchte und wann und wie die aufgerufen werden sollen, also z.b. "datei hochladen", "datei herunterladen", "datei löschen" und welche fehler dabei auftreten könnten, und ich muss mir noch gar keine gedanken darüber machen, wie diese fehler festgestellt werden, oder wie diese "hauptfunktionen" intern arbeiten sollen und so wie ich die sache sehe, kann ich das dann nachher viel einfacher in programmcode umwandeln, weil die anforderungen und schnittstellen ja klar sind.
-
Wade1234 schrieb:
also ich arbeite gerade an meiner bachelorarbeit und habe mir eigentlich vorgenommen, die nicht nur mit 4,0 zu bestehen, sondern eher so mit 1,0.
Ach so, vielleicht verstehst du mich wenn du in der Realität (aka freie Wirtschaft) ankommst
So Kleinkram von dem du schreibts meine ich gar nicht.
-
Unklare Anforderungen und Projektplanung müssen sich ja nicht ausschließen.
Ich würde unklare Anforderungen als Teil der Risikoanalyse sehen, und damit in die Projektplanung mit einbeziehen. Zum Einen kann dann mehr Zeit eingeplant werden, zum Anderen können die Entwickler den Code an den entsprechenden Stellen flexibler gestalten. Generell sollte der Code ja gut anpassbar gehalten werden.
Planer und Entwickler müssen sich da von beiden Seiten entgegenkommen um ein gutes Ergebnis abzuliefern.
-
Tyrdal schrieb:
... sondern damit daß der Kunde erst während der Entwicklung (zb durch Sprint Reviews bei Scrum) so merkt was er will/braucht. Das unterscheidet sich nunmal oft von dem was der am Anfang anfordert ...
Das ist aber nicht der Sinn von Scrum, dass der Kunde sich erst im Lauf der Sprint-Reviews darüber klar wird, was er eigentlich haben will.
-
Hallo
das ist der Unterschied zwischen Theorie und Praxis
-
Printe schrieb:
Tyrdal schrieb:
... sondern damit daß der Kunde erst während der Entwicklung (zb durch Sprint Reviews bei Scrum) so merkt was er will/braucht. Das unterscheidet sich nunmal oft von dem was der am Anfang anfordert ...
Das ist aber nicht der Sinn von Scrum, dass der Kunde sich erst im Lauf der Sprint-Reviews darüber klar wird, was er eigentlich haben will.
Doch genau das ist der Sinn. Man zeigt dem Kunden früh genug was er bekommt, um dann rechtzeitig gegensteuern zu können.
-
aber wenn ich so programmiere und möglicherweise ständig alles ändere, dann gibt das doch übelstes geflicke ab, oder sehe ich das falsch?
-
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.
