mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Kollege kommentiert Doku-Entwurf nicht


Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal ne blöde Frage.

Nicht zum ersten Mal macht mir der Kollege die Kommentierung nicht 
fertig.

Ist ca. 2 Stunden Arbeit, ein richtiger Endtermin existiert so nicht. 
Der steht ca. 3 Jahre vor der Rente, das Verhältnis ist an sich ganz 
gut.

Mehrmalige Nachfragen bisher ohne Erfolg (6 Wochen lang). Bin Externer, 
der Gruppenleiter hat andere Sorgen (er hält fast keinen Termin ein).

Ich weiss doch wie es ist, hinterher heißt es nur, Du hast zu wenig 
Output gebracht (geliefert).

Gruppenmeetings gibt's nicht  (bzw. eins kurz nach Nikolaus). Ach so das 
ist ein bundeseigenes Unternehmen (Energie).

Also was ist zu tun?

Autor: Claus M. (energy)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Was für ne Kommentierung?

Autor: Juergen P. (optronik)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dokumentenhistorie/Versionierung einfügen.
Z.B. v0.x / 1. Aug. 2016 - Doku zur Kommentierung bereitgestellt
v0.x / 15. Sept- 2016 - Kommentierte Version zurückerhalten
v1.0 / 16. Sept- 2016 - Korrigierte Version auf Basis Kommentierung v. 
Herr XY


Dann ist zumindest klar wer was wie lange gemacht hat...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wer ist derjenige, der die Bezahlung Deiner Rechnung freigibt?
Denjenigen musst Du davon vorzugsweise schriftlich in Kenntnis setzen, 
dass Du bei der Durchführung Deiner Arbeiten behindert wirst und daraus 
ein Projektverzug droht. So etwas solltest Du als reine Feststellung 
formulieren und nicht als Drohung Deinerseits.

Du solltest aber auf keinen Fall Dir selbst ins Knie schießen und 
behaupten, dass Du ohne die Kommentierung nicht weiterarbeiten könntest! 
Denn solch eine Aussage würde bedeuten, dass Dich Dein Kunde für die 
Zeit bis zur Zustellung der Kommentierung nicht bezahlen müsste, denn 
schließlich kündigst Du ja selbst Deine Untätigkeit an.

Man muss bei so etwas ggf. ganz formell vorgehen. Es kommt nicht darauf 
an, dass Du üblicherweise Deinem Gruppenleiter den Stundenzettel oder 
die Rechnung in die Hand drückst, sondern wer der 
Kostenstellenverantwortliche ist. Wessen Unterschrift steht auf der 
Beauftragung?

Falls jedoch nicht Du, sondern ein Projektvermittler o.ä. der 
Vertragspartner des Kunden sein sollte, solltest Du mit ihm 
diesbezüglich Rücksprache halten. Er wird wesentlich genauer wissen, 
welches die relevanten Entscheidungsträger sind.

In keinem Fall solltest Du aber davon ausgehen, dass Du die 
Kommentierung zügiger erhalten wirst, sondern es geht bei den obigen 
Maßnahmen ausschließlich darum, ggf. gerichtsfest nachzuweisen, dass Du 
drohenden Verzug den Verantwortlichen gemeldet hast, um eine 
Schadensbegrenzung für den Kunden zu vermeiden und sowohl Deine 
Honorarforderung abzusichern und eine Schadensersatzforderung Deines 
Kunden zu vermeiden.

