Wie plant man ein (größeres) Projekt richtig?
-
also meine bisherige erfahrung sagt mir einerseits, dass ich das genau so planen sollte, wie oben beschrieben, und andererseits, dass es besser ist, einfach drauf los zu proggen, dann alles löschen und das ganze nochmal von vorne ohne die ganzen fehler machen sollte, weil mir irgendwie die praxis fehlt, um das alles von vorne durchzuplanen.
andererseits glaube ich eben, dass ich schon sehr genau überlegen sollte, was das programm eigentlich können soll. wenn ich ein auto bauen will, schraube ich ja auch nicht einfach drauf los, sondern überlege mir die anforderungen (welche leistung, welcher treibstoff, front- oder heckantrieb, ...), plane, rechne und dann wird irgendwann geschraubt.
also wenn dich die methoden ansich interessieren, such mach bei amazon oder in der örtlichen uni-bibliothek nach "software engineering".
-
Wade1234 schrieb:
also meine bisherige erfahrung sagt mir einerseits, dass ich das genau so planen sollte, wie oben beschrieben, und andererseits, dass es besser ist, einfach drauf los zu proggen, dann alles löschen und das ganze nochmal von vorne ...
Eine klassische Top-down-Planung (also von der Gesamtidee zum Detail) kannst du nur machen, wenn du das Projekt in Gänze überblickst, und wer tut das schon? Dazu müsstest du etwas sehr ähnliches schon mal gemacht haben.
Wenn das nicht der Fall ist, sollte man stattdessen eine Bottom-Up-Planung in Betracht ziehen, also erst die Teile entwerfen und brauchbare Prototypen (*) entwickeln, und dann überlegen, wie man alles zu einem Ganzen zusammensetzt.
Wahrscheinlich wird man auch hier mehrere Iterationen brauchen, bis sich alles richtig anfühlt, aber die richtig teuren Planungsfehler (auf halbem Weg erkennen, dass der Gesamtplan nichts taugt, oder für die letzten 10 Prozent nochmal soviel Zeit verbraten wie für die ersten 90) kann man hoffentlich vermeiden, indem man das Haus erst plant, nachdem man funktionstüchtige Bausteine hat.
(*) "brauchbare Prototypen" heißt: ausreichender Funktionsumfang, um was damit anzufangen, aber noch nicht unbedingt in jeder Situation kugelsicher.
andererseits glaube ich eben, dass ich schon sehr genau überlegen sollte, was das programm eigentlich können soll.
Was das Programm können sollte (und was nicht), sollte man sich vorher überlegen, das stimmt. Man muss das Was aber trennen vom Wie.
-
Wade1234 schrieb:
wenn ich ein auto bauen will, schraube ich ja auch nicht einfach drauf los, sondern überlege mir die anforderungen (welche leistung, welcher treibstoff, front- oder heckantrieb, ...), plane, rechne und dann wird irgendwann geschraubt.
Klar, das macht man wenn man schon mal ein Auto gebaut hat, bzw. wenn man schon weiss wie Autos üblicherweise aufgebaut sind, weil andere schon viele Autos gebaut haben.
-
Hi,
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Bei meiner ersten Abschlussarbeit hatte ich ein Programm zu erstellen, das auf einer nackten DOS-Oberfläche aufsetzen sollte aber mit einzelnen Masken, Auswahlfenstern, Popups, Linien, Rahmen, kompfortablen Zeileneditoren (getrennt nach Zeichenketten Integer und Float) und vor-und zurückspringen innerhalb der einzelnen Elemente bestehen sollte.
Also ist das Programm sowohl von unten nach oben als auch von oben nach unten gwachsen. Von unten erst mal die grundsätzlichen Basiselemente definieren und die darauf aufbauenden. Also z.B. Linie und Viereck aus vier Linien.
Gleichzeitig von oben her das Programm in die einzelnen Grundelemente zerlegen, z.B. Main mit Auswahl der einzelnen Grundfunktionen, und die dann schrittweise so weit untergliedern, bis sich "oben" und "unten" treffen. Danach ggf. noch aus jeder Ebene 1-2 Elemente codieren um einen Überblick über den Zeitbedarf zu bekommen und für alle Elemente aufsummieren. Und dann nicht vergessen einen Puffer für unvorhergesehenes mit vorzusehen, je nach Erfahrung 10 - 100%.
Gruß Mümmel
PS: es gab da mal von Dr. Günter Rothardt mal das Buch Praxis der Softwareentwicklung, das sich genau mit den Themen sehr ausführlich beschäftigt hat. Ist aber von 1987 und daher wohl kaum noch zu bekommen. Aber vielleicht haben es noch Bibliotheken zum Ausleihen.
2.PS: Grad gefunden bei Amazon ab 10 Euro: Na wenn das mal kein Schnäppchen ist.
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/3778514393
-
Ich finde auch die Kombination aus Top-Down und Bottom-Up am besten.
Macht man nur Top-Down, so werden die technischen Hürden erst viel zu spät entdeckt und umgekehrt bei Bottom-Up fehlt einem das Grundverständnis für die Gesamtarchitektur.
Gerade für einen Prototypen sollte man einen Durchstich entwickeln, welcher schon auf der Architektur aufbaut und schon einige technische Details enthält.Aber ein Projekt zu planen ist mehr als nur Code zu schreiben, dazu gehören alle Unterpunkte aus Software Engineering (und weitere nicht-technische, wie Infrastruktur, Teamkommunikation, etc.).
-
muemmel schrieb:
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Die Bildschirmmaske ist ja auch nicht das "nackte Gerippe", sondern im Gegenteil die Haut, die am Ende drübergezogen wird. Projektleiter sollten das nicht verwechseln, und sie sollten die Entscheider nicht in diesem Glauben lassen.
Entscheider, die immer nur nicken und nicht rückfragen, zeigen damit, dass sie das Projekt nicht verstanden haben. Erfahrene Projektleiter wissen das und verlangen die Rückmeldung. Wenn die Entscheider nicht nur nicken, sondern unterschreiben sollen (mit ihrem Namen auf einem Stück Papier), dann werden sie normalerweise wach.
-
Ich bedanke mich für die Zahlreichen sehr hilfreichen Antworten.
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.
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.
Dabei ist dann vorläufig diese Mindmap entstanden.
https://mind42.com/mindmap/28ff26b8-6cb6-47e4-a0be-e8cf224601feWenn ich das Grundkonzept, welches hier erwähnt wurde nun hierauf beziehe, dann war das eine Top -> Down Planung.
Als nächstes würde dann eine Bottom -> UP Ergänzung folgen.
Sobald diese dann abgeschlossen ist, würden einzelne Module konkret entwickelt und das gesamt Konstrukt bei Bedarf erweitert werden.Habe ich das so richtig verstanden oder ist mir hier ein Fehler unterlaufen?
Grüße
TheSupercmputer
-
muemmel schrieb:
Hi,
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Es gibt ein schönes Sprichwort, das heißt: "Die Frage war nach dem Himmel, die Antwort war ein Seil".
Ich weiß nur, dass es gewisses bewährtes Grundrüstzeugs gibt.
Z.B. ein Protokollheft mit Inhaltsaddressierung oder das (Stützradmäßige) Entlanghangeln an einem Modell, bzw. an einem Arbeitsplan nach Modell x, y, z,..
Das kann man genauso später bei z.B. Evaluationen so handhaben.Statt eines (bewährten) theoretischen Modells kann man in Software ein anderes Programm zum Vorbild nehmen. Tabellenkalkulationen oder Betriebssysteme haben auch mal klein angefangen.
Bei grundlegenden Entwürfen/Plänen kann ich nicht ohne Papier- und Bleistift-Schmierereien.
Bei Programmen kommt außerdem noch die lästige Frage auf, was ist der aktuellste (Haupt/Offiziell-)Code, bzw. wo war ich zuletzt?
Die Lösung ist auch hier wieder Transparenz - die sich auch im disziplinierten oder eben ritualisierten Handeln ausdrücken kann.Gute Planhilfen nach wie vor sind Plakate + A5-Zettel. Die Plakate lassen sich auch gut zusammenkleben, falls man Wandbreite/King-Size-Monitoring braucht.
-
Hi Printe,
Printe schrieb:
Die Bildschirmmaske ist ja auch nicht das "nackte Gerippe", sondern im Gegenteil die Haut, die am Ende drübergezogen wird. Projektleiter sollten das nicht verwechseln, und sie sollten die Entscheider nicht in diesem Glauben lassen.
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. Mindestens die Hälfte aller Modulbeschreibungen ( na ja Bildschirmoberflächen) wurden mir als mit Excel/Powerpoint... gezeichnete Bildchen übergeben. Teilweise dann noch in einem Breitwand-Format, das gar nicht in die vorgesehene Bildschirmauflösung passt.
Ich kann mich noch an ein großes Projekt an der UNI erinnern, dass dan regelmäßig dem Professor vorgeführt wurde, um von ihm weitergehenden Input zu bekommen. Aber das einzige was da immer kam war der Hinweis, das an dieser oder jener Stelle noch ein Rechtschreibfehler war. Nur, dazu hätte ich auch die Sekretärin befragen können. Von den erwarteten gehobenen fachlichen Hinweisen kam da hingegen in den ganzen Jahren nicht ein einziges Mal was.
Man kann dem, der die Sache zu erledigen hat nur raten, selber in die Materie einarbeiten und die Chefs in dem Glauben lassen sie hätten dabei auch was zu melden.
Oder wie es mit mal jemand empfohlen hat, lassen sie sich die Zuarbeit von einem Lehrling des 2. oder 3. Lehrjahres machen, der blickt schon genug durch aber kommt noch auf den Punkt. Peinlich peinlich, aber ist leider so.Gruß Mümmel
-
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.
