Autorenarchiv

« Ältere Einträge
 

Buchvorstellung “Payback”

Freitag, 15. Januar 2010

Früher hatte dieser Blog ja mal den Untertitel “Technologie und ihre Folgen”. In diesem Sinne erlaube ich mir mal zur Abwechslung ein Buch vorzustellen, dass mir zum Jahreswechsel zwischen die Finger und unter die Augen gekommen ist.

Schirrmacher - PaybackEs handelt sich um das Buch “Payback” von Frank Schirrmacher.  Erschienen im Karl Blessing Verlag (16. November 2009).

Der Autor beschäftigt sich darin vorrangig mit der Frage, welche Auswirkungen die IT-Entwicklungen der letzten Jahre, insbesondere Vernetzung, WWW und Google, auf uns als Menschen haben. Dabei legt der Autor großen Wert darauf, dass er  kein grundsätzlicher Technologieskeptiker ist, der alle neuen Entwicklungen grundsätzlich ablehnt. Es geht auch nicht um Ablehnung, sondern vielmehr um kritische Beobachtung der Dinge, die um uns herum passieren und denen wir nicht entkommen können.

Warum ist dieses Buch nun etwas für diesen Blog? Wie der Autor ganz richtig bemerkt sind wir, die Softwareentwickler und Architekten, diejenigen, die mehr als jeder Andere Einfluss haben auf die Gestaltung unserer Welt. Hört sich massiv an, aber ist es nicht so? Wir sind die paar Prozent der Gesellschaft, die einerseits die technischen Rahmenbedinungen des WWW überhaupt verstehen aber auch ausbauen können. Also kann es ja nicht schaden, intelligente Gedanken zu diesem Thema zu hören und zu reflektieren.

Intelligente Gedanken sind ein gutes Stichwort: Das Buch ist definitiv nix für die intellektuelle Unterschicht. Bei amazon findet man Kommentare, dass der Autor zu viel schwallert und wichtigtuerisch fehlerhafte Thesen aufstellt. Der Sprachstil ist gepflegt gehoben und der Mann schreibt eben, wie ein Germanist schreibt. Aber man muss sagen: für einen Germanisten hat er erstaunlich viel verstanden.

Seine Beobachtungen von Rahmenbedingungen und Zusammenhängen finde ich recht interessant, auch wenn die eine oder andere Schlussfolgerung sicher in Frage zu stellen ist. Insbesondere zum Ende hin erwartet der Leser eine Art Lösungsvorschlag zu den angesprochenen Themen, der aber deutlich schwammiger (und rein von der Anzahl der Seiten im Buch kleiner) ausfällt, als die Feststellung der Ist-Situation. Somit bleibt ein etwas schaler Nachgeschmack, zumindest für mich als lösungsorientierten Menschen.

Unterm Strich möchte ich dieses Buch dennoch jedem empfehlen, der mal eine andere Sichtweise auf unsere tägliche Arbeit und unsere Welt gewinnen möchte. Ich habe viele bekannte Aspekte in dem Buch wiedergefunden und hatte Spaß an einem teils kritischen, teils interessanten und teils philosophischen Ausflug. Wie gesagt: für einen Germanisten hat er eine Menge verstanden.


Andreas Jene

Abgelegt in Allgemeines | Keine Kommentare »

SCRUM als Dienstleister

Montag, 14. September 2009

“Ihr macht SCRUM? Und wie macht Ihr das als Dienstleister?”

Wenn wir mit Bekannten und Kunden darüber sprechen, welches Vorgehen wir bei uns in der Softwareentwicklung einsetzen, dann hören wir häufig diese Frage. So verlockend SCRUM auch ist, es scheint sich auf dern ersten Blick nicht so sehr für den Einsatz als Dienstleister zu eignen. Es sprechen offensichtlich  zwei Gründe dagegen:

  1. SCRUM ist ein iteratives Vorgehensmodell. Es ist quasi Teil der Philosophie, dass zu Beginn des Projektes nicht der gesamte Umfang des Projektes definiert ist und sich dieser Schritt für Schritt aus den Fortschritten des Projektes entwickelt.
  2. Der Kunde und seine Ansprechpartner kennen z.T. nicht  die Notwendigkeiten eines Software-Projektes. Sie verstehen sich daher nicht als Teil des Projektes und sind kaum in der Lage, die Rolle des Product Owner richtig zu spielen. Und wer kann sonst der Produkt Owner sein, wenn nicht der Kunde?

