Posts mit dem Label People werden angezeigt. Alle Posts anzeigen
Posts mit dem Label People werden angezeigt. Alle Posts anzeigen

Montag, November 24, 2008

Direkte Kommunikation in Konfliktsituationen

Es ist eigentlich ein alter Hut: Wenn ich ein Problem/Konflikt mit jemandem habe, versuche ich das direkt mit dem betroffenen zu klären und belästige damit nicht meinen oder seinen Vorgesetzten. Das stieht dem Vorgesetzten die Zeit und führt häufig zu noch größeren Problemen.
Quint Studer hat es in einem Blogeintrag sehr schön auf den Punkt gebracht: "If an employee at my organization is upset with another employee, who do they tell? If the answer is HR, or their boss, or that person’s boss – actually, if it’s anything other than the employee they’re upset with – then your culture is at risk of being derailed."
Wenn man dann im direkten Gespräch keine Lösung finden kann, holt man sich natürlich Hilfe - und da können Vorgesetzte dann wieder hilfreich sein.

Post bewerten

Dienstag, November 11, 2008

Stehen, stehen, immer nur stehen?

Hier ist ein interessanter Blog-Eintrag, in dem beschrieben wird, dass die japanischen Lean-Unternehmen auf das Stehen stehen (was für eine formvollendete Formulierung :-)
Die dort genannten Gründe für das Stehen (bessere Ergonomie, herumlaufen ist wichtig etc.) gelten alle auch für die Softwareentwicklung. Unsinn? Nein! Mein Kumpel Henning hat seit seinem Bandscheibenvorfall einen Tisch, der sich auf Stehhöhe hochfahren lässt. Und daran haben wir auch schon Pair-Programming gemacht und es war auf keinen Fall unangenehmer als dies sitzend zu tun.
Irgendwie haben wir die Idee aber nicht weitergetrieben. Ich habe aber mehr und mehr das Gefühl, dass wir das nochmal tun sollten.

Post bewerten

Montag, November 10, 2008

Kundenorientierung und Kommunikation extrem

absolut lesenswerter Artikel

Und jeder der denkt "bei uns geht sowas nicht", könnte mal dazu denken: "Was muss ich tun, damit sowas bei uns geht?".

Post bewerten

Dienstag, September 23, 2008

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Post bewerten

Freitag, August 01, 2008

Können Anwender/Fachexperten modellieren?

Auf diese Frage hätte ich früher mit einem klaren "Nein" geantwortet. Inzwischen mehren sich aber deutlich die Anzeichen, dass sie mit entsprechender Unterstützung vielleicht doch viel mehr können, als zumindest ich früher dachte.
  • In Feature-Driven-Development sind die Fachexperten beim Color Modeling mind. sehr stark in die Erstellung fachlicher Klassenmodelle involviert.
  • Bei InfoQ ist ein Artikel erschienen, der beschreibt, wie die Fachexperten selbst mit Domain Driven Design fachliche Klassenmodelle erstellt haben, die die Entwickler dann auch genau so umgesetzt haben.
Der InfoQ-Artikel hat mir auch nochmal eine Situation in Erinnerung gerufen, die wir vor 2 oder 3 Jahren in einem Projekt hatten. Wir hatten zeitliche Ereignisse an Wasserzählern modelliert (Einbau, Wechselung, Eichung etc.). Es wurde irgendwann im Projekt klar, dass wir das Modell ändern müssen. Der Code war schwer verständlich und sträubte sich gegen Änderungen.

In der Diskussion über das Zielmodell haben sich zwei Fronten im Team gebildet, die sich auch nicht von selbst auflösten. (Dass die Fronten entstanden sind, halte ich heute für ein Sympton eines tieferliegenden gruppendynamischen Problems, aber das ist hier nicht das Thema.)
Wir haben ziemlich viel Zeit in die Diskussion gesteckt, ohne zu einem Ergebnis zu kommen. Irgendwann habe ich einen Fachexperten einfach mal die beiden Modelle skizziert und gefragt, ob er etwas beitragen kann. Konnte er. Er hat gesagt, dass beide Modelle nicht so gut passen und ein drittes skizziert. Dieses Modell leuchtete dem ganzen Team schnell ein und wir haben die Änderungen durchgeführt. Tatsächlich beseitigte das Modell des Fachexperten unsere Probleme im System.