: Bearbeitet durch User
Autor: Zitronen Falter (jetztnicht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ein Verzicht der Kommentierung bedeutet doch : Angenommen !

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh D. schrieb:
> Ein Verzicht der Kommentierung bedeutet doch : Angenommen !

Das bedeutet es keineswegs. Zum einen kann es durchaus die Anweisung 
eines Entscheidungsträgers gegeben haben, dass die Spezifikation nur 
nach erfolgter Kommentierung verwendet werden dürfe, und zum anderen 
muss der TE ggf. auf den Verzug hinweisen. Sofern also nicht 
ausdrücklich vereinbart wurde, dass er auf der nicht-kommentierten 
Version arbeiten dürfe, sieht es für ihn schlecht aus. Und wie schon 
angedeutet, kann es im Extremfall sogar bedeuten, dass seine Arbeit 
nicht abgenommen bzw. bezahlt wird.

Autor: externer Projektleiter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Um was für ein Dokument geht es überhaupt? Wieso bist Du als Externer 
für Inhalte zuständig?

Normal wäre, dass man Dir sagt, wann was fertig zu sein hat und was es 
zu tun gibt und da ist der Verzug durch einen Internen nicht Dein 
Problem.

So eine komische Verstrickung darf es bei Externen gar nicht geben, weil 
Du eine abgegrenzte Arbeit abliefern (können) musst! Der Herr ist also 
auch nicht Dein Kollege!

Ansonsten gibt es das nur, wenn Du ein externer Projektleiter bist und 
dann machst Du die Termine!

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
externer Projektleiter schrieb:
> So eine komische Verstrickung darf es bei Externen gar nicht geben, weil
> Du eine abgegrenzte Arbeit abliefern (können) musst!

Das gilt nur bei Werkverträgen, nicht aber bei Arbeitnehmerüberlassung.

Autor: Jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danilo schrieb:
> Hab mal ne blöde Frage.
>
> Nicht zum ersten Mal macht mir der Kollege die Kommentierung nicht
> fertig.
>
> Ist ca. 2 Stunden Arbeit, ein richtiger Endtermin existiert so nicht.

Vielleicht

- ist der Entwurf inhaltlich so unsagbarer Mist, dass es das erfahrene 
Projektmitglied schon bei dem Gedanken daran ihn lesen zu müssen graut?

- ist das Dokument schlecht lesbar, unverständlich, 
verschwurbelt-angeberisch gechrieben, mit Berater-BWL-Sprech aufgepimpt 
und in Neusprech-Zuckerguss vepackt?

- ist die Schätzung von zwei Stunden Arbeit maßlos untertrieben?

- hat besagtes Projektmitglied keine Lust mittels der Kommentare den 
Entwurf gerade zu ziehen und damit deine Arbeit zu machen?

- hat er schlicht und ergreifend Aufgaben höherer Priorität und keine 
Lust wegen dem Entwurf noch 2 + x Überstunden dran zu hängen?

- hat er keine Lust auf die absehbar folgende endlose, sinnlose und 
fruchtlose Diskussion über seine Kommentare?

- sagt ihm seine Erfahrung, dass dein ganzes Projekt eine Luftnummer 
irgendwelcher Wichtigmacher ist?

- war das mal sein Projekt oder seine Idee, die man ihm weggenommen hat 
und die du jetzt an die Wand fährst?

> Also was ist zu tun?

Aktennotiz und ohne Kommentare weitermachen. Sollten die Kommentare laut 
Prozess / Vorgehensmodell Pflicht sein dann formal eine Ausnahme 
beantragen um ohne Kommentare weitermachen zu dürfen.

Autor: Ingo Less (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Danilo schrieb:
> Also was ist zu tun?
Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter... 
Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der 
Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Oft sind aber 
gerade diese Leute in der Weiterbildung vor 10-15 Jahren stehengeblieben 
und um das zu vertuschen machen sie sich unnötig wichtig.

Autor: Elektron (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Ingo Less schrub:
> Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter...
> Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der
> Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Oft sind aber
> gerade diese Leute in der Weiterbildung vor 10-15 Jahren stehengeblieben
> und um das zu vertuschen machen sie sich unnötig wichtig.

Auch du wirst mal alt sein, vergiss das nicht!

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ingo Less schrieb:
> Danilo schrieb:
>> Also was ist zu tun?
> Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter...

Ist er derjenige, der den Leistungsnachweis unterschreibt? Nein? Dann 
ist er nicht der richtige Ansprechpartner.

Autor: Jack (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ingo Less schrieb:
> Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter...
> Leider erlebt man immer häufiger,

"Man erlebt"? Und "häufig"? Glaube ich dir nicht. Das klingt mehr nach 
der Wiederholung von Standardsprüchen denen keine eigene Erfahrung 
zugrunde liegt.

> dass sich ältere Kollegen kurz vor der
> Rente quer stellen um ihre Wichtigkeit zu demonstrieren.

Gerade erfahrene Kollegen haben es nicht nötig ihre Wichtigkeit zu 
demonstrieren. Normalerweise sind es die prallen Jungspunde die sich 
aufführen als wären sie Gottes Geschenk an die Ingenieurskunst.

Autor: Danilo (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Jack schrieb:
> Vielleicht
>
> 1) ist der Entwurf inhaltlich so unsagbarer Mist, dass es das erfahrene
> Projektmitglied schon bei dem Gedanken daran ihn lesen zu müssen graut?
>
> 2) ist das Dokument schlecht lesbar, unverständlich,
> verschwurbelt-angeberisch gechrieben, mit Berater-BWL-Sprech aufgepimpt
> und in Neusprech-Zuckerguss vepackt?
>
> 3) ist die Schätzung von zwei Stunden Arbeit maßlos untertrieben?
>
> 4) hat besagtes Projektmitglied keine Lust mittels der Kommentare den
> Entwurf gerade zu ziehen und damit deine Arbeit zu machen?
>
> 5) hat er schlicht und ergreifend Aufgaben höherer Priorität und keine
> Lust wegen dem Entwurf noch 2 + x Überstunden dran zu hängen?
>
> 6) hat er keine Lust auf die absehbar folgende endlose, sinnlose und
> fruchtlose Diskussion über seine Kommentare?
>
> 7) sagt ihm seine Erfahrung, dass dein ganzes Projekt eine Luftnummer
> irgendwelcher Wichtigmacher ist?
>
> 8) war das mal sein Projekt oder seine Idee, die man ihm weggenommen hat
> und die du jetzt an die Wand fährst?

Sehr gute Anmerkungen Deinerseits.

Antworten wie folgt:

1) Entwurf inhaltlich so unsagbarer Mist:
Nö Dokument ist Klasse, jedenfalls mind. so gut wie das meiste was da 
bisher so fabriziert wurde!

