Freitag, 25. September 2015

Mögliche Gründe für den (unerklärlichen) Siegeszug der "agilen" Methoden

Ich habe mir ein Paar Gedanken gemacht über die Akzeptanz der agilen Entwicklungsmethoden.

Wieso werden diese eingesetzt, blind, ohne den Versuch zu unternehmen, daraus etwas vernünftiges, ordentliches, funktionierendes zu gestalten?

Hier einige Ideen:
  • Das Management ist sich über die Nachteile nicht im KlarenJunge Entwickler scheinen wohl stark indoktriniert worden zu sein
  • Die Entwickler lassen es sich gut ergehen, genießen wohlgemerkt die Wonne der Verantwortungslosigkeit, die Ruhe sich nur zu dem zu "commiten", was man bequem schaffen kann
  • Das Management genießt auch die Verantwortungslosigkeit: laxe, unbekümmerte Vorgehensweise, sich in "Rollen" wiederfinden, die leicht von der Arbeit und einfach zu handhaben sind

In meinen Augen sieht es eher so, dass einer ohne wirklich nachzudenken sich für die agilen Methoden geäußert hat, und dann haben viele andere das einfach, weiterhin ohne richtig nachzudenken, wenn überhaupt, sich auch für diese Ideen geäußert.

Keine gute Voraussetzung, um das Problem mit der Software-Entwicklung zu lösen.

Ich glaube, man hat sich leichtsinnigerweise an den Symptomen ausgetobt, anstatt die Wurzel des Problems zu analysieren, und vernünftigerweise hier anzusetzen.

Doch solange die Geldgeber überzeugt sind, dass Software-Entwicklung eine ganz besondere Sache ist, die "agil" zu erfolgen hat und viel Geld verschlingen muss, wird eine Vielzahl von "agilen" Entwickler gemütlich absahnen können.

Sonntag, 13. September 2015

Agile Entwicklungsmethoden => Dogmatischer Glaube und kein bisschen Nachdenken


Ich erlebe, verstärkt in den letzten Zeiten, dass die sogenannten "agilen" Methoden nicht nur vom Management (das Management hat eigentlich keine Ahnung von Entwicklung und soll diese auch nicht haben, da das Management durchaus andere Aufgaben zu erledigen hat) "gepuscht" werden (was man noch u.U. vermeiden könnte als erfahrener Entwickler), sondern auch, dass viele "Entwickler", also tatsächlich Menschen die SW Code schreiben, (Im Allgemeinen junge Leute, die wahrscheinlich noch mit einem Bein an der Uni stehen) sich diese Methoden dogmatisch hingeben.

Dass das Management oft und gerne auf "Hypes" reitet ist hinlänglich bekannt. Aber dass auch Entwickler so etwas anscheinend machen, versetzt mich im Erstaunen.

Eine rhetorische Frage von den eher unerfahrenen Entwicklern: "Sollen wir etwa Wasserfall anwenden?" - Betonung auf das Wörtchen "etwa". Tertium non datur. Schwarz-Weiß Auffassung der Welt...

Lernen sie so etwas an der Uni? Lehren die Profs, dass die sogenannten "agilen" Methoden das non-plus-ultra der Entwicklung ist? Die jungen Entwickler scheinen tatsächlich zu glauben, dass agile Methoden "agil" und besser seien, und Wasserfall "abscheulich" ist. Und das glauben sie mit religiösem Eifer... Schwarz-Weiß-Denken.

Für Akademiker sollte klar sein, dass ALLES Vor- und Nachteile hat. Und echte Profis sollten auf der Arbeit (eigentlich) auch bemüht sein, die Arbeit, Arbeitsmethoden usw zu verbessern, optimieren, Probleme zu entdecken und verschwinden zu lassen. Das geht aber nicht wenn man dogmatisch an bestimmten "Prinzipien" oder gar "Manifestos" fest hält.

Ich arbeite daran :-)

Dienstag, 23. Juni 2015

Das Toyota-System: Lean und Kaizen. Einige Begrifflichkeiten.

Die Grundlagen von Lean sind weder irgendwelche Werkzeuge noch eine Vermeidung von Verschwendung.

Wakamatsu und Kondo, beide Experten bei Toyota, brachten es auf den Punkt:
Das Wesen des Toyota-Systems ist einfach; dass jeder einzelne Mitarbeiter die Gelegenheit hat, in seinen eigenen Arbeitsumfeld Probleme zu finden, diese zu lösen und Verbesserungen zu machen.

So "einfach" wie es auch klingt, so schwierig ist doch die Umsetzung.

Das Toyota-System kann man durch 2 Grundlagen kurz beschreiben:
  1. Kontinuierlich Verbessern, und
  2. Menschen respektieren.

