Projekt Plan
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (zum vorhergehenden Autor) (Änderung, Korrektur, Normalansicht)

Verändert: 1c1,5
Ein ProjektPlan beschreibt Details eines geplanten Projektes und soll den Beteiligten helfen, das Projekt zu realisieren. Je nach Art des Projektes (Branche, Aufgabenstellung, Größe) und der verwendeten Methodologie (Philosophie) exististieren unterschiedliche Vorstellungen, wie ein ProjektPlan aussehen soll. Das Spektrum reicht von der totalen Bürokratisierung bis zur möglichst weitgehenden Entbürokratisierung. Mögliche Probleme des Projektplans sind, dass erheblicher Aufwand in der Planung und Verfolgung des Planes betrieben wird, der unter Umständen über die Köpfe der Betroffenen hinweg und an der Realität vorbei betrieben wird. Änderungen an den Rahmenbedinungen eines Projektes, können Neuplanungen erforderlich machen. Im ungünstigsten Fall entsteht durch detaillierte Planung mehr Schaden als Nutzen. Andererseits kommen Projekte ab einer gewissen Größe nicht ohne eine detaillierte Planung und ein entsprechendes Kontrolling aus.
Ein ProjektPlan beschreibt Details eines geplanten Projektes und soll den Beteiligten helfen, das Projekt zu realisieren. Je nach Art des Projektes (Branche, Aufgabenstellung, Größe) und der verwendeten Methodologie (Philosophie) exististieren unterschiedliche Vorstellungen, wie ein ProjektPlan aussehen soll. Das Spektrum reicht von der totalen Bürokratisierung bis zur möglichst weitgehenden Entbürokratisierung. Mögliche Probleme des Projektplans sind, dass erheblicher Aufwand in der Planung und Verfolgung des Planes betrieben wird, der unter Umständen über die Köpfe der Betroffenen hinweg und an der Realität vorbei betrieben wird. Änderungen an den Rahmenbedinungen eines Projektes, können Neuplanungen erforderlich machen. Im ungünstigsten Fall entsteht durch detaillierte Planung mehr Schaden als Nutzen. Andererseits kommen Projekte ab gewissen Leistungsverpflichtungen nicht ohne eine detaillierte Planung und ein entsprechendes Kontrolling aus.

Verwandte Themen:
* SoftwareMethodologien
* AufwandsSchätzung

Ein ProjektPlan beschreibt Details eines geplanten Projektes und soll den Beteiligten helfen, das Projekt zu realisieren. Je nach Art des Projektes (Branche, Aufgabenstellung, Größe) und der verwendeten Methodologie (Philosophie) exististieren unterschiedliche Vorstellungen, wie ein ProjektPlan aussehen soll. Das Spektrum reicht von der totalen Bürokratisierung bis zur möglichst weitgehenden Entbürokratisierung. Mögliche Probleme des Projektplans sind, dass erheblicher Aufwand in der Planung und Verfolgung des Planes betrieben wird, der unter Umständen über die Köpfe der Betroffenen hinweg und an der Realität vorbei betrieben wird. Änderungen an den Rahmenbedinungen eines Projektes, können Neuplanungen erforderlich machen. Im ungünstigsten Fall entsteht durch detaillierte Planung mehr Schaden als Nutzen. Andererseits kommen Projekte ab gewissen Leistungsverpflichtungen nicht ohne eine detaillierte Planung und ein entsprechendes Kontrolling aus.

Verwandte Themen:

Beispiel mit Diskussion

In meinem (bs) Projekt (StudentischesProjektVisuelleBildsuche) haben wir uns als Weg zum Ziel für ExtremeProgramming entschieden. In studentischen Projekten der Universität Bremen war es anscheinend bisher üblich, einen ProjektPlan zu erstellen. Die Erstellung des Projektplanes wurde zu Beginn des Projektes als Scheinkriterium festgelegt, d. h. kein ProjektPlan zu erstellen bedeutet, keinen Projektschein zu bekommen. Es wurde jedoch nicht konkret erläutert, was ein ProjektPlan nun eigentlich sein soll bzw. welche Dinge in ihm stehen sollen.