2) Dokument ist inhaltlich fast genauso wie einige der Unterlagen die 
der "Kommentierende" früher selbst erstellt hat (techn. Beschreibung, 
Selektivitätsnachweis, Materialliste, Prüfprotokolle, Schaltpläne im 
Änderungsmodus, usw..)

zu 3) zwei Stunden Arbeit maßlos untertrieben
Kann auch etwas mehr sein. Ist aber irgendwie ein Standard-Kleinprojekt 
(wo derjenige schon mind. 50 Stück so abgewickelt hat)


zu 4) besagtes Projektmitglied hat keine Lust:
gut möglich,
glaube aber fast eher, dass da firmenintern einer die Bremse 
reingedrückt hat weil ich doch etwas zu viel guten Output gebracht habe 
(ohne Quatsch). Das gefällt den wenigsten wenn ein externer kommt und 
den Spiegel aufstellt und die Transparenz über die "Leistung" vieler 
Interner herstellt!


zu 5) Aufgaben höherer Priorität:
Kann sein, dass er die hat, ich weiß aber nicht was andere machen da 
keine Gruppenmeetings

7) ist keine Luftnummer sondern nur ein Planungs-Dokument welches für 
die Gruppe ein recht wichtiger Output sein könnte (weil es ähnlich in 
Zukunft wieder genutzt werden könnte für ähnliche Projekte)

zu 8) war das mal sein Projekt?:
ja das gehört zu seinem früheren Aufgabengebiet

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Danilo schrieb:
> glaube aber fast eher, dass da firmenintern einer die Bremse
> reingedrückt hat weil ich doch etwas zu viel guten Output gebracht habe
> (ohne Quatsch).

Bundeseigenes Unternehmen, älterer Mitarbeiter, Du kommst als externe 
Heißdüse rein und versaust den Akkord. Ja, damit macht man sich auf 
Arbeitsebene nicht beliebt. Andererseits kommt es beim Chef nicht gut 
an, wenn man genauso bummelt wie der durchschnittliche Festangestellte.

Strategisch wählt man da einen Kompromiß und positioniert sich im oberen 
Drittel, aber nicht als Überflieger. Dann ist der Chef zufrieden, aber 
man eckt auf Arbeitsebene nicht an.

