Vom Beamen und von Meetings - Science Fiction "im Enterprise"

Manchmal scheint in Unternehmen der Größenklasse "Enterprise" vergessen werden, dass die Beamer, die man zu den Besprechungsräumen buchen kann, nichts mit dem – ebenfalls "beamen" genannten – Ort-zu-Ort-Versetzen aus dem Raumschiff "Enterprise" in "Star Trek" zu tun haben.

Wie ich zu dieser Einschätzung komme?

Natürlich aus den Kalendern und Termineinladungen.

10:00 - 11:00 Vertriebsmeeting in Haus 1
11:00 - 12:00 Design-Sitzung in Haus III
12:00 - 13:00 Besprechung kanonisches Datenmodell Haus IIV
13:00 - 13:30 Strategie-Abstimmung beim Lunch im Freigelände
13:30 - 14:00 Präsentation beim Vorstand (42. Etage Hochhaus)

Da nach meiner Erinnerung selbst das Beamen bei Star-Trek ein paar Sekunden in Anspruch nahm, ist mir völlig unklar, wie irgendjemand die Phantasie entwickeln kann, das ein solcher Terminplan funktionieren kann.

Strategie für Meeting-Einladungen

"Krumme" Zeiten für die Einladungen - z.B. 11:05 bis 11:40 - und ein konsequentes Einhalten beider Endpunkte als Einladender.

Warum solch exakte Angaben?

Einerseits ist es leichter von Meeting zu Meeting zu kommen, andererseits ist es unwahrscheinlicher, dass noch jemand ein Meeting direkt auf Stoß davor plant. Und schließlich werden bei solch exakten Uhrzeiten von den meisten Lesern geringere Toleranzen angenommen.

Scrum Master? Coach? Selbstorganisation?

Heute im Chat - Nur leicht anonymisiert und mit Freigabe des Chatpartners:

• "Ein Freund": Ich finde, die Rolle des Scrummasters wird oft unterschätzt.
• ich: ?
• "Ein Freund": So nach dem Motto, den brauche man ja nicht weil selbstorganisiert.
• ich: Jo - beliebte Fehlinterpretation
  Allerdings geht es ja nicht um den Scrum-Master in der Defintion des Scrum-Guide Meiner Ansicht nach gibt es die entsprechende Rolle in jedem methodischen Ansatz zur Softwareentwicklung - mal ist es der XP-Coach, mal der Scrum Master und mal einfach der Coach
• "Ein Freund": Und wenn die Rolle nicht besetzt ist, kommt sowas bei raus wie bei uns.
• ich: Yep - leider ist das so. Und das ist eines der größten Probleme von Scrum
  Vor allem, wenn die Unternehmen ihre Probleme mit "Scrum" lösen wollen
  Deshalb ist XP m.E. auch nicht so erfolgreich - da wird von vornherein zu deutlich gesagt, dass man viel Disziplin braucht und das es wirklich schwer ist etc.

Passt gut zu meiner aktuellen Kritik an Scrum:
Wenn man Scrum auf die so plakativ z.B. in Scrum in one Minute beschriebenen 3 x 3 Elemente reduziert fehlt auf einmal sehr viel.
Scrum kann aus meiner Erfahrung sehr gut ein Element auf dem Weg zu funktionierenden Projekten sein, aber in dieser über-minimalistischen Form, ohne Praktiken und ohne Details, meiner Ansicht nach keinesfalls das einzige Element.

Meine 2 cent:

Auch wenn ich sehr wenig von "der Deutschen liebstem Sport *" verstehe, so bin ich mir doch sehr sicher, dass es nicht reicht, das veraltete WM-System durch die Viererkette zu ersetzen - die Spieler brauchen sicherlich auch noch andere Fähigkeiten und Fertigkeiten um siegreich zu sein und viele davon dürften direkt mit dem Medium mit dem sie umgehen – dem Ball – und dessen Nutzung innerhalb des neuen Konzeptes zu tun haben.
Und vor allem sind mehr als die elf Personen auf dem Platz beteiligt - sonst müsste ja nicht immer der Trainer gehen, wenn die Mannschaft verliert.

Ähnliches bei der Softwareentwicklung im Hinterkopf zu haben ist sicherlich keine schlechte Idee.

[Gleiches gilt natürlich für Software-Kanban, obwohl es sich dabei ja ohnehin nicht um einen Prozess handelt, sondern um eine Methode zur Prozessverbesserung... wie auch schon David Anderson sehr deutlich machte auch wenn man diesen Beitrag heute nur noch in den Yahoo!-Groups archiven und nicht mehr auf Davids eigener Website findet.]