Mein Vorschlag für einen ProjektPlan ist, alle Deadlines zu nehmen und sie dort übersichtlich aufzuführen. Dies sind momentan zwei: das Projektende (in etwa eindreiviertel Jahren) und die öffentliche Projektvorstellung (in eineinhalb Jahren). Mehr würde ich dort aus XP-Sicht nicht integrieren.

Dieser Vorschlag stößt auf Ablehnung seitens des Professors. War dieser bisher sehr davon angetan, daß wir XP einsetzen, so möchte er doch, daß der ProjektPlan auch alle Release-Umfänge beschreibt. Weiterhin möchte er auch jeweils die nächsten Iteration im voraus verplant wissen.

Argumente gegen diese XP-untypische Vorgehensweise tat er ab: daß nicht alles planbar sei und, je weiter es in die Zukunft ragen würde, desto ungenauer werden würde, würde uns Erfahrung lehren in dem Sinne, als daß wir besser Schätzen lernen würden. Auch, daß wir mittels Planspiel einen sehr genauen Iterationsumfang festlegen könnten, sei kein Grund gegen einen Projektplan, da dieser ja auch immer angepaßt werden könnte. Wird daraufhin mit "Das ist zuviel Overhead, zuviel Arbeit, nach jedem Schritt den Plan erneut anpassen zu müssen" argumentiert, so ist die Antwort "Tja, man muss natürlich auch etwas für das Projekt tun...!". Diese Diskussion führte bislang zu keinem Ergebnis.

Der Prof ist sehr aufgeschlossen und läßt uns enorm viel Freiraum, daher gehe ich davon aus, daß ich mit den falschen Argumenten hier an die Sache rangehe, vielleicht sogar die Lage falsch sehe oder mißverstehe.

Frage: wie könnte man dieses Problem XP-like lösen, am besten so, daß alle zufrieden sind? Konkret: wie sieht ein XP-Projektplan aus? --bs

Einen Projektplan zu fordern ist ziemlich vernünftig. Nur so kann man einigermassen effektiv planen und gezielt arbeiten. In einem Projektplan sollten beabsichtigte Aktivitäten und Ziele beschrieben werden. Das man die Ziele mit der XP-Methodik umsetzen will spricht keineswegs gegen die Erstellung eines Projektplanes.

Doch, meiner Meinung nach widerspricht ein Projektplan, so wie ihn mein Prof haben will, dem Prinzip von XP. EmbraceChange ist doch genau entgegen einem Projektplan gerichtet. D. h. ein Projektplan, in dem alle Anforderungen (auch die, die erst in zwei Jahren relevant sind bzw. sein könnten) verzeichnet sind, müßte in einem XP-Prozess ständig angepasst werden - eine Aufgabe, für die doch das Planspiel eingesetzt wird. --bs

Das interessante an einem Projektplan ist, das er in der Praxis praktisch nicht eingehalten wird. Der Projektplan rahmt das Projekt dermassen ein, dass schlussendlich der Faktor Kreativität vollständig flöten geht.

Es kann natürlich sein, dass XP nicht das Wahre für euer Projekt ist? Man sollte die Methode nach der Aufgabe aussuchen. In diesem Falle sehe ich es aber nicht so. Wenn Eure Ziele jetzt definiert sind, dann sollte es möglich sein, deren Verwirklichung zu planen. Sicherlich, Ihr werdet Fehler in Euren Schätzungen machen, Eure Ziele werden sich ändern... und wird sich Euer Plan ändern müssen. Einen Projektplan zu erstellen mach aber trozdem Sinn. Und noch mehr Sinn macht es, zu lernen wie man Projektpläne erstellt und überwacht. Es ist wichtig, wenn Du später mit Softwareentwicklung Geld verdienen willst :-)

