Wie plant man ein (größeres) Projekt richtig?
-
Printe schrieb:
Tyrdal schrieb:
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
Der Threadtitel ist "Wie plant man ein größeres Projekt richtig?"
Und am Anfang einer richtigen Planung stehen nun mal klare Anforderungen.
Hab ich erst ein einziges mal erlebt. Und da lags daran, daß es ein Folgeprojekt war, also Erfahrungen aus dem ersten Anlauf verwertet werden konnten.
Üblich sind große weiße Flächen in der Anforderungslandschaft.
-
Tyrdal schrieb:
Printe schrieb:
Sobald die Entscheidung fällt, dass das Produkt entwickelt werden soll, müssen alle (Produktmanager, Consultants, Vertrieb) ihren Senf dazugeben, und zwar zeitnah. Das müssen die, das gehört zu ihrem Job, da können sie sich nicht einfach raustun. Solange das nicht geschehen ist, startet die Entwicklung nicht, weil die Anforderungen noch unklar sind, so einfach ist das.
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
Die zwei Enden der aktuellen Presswürste:
Vorne: Projekt mir sehr guter Idee wird gegen die Wand gefahren, die Entwickler übernehmen sich und Insolvenz und Anwälte winken lächelnd.
Hinten: "Von Nichts kommt Nichts" hallt es durch die Gänge der leeren Hallen (Alles da, fast wie im Schlaraffenland: aber es muss irgendwas verkauft werden)
Selbstoszillation mit Marketingsprüchen/Symbolbegriffen ist das nicht, die Situation erinnert zu sehr an das Mädchen mit den Schwefelhölzern.
-
Tyrdal schrieb:
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
also windows 1.0 sah ja auch ein wenig anders aus, als windows 10.
irgendwo muss die planungsphase doch mal zu ende sein und dann sollte man zusätzliche ideen auf die nächste version verschieben. da muss man sich dann halt mal den marketingheinis gegenüber durchsetzen.ich mache das jetzt jedenfalls so:
1. anforderungen festlegen
2. das hauptproblem von oben nach unten in viele kleine einzelprobleme zerlegen
3. überlegen wie die abläufe von oben nach unten bzw. von links nach rechts umgesetzt werden können
4. dann erst in die programmiersprache umsetzenund ich muss sagen, dass das angenehmer ist, als einfach so "loszuproggen"
-
Wade1234 schrieb:
Tyrdal schrieb:
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
also windows 1.0 sah ja auch ein wenig anders aus, als windows 10.
irgendwo muss die planungsphase doch mal zu ende sein und dann sollte man zusätzliche ideen auf die nächste version verschieben. da muss man sich dann halt mal den marketingheinis gegenüber durchsetzen.Arbeitet ihr denn in dem Bereich? Klar grobe Gegebenheiten sind von vornherein klar, aber die Details ändern sich ständig. Das hat noch nicht mal unbedingt was mit Marketingheinis zu tun, 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, zumindest in meiner Arbeitswelt. Vielleicht liegts auch daran, daß bei uns die Projekte oft 2 Jahre oder mehr laufen bis zum ersten Release.
-
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.
