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