Wie plant man ein (größeres) Projekt richtig?
-
Supercomputer schrieb:
Um die ganze Überlegung von der reinen Theorie hin zu einem greifbarem Beispiel zu führen, habe ich einmal grob angefangen eine "Gameengine" zu planen.
Ich finde, das ist jetzt wieder etwas anderes als das, wonach du ursprünglich gefragt hast. Da sind die Anforderungen und Voraussetzungen völlig unterschiedlich. Bei einer game engine gehts dir dann um das reine Design der Software. Das Projekt ist sehr überschaubar, die möglichen Anforderungen begrenzt, und du hast weniger Stakeholder.
Bei "großen" und realen Projekten gehts bei weitem nicht nur darum, Klassendiagramme auf der grünen Wiese möglichst sauber zu definieren. Dann kommen die meisten Probleme eher daher, dass man viel mit gewachsenen Strukturen zu tun hat, widersprüchlichen Anforderungen, unklaren Anforderungen, irgendwelchen Features, die schon seit Jahrzehnten drin sind und bei neuen Anforderungen stören, die man aber auch nicht loswerden kann, ohne wichtige Kunden zu verärgern usw...
-
muemmel schrieb:
Eigentlich ja, aber meine Erkenntnis ist, dass die "Entscheider" meist nicht weiter als bis zu einem bunten Bildchen denken können/wollen.
Ja, oft gehts um Bildchen. Man kann aber ab und zu jemanden dazu zwingen, irgendwas beizusteuern. Man fängt vielleicht mit einem Produkt an, und erste Version funktioniert so, wie Entwickler sich das halt gedacht hatten, also vielleicht etwas zu kompliziert für Consultants. Dann gibts vielleicht paar Configs und paar Einstellungen zu viel, die daher kommen, dass man als Entwickler das System genau versteht, und die Consultants das nicht so genau verstehen und nicht alles einstellen wollen. Dann bleibt erstmal der Eindruck, das Produkt ist zu kompliziert oder "funktioniert nicht", und benutzt es nur widerwillig.
Nebenbei gibts aber auch doch produktiven Input, z.B. es ist zu langsam, bestimmte Sachen funktionieren nicht, einige Kunden brauchen noch irgendwas usw... Dann versucht man sich als Entwickler an der nächsten Version und versucht mit den Verantwortlichen zusammen zu klären, wie man das jetzt alles in ein neues Konzept integriert, mit dem alle zufrieden sind.
Dann kommen Produktmanager und Consultants an einen Tisch (oder auch nicht, meist gehts lang hin und her und es gibt viele einzelne Besprechungen) und dann ist das, was am ehesten hängen geblieben ist, das war viel zu kompliziert, hatte keiner verstanden, und jetzt soll eine GUI her und jemand soll einen Vorschlag für die GUI machen. Und die Entwickler versuchen dann lange Zeit zu kommunizieren, die GUI ist egal, soll halt jemand einen Vorschlag machen, das macht 5% der Arbeit aus, aber lasst uns doch bitte die wichtigen Punkte klären. Das funktioniert dann aber eher schlecht, meist diskutiert man doch nur über die GUI und kriegt da das meiste Feedback. Bei den wichtigeren Sachen gibt man das dann irgendwann auf und macht es so, wie man es für richtig hält, bzw. fast noch paar Punkte, bei denen man wirklich eine Entscheidung haben will, so zusammen, dass man irgendwann halt auch eine Antwort bekommt.
-
muemmel schrieb:
Eigentlich ja, aber meine Erkenntnis ist, dass die "Entscheider" meist nicht weiter als bis zu einem bunten Bildchen denken können/wollen. Gerade im öffentlichen Dienst geht das von den Mitarbeitern, Doktoren und Professoren bis hin zu den verantwortlichen Entscheidern in den Ministerien.
In gut geführten Unternehmen ist das zum Teil ein wenig anders. Aber auch nicht immer. Jeder will was Buntes sehen, denn das kann er schön oder nicht schön finden.Vielleicht entsteht dadurch starkes Missverständnis. Wenn man z.B. ein Programm braucht, sagt, was es können muss bzw. man kann sich beschreibend/einigend auf Funktionen einigen - dann sind doch in erster Linie die Funktionen/das Werkzeughafte das wichtigste.
Beispielsweise https://www.tipp10.com/de/
Hier kommt es doch vor allem auf die Grundfunktionen an (Tippen lernen), die Datenbank (Verbesserung oder Lücken erfassen, Statistik) oder die Kosten und vor allem, dass das Programm als solches funktioniert (Ich habe ein Dos-Konsoleprg, das funktioniert ähnlich, aber mindestens genausogut). Eine Luft-Boden-Rakete, die bestimmte Panzer am Boden trifft, ist keine Wunderfunktion, das soll sie auch.Wann kommt bei den Linuxprogrammierern an, dass Rechner mit Internetbrowser auf Fensterbasis beim Verschieben der Fenster nicht abstürzen sollten?
Mein Senf zu diesem (unter der Haube komplexen Thema) ist, dass der Netscape Browser vor über 20 Jahren auf Unixsystemen fehlerfrei mit Maus benutzt werden konnte.
(Wie das heute ist, weiss ich nicht, entweder fehlt ein wichtiger Treiber bei den Unixen, Maus geht nicht, Internet geht nicht (Modul nicht erkannt o.ä.)
oder der Bildschirm bleibt komplett schwarz. Maus-/Internet- Nix am weitesten verbreitet.)
-
[quote="Mechanics"]
muemmel schrieb:
Dann bleibt erstmal der Eindruck, das Produkt ist zu kompliziert oder "funktioniert nicht", und benutzt es nur widerwillig.
...
Dann versucht man sich als Entwickler an der nächsten Version
...
Dann kommen Produktmanager und Consultants an einen Tisch ...... und damit sind wir schon bei Version 3, es ist ein Jahr vergangen und immer noch nichts Kundentaugliches da. Das ist leider der Normalfall, wenn Entwickler sich das Produkt ausdenken, weil kein anderer es tun will. Es muss anders laufen.
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. (Dass man bestimmte Teile, die hundertprozentig kommen werden, schon mal vorbereiten kann, steht auf einem anderen Blatt. Das betrifft aber in erster Linie Dinge unter der Haube).
Und dieses "Senf dazugeben" ist auch keine Einbahnstraße. Da kann und soll rückgefragt und diskutiert werden. Oft fordern Leute ganz spezielle Dinge: "Wir wollen den XY-Button", und beim Nachfragen und Überlegen stellt sich raus, dass XY mit einer Dropdown-Liste noch viel besser ist.
Mit dem, was in dieser Phase genannt und als wichtig eingestuft wird (nicht alles, was ein einzelner Consultant für wichtig hält, ist tatsächlich wichtig - gleiches gilt aber auch für Entwickler), baut die Entwicklung einen Prototyp. Wenn der dann vorgestellt wird, kann keiner mehr nörgeln, dass es "nicht funktioniert" - außer es funktioniert tatsächlich nicht wie besprochen.
-
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
-
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.
-
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.
-
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