Autor: идиотендетектор (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Dokuentwurf kommentieren?

Wie hat man vor ein paar Jahren noch ohne einen solchen Schwachsinn 
arbeiten können? Ach Halt! Da hat man ja wirklich arbeiten müssen 
und nicht die Produktion von Papierbergen als Arbeit bezeichnet.

SCNR

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
идиотендетектор schrieb:
> Da hat man ja wirklich arbeiten müssen
> und nicht die Produktion von Papierbergen als Arbeit bezeichnet.

Da hat man schlichtweg überhaupt keine Doku gemacht, und wenn der 
ursprüngliche Hacker weg war, dann wurde der Einbau von selbst trivialen 
neuen Features sauteuer.

Man hat auch kein Design gemacht und das erstmal einem Review 
unterzogen, sondern gleich mal drauflosgehackt. Damit war man ja viel 
produktiver. Gut, daß dann eine vierstellige Zahl von Geräten aus dem 
Feld zurückkam und die Kunden bei den nächsten Preisverhandlungen dann 
sehr aggressiv verhandelt haben, hat man nicht miteinander in Verbindung 
gebracht.

Jaja, die guten alten Zeiten. Obwohl, alteingesessene Firmen arbeiten 
heute noch auf diese Weise. Das Ergebnis kann man sich dann z.B. bei BMW 
connected drive anschauen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Nop schrieb:
> Man hat auch kein Design gemacht und das erstmal einem Review
> unterzogen, sondern gleich mal drauflosgehackt.

Heutzutage sieht man aber häufig genau das Gegenteil, nämlich teils 
jahrelange Spezifikationsprozesse, die komplett an der technischen 
Machbarkeit vorbeigehen. In der Zeit hätte man schon etliche Prototypen 
zusammenbasteln und daraus wichtige Erkenntnisse gewinnen können. Wer 
auf Anglizismen steht, kann das als "Rapid Prototyping" bezeichnen.

Wichtig sind aber bloß die darauffolgenden Schritte. Wer meint, dass 
solche Prototypen schon nahezu fertigentwickelte Serienprodukte seien, 
lügt sich in die eigene Tasche. Wer aber die Erkenntnisse aus dieser 
RP-Phase akribisch zusammenträgt, hat eine viel bessere Grundlage für 
die Erstellung der Spezifikationen für das Serienprodukt. Allerdings 
scheitert die erfolgreiche Umsetzung in manchen Fällen auch daran, dass 
viele Entwickler nicht bereit sind, Programmcode oder Schaltungen, die 
sich nicht bewährt haben, einfach in die Tonne zu treten, sondern ihr 
Leben lang daran hängen. Ggf. muss man da als Projektleiter sehr 
stringent vorgehen und auch immer wieder kontrollieren, dass nicht 
hintenherum solche verkorksten Teile wieder eingeführt werden.

Auch wenn sich in etlichen Jahrzehnten der Ingenieurskunst immer wieder 
gezeigt hat, dass reine Top-Down-Entwicklungsmodelle zu komplett 
unbrauchbaren Produkten geführt haben, sehe ich aber in letzter Zeit 
eine stärkere Rückkehr zu solchen Prozessen. Dies liegt in vielen Fällen 
auch an der unglaublichen Arroganz mancher "Systemarchitekten", die sich 
mit der realen Produktentwicklung nicht die Finger dreckig machen 
wollen.

Gerade Entwicklungsprozesse, in denen Unmengen an Dokumentation 
produziert werden, sorgen auch dafür, dass in den meisten Fällen genau 
diese Dokumentation weder in sich konsistent ist noch die Dokumente 
untereinander. Und die Umsetzung im konkreten Produkt unterscheidet sich 
dann auch nochmals sehr deutlich von den zuvor angefertigten 
Spezifikationen.

: Bearbeitet durch User
Autor: Danilo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> Bundeseigenes Unternehmen, älterer Mitarbeiter, Du kommst als externe
> Heißdüse rein und versaust den Akkord. Ja, damit macht man sich auf
> Arbeitsebene nicht beliebt. Andererseits kommt es beim Chef nicht gut
> an, wenn man genauso bummelt wie der durchschnittliche Festangestellte.
>
> Strategisch wählt man da einen Kompromiß und positioniert sich im oberen
> Drittel, aber nicht als Überflieger. Dann ist der Chef zufrieden, aber
> man eckt auf Arbeitsebene nicht an.

Genauso sieht das aus.

Weder die Zeiten kaputtmachen noch bummeln, das ist der richtige Weg.

Da aber der Gruppenleiter offenbar in der Kritik steht, weil nix richtig 
geht strebe ich aber schon an den Schnitt etwas zu anzuheben.

Ich denke in 12 Monaten ca. 150 Seiten gute Planungsdokumente machen ist 
durchaus noch nicht übertrieben. Das sind im Monat 15 Seiten, das muss 
ein Minimum sein. Immerhin sind das hier auch Steuergelder (bzw. fast 
nur) die verbraten werden.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Du hast Dich immer noch nicht dazu geäußert, wer für die Abnahme Deiner 
Lieferungen bzw. Freigabe Deiner Leistungsnachweise zuständig ist. Nur 
dessen Befindlichkeiten sind relevant.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Heutzutage sieht man aber häufig genau das Gegenteil, nämlich teils
> jahrelange Spezifikationsprozesse, die komplett an der technischen
> Machbarkeit vorbeigehen.

Was im Wesentlichen auf schlechtes Projektmanagement zurückzuführen ist. 
Namentlich, daß eben keine strukturierte Vorgehensweise da ist, sondern 
z.T. ganz wesentliche Änderungen zu jedem Zeitpunkt einfließen, wodurch 
man überhaupt nicht mehr dazu kommt, ein rundes Konzept zu machen.

Das wiederum kommt durch Featuritis zustande. Egal, wie unnütz und 
unbrauchbar ein Feature ist, Hauptsache, man kann im Prospekt damit 
werben. Wenn die Waschmaschine der Konkurrenz schon einen Webserver und 
beinhaltet, dann "muß" man natürlich ins eigene Produkt zusätzlich auch 
noch GPS integrieren.

Auch ein hübsches Beispiel für sowas sind transnationale 
Rüstungsprojekte, wo jeder für seine Armee irgendwelche Sonderwünsche 
hat und am Ende die eierlegende Wollmilchsau herauskommen soll. Die, oh 
Wunder, nicht funktioniert.

> In der Zeit hätte man schon etliche Prototypen
> zusammenbasteln und daraus wichtige Erkenntnisse gewinnen können.

Das war früher mal. Inzwischen ist das Problem, daß nennenswerte 
Neuentwicklung an sich schon sauteuer geworden ist. Außer für Produkte, 
die man aus vorhandenen Sachen zusammenstoppeln kann, aber das tun die 
Chinesen dann für 10% des Preises.

> Wichtig sind aber bloß die darauffolgenden Schritte. Wer meint, dass
> solche Prototypen schon nahezu fertigentwickelte Serienprodukte seien,
> lügt sich in die eigene Tasche.

Das sag mal Managern. Auch ein Grund, wieso man von Rapid Prototyping 
abgekommen ist, weil die Entscheider dann unfähig waren, das als 
Prototypen zu sehen. Mit dem Ergebnis, daß zusammengefrickeltes Zeug in 
Serie ging. Deswegen ist das heute wieder prozeßlastiger.

> Auch wenn sich
> in etlichen Jahrzehnten der Ingenieurskunst immer wieder gezeigt hat,
> dass reine Top-Down-Entwicklungsmodelle zu komplett unbrauchbaren
> Produkten geführt haben, sehe ich aber in letzter Zeit eine stärkere
> Rückkehr zu solchen Prozessen.

Liegt auch daran, daß die Welt komplexer geworden ist und man dasselbe 
Produkt nahezu beliebig aufwendig machen kann. Besonders unbeliebt sind 
versteckte Kostentreiber wie z.B. alles, was mit IT-SIcherheitsaspekten 
zu tun hat. Die sieht der Nutzer halt nicht direkt, also bezahlt er sie 
auch nicht gerne.

Deswegen kommt am Ende so ein unreifer Mist wie BMW connected drive 
raus. Oder der Hack, wo sie einen Chrysler während der Fahrt in den 
Graben geschickt haben, von außen.

Derlei wird eben nur korrekt implementiert, wenn es auch so spezifiziert 
und bezahlt wurde. Das gilt nochmal verschärft, wenn man Teile davon 
nach Indien auslagert.

Autor: Danilo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Du hast Dich immer noch nicht dazu geäußert, wer für die Abnahme
> Deiner
> Lieferungen bzw. Freigabe Deiner Leistungsnachweise zuständig ist. Nur
> dessen Befindlichkeiten sind relevant.

Den Stundenzettel unterschreibt der Gruppenleiter (bei dessen 
Abwesenheit der AL).

Wie gesagt steckt der GL (weil er erst seit 10 Monaten GL ist) noch 
aktiv in eigenen Projekten drin(die aus dem Ruder laufen terminlich). Er 
hat da zwar eigene Leute für, steckt aber ganz tief drinne und kann 
nicht loslassen. Zumind. sehe ich das so.

Will ich 10 (oder 15) Leute führen kann der das so nicht mehr machen. 
Der dürfte nur noch managen.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Auch wenn sich in etlichen Jahrzehnten der Ingenieurskunst immer wieder
> gezeigt hat, dass reine Top-Down-Entwicklungsmodelle zu komplett
> unbrauchbaren Produkten geführt haben, sehe ich aber in letzter Zeit
> eine stärkere Rückkehr zu solchen Prozessen.

Das ist die eine Richtung, aber es gibt auch eine Gegenbewegung -- 
zumindest im Softwareumfeld. Durch die Agile Entwicklung sollen die von 
Dir so richtig identifizierten Probleme vermieden werden. 
Softwareentwickler haben im Laufe der Jahrzehnte gelernt, daß man 
Software nicht im Elfenbeinturm entwerfen kann, daß sich Anforderungen 
laufend ändern und zum Teil auch erst während des Entwicklungsprozesses 
erkannt werden können.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Durch die Agile Entwicklung sollen die von
> Dir so richtig identifizierten Probleme vermieden werden.

Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso man 
überhaupt erst dazu kam, definierte Prozesse einzuführen. Agile 
Entwicklung kannste bei tendentiell GUI-lastigen Sachen als interaktives 
Rapid Prototyping machen, aber ansonsten führt das zu völlig vergurkten 
Systemdesigns, weil keine Planung mehr stattfindet, sondern nur noch 
Userstories irgendwie kurzfristig ins bestehende System reingefrickelt 
werden.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und in vielen Firmen (bei uns auch) wird dann noch versucht dieses agile 
Konzept auf alles auszubreiten. Das es bei Elektronikentwicklungen ggf. 
nicht sinnvoll ist sich täglich 10min mit dem gesamten Team zu treffen 
und zu sagen was man dann in der nächsten Stunde macht leuchtet den 
Managern nicht so ein. Dabei wird man als Elektronikentwickler doch 
lieber mal wenigstens eine Woche mit den Spezifikationen alleine 
gelassen um sich überhaupt mal grobe Ansätze zu überlegen...

Autor: Kommunikator (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingo Less schrieb:
> Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der
> Rente quer stellen um ihre Wichtigkeit zu demonstrieren.
Das ist leider wahr. Trauig eigentlich, wenn es soweit kommt. Hat aber 
auch damit zu tun , dass die von den Firmen irgendwann abserviert 
wurden.

> Oft sind aber gerade diese Leute in der Weiterbildung vor 10-15 Jahren
> stehengeblieben
... was daran liegt, dass man Leute über 50 nicht mehr fördert.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommunikator schrieb:
>> Oft sind aber gerade diese Leute in der Weiterbildung vor 10-15 Jahren
>> stehengeblieben
> ... was daran liegt, dass man Leute über 50 nicht mehr fördert.

Dem muss ich widersprechen. Viele Leute sind der Auffassung, dass sie 
nach dem Studium keine fachbezogene Weiterbildung mehr betreiben müssen, 
zumindest nicht aus eigenem Antrieb. Wer dann irgendwann, wenn das Kind 
in den Brunnen gefallen ist, sich darauf beruft, dass der Arbeitgeber 
ihn in all den Jahren nicht zu Weiterbildungsmaßnahmen gezwungen habe, 
ist selbst Schuld. Solche Leute merken auch nicht, dass sich ihre 
fachlich wesentlich besser aufgestellten Kollegen fortwährend 
weiterbilden, und zwar nicht (nur) in irgendwelchen verordneten Kursen, 
sondern im Selbststudium.

Autor: klausi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen 
seit Jahren dasselbe, keine Lust, kein Interesse,  keine Weiterbildung.

Kommen immer genau um 8, um 17 Uhr Feierabend.
Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was 
überlegen, undenkbar.

War so ein halber Beamtenladen.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Sheeva P. schrieb:
>> Durch die Agile Entwicklung sollen die von
>> Dir so richtig identifizierten Probleme vermieden werden.
>
> Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso man
> überhaupt erst dazu kam, definierte Prozesse einzuführen. Agile
> Entwicklung kannste bei tendentiell GUI-lastigen Sachen als interaktives
> Rapid Prototyping machen, aber ansonsten führt das zu völlig vergurkten
> Systemdesigns, weil keine Planung mehr stattfindet, sondern nur noch
> Userstories irgendwie kurzfristig ins bestehende System reingefrickelt
> werden.

Nach meiner Erfahrung kommen "vergurkte Systemdesigns" meistens davon, 
daß sich jemand am Anfang der Entwicklung auf ein bestimmtes Design 
festgelegt hat und daran unbeirrt und stur festhält, obwohl veränderte 
Anforderungen eigentlich ein Refactoring nötig machen würden. Aber dann 
sitzt dann unser Systemdesigner da und will a) nicht zugestehen, daß 
sein Design nicht mehr zur Aufgabenstellung paßt und b) nicht für ein 
vermeintlich unproduktives, zeitaufwändiges Refactoring verantwortlich 
sein.

