.in jeder Entwicklungsabteilung das gleich Chaos.oder bin ich das Problem?

"Im Großunternehmen, oder im großen Mittelstand dagegen habe ich
gerade in den organisatorischen Bereichen und im Prozess klare
Pluspunkte gefunden."

So kann man es auch ausdrücken.

Tatsächlich dürfte die Wahrheit schon irgendwo in der Mitte liegen. Wenn 
man vor lauter Planung keine Änderungen mehr machen kann, weil das die 
Planung über den Haufen werfen würde, hat man nichts gewonnen.

Das Leben ist nun mal chaotisch.

Gruss
Axel

vielfach wäre man ja schon froh, wenn am anfang eines projektes, der 
umfange, oder das ziel halbwegs definiert wäre :-)

Oh, Gott, was ich schon alles bei Entwicklern gesehen habe.


*Überhaupt keine Systemdokumente obwohl umfangreiche Projekte (ganz zu 
schweigen von übersichtlicher Plannung bzw. Milestones etc.)
*Nur ein ausgedruckter Bestückungsplan mit markierten Bauteilen, das ist 
schon alles an Dokumentation
*Wenn irgendwo Widerstand getausch wird, weiß keiner zwei Wochen später 
warum
*Da werden Bauteile im Schaltplan ausgetauscht weil billige Alternative 
da ist, keiner prüft die Kompabilität genau: weitere Probleme die Zeit 
kosten
*Ein Oszilloskop für 20 Entwickler
*Keine Dokumentierung der Fehler: die haben alles irgendwie im 
Kopf...lol
*Keine Meetings: keiner weiß was der Andere macht oder beide machen das 
Gleiche

Unsere moderne Raubtieirtschaft bietet da eine ganze Bandbreite an 
Perversitäten an

Hallo,

ich arbeite auch in einer Fa. < 50 Mitarbeiter und muss sagen dass es 
bei uns sehr strukturiert zu geht. Wir entwicklen hauptsächlich für die 
Automobilindustrie. Evtl. steigert das Anwendungsgebiet der SW/HW auch 
die Ansprüche. Könnte mir vorstellen, dass es in der Medizintechnik und 
Luftfahrt noch strenger zu geht.

Aus welchen Branchen stammen deine Erkenntnisse?

@Axel: Muss dir recht geben. Zu viel Dokumentation und nur Meetings sind 
auch nicht optimal!

@Helmut Lenzen: Manchmal stimmt das. Ein gut kommentierter Quellcode ist 
manchmal aufschlussreicher als eine Doku. Aber gerade bei großen 
Projekten und zum schnellen Einstieg kann die Doku sehr hilfreich sein.

Kleine Firmen haben die Tools nicht weil sie kein Geld dafür haben, 
sondern weil die Leute dort unstrukturiert arbeiten wollen.
Wenn man in so einer Firma solche tools einführen will, bricht sofort 
ein Aufstand los. Egal wie gut das ist.
Und wenn man mal Struktur hineingebracht hat wird so gearbeitet, daß 
diese sofort wieder Makulatur ist.

Meine Erfahrung.

White

Bin in einem großen Konzern, habe aber auch das Gefühl, dass in den 
vielen kleineren und mittleren Projekten vieles kreuz und quer und 
ziemlich unorganisiert läuft. Weiter oben werden natürlich auf 
Gemeinkosten bis ins kleinste Detail Standardprozesse kreiert, optimiert 
etc. Bis das alte jedoch mal halbwegs in der Basisarbeit implementiert 
ist, steht schon wieder was komplett neues auf dem Programm. Was unten 
dann ankommt sind eine Hand voll zentraler Milestones, die dann in MS 
Project schön ausgeschmückt werden, um die Führungskräfte 
zufriedenzustellen.

Kann mal jemand der weiß wie man dokumentiert sagen wie man es denn 
richtig bzw besser machen könnte?

Ein wenig erkenne ich mich selbst hier wieder(habe zwar noch nicht mit 
vielen Leuten an einem Projekt gearbeitet) aber das leidige Thema 
Dokumentation macht mir auch immer zu schaffen(Das eine gute Doku für 
einen selbst wichtig sein kann habe ich auch schon gemerkt wenn man 
Quellcode mal ne Weile liegen läßt und sich dann wieder reeinfuchsen 
muss)

Gibts für sowas Standardsoftware? Oder bedeutet Doku einen Text in Word 
zusammenzuhacken

"Oder bedeutet Doku einen Text in Word zusammenzuhacken"

Vorher (also bevor Code geschrieben wird) schon.