Post bewerten

Samstag, Dezember 15, 2007

Screencast zum Vortrag "Einfachheit in Softwareprojekten"

Auf den XP-Days habe ich einen Vortrag mit dem Titel "Einfachheit in Softwareprojekten" gehalten. Den habe ich als Screencast aufgezeichnet und dabei leider das Mikro so übersteuert, dass der Ton unbrauchbar ist.
Glücklicherweise hat Jens Himmelreich den Ton separat aufgezeichnet und mir zur Verfügung gestellt. Nach ziemlich viel Arbeit habe ich es dann auch geschafft, Bild und Ton so zu mischen, dass sie synchron laufen.
Das Gesamtkunstwerk kann man sich hier ansehen (oder einfach nur den Ton oder die Folien als PDF runterladen).

Nochmal vielen vielen Dank an Jens Himmelreich. Ohne seine Ton-Aufnahme wäre das alles nichts geworden.

Post bewerten

Samstag, Dezember 08, 2007

Warum einfach, wenn es auch kompliziert geht?

Ich habe auf den XP-Days in Karlsruhe einen Vortrag über Einfachheit in Softwareprojekten gehalten, den ich hoffentlich bald als Screencast online stellen kann.
In dem Vortrag ich von einem Experiment berichtet, dass von Bavelas an der Stanford-Universität durchgeführt wurde. Man hat Propanden mit Bildern von Gewebezellen konfrontiert. Sie sollten ohne medizinische Vorkenntnisse diagnostizieren, ob die Zellen gesund oder krank sind. Sie bekamen als Feedback dann jeweils, ob sie richtig oder falsch gelegen haben. Aus dem Feedback entwickelten sie ein Modell darüber, woran man krankhafte Gewebezellen erkennt.
Allerdings hat man nur der einen Gruppe korrektes Feedback gegeben. Die andere Gruppe hat zufälliges Feedback erhalten.
Schließlich hat man Paare mit jeweils einem Vertreter jeder Gruppe gebildet, die dann gemeinsam Gewebezellen diagnostizieren sollten. Und dabei setzte sich meistens die Person durch, der man das zufällige Feedback gegeben hatte.
Begründung: Diese Person hat sich auf Basis des zufälligen Feedbacks ein sehr kompliziertes (aber falsches) Modell darüber gemacht, woran man krankhafte Zellen erkennt. Die Person mit dem korrekten und einfachen Modell war begeistert von der Detailtiefe des komplizierten Modells ("da habe ich selbst wohl etwas übersehen") und ist daher der meist falschen Einschätzung seines Partners gefolgt.
Und dieses Phänomen findet sich auch ständig in der Softwareprojekten. Es ist so verführerisch den komplizierten Architekturen, Technologien und Vorgehensmodellen zu folgen. Ich glaube jedoch, dass das meistens der falsche Weg ist: Komplizierte Lösungen sind auch dann falsch, wenn sie richtig sind.

Eine genauere Beschreibung des Experimentes findet sich in "Wie wirklich ist die Wirklichkeit?" von Paul Watzlawick im Kapitel ("Warum einfach, wenn es auch kompliziert geht?"). Der Text findet sich unter der gleichen Überschrift auch Online auf Seite 20ff.

Post bewerten

Montag, Januar 01, 1990

Vorträge