Ständige Verbesserungen, -oft als Kaizen benannt- ist Toyotas Ansatz, das tägliche Geschäft zu führen. Nach dem Prinzip: "Alles in Frage stellen". Mit anderen Worten: "Stets denken".

Wichtiger aber als die tatsächlichen Verbesserungen, die die Mitarbeiter umsetzen (dürfen), ist der wahre Mehrwert das Schaffen einer Umgebung in der man ständig lernen kann; eine Umgebung, die nicht nur Änderungen akzeptiert, sondern sie geradezu fördert.
Eine solche Umgebung kann nur dort entstehen, wo man die Menschen ohne wenn und aber respektiert - daher ist dieser der 2. Grundsatz des Toyota-Systems.

Und an diesem 2. Grundsatz scheitert grundsätzlich die Mehrzahl von unserem "westlichen" Management.

Kaizen wird (oft) schlicht als "kontinuierliche Verbesserung" übersetzt. Das aber verwechselt die Bedeutung von "kontinuierlichen Verbesserung" und ist nicht mit dem wahren "Kaizen" deckungsgleich.
Es wird empfohlen, das japanische Wort Kaizen zu gebrauchen und sich dabei der wahren Bedeutung bewusst werden: Kaizen ist gleichzeitig gelebte Praxis und eine (persönliche) Einstellung.
Nicht einfach "stets verbessern"...


Cargo Cult (Cargo-Kultur)


Eine Cargo-Kultur sind Rituale, von einer (primitiven) Gesellschaft durchgeführt, die das Verhalten von nicht-native Besucher (oft aus Europa) nachahmt.

Analog dazu nennt man Cargo-Kultur-Prozesse solche, wo Rituale und Oberflächlichkeiten, ohne eingehendes Verständnis für die Hintergründe, praktiziert werden. (Oft vorzufinden bei vielen Organisationen, die "Agile Methoden" praktizieren, ohne sich mit der "agilen" Denkweise auseinander zu setzen -siehe "Scrum"-.)

Eine "Lean Cargo-Kultur" führt "lean" Werkzeuge (durch das Management) ein, ohne dass sich wirklich weder die Denkweise noch das Verhalten von Management oder gar der Mitarbeiter ändert.

Natürlich können sich beide nicht von heute auf morgen ändern, das braucht:
1. (eine lange) Zeit.
2. Maßnahmen, um die Mitarbeiter dahin zu führen (vom Management getragen).
Und sicher auch noch der Wille dazu und die Bereitschaft, Mitarbeiter gewähren zu lassen.

Nein... einfach ist das nicht.

Samstag, 13. Juni 2015

(Nicht so sehr) Lean Untersuchung der Lean-Prinzipien

Zunaechst sei angemerkt, dass die "Lean-Prinzipien" schon eine etwas längere Geschichte haben als die sogenannten "agilen".

Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".

"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."

Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)

Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.

Nun zu den Prinzipien.

Die sieben Prinzipien der Lean-Entwicklung:
  1. Verschwendung vermeiden (siehe weiter unten)
  2. Feedback einfordern (alle Teilnehmer einbeziehen - Kommunikation intensivieren)
  3. Spät entscheiden (sich so viel Zeit wie möglich nehmen: zum Denken und zum Planen)
  4. Schnell ausliefern (so schnell wie möglich die Entwicklung durchziehen, nachdem "entschieden" wurde)
  5. Team trägt Verantwortung (impliziert Selbst-Organisation...)
  6. "Integrität einbauen" ("stets" standardisieren, so wie ich es verstanden habe)
  7. Die Gesamtheit optimieren (Den gesamten Prozess verbessern)

Andere "Übersetzungen" postulieren:
  • Die Arbeiten gleich beim 1. Mal richtig machen (inhaltlich zum 1. Punkt: keine Verschwendung)
  • Den Arbeitern erlauben, Entscheidungen zu treffen (nicht nur "ganze Teams" sondern auch auf persönlicher Ebene)
  • Stets verbessern (inhaltlich zum 7. Punkt)
  • Lernen unterstützen (entfernt verwand mit dem 2. Punkt...)


Und hier die 7 Verschwendungen der SW-Entwicklung:

  • Überproduktion (Zusätzliche Funktionalität)
  • Inventur (Administration / Anforderungen)
  • Zusätzliche Produktionsschritte (Komplexität / Überfluss)
  • Bewegungen (Suche von Informationen)
  • Fehler (Bugs / Fehler in der SW / Tools mit )
  • Wartezeiten (Warten auf Entscheidungen / Warten auf Kunden-Feedback)
  • Transport (Schnittstellen / Workflow der Arbeit)


Hier die japanischen Begriffe für Verschwendung:

- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.


Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.

Samstag, 23. Mai 2015

Warum Scrum abbrennen soll (eine Übersetzung)


