Artikel zu Projektumstrukturierung und -organisation

[slawaweis]

Hallo,

ich suche Bücher, Artikel, Links oder auch persönliche Erfahrung zu folgenden Themen:

- Projektumstrukturierung in bestehenden Projekten

Dabei geht es um ein Softwareprojekt, welches bereits eine größere Codebasis hat und ein erfolgreiches Produkt realisiert. Doch leider ist es inzwischen an dem Punkt angelangt, wo der Quelltext nur schwer wartbar ist und einer Grundsanierung bedarf. Doch die vorhandenen Entwickler haben viele Vorbehalte noch größere Änderungen zu machen, in der Furcht alles bisherige zu verlieren. Ich brauche Literatur für solche Art von Projekten, die also bereits bestehen und saniert werden müssen, ohne dass alles auseinander bricht. Am besten mit vielen Beispielen/Erfahrung aus der Praxis und auch einem großen Kapitel über die soziale Komponente, wie man also das bestehende Team einbinden und von Neuerungen überzeugen kann.

- Teamorganisation bzw. -management in Open Source Projekten

Dieses Thema hat nicht direkt mit dem ersten zu tun. Hier suche ich Literatur, wie man ein Softwareprojekt und ein Team aus Personen organisieren/motivieren kann, die sich gar nicht persönlich begegnen und in unregelmäßigen Abständen am Projekt arbeiten oder auch ganz verschwinden können.

Slawa

 

[stareagle]

Moin,

ich habe vor kurzem, da ich was zu einem bestimmten Aspekt der Softwaresanierung (Austausch des Persistencelayers) gesucht, folgendes Buch untergekommen:

Sebastian Kübeck (2009): Software-Sanierung. mitp-Verlag, Heidelberg.

Gruß

Stareagle

 

[slawaweis]

vielen Dank, das Buch sieht sehr interessant aus, werde ich mir auf jedenfall ansehen. Hast Du es schon gelesen?

Slawa

 

[stareagle]

Hallo slawaweis,

nein durchgelesen habe ich dass Buch nicht. Nur den Teil über Persistenzlayer, und ein wenig quergelesen.

Gruß

Stareagle

 

[KSG9|sebastian]

Warum bist du da auf der Suche nach einem Buch?

Real sieht es doch so aus:

Projekte werden von Anfang bis Ende komplett durchgeplant, jedes Detail, jedes Datum, jeder Meilenstein - einfach alles.
Es ist nahezu unmöglich den Projektleiter von einem kompletten Refactoring zu überzeugen. Und selbst wenn der Projektleiter noch zustimmt wird spätestens derjenige der auf dem Geld sitzt ablehnen - schließlich will er ein funktionierendes und kein schönes Projekt.

Solltest du es dennoch schaffen (ich würde es dir wünschen, hab selber fast nur gegenteilige Erfahrungen gemacht):

Du benötigst eine vollständige Analyse des Systems, und zwar absolut vollständig. Welche Funktionen sind vorhanden (Functional, Non-Functional) und wirklich allem was das System hergibt.
Einfach drauflos wird nicht klappen..und dann schön eins nach dem anderen machen, zuerst mal viel Design, dann noch mehr Design, dann noch mehr Diagramme, und vielleicht irgendwann programmieren..

Viel Erfolg

 

[ARadauer]

Projekte werden von Anfang bis Ende komplett durchgeplant, jedes Detail, jedes Datum, jeder Meilenstein - einfach alles.

naja... meinst du das ironisch? Gibt durchaus Firmen die sich in Richtung "agile" bewegen und danach leben...

 

[maki]

Working Effectively with Legacy Code Robert C Martin: Amazon.de: Michael Feathers: Englische Bücher
Amazon.com: Refactoring Databases: Evolutionary Database Design (9780321293534): Scott W. Ambler, Pramodkumar J. Sadalage: Books
Amazon.com: Refactoring: Improving the Design of Existing Code (0785342485677): Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: Books

IMHO: Am besten gar nicht weit kommen lassen und regelmässig tests schreiben + refactorings durchführen.
Anforderungen ändern sich in den meisten Projekten während der Entwicklung, damit muss man zurechtkommen, deswegen denke ich nicht dass für die meisten Projekte das "Alles Analysieren & komplett durchplanen" Vorgehen das beste ist

 

[slawaweis]

Warum bist du da auf der Suche nach einem Buch?

weil ich mich mit den theoretischen Grundlagen beschäftigen will.

Real sieht es doch so aus:

Projekte werden von Anfang bis Ende komplett durchgeplant, jedes Detail, jedes Datum, jeder Meilenstein - einfach alles.
Es ist nahezu unmöglich den Projektleiter von einem kompletten Refactoring zu überzeugen. Und selbst wenn der Projektleiter noch zustimmt wird spätestens derjenige der auf dem Geld sitzt ablehnen - schließlich will er ein funktionierendes und kein schönes Projekt.

um so eine Planung durchzuführen, braucht man erstens gute Experten und zweitens eine breite Geldbasis. Meiner Erfahrung nach kann man große Projekte nicht von Anfang an so planen, dass es später keine Probleme mit dem Projektplan gibt. Schon alleine die begrenzten Mittel am Anfang verhindern eine langfristige Planung.

Bei dem Projekt, für das ich diese Sachen brauche, geht es um eine Software die iterativ entwickelt wird. Am Anfang gab es einen durchdachten Projektplan. Doch in der Zwischenzeit wurden immer mehr neue Features eingeführt, die gar nicht vorher angedacht waren. Irgendwo unterwegs hat man aus verschiedenen Gründen den Überblick verloren. Jetzt soll die Softwarebasis und der Projektplan überarbeitet und auf die Zukunft ausgerichtet werden.

Solltest du es dennoch schaffen (ich würde es dir wünschen, hab selber fast nur gegenteilige Erfahrungen gemacht):

Du benötigst eine vollständige Analyse des Systems, und zwar absolut vollständig. Welche Funktionen sind vorhanden (Functional, Non-Functional) und wirklich allem was das System hergibt.
Einfach drauflos wird nicht klappen..und dann schön eins nach dem anderen machen, zuerst mal viel Design, dann noch mehr Design, dann noch mehr Diagramme, und vielleicht irgendwann programmieren..

Viel Erfolg

danke. Natürlich werde ich eine Analyse erstellen, aber das Problem ist, wie schon oben erwähnt, ich habe nur begrenzte Mittel und Zeitrahmen zu Verfügung. Ich muss das Beste mit den vorhandenen Möglichkeiten rausholen, ich kann mir nicht einfach dafür beliebig viel Zeit nehmen.

@maki
danke für die Bücherlinks.

Slawa