Autor: Danilo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
klausi schrieb:
> Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen
> seit Jahren dasselbe, keine Lust, kein Interesse,  keine Weiterbildung.
>
> Kommen immer genau um 8, um 17 Uhr Feierabend.
> Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was
> überlegen, undenkbar.
>
> War so ein halber Beamtenladen.

Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht 
viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch 
bisschen was geht.

Ich nehme an die Geschäftsführung weiß das aber auch (obwohl die 
etablierten Führungskräfte das best. anders darstellen).

Des Weiteren gehe ich davon aus, dass der Laden mal durchleuchtet wird.

Wobei ich auch sicher keiner bin der 130 % bringt (bringen kann). Kann 
auch sein, dass man da selbst dran krank wird, dann muss man vorher 
gehen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@ Danilo (Gast)

>> Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen
>> seit Jahren dasselbe, keine Lust, kein Interesse,  keine Weiterbildung.
>
>> Kommen immer genau um 8, um 17 Uhr Feierabend.
>> Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was
>> überlegen, undenkbar.
>
>> War so ein halber Beamtenladen.

>Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht
>viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch
>bisschen was geht.

Willkommen im VEB!

https://de.wikipedia.org/wiki/Volkseigener_Betrieb

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen schrieb:
> Und in vielen Firmen (bei uns auch) wird dann noch versucht dieses agile
> Konzept auf alles auszubreiten. Das es bei Elektronikentwicklungen ggf.
> nicht sinnvoll ist sich täglich 10min mit dem gesamten Team zu treffen
> und zu sagen was man dann in der nächsten Stunde macht leuchtet den
> Managern nicht so ein. Dabei wird man als Elektronikentwickler doch
> lieber mal wenigstens eine Woche mit den Spezifikationen alleine
> gelassen um sich überhaupt mal grobe Ansätze zu überlegen...

