Archiv des Autors: PhilipMay

Die Abkürzung von „zum Beispiel“

Wie wird eigentlich „zum Beispiel“ richtig abgekürzt? An vielen Stellen findet man die Schreibweise „z.B.“. Das ist jedoch leider falsch. Korrekt ist die Schreibweise mit einem Space: „z. B.“ – wie man hier im Duden oder im Wiktionary nachlesen kann:

Die Abkürzung wird nicht zusammengeschrieben (z.B.), sondern getrennt (z. B.).

In elektronischen Dokumenten sollte man zusätzlich noch darauf achten ein Geschütztes Leerzeichen zu verwenden. In Microsoft Word wird dieses Zeichen durch „Shift + Steuerung + Space“ eingefügt (siehe Bild unten).

Darstellung von "z. B." in Microsoft Word

Darstellung von „z. B.“ in Microsoft Word

In HTML wird dieses durch die Eingabe von „ “ erreicht. Siehe auch SELFHTML:

Die Zeichenfolge   erzeugt ein geschütztes Leerzeichen (nbsp = non-breaking space = Leerzeichen ohne Umbruch). Es wird ein normales Leerzeichen angezeigt, doch an dieser Stelle kann kein Zeilenumbruch erfolgen. Notieren Sie die Zeichenfolge inklusive dem „kaufmännischen Und“ (&) am Beginn und dem Strichpunkt am Ende. Die gleiche Wirkung erzielen Sie durch Notieren der Zeichenfolge  .

Gleiches gilt übrigens auch zum Beispiel für „u. a.“ und „d. h.„.

Sprint Retrospektive: Die Brücke zwischen den Sprints

Wie Jutta Eckstein auf ihrem Blog schon schreibt sind Retrospektiven keine bloßen Plus-/Minuslisten. Doch was sind Sprint Retrospektiven und wie sollten sie gestaltet sein um einen möglichst großen Nutzen zu bringen?

Was ist eine Sprint Retrospektive eigentlich?

Um diese Frage zu beantworten schauen wir uns einfach „The Scrum Guide, the official rulebook“ von Scrum.org an.

Eine Sprint Retrospektive ist für das Scrum Team eine Möglichkeit um sich selbst zu inspizieren um Verbesserungen für den nächsten Sprint zu planen. Die Sprint Retrospektive findet nach dem Sprint Review und vor dem nächsten Sprint Planning Meeting statt und hat bezogen auf einen einmonatigen Sprint eine Timebox von drei Stunden (0,75 Stunden pro Woche Sprint).

Die Brücke zwischen den Sprints bauen

Um zu beschreiben wie eine gute Sprint Retrospektive gestaltet sein sollte habe ich mir einen Vergleich aus dem Buch Agile Coaching von Rachel Davies und Liz Sedley geborgt. Hier wird die Retrospektive als Brücke zwischen zwei Sprints beschrieben (siehe Abbildung unten).

In dem letzten Sprint (Sprint X) hat das Scrum Team Erfahrungen gesammelt welche zu Erkenntnissen führen. Nun muss das Team entscheiden auf welche dieser Erfahrungen es sich fokussieren möchte. Im letzten Teil der Brücke sucht das Team mit Hilfe von Kreativitätstechniken nach konkreten Aktionen die es im nächsten Sprint (Sprint X+1) umsetzen möchte.

Zeitlicher Aufbau der Retrospektive

Um bei der Retrospektive nicht den zweiten Schritt vor dem ersten zu machen empfehle ich folgendes Vorgehen:

  1. Die Vergangenheit (Erfahrungen) betrachten und nach Erkenntnissen suchen
  2. Themen auswählen auf die man sich fokussieren möchte
  3. Die geplanten Aktionen der letzten Retrospektive(-n) betrachten
  4. Ideen zur Verbesserung entwickeln
  5. Konkrete Aktionen planen

Es ist sehr wichtig, dass alle diese Phasen durchlaufen werden und das Team nicht vorzeitig abbricht. Es geht um konkrete Aktionen und nicht darum nebulöse Dinge zu finden die man mal verbessern sollte.

PMI und Konfliktmanagement

Was sagt das PMI eigentlich zum Thema Konfliktmanagement?

