Forum: Ausbildung, Studium & Beruf SCRUM und die Arbeitsweise von Selbständigen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Olli Polli (Gast)


Lesenswert?

Wer sich mit der Vorgehensweise bei SCRUM auskennt, der weis, wie das so 
ungefähr läuft, mit den Aufgabenplanungen und Verteilungen - 
insbesondere dann, wenn einer nicht weiter kommt und Tasks umverteilt 
werden.

Es ist nun die Frage aufgetaucht, wie das mit der Arbeitsweise von 
Selbständigen zusammenpasst, weil diesen - soweit sie in das System 
eingebunden sind - ebenfalls ständig und ad hoc Aufgaben zugewiesen 
werden.

Ist das schon eine weisungsgebundene Tätigkeit?

Widerspricht die Nutzung von SCRUM generell dem Involvieren von externen 
Mitarbeitern, oder gfs dann, wenn es in bestimmter Weise genutzt wird?

1) Nehmen wir an, es gibt TÄGLICHE(!) Meetings, in denen abgeprüft wird, 
welche Aufgaben erledigt sind und eine Art "Berichterstattung" läuft.

2) Nehmen wir weiter an, dass aufgrund der Berichterstattung, Tasks neu 
definiert, neu verteilt werden, um einen "aligned sprint" zu erzielen.

3) Nehmen wir weiter an, dass es WÖCHENTLICHE Sprints mit festem 
Zeitrahmen gibt, in denen der Projektleiter die Zeitvorgaben macht und 
anhand der kommunizierten Einzeltasks, die man zusichert, abarbeiten zu 
können, dann Tasks aus dem Tableau nimmt, diese anderen Teammitgliedern 
zuteilt oder in nächste Sprints verschiebt, also damit eine Zeitplanung 
für den Externen vornimmt.

4) Nehmen wir weiter an, daß man Tasks zugeschoben bekommt, die 
"brennen" weil ein anderer nicht weiter kommt, oder die Resourcen nicht 
reichen und deshalb der eigentliche Task, an dem man arbeitet und der 
Vertragsgegenstand ist, unterbrochen wird, obwohl nie die Rede von 
diesem neuen Task war und er auch nicht Vertragsgegenstand ist?

Wäre - als Frage formuliert - schon das Mitglied sein in einem 
SCRUM-Team ein Problem?

Wäre es gfs sicherer, man trennt die Teams in Externe und Interne?

Die Arbeitsplätze werden oft genug ja auch getrennt, d.h die Externen 
dürften nicht zuwischen den Internen sitzen.

von Uwe D. (monkye)


Lesenswert?

Deine Einführung liest sich wie ein Hybrid-SCRUM.

SCRUM stellt die Verantwortung des Einzelnen heraus, das Team 
entscheidet - es gibt aber Ausnahmen. Der Product Owner wäre ein 
Kandidat für „Chef Allüren“ im Sinne eines Juristen…

Zielt die Frage auf „Scheinselbständigkeit“ ab?

von Olli Polli (Gast)


Lesenswert?

Uwe D. schrieb:
> Zielt die Frage auf „Scheinselbständigkeit“ ab?
unter anderem, JA.

Uwe D. schrieb:
> das Team entscheidet
Wäre für mich ein Hinweis auf "eingebunden in Organisationsstruktur"

Uwe D. schrieb:
> Der Product Owner wäre ein Kandidat für „Chef Allüren“
Wäre für mich ein Hinweis aus "weisungsgebunden".

Beitrag #7320118 wurde von einem Moderator gelöscht.
Beitrag #7320136 wurde von einem Moderator gelöscht.
von Opferanode für Teamstimmung (Gast)


Lesenswert?

Olli Polli schrieb:
> Ist das schon eine weisungsgebundene Tätigkeit?

Nein. Schau Dir die Rollen im SCRUM an. Gibt es da einen "Einweiser"?!
Nein, es gibt lediglich einen Moderator der durch die daily scrumms 
führt und darauf achtet, das die SCRUM-Teammitglieder ihr Commitment zum 
daily sprint abgeben.