Tja, und auch dann ist eine Agile Entwicklung gar keine so schlechte 
Idee, wie Du sie hier darstellst. Wenn der Elektronikentwickler im 
Meeting über seine Fortschritte berichtet, können ihn die anderen dabei 
unterstützen und erfahren gleichzeitig die große Richtung dessen, was 
auf sie zukommt. Es geht schließlich darum, die Leute aus ihren stillen 
Kemenaten heraus und ins Gespräch mit einander zu bringen.

Letzten Endes geht es bei der Agilen Entwicklung primär um eine bessere 
Kommunikation zwischen allen Beteiligten, anders gesagt: um eine andere 
Kultur des Umgangs miteinander und mit der Aufgabe. Die formalen 
Prozesse sind nicht das Ziel, sondern lediglich ein Hilfsmittel, einen 
kulturellen Wandel zu erzielen und erfolgreich zu bewältigen.

Wenn ich Deine Klage lese, gewinne ich den Eindruck, daß der kulturelle 
Aspekt bei Euch nicht verstanden wurde oder jedenfalls deutlich zu kurz 
gekommen ist. Stattdessen scheint es, als seien nur die alten Prozesse 
gegen neue ausgetauscht worden, ohne daß der Sinn und Zweck dieser neuen 
Prozesse verstanden worden sind, und ohne daß die neuen Prozesse 
sinnvoll und zweckgemäß genutzt würden, um ihre Ziele zu erreichen.

Sowas passiert leider häufig in Unternehmen mit starken Formalismen, die 
daran gewöhnt sind, ihre Prozesse von Zeit zu Zeit umzustellen, weil ein 
Wichtigtuer ein Buch gelesen oder ein Seminar besucht hat. Da werden die 
Ziele der neuen Prozesse dann nicht verstanden und die Prozesse einfach 
nur als neue Prozesse installiert, ohne den damit bezweckten kulturellen 
Wandel zu befördern.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Tja, und auch dann ist eine Agile Entwicklung gar keine so schlechte
> Idee, wie Du sie hier darstellst. Wenn der Elektronikentwickler im
> Meeting über seine Fortschritte berichtet, können ihn die anderen dabei
> unterstützen

