Projektmanagement
-
Simon L. schrieb:
In Großen firmen und bei Großen Projecten sollte sowas ja nicht vorkommen und desshalb wird doch sicher ein Art von Vorplanung gemacht, um sich ein Ziel zu setzten, dass es gild zu erreichen ?
Ich sach nur "TollCollect". Oder "Software zur Verwaltung von Hartz IV". Ein Desaster reiht sich an das vorige...
Du wirst in jedem Buch zu "praxisorientiertem Softwareprojektmanagement" rasch die Aussage finden, daß ein Projekt, bei dem man am Anfang alles planen will, und danach diese Planung ausprogrammiert, scheitert, oder die Kundenwünsche verfehlt.
Die Ursache ist auch klar:
Ein funktionierendes System benötigt eine Regelung. Regelung heißt, daß man Abweichungen vom Plan erfasst, und die Sollwerte entsprechend nachstellt.
Das gilt nicht nur für eine Heizungsregelung, sondern auch für ein Projekt (egal ob Software oder Hochhausbau).
Natürlich braucht man einen Masterplan, ein generelles Ziel. Irgendwas soll irgendwie etwas für irgendwen tun. Das muß klar am Anfang definiert sein.
Aber wenn man nun dafür einen großen Plan macht, und diesen einfach abarbeiten will, wird jeder kleine Fehler am Anfang ja komplett ausgeführt. Angenommen, man müßte - auf einem Kompaß - mit Zielrichtung 12 Uhr starten, startet aber mit 12:30. Weil man eine Kleinigkeit nicht ganz verstanden hat, oder weil der Kunde sich über eine gewisse Dynamik unklar war. Je weiter man nun diese Person ohne Korrektur marschieren läßt, desto größer wird die Abweichung vom Ziel. Obwohl am Anfang nur eine kleine Abweichung bestand, wird der Fehler am Ende riesig.
Ein Projektplan muß also so ausgelegt sein, daß er möglichst viele Kontrollstellen und Änderungsmöglichkeiten besitzt. Das heißt konkret bei Softwareprojekten eben Rapid Prototypes, damit die Kunden möglichst früh ein Gefühl für das System bekommen und man Ablehnungen oder Änderungen einbauen kann, aber auch abgeschlossene Zwischenschritte und frühe Rollouts, d.h. man entwickelt nicht 100% des Gebildes und gibt das dann in den ultimativen Betatest. Sondern man definiert Module, und darin wählt man "wesentliche" Module für einige Grundarbeitsschritte aus - und diese implementiert man zunächst, testet sie, gibt sie frei. Und erweitert das System dadurch, bis alles vorhanden ist. Oder wirft auch etwas weg, weil es so nicht gut ist.
Wichtig ist zu verstehen, daß "ein flexibler Plan" nicht bedeutet "kein Plan".
Die Sache verlangt vom Projektleiter relativ viel Mut, weil er auf die Frage "an welcher Klasse arbeitet Entwickler B am 15. Oktober?" heute keine Antwort geben kann - Chefs und Investoren wollen sowas aber oft wissen und glauben, daß ein gut geführtes Projekt bei Projektstart bereits Antworten auf diese Fragen geben kann. Daher werden die Leute oftmals in Versuchung geführt, ein Projekt auf 3 Monate hinaus minutiös mit MS Project zu zeichnen, damit sie was in der Hand haben. Aber ein solcher Projektplan ist eine Lüge, evtl. auch nur Selbstbetrug. 0% fehlertolerant.
-
Also ich plane meine Projekte meist in der Hinsicht, dass ich mir meine Ziele ganz klar formuliere, die müssen einfach erreicht werden, aber der Weg wie ich zu denen komme ist ziemlich flexibel. Beim Ziele formulieren kommen meist schon Ideen zr Umsetzung und von denen rstelle ich am Anfang simple P?rototypen ob das so funktioniert wie gedacht und danach kristallisiert sich praktisch schon von selber ne gute Vorgehensweise und nen Programmaufbau heraus den man dann leicht umsetzen kann. UML Diagramme helfen dann natürlich im fortgeschrittenen Projekt den Aufbau des Programms formal festzuhalten ,aber von Anfang an damit arbeiten wird schwer. Hab selber nen Semester Projektmanagment gehabt in der BA und muss sagen dass die Theorie nur sehr beschränkt in der Realität umgesetzt werden kann.
Daher werden die Leute oftmals in Versuchung geführt, ein Projekt auf 3 Monate hinaus minutiös mit MS Project zu zeichnen, damit sie was in der Hand haben
Hehe, wenn ich sowas mache, dann nur bei größeren Projekten und dann bei fast allen Zeiten nen ? dahinter *gg*
-
Also wir machen das so, das wir natürlich eine Zielvorgabe haben, also was wird fachlich erwartet und welchen Nutzen soll der Benutzer davon haben. Das muß definiert werden. Was aber nachher die Umsetzung angeht, machen wir das iterativ, das heißt jede Woche (oder jeden Tag!) gibt es die Palnung der nächsten Schritte. Natürlich gibts auch Schritte die in 3 oder 6 Monaten umgesetzt werden sollen. Aber im Prinzip ändert sich das innerhalb dieser Zeit wieder.
Wir haben aber auch eine Framework das uns vorgibt wie wir es designmäßig umsetzen sollten.
-
http://de.wikipedia.org/wiki/Projektplanung
Ist eigentlich immer das gleiche. Lastenheft, Pflichtenheft, Zeitabschätzung, Resourcenplanung usw. Wichtig ist das man klar definiert was gemacht werden soll. Tut man das nicht entwickelt man womöglich monatelang weiter, weil man nie weiß wann etwas eigentlich "fertig" ist oder man muss in letzter Minute noch zig Sachen einbauen die man nicht berücksichtigt hat.
Wichtig natürlich auch das man regelmäßig kontrolliert wo man überhaupt hingeht. Ich kenn das selber von mir, da hat man irgendwas interessantes und entwickelt munter drauf los, obwohl die Kundenlösung sowas gar nicht vorsieht/benötigt. Da muss dann irgendwann ein Milestone her an dem man sagt, so jetzt ist Schluss damit, das Projekt muss in die nächste Phase. Und das muss nicht der Programmierer kontrollieren sondern ein Projektleiter.
So was noch? Achja ein Plan wird nicht besser, weil er in UML oder MS Project statt auf einem Zettel gemacht wurde. Es zählt immer der Inhalt nicht die Buzzwords.
-
Artchi schrieb:
Also wir machen das so, das wir natürlich eine Zielvorgabe haben, also was wird fachlich erwartet und welchen Nutzen soll der Benutzer davon haben. Das muß definiert werden. Was aber nachher die Umsetzung angeht, machen wir das iterativ, das heißt jede Woche (oder jeden Tag!) gibt es die Palnung der nächsten Schritte. Natürlich gibts auch Schritte die in 3 oder 6 Monaten umgesetzt werden sollen. Aber im Prinzip ändert sich das innerhalb dieser Zeit wieder.
Wir haben aber auch eine Framework das uns vorgibt wie wir es designmäßig umsetzen sollten.
Am besten Zielvorgabe und Programmierer auseinander setzen, so denken die Leute zweimal. Org-Abteilung spricht mit dem Kunden über Features und teilt die in klaren Zielen den Programmierern mit. Diese entwickeln wideerrum ein Design (natürlich passend zum Projektgesamt-Stil) und geben die genauen Features zurück an die Org-Abteilung. Wird das abgesegnet kann die Implementierung von den Programmieren vorgenommen werden - natürlich möglichst optimal (das wiederrum geht die Org-Abteilung nix an).
MfG SideWinder
-
Ok, einige sagten jetzt, dass es sehr wichtig ist sich ein Zeil zu setzen. Aber da stellt sich doch die Frage wie man sowas am besten macht.
Ich stell mir das So vor:
Alle Features auf einem niederschreiben.Was sich mir auch noch für ne frage stellt, ist wie man nun mehrere Programmierer an einem Project arbeiten lässt. Da müsste man die einzelen Personen verschiedene module Programmieren lassen und dann eine Person das zusammenfügen lassen. Aber gibts da nicht leseschwierigkeiten auf das Gesamte Project gesehen...jeder hat ja seinen eingenen Programmierstiel.
-
Deswegen gibt es Coding Standards, damit nicht jeder anders programmiert. Aber selbst wenn gibt es schlimmeres als verschiedene Tabgrößen oder der andere Umgang mit Whitespaces. "Alle Features" aufschreiben ist eine schlechte Idee. Überleg dir lieber Iterationen, also was soll die Software in Version 0.1 können was in 0.2 usw. Am besten noch mit "muss rein", "sollte rein" und "nice to have" Abstufung der Features.
-
Also im Idealen Fall gibt dir der Kunde ja das Lastenheft und dort steht alles drin was er haben will. Daraus lassen sich recht schnell die Ziele definieren. Man sollte nicht alles auf einmal wollen, wie asdrubael schon sagte sollte man Zwischenziele definieren. Aber wichtig ist das man die Ziele genau definiert. Eine Definition wie z.B: "Programm sollte leicht konfigurierbar sein" nützt keinem was, du musst schon genau festhalten was wie konfiguriert werden muss usw.
Für den Fall mit mehreren Programmierern gibts ja entsprechende Tools wie SourceSafe z.b. oder diese ganzen Open Source Dinger wo ich die Abkürzungen immer vergesse
Da muss auch keine Person speziell die Teile zusammenfügen, die Schnittstellen zwischen den Modulen und die Funktionen sollten ja vorher definiert sein, und da müsste rein theoretisch kaum was schief gehen. Die bisschen Integrationsarbeit kann auch der Projektleiter machen.
-
-
-
kingruedi schrieb:
asdrubael schrieb:
http://web.mit.edu/is/usability/IAP/2003/Session1/Images/Easy-to-use.gif
:D:D
MfG SideWinder
