Hoher Druck in Softwareentwicklungsabteilung

Ne, bei uns sagt der Chef: Lasst euch mal Zeit, arbeitet in eurem Tempo 
und macht euch bloß nicht kaputt.

In den meisten Fällen liegt es daran, dass keiner sagt: "Scheiße das 
dauert aber länger".

Derjenige der den Druck erzeugt, hat mit Sicherheit auch irgendeinen 
"Drückeberger" im Rücken und sehr oft ist in der Befehlshierarchie 
jemand der zwar bis drei (Stunden oder Euro) zählen kann, aber sonst von 
Tuten und Blasen keine Ahnung hat.

Aber langer Rede kurzer Sinn: Solange alle nur nicken, werden sich alle, 
in der Hierarchie oben stehenden wundern, warum das Projekt nicht in die 
Pötte kommt.

Amateur schrieb:

> Derjenige der den Druck erzeugt,

findet sogar gelegentlich, daß seine Entwicklungsabteilung völlig 
überflüssig ist, und die nur zum Schein tun, als wenn sie arbeiten, weil 
es am Markt angeblich schon alles entwickelt fertig gäbe. Am besten 
gratis.

Softi schrieb:
> geht es euch auch so dass bei den Entwicklung neuer Produkte
> (in meinem Fall Software) hoher Druck vom Chef ausgeübt wird ?
Leider: ja!
Wobei bei uns der Grund z.T. die Kunden sind, die unrealistische Termine 
fordern. Leider wird das von den Chefs meist auch nicht wirklich 
entschärft. Z.T. versuchen sie's, aber die Termine sind meistens fest. 
Wenn wir das nicht abnicken, wird halt zur Konkurrenz gegangen.
Aber dass man deshalb bei uns mehr Entwickler einstellen würde? 
Fehlanzeige.

Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die 
zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu 
programmieren, die aber nicht wirklich gefordet sind.
Auch wenn ich mir denke, dass das 100%ig noch kommen wird, mache ich es 
nicht, denn ich weiß, dass dann am Ende gar nichts fertig sein wird.

Wenn Umfang und Zeitschiene festgelegt sind, kann man leider nur an der 
Qualitätsschraube drehen. Da wird halt dann aus einem "Ist getestet, 
funktioniert!" eher mal ein "Nicht getestet, aber wird schon passen.".

Leider habe ich schon von vielen Entwicklern (nicht nur Software, auch 
Elektronik, Masch.bau usw.) in anderen Firmen Ähnliches gehört.
Da grenzt es natürlich an russischem Roulette, wenn man die Firma 
wechselt, um zu hoffen, es dort besser zu haben.

Auf jeden Fall muss das jeder selber für sich entscheiden. Nicht jeder 
kann bei so einer chaotischen Arbeitsweise und Terminen im Nacken noch 
ruhig schlafen. Kaputt machen lassen darf man sich jedenfalls nicht. Das 
ist kein Geld der Welt wert.

Ein gewisser Druck ist immer notwendig, das ist einfach eine Folge aus 
dem Parkinson-Gesetz. Wenn man keinen Druck aufbaut, dauert es einfach 
viel länger als es müsste. Der Trick ist, genau so viel Druck auszuüben, 
dass die Mitarbeiter effizient arbeiten aber dabei nicht ausbrennen. 
Ideal ist, wenn der Druck durch innere Motivation entsteht, sprich die 
Leute sind von sich aus motiviert, die knappen Termine zu halten. Habe 
selbst erlebt, wie eine eher träge Entwicklungsabteilung plötzlich 
aufblüht, weil die Leute durch einen besonderen Umstand und einen sehr 
engen Terminplan eine sehr hohe Motivation für ein bestimmtes Projekt 
entwickelt hat. Außerdem muss sich Druck und Entspannung abwechseln. Man 
kann durchaus ein Entwicklungsteam auch mal ein paar Wochen oder Monate 
vor sich hin bummeln lassen, damit die Akkus wieder aufgetankt werden. 
Arbeit wird ja in der Zeit immer noch erledigt.

bei Software gibt es immer Probleme, die man vorher meist nicht voraus 
gesehen hat. Teilweise dauert manchmal ein einzelner Step für den 1 Tag 
eingeplant war, auch mal eine Woche. Oder man braucht zur Behebung eines 
auf die Schnelle trivial aussehenden Bugs mehrere Stunden, obwohl man 
dachte, das wäre in 10-15 Minuten erledigt. Dann dem Projektleiter sowas 
jedes mal zu erzählen, ist oft unangenehm, der muss es dann seinem Chef 
oder dem Kunden erzählen, der dafür meist wenig Verständnis hat.

Dazu kommt, dass Individual Entwicklung extrem teuer ist, gerade wenn 
mit der Software nur sehr wenige Leute später arbeiten. Ein 
Entwicklertag kostet gerne mal 500 Euro (intern) und ein Projekt mit 300 
PTs ist jetzt nicht mal ein größeres.
Meist ist es bei der SW Entwicklung auch so, dass man selten Dinge 
entwickelt, die man schon sehr oft entwickelt hat, sonst würde man ja 
einfach eine Standardlösung benützen bzw. anpassen. Daher hat man meist 
sehr hohe Unsicherheitsfaktoren. Bei einem Hausbau ist das anders, da 
sind die Arbeitsschritte i.d.R. viel besser zu standardisieren.