Danach finde ich aber, dass der Code sauber dokumentiert sein muss. Und 
es gibt natürlich ein paar Grundregeln. Habe mich gerade wieder durch 
zwei Dutzend Dateien VHDl schlagen dürfen, bei der die Signalnamen durch 
die verschiedenen Module gewechselt haben und kein Signal beschrieben 
war.

Darf der Lieferant jetzt nachbessern. Habe die Schnautze voll.

Gruss
Axel

> Für die Dokumentation des Codes selbst gibt es Tools wie Doxygen und
Javadoc.

Und Zitronenfalter falten Zitronen.

Plan- Was ist das?
Dokumentation- Hahahahaahaahahaaha- Der war gut!

Firma: etwa oehh 3000 Leutchen weltweit.

OOOOH JAAA!

Das Thema kenne ich auch seit Jahren. Als Entwickler muss ich jedesmal 
wieder fluchend feststellen, dass man einen Haufen Zeit und Ressourcen 
sparen könnte, wenn man denn nur einmal anständig ein paar Tage in ein 
Pflichtenheft oder eine Dokumentation stecken würde. Am Ende kostet der 
Verzicht darauf oft viele Wochen an Zeit, die man sinnvoller verwenden 
könnte und Nerven, die man mit unnötigem Krach belastet, weil am Ende 
das nicht mehr gilt, was am Anfang so alles in den Raum geworfen wurde. 
Da kann man sich ja dann auch viel einfacher vorwerfen lassen "..da 
haben wir doch drüber gesprochen!", weil schriftlich nichts festgehalten 
wurde!

Es geht hier nicht um Softwaretools, die man zur Projektverwaltung 
nutzt, auch ist der Kostenfaktor seit Linux nicht mehr so das Problem, 
ein SVN oder Apache usw. kann heute jede Fa. einsetzten.

Nöö, es geht einfach darum, dass Manager immer noch glauben, dass eine 
anständige Projektplanung am Anfang eines jeden Projekts zu viel Zeit 
und Geld kostet, die sie dann während und am Ende des Projekts 
drauflegen müssen, weil man dann feststellt, dass es doch sinnvoller 
gewesen wäre. Jedes Grundlagenkapitel über Software Engineering sagt 
natürlich, dass eine gründliche Spezifikation und der Design Entwurf 
mehr Zeit kostet als die Implementierung. Aber: WER WILL DAS DENN SCHON 
HÖREN?

Ich kann nur sagen, dass ich in den letzten Jahren oft genug Krach mit 
meinem Vorgesetzten hatte - GENAU DESWEGEN - und am Ende trotzdem 
jedesmal recht hatte.

Ändert nix, als Entwickler ist man halt -sorry- der Arsch, oder "das 
Kamel, auf dem die Kaufleute reiten"!

So,
genug gejammert, Hautpsache die eigentliche Entwicklerarbeit macht 
Spass!

Deshalb mein Mitgefühl und mein Credo: "Wehrt euch! - anständig"

Gruss
Gunb

Sowas?

> Was an dem Satz war nicht zu verstehen?

Och, verstanden haben wir die gnadenlose Naivität schon, in der er 
offenbar geschrieben wurde.

>Kann ich nur zustimmen. Kein Pflichtenheft, was das Gerät können soll
>wurde "mal eben telefonisch" geklärt, 5 Monate später kommt noch ne
>größere Änderung, dazu Verwaltungschaos.

Da gäbe es noch die Unterscheidung zwischen Lasten- und Pflichtenheft.

Normalerweise erstellt das Produktmanagement das Lastenheft. Im 
Lastenheft stehen alle für's Produktmanagment wichtigen Eigenschaften 
des Produktes.

Der Entwickler schreibt als Antwort auf das Lastenheft das Pflichtenheft 
in dem er sich zur Umsetzung zu den aus dem Lastenheft gewünschten 
Eigenschaften "verpflichtet", die technisch auch machbar sind.

Eselsbrücke:

- Das Lastenheft ist dem Entwickler eine Last.
- Er antwortet darauf mit dem Pflichtenheft ( wenn er schlau ist, mit 
der kleinst möglichen Pflicht )

Wenn man mal von Produktion, Banken und Versicherungen absieht - viele 
Software ist gar nicht lange genug im Einsatz, als daß man das Gefühl 
bekäme, ein ordentliches Projekt hätte sich gelohnt.. Namche wird auch 
nie fertig und wieder verworfen.. :-)

Wenn schon wenig Doku, dann macht ein gutes Design (best things are 
always simple) - die Fehler am Projektanfang sind die teuersten in der 
Behebung.