Unsere Ziele sind eben noch nicht definiert. Somit können wir deren Verwirklichung noch nicht planen. Wenn unser Ziel noch nicht definiert ist, dann ist es anzunehmen, daß sie sich noch oft ändern werden. Dies bedeutet eine hohe Änderungsrate auch am Plan. Dies bedeutet, daß jede Änderung des Zieles eine Änderung am Plan zur Folge hat und das bedeutet, daß der Plan eine Menge Zeit kosten wird, welche durch das Planungsspiel, durch häufige Releases, durch Iterationen, kurz durch XP, eben anders, aber ebenso effektiv eingesetzt wird.
Warum macht es trotzdem Sinn, einen Projektplan zu erstellen? Warum ist er wichtig, wenn ich später mit Softwareentwicklung Geld verdienen will? Kann ich das mit XP etwa nicht tun? --bs

Ich gehe davon aus, dass die Aufgabenstellung bekannt ist, anhand der Aufgabenstellung kann man den benötigten Aufwand schätzen und entsprechend der Schätzung einen Projektplan ausarbeiten. Da eine Schätzung nicht 100% korrekt sein kann, sollte man Meilensteine und Kennzahlen definieren, deren Einhaltung man überprüfen kann, um den Projektvorschritt überwachen zu können, und den Projektplan eventuell anzupassen.

Dafür ist das Planungsspiel zuständig. Bei XP gibt es keine Meilensteine, sondern Iterationen und Releases. Diese zu schätzen ist sinnvoll, denn man erhält relativ sofort FeedBack über Erfolg oder Mißerfolg seiner Schätzung. Von daher ist doch ein Milestone äquivalent zu einem Release, mit der Ausnahme, daß ein Milestone nicht unbedingt lauffähig sein muss, auch wenn man dies als Kenngröße ansehen könnte.

Leider ist schneller FeedBack ein rares Gut :-(

Somit ist es umso erstrebenswerter, Mittel und Wege zu finden, schnell FeedBack zu erhalten: ExtremeProgramming und darin das Planungsspiel, welches mir FeedBack bzgl. der Planung gibt. --bs

Es wäre aber nicht gut, alle Milestones auf einmal zu bestimmen, zu schätzen und dann abzuarbeiten, da der vorherige Milestone den aktuellen immer stark beeinflusst. Von daher sollte doch immer iterativ geplant werden und genau das sehe ich bei einem Projektplan nicht gegeben, bei XP hingegen schon. Ich sehe es kommen: wenn wir mit dem ersten Release fertig sein werden, werden wir 1000 Dinge ändern wollen, da wir uns jetzt nicht vorstellen können, wie das alles einmal aussehen soll. Ich sehe einen gewaltigen Overhead auf uns zukommen, jedesmal dann den Projektplan anzupassen. Alleine die (arme) Person, die das machen muss, fehlt dem Team. Und das alles nur, weil unser Prof das möchte. Somit fände ich es besser, den Prof davon zu überzeugen, keinen Projektplan, so wie er es möchte, erstellen zu müssen. --bs

Es würde wenig Sinn machen, Projektpläne in Stein zu meisseln. Projektpläne müssen auch immer wieder aktualisiert werden und der Realität angepasst werden.

Genau, und daß bedeutet zwei Dinge: Zum einen einen nicht zu verkennenden Mehraufwand, da zuzätzlich zum Planungsspiel auch noch der Projektplan gepflegt werden muss. Zum anderen Redundanz, denn die Informationen, die mir das Planungsspiel geben, stehen auch noch im Projektplan, IMHO völlig unnützt und sogar gefährlich (siehe EinmalUndNurEinmal).

Bei XP wird ein Projektplan selbstverständlich anders aussehen als bei RUP oder V-Modell, nichts desto wenigen kann man nicht behaupten, dass XP planlos sei. Wie wollt ihr die Software entwickeln? Kannst Du kurz beschreiben, was zu tun ist? Wer was wann macht? Wenn Du das beschreiben kannst, dann hast Du was Dein Prof verlangt.

Ich habe nie behauptet, daß XP planlos sei, sondern bin vielmehr der Meinung, daß XP genau die Dosis an Plan dem Team abverlangt, damit der nächsten Schritt gegangen werden kann.
Was zu tun ist wissen wir jetzt noch nicht. Wir wissen, was in den nächsten 4 bis 8 Wochen zu tun sein wird, aber nicht, was in einem Jahr zu tun sein wird.
Wer was wann macht können wir auch nicht sagen, da dies das Planspiel festlegt. Und wer dann etwas macht, ist egal, da eine GemeinsameVerantwortung? (XP-Praktik) besteht und jeder das erfüllt, wofür er verantwortlich sein möchte (konkret: das Team, welches programmieren möchte, nimmt sich eine Storycard und legt los - welche Storycard ist egal).
Ergo: ich kann nicht beschreiben, was mein Prof verlangt. Ich müßte schätzen, auf 2 Jahre im voraus; ich müßte lügen. Ich möchte nicht lügen. Genau darum schreibe ich mein Leid ja auch in dieses Wiki, in der Hoffnung auf neue Erkenntnisse :-) --bs