Industriealisierung der SW Entwicklung ist an sich nichts verkehrtes, 
aber das Problem ist, dass manche Manager meinen, man könnte SW 
Entwickler quasi genauso entwickeln lassen, wie angelernte Bandarbeiter, 
wo jeder Schritt bis ins genauste durchgeplant ist (inkl. 
Spezifikation!!!!!). Dabei kann man viele industrielle Prozesse nicht 
mit SW Entwicklung vergleichen. Die reine Fertigung bei der SW 
Entwicklung übernimmt nämlich der Compiler.

Dazu kommt, dass Software nicht so sehr den riesen Wert zugesprochen 
wird. Viele meinen einfach, Software und sowas, das kostet doch alles 
nichts. Bei Anlagen, Autos und Maschinen wird da ganz anders gedacht. 
Insbesondere bei "Made in Germany".

>Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die
>zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu
>programmieren, die aber nicht wirklich gefordet sind.

Solches sollte eigentlich durch ein Pflichtenheft festgelegt sein.

Größere Projekte kann man einfach nicht nach dem Motto: "Nun macht mal" 
durchziehen.

An dieser Stelle kann auch Druck, etwas positives, das Projekt 
förderndes, sein.

Amateur schrieb:
> Solches sollte eigentlich durch ein Pflichtenheft festgelegt sein.

eben. Solche Dinge die nützlich aber nicht gefordert sind, nennt man ja 
auch gerne "goldene Henkel". Sowas würde ich niemals extra dazu 
einbauen. Dann lieber mehr Zeit dafür einsetzen, damit das was gefordert 
ist, wirklich zu 100% stimmt, inkl. Dokumentation, 
Installationsanleitung, ggf. Beschreibung für die Wartung, 
Bedingungsanleitung usw.

Dafür wird man bezahlt und das war auch gewollt. Solche nützlichen, aber 
nicht geforderten Dinge, kann man später immer noch als Change Request 
gut verkaufen und so sichert man sich ggf. Zusatzaufträge.

Ein Autohersteller baut ja auch nicht für Umsonst Extras in ein 
bestelltes Auto mit ein, die der Kunde gar nicht gefordert hat.

Am Ende sagt der Kunde vielleicht sogar "Ja ganz nett, brauchen wir aber 
gar nicht"

Marvin schrieb:
> Ein Autohersteller baut ja auch nicht für Umsonst Extras in ein
> bestelltes Auto mit ein, die der Kunde gar nicht gefordert hat.

Oh doch, genau das tut er! Ich habe z.B. einen Berganfahrassistenten und 
eine Scheinwerferreinigungsanlage, die ich gar nicht wollte.

> Am Ende sagt der Kunde vielleicht sogar "Ja ganz nett, brauchen wir aber
> gar nicht"

Exakt so ist es!

Dirk K. schrieb:
> Oh doch, genau das tut er! Ich habe z.B. einen Berganfahrassistenten und
> eine Scheinwerferreinigungsanlage, die ich gar nicht wollte.

Das glaube ich kaum. Diese Extras gehen garantiert mit in den 
Fahrzeugpreis ein. Und wenn du das nicht wolltest bzw. nicht wusstest, 
dann hast du dich vor dem Kauf nicht ausreichend informiert.

>Dazu kommt, dass Software nicht so sehr den riesen Wert zugesprochen wird. Viele 
meinen >einfach, Software und sowas, das kostet doch alles nichts. Bei Anlagen, 
Autos und Maschinen >wird da ganz anders gedacht


Das kenne ich hier in der Firma auch. Besonders von den mechanischen 
Entwicklerkollegen oder yprojektleitern. Die denken msnchmal, mit 
Software kann man alles korrigieren, auch wenn die Mechanik das 
überhaupt nicht unterstützt.

Ich schlage dann immer vor, die Elektrik komplett zu entfernen und alles 
rein mechanisch zu erledigen. Kurvenscheiben, Baudenzüge, etc. Wenn sie 
damit genauso flexibel sind, dann sollen die es doch machen.

Dem Chef sage ich dann immer, ich wäre schön froh, wenn die Software 
wenigstens als notwendiges Übel,  statt nur als Übel angesehen wird....

Ein großes Problem sehe ich darin, dass Software angeblich jeder Depp 
schreiben kann. Da hat der Nachbarjunge irgendetwas tolles gemacht.
Also kann es ja nicht so schwer sein.

http://www.amazon.de/Clean-Coder-Verhaltensregeln-professionelle-Programmierer/dp/3827331048/

Christian Berger schrieb:
> Ein
> Problem, dass in einer Sprache Bildschirmseiten an Code benötigt, kann
> in einer anderen Sprache in 5 Zeilen erledigt werden.