Why Scrum Should Basically Just Die In A Fire (hier nur ein Abzug)

Von: http://gilesbowkett.blogspot.de/2014/09/why-scrum-should-basically-just-die-in.html

(Ich empfehle das Original zu lesen!)


The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense.

Well-written text very often trumps face-to-face communication. You can refer to well-written text later, instead of relying on your memory. You can't produce well-written text unless you think carefully. Also, technically speaking, you can literally never produce good code in the first place unless you produce well-written text. [...]

In fact, GitHub itself was built without face-to-face communication. Basecamp was built without face-to-face communication as well. I'm not saying these people never met each other, but most of the work was done remote.  [...]. And face-to-face communication plays a minimal role in the majority of open source projects, which usually outperform commercial projects in terms of software quality.

In addition to defying logic and available evidence, both these Agile Manifesto principles (1) encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points.


Übersetzung (des Abzuges)

Das Agile Manifesto widerspricht auch die Standup des Scrum . Es besagt, dass "die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch". Um fair zu den Autoren zu sein muss man hier bemerken, dass dieses wurde im Jahr 2001 geschrieben, und zu dieser Zeit gab es noch kein git log. Bei den heutigen Tools, die für die verteilte Zusammenarbeit existieren, es diese Behauptung recht unglaubwürdig, und eben auch im Jahr 2001; musste man doch annehmen, die Autoren haben nie etwas von Linux gehört, wenn Sie wirklich richtig liegen sollten.

Ein gut geschriebener Text ist oft einfach besser als ein persönliches Gespräch. Ein Text kann jederzeit nachgelesen werden, anstatt dass man sich auf das eigene Gedächtnis verlässt. Man kann auch ein Text nicht schreiben ohne (genau) zu wissen, was man wirklich äußern will. Technisch gesehen, man kann auch nicht gut programmieren wenn man nicht richtig schreiben kann. [...]

Richtig ist es, dass GitHub selbst ohne persönliche Gespräche entwickelt wurde. Das Gleiche gilt für Basecamp. Ich behaupte nicht, das die Entwickler sich nie getroffen haben, doch die meiste Arbeit wurde aus der "Ferne" getan. [...]. Ebenfalls spielen persönliche Gespräche in den meisten Open-Source-Projekte eine untergeordnete Rolle. Und Open-Source-Projekte übertreffen in der Regel, in Bezug auf die Qualität der SW, kommerzielle Projekte.

Nich nur dass diese beide "agilen" Prinzipien (1) vorhandene Beweise und einfache Logik trotzen, sondern dass sie auch eine Art Kindergarten-Mentalität fördern. Ich habe noch nie gesehen, dass man Scrum bei Design, Buchhaltung oder Ein- und Verkauf benutzt: oberflächliche, Bilderbuch-ähnliche Vereinfachungen, wie die Sache mit den "Story Points" (Bewertung der 'Geschichten').


(1)
Als 2. Prinzip ist gemeint:
"business people and developers must work together."
Zu deutsch:
'Geschäftsleute und Entwickler müssen zusammenarbeiten.'

Die 1. angesprochene Prinzip war:
'die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch'.

Mittwoch, 13. Mai 2015

Agile Prinzipien: Schwammig. Schwach. Lahm.

From: http://www.agilemanifesto.org/principles.html
Principles behind the Agile Manifesto

We follow these principles:


1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -the art of maximizing the amount of work not done- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Mein Senf dazu:

Zu 1. Gut und wichtig ist es, den Kunden stets glauben zu lassen, man will sie zufriedenstellen. Ansonsten ist der Punkt eher schwammiges Wunschdenken.

Zu 2. Mehrarbeit zu begruessen zeugt eher von schwacher Denkweise. Es soll gelten: Aenderungen zu minimieren. Das soll auch der Kunde beherzigen. Je eher die Anforderungsaenderungen erscheinen desto besser, man soll diese ergo verlangen, ASAP, doch nicht "auch spaet im Projekt diese willkommen heiszen".

Zu 3. Schwacher Punkt. Es ist wichtig, dass das Ergebnis funktioniert, und zwar so gut wie moeglich. Das die SW lange vor Ende des Projekts "arbeitet", und auch diese (so) oft (wie moeglich) zu liefern... das kann kein wirkliches Ziel sein. Ziel ist das Endergebnis. Und darauf sollte man fokusieren.

Zu 4. Die Entwickler taeglich mit Meetings (oder was auch immer eine Zusammenarbeit bedeutet) mit "Business People" wuerde den Entwickler eher zu sehr ablenken, belasten. Eine enge Zusammenarbeit ist erwuenscht, doch "taeglich" ist uebertrieben. Die "Business People" sollen dem Entwickler jederzeit zur Verfuegung stehen. Nicht mehr und nicht weniger. "Taeglich" etwas zu erzwingen ist irgendwie besonders unflexibel.