---

*(gemeint ist hier übrigens Fußball. Wenngleich der vor allem angeguckt wird, während der tatsächlich aktiv ausgeübte Sport Nummer Eins laut der Augsburger Allgemeinen das Radfahren ist.)

Technische Unfähigkeit bei Konzernen, Folge n+1 (Flinkster und Deutsch Bahn)

Disclaimer: Ich weiss, dass es kindisch ist, diesen Eintrag zu schreiben, aber da ich schon gerade dabei war, mich aufzuregen...

Schon mal versucht einen Flinkster Vertrag online abzuschließen?
Wenn ja, dann hoffentlich mit einem Windows-Rechner mit der richtigen Version von Microsoft™ Word.

Hier die Mail, die ich (ohne viel Hoffnung auf sinnvolle Reaktionen) gerade an Flinkster geschickt habe:

====8<----- snip ----

Sehr geehrter Damen und Herren,

der zur Vervollständigung des Anmeldeprozesses auszudruckende
Vertrag liegt leider in einem Format vor, welches von meinen
Systemen nicht verarbeitet werden kann.
(Es scheint sich hier um ein Mircrosoft-Word Derivat des
Formates RTF zu handeln)

Bitte lassen sie mir den Vertrag in einer nicht
herstellerspezifischen Form zukommen.

Beispiele für solche übergreifend nutzbaren Formate sind:
* Rich Text Format (rtf) [Standardkonform]
* Portable Document Format (pdf)
* Postscript (ps)
* Hypertext Markup Language (html)
* Tagged Image File Format (TIFF)
* Portable Network Grafics (png)

In der Anlage erhalten sie in Form einer png Datei ein
Beispiel dafür, wie der Vertrag aussieht, der durch das
für die Flinkster Website derzeit eingesetzte System
erstellt wird, wenn er /ohne/ Microsoft Word
ausgedruckt wird.

Mit freundlichen Grüßen
Michael Mahlberg
--
TCG The Consulting Guild AG * Friesenwall 126 * 50672 Köln
Mobil: +49 160 97856224 * Büro: +49 221 677742111 * Fax: +49 221 677742119
HRB (Köln): 63476, Vorstand: Michael Mahlberg (V)
Vorsitzender des Aufsichtsrates: Daniel Speicher


(Nein, die schwärzungen stammen nicht von mir, sondern sind das ergebnis des heruntergeladenen Vertrags)
====8<----- snip ----

Mittlerweile habe ich mich auf ein paar anderen Rechnern ausgetobt: Mit Microsoft Word auf dem Mac sieht es halbwegs vernünftig aus - Zeichensatzprobleme nicht mitgerechnet.

Scrum? Das ist doch das mit den Kreisen!

Na Super!
Vielen Dank auch an die Marketing-Spezialisten...

(Die Titelzeile "Scrum? Das ist doch das mit den Kreisen!" ist ein reales Zitat von einem Networking-Treffen im Herbst 2010...)

Das einfache Bild (dass ja bekanntlich sogar auf einen Bierdeckel passt ist) hat sicherlich viel dazu beigetragen, Scrum und auch dem Gedanken agiler Prozesse ganz allgemein zu der heutigen Akzeptanz zu verhelfen.

Als "hilfreiche Vereinfachung um die Grundgedanken von Scrum zu transportieren" kann ich mit diesem Bild leben. Zur Einführung eines Scrum-basierten agilen Prozesses werden aber meiner Erfahrung nach doch einige Aspekte mehr benötigt.


("Standard"-Bild zu Scrum)

Die andere Seite - das Produkt ist nicht das einzige, was durch einen Scrum-basierten Prozess verbessert wird - wird zunehmend auch wahrgenommen, wie David Harvey in seinem Beitrag deutlich macht.


(David Harveys Bild zu Scrum )

Was David Harvey hier herausstellt ist die Tatsache, dass neben dem eigentlichen Produkt durch den Prozess selber auch noch ein Team und ein im Team gelebter, konkreter Prozess erzeugt werden, die sich auch mit jedem Inkrement verbessern.

Was man darüber hinaus aber nicht vergessen darf ist, ...

[Vorsicht, Analogie für Softwareentwickler, die Objektorientierung kennen]

dass Scrum so etwas ist wie eine abstrakte Klasse - man kann es nicht instantiieren ohne die spezifizierten Methoden zu implementieren - und wenn man die Implementierung nur in Form von leeren Stubs durchführt kann man auch kaum erwarten, dass die Instanz sinnvolle Arbeit leistet.