Ich schätze, dass genau hier das Problem liegt. Du willst für das Team planen, Dein Prof scheint hier aber eher die Rolle des Geldgebers zu spielen (oder entwickelt er mit?). Versuche Dir die Sache aus der Sicht eines Geldgebers vorzustellen, der paar hunderttausen für eine Software ausgeben soll. Würdest Du das ohne einen Plan machen? (Klar, hier geht es um "billige" Studentenzeit und etwas Kleingeld, aber Ihr macht es doch um es zu lernen.) --gR

Nein, mein Prof entwickelt nicht mit. Geldgeber aber ist er auch nicht, eher eine Art Coach, der den Aufprall dämpft, falls wir mit Karacho gegen die Wand laufen :-) Du mußt wissen, daß unser Projekt studentisch selbstverwaltet ist. Dies bedeutet, daß es mehr oder minder ohne Prof auskommt. Der Prof ist zwar dort und bringt auch ab und an seine Meinung mit ein, aber er beeinflußt uns nur in solchen Dingen, die er für sehr wichtig hält oder die er für die Zensurbildung benötigt (hier eben beim ProjektPlan).
Ich stelle mir die Sache nun aus der Sicht eines Geldgebers vor: ich habe die Möglichkeit, die Anforderungen genau zu bestimmen, habe präzise Aussagen, wann mein nächstes Release mit welchen Features, die ich vorher beeinflusst habe, vorhanden sein wird, kann jederzeit Dinge mit Geschäftswert anders Priorisieren (ohne exorbitante Kostenänderungen befürchten zu müssen) und stehe in Kontakt zu einem Team, daß mit mir redet. Ich habe die Möglichkeit, jederzeit das Projekt zu beenden und eine meiner Investition angemessenen Funktion meiner Software zu erhalten. Denn ich weiss, daß ich keinen Werkvertrag, sondern einen Dienstleistungsvertrag mit dem Team abgeschlossen habe. Ich denke, ich mache das ohne einen ProjektPlan, denn ich brauche ihn nicht. Aber ich tue dies mit einem Plan: XP. --bs


Was versteht Euer Prof denn grob unter einem ProjektPlan? Würde ihn das Ergebnis Eures PlanungsSpiels nicht zufrieden stellen?