Das mag gelten, wenn das Meeting mit anderen Elektronikentwicklern 
stattfinden würde. Aber hier bei uns sind in einem Team normalerweise 
nur ein bis zwei Elektronik Entwickler, dazu kommen dann Konstrukteure, 
Physiker und Softwareentwickler.

Wenn der Softwareentwickler mir dann in diesen täglichen Meetings 
erzählt wie er bestimmte Klassen implementieren möchte kann ich damit 
genauso wenig anfangen wie er mit meinen aktuellen Berechnungen zur 
Optimierung des Rauschens als Beispiel.

Ich finde da größere Zeiträume mit etwas abstrakter beschriebenen 
Tätigkeiten sinnvoller. Ich brauche diese täglichen Updates von 
Mitarbeitern die ein anderes Fachgebiet haben nicht wirklich. Natürlich 
müssen am Ende alle zusammen wirken, aber die Ebene der Kommunikation 
muss so gewählt sein, dass man eine gemeinsame Sprache spricht. Tägliche 
Monologe von jedem bringen kaum etwas, wenn die anderen einem eh nicht 
folgen können.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Tja, und auch dann ist eine Agile Entwicklung gar keine
> so schlechte Idee, wie Du sie hier darstellst.

Ich lese Dein Loblied auf die Agilität mit äußerst gemischten
Gefühlen.

Ich bin ein großer Freund agiler Methoden, aber man sollte
doch wissen, dass sie - so wie überhaupt alle Methoden - nur
unter bestimmten Voraussetzungen funktionieren. Agiles
Vorgehen eignet sich nur für bestimmte Leute und nur für
bestimmte Probleme. Sie sind kein Allheilmittel.

> Da werden die Ziele der neuen Prozesse dann nicht verstanden
> und die Prozesse einfach nur als neue Prozesse installiert,
> ohne den damit bezweckten kulturellen Wandel zu befördern.

Ja - und genau das gilt auch für die agilen Methoden selbst.
Du kannst Menschen, die sich nicht kulturell wandeln wollen,
dazu nicht wirksam zwingen.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen schrieb:

> Und in vielen Firmen (bei uns auch) wird dann noch
> versucht dieses agile Konzept auf alles auszubreiten.

Naja... man kann jede beliebige Methode dadurch in Verruf
bringen, dass man sie hartnäckig auf Fälle anwendet, für
die sie sich nicht eignet.

> Das es bei Elektronikentwicklungen ggf. nicht sinnvoll
> st sich täglich 10min mit dem gesamten Team zu treffen
> und zu sagen was man dann in der nächsten Stunde macht
> leuchtet den Managern nicht so ein.

Das kommt auf die Aufgabe und die Firmengröße bzw. die
Teamgröße an.

Ich habe mal in einer 10-Mann-Bude gearbeitet, die spezielle
elektronische Messtechnik gemacht hat. Unser kaufmännischer
Chef war brilliant, aber schüchtern; unser technischer Chef
war fachlich brauchbar bis sehr gut, aber menschlich SEHR
speziell.

Wir haben bestimmte Projekte nur deshalb erfolgreich
überlebt, weil auf den Druck der Belegschaft hin (!!)
wöchentliche (und zeitweise tägliche) Besprechungen
gemacht wurden.

> Dabei wird man als Elektronikentwickler doch lieber
> mal wenigstens eine Woche mit den Spezifikationen
> alleine gelassen um sich überhaupt mal grobe Ansätze
> zu überlegen...

Klar.
Der Witz ist, dass sich das überhaupt nicht ausschließt.

Je nach Projektphase gab es Zeiten, in denen ich fast
wochenlang ungestört arbeiten konnten, und auch solche,
in denen ich alle Stunde gezwungen war, neu zu planen.

Autor: Possetitjel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:

> Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso
> man überhaupt erst dazu kam, definierte Prozesse einzuführen.

Die definierten Prozesse hat man, damit ein anderer schuld ist,
wenn es am Ende nicht funktioniert.

Agile Methoden hat man, damit es am Ende funktioniert.

> Agile Entwicklung kannste bei tendentiell GUI-lastigen
> Sachen als interaktives Rapid Prototyping machen,

Zu enger Fokus: Agile Methoden können sich eignen, wenn
kleine Teams komplexe Dinge tun.

> aber ansonsten führt das zu völlig vergurkten Systemdesigns,
> weil keine Planung mehr stattfindet,

Vermutlich einer der folgenschwersten Irrtümer: Agilität
macht Planung nicht überflüssig!

> sondern nur noch Userstories irgendwie kurzfristig ins
> bestehende System reingefrickelt werden.

Die Schlüsselworte hier sind "irgendwie" und "reingefrickelt".