siehe auch meine Artikel und Bücher

  • Bernd Schiffer, Stefan Roock: Agile Entwicklung mit Grails, XP-User-Group-Hamburg und Java-User-Group-Hamburg, Dezember 2007
  • Stefan Roock: Einfachheit in Softwareprojekten, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock (Organisation): Agile Lightning Talks, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock, Bernd Schiffer, Henning Wolf: Agile Lego Hour, W-JAX 2007, München, November 2007
  • Stefan Roock, Henning Wolf: Festpreisvertrag und agil nützt nicht viel?, Agility Day auf der W-JAX 2007, München, November 2007, Folien
  • Stefan Roock (Organisation): Agile Lightning Talks, Agility Day auf W-JAX 2007, München, November 2007
  • Stefan Roock: Anforderungen, Usability und Agilität, Universität Konstanz, 2007, Folien
  • Stefan Roock, Henning Wolf: Scrum und Lean-Management in IT-Projekten, Arbeitskreis Projektmanagement, Nordakademie, 2007
  • Jürgen Ahting, Stefan Roock: Warum sind die Kunden in Softwareprojekten so schwierig?, JAX 2007, Wiesbaden, 26.04.2007
  • Robert Beeger, Matthias Lübken, Stefan Roock, Sebastian Sanitz: XP-Live-Demo, JAX 2007, Wiesbaden, April 2007
  • Stefan Roock, Henning Wolf: IT-Kaizen: Kontinuierliche Verbesserung in der Softwareentwicklung, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Bernd Schiffer, Stefan Roock: Beispiel Grails - Brauchen wir neue Technologien für agile Entwicklung?, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Arno Haase, Stefan Roock, Sebastian Sanitz: Hibernate 3 (ganztägiger Power-Workshop). JAX 2006, Wiesbaden, 08.05.2006
  • Stefan Roock, Henning Wolf: Aufwandsschätzung in agilen Projekten. Lehmanns Buchhandlung, Hamburg, Januar 2006.
  • Robert Beeger, Arno Haase, Stefan Roock: Hibernate 3. (ganztägiger Power-Workshop). W-JAX 2005, München, November 2005.
  • Bernd Schiffer, Stefan Roock: eXtreme Programming (Tutorial). ix-Konferenz, Köln, November 2005.
  • Jürgen Ahting, Stefan Roock: Der Kunde in agilen Projekten. ix-Konferenz, Köln, November 2005
  • Stefan Roock: Aufwandsschätzung in großen agilen Projekten. ix-Konferenz, Köln, November 2005.
  • Stefan Roock: Refactorings in großen Softwareprojekten, XP-Days 2004, Karlsruhe
  • Martin Lippert, Stefan Roock: Refactorings in großen Softwareprojekten, Java Forum Stuttgart 2004, 01.07.2004, Stuttgart.
  • Stefan Roock, Martin Lippert, Frank Westphal: Testing in the Extreme Programming World. (Full-Day Tutorial). ICS Test, Köln, http://www.icstest.com, 01.04.2003
  • Stefan Roock, Martin Lippert: Large Refactorings (Workshop). OT 2003, Cambridge, UK, http://www.ot2003.org, 2003
  • Stefan Roock: Requirements Engineering bei agilen Methoden. GI-Workshop "Requirements Engineering", Ulm, http://www-lufgi3.informatik.rwth-aachen.de/GI/GI-FG2.1.6.html. 28.09.2002
  • Holger Breitling, Axel Schmolitzky, Stefan Roock: Extreme
    Programming (Half-Day Tutorial). Software Management Tagung, Hamburg, 06.11.2002
  • Holger Breitling, Petra Becker-Pechau, Stefan Roock: Agile Requirements Engineering (Full-Day Tutorial). RE 2002, Essen. 10.09.2002
  • Martin Lippert, Stefan Roock: Using and Adapting Extreme Programming (Full-Day Tutorial). ECOOP 2002, Malaga, Spanien, 11.06.2002
  • Martin Lippert, Stefan Roock: Extreme Programming in komplexen Projektsituatuionen (Full-Day Tutorial). OOP 2002, München. Januar 2002.
  • Stefan Roock: eXtreme Programming integrativ? GI-Workshop "Vorgehensmodelle". 2001
  • Martin Lippert, Stefan Roock: Extreme Programming in Complex Project Settings (Half-Day Tutorial). ECOOP 2001, Budapest, Ungarn, Juni 2001
  • Stefan Roock: Anforderungsermittlung mit eXtreme Programming. GI-Workshop
    "Requirements Engineering", 2001.
  • Stefan Roock, Henning Wolf: Framework-Entwicklung (Full-Day Tutorial). OOP
    2001, München, Januar 2001.
  • Stefan Roock: Object Oriented Design (3-Day Workshop). University
    of Roenneby, Schweden, März 2000.

Post bewerten