Unser Prof möchte in einem ProjektPlan Deadlines und Ziele sehen. Gegen externe Deadlines, d. h. solche, die uns von außerhalb auferlegt werden, habe ich nichts. Dazu würde z. B. das Projektende oder die Präsentation unserer Ergebnisse gehören. Aber nur um dieser externen Deadlines willen würde es auch ein Kalender tun (den man dann auch Kalender und nicht ProjektPlan nennen sollte).
Unser Prof möchte hingegen auch die internen Deadlines, also Iterationen und Releases, festgelegt wissen. Da wir aber noch keine Ahnung haben, wie unsere Geschwindigkeit aussehen wird, habe ich auch keine Ahnung, wie wir solche Deadlines festlegen könnten. Hinzu kommt, daß wir Studenten sind, d. h. unsere Zeitresourcen können nicht so einfach 5 mal 8 gleich 40 Stunden / Woche festgelegt werden, sondern sind auf solche Dinge wie Semesterferien, Prüfungszeit und Vorlesungsverzeichnis bezogen und damit für jeden einzelnen von uns sehr flexibel, d. h. sehr schwer dies zu schätzen.
Als Ziele möchte er die Anforderungen im Projektplan sehen, und da sehe ich den meisten Overhead: jedesmal, wenn sich eine Anforderung ändert, muß sich auch der Projektplan ändern. Als Vorschlag ist bereits gefallen, daß nach jedem Plenum (bei uns momentan wöchentlich 2 bis 4 Stunden) der Projektplan angepasst werden muss. Das würde bedeuten, daß praktisch ein Student bis zu mehreren Stunden pro Woche mit der Plananpassung verbringen müsste! Und nur um des Profs Willen: ich sehe keinen Nutzen für diesen Plan. Unsere Informationen würden aus den im PlanungsSpiel entstandenen Storycards gezogen werden. Mit Storycards und Projektplan wäre dies sogar Datenredundanz - nicht gut, gar nicht gut.
Das einzige, was ich momentan Gutes sehe an diesem Plan, ist, daß er uns für später eine gute Projekt-Historie aufzeigen würde. Aber dafür so einen Aufwand betreiben ... - ich weiss nicht so recht ;-) --bs

Wie wäre es denn, wenn Ihr die StoryCards? direkt als ProjektPlan verwendet? Ihr könntet Euch z. B. eine Pinnwand o. ä. suchen und die StoryCards? dort gruppiert nach Iterationen anpinnen. Wenn Ihr dann etwas an dem Plan ändern wollt, braucht Ihr die entsprechenden Karten nur umzuhängen - für den Prof / das Archiv könnt Ihr regelmäßig Fotos von dem Plan machen. Ähnlich für TaskCards? und IterationsPlanung?. --ip

Das mit der Pinnwand und den gruppierten Storycards habe ich sowieso bereits ins Auge gefasst. Sollte dies Probleme machen, so wäre auch eine Software für die Verwaltung der Storycards sinnvoll. Wie auch immer: die Storycards würde ich gerne als Projektplan sehen. Mehr Informationen, als in den nach Iterationen und Inhalten gruppierten Storycards wäre auch aus einem ProjektPlan nicht zu entnehmen (vielleicht noch ein zusätzlicher Kalender für außergewöhliche Termine, der aber sehr klein zu halten ist und Bezüge(!) zwischen Terminen und Inhalten herstellen könnte.
...könnt Ihr regelmäßig Fotos von dem Plan machen. Ernsthaft? Ich könnte mir bei der Verwendung einer Software so etwas wie ein Freeze fürs Archiv vorstellen, aber Fotos von einer Pinwand wären IMHO nicht praktikabel: kaum etwas zu erkennen (selbst mit Megapixelkameras, und die muss man ja auch erstmal beschaffen :-) ), unpraktisch zu betrachten (der Bildverarbeitungsaufwand wäre doch nicht unerheblich, um aus einer mehreren hundert Pixel breiten und hohen Bildmasse etwas handliches und durchsehbares zu gestalten) und in meinen Augen den Aufwand nicht wert, da es sich eh keiner mehr anschauen würde. Da würde ich später lieber mal die einzelnen lauffähigen Release-Versionen durchschauen (wäre bestimmt lustiger :-) oder, bzgl. der Storycards, mir die Stapel Karteikarten in real life durchblättern :-) --bs

Diese Form der ReleasePlanung sollte recht problemlos für mindestens ein halbes Jahr im voraus möglich sein - für die darauffolgende Zeit würde ich wahrscheinlich nicht viel mehr als "grobe Visionen" ausformulieren (vielleicht in der Art eines "Themas", unter dem die Entwicklung stehen soll). --ip