"Irgendwie reinfrickeln" führt mit jeder Methode zu einem
vergurkten System.

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> "Irgendwie reinfrickeln" führt mit jeder Methode zu einem
> vergurkten System.

Mitteilung aus dem VEB Vegetarierproduktion:

Wer mit Tomaten auf den Augen an einem vergurktem System arbeitet, hat 
bald den Salat und wird angepflaumt. Da muß man seine Birne mal 
anstrengen, um auf einen grünen Zweig zu kommen, bevor Gras über die 
Sache gewachsen ist.
Wenn erst etwas im Busche ist, braucht man die Kastanien auch nicht mehr 
aus dem Feuer zu holen.

gez.
-Paul-

Produktionsleiter

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Die definierten Prozesse hat man, damit ein anderer schuld ist,
> wenn es am Ende nicht funktioniert.

Nein, die hat man, damit es funktioniert. Ich hab es noch jedesmal 
erlebt, wenn "aus Zeitgründen" die Prozesse mißachtet wurden, daß es am 
Ende länger dauerte und schlechter wurde. Beispielsweise, weil jemand 
mit der Codierung schon angefangen hat, obwohl die Spec noch nicht mit 
dem Kunden gefixt war, sondern nur irgendwelche Memos herumfluteten. Was 
dann auch beim Testdesign aus derselben Unklarheit zu vergurkten 
Testfällen führte, die die Fehler ebenfalls nicht aufdecken konnten.

> Zu enger Fokus: Agile Methoden können sich eignen, wenn
> kleine Teams komplexe Dinge tun.

Das ist übrigens der Hauptgrund, wieso die agilen Methoden sich mit der 
höheren Erfolgsrate schmücken können. Kleine Projekte haben nämlich 
IMMER eine höhere Erfolgrate als große, weil weniger schiefgehen kann, 
und Agile Entwicklung pickt sich da die Rosinen der Kleinprojekte raus.

Nur, diese kleinen Projekte klappen auch ohne Agilität besser als die 
großen.

> Vermutlich einer der folgenschwersten Irrtümer: Agilität
> macht Planung nicht überflüssig!

Genau das ist aber die Praxis, weil die Performancebewertung der 
Mitarbeiter nach implementierten Userstories geht. Wenn man so ein 
Anreizsystem setzt, wird eben nicht mehr groß geplant.

> Die Schlüsselworte hier sind "irgendwie" und "reingefrickelt".

Anders geht's aber auch nicht, wenn man Frontup-Design unter den Tisch 
fallen läßt, und genau das passiert nunmal bei Agiler Entwickung, weil 
das ja gerade deren Sinn war.

Das funktioniert, wenn es um Sachen wie Änderungswünsche geht, bei denen 
im Grunde nur mal eine kleine Routine oder ein paar Konstanten geändert 
werden müssen. Die ursprüngliche Kritik seitens der Agilbewegung, daß 
man an solchen Stellen nun wirklich nicht 8 Wochen Dokumentationsvorlauf 
machen braucht, ist ja durchaus berechtigt gewesen.

Ansonsten kann man die Grundidee agiler Entwicklung auch mit iteriertem 
Wasserfall kombinieren. Ohne nervige Standup-Labermeetings, bei denen 
man sich nur wünscht, endlich wieder an die Arbeit gehen zu können.

Der Trick ist sehr einfach, mit seinen Kollegen zu REDEN, und zwar 
sinnvoll. Jede Phase wird nach dem Grundentwurf gemeinsam einen Review 
unterzogen, damit man den Wasserfall ohne Iteration hinbekommt (die 
nächste Iteration soll erst beim nächsten Änderungsdurchlauf sein).

Sinnigerweise sind dabei nicht nur die Entwickler zugegen, sondern auch 
die Tester, die auf diese Weise gleich mitbekommen, was sich ändert, und 
worauf es beim Testen dabei ankommt. Oder die aus praktischer Erfahrung 
heraus gleich inhaltliche Anregungen machen, weil nämlich Tester die 
sind, die das System in der Realität sehr gut kennen.

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Beispielsweise, weil jemand
> mit der Codierung schon angefangen hat, obwohl die Spec noch nicht mit
> dem Kunden gefixt war, sondern nur irgendwelche Memos herumfluteten.

No Comment.

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>>> War so ein halber Beamtenladen.
>
>>Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht
>>viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch
>>bisschen was geht.
>
> Willkommen im VEB!
>
> https://de.wikipedia.org/wiki/Volkseigener_Betrieb

Nachdem hier im Fred nun die "agile Entwicklung" besprochen wurde ist 
festzuhalten, dass es hier in der Fa. nix agiles gibt.

Man muss alles mal erlebt haben: Es ist hier so wie einst in der 
TK-Firma als innerhalb von 6 Wochen der Bereichsleiter, der Abt.-Leiter 
und der Teamleiter abgehauen sind und die Nachfolger nur zu 30 % (und 
zeitversetzt) da waren. Da gab es auch nix an Führung.

Dann muss man halt selbst sehen das Bestmögliche für das Team (und mich 
selbst) herauszuholen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.