> Widerspricht die Nutzung von SCRUM generell dem Involvieren von externen
> Mitarbeitern, oder gfs dann, wenn es in bestimmter Weise genutzt wird?

nein. Höchstens als höfliche Notlüge wenn es eigenlich andere Gründe 
gibt, diesen konkreten Freiberufler in dieses Projekt zu holen.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Olli Polli schrieb:
> Ist das schon eine weisungsgebundene Tätigkeit?

Rechtsthemen in einem Mikrocontroller-Forum diskutieren ist nicht 
zielführend.

Notfalls entscheidet das am Ende ein Richter. Der wird sich in keinster 
Weise davon beeinflussen lassen was der als besonders vertrauenswürdig 
erscheinende "testdödel 32" irgendwo im Internet in einem Forum 
behauptet hat.

Falls du es nicht verstanden hast, die Antworten die du hier bekommst 
kannst du dir in die Haare schmieren, von der Backe putzen, knicken.

Such dir eine zuverlässige Quelle von der du belastbare Informationen 
bekommst.

von Michael B. (laberkopp)


Lesenswert?

Olli Polli schrieb:
> Wäre - als Frage formuliert - schon das Mitglied sein in einem
> SCRUM-Team ein Problem?

Ja. Problem in der Art, als dass der Selbständige der in Scrum 
eingebunden ist definitiv ein Scheinselbständiger ist und der ihn 
Beauftragende dann Sozialversicherung nachzahlen muss.

> Wäre es gfs sicherer, man trennt die Teams in Externe und Interne?

Nein.

Selbständige arbeiten gar nicht als Rädchen im Scrum.

Man gibt ihnen einen Auftrag, als Werkvertrag oder Stundenlohn, und 
rechnet ab nach Erledigung des Auftrags. Zwischendrin lässt man ihn in 
Ruhe selbständig arbeiten.

WIE kleinteilig die Aufgabe ist, kann sich der Arbeitgeber ja aussuchen, 
viele Selbständige setzen ihre Einkünfte auf 5min oder 15min kurzen 
Arbeitseinsätzen zusammen. Wenn aber alle 250 dieser kurzen Abrechnungen 
vom selben Auftraggeber stammen, ist das wieder Scheinselbständigkeit.

: Bearbeitet durch User
Beitrag #7320234 wurde von einem Moderator gelöscht.
Beitrag #7320488 wurde von einem Moderator gelöscht.
Beitrag #7320509 wurde von einem Moderator gelöscht.
von Opferanode für Teamstimmung (Gast)


Lesenswert?

Lebensberatung schrieb im Beitrag #7320509:
> Opferanode für Teamstimmung schrieb:
>> Ich Kenne einige Freelancer in scrum-Teams,
> Weil du jetzt ein paar Vollpfosten kennst die sich freiwillig dem
> Verdacht der Scheinselbstständig aussetzen soll das jetzt autmatisch die
> Regel/problemlos sein?

Mumpotz, Mitarbeit im Scrum-Team alleine ist kein Kriterium für 
Scheinselbstständigkeit. Kannste gerne nachlesen:

https://www.ihk-muenchen.de/de/Service/Recht-und-Steuern/Arbeitsrecht/Einstellung-von-Arbeitnehmern/Scheinselbst%C3%A4ndigkeit/

Und es gibt klare Anzeichen für Nicht-Scheinselbstständigkeit wie
-Angestellte haben
-Rechtsform GmbH
-mehrere Auftraggeber
-aktive Akquise
-Werkvertrag

Vielleicht solltest du mal an daran arbeiten.

> Nenn mal den Namen der Firma damit wir die Behörden informieren können,
> dann wirste schon sehen wie legal das ganze Konstrukt ist.

Mach, mal: Rohde & Schwarz München, ESG Fürstenfeldbruck, ... welche 
Bude macht den heutzutage nicht aus SCRUM ?!