Teammitglieder sind zunächst selber für das Lösen von Konflikten zuständig – bevor sie es an höhere Ebenen eskalieren. Wenn Probleme eskalieren sollte der Projektmanager sicherstellen, dass der Konflikt früh und privat adressiert wird und einen gemeinschaftlichen Ansatz wählen.

Das PMI nennt sieben Konflikt-Quellen in Projekten. In absteigender Reihenfolge der Wichtigkeit sind dieses:

  1. Ablaufplanung (Schedule)
  2. Prioritäten (Priorities)
  3. Ressourcen (Ressources)
  4. Technische Meinungen (technical opinions)
  5. Administrative Abläufe (Administrative procedures)
  6. Kosten (Cost)
  7. Persönlichkeiten (Personalities)

Konflikte können manchmal durch folgende Techniken vermieden werden:

  • Klare Abgrenzung von Aufgaben (Doppeldeutigkeiten oder überlappende Zuständigkeiten vermeiden)
  • Das Team informieren über:
    • Wo genau das Projekt hinführt (Ziele und Grundsätze)
    • Ergebnisse von Schlüssel-Entscheidungen (das Team einbeziehen wenn es angebracht ist)
    • Änderungen
  • Arbeitsanweisungen herausfordernd und interessant gestalten

Konflikte können einen positiven oder negativen Effekt auf Projekte haben. Es hängt davon ab wie sie gehandhabt werden. Das PMI nennt fünf Techniken wie man auf Konflikte reagieren kann:

  1. Problemlösung (ansprechen): Die Angelegenheit direkt und gemeinschaftlich ansprechen. Durch klassische Problemlösungsmethoden können beide Parteien auf eine Lösung hinarbeiten die ihren Bedürfnissen genügt („Win-Win-Situation“). Das PMI befürwortet diesen Ansatz als den ersten und besten.
  2. Kompromiss: Verhandeln und nach Kompromissen suchen die beide Parteien zu einem gewissen Grad zufriedenstellen. Das PMI betrachtet diesen Ansatz als den zweitbesten.
  3. Schlichten: Differenzen herunterspielen um die Atmosphäre freundlich zu halten. Diese Methode wird vermutlich die Ursachen des Konfliktes nicht lösen. Deshalb wird diese „Scheinlösung“ nur temporär sein.
  4. Rückzug: Verwendung einer herauszögernden Taktik wenn die Spannungen sehr stark werden und die zukünftige Zusammenarbeit gefährdet ist. Die Abfolge wäre dann: zurückziehen, abkühlen und später wieder eingreifen.
  5. Erzwingen: Eine Win-Lose-Situation erzeugen indem man die Ziele einer Partei heraushebt und die der anderen unterdrückt. Das PMI empfiehlt das „Erzwingen“ nur als letzten Ausweg, da es zu Feindschaft und einer Patt-Situation führen kann. Dieses wird zu weiteren Konflikten führen.

Quelle: PMP Exam Study Guide von C. Michael Farr (Ph.D.) und CMF Solutions, Inc, Seite 7-11f

WikidPad – das persönliche Wiki

Was ist WikidPad?

WikidPad ist eine Mischung aus Outliner (Notizblocksoftware) und (persönlichem) Wiki. Man kann also ähnlich wie in einem normalen Texteditor Notizen machen. Die Notizzettel werden jedoch nicht in einzelnen Dateien abgelegt, sondern durch das Wiki gebündelt und in einer Baum-Ansicht dargestellt (siehe Abbildung unten).

Aussehen von WikidPad

Aussehen von WikidPad

Wie in einem Wiki kann man Einträge (Notizzettel) miteinander verlinken. Weiterhin gibt es eine Auszeichnungssprache z.B. für Überschriften, Formatierungsoptionen (Fettschrift) und Aufzählungslisten.

Die Bedienung von WikidPad erfolgt nicht mit einen Webbrowser, sondern durch eine lokal installierte Software. Dadurch ist es jedoch nicht möglich WikidPad mit mehreren Benutzern parallel zu nutzen. Es ist halt kein „echtes“ Wiki sondern ein persönliches Wiki (Personal wiki).