Zu 5. Gute Idee. Ist das aber eine exklusive Eigenschaft des "Agilen" Entwickelns, oder eher eine allgemeine gute Idee ...?

Zu 6. Aber auch nicht immer. Ausnahmen existieren. Ich halte solche allgemenine generalisierneden Aussagen, fuerwahr, fuer eher unflexibel. Die Punkte 5 bis 7 sind eher allgemeine gute Praktiken, wurden aber sicher nicht von den Autoren des "agilen Manifests" "erfunden".

Zu 7. Es kommt darauf an, wie man "Fortschritt" definiert. Und was man genau messen will. Komplexitaet, z.B. -in Bezug auf Fortschritt-, sollte man anders messen. Diese Aussage ist in meinen Augen auch eher zu allgemen. Dieser Punkt auch eher unflexibel.

Zu 8. These ohne Beweis. Nur solange die Entwickler bezahlt werden, werden sie auch entwickeln. Ausserdem muessten die Entwickler auch die Taetigkeit als sinnvoll erachten. Diese Voraussetzungen basieren nicht auf "agilen Prinzipien".

Zu 9. Scheinbar waren die Schreiber des Manifests ab Punkt 8 schon etwas muede. Schoene Woerter, zusammenhaltslos aneinadergereiht. Nicht nur, dass die Folgerung, wie hier beschrieben, nicht ersichtlich ist; sondern vielmehr lassen sich zahlreiche Gegenbeispiele zu dieser Aussage finden.

Zu 10. Einfachheit ist schon (sehr) wichtig. Doch "essential" ? Na ja. Ausserdem ist "Einfachheit" ganz sicher nicht "die Kunst, die nicht verrichtete Arbeit zu maximieren". Im Gegenteil; oft muss man mehr Arbeit verrichten und ein System einfacher zu gestalten.

Zu 11. Ich halte dieses Prinzip auch wieder fuer schwach im Sinne des Denkens: Gute Architekturen werden von guten Architekten entwickelt. Gute Anforderungen werden von guten Requirement-Engineers geschrieben. Gutes Design wiederum von guten Designers erstellt. Diese Arbeiten haben mit einem Team eher wenig zu tun. Ziemlich egal wie sehr sich das Team "selbst organisiert".

Zu 12. Gutes Prinzip. Sehr gut sogar (richtung Kaizen). Doch... eine Exklusivitaet von agilen Teams...? Zweifle ich stark.

Mein Fazit zu dem Manifest:

Inhaltslos: Punkte 1, 5 und 9.
Unflexibel: Punkte 4, 6 und 7.
Folgerung unlogisch: Punkte 8 und 9.
Falsch: Punkte 2, 10 und 11.

Auch hier (wie bei http://www.agilemanifesto.org) sollte man stark (zum Besseren) ueberarbeiten.
Vom urspruenglichen Manifest wird wahrscheinlich kaum etwas uebrig bleiben.

To be done. Bei mir. Im Laufe dieses Jahres.
 :-)

Freitag, 3. April 2015

Agile heilige Kühe in Indien...


Frage: Warum sind die Inder so stark vertreten seit einigen Jahren (seit der Einführung der "agilen" Methoden) bei der Entwicklung von Software?

Antwort: Weil bei der Software-Entwicklung so viele heiligen Kühe gibt!

Freitag, 27. März 2015

Wie "Agil" ist eigentlich "Agil"? Was kann man damit anfangen?

From: http://www.agilemanifesto.org

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:
1- Individuals and interactions over processes and tools
2- Working software over comprehensive documentation
3- Customer collaboration over contract negotiation
4- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.



Meine Gedanken zu den "Werten" des Manifestes:

1- Also, "agil" sind Individuen ohne Tools die wilde Interaktionen ohne wesentliche Prozessorientierung zu tun pflegen.

2- Das Ergebnis wird dann nicht unoft: "Unmaintable SW and uncomprehensive documentation". Also für die Katz, die Entwicklung...

3- Echt super, die Kunden werden geradezu ermuntert, ständig Änderungen und neue Funktionalitäten zu fördern!

4- Alles Andere als zielorientiert...

Daraus folgt, aus meiner Sicht: Das "Manifesto" ist noch nicht richtig anwendbar, ca 80% müsste noch korrekt überarbeitet werden.

Dazu, zu lesen (wenngleich nicht besonders informativ, sondern eher Gelaber/Textguss ohne wertvollem Inhalt): http://ronjeffries.com/xprog/articles/beyond-agile-new-principles/

Dienstag, 11. Dezember 2012

Meetings ohne Vorbereitung sind etwas fuer Unorganisierte

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).

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.

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

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...

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.

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.