das muss aber nicht unbedingt was gutes heißen. Wie jemand schon sagte, 
geht oft viel Zeit für die Wartung drauf, insbesondere dann, wenn die 
Wartung von jemand anderem übernommen wird. In so einem Fall steigt man 
ggf. besser durch einen etwas längeren aber weniger komplexen Code 
durch, als durch einen sehr kurzen, hoch eleganten Code, wo sich jemand 
4 mal das Gehirn hat verbogen. Das ist natürlich nicht immer so und 
kommt auf den Einzelfall darauf an. Manchmal ist so eine Lösung z.B. aus 
Performance Gründen notwendig. Manchmal leidet auch sowas wie die 
Trennung von Zuständigkeiten in einem sehr kurzen Code. Vieles kann man 
z.B. ohne saubere Schichtentrennung etc. in sehr kurzem Code lösen, aber 
dann leidet manchmal die Wartbarkeit. Z.B. GUI Coding, Anwendungscoding 
und Datenhaltung alles in einer Routine. Im Einzelfall, gerade für 
triviale Anwendungen mag das noch Sinn machen, nicht aber für große 
Anwendungen.

genervt schrieb:
> http://www.amazon.de/Clean-Coder-Verhaltensregeln-...

Und was soll das bringen? Ich denke nicht das man bei entsprechendem 
Druck noch die Zeit für CCD findet.

Das ist das gleiche wie agile Entwicklungsmethoden, natürlich hat sowas 
langfristig vorteile für die Firma, aber die meisten denken ja nur bis 
zum Ende der Woche.

Bei solchen Dingen muss die Firma voll dahinter stehen und ich glaube 
nicht dass das bei einer Firma die schon so einen enormen Druck aufbaut 
der Fall sein wird.

FZ schrieb:
> Bei solchen Dingen muss die Firma voll dahinter stehen und ich glaube
> nicht dass das bei einer Firma die schon so einen enormen Druck aufbaut
> der Fall sein wird.
Das ist in reinen Softwarefirmen der Fall und deshalb arbeite ich auch 
nur noch selten für Firmen die Software als kostenintensiver Ballast 
ansehen, dementsprechend wird dort auch entwickelt, besser gesagt 
gefrickelt.
Dort bist du als Softwaremensch in einem unternehmen das damit nicht 
sein Geld verdient immer der Arsch. Zeitgemässe Entwicklungsmethoden 
kannst du nicht einführen, weil "das nur Geld kostet und keine schnellen 
Ergebnisse bringt", denn nur das zählt dort wo der Controller das sagen 
hat, dann kommt halt nur Scheisse bei raus, das geht aber nicht in deren 
minderbemittelten Erbsenzählerhohlschädel die nur ein Jahr voraus 
"denken" können.
Die letzte Bude wo noch nach Gutsherren Art entwickelt wurde, war ich 
ein Tag, dann hatte ich die Schnauze voll von solchen Firmen, wo wieder 
so ein BWL-Hans Wurst dir erklären will wie du Software zu entwickeln 
hast, welche Tools du nutzen darfts, von denen er gar nicht weiss wozu 
die gut sind. Allein schon die Arbeitsplätze die man zugewiesen bekommt: 
die übelste Kammer auf dem ganzen Stockwerk, mit dem ältesten Rechner 
und daraus soll man Spitzensoftware rauszaubern. Das ist wie wenn ein 
Sternekoch in einer Teeküche 200 Essen raushauen soll, auf Sterneniveau.

FZ schrieb:
> genervt schrieb:
>> http://www.amazon.de/Clean-Coder-Verhaltensregeln-...
>
> Und was soll das bringen? Ich denke nicht das man bei entsprechendem
> Druck noch die Zeit für CCD findet.

Nicht verwechseln mit:

http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1393492473&sr=8-1&keywords=clean+code

>Andererseits musst du ja irgendwann irgendwie mal beweisen, dass deine
>besseren Methoden insgesamt auch WIRKLICH besser und preiswerter sind!
>Dumm ist nur, wenn man das erst nach Jahren kann, wenn sie die
>Anlaufkosten und der Einführungsaufwand vorbei sind.

Gute Beispiele gibt es hier auch.

Im Herbst letzten Jahres bekamen ein Kollege und ich eine SW 
überbeholfen. Macht mal schnell fertig. Ich habe nach Analyse des Codes 
und viel Flucherei vorgeschlagen, das neu zu schreiben. Angegeben habe 
ich 5-6Mann-Monate. Danach hätten wir, so argumentierte ich, eine 
saubere neue SW, wo die aktuellen Kernprobleme behoben sind (paar Zeilen 
anzupassen, reichte nicht, weil das Grundkonzept nocht passte, und somit 
wenn man eine Stelle anfasste, hundert andere sofort an der Backe 
hatte), die Visu so aussehen würde, wie alle anderen Maschinen 
(corporate identity heisst das wohl). Somit könnte jeder unserer 
Monteure das auch handeln und nicht nur zwei drei die es kennen. 
WEiterhin wären viele Anforderungen nicht dazu gebastelt, sondern im 
Konzept berücksichtigt, etc. Wollte man nicht. Der Kollege wird diese 
5-6Mann-Monate bald verbracuht haben. Ergebnis: Viele Flicks und ein 
beruhigter Kunde. Aber nicht besonders zufrieden. Kein einheitliches 
(Visu)Design, schlecht wartbar, da (gegenüber den anderen Maschinenpark) 
völlig anders, etc...

Anderes Beispiel ein selbstgeschriebenes PC-Tool. Das ist damals mit den 
Anforderungen gewachsen. Soweit ist das so. Es würde übernommen und mal 
schnell noch ein zwei Funktionen zu ergänzen. Ich habe dem, der es 
machen sollte, gesagt, schreib es neu. Wir wissen jetzt was es werden 
soll. Zumindest er sieht es mittlerweile ein. Auch dort, ungeeignete 
Tools. Die Entwicklungsumgebung ist ein Misch aus Borland und was weiss 
ich noch alles. zB hat ein riesen Aufwand mit UnicodeStrings. Ich sagte 
damal VisualStudio. System::String und fertig...