WikidPad ist Open-source software und wird auf dieser SourceForge Seite gehosted. Es ist in Python implementiert und läuft sowohl unter Windows als auch auf Mac OS X und Linux. Die Informationen werden als Textdateien im eigenen Dateisystem gespeichert. Zusätzlich wird eine lokale Datenbank benutzt (SQLite). Diese speichert unter Anderem Daten von der Volltextindexierung.

Vorteile von WikidPad

WikidPad ist hervorragend geeignet um Wissen (Notizen) zu strukturieren, zu speichern, zu verwalten und miteinander zu vernetzen (verlinken). Es verhindert Zettelwirtschaft die man a) eh irgendwann elektronisch erfassen muss und über die man b) irgendwann die Übersicht verliert.

Ein weiterer Vorteil ist die einfache Veraltung von Todos. Beim Zeitmanagement kann WikidPad wertvolle Unterstützung leisten.

Zeitmanagement mit WikidPad

Wie in Getting Things Done gefordert erfasse ich meine ToDos sortiert nach Orten wo ich sie erledigen kann. Büro, zuhause, Telefon, etc. Diese Unterteilung wird einfach mit Überschriften gemacht (siehe Abbildung unten).

ToDos in WikidPad verwalten

ToDos in WikidPad verwalten

Das Schöne an WikidPad ist die Möglichkeit zusätzliche Keywords anzuhängen. Zum Beispiel todo.heute (siehe Abbildung oben). Aus diesen Keywords wird nun in der Baumansicht (links im WikidPad Fenster) eine dynamische View erstellt (siehe Abbildung unten). Diese View wird bei jedem Speichern aktualisiert. In ihr kann man genau sehen wann man was geplant hat.

Dynamisch erzeugte View der ToDos in WikidPad

Dynamisch erzeugte View der ToDos in WikidPad

Installation

Die Installation ist recht einfach. Zunächst WikidPad herunterladen. Zurzeit (Stand Januar 2012) ist es in Version „2.1 (stable)“ verfügbar. Dann die Installation starten.

Ich habe WikidPad als portable Installation auf einem USB Stick installiert (siehe Abbildung unten). So habe ich auf dem Stick nicht nur die Daten, sondern auch die Software immer dabei.

Optionen bei der Installation von WikidPad

Optionen bei der Installation von WikidPad

Ein neues Wiki anlegen

Nach der Installation öffnet sich nach dem Start von WikidPad die WikidPad Hilfe, die natürlich in Form eines WikidPad Wiki dokumentiert ist. Möchte man ein eigenes Wiki anlegen, so kann man das mit „Wiki -> New“ tun.

Bei der Auswahl des Datenbank-Typen kann man die Default-Werte benutzen (siehe Abbildung unten).

Anlegen eines neuen WikidPad (Default Einstellungen)

Anlegen eines neuen WikidPad (Default Einstellungen)

Formatierung

Wie man bei WikidPad Text formatiert ist unter WikidPad Formatierung beschrieben. Unten sind zwei Abbildungen mit einem Beispiel für die Formatierung von Text (fett, kursiv) und die Auszeichnung von Überschriften.

Formatierung in WikidPad

Formatierung in WikidPad

Überschriften bei WikidPad

Überschriften bei WikidPad

Mehr zum Thema Listen und wie zum Beispiel Nummerierte Listen erstellt, kann man hier nachlesen: WikidPad Bulleted Lists. Unten ist ein Beispiel einer Liste zu sehen.

Listen in WikidPad

Listen in WikidPad

Konfiguration

Die Standard-Konfiguration von WikidPad ist im Prinzip ok. Dennoch habe ich bei mir ein paar eigene Einstellungen gemacht.

DisableCamelCaseWords

WikidPad erkennt automatisch sogenannte „wiki words“ und stellt diese als interne Links dar. Interne Links verweisen immer auf eine andere WikidPad Seite.

Wiki words are (at least by default) all words which start with an
uppercase letter and where at least one uppercase letter follows a
lowercase letter in the word (this is called „camelcase“, like e.g.
WikiWord) or where a lowercase letter follows after multiple uppercase
letters (ABCd). (siehe auch Word Linking)