Ich habe ehrlich keine Ahnung, für welchen Zeitraum im voraus das möglich sein könnte. Wohlgemerkt: wir haben eine (sehr) grobe Richtung, welche wir gehen wollen, aber ein Ziel kann man das noch nicht nennen. Daher weiss ich auch nicht, wie weit im voraus wir in Bezug auf dieses Projekt denken können werden. Hinzu kommt, daß viele von uns keine erfahrenen Programmierer sind (und ich rede noch nicht einmal hier von denen, die dieses Projekt nicht machen wollen, sondern müssen, da der Schein fürs Diplom sehr wichtig ist), und fast keiner von uns XP kennt bzw. die Methoden und Werkzeuge versteht, geschweige denn die Philosophie dahinter. Dies führt dazu, daß wir gerade in den ersten Monaten, wenn wir die Software entwickeln, viel Zeit auf die Einarbeitung verwenden müssen und somit das Vorausschauen noch schwieriger wird.
Ich sehe es kommen, daß wir das erste Release fertig haben, verdutzt das anschauen, was wir gemacht haben und dann mehrere gravierende Veränderungen vornehmen werden :-) Generell, sobald wir unsere Geschwindigkeit gefunden haben, finde ich es aber eine gute Idee, "themenbezogen" vorzugehen. --bs


Hallo, hier MatthiasBohlen:

Ich finde diese Diskussion hier hochinteressant, weil sie aus dem üblichen Sicherheitsbedürfnis eines Geldgebers entspringt. Meine 2 Cents dazu sind folgende:

Paragraph 1: Diskutiere nicht! Du kannst nie gegen Deinen Kunden gewinnen, und wenn, ist er nicht mehr Dein Kunde! Entspanne Dich, hör auf, nach Argumenten zu suchen, Argumente sind ein Fall von YAGNI. --mb

...mehr hierzu unter ArgumentationUndYAGNI.

Dann: Mache ihm dann folgendes klar: Soll ich Dir sagen, was passieren wird?
Eine fantastische Idee! Sie gefällt mir sehr gut, allerdings halte ich sie für nicht praxistauglich!
Schlimmster Fall mal angenommen, wir können unseren Prof nicht überzeugen, Release-/Iterationsplan-Kombo samt Planungsspiel als guten Projektplan-Ersatz anzusehen. Weiter angenommen, wir schlagen ihm den Projektplan als Anforderung im XP-Sinne vor, samt AnforderungsGeschichte, Schätzung des Geschäftswertes und Aufwandsschätzung. [Die Rolle des Profs unterscheidet sich stark von der eines Kunden. Im optimalen Falle sitzen Auftragnehmer und -geber in einem Boot und sind beide daran interessiert, den Hafen zu erreichen. Im Prof-Studi-Verhältnis ist der Prof zwar eigentlich auch im Boot, jedoch hat er selbst keinerlei Nachteile, wenn der Hafen nicht erreicht wird!] IMHO wird er vielleicht lachen, vielleicht aber auch ganz ernsthaft dies für einen guten Vorschlag halten. Nichts desto trotz wäre es an uns, diese Aufgaben zu erledigen. Er selbst wird nichts tun und somit nicht die Erkenntnis erlangen, daß es nicht ganz einfach ist, ein AnforderungsGeschichte für einen Projektplan zu erstellen. Im Gegenteil: sollten wir die Schwierigkeit einer solchen Aufgabe beanstanden, so würde es vom Prof als lehrreicher Ausflug erklärt werden, der uns gut tun würde und daher nicht schlecht sein kann ;-) Ich habe dies polemisch geschrieben, ich weiss. Aber dies ist in etwa das, was ich kommen sehe, wenn wir diesen Weg einschlagen. Was meinst Du? --bs

Hmmm ... also ist er nicht bereit, wenigstens den Kunden zu spielen? Dann könnt Ihr XP eigentlich gleich vergessen! Oder kann jemand anders (z. B. sein Assistent) den Kunden gültig vertreten (sprich: bereit sein, AnforderungsGeschichten zu schreiben)? --mb

Wie bereits geschrieben, ist der Prof (und zwei WiMis) als Projektbetreuer zu sehen, eine Art Coach, der eine beratende Funktion ausübt. Kunde ist eine Rolle, die einige von uns temporär übernehmen wollen. Momentan befinden wir uns in der Zielfindung des Projektes, wobei wir in dieser Phase quasi alle zusammen Kunde sind und uns Gedanken machen, was wir eigentlich da bauen wollen (uns es ist sehr schwer, auf Kommando zu erfinden!). Wir schreiben also selbst unsere AnforderungsGeschichten, bewerten diese und schätzen den Aufwand.
Warum soll XP deswegen nicht einsetzbar sein? Kunde und Entwickler sind Rollen, welche verteilt werden können. Sicherlich gehört Disziplin dazu, sich stetig daran zu erinnern, welche Kappe sich gerade auf dem Kopf des Studenten befindet, aber ist doch kein Grund, XP nicht einzusetzen? --bs