Und um es gleich vorweg zu nehmen: wir haben auch noch keinen Königsweg gefunden. Anhand unserer Erfahrungen aus dem letzten Jahr können wir aber einige Ideen mitgeben:

Zu Punkt 1 muss man zunächst auf das deutsche Gesetz schauen, damit das Dilemma klar wird. Wenn man zu einem Festpreis einen sog. “Werkvertrag” mit dem Kunden abschließt, dann schuldet man dem Kunden für den Werklohn den “Erfolg”. Man muss also das “Werk” fertigstellen und zwar so, wie es mit dem Kunden vereinbart wurde. Wenn es keine Definitionen zum Werk gibt, dann schuldet der Auftragnehmer ein Ergebnis mit den “durchschnittlichen” Eigenschaften, die man so erwarten dürfte. Diese Rahmenbedingung zwingt den Dienstleister, Rahmen und Umfang der gewünschten Software zu definieren. Das ist völlig unabhängig von SCRUM. Und ebenso unabhängig von SCRUM stellt es den Dienstleister vor die Aufgabe, ein Angebot abzugeben, zu dem er am Ende stehen muss. Als Dienstleister  muss ich also im Falle eines Werkvertrages den Gesamtumfang kennen und eine Schätzung des Umfanges haben, zu der ich stehen kann. Dies ist kein SCRUM Problem und wird auch mit SCRUM nicht gelöst (was man irrtümlich jedoch hofft).

Alternativ kann man auf eine vertrauensvolle Zusammenarbeit mit dem Kunden bauen und eine Entlohnung nach Aufwand vereinbaren. Das ist für den Dienstleister bequemer, verlagert das finanzielle Riskio jedoch auf den Auftraggeber, ohne auch die Entscheidungshoheit auf den Auftraggeber zu verlagern, sofern er Kunde keine Ahnung von Softwareprojekten hat. Insofern ist dieser Ansatz wohl nur etwas für Dienstleister-Kunden-Beziehungen, denen ein hohes Maß an Vertrauen zugrunde liegt.

Zu Punkt 2:  Wenn der Kunde die Rolle des Product Owner nicht kennt, dann muss man ihm helfen. So einfach ist das – und so schwer umzusetzen. Wenn der Kunde nämlich jemand ist, der sich nicht selber bemüht, diese Rolle auszufüllen, dann muss der Dienstleister dem Kunden jemanden zur Seite stellen, der diese Arbeit in Vertretung des Kunden übernimmt. Im einfachsten Fall könnte das ein sehr bemühter SCRUM Master sein, der nie müde wird, den Kunden immer wieder anzusprechen, hinzuweisen und einzubinden. Aber auch ein Berater, der keine andere Aufgabe hat, als die Visionen des Kunden “anwaltlich” zu übernehmen wäre denkbar.

Beide Punkte zeigen mal wieder eines: SCRUM ist kein Heilmittel, dass problemloses Projektmanagement ohne Aufwand verspricht. Es ist ein Werkzeug, das richtig eingesetzt werden muss, damit es seine ganze Macht entfalten kann.


Andreas Jene

Tags:
Abgelegt in Allgemeines | Keine Kommentare »

Mein erstes eigenes Rails-PlugIn

Montag, 29. Juni 2009

Letztens hat mich ein Kollege gefragt: “Was ist das Problem, wenn man 2 Rails-Entwickler und 2 Java-Entwickler in ein Projekt steckt? Man hat hinterher 4 Rails-Entwickler…”.  Ok, Rails macht Spaß. Aber es ist nicht immer soooo ganz einfach auch mal hinter die Kulissen zu schauen. So habe ich auch ein wenig gebraucht, bis ich zum ersten mal ein einfaches eigenes Plug-In schreiben konnte, das automatisch die anderen Klassen in meinem Projekt bei Systemstart erweitert.