Aber naja, die Chefs verstehen sowas nicht. Und im Nachhinein ist man 
immer schlauer, aber selten klüger...

Matthias Lipinsky schrieb:
> Macht mal schnell fertig.

Wenn solche Sätze zum Projektmotto werden, kann es nur schief gehen. Es 
wird in Pfusch, Hektik und Mehrarbeit enden.

Es gibt einfach zu viele Projektkasper, die dem Kunden das blau von 
Himmel versprechen ohne Rücksprache mit den Leuten zu halten, die es 
ausbaden müssen!

Es gibt drei Möglichkeiten:

1) Man bekommt den Projektkasper zum Projektmanager erzogen.
2) Man bekommt Projektkasper gegangen.
3) Man geht selbst.

Leave it, love it or change it!

genervt schrieb:
> Wenn solche Sätze zum Projektmotto werden, kann es nur schief gehen. Es
> wird in Pfusch, Hektik und Mehrarbeit enden.

So läuft es gefühlt bei 99.99% aller Firmen ab, man versucht natürlich 
es dennoch so strukturiert wie möglich zu machen.

Wer es dann auf die Spitze treibt wie bei großen Konzernen wo alles 
irgendwo registriert sein muss beschäftigt dann einen Rattenschwanz an 
Leute die nur mit der Verwaltung beschäftigt sind - und raus kommt dann 
erst recht so etwas wie z.B bei Intel und AMD … Projektverzögerung, 
Rückrufe usw.


Leider kann nicht jeder so eine tolle Stelle wie Mehdorn beim Flughafen 
BER haben wo man sich keine Gedanken machen muss dass das Staatsgeld 
irgendwann mal ausgeht.

>wie Mehdorn beim Flughafen

Der hat die Stelle doch nur bekommen, weil er sich mit Verspätungen 
bestens auskennt ;-)

Auf Termine, die ich nicht bestaetigt habe, aber eingehalten werden 
sollen, sag ich jeweils : ja, ich schaue. Dabei ist mir voellig egal ob 
ueberzogen wird.
Und wenn ich einen Termin bestaetigen soll, sage ich : ich schaue. Wir 
haben diese Unabwaegbarkeiten, die wir unterwegs erst abschaetzen 
koennen....
Wenn mich einer ersetzen will : Ok. Sofort. Macht mal.

Das habe ich auch schon erlebt, dass SW-Entwickler sich unentbehrlich 
machen indem es keine Doku gibt und wenn man es nachvollziehen will, 
müsste man an etlichen Schrauben ziehen (VHDL+Code). Eigentlich am 
besten neu schreiben...

Wegen jeden Müll kann man dann nachfragen. Teilweise weiß dieser dann 
aber auch nicht so recht.
"Probier mal..."
"Aja, wenn man das einstellt, dann kann das meine SW nicht"

Blutdruck++;

Softwerker schrieb:

> Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die
> zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu
> programmieren, die aber nicht wirklich gefordet sind.

Ganz genau DAS ist der Grund, warum viele Softwareentwickler nicht mir 
ihrer Arbeit fertig werden. Sie denken, die seien kreativ, wollen selber 
mitentscheiden, was in die SW rein soll und bauen an der Funktion mit, 
wovon sie aber besser die Finger lassen sollten. Zudem konzeptionieren 
sie damit während der Umsetzung und designen hin und her. Das ist das 
typische Gehacke, was viele veranstalten.

Klare Vorgaben und harte Termine sind die einzige Möglichkeit, die 
Kostem für die SW-Entwicklung gering zu halten. Lässt man den Softies 
freie Hand, bauen sie, was sie Lust haben, aber keiner gebrauchen kann, 
ausser ihnen selber keiner bedienen kann und vor allem keiner bezahlt!!

Wenn SW-Leute "Ideen" zu Funktionen haben, sollten sie sie formulieren 
und mitsamt einem Termin- und Kostenentwurf nach oben kommunizieren. Der 
Projektleiter entscheidet dann mit dem Kunden, ob es rein kommt und 
wann. Ansonsten ist weder eine gesteuerte Projekt- noch Terminplanung 
möglich und Teamwork klappt schon garnicht, wenn die Ziele, auch die 
alle gleichzeitig zuarbeiten müssen, 100% klar sind.

Jürgen N.N. schrieb:
> Klare Vorgaben


Ja. Toll. Ich bin nun schon seit 30 Jahren im Business und bin immer 
noch weit davon entfernt alle Eventualitaeten vorherzusehen und zu 
spezifizieren. Ich bin zwar um Groessenordnungen besser als vor Dekaden, 
es fehlt aber immer ein Stueck.

Jürgen N.N. schrieb:
> Klare Vorgaben

Die gibt es vielleicht im Disneyland, aber nicht in der Realität!
Requirements kommen erstens immer viel zu spät und zweites ändern sie 
sich dann noch mindesten drei mal.

Jubi schrieb:
> Die gibt es vielleicht im Disneyland, aber nicht in der Realität!
> Requirements kommen erstens immer viel zu spät und zweites ändern sie
> sich dann noch mindesten drei mal.

