Hallo, wie handhabt Ihr die Planung und Umsetzung bei etwas größeren Software-Projekten? Also jetzt keine Riesen-Projekte mit Programmier-Teams, sondern eher eine maßgeschneiderte Software-Lösung eines Einzelunternehmers für die Kernprozesse eines kleineren Unternehmens mit Schnittstellen zu anderen Anbietern (SOAP, etc.) und mit einer zum jetzigen Zeitpunkt vorsichtig geschätzten Projekt-Dauer von ca. 9 - 12 Monaten. Während meiner beruflichen Entwicklung habe ich früher mal einen Blick in die Anforderungsunterlagen eines relativ dicken Software-Projekts werfen dürfen. Da waren hunderte von Seiten voll mit stets ähnlich aufgebauten Absätzen, die jede Funktion, jeden Button, jeden Text, usw., furztrocken beschrieben haben. Eigentlich habe ich mich bei meinen bisherigen Kundengesprächen immer auf die Funktionalität der Software beschränkt und versucht, diese gemeinsam mit dem Kunden möglichst präzise und dennoch möglichst knapp zu beschreiben. Das aktuelle Projekt wird aber etwas umfangreicher werden und die Entwicklung soll auch bei Abwesenheit des Chefs durch Gespräche mit den Mitarbeitern weiter verfolgt werden, daher stellt sich mir die Frage, in welcher Form man die vielen noch folgenden Informationen abstrakt und somit kundengerecht visualisieren und dennoch jederzeit den gewünschten Komplexitätsgrad wieder hervorzaubern kann, damit die vereinbarten Details nicht auf der Strecke bleiben und man dennoch frühzeitig Inkonsistenzen erkennt? Benutzt Ihr dafür Software, um die Anforderungen besser sammeln, formulieren und darstellen zu können? Ich bin bei meiner Recherche natürlich auf diverse Mind Map Programme gestoßen - was haltet Ihr davon? Also vom Programmiertechnischen her bin ich der Aufgabe definitiv gewachsen, aber ich werde da wohl viele Monate dran entwicklen und lange Besprechungen mit unterschiedlichen Mitarbeitern haben. Missverständnisse bezüglich des Umfangs oder der Funktion sollten daher möglichst vermieden werden. Eventuell hat hier ja jemand Erfahrung mit Software-Entwicklung in dem von mir beschriebenen Umfang und kann mir ein paar nützliche Tipps geben... Grüße...Jay
Agile Entwicklung :) Jedes Monat zu Beginn die Ziele für dieses Monat besprechen, dann entwickeln und am Ende des Monats dem Kunden einen lauffähigen Zwischenstand zum Spielen (oder sogar zum Benutzen) geben. Meiner Erfahrung nach kann man spezifizieren was man will - erst wenn der Kunde etwas sieht und damit spielen kann weiß er, was er eigentlich will und braucht. Schon im Vorhinein alles zu spezifizieren hat bei mir nie funktioniert. Außer man ist auf massig Geld durch Change Requests scharf, das soll es ja auch öfter einmal geben.
Mein Tipp, erst mal den Kern des Problems finden, ihn dann lösen und dann den Rest dran hängen. Man darf auch keine Angst davor haben, auch mal Teile neu zu machen. Dein großer Feind ist die Komplexität, die gilt es zu vermeiden.
A. B. schrieb: > wie handhabt Ihr die Planung und Umsetzung bei etwas größeren > Software-Projekten? Wie die Igel den GV, sehr vorsichtig. > Also jetzt keine Riesen-Projekte mit Programmier-Teams Die Zahl der Entwickler ist eigentlich immer das geringere Problem. Das Hauptproblem sind die Kunden, die vielfach einfach keinen Projektverantwortlichen haben, der auch nur annähernd die nötige Kompetenz hat. Damit meine ich: Den abzubildenden Prozeß in seiner ganzen Komplexität zu kennen. Schlimmer ist noch: oftmals ist in der ganzen verschissenen Kundenfirma überhaupt niemand aufzutreiben, der versteht, wie der Prozess im Detail funktioniert, der alle Ausnahmen von der Regel kennt und alle Verästelungen von deren Auswirkungen. D.h.: in aller Regel vergeht entweder die halbe Projektzeit mit der Erforschung dieser Sachen durch Leute, die abstraktes Denken gewohnt sind (also eigenenes, in der Prozessmodellierung erfahrenes Personal) und die darüber hinaus Erfahrung darin haben, die kritischen Punkte durch hochnotpeinliche Befragungen quasi des gesamten Kundenpersonals herauszukitzeln, oder es kommt unbrauchbarer Schrott raus, um den dann langwierige Gerichts-Prozesse geführt werden müssen, wenn der Kunde am Ende nämlich merkt, was alles nicht geht, aber gebraucht wird, um den oft in den "Ausnahmen" durch und durch unlogischen Prozess in der eingefahrenen Form weiterführen zu können. Auf die Idee, mal irgendwas zu ändern, was "schon immer so gemacht wurde", kommt natürlich i.d.R. kein Kunde. Genausowenig übrigens wie darauf, vor der Implementierungsphase von sich aus zu sagen dass es so gemacht wird... > Während meiner beruflichen Entwicklung habe ich früher mal einen Blick > in die Anforderungsunterlagen eines relativ dicken Software-Projekts > werfen dürfen. Da waren hunderte von Seiten voll mit stets ähnlich > aufgebauten Absätzen, die jede Funktion, jeden Button, jeden Text, usw., > furztrocken beschrieben haben. Von Idioten, für Idioten... Das ist unbrauchbarer Labersülz für Leute, die maximal in den Kategorien eines GUI denken können. Nicht, daß ein gut benutzbares GUI unwichtig wäre, aber das ist eine Sache, die man notfalls von Praktikanten umsetzen lassen kann. Das Wesentliche ist das, was an der Oberfläche nicht direkt zu sehen ist: Das Prozessmodell (neudeutsch: die "business logic"). Wenn das auf den abgebildeten Prozess paßt, ergibt sich die GUI-Logik für jede beliebige Stelle im Prozess praktisch von selbst. Deswegen würde ich jedem Kunden empfehlen, tiefstes Mißtrauen gegen Anbieter aufzubringen, die nach 10% der Projektzeit erste Versionen der GUI-Anwendungen vorführen wollen. Das kann nur kompletter Mist der Klasse "PowerPoint enhanced reality" sein, nur daß es halt statt mit PP mit VS oder Eclipse generiert wurde...
Jan Hansen schrieb: > Schon im Vorhinein alles zu spezifizieren hat bei mir nie funktioniert. Während des Entwicklungsprozesses wird es immer Änderungs-/Erweiterungsbedarf von Kundenseite geben. Insofern sehe ich es ähnlich wie Jan. Allerdings sollte im Vorfeld der Rahmen stehen. Bei Sicherheitslösungen oder Penetration Tests würde man ja auch nicht dem Kundenwunsch a la "Prüfen Sie mal auf alles" entsprechen, sondern eingrenzen, worauf es dem Kunden besonders ankommt und was in seinem Falle ein Muß ist, was weggelassen werden kann. A.B. schrieb: > Ich bin bei meiner Recherche natürlich auf diverse Mind Map Programme gestoßen - > was haltet Ihr davon? Für die kaufmännische Seite oder die Bosse ganz sinnvoll, sollte man aber auch nicht überbewerten, denn... c-hater schrieb: > Das Hauptproblem sind die Kunden, die vielfach einfach keinen > Projektverantwortlichen haben Der Boss sagt, was er will, aber der Projektverantwortliche ist der Ansprechpartner und sollte auch was von der Materie verstehen. Dem dann mit Folien zu kommen halte ich nicht für zielführend. Viel wichtiger ist es, wie schon angeklungen, dass es diesen Verantwortlichen überhaupt gibt und das die Zusammenarbeit mit dieser Person im Vorfeld besprochen und festgehalten wird.
c-hater schrieb: > Kompetenz hat. Damit meine ich: Den abzubildenden Prozeß in seiner > ganzen Komplexität zu kennen. Schlimmer ist noch: oftmals ist in der > ganzen verschissenen Kundenfirma überhaupt niemand aufzutreiben, der > versteht, wie der Prozess im Detail funktioniert, der alle Ausnahmen von > der Regel kennt und alle Verästelungen von deren Auswirkungen. Jep. Hellhörig sollte man auch immer werden, wenn bei den ersten Besprechungen dir 10 Dinge auffallen, von denen dein Gegenüber dir sagt "Das kommt bei uns nicht vor" ohne weitere Begründung warum nicht. Wetten doch? Dein Gegenüber weiss das nur noch nicht, weil diese Fälle in Eigenregie von den Mitarbeitern gelöst werden. Verlässt du dich auf dieses "Kommt bei uns nicht vor", dann landest du eigentlich unweigerlich nach ein paar Monaten in Teufels Küche. > Das Wesentliche ist das, was an der Oberfläche nicht direkt zu sehen > ist: Das Prozessmodell (neudeutsch: die "business logic"). Wenn das auf > den abgebildeten Prozess paßt, ergibt sich die GUI-Logik für jede > beliebige Stelle im Prozess praktisch von selbst. Das ist auch meine Erfahrung. Wobei das Problem beim Prozessmodell darin besteht, dass der Kunde es oft selbst nicht versteht. Da schliesst sich wieder der Kreis zu Jan: Je früher der Kunde damit spielen kann, um so schneller fällt auf, wo er dir falsche Informationen gegeben hat. Wenn überhaupt. Denn oft nickt dein Gegenüber deine Vorschläge einfach nur ab, weil er eigentlich keine Ahnung hat, wovon zum Teufel du eigentlich sprichst. Und die Vorschläge WERDEN von dir kommen, rechne nicht damit, dass dein Kunde da eine grosse Hilfe ist. Allerdings taucht dann wieder das Problem auf, dass es Kunden gibt, die GUI mit Prozessmodell verwechseln und sich stundenlang mokieren, dass der Button der ersten Testversion mit der du testen willst, ob die Leute mit der Logik klarkommen, die falsche Farbe hat. Bildlich gesprochen. SW Entwicklung könnte so schön sein, wenn es keinen Kunde gäbe :-) Das einzige, was bei mir einigermassen funktioniert (hat), ist ein konsequent modularer Ansatz. Möglichst wenig Querverbindungen zwischen den Modulen. Keine Funktionalität in die GUI, die dort nicht hingehört. Um zb Eingaben zu validieren, hält die GUI konsequent Rücksprache, auch wenn das momentan programmtechnischer Overkill zu sein scheint. Dann kann man Module meistens noch gegen eine andere Implementierung austauschen. Aber sobald es zu viele Querverbindungen und Verflechtungen gibt, wird das oft schwierig.
:
Bearbeitet durch User
Karl Heinz schrieb: > ... dann landest du > eigentlich unweigerlich nach ein paar Monaten in Teufels Küche. Darauf würde ich mich freun. Die Teufels Küche ist ein super Burger- und Steak-Schuppen! http://www.teufelskueche-ab.de/ Aber zum Thema: Ich habe auch schon erlebt, dass der Kunde gar nicht weiß, was er eigentlich will. Und eigentlich will er es auch gar nicht so genau wissen. Eigentlich hast du einfach nur eine Möglichkeit, ein Maßgeschneidertes Produkt zu verkaufen, bei dem der Kunde nur die grobe Funktion vorgibt. Jede detaillierte Dokumentation im Vorfeld tust du also eigentlich nur für dich. Der Kunde verlangt meistens nicht mehr als ein paar Milestones. Hast du jedoch einen kompetenten Kunden (sowas soll es auch geben), dann wird er dir den Rahmen auch entsprechend vorgeben. Das kann dann beliebig detailliert werden und sollte im Lasten/Pflichtenheft niedergeschrieben werden
Noch was: von irgendwelchen Programmen, mit denen beim Kunden die Anforderungen aufgenommen werden, halte ich ehrlich gesagt überhaupt nichts. Das Problem: 70% der Zeit wird damit verschissen, auszuprobieren welcher Font in welcher Größe für Überschriften benutzt werden soll und welche Stichworte in welcher Farbe unterstrichen werden sollen. D.h. nachdem man 30 Minuten damit verbracht hat, den beschissenen Beamer beim Kunden am Laptop anzuschliessen. Derartige Programme verleiten dazu, sich mehr mit der Form als mit dem Inhalt zu beschäftigen. Ich war schon in Besprechungen, die hauptsächlich daraus bestanden, dass jemand in Mind Map Punkte von einer Ecke des Bildschirms in die andere zu verschieben, weil das besser aussieht. Papier und Kugelschreiber und zu Hause kann man dann meinetwegen das alles in elektronische Form bringen und dem Kunden zur Kontrolle zusenden.
:
Bearbeitet durch User
Karl Heinz schrieb: > Wobei das Problem beim Prozessmodell darin besteht, dass der Kunde es > oft selbst nicht versteht. Sag' ich ja. Manchmal ist es echt erschreckend, daß Produktion tatsächlich überhaupt funktioniert, obwohl eigentlich absolut niemand der Beteiligten weiß, wie genau sie eigentlich in ihrer Gesamtheit funktioniert. Tatsächlich ist das nämlich auf Grund der Vielzahl der intelligenten Beteiligten in gewissem Maße ein selbstorganisierendes (aber leider nicht unbedingt selbstoptimierendes) stochastisches System. Das ist allerdings gut für uns Software-Lieferanten. Wenn man erstmal "drin" ist, sind Folgeaufträge fast unausweichlich, weil man immer derjenige Anbieter sein wird, der die durch die Selbstorganisation oder auch äußere Einflüsse nötigen Änderungen zu den geringsten Kosten in das bestehende System einpflegen kann. Es sei denn, man hat zwischenzeitlich den oder die Entwickler entlassen, die sich mit dem System auskennen. Dann ist man oft raus, weil dann der Kostenvorteil massiv zusammenschmilzt und die Konkurrenz mit Dumping-Abschlägen zum "reinkommen" kalkuliert oder auch einfach nur wild spekuliert und es auf einen Gerichtsprozess ankommen läßt. Selbst wenn die den verlieren, hilft dir das nicht: du bist raus, denn die Projektkohle ist dann bereits verbrannt. > SW Entwicklung könnte so schön sein, wenn es keinen Kunde gäbe :-) Wohl wahr... > Das einzige, was bei mir einigermassen funktioniert (hat), ist ein > konsequent modularer Ansatz. Möglichst wenig Querverbindungen zwischen > den Modulen. Das ist natürlich immer anzustreben. Blöderweise wird genau das eben fast immer dadurch unterminiert, daß es Abhängigkeiten gibt, von denen du noch garnix weißt, weil halt das Prozessmodell nicht vollständig ist...
Ach ja, lese mal "The Art of UNIX Programming" durch, da stehen viele wichtige Hinweise drin. Auch ist es oft sinnvoll zuerst einen Prototypen zu bauen. Der mal die wichtigsten Funktionen abdeckt und nicht schön sein muss. Das kann man dann den Nutzern geben um Feedback zu bekommen. Damit kann man auch rechtzeitig feststellen ob man nicht total auf dem Holzweg ist. Die meisten Probleme in der Software sind nicht sehr komplex wenn man sie mal richtig verstanden hat. Das Verstehen des Problems dauert die meiste Zeit. Und versuche die Software selbst zu benutzen. Stört Dich dabei was, so baue das um so dass es Dich nicht mehr stört. Baue keine Funktionen um der Funktion selbst wegen ein, es sei denn sie ist orthogonal und ermöglicht völlig neue Anwendungen. Im Allgemeinen sollten die meisten Funktionen orthogonal sein, sprich sich nicht überlappen und dafür gegenseitig ergänzen. Für immer wiederkehrende Vorgänge können aber auch nicht-orthogonale Funktionen notwendig sein die im Prinzip die Arbeit von n anderen Funktionen machen. Versuche Wege zu finden, dabei doppelten Codeaufwand zu sparen.
:
Bearbeitet durch User
Das ist auch meine Erfahrung, dass der Kunde zu Projektbeginn nicht (genau) weiß, was er eigentlich braucht und der System/Software-Ersteller hat nur in Ausnahmefällen eine Ahnung davon. Das führt oft zu zwei unschönen Abläufen: Der Kunde schreibt in seinen Worten das Pflichtenheft, der Realisierer schreibt in seinen Worten die Grobspezifikatio, die dann zur Vertragsgrundlage wird. Wenn der Kunde das fertige Programm/System bekommt, dann fühlt er sich oft über den Tresen gezogen, weil er das Ergebnis fast nicht brauchen kann, aber bezahlen muss. Der Kunde ist projektbegleitend dabei und es fließen laufend Änderungswünsche ein ("Die einzige Konstante in diesem Projekt ist die Zahl der monatlichen Änderungen!"). Wenn man da keine Gleitklausel im Vertrag hat, dann zahlt man als Firma letztlich drauf. Rapid Prototyping ist, falls anwendbar, ein hervorragendes Mittel, wenn man den Kunden dazu bekommen kann, die Funktionen und nicht das Aussehen zu bewerten. Mit so einem Prototypen lernen Kunde und Realisierer gemeinsam, bevor wirklich kostenintensive Arbeiten angepackt werden. Von den ganzen Planungswerkzeugen halte ich sehr wenig, denn sie sorgen nur dafür, dass man Papier gutaussehend bedrucken kann; den wichtigen Teil, nämlich das Nachdenken, können sie nicht ersetzen und bestenfalls nur minimal unterstützen. Wenn man weiß, was man wie realisieren will, dann kann man solche Tools benutzen, um hübsches Papier zu erzeugen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.