Es ist mir klar, dass ich schon radikale Meinungen habe... :-)
Ich moechte ein bisschen hier an dieser Stelle mein Hintergrund ansprechen, das koennte helfen, so hoffe ich jedenfalls, solche radikale Ansichten nachzuvollziehen.
1. Ich bin nun mal Deutscher (trotz oder gerade weil ich im Ausland aufgewachsen bin: ich bin naemlich in einem Deutschen Haushalt aufgewachsen, mit Deutscher Kultur. Ich bin von der Propaganda der Nachkriegszeit in Deutschland nicht in uebermass beeinflusst worden). Und als Deutscher versuche ich auch immer alles richtig zu machen (deswegen vielleicht arbeite ich auch in erster Linie bei der Qualitaetssicherung).
2. Ich habe Mathematik studiert. Mathe ist doch ein Fach fuer Faule (bitte beachten Sie diese Aussage ganz genau!), fuer Leute die, wie ich, es vorziehen 5 Male zu denken bevor sie etwas tun, dafuer aber richtig. Mathematiker sind Menschen, welche die ganze Zeit versuchen Prozesse zu optimieren, Vorgaenge zu verbessern. Nicht, wie ein lieber Freund von mir behaupten wuerde, weil wir "Gutmenschen" sind, nein; aus Faulheit!
Aus diesem Hintergrund heraus wird es fuer jedermann/jedefrau so weit nachvollziehbar, hoffe ich zumindest, warum ich so denke wie ich denke.
Beschreibung des Ist-Zustandes: Es ist doch so, dass Vorgesetzte mit wenig Ahnung sehr schnell bei der Sache sind, Meetings aufzurufen. Meetings werden also vorgetragen von Personen mit wenig (oder gar keine) Vorbereitung und besucht von Menschen, die oft genug das vermeintlich erteilte Wissen von Meetings ueberhaupt nicht brauchen.
Damit sind Meeting Zeitfresser der uebelsten Sorte:
1. Es gibt Leute (keine Mathematiker ;-) die durch Meetings das Gefuehl kriegen, viel "gemacht" zu haben (mit kaum eine/eigene Anstrengung)
2. Meetings fressen Zeit von Menschen, die das zu ermittelnde Wissen brauchen, es aber unstrukturiert und unvollstaendig durch unvorbereitete Vortrage erhalten (sollen)
3. Fressen Zeit von Menschen, die nur ein Teil (wenn ueberhaupt) der Vortrages brauchen.
Hier einige eigene Gedanken, um Meetings ein Mindestmass an Nutzen einzuhauchen.
Check-Liste zur Verbesserung von Meetings
1. Vorbereiten: Ziel; Was genau ermittelt werden soll
2. Benoetigte Zeit genau festlegen (Zielzeit)
3. Vorbereitung der Teilnehmer (!) Stoff im Vorwege zusenden und Fragen den Teilnehmer vorbereiten lassen (und diesen Punkt hier ist der "Kasus Knaktus")
4. Am Besten die Fragen von Punkt 3. den Vortragenden mitteilen
5. Nacharbeit: Zusammenfassung des Vortrages mit FAQs an alle Teilnehmer zusenden
6. Bei jeder Teilnehmer definieren, warum er/sie teil nehmen soll (sonst keine Teilnahme!)
Es gibt natuerlich Meetings die wichtig sind, z.B. wenn eine Gruppe Designer und Entwickler Teile einer SW definieren muessen. Da hilft natuerlich die Check-Liste sehr, zwecks Definition, was genau das Ergebnis sein soll.
Ich kann mir schon vorstellen, dass ca 90 bis 95 % aller Meetings zwar notwendig sind, doch die Zeit kann man sicherlich halbieren: Ein einstuendiger Meeting kann in 10 Minuten gehalten werden, dazu kommen 15 Minuten Vorbereitung plus 5 Minuten Nacharbeit.
Nachtrag: 37Signals, eine Firma mit der ich keinerlei geschaeftlichen Verbindungen habe, teilt aber meine Meinung ueber Meetings (sie schreibt: Meetings are toxic).
Dienstag, 11. Dezember 2012
Montag, 26. November 2012
Der Untergang des Titanics aus der Perspektive eines Qualitaetssicherers
Der Fall "Titanic" ist laengst untersucht in allen Einzelheiten.
Also mache ich es kurz nur mit einigen Gedanken aus der Perspektive der Qualitaetssicherung.
Welche waren die Ursachen fuer das Unglueck?
Warum mussten Menschen sterben?
Ganz knapp sind 2 Tatsachen dafuer zu nennen:
1. Das Schiff fuhr zu schnell
2. Es gab nicht genug Rettungsboote fuer alle Passagiere
Und... Warum war das Schif zu schnell?
War der Kapitaen leichtsinnig?
Es war doch seine letzte Fahrt. Alt genug war er also und Erfahrung soll man ihm nicht absprechen. Und schnell soll er gewesen sein weil er einen neuen Rekord aufstellen wollte. So wird es zumindest berichtet. Glauben soll man es nicht unbedingt (wo so viele Sachen, die berichtet werden, oft -sehr oft- gelogen oder bestenfalls erfunden sind). Doch Leichtsinn moechte ich ihm (aufgrund seines Berufslebens) nicht bescheinigen. Warum war er dann zu schnell?
Und warum gab es fuer alle Passagiere nicht genug Rettungsboote?
Auch leichtsinn?
Ja...
Eine Antwort die zu beide Fragen passt und noch dazu schoen geschichtlich belegt ist, ist die, dass das Schiff als unsinkbar galt.
Wenn man oft genug eine idiotische Aussage hoert, dann glaubt man am Ende langsam daran.
Sogar ein alter Kapitaen scheint daran geglaubt zu haben. Er haette es besser wissen, naemlich: Alles sinkt, wenn der Schaden bloss gross genug ist.
Alles. Holz- und Metalschiffe. Einruempfige und mehrruempfige Schiffe, alles.
Wenn der Glaube, dass das Schiff "unsinkbar" war, die Grundlage fuer den Leichtsinn zu gelten hat, dann wuerde ich behaupten, dass die Qualitaetssicherung ganz miserabel gegenueber der Werbung und den Slogansmachern versagt hat.
Die ernuechtende Qualitaetssicherung-Aussage "Alles sinkt wenn der Schaden gross genug ist" wurde ausser Acht gelassen, verdraengt durch die (falsche aber werbewirksame) Aussage "unser Schiff sinkt nicht". Und alle Menschen scheinen es geglaubt zu haben. Auch die, die das eigene Leben aufs Spiel gesetzt haben.
Heutzutage gibt es mehr Regel und Gesetze, Schiffe muessen genug Rettungsboote fuer alle haben. So etwas kann eigentlich nicht mehr vorkommen.
Doch das Problem liegt, meiner Ansicht nach, daran, dass Werbeslogans mehr "gewicht" haben als nuechterndes Ingenieurwissen... schlimmer noch, sie haben mehr gewicht sogar als jahrelanges Berufswissen oder gar schlichter Vernunft.
Oder liegt es eher daran, dass ueber die Werbung nicht nachgedacht wird?
Oder daran, dass, wenn eine Aussage oft genug wiederholt wird, diese geglaubt wird, ohne nachzudenken?
Und, was damals geschah, kann sich doch jederzeit wiederholen.
Nur weil man nicht ueberlegt...
Qualitaetssichern bedeutet ueberlegen. Haette doch damals geholfen, denke ich.
Also mache ich es kurz nur mit einigen Gedanken aus der Perspektive der Qualitaetssicherung.
Welche waren die Ursachen fuer das Unglueck?
Warum mussten Menschen sterben?
Ganz knapp sind 2 Tatsachen dafuer zu nennen:
1. Das Schiff fuhr zu schnell
2. Es gab nicht genug Rettungsboote fuer alle Passagiere
Und... Warum war das Schif zu schnell?
War der Kapitaen leichtsinnig?
Es war doch seine letzte Fahrt. Alt genug war er also und Erfahrung soll man ihm nicht absprechen. Und schnell soll er gewesen sein weil er einen neuen Rekord aufstellen wollte. So wird es zumindest berichtet. Glauben soll man es nicht unbedingt (wo so viele Sachen, die berichtet werden, oft -sehr oft- gelogen oder bestenfalls erfunden sind). Doch Leichtsinn moechte ich ihm (aufgrund seines Berufslebens) nicht bescheinigen. Warum war er dann zu schnell?
Und warum gab es fuer alle Passagiere nicht genug Rettungsboote?
Auch leichtsinn?
Ja...
Eine Antwort die zu beide Fragen passt und noch dazu schoen geschichtlich belegt ist, ist die, dass das Schiff als unsinkbar galt.
Wenn man oft genug eine idiotische Aussage hoert, dann glaubt man am Ende langsam daran.
Sogar ein alter Kapitaen scheint daran geglaubt zu haben. Er haette es besser wissen, naemlich: Alles sinkt, wenn der Schaden bloss gross genug ist.
Alles. Holz- und Metalschiffe. Einruempfige und mehrruempfige Schiffe, alles.
Wenn der Glaube, dass das Schiff "unsinkbar" war, die Grundlage fuer den Leichtsinn zu gelten hat, dann wuerde ich behaupten, dass die Qualitaetssicherung ganz miserabel gegenueber der Werbung und den Slogansmachern versagt hat.
Die ernuechtende Qualitaetssicherung-Aussage "Alles sinkt wenn der Schaden gross genug ist" wurde ausser Acht gelassen, verdraengt durch die (falsche aber werbewirksame) Aussage "unser Schiff sinkt nicht". Und alle Menschen scheinen es geglaubt zu haben. Auch die, die das eigene Leben aufs Spiel gesetzt haben.
Heutzutage gibt es mehr Regel und Gesetze, Schiffe muessen genug Rettungsboote fuer alle haben. So etwas kann eigentlich nicht mehr vorkommen.
Doch das Problem liegt, meiner Ansicht nach, daran, dass Werbeslogans mehr "gewicht" haben als nuechterndes Ingenieurwissen... schlimmer noch, sie haben mehr gewicht sogar als jahrelanges Berufswissen oder gar schlichter Vernunft.
Oder liegt es eher daran, dass ueber die Werbung nicht nachgedacht wird?
Oder daran, dass, wenn eine Aussage oft genug wiederholt wird, diese geglaubt wird, ohne nachzudenken?
Und, was damals geschah, kann sich doch jederzeit wiederholen.
Nur weil man nicht ueberlegt...
Qualitaetssichern bedeutet ueberlegen. Haette doch damals geholfen, denke ich.
Sonntag, 4. November 2012
REQB Pruefung Foundation Level - Ein Erfahrungsbericht
Die Pruefung sehr geradeaus, sehr an das Syllabus angelehnt. Die ersten 22 Fragen sehr einfach zu beantworten, "Negationen" sind mir nicht aufgefallen.
Nur selten hatte ich Schwierigkeiten, Fragen zu beantworten. Allerdings bin ich ziemlich suspect der Pruefung gegenueber gewesen, weil ich schon bei der ISTQB FL mir ziemlich sicher war, dass es gut gelaufen war; ich hatte doch auf etwa 95% richtige Antworten in den Mock Exams aus dem Internet, zwar waren die Fragen etwas anders in der wahren Pruefung, doch schwieriger kamen sie mir ueberhaupt nicht vor. Nun hatte ich aber "nur" 2 mehr richtig, als notwendig, und damit eigentlich die Pruefung mit "gerade ausreichend" bestanden. Man kann dazu bemerken, dass ich schon seit gut 12 Jahre bei der Qualitaetssicherung arbeite und vielleicht mehr auf Erfahrung als auf Wissen gesetzt habe. Ausserdem hatte ich schon auch bemerkt, dass die gleiche Frage in verschiedenen Mock Exams teils als falsch teils als richtig bewertet wurde. Nichtdestotrotz bin ich mit dem Ergebnis (meine Leistung) der ISTQB FL eher unzufrieden. Aus dieser Erfahrung heraus habe ich auch die REQB sehr "ordentlich" vorbereitet. Ausserdem gibt es im Internet gar keine Mock Exams fuer REQB und sonst keine Muster, so dass ich ganz und gar auf das Syllabus und anderen theoretischen Informationen mich verlassen musste. Dadurch bedingt habe ich auch die Fragen bei der Pruefung sehr genau gelesen.
Bei der Frage wo ich sehr unsicher war: Welche IEEE Norm gilt fuer die Spezifikation von System Funktionalitaet.
Nur unsicher war ich mir bei der Frage; wenn man dabei ist, einer "Solution Spec" zu schreiben, genauer "detailed high level req", und man hat schon das System definiert, die low-level req. spezifiziert, dokumentiert und aneinander in Relation gebracht u.s.w.; was macht man als Naechstes?
- REQ Analysis
- Solution modellieren
- Solution festlegen
Im letzten Teil der Pruefung jedoch, genauer REQ Analysis (auch "Tools" ganz am Ende mit nur 3 Fragen) ist mir aufgefallen, dass viele, viele Fragen mit Negationen behaftet waren, in der Art:
"Welche Aussage gilt NICHT fuer XY (wenn XZ) ?"
Da sollte man schon etwas genauer die richtige Antwort (die falsche) markieren.
Mehr als Definitionen von SysML und UML sollte man nicht wissen; OK, die Charakteristiken der beiden und die Unterschiede zwischen den beiden sollte man schon wissen.
Eine Frage war wohl; was fuer ein UML Diagramm man waehlen wuerde um die Stationen eines Dokuments in einem Document-Management-System darzustellen.
Das Gleiche ueber Agile Methoden... eine Frage gab es, dabei mussste man schon wissen was ein Backlog ist und was nicht.
Summa summarum: Meines Erachtens nach, wenn man erst das Syllabus durcharbeitet, (spricht auch die Fehler des Syllabus erkennen und beseitigen, dann das Richtige und Wichtige verstehen), dazu erstmals und zusaetzlich die Grundlagen von verwandten Themen wie UML (Modellierung) und Entwicklungsmethoden (Agile Methoden) durchlesen, dann hat man eine gute Basis, die Pruefung zu schaffen.
Hier kann man neine eigene Ueberarbeitung des Syllabus runterladen: Ich hatte die englische Version bearbeitet, die Kommentare jedoch sind auf Deutsch:
http://www.scribd.com/doc/110113815/reqb-syllabus
Nur selten hatte ich Schwierigkeiten, Fragen zu beantworten. Allerdings bin ich ziemlich suspect der Pruefung gegenueber gewesen, weil ich schon bei der ISTQB FL mir ziemlich sicher war, dass es gut gelaufen war; ich hatte doch auf etwa 95% richtige Antworten in den Mock Exams aus dem Internet, zwar waren die Fragen etwas anders in der wahren Pruefung, doch schwieriger kamen sie mir ueberhaupt nicht vor. Nun hatte ich aber "nur" 2 mehr richtig, als notwendig, und damit eigentlich die Pruefung mit "gerade ausreichend" bestanden. Man kann dazu bemerken, dass ich schon seit gut 12 Jahre bei der Qualitaetssicherung arbeite und vielleicht mehr auf Erfahrung als auf Wissen gesetzt habe. Ausserdem hatte ich schon auch bemerkt, dass die gleiche Frage in verschiedenen Mock Exams teils als falsch teils als richtig bewertet wurde. Nichtdestotrotz bin ich mit dem Ergebnis (meine Leistung) der ISTQB FL eher unzufrieden. Aus dieser Erfahrung heraus habe ich auch die REQB sehr "ordentlich" vorbereitet. Ausserdem gibt es im Internet gar keine Mock Exams fuer REQB und sonst keine Muster, so dass ich ganz und gar auf das Syllabus und anderen theoretischen Informationen mich verlassen musste. Dadurch bedingt habe ich auch die Fragen bei der Pruefung sehr genau gelesen.
Bei der Frage wo ich sehr unsicher war: Welche IEEE Norm gilt fuer die Spezifikation von System Funktionalitaet.
Nur unsicher war ich mir bei der Frage; wenn man dabei ist, einer "Solution Spec" zu schreiben, genauer "detailed high level req", und man hat schon das System definiert, die low-level req. spezifiziert, dokumentiert und aneinander in Relation gebracht u.s.w.; was macht man als Naechstes?
- REQ Analysis
- Solution modellieren
- Solution festlegen
Im letzten Teil der Pruefung jedoch, genauer REQ Analysis (auch "Tools" ganz am Ende mit nur 3 Fragen) ist mir aufgefallen, dass viele, viele Fragen mit Negationen behaftet waren, in der Art:
"Welche Aussage gilt NICHT fuer XY (wenn XZ) ?"
Da sollte man schon etwas genauer die richtige Antwort (die falsche) markieren.
Mehr als Definitionen von SysML und UML sollte man nicht wissen; OK, die Charakteristiken der beiden und die Unterschiede zwischen den beiden sollte man schon wissen.
Eine Frage war wohl; was fuer ein UML Diagramm man waehlen wuerde um die Stationen eines Dokuments in einem Document-Management-System darzustellen.
Das Gleiche ueber Agile Methoden... eine Frage gab es, dabei mussste man schon wissen was ein Backlog ist und was nicht.
Summa summarum: Meines Erachtens nach, wenn man erst das Syllabus durcharbeitet, (spricht auch die Fehler des Syllabus erkennen und beseitigen, dann das Richtige und Wichtige verstehen), dazu erstmals und zusaetzlich die Grundlagen von verwandten Themen wie UML (Modellierung) und Entwicklungsmethoden (Agile Methoden) durchlesen, dann hat man eine gute Basis, die Pruefung zu schaffen.
Hier kann man neine eigene Ueberarbeitung des Syllabus runterladen: Ich hatte die englische Version bearbeitet, die Kommentare jedoch sind auf Deutsch:
http://www.scribd.com/doc/110113815/reqb-syllabus
Samstag, 27. Oktober 2012
Kurze Auslassung ueber "Agile Methoden"
Zurzeit leide ich unter die Ignoranz eines (oder mehrerer) einfaeltigen Manager(s), die irgendwie geglaubt haben muessetn, dass wenn etwas sich "agil" nennt, es auch irgendwie sein soll.
Nichts da. Pustekuchen.
Ja, "leiden"; ich habe naemlich eine nicht zu unterschaetzenden Schwierigkeit mit Zeitverlust und Unueberlegenheit.
Bei mir auf der Arbeit wurde so eine "agile" Methode vorgeschrieben. Und zwar die (von meiner Sicht der Sache heraus) schlimmste von allen: Scrum.
Scrum auf deutsch bedeutet "Gedraenge". Was daran gut sein soll, ist mir ein einziges Raetsel. Sowohl an einem echten "Gedraenge" als auch in der Art und Weise, wie diese "Methode" durchgefuehrt wird.
Zunaechst ist auffallend, dass gewoehnliche Dinger bei den Scrum-Propheten mit anderen Namen genannt werden. So gibte es "Sprint" fuer Etappen, Backlog fuer Beschreibungen und das mieseste von allem sind die User Stories. Die gesamte beschriebene "Methode" ist eine Zwangsjacke (de Benutzung des Wortes "Methode" ist weitgehend verfehlt): Man wird gezwungen, anstatt Funktionalitaet, Wuensche bzw Beduerfnisse aus der Sicht eines Benutzers ganz knapp zu (be)schreiben. Ein Beispiel? Bitte schoen: "Als Kranfahrer moechte ich eine Software, was mir die taeglichen Berichte schreibt". Warum abweichende Namen fuer die Sachen? Eine logische Erklaerung gibt's nicht, wahrscheinlich will man irgendwie versuchen, mit positiven Begriffen die Untauglichkeit der "Methode" zu vertuschen.
Ganz wichtig dabei ist, dass der "Kunde" ganz eng mit den Entwicklern zusammenarbeiten muss. In unserem Fall muesste der Kranfahrer jede 2 oder 3 Tage bei den Entwicklern den Fortschritt der Arbeit kontrollieren, sonst wurde am Ende eines "Sprints"... doch nichts Brauchbares rauskommen.
Es ist natuerlich klar, dass ohne genaue Produktbeschreibung die Anwesenheit von Kranfuehrern und Chirurgen und Diplomaten sogar vonnoeten ist, um die SW schreiben zu koennen.
Stoerend wirken sich auch die vorgeschriebenen taeglichen Scrum-Meetings. Diese reissen die Entwickler von der Arbeit weg, und dann wird -alle zusammen stehend- Produktdesign in Mikrosteps gemacht. Ein Scrum-Meeting sollte nicht mehr als 15 Minuten dauern, bei uns dauern sie mindestens 15 Minuten, 1 oder 2 Male in der Woche etwa 30 Minuten, naemlich dann, wenn einen groesseren Step oder Aenderung in dem Design vollzogen werden muss. Nach dem Meeting ist es stets muehsam, sich der abgebrochenen Aufgabe wieder zu widmen. Meine Meinung? Scrum ist fuer ganz besonders Faule, die nicht schreiben koennen und in den Tag hinein zu leben pflegen.
Eine nicht so bescheuerte aber dafuer fast noch zeitraubender Sache -weil uneffizient (sogar mit den taeglichen Scrum-Meetigs verglichen!)-, sind die monatlichen Sprint-Meetings, wo jeder Entwickler selbst, aber in Beisammensein von allen, den Scrummaster schreiben laesst, was er so zu tun beabsichtigt fuer den kommenden Sprint. Dauert etwa 2 Stunden einmal pro Monat bei uns.
Die Scrum "Methode" ist wohl mit einer grossen Anzahl an Meetings versehen, wohl die vielen Studien ignorierend, die schon vor etlichen Jahren herausgefunden haben, was fuer ein Zeitverlust die Meetings darstellen. Ich schaetze, dass mehr als "ignorierend" gilt "Ignoranz": Das Lesen ist keine Staerke der "Gedraenge"-Apostel.
Der Grundgedanke der agilen Methoden, die sich selbst verwaltenden, organisierenden Entwicklerteams ist an sich nicht falsch. Mit Intelligenz angewendet duerften sie sicherlich gute Ergebnisse liefern. Doch, wenn man die Methoden unreflektiert implementiert, dabei es sich auch um eine der "agilen" (ich lache und heule gleichzeitig) Methoden handelt, die am unflexibelsten ist, mit gezwungen vorgeschriebenen Massnahmen... so sollte man eigentlich nicht ueberrascht sein, wenn die Ergebnisse eher ernuechternd wirken.
Es wird zwar behauptet, dass mit Hilfe der Sprints die Produktivitaet steigt (trotz haufenweise unnoetigen Meetings) weil in kuerzeren Etappen "brauchbare Produkte" erzeugt werden (z.B. Prototypen, ungetestete Module, getestete nicht integrierten Module, usw usf). Tja... Wunschdenken ist maechtig. Und ich bestreite nicht einmal (warum sollte ich?), dass die Effektivitaet steigt... leider sinkt dafuer die Effizienz um so mehr.
Bei uns ist nun der Geschaeftsfuehrer Scrummaster geworden. Macht er ganz gut; er laesst sich nicht merken, ob ihm die "Methode" nervt. Vielleicht glaubt er daran, er muesste naemlich; das ist sein Job...
Sicher gibt es Faelle, wo eine Scrummethode gut angewendet werden kann. Doch es sollte genau abgewogen werden, welche Vor- und Nachteile damit verbunden sind. Das blinde Anwenden eine Methode ohne Pruefung, ohne Anpassung, wenn sogar, wie in unserem Falle, einige der "zu empfehlen bei" nicht gegeben sind... das ist alles andere als durchdacht.
Zu empfehlen hierzu sind die Artikel und Buecher bei oose.de
Lesen hilft...
Nichts da. Pustekuchen.
Ja, "leiden"; ich habe naemlich eine nicht zu unterschaetzenden Schwierigkeit mit Zeitverlust und Unueberlegenheit.
Bei mir auf der Arbeit wurde so eine "agile" Methode vorgeschrieben. Und zwar die (von meiner Sicht der Sache heraus) schlimmste von allen: Scrum.
Scrum auf deutsch bedeutet "Gedraenge". Was daran gut sein soll, ist mir ein einziges Raetsel. Sowohl an einem echten "Gedraenge" als auch in der Art und Weise, wie diese "Methode" durchgefuehrt wird.
Zunaechst ist auffallend, dass gewoehnliche Dinger bei den Scrum-Propheten mit anderen Namen genannt werden. So gibte es "Sprint" fuer Etappen, Backlog fuer Beschreibungen und das mieseste von allem sind die User Stories. Die gesamte beschriebene "Methode" ist eine Zwangsjacke (de Benutzung des Wortes "Methode" ist weitgehend verfehlt): Man wird gezwungen, anstatt Funktionalitaet, Wuensche bzw Beduerfnisse aus der Sicht eines Benutzers ganz knapp zu (be)schreiben. Ein Beispiel? Bitte schoen: "Als Kranfahrer moechte ich eine Software, was mir die taeglichen Berichte schreibt". Warum abweichende Namen fuer die Sachen? Eine logische Erklaerung gibt's nicht, wahrscheinlich will man irgendwie versuchen, mit positiven Begriffen die Untauglichkeit der "Methode" zu vertuschen.
Ganz wichtig dabei ist, dass der "Kunde" ganz eng mit den Entwicklern zusammenarbeiten muss. In unserem Fall muesste der Kranfahrer jede 2 oder 3 Tage bei den Entwicklern den Fortschritt der Arbeit kontrollieren, sonst wurde am Ende eines "Sprints"... doch nichts Brauchbares rauskommen.
Es ist natuerlich klar, dass ohne genaue Produktbeschreibung die Anwesenheit von Kranfuehrern und Chirurgen und Diplomaten sogar vonnoeten ist, um die SW schreiben zu koennen.
Stoerend wirken sich auch die vorgeschriebenen taeglichen Scrum-Meetings. Diese reissen die Entwickler von der Arbeit weg, und dann wird -alle zusammen stehend- Produktdesign in Mikrosteps gemacht. Ein Scrum-Meeting sollte nicht mehr als 15 Minuten dauern, bei uns dauern sie mindestens 15 Minuten, 1 oder 2 Male in der Woche etwa 30 Minuten, naemlich dann, wenn einen groesseren Step oder Aenderung in dem Design vollzogen werden muss. Nach dem Meeting ist es stets muehsam, sich der abgebrochenen Aufgabe wieder zu widmen. Meine Meinung? Scrum ist fuer ganz besonders Faule, die nicht schreiben koennen und in den Tag hinein zu leben pflegen.
Eine nicht so bescheuerte aber dafuer fast noch zeitraubender Sache -weil uneffizient (sogar mit den taeglichen Scrum-Meetigs verglichen!)-, sind die monatlichen Sprint-Meetings, wo jeder Entwickler selbst, aber in Beisammensein von allen, den Scrummaster schreiben laesst, was er so zu tun beabsichtigt fuer den kommenden Sprint. Dauert etwa 2 Stunden einmal pro Monat bei uns.
Die Scrum "Methode" ist wohl mit einer grossen Anzahl an Meetings versehen, wohl die vielen Studien ignorierend, die schon vor etlichen Jahren herausgefunden haben, was fuer ein Zeitverlust die Meetings darstellen. Ich schaetze, dass mehr als "ignorierend" gilt "Ignoranz": Das Lesen ist keine Staerke der "Gedraenge"-Apostel.
Der Grundgedanke der agilen Methoden, die sich selbst verwaltenden, organisierenden Entwicklerteams ist an sich nicht falsch. Mit Intelligenz angewendet duerften sie sicherlich gute Ergebnisse liefern. Doch, wenn man die Methoden unreflektiert implementiert, dabei es sich auch um eine der "agilen" (ich lache und heule gleichzeitig) Methoden handelt, die am unflexibelsten ist, mit gezwungen vorgeschriebenen Massnahmen... so sollte man eigentlich nicht ueberrascht sein, wenn die Ergebnisse eher ernuechternd wirken.
Es wird zwar behauptet, dass mit Hilfe der Sprints die Produktivitaet steigt (trotz haufenweise unnoetigen Meetings) weil in kuerzeren Etappen "brauchbare Produkte" erzeugt werden (z.B. Prototypen, ungetestete Module, getestete nicht integrierten Module, usw usf). Tja... Wunschdenken ist maechtig. Und ich bestreite nicht einmal (warum sollte ich?), dass die Effektivitaet steigt... leider sinkt dafuer die Effizienz um so mehr.
Bei uns ist nun der Geschaeftsfuehrer Scrummaster geworden. Macht er ganz gut; er laesst sich nicht merken, ob ihm die "Methode" nervt. Vielleicht glaubt er daran, er muesste naemlich; das ist sein Job...
Sicher gibt es Faelle, wo eine Scrummethode gut angewendet werden kann. Doch es sollte genau abgewogen werden, welche Vor- und Nachteile damit verbunden sind. Das blinde Anwenden eine Methode ohne Pruefung, ohne Anpassung, wenn sogar, wie in unserem Falle, einige der "zu empfehlen bei" nicht gegeben sind... das ist alles andere als durchdacht.
Zu empfehlen hierzu sind die Artikel und Buecher bei oose.de
Lesen hilft...
Samstag, 20. Oktober 2012
Was ist falsch mit Power Point?
Alles.
Ueber die Manager, die mittels PoPo (Power-Point) managen, habe ich mich schon frueher geaeussert.
Nun ist es dazu gekommen, dass ich in den letzten Wochen auf der Arbeit alte Kursunterlagen durchgegangen bin. Es sind der Art, dass "Folien" auf der Wand geschmissen werden, die in paar Begriffe beinhalten, und dann wird vom Vortragende in etwas abgewandelte Form den Inhalt wiederholt, waehrend die Zuhoerer gegen das Einschlafen kaempfen.
Mir hat diese Form des Unterrichts schon immer gestoert.
Gruend: Der Kampf gegen das Einschlafen ist dermassen ermuedend, dass man sich nicht auf die unsinnigen Folien konzentrieren kann.
Es gibt natuerlich viele andere Gruende, so z.B. kann sein, dass der Vortragende selbst den Stoff nur von Folien kennt (oder zumindest kriegt man allzuoft diesen Eindruck), kann also nichts dazu beitragen. Oder die Folien sind eine zusammenhangslose Anreihung von Woerter (sehr oft sogar ist diese Variante vorzufinden). Oder
Doch, wo liegt das Problem mit PoPo und die bunten Folien auf die Wand?
Zunaechst ist es positiv, dass der Vortragende (oder eine andere Person) eine huebsche Vorbereitung durchgefuehrt hat. Das spart doch Zeit. Man moechte annehmen, dass die Effektivitaet steigen duerfte.
Warum habe ich zumindest immer den Eindruck, nach so einem Kampf gegen das Einschlafen, dass so gut wie nichts haengengeblieben ist?
Hier einige Gedanken dazu:
1. Ich halte es fuer falsch, zu versuchen Wissen in vorgefertigten vordefinierten "Templates" zu bringen. Entweder ist man ein Genie und man kriegt es irgendwie doch fertig, trotz bunte Formgestaltung, Begriffssalat und Uebersichtslosigkeit, Wissen zu vermitteln, oder man ist hoffnungslos verwirrt in aufgezwungenen Schablonen. Der Sinn eines Vortrages ist Wissen zu vermitteln, dieser Ziel verfehlt man, wenn man PoPo benutzt.
2. Bedingt duch die vorgegebene Formatierung, so meine Einschaetzung, ist es schwierig einen "roten Faden" zu (be)folgen. Zumindest fuer den Zuhoerer, ist es nicht einfach aufgrund der Reihe an Begriffen, den Zusammenhanng und damit den "roten Faden" zu folgen. Da ist der Vortragende gefragt, diese fehlende Verbindung deutlich zu machen. Hier brauchen wir wieder den "Genie", der sich dies bewusst ist und nicht einfach den Inhalt der Folien mit anderen Woertern (so weit durchfuehrbar) wiedergibt.
3. Und es gibt noch einen Punkt, der zwar nicht immer auftreten soll, den ich jedoch auch noch ausfuehren will, weil... der kommt schon mehr als oft genug vor: Manglende Uebersicht bzw Eingliederung. Ist das nicht einleuchtend? Klar, ich werde etwas ausfuehrlicher erklaeren, was ich meine. Wenn man mitten im Vortrag eine Folie mit mehr oder minder viele Begriffe darauf hat und der Vortragende sich Muehe gibt zu erklaeren, was diese bedeuten und ggf. wie sie zusammenhaengen (bei den Besseren...) ist fuer der Zuhoerer oft gar nicht klar, zu welcher Ueberschrift diese Folien gehoeren. M.a.W. wo sie sich eingliedern.
Fazit: Sicher sind PoPo Folien ein Fortschritt und eine grosse Hilfe bei vielen Vortraegen, vor allem wenn man bunte Bilder hat und vor dem Auftraggeber den erfolgreichen Abschluss von Projektteilen naeher beibringen will. Ich halte jedoch die Benutzung von PoPo Folien zur Wissensvermittlung fuer schlichtweg falsch. Je komplexer das Wissen, desto ungeeigneter sind PoPo Folien.
Ueber die Manager, die mittels PoPo (Power-Point) managen, habe ich mich schon frueher geaeussert.
Nun ist es dazu gekommen, dass ich in den letzten Wochen auf der Arbeit alte Kursunterlagen durchgegangen bin. Es sind der Art, dass "Folien" auf der Wand geschmissen werden, die in paar Begriffe beinhalten, und dann wird vom Vortragende in etwas abgewandelte Form den Inhalt wiederholt, waehrend die Zuhoerer gegen das Einschlafen kaempfen.
Mir hat diese Form des Unterrichts schon immer gestoert.
Gruend: Der Kampf gegen das Einschlafen ist dermassen ermuedend, dass man sich nicht auf die unsinnigen Folien konzentrieren kann.
Es gibt natuerlich viele andere Gruende, so z.B. kann sein, dass der Vortragende selbst den Stoff nur von Folien kennt (oder zumindest kriegt man allzuoft diesen Eindruck), kann also nichts dazu beitragen. Oder die Folien sind eine zusammenhangslose Anreihung von Woerter (sehr oft sogar ist diese Variante vorzufinden). Oder
Doch, wo liegt das Problem mit PoPo und die bunten Folien auf die Wand?
Zunaechst ist es positiv, dass der Vortragende (oder eine andere Person) eine huebsche Vorbereitung durchgefuehrt hat. Das spart doch Zeit. Man moechte annehmen, dass die Effektivitaet steigen duerfte.
Warum habe ich zumindest immer den Eindruck, nach so einem Kampf gegen das Einschlafen, dass so gut wie nichts haengengeblieben ist?
Hier einige Gedanken dazu:
1. Ich halte es fuer falsch, zu versuchen Wissen in vorgefertigten vordefinierten "Templates" zu bringen. Entweder ist man ein Genie und man kriegt es irgendwie doch fertig, trotz bunte Formgestaltung, Begriffssalat und Uebersichtslosigkeit, Wissen zu vermitteln, oder man ist hoffnungslos verwirrt in aufgezwungenen Schablonen. Der Sinn eines Vortrages ist Wissen zu vermitteln, dieser Ziel verfehlt man, wenn man PoPo benutzt.
2. Bedingt duch die vorgegebene Formatierung, so meine Einschaetzung, ist es schwierig einen "roten Faden" zu (be)folgen. Zumindest fuer den Zuhoerer, ist es nicht einfach aufgrund der Reihe an Begriffen, den Zusammenhanng und damit den "roten Faden" zu folgen. Da ist der Vortragende gefragt, diese fehlende Verbindung deutlich zu machen. Hier brauchen wir wieder den "Genie", der sich dies bewusst ist und nicht einfach den Inhalt der Folien mit anderen Woertern (so weit durchfuehrbar) wiedergibt.
3. Und es gibt noch einen Punkt, der zwar nicht immer auftreten soll, den ich jedoch auch noch ausfuehren will, weil... der kommt schon mehr als oft genug vor: Manglende Uebersicht bzw Eingliederung. Ist das nicht einleuchtend? Klar, ich werde etwas ausfuehrlicher erklaeren, was ich meine. Wenn man mitten im Vortrag eine Folie mit mehr oder minder viele Begriffe darauf hat und der Vortragende sich Muehe gibt zu erklaeren, was diese bedeuten und ggf. wie sie zusammenhaengen (bei den Besseren...) ist fuer der Zuhoerer oft gar nicht klar, zu welcher Ueberschrift diese Folien gehoeren. M.a.W. wo sie sich eingliedern.
Fazit: Sicher sind PoPo Folien ein Fortschritt und eine grosse Hilfe bei vielen Vortraegen, vor allem wenn man bunte Bilder hat und vor dem Auftraggeber den erfolgreichen Abschluss von Projektteilen naeher beibringen will. Ich halte jedoch die Benutzung von PoPo Folien zur Wissensvermittlung fuer schlichtweg falsch. Je komplexer das Wissen, desto ungeeigneter sind PoPo Folien.
Samstag, 13. Oktober 2012
Das war 2011 (verspaetet)
In nachhinein betrachtet; es war kein gutes Jahr.
Aber, ganz kurz das Jahr ueberblickt:
Ich bin die 200, die 300 und die 400 Km Brevets in Oslo gefahren.
Bei der 600 Km war ich erkaeltet, bin also nicht gefahren. Um PBP (Paris-Brest-Paris) zu fahren muss man alle 4 Brevets beendet haben, als Qualifizierung.
Ich haette noch die Chance gehabt in Schweden die 600 zu fahren. Auch von der Osloer Abteilung wurde einen Nachbrevet organisiert, um zu qualifizieren. Ich aber beschloss mich nicht unter Zwang zu stellen und bin nicht gefahren. Mein Hintergedanken war doch, dass, wenn ich es nicht unter "normalen" Zustaende es schaffe, dann ist es "Schicksal", Zwang wuerde nur kontraproduktiv sein, am Ende wuerde etwas brechen. Als habe ich PBP fuer dieses Jahr abgeschrieben.
Nun aber lag Trondheim-Oslo (T-O) noch vor der Tuer. Mein lieber Freund AB hatte abgesagt, nachdem ihm die Frau die Ohren heiss gesprochen hatte, T-O nicht zu fahren. Also ich alleine. Und ich hatte geplant, am Freitag nachts zu starten und ueber Nacht zu fahren, 2 Stunden zu schlafen und das ganze in etwa 24 Stunden zu schaffen. Nun war das mit dem Schlafen im ABs Auto geplant, vorausgesetzt natuerlich die Frau faehrt es. Das ging also nicht mehr... Ich halte aber an dem originalen Plan fest. Auch ans Ankommen am Samstag gegen Mitternacht.
Nach einigen Zwischen-Hindernisse (AF hatte vergessen, mich/uns anzumelden,also starte ich unter "falschen" Namen nach Telefonat mit dem Kollege,der nicht zu fahren beabsichtigte). Zeitaenderung, da ich angebe innerhalb 24 Stunden ankommen zu wollen, starte ich also gegen 23 Uhr. Ich kann leider tagsueber nicht schlafen, wie ich geplant (erhofft?) hatte. Also muede starte ich: Kalt ueber Nacht, ich schlafe etwas bei dem 2. Stopp -ein Krog nach etwa 80 Km, genauer weiss ich es nicht, es sind die Raststaette fuer die "Nachtfahrer"-. Weiter geht es. Ich bin aber nicht motiviert, werde in der Ebene auch etwas langsam und merke, dass es schwierig wird, gegen Mitternacht anzukommen wie ich es geplant hatte. Beschliesse aufzugeben, in Lillehammer werde ich im Auto einsteigen. Das tue ich auch. Nur sind wir mit dem Auto erst gegen 1 oder 2 Uhr morgens in Oslo angekommen. Da haette ich doch auch mit dem Rad die Strecke gefahren und sogar frueher da gewesen. Na gut. Einmal sollte man auch T-O aufgegeben haben.
Das war also nicht gut: Fuer PBP nicht qualifiziert und T-O aufgegeben.
Und mein Auto wurde geklaut. In Oktober. Geklaut und versaut; die Armleuchte, die das Auto geklaut hat, hat den Feuerloescher im Auto entleert. Damit ist die Kiste kaum noch etwas Wert, Teil der Elektrik ausgefallen, und ich habe kein Vertrauen mehr in das Auto.
Doch es gab noch mehr, was im Jahr 2011 schief lief. Meine Liebste sollte Grossvater in Kanada besuchen um Enkelkind vorzufuehren. Flugtickets gekauft. Visum nicht bekommen. Nicht nur nicht bekommen, die kanadische Botschaft hat es verschlampt, mir das (von mir faelschlich) bezahlte Geld zurueckzubezahlen. Die kanadische Botschaft in Deutschland funktioniert nicht: Geld nicht zurueckbezahlt, ueber Email nicht erreichbar, keine Antwort auf meine Emails. Nichts. Ich mag die Sachen beim Namen zu nennen; die kanadische Botschaft ist ein Saftladen. Und was noch schlimmer ist, ist das ich das Gefuehl bekommen habe, dass die Botschaft es auf das Geld abgesehen hat. Schwer zu glauben, aber vom Benehmen her, ist das Veruntreuung von Gelder.
Ueberhaupt waren sie interessiert, dass man Geld bezahlt, und Trotz Einladung vom Bruder (kanadischer Staatsbuerger), dass die eine eingetragene Firma besitzt, dass sie ein geregeltes Einkommen und Familie und Rente hier hat, wollte man ihr das Visum nicht erteilen. Leider muss ich das Land Kanada nach seiner Behoerde im Ausland beurteilen. Diebe. Bis heute, etwa 12 Monate nach dem Vorfall, ... Schweigen in den Stuben...
Doch das war leider nur Geldverlust, dadurch gelernt, dass Kanada als eine Bande Betrueger zu betrachten ist.
Aber das Schlimmste kommt am Ende des Jahres. Ich plane, im naechsten Jahr (2012) die Marathon in Berlin zu laufen und beginne dafuer mit einem strikten Training, werde ziemlich fit und bin sehr motiviert (nicht mehr Rad zu fahren) zu laufen. Doch Anfang November habe ich einen Unfall mit dem Fahrrad, der 2. Tag nach der Zeitumstellung, von der Arbeit zurueck nach Hause, wache ich im Krankenhaus nach ca. 4 Stunden Bewusstlosigkeit. Angeblich habe ich einen "Fussgaenger" ueberfahren. Oslo ist bergisch und es war auf eine Bergab-Strecke, mit 1 Meter Radstreifen rechts von der Strasse, breit und gut sichtbar, ich schaetze ich hatte sicher mehr als 40km/h. Irgendein Idiot ist quer ueber die Strasse gelaufen (keine Zebrastreifen oder Ampel), wie die Leute es hier zu tun pflegen. Wahrscheinlich hat der Schwachsinniger sogar geguckt, aber kein Auto gesehen (Rad uebersehen, es war leider 2 Tage nach Zeitumstellung und damit ploetzlich fuer die "Tageszeit" dunkel).
Als die Polizei die "Ermittlungen" abgeschlossen hatte, ist, wie immer, nichts passiert. Beim Auto haben sie gesagt, sie haetten nicht genug Leute, um die Arbeit zu erledigen. Beim Unfall, dass, wenn ich es wuensche, kann ich mir die Akten angucken, bevor sie archiviert wird. Es ist mir schon klar, dass egal was passiert, es wird nichts passieren.
In mir, nach 4,5 Jahre Leben in Norwegen, gedeiht der Gedanke, Norwegen den Norwegen zu belassen. Ich bin und bleibe, nicht nur ein Auslaender, sondern vielmehr ein Fremder, da ich mich an dieser Schlamperei nicht anpassen moechte.
Was der Arbeit angeht, so ist das ein anderer Kapitel.
Aber, ganz kurz das Jahr ueberblickt:
Ich bin die 200, die 300 und die 400 Km Brevets in Oslo gefahren.
Bei der 600 Km war ich erkaeltet, bin also nicht gefahren. Um PBP (Paris-Brest-Paris) zu fahren muss man alle 4 Brevets beendet haben, als Qualifizierung.
Ich haette noch die Chance gehabt in Schweden die 600 zu fahren. Auch von der Osloer Abteilung wurde einen Nachbrevet organisiert, um zu qualifizieren. Ich aber beschloss mich nicht unter Zwang zu stellen und bin nicht gefahren. Mein Hintergedanken war doch, dass, wenn ich es nicht unter "normalen" Zustaende es schaffe, dann ist es "Schicksal", Zwang wuerde nur kontraproduktiv sein, am Ende wuerde etwas brechen. Als habe ich PBP fuer dieses Jahr abgeschrieben.
Nun aber lag Trondheim-Oslo (T-O) noch vor der Tuer. Mein lieber Freund AB hatte abgesagt, nachdem ihm die Frau die Ohren heiss gesprochen hatte, T-O nicht zu fahren. Also ich alleine. Und ich hatte geplant, am Freitag nachts zu starten und ueber Nacht zu fahren, 2 Stunden zu schlafen und das ganze in etwa 24 Stunden zu schaffen. Nun war das mit dem Schlafen im ABs Auto geplant, vorausgesetzt natuerlich die Frau faehrt es. Das ging also nicht mehr... Ich halte aber an dem originalen Plan fest. Auch ans Ankommen am Samstag gegen Mitternacht.
Nach einigen Zwischen-Hindernisse (AF hatte vergessen, mich/uns anzumelden,also starte ich unter "falschen" Namen nach Telefonat mit dem Kollege,der nicht zu fahren beabsichtigte). Zeitaenderung, da ich angebe innerhalb 24 Stunden ankommen zu wollen, starte ich also gegen 23 Uhr. Ich kann leider tagsueber nicht schlafen, wie ich geplant (erhofft?) hatte. Also muede starte ich: Kalt ueber Nacht, ich schlafe etwas bei dem 2. Stopp -ein Krog nach etwa 80 Km, genauer weiss ich es nicht, es sind die Raststaette fuer die "Nachtfahrer"-. Weiter geht es. Ich bin aber nicht motiviert, werde in der Ebene auch etwas langsam und merke, dass es schwierig wird, gegen Mitternacht anzukommen wie ich es geplant hatte. Beschliesse aufzugeben, in Lillehammer werde ich im Auto einsteigen. Das tue ich auch. Nur sind wir mit dem Auto erst gegen 1 oder 2 Uhr morgens in Oslo angekommen. Da haette ich doch auch mit dem Rad die Strecke gefahren und sogar frueher da gewesen. Na gut. Einmal sollte man auch T-O aufgegeben haben.
Das war also nicht gut: Fuer PBP nicht qualifiziert und T-O aufgegeben.
Und mein Auto wurde geklaut. In Oktober. Geklaut und versaut; die Armleuchte, die das Auto geklaut hat, hat den Feuerloescher im Auto entleert. Damit ist die Kiste kaum noch etwas Wert, Teil der Elektrik ausgefallen, und ich habe kein Vertrauen mehr in das Auto.
Doch es gab noch mehr, was im Jahr 2011 schief lief. Meine Liebste sollte Grossvater in Kanada besuchen um Enkelkind vorzufuehren. Flugtickets gekauft. Visum nicht bekommen. Nicht nur nicht bekommen, die kanadische Botschaft hat es verschlampt, mir das (von mir faelschlich) bezahlte Geld zurueckzubezahlen. Die kanadische Botschaft in Deutschland funktioniert nicht: Geld nicht zurueckbezahlt, ueber Email nicht erreichbar, keine Antwort auf meine Emails. Nichts. Ich mag die Sachen beim Namen zu nennen; die kanadische Botschaft ist ein Saftladen. Und was noch schlimmer ist, ist das ich das Gefuehl bekommen habe, dass die Botschaft es auf das Geld abgesehen hat. Schwer zu glauben, aber vom Benehmen her, ist das Veruntreuung von Gelder.
Ueberhaupt waren sie interessiert, dass man Geld bezahlt, und Trotz Einladung vom Bruder (kanadischer Staatsbuerger), dass die eine eingetragene Firma besitzt, dass sie ein geregeltes Einkommen und Familie und Rente hier hat, wollte man ihr das Visum nicht erteilen. Leider muss ich das Land Kanada nach seiner Behoerde im Ausland beurteilen. Diebe. Bis heute, etwa 12 Monate nach dem Vorfall, ... Schweigen in den Stuben...
Doch das war leider nur Geldverlust, dadurch gelernt, dass Kanada als eine Bande Betrueger zu betrachten ist.
Aber das Schlimmste kommt am Ende des Jahres. Ich plane, im naechsten Jahr (2012) die Marathon in Berlin zu laufen und beginne dafuer mit einem strikten Training, werde ziemlich fit und bin sehr motiviert (nicht mehr Rad zu fahren) zu laufen. Doch Anfang November habe ich einen Unfall mit dem Fahrrad, der 2. Tag nach der Zeitumstellung, von der Arbeit zurueck nach Hause, wache ich im Krankenhaus nach ca. 4 Stunden Bewusstlosigkeit. Angeblich habe ich einen "Fussgaenger" ueberfahren. Oslo ist bergisch und es war auf eine Bergab-Strecke, mit 1 Meter Radstreifen rechts von der Strasse, breit und gut sichtbar, ich schaetze ich hatte sicher mehr als 40km/h. Irgendein Idiot ist quer ueber die Strasse gelaufen (keine Zebrastreifen oder Ampel), wie die Leute es hier zu tun pflegen. Wahrscheinlich hat der Schwachsinniger sogar geguckt, aber kein Auto gesehen (Rad uebersehen, es war leider 2 Tage nach Zeitumstellung und damit ploetzlich fuer die "Tageszeit" dunkel).
Als die Polizei die "Ermittlungen" abgeschlossen hatte, ist, wie immer, nichts passiert. Beim Auto haben sie gesagt, sie haetten nicht genug Leute, um die Arbeit zu erledigen. Beim Unfall, dass, wenn ich es wuensche, kann ich mir die Akten angucken, bevor sie archiviert wird. Es ist mir schon klar, dass egal was passiert, es wird nichts passieren.
In mir, nach 4,5 Jahre Leben in Norwegen, gedeiht der Gedanke, Norwegen den Norwegen zu belassen. Ich bin und bleibe, nicht nur ein Auslaender, sondern vielmehr ein Fremder, da ich mich an dieser Schlamperei nicht anpassen moechte.
Was der Arbeit angeht, so ist das ein anderer Kapitel.
Abonnieren
Posts (Atom)