ja eben, nicht nur das. Oft merkt man erst in der Realisierung, dass 
etwas doch anders gemacht werden muss oder das Unklarheiten noch drin 
sind.

Oft ist es halt in der Entwicklung so, dass man manchmal Probleme hat, 
wo man stundenlang debuggen muss und plötzlich macht es klick und es ist 
nur irgendwo ein Flag was man anders setzen muss, damit es geht. Quasi 
Arbeit eine Sekunde, aber Vorarbeit Stunden. Sowas dann an einen nicht 
so technisch-affinen PL heran zutragen ist dann halt nicht immer leicht.
Von wegen "wie Sie haben 3 Stunden für das umsetzen eines Flags 
gebraucht?"

>Von wegen "wie Sie haben 3 Stunden für das umsetzen eines Flags gebraucht

Ich hab auch schon mal die Aussage "Die zehn Zeilen sind doch schnell 
getippt", gehört,  als ein Kollege, der die SW getreut, krank war. Der 
Vergleich zielte wohl auf eine Sekretärin mit zehn Finger Suchsystem ab. 
Aber das diese nur abtippt oder nachtippt und der Softie darüber 
nachdenken muss, war nicht zu vermitteln...

Die letzt geposteten Beiträge über mir widerlegen nicht meine Forderung 
nach klaren Vorgaben.

Zum einen sind Funktionen und Umsetzung zu trennen und selbstredend sind 
theoretisch jederzeit Funktionsänderungen denkbar, wenn der Kunde, die 
GL oder die IB das möchte. Aber dennoch muss sie klar definiert und 
eingeflochten werden und JA, DAS GEHT! Das geht genau dann, wenn es eine 
klare Doku und eine gemeinsame DB gibt, in welche die Ideen und 
Änderungen einfliessen. Und es geht genau dann, wenn eben nicht die 
Entwickler von unten die Funktionen beim Bauen ändern, weil eben 
Funktion und Art der Umsetzung getrennt werden. Es ging ja um den 
Einwand, dass nichtgeforderte Funktionen auch nicht eingebaut werden.

Wichtig ist, dass die Entscheider über die Funktionen die Übersicht über 
die Kosten und Zeiten haben und das haben sie nur, wenn sie selber mal 
Entwickler waren und die Entwickler in der Lage sind, ihnen die Infos zu 
geben - insbesondere genau dann, wenn sich was tut, während der 
Umsetzung.

Das erfordert alllerdings eine exakte Projektverfolgung, sodass 
Projektleiter UND Entwickler mit der Zeit lernen, wann was wieviel Zeit 
dauert und welche Kosten verursacht - z.B. was Test der vielen von 
Hackern reingestopften Funktionen angeht.

Und ja, es geht!

Das Problem ist nur, dass es nicht gemacht wird und Entwickler jahrelang 
im Chaos entwickeln, nichts dokumentieren und keinerlei Lerneffekt in 
der Beurteilung der eigenen Geschwindigkeiten und der Komplexitäten 
haben. Hier haben wir ein Beispiel:

>Ja. Toll. Ich bin nun schon seit 30 Jahren im Business und bin immer
>noch weit davon entfernt alle Eventualitaeten vorherzusehen und zu
>spezifizieren.
10 Jahre sollten reichen, das weitgehend zu erlernen.

Aber die meisten machen es wie gesagt nicht, stagnieren also.  Werden 
diese dann Projektleiter, haben wir die stets unterschätzten Projekte 
und den hohen Druck,um den es in diesem Thema geht.

Viele Entwickler machen sich kein Bild, dass die 200 Zeilen Code, die 
sie für eine Funktione reintippen, nur 15%...20% der Arbeit sind. Den 
Planungsanteil, den Koordinationsanteil, den Test- und 
Verifikationsanteil überschauen und berücksichtigen sie oft nicht. Und: 
Sie kommunizieren ihn nicht. Da sie ihn auch nicht dokumentieren, hat 
die PL auch keine Chance, das zu erkennen.

Und damit bleibt es bei der altem Situation, dass sicher 80%-90% der 
gesamten Entwicklung in der SW (und auch HW?) chaotisch und impulsiv 
erfolgt.

> Kennst Du irgendeine Firma die es tatsächlich
> schafft, die Vorgaben (also Requirements) an die Software klar,
> vollständig, fehlerfrei und in sich konsistent zu halten?
Ich kenne einige, die sich darum bemühen. Dort, wo es nicht klappt, ist 
es Aufgabe der Entwickler, die REQs einzufordern.

Falk Brunner schrieb:
> Vor allem ist die Logik der meisten Poster unlogisch. Weil man keine
> Perfekten Requirements aufschreiben kann, lässt man es gleich ganz
> bleiben? Hä?
Unverständlicherweise begegnet einem diese "Logik" an jeder Ecke. Die 
haben wir auch in der Firma. Es ist sozusagen die erste reflexartige 
Antwort "... man kann nie alles festlegen, weil sich immer was ändert". 
Dabei ändert "sich" nie etwas. Keine Anforderung tauscht sich selber 
weg.