>> also es ist wohl eher die
>> 'Lebensberatung' die ein problem mit adequater Wiedergabe der Umwelt hat
>> ...
> Red doch nicht so saudumm daher, so blöd bist du doch selber nicht, dass
> das angeblich die Regel und unproblematisch ist.

Nein danke, behalt mal deine dissoziativen Störung für Dich.

von Michael B. (laberkopp)


Lesenswert?

Lebensberatung schrieb im Beitrag #7320509:
> Nenn mal den Namen der Firma damit wir die Behörden informieren können

Unsinn.

Der Weg geht andersrum: man arbeitet still und leise und voll 
eingebunden in dem Scrum Team der Firma, und wenn die nach 2 Jahren der 
Meinung sind, sie können einem keine Verlängerung des Auftrags geben, 
der Job hat also ein Ende, dann klagt man vor dem Arbeitsgericht:

Scheinselbständig ist bei Scrum offensichtlich, die nicht-Verlängerung 
ist unwirksam weil sie einem ordentlich hätten
kündigen müssen wie einem Arbeitnehmer , weil aber das Urteil aber Jahre 
nach dem Rauswurf kommt muss die Firma Gehalt nachzahlen, zudem darf sie 
zum damaligen Stundensatz noch die Sozialversicherung oben drauf legen.

Es sind die Firmen  die ein Risiko eingehen, nicht der Auftragnehmer.

Und man selbst hat so die Kohle von der Firma mit der man sowieso nicht 
zusammenarbeiten will weil sie einem die Kohle vorenthalten wollte.

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

Michael B. schrieb:
> Problem in der Art, als dass der Selbständige der in Scrum
> eingebunden ist definitiv ein Scheinselbständiger ist

Michael B. schrieb:
> Scheinselbständig ist bei Scrum offensichtlich

Das mag in Deiner Welt so eindeutig sein, Richter sehen das nicht 
unbedingt so:

https://www.gulp.de/freelancing/wissen/scheinselbststaendigkeit/urteil-scrum-projekte-kein-indiz-scheinselbststaendigkeit

von Uwe D. (monkye)


Lesenswert?

Lebensberatung schrieb im Beitrag #7320509:
> Opferanode für Teamstimmung schrieb im Beitrag #7320488:
>> Ich Kenne einige Freelancer in scrum-Teams,
> Weil du jetzt ein paar Vollpfosten kennst die sich freiwillig dem
> Verdacht der Scheinselbstständig aussetzen soll das jetzt autmatisch die
> Regel/problemlos sein?
>
> Nenn mal den Namen der Firma damit wir die Behörden informieren können,
> dann wirste schon sehen wie legal das ganze Konstrukt ist.

DB, Commerzbank, Airbus, Thales, Lufthansa, TÜV Nord/Süd, …

Es gibt massenhaft freiberufliche Spezialisten, die haben alle Deine 
Befürchtungen nicht. Und verrückt: Sogar der formale Projektleiter ist 
ein Freiberufler….

von Peter A. (Gast)


Lesenswert?

Wer sich diesen SCRUM Rotz als selbstständiger freiwillig antut ist echt 
nicht zu retten.

von Kindergärtner (Gast)


Lesenswert?

Peter A. schrieb:
> Wer sich diesen SCRUM Rotz als selbstständiger freiwillig antut ist echt
> nicht zu retten.

Gehst doch zur Schule? Oder Kindergarten? Oder bist sonst nur ein 
Rotz-junge?

von Da Baby (Gast)


Lesenswert?

Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst 
verloren

von Old (old_newcomer)


Lesenswert?

Kindergärtner schrieb:
>
> … Oder bist sonst nur ein
> Rotz-junge?

Du machst deinem Nick alle „Ehre“. Hoffe für die Kinder, dass du kein 
Kindergärtner im realen Leben bist.

von Genervter (Gast)


Lesenswert?

Ich danke Gott, dass ich nicht mehr als Informatiker arbeiten muss.

von Uwe D. (monkye)


Lesenswert?