Mein Privat-Projekt: Ein System zum Verwalten von Segel-Regatten und den zugehörigen Anmeldungen.(www.regattamanager.org)

Das Problem: Zu jedem Schiff, User und Anmeldung gehört ein Segel-”Club”, der referenziert werden soll. Allerings gibt es Clubs wie Sand am Meer und somit gibt es niemals eine Tabelle mit allen möglichen Clubs, sondern die Teilnehmer sollen selber auch eigene Clubs “on-the-fly” anlegen können.

Die Lösung: Meine Entitäten Ship, User und Registration sollen zwar intern eine Referenz auf die club_id besitzen, nach aussen aber diese Referenz wie zwei eigene Felder club_name und club_shortcut “maskieren” (und damit die automatische Erstellung von nicht vorhandenen Clubs übernehmen).

[Anmerkung:  Dass ich überhaupt in der Situation bin, das Problem wie oben zu haben und zu lösen ist wohl "broken-by-design", aber so ist das in Freizeitprojekten... ;-) ]

Die Strategie: In Java hätte ich einfach die Vererbungshierarchie der Entitätsklassen erweitert. Das geht aber in Rails nicht, da jede Kindklasse von ActiveRecord auch persistiert werden muss (Konvention). Somit bleibt mir nur eins: ein Plugin, in dem ich meine Funktionen in alle betreffenden Klassen “einmixe”. Ich nenne das Plugin “ClubMasquerade”.

Und so funktioniert das mit den PlugIns:

1. Ich schreibe mein eigenes “module” in vendor/plugins/club_masquerade/lib/club_masquerade.rb

require 'activerecord'
 
module ClubMasquerade #:nodoc:
 
 def self.included(base)
   base.extend ClassMethods
 end
 
  module ClassMethods
   def acts_as_club_masquerade
      before_save :set_club_from_fields  
      validates_length_of :club_name, :within => 3..50, :allow_blank =>true, :allow_nil => true
      validates_length_of :club_shortcut, :within => 2..10, :allow_nil => true, :allow_blank => true  
      include ClubMasquerade::InstanceMethods
    end
  end
 
  #  Hier sind die zu erweiternden Objekt- / Instanzmethoden drin
  module InstanceMethods
    # ...
  end
 
end

Beachte: mein Modul “ClubMasquerade” hat 2 Unter-Module “ClubMasquerade::ClassMethods” und “ClubMasquerade::InstanceMethods”

2. Und nun kommt das Kunststück: durch diese magische Zeile wird in meinem Modul die Funktion “self.included” (siehe 1.) ausgeführt. Die darin beschrieben Funktion ruft per “Reflection” die Methode “include” für ActiveRecord::Base auf und fügt damit den Funktionsumfang meines Moduls ClubMasquerade dynamisch der Klasse hinzu.

Im Projekt-Ordner vendor/plugins/club_masquerade schreibe ich dazu in die Datei init.rb

ActiveRecord::Base.send(:include, ClubMasquerade)

3. Kurzer Zwischenstand: Wenn Rails beim Hochfahren des Systems nun die init.rb findet und ausführt (Automatismus), dann wird der Funktionsumfang von ActiveRecord erweitert um meine eigenen Funktionen. Das bedeutet, dass auch in allen Model-Klassen (die sich ja von ActiveRecord ableiten) die Funktion “acts_as_club_masquerade” zur Verfügung steht.

In jedem Model wird nun eingetragen:

class Ship < ActiveRecord::Base
  acts_as_club_masquerade
# ...
end

Durch den Aufruf dieser Klassenmethode beim Interpretieren der Klasse “Ship” wird der zugehörige Codeblock aus meinem Modul ausgeführt (siehe oben). Und was macht der Code-Block “acts_as_club_masquerade” ? Er fügt wiederum Instanzmethoden zum Funktionsumfang meines Objektes hinzu, nämlich genau die Funktionen, die ich im Objekt erweitern wollte. Es lebe Reflection. Hoch Introspection. Vive la revolution!

Das Ergebnis:
Alle Model-Klassen, die ich mit meinem “acts_as_club_masquerade” versehen habe (und nur die) besitzen einen um meine Wünsche erweiterten Funktionsumfang, den ich entsprechend nutzen kann.