Es sind immer Personen, die Informationen in das System eintreiben und 
irgendwas geändert haben wollen. Meistens sind es denk- und arbeitsfaule 
Personen, die keine Lust haben, sich hinzusetzen und etwas zu 100% 
hinzuschreiben und vorher entsprechend zu denken. Sie hauen lieber 
schnell ein Powerpoint raus und schicken 20 Änderungen hinterher, statt 
sich - wie früher die Schriftsteller zu Schreibmaschinenzeiten - einen 
Satz vorher zu überlegen und ihn dann zu Papier zu bringen.


> Je komplexer das Projekt, umso nötiger ist eine möglichst klare,
> systematische Vorgehensweise. Dass die nie perfekt sein wird ist dabei
> nicht schlimm. Schlimm ist das Rumwurschteln und die Lernresistenz!
100% d'accord!

> Ein Fehler machen ist das eine, ihn mehrfach zu wiederholen ist das
Es geht eigentlich garnicht um die Fehler, die man sich scheut 
hinzuschreiben. Sondern es geht darum, sie hingeschrieben zu haben und 
bei deren Korrektur auch die Änderungen in die Tiefe treiben zu können. 
Dazu müssen vorher die Abhängigkeiten auch definiert worden sein. Wenn 
man das immer macht, geht das auch rasch von der Hand. Zudem werden 
Änderungen und deren Auswirkungen evident und dann auch oft unterlassen, 
so wie die schnell reingestreuten Verbesserungen aus dem PM.

Der Fehler der gemacht wird, ist, aus Angst vor unnötiger Arbeit, die 
Sache nicht sauber zu dokumentieren und Konzepte zu Ende zu formulieren 
und damit alles in die Tiefe zu treiben, weil man sich eine schlampige 
Daueränderungstechnik angewöhnt hat.

Richtig dagegen wäre, mehr zu denken, mehr zu planen und dann 
zielführender in die Tiefe zu gehen, damit das gesamte Team besser zu 
steuern ist.

Bei einer Maschine muss auch alles exakt mit einander verbunden sein, 
damit Steuerimpulse zu jederzeit erfolgen und Änderungen der Richtung 
möglich sind. Und: Es muss bekannt sein.

Meistens ist es aber so, dass einige voranrennen, indirek etwas 
festlegen und dann versuchen, es zusammenzubringen. Und dann haben wir 
sie: Die sich selbst installierenden und unaufgefordert auftauchenden 
Änderungen, die keiner vorhersehen konnte.

Ein ungesteuertes waberndes System!

Und wenn Leute das nicht konsequent erlernt haben, nach Requirements zu 
arbeiten, kriegen sie es aus dem Stand auch nicht hin. Und dann 
bestätigt sich für sie, dass es so "länger und umständlicher" ist.

Das Fehlen an Planung und Requirements ist aber selten ein alleiniger 
Fehler der Entwickler:

- Es werden Requirements vom Kunden akzeptiert (oder aus historischen 
Gründen mitgeschleppt) die technisch nicht sinnvoll realisierbar sind
- Es werden Termine den Kunden versprochen ohne das überhaupt die 
Requirements des Kunden klar erfasst sind
- Nicht selten setzen auch PM darauf als erstes bei Doku zu sparen wenn 
der Terminplan knapp ust

Nur so als Beispiele...

Bei mir herrscht ständig Unterdruck. Ihr müsst was falsch machen.

topstory schrieb:
> Bei mir herrscht ständig Unterdruck. Ihr müsst was falsch machen.

Bist du vielleicht im Arbeitnehmer-Disneyland? Das wäre eine Erklärung.

Druck habe ich nur auf´m Pott.

Ganz ehrlich: "Druck" gehört doch dazu, das sollte man einfach nicht so 
ernst nehmen. Viele Dinge im (Berufs-)leben kann man relativ einfach 
durchschauen, gerade auch zwischenmenschliche Verhaltensweisen.

So lebt es sich recht entspannt.

also ehrlich:

Entweder hier empfinden einige normale Arbeit, als Überlastung oder sie 
sind in einer XXX-Firma. Ich kenne keinen SW-Entwickler, der sich kaputt 
macht. Von einigen japanischen Firmen in Deutschland hört man seltsame 
Sachen, aber deren Problem ist, dass sie nur billige Dödelprogrammierer 
einstellen, die so arbeiten, wie oben angedeutet und dann ständig am 
Wühlen sind und ihre Arbeit nicht fertig kriegen ("siehe 3h suchen am 
flag"). Die Sorte hat dann logischwerweise Druck.

Ich für meinen Teil haben keinen Druck. Ich arbeite azyklisch zu den 
anderen Kollegen, die meistens schon um 7.00 auf der Arbeit sind, damit 
sie sich gegen 16.00 in den Feierabendverkehr stürzen können :-)

Den Stress spare ich mir und fahre frühestens um 8.30 morgens los, wenn 
der grosse Schwung der Karossen schon durch ist und trudele nicht vor 
9.00 im Büro ein. Statt 20min Strafzeit im Stadtverkehr, die meine 
Kollegen, die 2h früher anrücken, auf den letzten Zufahrtstrassen von 
der BAB zur Firma brauchen, sause ich in weniger als 10min durch und 
spare täglich 20min. Dann lasse ich noch das "2. Frühstück" ausfallen 
und bin wieder 30min näher dran. Ich verschwinde dann frühestens um 
18.00, meistens um 19.00 und bin dann ruckzucki daheim. Weniger Benzin, 
weniger Stress und vor allem keine Morgenhektik und 2 erholsame leise 
Stunden abends, mit leerem Büro und herrlichen Surfmöglichkeiten.