Da Baby schrieb:
> Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst
> verloren

Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar, 
dass keine (internationale) Großprojekterfahrung vorhanden ist oder die 
menschliche Reife, andere Denkmodelle zuzulassen.

Und nein, dass ist keine Aufforderung zu einer Antwort auf meine Zeilen.

von Peter A. (Gast)


Lesenswert?

Uwe D. schrieb:
> Da Baby schrieb:
>> Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst
>> verloren
>
> Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar,
> dass keine (internationale) Großprojekterfahrung vorhanden ist oder die
> menschliche Reife, andere Denkmodelle zuzulassen.
> Und nein, dass ist keine Aufforderung zu einer Antwort auf meine Zeilen.

Internationale Großprojekte und SCRUM? Hat man dir das in deiner Dorf 
Hinterhof klitsche erzählt? Geh mal in die Welt denn viel Erfahrung 
scheint du nicht zu haben.

Beitrag #7323278 wurde von einem Moderator gelöscht.
von Kindergärtner (Gast)


Angehängte Dateien:

Lesenswert?

Peter A. schrieb:

>>> Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst
>>> verloren
>>
>> Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar,
>> dass keine (internationale) Großprojekterfahrung vorhanden ist oder die
>> menschliche Reife, andere Denkmodelle zuzulassen.

>
> Internationale Großprojekte und SCRUM? Hat man dir das in deiner Dorf
> Hinterhof klitsche erzählt?

Wahrscheinlich bist es eher du, dessen Kopf nur in Dorf-Kategorien 
denken kann. SCRUM wurde für Grossprojekte hockskaliert, beispielsweise 
als SAFe:
Scaled agile framework

Anhang nach: https://isapm.org/safe-solutions/

Siehe auch: https://de.wikipedia.org/wiki/Scaled_Agile_Framework

von Peter A. (Gast)


Lesenswert?

Dieses Diagramm zeigt die perversen Auswüchse der Generation Powerpoint. 
Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen? 
Kein Wunder, dass nichts voran geht weil alle nur noch mit der 
Einhaltung von SCRUM und Konsorten beschäftigt sind.

von Kindergärtner (Gast)


Lesenswert?

Peter A. schrieb:
> Dieses Diagramm zeigt die perversen Auswüchse der Generation
> Powerpoint.
> Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen?
> Kein Wunder, dass nichts voran geht weil alle nur noch mit der
> Einhaltung von SCRUM und Konsorten beschäftigt sind.

Ich verweise an die unbeantworteten Fragen: 
Beitrag "Re: SCRUM und die Arbeitsweise von Selbständigen"

von Peter A. (Gast)


Lesenswert?

Kindergärtner schrieb:
> Peter A. schrieb:
>> Dieses Diagramm zeigt die perversen Auswüchse der Generation
>> Powerpoint.
>> Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen?
>> Kein Wunder, dass nichts voran geht weil alle nur noch mit der
>> Einhaltung von SCRUM und Konsorten beschäftigt sind.
>
> Ich verweise an die unbeantworteten Fragen: Beitrag "Re: SCRUM und die
> Arbeitsweise von Selbständigen"

Kindergärtner schrieb:
> Peter A. schrieb:
>> Dieses Diagramm zeigt die perversen Auswüchse der Generation
>> Powerpoint.
>> Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen?
>> Kein Wunder, dass nichts voran geht weil alle nur noch mit der
>> Einhaltung von SCRUM und Konsorten beschäftigt sind.
>
> Ich verweise an die unbeantworteten Fragen: Beitrag "Re: SCRUM und die
> Arbeitsweise von Selbständigen"

Vielleicht bist du in deinem Kindergarten besser aufgehoben. Unter 
erwachsenen scheint du recht unsicher zu sein.

von Selbständiger (Gast)


Lesenswert?

SCRUM Training Schmitz schrieb im Beitrag #7323278:
> solange die externen Mitarbeiter in das Team integriert werden
So von der Seite eingeworfen, scheint mir das aber sehr verdächtig zu 
sein, denn "eingebunden ins Team" ist eben nicht selbständig. Denn:

