Wie plant man ein (größeres) Projekt richtig?

muemmel

Hi Supercomputer,

Supercomputer schrieb:

Gerade auch der Buchtipp, hier werde ich jedoch erst schauen, ob ich es in der Bibliothek finden kann, bevor ich es mir kaufe. An sich scheint es aber sehr gut zu sein.

Mit ein wenig Suchen findet man es sogar für 4,95 Euro:
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/B0029GQ0ZW/ref=sr_1_2?s=books&ie=UTF8&qid=1518522238&sr=1-2
Da ist die Fahrt in die nächste Bibliothek teurer, und gute Fachbücher sollte mann selbst im Regal stehen haben.

Gruß Mümmel

Tyrdal

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.

Printe

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. Solange die fehlen, gibts auch keine richtige Planung, sondern nur unsichere Planungsversuche, die jederzeit wieder einkassiert werden können.

Wenn das allen (inklusive Geschäftsführung) klar ist, spricht nichts dagegen, dass die Entwicklung "herumspielt" und "Machbarkeitsstudien" veranstaltet, denn mehr ist das nicht. Wenn die Entwicklung aber dafür eins auf den Deckel kriegt ("ihr verplempert Zeit und es kommt nichts dabei heraus"), dann wirds Zeit, mal zurückzufragen, was denn eigentlich erwartet wird, was herauskommen soll.

Es kann nämlich nicht sein, dass die Entwicklung die Arbeit des Produktmanagements / Vertriebs / Consultings tut und sich ausdenkt, welche Produkte mit welchen Eigenschaften in Zukunft gebraucht werden.

Tyrdal

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 umsetzen

und ich muss sagen, dass das angenehmer ist, als einfach so "loszuproggen"

Tyrdal

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.

Tyrdal

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.

Tobiking2

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.

Printe

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.

KlausB

Hallo

das ist der Unterschied zwischen Theorie und Praxis

Tyrdal

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?

hustbaer

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 mies

Bzw. 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.

Tyrdal

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.

Tyrdal

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 ...

muemmel

Hi KlausB,

KlausB schrieb:

Hallo
das ist der Unterschied zwischen Theorie und Praxis

Das 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

Tyrdal

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.