Ich habe nur das Zeitfenster zwischen 14.00 und 16.00, wo ích voll 
ranklotzen muss, ansonsten ist lockeres Kaffetrinken und warten auf den 
Compiler angesagt.

Wer sich Stress und Druck machen lässt, hat den falschen Job.

>und warten auf den Compiler angesagt.


Wenn das machst du während dieser Zeit Wartung.

Mh also bei uns in der Firma scheint jeder (inkl. mir) ziemlich 
entspannt. Ja zu Milestones oder ähnlichen Terminen wirds mal weng 
stressiger und ein paar Überstunden fallen an, aber die landen auf dem 
Gleitzeitkonto und werden abgebummelt.
Ich selber bin in einem 7-Kopf Team und wir arbeiten nach Scrum an einem 
mehrjährigen ~100-Mann Projekt für einen Kunden. Funktioniert meiner 
Meinung nach wunderbar. Ich bin zufrienden, die Kollegen sind zufrieden, 
der Projektleiter ist zufrieden, der Chef ist zufrieden und der Kunde 
ist zufrieden. Gefühlt würde ich sagen, dass Scrum auf den ersten Blick 
schon etwas teurer ist als "klassische" Entwicklung. Andererseits, für 
jeden ist transparent an was gerade gearbeitet wird und das an nichts 
rumgenudelt wird was nicht vereinbart war. Wir arbeiten in 3 Wochen 
Sprints und die sehen in etwa so aus:

1. Woche:

- reine Abarbeitungszeit der User Stories (Arbeitspakete)
- keine planmäßigen Meetings bzgl. Scrum, Meetings nur nötig wenn sich 
mit den Projektarchitekten abgestimmt werden muss

2. Woche:

- Mittwoch 2 Stunden Grooming, dort gehen wir das Product Back Log durch 
in dem die User Stories festgehalten sind, was der Kunde sich in den 
nächsten Wochen so wünscht. Unklar spezifizierte Beschreibungen oder 
Akzeptanzkriterien klärt unser Projektleiter. Darüberhinaus haben wir 
Entwickler immer den Überblick was demnächst so kommt. Jeder Entwickler 
bekommt 1-2 Arbeitspakete zugewiesen (je nach Komplexität), die er 
schonmal grob vorplant wie man diese lösen könnte sobald der 
Projektleiter die Unklarheiten beseitigt hat. Zeitaufwand dafür 1-2h.

- Restliche Zeit ist wieder reine Abarbeitungszeit

- Freitags holt der Integrator den Main-Branch für eine Forward 
Integration um unseren Team-Branch auf den neuesten Stand zu bringen und 
für eine Reverse Integration am Montag vorzubereiten. Das geht manchmal 
zügig und manchmal ist es ein ewiges gemerge, jenachdem wieviel 
Reibungspunkte man mit anderen Teams und deren Bundles hatte.

3. Woche:

- Montags ist die Reverse Integration in der unsere Arbeit in den 
Main-Branch integriert wird. Während unser Integrator das erledigt, 
zieht der Rest die EA-Diagramme / Dokumentation unserer Arbeit auf einen 
aktuellen Stand

- Dienstag ist Abnahmemeeting, das dauert normalerweise nen halben Tag. 
Dort gehen wir mit dem Kunden Paket für Paket durch und lassen ihn die 
Ergebnisse anhand der Akzeptanzkriteren verifizieren und abnehmen.

- Mittwoch 1-2h Retrospektive Meeting, dort diskutieren wir teamintern 
was gut und was schlecht lief im letzten Sprint und wo man was 
verbessern kann.
Danach machen wir noch mittwochs unser Planungsmeeting, welches 
üblicherweise 5-6h geht. Dort werden die Vorplanungen der einzelnen 
Pakete vorgestellt und in einzelne Tasks überführt, darüberhinaus wird 
die Komplexität / der Zeitaufwand für jedes Paket geschätzt und 
anhanddessen treffen wir die Zusagen für den Kunden was möglich ist 
abzuarbeiten. Am Ende weiß jeder im Team was zu tun ist und prinzipiell 
auch wie, d.h. Krankheit eines Kollegen etc. fällt kaum ins Gewicht. 
Nicht eingecheckter Code landet am Ende des Tages in einem Shelveset, 
welches sich ein anderer reinziehen kann.

- Ab Do wieder Abarbeitung der Pakete

Es gibt projektweite Coding-Guidelines und teamintern halten wir uns an 
Clean-Code. Code darf in unserem Umfeld nur nach einem 4-Eye Review 
eingecheckt werden, Hazard-relevanter Code nur nach einem 6-Eye Review.

So läuft es in dem Team in dem ich arbeite. Nicht jedes Team in unserer 
Firma kann agil arbeiten (hängt immer vom Kunden etc. ab), der 
Grundtenor wenn man sich am Mittagstisch austauscht ist jedoch, dass es 
in agilen Teams meist kontrollierter und fokussierter abläuft als in den 
nicht-agilen.