Wieso sollte jemand täglich von seiner Arbeit berichten, wenn andere das 
gar nicht verwerten können, weil sie an anderen Dingen arbeiten? Und 
wieso sollte der Selbständige täglich 1:1 mitbekommen, woran die anderen 
arbeiten, wenn er das ebenfalls nicht auswerten kann, weil er ein 
eigenes Projekt hat?

Wozu? Ich habe schon mehrere solcher Projekte gemacht und beobachte in 
vielen Abteilungen wie nutzlos das SCRUM ist - gerade für uns Externe.

Aus meiner Sicht kann und muss das tägliche meeting völlig getrennt 
laufen. Der Projektleiter fragt den Selbständigen, wo er steht und 
koordiniert das mit dem Team und fragt das Team parallel. Genau so, wie 
er die internen Teams parallel abfragt, die nicht an derselben SW 
arbeiten. So sehr viel sollte es da auch nicht zu synchronisieren geben, 
weil es eine abgetrennte Aufgabe sein muss, die der Externe erledigt.

Wenn es nötig oder möglich ist, dass der Externe im Team mitwirkt und 
mitdiskutiert, dann beeinflusst er die anderen Festangestellten und wird 
von diesen beeinflusst. Die Mitwirkung in einem SCRUM-Team ist aus 
meiner Sicht ein klares Indiz für das Eingebunden sein in einer Gruppe 
und damit für unselbständiges Arbeiten, weil die Aufgaben dann hin- und 
her fließen, da diese ja vom Team verteilt werden. Eine solche Rolle ist 
höchst kritisch. Einzig der Scrum Master kann ein Selbständiger Externer 
sein, der die gesamte Ausarbeitung macht, weil er ja gar nicht so über 
die Inhalte Bescheid wissen muss, sondern nur die formale Abwicklung 
macht.

Wenn diese enge Abstimmerei aber nicht passiert und der Externe nur 
nebenher mitläuft, dann braucht er die anderen und deren Reports auch 
nicht und kann seinen Status dem PL direkt melden. Eine Mitwirkung IM 
Team ist also unsinnig.

Der Punkt ist nämlich der:

An wen berichtet ein Externer? Normalerweise ist der Auftraggeber des 
Externen die Geschäftsleitung, die entweder den Abteilungsleiter oder 
den Projektleiter benennt, der als Kommunikator dient. Der 
Geschäftspartner des Externen ist der Einkäufer der Firma. Die Senior 
Entwickler oder andere, haben ihm demgemäß gar nichts zu sagen und er 
muss sich auch nicht mit diesen abstimmen. Die haben nichts mit dem 
Projekt des Externen zu tun. Genau wie der Teamleiter der SW nichts mit 
den Abläufen im HW-Team zu tun hat. Die Berichtskette ist ja schon dort 
aufgetrennt und läuft parallel.

Daher läuft die Kommunikation eines Externen normalerweise immer über 
den PL, der die technischen Zusammenhänge kennt und die Termine macht.

In einem SCRUM-Team ist der technisch bestimmende Part der Product 
Owner. Der wäre auch derjenige, der bestimmt, was der Externe überhaupt 
macht. Der muss den Auftrag an den Einkäufer geben und die spätere 
Abnahme machen. Der Scrum-Master oder das Team haben damit genau 
genommen, gar nichts zu tun, weil es ein paralleles System ist. Das 
Problem entsteht natürlich dann, wenn das ein und dieselbe Person ist. 
Der muss das dann von sich aus trennen.

Aus meiner Sicht gibt es keinen Grund für ein tägliches meeting mit 
Externen. Das ist weder formell noch inhaltlich nötig. Was die Sprints 
angeht, sollte sich der Projektleiter einfach vom Team die Sprintplanung 
geben lassen oder erarbeiten und sie mit den Tasks der Externen 
synchronisieren. Das reicht völlig, im 2-3-Wochen-Rhythmus.