Na, dann müsste es ja gehen! Meine Aussage oben bezog sich eigentlich auf die Situation, in der KEINER bereit ist, den Kunden zu spielen. Aber so ist das ja OK. --mb

Hrmpf - nein, ist es eben nicht. Deine Statements zielen darauf ab, daß wenn mein Prof auf dem ProjektPlan besteht, es möglich sein müßte, wenn man ihm zeigt, wieviel Arbeit es ihm selbst machen würde, er es über kurz oder lang einsehen würde, daß es nicht sinnvoll ist. Wenn aber wir die Kunden sind, so wird der Prof sehen, daß es uns viel Arbeit macht - und vielleicht darüber sogar sehr erfreut sein! Im schlimmsten Falle vergraule ich bis dahin Mühsam für XP empfindsam gemachte Entwickler, so nach dem Motto: "Bäh, wenn es das ist, was uns XP bringt (viel Arbeit, die keiner mag, die redundant ist und überflüssig), dann ist es nicht gut, XP zu machen!" Ursprünglich war - und ist es immer noch -, daß ich ja gerade keinen ProjektPlan erstellen möchte. So aber glaube ich, einen erstellen zu müssen, und zwar, weil ich mich selbst dahin argumentiert habe :-) --bs

Sag bitte mal per Email Bescheid, wie's läuft! Bin neugierig! -- MatthiasBohlen

Email: mbohlen@mbohlen.de

Jap, kein Problem. --bs

verschoben nach StudentischesProjektVisuelleBildsuche

Hmmm, warum sind Projektplan und XP ein Widerspruch? XP heisst nicht, planlos zu hacken!

Ich mach bei jedem meiner (XP-) Projekte einen Projektplan, einfach um für mich den Resourcenbedarf schätzen zu können und Punkte zu finden, an denen ein Projekt korrigiert werden muss. Im Gegensatz zu herkömmlicher Projektplanung halte ich mein Projektplan flexibel, diskutierbar, aktuell und nicht zu detailreich in der fernen Zukunft. Die Projektziele müßen aber in jedem Fall enthalten sein! -- mj

Prozesse entstehen als Reaktion auf Ängste - z. B. reagiert ExtremeProgramming auf die Angst, ein unwartbares Design zu erstellen, durch GnadenlosesRefaktorisieren. Wenn wir jedoch auf alle unsere Ängste durch einführen von Regeln reagieren ohne sie zu hinterfragen, entstehen schnell Prozesse die eine unhandliche Komplexität erreichen - die uns zwar unsere Ängste nehmen mögen, aber nicht unbedingt eine effektive Arbeit ermöglichen. Daher fordert XP den Mut aufzubringen, es auch einmal mit weniger zu probieren, statt mit mehr. Das heißt nicht, dass man blind in sein Verderben laufen soll, sondern durch kleine gesicherte Experimente zu untersuchen, ob Ängste wirklich die damit verbundenen Sicherheitsmaßnahmen rechtfertigen - brauche ich wirklich MsProject??, um die Übersicht über den Projektplan zu behalten, oder tun es auch KarteiKarten? Bei genauerem Hinsehen stellt man fest, dass effektive Softwareentwicklung auch an vielen anderen Stellen Mut erfordert: den Mut, Probleme offen und ehrlich zu kommunizieren; Mut, etwas nicht funktionierendes aufzugeben auch wenn man bereits viel darin investiert hat; den Mut, sich auf seine Mitstreiter zu verlassen; Mut, einen neuen Weg auszuprobieren usw.


Links:


KategorieProjektManagement
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 7. August 2004 11:02 (diff))
Suchbegriff: gesucht wird
im Titel
im Text