Für mich persönlich kann ich nur sagen, dass die Meetings manchmal 
nerven aber andererseits erfüllen sie ihren Zweck und kosten nicht 
sinnlose Zeit. Ansonsten kann ich über meine tägliche Arbeit nichts 
negatives berichten. Meine Firma ist ein reines Softwarehaus (KMU ~200 
Mann, Mitarbeiter-AG) und wir wickeln halt Kundenprojekte ab. Ich finds 
ganz nett, da man so die Möglichkeit hat in unterschiedliche 
Technologien abzutauchen wenn man was frisches machen will, da wir 
Know-How-bezogen breit aufgestellt sind, Themenwechsel sind meist kein 
Problem.

Was ich hier manchmal über Softwareentwickler/-ung lese würde mir angst 
und bange machen. Das fiele für mich in den Bereich Folter und 
unprofessionelle Fricklerei. Hängt wohl wirklich stark davon ab, wie die 
Software im Gesamtkontext eines Produkts eingeordnet wird.

Matthias Lipinsky schrieb:
>>und warten auf den Compiler angesagt.
>
> Wenn das machst du während dieser Zeit Wartung.

Komisch sein Satz Deiner. Deutsch schreiben können Du?


D. I. schrieb:
> Hängt wohl wirklich stark davon ab, wie die
> Software im Gesamtkontext eines Produkts eingeordnet wird.

Das glaube ich aber auch. In kleinen Softwareklitschen, die Aufträge 
abarbeiten, schlägt die Zeit voll durch. Ist die SW nur eine kleine 
Teilkomponente und macht nicht viel aus, kann man sich Bummelei leisten. 
Komischerweise wird aber dort eher noch linear gearbeitet, als in der 
Dienstleisterklitsche, die drücken und nur das Nötigste machen.

>Matthias Lipinsky schrieb:
>und warten auf den Compiler angesagt.
>Wenn das machst du während dieser Zeit >Wartung
>>Komisch sein Satz Deiner. Deutsch >>schreiben können Du?

Beruhige dich mal. ich hasse diese pseudointelligenz von auto 
vervollständigen. ....

der Satz soll heißen:

wenn dann machst du während dieser Zeit Wartung. ..

Matthias Lipinsky schrieb:
> wenn dann machst du während dieser Zeit Wartung. ..

Wenn Du richtig schreiben würdest, könnte man den Satz auch mit einem 
kleinen Vertipper noch lessen. Ich hätte ihn auch nicht verstanden...

-> wenn - dann machtest Du während dieser Zeit Wartung

wäre korrekt gewesen.

>machtest

Ok. Wieder ein neues Wort gelernt.

Matthias Lipinsky schrieb:
>>machtest
>
> Ok. Wieder ein neues Wort gelernt.
Gerne doch. Für alle jene, die des gehobenen Deutschen weniger kundig 
sind:

"Machtest" ist die etwas elegantere Form von "würdest machen", welche 
alternativ Verwendung hätte finden können, die aus inhaltlichen Gründen 
an dieser Stelle aber eher "würdest gemacht haben" zu verwenden gewesen 
waäre, weil im obigen Satzzusammenhang formell und inhaltlich ja der 
Konjunktiv, also eine Möglichkeitsform der Tenor ist.

>kommt das von Gemächt?

Bildung kommt auch nicht vom Lesen. Dann hieße es Buchung. Bildung kommt 
von Einbildung.

als ich neu in der firma war, hab ich die stresserei auch viel zu ernst 
genommen.
"wenn fehler xy nicht heute gefixt wird, steht morgen der ganze betrieb"
"feature xy muss bis morgen drinnen sein, sonst müssen wir pönale 
zahlen"
...
und meine antwort war "ja klar, das ist machbar, ja klar, das mach ich 
schon, ..."

irgendwann war der punkt erreicht, an dem ich wirklich viel fachwissen 
hatte, und in einigen wichtigen codeteilen der einzige war, der wirklich 
durchsteigt.
ich hab gesehen, dass ich mit meinem jetzigen fachwissen locker einen 
anderen job bekommen würde.

und seitdem ist mir das gerede relativ egal. die chefs und projektleiter 
sind doch ohnehin auf uns entwickler angewiesen.
wenn jetzt wer herkommt und sagt er braucht aufgabe xy, so zeige ich ihm 
meine derzeitigen aufgaben, und sage ihm wann ich mit dem feature 
anfangen kann. meistens frühestens eine woche später.
dann sind sie erstmal ganz nervös, weil der kunde das ja schon so 
dringend braucht.
meine antwort: "kannst ja mit dem chef reden ob ich die aufgabe 
vorziehen soll, nur dann bleibt halt die derzeitige aufgabe liegen". das 
wars dann meist auch schon, weil die aufgabe eh nicht so wichtig ist.
und wenn ich es dann 2 wochen später abgebe, so ist es 
interessanterweise meist eh gar nicht so wichtig gewesen. "von was 
redest du? ah, von der aufgabe. ja, das ist jetzt eh nicht so kritisch".


also mein tipp:
1. schau dass du fachlich gut bist
2. schau dass du know how hast, dass dich auch für andere firmen 
interessant macht
3. merk dir, dass projektleiter und chefs ohne dich nicht können
4. erklär ihnen deinen terminplan, und dass du für ihre aufgabe erst am 
tag xy zeit haben wirst, sie aber mit dem chef gerne eine 
terminverschiebung besprechen können
5. interessante aufgaben kannst du natürlich sofort nach vorne schieben