So, ich hoffe, das hilft ;-) !


Andreas Jene

Tags:
Abgelegt in Allgemeines, on Rails | Keine Kommentare »

Erfahrungsbericht Aglie Softwareentwicklung mit SCRUM

Montag, 16. März 2009

Wir haben lange verschiedene Formen des Projektmanagements für unsere Softwareprojekte ausprobiert. Erst mit SCRUM habe ich das Gefühl, die Kontrolle über unsere Softwareprojekte zurückbekommen zu haben.

Gleichzeit entspricht SCRUM genau dem, was wir eigentlich immer von allen Kollegen erwartet haben: eigenständige und verantwortungsvolle Softwareentwicklung. Allerdings lernen wir, die wir uns immer in der Verantwortung für die Ergebnisse und die Steuerung der Projekte sehen, jeden Tag dazu. Z.B. wie ein kleiner ungeschickt formulierter Kommentar des “Chefs” bei Mitarbeitern schnell zu Misverständnissen führen kann. Wenn man nicht aufpasst bauen sich Blockaden in der Kommunikation auf und die Situation wird schwieriger – zwischenmenschlich und im Projekt. Die “Chefs” können eben nicht immer in die Köpfe der Mitarbeiter schauen – und andersrum geht es auch nicht.

Was das mit SCRUM zu tun hat? Zum einen gibt es im SCRUM das Regelwerk zur Durchführung von Projekten, inkl. Sprints, Rollenverteilung, Meetingzyklen usw. – dazu wurde schon viel Literatur verfasst.
Zum anderen ist SCRUM eine Frage der Arbeitskultur. Und dies ist wohl der Punkt, an dem sich das Gelingen oder Mislingen eines jeden Projektprozesses entscheidet!

Was ich meine ist: die reine Einführung des SCRUM Regelwerkes wird nicht funktionieren, wenn es nicht von ALLEN Beteiligten in gleichem Maße gewünscht ist. Jeder muss es wollen und auch unterstützen – Product Owner, Scrum Master und auch das Team! Manchmal habe ich in Gesprächen den Eindruck, dass der Wille zum SCRUM Prozess hauptsächlich bei den sog. Projektmanagern liegt. Ist ja auch klar, da diese den stärksten Wunsch haben, irgendwie das Projekt unter “Kontrolle” bringen zu können. Wenn der Wille aber nicht gleichermaßen auch z.B. beim Team vorhanden ist, dann hat der Projektmanager nur die Möglichkeit, den Prozess über Druck auf die Mitarbeiter durchzusetzen. Und damit wäre er dann schon direkt kontraproduktiv, da der Druck früher oder später die Eigenständigkeit des Teams erstickt und eben diese im SCRUM erwünscht ist.

Ich habe mit Absicht Projektmanager geschrieben, nicht SCRUM Master, denn wie wir alle wissen, ist der SCRUM Master kein verantwortlicher Manager. Und das ist genau der Punkt: unterschiedliche Arbeits- und Denkkultur. Wir versuchen zwar das Neue (SCRUM) umzusetzen, im Zweifelsfall verfallen wir aber immer wieder in alte Ansichten (Projektmanager, Gannt-Charts).

Es ist wichtig, dass sich jeder Einzelne für seine Verantwortung in einem SCRUM Prozess bewusst ist. Diese Verantwortung ist der Preis für einen hohen Grad an Eigenständigkeit und viele Rechte, die der Einzelne sonst nicht hätte. Mit diesen Rechten und Pflichten sollte sich jeder Beteiligte identifizieren – und dann damit auch umzugehen wissen. Jeder, der sich damit nicht auseinandersetzt und somit (beabsichtigt oder nicht) Rechte und Pflichten verletzt, sorgt auf seine Art für eine Destabilisierung des Prozesses.

Mein Fazit: SCRUM funktioniert, wenn ALLE Beteiligten es auch wirklich unterstützen. Der “Aufwand” lohnt sich!


Andreas Jene

Tags:
Abgelegt in Allgemeines, SCRUM | Keine Kommentare »

« Ältere Einträge