[Nach einer guten Analogie für BWL oder PMI Spezialisten suche ich noch, hier die schlechte]

dass Scrum nur den groben Bauplan vorgibt - wie bei einem "Standardhaus", welches man so auch nicht bauen kann ohne sich nicht zu entscheiden, wie man bei diesem konkreten Exemplar die Wände zieht, was für Treppen man einsetzt und wo welche Anschlüsse nun wirklich liegen sollen.

Das reale Bild - und auch hier sind noch nicht alle relevanten Details aufgeführt - sieht dann eher so aus wie diese konkrete Instanz eines Scrum-basierten Entwicklungsprozesses:

(um Missverständnisse zu vermeiden: Dies war eine konkrete Ausgestaltung für ein konkretes Team - bitte nicht verallgemeinern!

Was ich damit deutlich machen will ist folgendes:
Ja, auf einer abstrakten Ebene ist Scrum ganz einfach - genau so, wie beispielsweise ein Auto auf einer abstrakten Ebene ganz einfach ist: drei bis vier Räder, Motor, Getriebe, Bremsanlage, ein paar Schaltelemente und eine selbsttragende Karosserie, fertig ist das Auto. Aber der Unterschied zwischen einem Benz Patent-Motorwagen Nummer 1 und einem Tesla Model S (oder irgend einem anderen aktuellen Fahrzeug) liegt sicher nicht nur im unterschiedlichen Zeitgeschmack, was die Gestaltung der Speichen anbelangt.
Nein, es reicht nicht, wenn man sich den Bierdeckel nur lange genug anguckt. Wenn man eine auch nur halbwegs konkurrenzfähige Umsetzung des einfachen Konzeptes haben will, dann muss sich sich intensiv mit den Details auseinander setzen und auch bereit sein, diese von Generation zu Generation (oder in unserem Fall von Iteration zu Iteration) zu überdenken.

Kreation statt Konsum! (diesmal per Mail)

Die allgemeine Meinung zum iPad scheint zu sein, dass es vor allem ein Werkzeug zum mobilen konsumieren digitaler Informationen sei. Ich selber kann mich dieser Sicht kaum anschließen und nutze es vor allem zum kreieren von Sachen (vor allem von Texten, die ich unterwegs schreibe).

Um nun auch meinen Blogs mal wieder ein wenig mehr Leben einzuhauchen Teste ich gerade verschiedene Möglichkeiten, Blogposts vom iPad aus zu erzeugen und zu verschicken.

Mail scheint schon eine erheblich bessere Variante zu sein um die Posts zu erzeugen, aber leider fehlt auch hier die Möglichkeit, eine vernünftige semantische Formatierung vorzunehmen.

- Listen
- Überschriften
- Hervorhebungen
- Zitate

Formatierungen wie fett, kursiv und Unterstrichen funktionieren nicht mal, wenn man die Inhalte aus einem Programm kopiert, dass diese Formatierung kann. (Wie dieser Absatz beweist)

Kreation oder Konsum?

Die allgemeine Meinung zum iPad scheint zu sein, dass es vor allem ein Werkzeug zum mobilen konsumieren digitaler Informationen sei. Ich selber kann mich dieser Sicht kaum anschließen und nutze es vor allem zum kreieren von Sachen (vor allem von Texten, die ich unterwegs schreibe).

Um nun auch meinen Blogs mal wieder ein wenig mehr Leben einzuhauchen Teste ich gerade verschiedene Möglichkeiten, Blogposts vom iPad aus zu erzeugen und zu verschicken.

Dieser hier stamm aus einem Programm, dessen Namen ich schon wieder verdrängt habe, da die Benutzerführung 'eher unglücklich' ist...
nicht gerade eine iPad Experience

Gerade Nachgeguckt: BlogPress heißt das Programm...

Permanentes Code-Review (Aka pair programming howto)

Was unterscheidet Pair-Programming davon, zu zweit vor einem Rechner zu sitzen?

Aus meiner Sicht 3 Dinge:

• Klare Rollendefinition
• Ein festes Prozedere
• Eine (mentale) Checkliste

Die Rollen

Die beiden Rollen, die wahrgenommen werden müssen sind die des Fahrers und die des Navigators. Dabei ist die Aufteilung ähnlich wie im Motorsport - der Fahrer ist dafür zuständig, bis zur nächsten Kurve zu kommen und der Navigator dafür, dass das Team auch nach der Kurve noch weiss, wie es weiter geht.

Übertragen auf die Programmierung bedeutet das, dass der Fahrer sich sowohl um Maus und Tastatur (entsprechend Gas und Kupplung) als auch um die konkreten Details der näheren Umgebung wie Klassen, Syntax, Struktur des aktuellen Codeblocks (entsprechend Geschwindigkeit, Drehzahl Straßenzustand etc.) kümmert. Der Navigator kümmert sich so lange um die weiter entfernten Zielen wie Design, Schnittstellen, Frameworks und Architektur (entsprechend Strassenkarte, Himmelsrichtung, Entfernungen etc.).

In dieser Rolle ist es auch Aufgabe des Navigators sich um so etwas wie das Roadbook – im Falle der Programmierung um den GoalStack – zu kümmern sowohl um die Erstellung, als auch um die Abarbeitung!

Das feste Prozedere

Das Prozedere zum Pair-Programming umfasst einen Bildschirm, eine Tastatur und eine Maus sowie eine Stoppuhr (welcher Art auch immer). Die Maßgabe lautet nun, dass beide Entwickler zugleich vor der Maschine sitzen, sich vor Beginn der Arbeit über das Ziel und den Zeitrahmen absprechen und in festen Intervallen von 10 bis 15 Minuten die Rollen wechseln. Beim Rollenwechsel sollten dabei tatsächlich nur Maus und Tastatur verschoben werden und weder die Sitzpositionen, noch die Monitorposition angepasst werden. Letzteres soll sicher stellen, dass der Navigator tatsächlich den gleichen Zugang zum Code hat wie der Fahrer. (Anm: Tools wie Key Jedi helfen zusätzlich, falls der Fahrer ein Mausgegner sein sollte...)

Die Checkliste

Die Checkliste für den Navigator kann entweder sogar physisch vorliegen, sollte aber auf jeden Fall zumindest mental bei jeder Zeile durchgegangen werden, die der Fahrer programmiert.

Kommt es zu "Verstößen" gegen die Checkliste ist es Aufgabe des Navigators, zu entscheiden, ob dieser "Verstoß" sofort aufgelöst werden muss (was zum Beispiel im Falle von Rechtschreibfehlern sicherlich sinnvoll ist) oder ob diese Verstöße eher in den GoalStack gehören – also auf eine kurze, völlig informelle Liste von Dingen, die man "noch in dieser Session" bereinigen muss. In diese letzte Kategorie fallen insbesondere notwendige Refactorings und Verstöße gegen das DRY oder YAGNI Prinzip.

Ein guter Startpunkt für eine solche Checkliste ist aus meiner Sicht die folgende:

• [Nur bei TDD und BDD] Haben wir einen (fehlschlagenden) Test für den Code, den wir gerade schreiben wollen?
• Wird die gleiche Absicht an andere Stelle im Code bereits ausgedrückt? (Verstoß gegen das Don't Repeat Yourself Prinzip, DRY)
• Benötigen wir diesen Code zu diesem Zeitpunkt? (Verstoß gegen das You Aren#t gonna Need It Prinzip, YAGNI)
• Kommuniziert der Code klar die Absicht, die mit ihm verfolgt wird? (Gegenbeispiel für C-Programmierer: {while(*p++=*q++)} )
• Entspricht der Code dem vereinbarten Coding-Style?
• Entspricht der Code den vereinbarten Naming Conventions?
• Entspricht der Code der vorgesehenen Nutzung des Frameworks?
• Ist der Code ausreichend dokumentiert?
• Bietet der Code Optionen für Refactorings? (Enthält er Code-Smells?)

Anm.:

Vor langer Zeit gab es mal einen guten aber kurzen Artikel darüber, was Pair-Programming davon unterscheidet einfach zu zweit vor einem Rechner zu sitzen.

Leider hat selbst extensive Google und Twitter-Recherche keine greifbaren Hinweise auf diesen Artikel geliefert, was bei mir die Befürchtung aufkommen lässt, dass es sich bei diesem Artikel und einen echten gedruckten Artikel handelt - daher diese Zusammenfassung aus meiner Sicht.

Einige der Quellen, auf die ich mich dabei beziehe sind:

http://c2.com/cgi/wiki?PairProgrammingPattern

http://c2.com/cgi/wiki?GoalStack

http://c2.com/cgi/wiki?LetTheJuniorDrive

http://webpages.cs.luc.edu/~anh/170/Kindergarten.html

http://softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/