Tägliche Arbeitskontrolle mit typischen Sprintplanungen von Einzeltasks 
und Abhaken der TODOs hat nämlich noch einen weiteren Negativpunkt: Die 
Tasks sind auf wenige Stunden zeitlich geplant und werden getrackt. Das 
entspricht einer Zeiterfassung! und die ist nach neuester Rechtsprechung 
ein weiteres Indiz für Scheinselbständigkeit -> siehe die 
Plattformdiskussion.

Der saubere Weg wäre also, die Tasks zu größeren Blöcken 
zusammenzufassen und nur Endtermine zu definieren. Das geht z.B. in JIRA 
sehr elegant, indem die Internen täglich ihre Subtasks abhaken, die 
Externen aber nur im 3W-Rhytmus vor deren Sprint-Review dabei sind und 
den Status vermelden. Die haben nur 3-4 große Main-Tasks, die zu eben 
jenem Termin abgehakt werden.

Hier läuft das aktuell so, dass es z.B. einen Werkvertrag gibt für 
"Testsoftware" zu 3 Monaten. Liefertermin von 31.3.2013. Dann gibt es 4 
große Module, die ausgeliefert werden. Der Werkvertragler liefert die 4 
Module genau zum Zeitpunkt 1+2 am 28.Feb und 3+4 am 31.3 und kriegt die 
vereinbarten Zahlungen. Dazwischen passiert nichts. Er soll sich nur 
melden, wenn er droht die Termine zu verletzen.

Wir Dienstvertragler stückeln unsere Module in ähnlicher Weise, 
kommunizieren unterwegs einmal die Woche die Prozente und ob wir im Plan 
sind. Da wir im Plan sein sollen, verarbeiten wir so viele Stunden, wie 
nötig. Daher werden dann einmal 35h, einmal 42h und einmal 47h die Woche 
abgerechnet. Klappt was nicht, muss man eben Termine verschieben, was 
der Kunde zu akzeptieren hat. Wir tragen die beanspruchten Zeiten einmal 
die Woche in eine Zeiterfassung ein und melden es verbal. Dann geht 
einmal im Monat die formelle Stundenmeldung raus. Der PL hakt es dann 
ab.

Daraufhin gibt es einmal im Monat eine Rechnung mit wechselnden Stunden. 
Ich rechne noch Anfahrten und Extra-Sätze ab, wenn ich hingefahren bin. 
Die Werkvertragler kriegen in der Regel Tranchen: 20% bei Auftragsbeginn 
und die anteiligen Prozente je Termin, hier also z.B. 40% + 40% nach 2 
Lieferterminen. Also Festsumme.

Vorzugsweise sollte man Werkvertrag machen, um sich vor all zu viel 
Aufwand  und TammTamm zu schützen. Das ist für beide Seiten das Beste. 
Nur muss man bei den weichen Definitionen des Kunden immer soviel Zusatz 
einplanen, dass es enorm teuer wird. Ich persönlich mache daher gerne 
Dienstverträge als Berater, erarbeite durchaus Pläne für andere, mache 
dies und das, habe aber im Vertrag nur ein-zwei wenige Hinweise stehen, 
was ich überhaupt mache und lasse mich nicht auf Anwesenheit oder 
Liefertermine festnageln. Der PL bekommt von mir einen Arbeitsplan, in 
dem alles verzeichnet ist, was aus meiner Sicht anfällt. Dann lässt sich 
schön aufzeigen, was sie immer so alles vergessen haben und ihnen noch 
einfällt.

Wenn die Firma mit SCRUM arbeitet, soll sie es machen: Ich schalte mich 
drauf, trinke meinen Kaffe und lasse mir die Zeit bezahlen. Der PL 
kriegt von mir 3-4 Stichworte, was ich in den nächsten Wochen tun werde 
und das ist so allgemein und konservativ, dass ich nicht dagegen 
verstoße oder es überziehe. Momentan mache ich gerade "Einarbeitung neue 
Requirements" in den Code. Da die sich täglich ändern, ist das eine 
neverending Story.

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]
  • [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.

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