Diese „wiki words“ habe ich deaktiviert, so dass man sie explizit durch eckige Klammern auszeichnen muss. Zum Beispiel [Mein Wiki Word].

Dazu muss man unter „WikiSettings“ folgendes einfügen: [global.camelCaseWordsEnabled: false] (siehe auch Abbildung unten und DisableCamelCaseWords).

WikiSettings: global.camelCaseWordsEnabled: false

WikiSettings: global.camelCaseWordsEnabled: false

WikidPad unterstützt eine Wiki Words Auto Completion, welche unvollständige Wiki Words per Ctrl-Space vervollständigen kann.

Dieses Auto Completion sollte man nun so konfigurieren, dass sie die schließende eckige Klammer anfügt. Das geschieht anhand eines Haken unter Extra -> Options… -> Editor bei „Append closing bracket on auto-complete“ (siehe auch Abbildung unten).

Konfiguration (Append closing bracket)

Konfiguration (Append closing bracket)

Initiales Level von Überschriften

Standardmäßig werden bei neu erzeugten Seiten Überschriften der zweiten Ebene erzeugt. Das sind Überschriften nach dem Muster ++ Überschrift. Das erscheint mir nicht sinnvoll, da ich eine Überschrift erster Ebene haben möchte.

Das Ganze wird unter Extra -> Options… -> Headings unter „Heading Prefix“ konfiguriert. Hier einfach ein „+“ löschen (siehe auch Abbildung unten).

Konfiguration (Heading Prefix)

Konfiguration (Heading Prefix)

Links

Hier noch ein paar hilfreiche Links:

Wissensmanagement in Firmen

Zum Thema Wissensmanagement in Firmen zu Zeiten von Twitter, Wiki, RSS und Blogs gibt es eine sehr interessante Präsentationsreihe. Diese möchte ich hier kurz vorstellen.

Zunächst wird die Frage gestellt wie man mit einem klassischen Wissensmanagement Menschen in einem Unternehmen miteinander verbinden kann und welches die eigentlichen Motive zum Teilen von Wissen sind. Dann werden die Ursachen des Scheiterns vom klassischen Wissensmanagement analysiert und auf „Social Software“ hingewiesen. Social Software ist jedoch nur ein Tool und nicht die Lösung…

Nun wird dargestellt wie man die sogenannte Social Software – das sind also zum Beispiel Wikis, Blogs etc. – für die tägliche Team- oder Projektarbeit nutzen kann und so die Menschen vernetzt werden. Dadurch wird Wissen ganz automatisch erfasst und geteilt. Der erfolgreiche Einsatz erfordert jedoch bestimmte kulturelle, technische und organisatorische Bedingungen. Wie ein Unternehmen solche Bedingungen gestaltet und erfolgreich einführt wird uns im dritten Teil der Präsentation gezeigt. Viel Spaß beim Lesen:

Teil 1 – Wissensmanagement im Enterprise 2.0 – Der Wikipedia Irrtum

Teil 2 – Die Entdeckung des Menschen

Teil 3 – Anleitung zum Handeln

Das wirklich witzige an diesen Präsentationen ist, dass sie durch Kollegen von mir (T-Systems) erstellt wurden. Gefunden habe ich sie jedoch nicht etwa durch ein T-Systems Wiki oder Blog, sondern durch ein Blog im Internet (pixelReality.log).

Quellen:

Texte unformatiert einfügen (Windows)

Wer kennt das nicht: Man kopiert einen Text von einer Webseite in eine E-Mail oder einen Texteditor und nach dem Einfügen hat der Text eine wirklich hässliche Formatierung. Das liegt daran, dass die Richtext-Informationen übernommen wurden. Nun muss man das Ganze umformatieren oder erst in einen anderen Texteditor einfügen und dort wieder rauskopieren. Oder aber „Bearbeiten -> Inhalte einfügen… -> Unformatierten Text“ klicken. Das Ganze nervt ziemlich.

Ich habe mich mal nach einer Lösung umgeschaut. Das Ganze heißt PureText und ist ein kleines Windows Tool. Es startet automatisch beim Booten. Mit der Tastenkombination „Windows+V“ kann man dann den Text unformatiert aus der Zwischenablage einfügen. Das Konfigurationsmenü sieht so aus: