Martin Fowler hat mal wieder einen sehr lesenswerten Eintrag geschrieben zum Thema „Welche Art von Wissen ist Wichtiger“. Seine Schlussfolgerung: Im Zweifelsfall ist es deutlich effizienter, einem guten Designer eine neue Plattform beizubringen, als einem Plattformspezialisten gutes Design. Ideal wäre natürlich beides, in der Realität steht man aber häufig vor der Wahl. Ich würde jedes seiner Worte unterschreiben.
Den vollständigen Eintrag finden Sie unter Prefer Design Skills
Ein wenig Werbung in „fremder Sache“: it-agile veranstaltet gemeinsam mit dem OBJEKTspektrum eine Umfrage über den derzeitigen Stand der Agilität. Die Ergebnisse werden im OBJEKTspektrum veröffentlicht. Da ich die Zusammenarbeit mit den Kollegen von it-agile immer sehr genossen habe (und auch selbst an den Ergebnissen der Umfrage interessiert bin), möchte ich diese Aktion unterstützen.
Wenn an der Umfrage teilnehmen wollen (auch wenn Sie [noch] nichts mit Agilität zu tun haben!), gehen Sie einfach bis zum 27.1.2008 auf folgenden Link: http://news.sigs-datacom.de/ff/srv2_output.php?s=25ddc0f8c9d3e22e03d3076f98d83cb2&xqnotr=1. Das Ausfüllen des Formulars dauert ca. 8 min.
Wie so häufig bei solchen Aktionen können Sie Ihre Kontaktdaten gegen die Teilnahme an einer Verlosung tauschen, Sie können aber auch anonym antworten.
„Ich bin nie gescheitert. Ich habe erfolgreich Wege eliminiert, die nicht zum Ziel führen“ antwortete er auf die Frage, wie er die tausenden Fehlschläge bei der Entwicklung der Glühbirne überstanden habe.
PS: Vielleicht sollte man, um das Bild von Edisons Persönlichkeit noch ein wenig abzurunden, ergänzen, dass Edison die Hinrichtung auf dem elektrischen Stuhl öffentlich als „to westinghouse“ bezeichnetet. Damit wollte er seinen Rivalen Westinghouse verunglimpfen, der die öffentlichen Netze auf Basis von Wechselstrom betrieben wollte, während Edison Gleichstrom bevorzugte.
[Hinweis: Ich habe diesen Eintrag nach einer Richtigstellung von Marko Schulz (s.u.) überarbeitet – 18.1.08]
Nun also doch: IBM hat am 14. Januar bekannt gegeben, dass Jazz ab sofort frei verfügbar ist. Damit steht das neueste „Baby“ der beiden Eclipse-Väter Erich Gamma und Andre Weinand wie auch schon Eclipse zumindest zur Evaluierung kostenlos zur Verfügung: Man muss IBM noch mit der Preisgabe seiner E-Mail Adresse bezahlen (http://www.jazz.net).
Selbst habe ich noch mit Jazz gespielt, geschweige denn es im Projekt eingesetzt. Dieser Bericht hier ist daher nur eine Zusammenfassung der White Papers und einer Vorführung auf der OOPSLA.
Was ist Jazz? Ähnlich wie Eclipse ist Jazz vor allem eine Plattform, also ein System, das zur Erweiterung mit Plug-Ins einlädt. Während Eclipse aber für den Arbeitsplatz eines einzelnen Entwicklers konzipiert ist, soll Jazz das ganze Team unterstützen. Es fordert damit also Micorsofts Team Foundation Server heraus.
Weiterlesen
Was ist eigentlich der methodische Unterschied zwischen Use Cases und User Stories? Ich habe mich selbst nicht sonderlich intensiv mit Use Cases beschäftigt, kann hier also nur wiedergeben, was ich von Alistair Cockburns Erklärung verstanden habe: Eine User Story ist letztlich die Überschrift eines Szenarios, möglicherweise zusammen mit einem Beispiel. Mehrere Szenarien ergeben gemeinsam einen Use Case.
Darf man als Agilist nun Use Cases verwenden, oder nicht? Die Frage ist in dieser Form natürlich Unsinn, weil es bei agiler Entwicklung nicht darum geht, was man „darf“ und was nicht, sondern wie man ein Ziel erreicht. Das Ziel ist in diesem Fall ein adäquates Verständnis der Art und Weise, wie das System eingesetzt wird.
Weiterlesen
In Alistair Cockburns Wiki erzählt ein Teilnehmer namens „Remick“ unter dem Titel „Why I still use use cases„, wie er ein Problem recht erfolgreich mit Use Cases analysieren konnte, bis ein „Agile Coach“ kam und das Team auf User Stories zwang – was letztlich zum Scheitern des Projekts führte, wenn man „Remick“ folgt.
Ich halte das für einen der häufigsten Fehler wenig- oder unerfahrener „Agiler Coaches“: Sie glauben, es müsse immer alles genau so ablaufen, wie in ihrem jeweiligen Lieblingsbuch beschrieben. Ich erinnere mich an eine Diskussion, ob man bei XP nur Karteikarten im amerikanischen Format verwenden könne, oder auch DIN A5 Karten verwendet werden dürfen…
Nach zehn Jahren Erfahrung mit der Einführung agiler Entwicklung sehe ich da manches entspannter: Ob jemand Use Cases oder User Stories verwendet, ist nicht projektentscheidend, solange man darauf achtet, sich nicht zu verkünsteln (Alistair hat fast eine halbe Stunde gebraucht, um mir überhaupt den Unterschied zu erklären…). Und die Entscheidung, was man ändern sollte und was man getrost übernehmen kann, und in welcher Reihenfolge, ist eben von Organisation zu Organisation unterschiedlich. Das braucht Erfahrung und Fingerspitzengefühl. Allerdings bekommt man diese Erfahrung nicht in einem 2-tägigen Kurs, auch wenn man anschließend ein Zertifikat in der Hand hält.
Seit Anfang Januar ist die Erstausgabe des Magazins „Business Technology“ erhältlich, einem Magazin für oberes und mittleres IT-Management. An der Jungfernausgabe habe ich mit einem Artikel über „Geschäftsausrichtung der IT und moderne Entwicklungsverfahren“ mitgewirkt. Aus der Einführung:
IT muss sich heute konsequent an den Erfordernissen der Geschäftsstrategie ausrichten. Die Fähigkeiten von Software dürfen nicht die Gestaltung der Geschäftsprozesse bestimmen. Software-Entwicklung muss schnell und agil veränderten Geschäftsprozessen folgen.
Den vollständigen Artikel können Sie entweder in der Druckausgabe lesen, oder in der Online-Ausgabe.
PS: In einer Einführungsaktion des Software&Support Verlages kann man bis zum 10.2.2008 ein Gratisabo bestellen.
Stefan Hagen hat in seinem „Projektmanagement Blog“ eine Folie bereitgestellt mit den „Bestandteilen eines Projektplans„. Die Folie enthält unter anderem 18 Teilpläne, einschließlich „Arbeitspaketdefinitionen“ und „Terminplan (GANTT)“.
Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:
Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Weiterlesen
Auf Einladung der XP User Group Frankfurt werde ich den Vortrag „Einführung agiler Entwicklung – ein Erfahrungsbericht aus zehn Jahren Praxis“ auch am 29. Januar ab 19:30 Uhr in Frankfurt. Eine Beschreibung des Vortrags finden Sie im Blog-Eintrag vom 12.12.2007, nähere Informationen zur Veranstaltung auf dem „AgileWiki“ der XP User Group Frankfurt.
„Companies cannot overlay work practices that have been successful in other markets and expect them to work in India“, schreiben Kari Heistad und Anjali Bhatia ihrem E-Mail Beitrag „An Introduction to Doing Business with India“ für den „Cutter IT Adivsor„. Diese Aussage ist sicherlich so richtig, wie sie auch generell ist: Ebensowenig, wie man indischen Firmen Verfahren und Kulturen aufpfropfen kann, die in Europa oder Nordamerika gut funktionieren, kann man automatisch davon ausgehen, dass in Indien erfolgreiche Vorgehensweisen auch bei uns sinnvoll einsetzbar sind.
Mich erinnert diese Feststellung – die eigentlich eine Selbstverständlichkeit ist – an das Phänomen, dass der größte Teil der nach CMM-I Level 5 zertifizierten Entwicklungsunternehmen in Indien ansässig sind. Hierzulande räumen selbst ausgewiesene Protagonisten des CMM-I ein, dass sich sowohl Kosten- als auch Qualitätsvorteile nur bis einschließlich Level 3 nachweisen lassen. Bei Level 4 und 5 droht der bürokratische Aufwand den Nutzen zu übersteigen (siehe R. Solingen: „Measuring the ROI of software process improvement„, Software, IEEE, May-June 2004, Volume 21, Issue 3 Seiten 32- 38)
Vielleicht haben sich die Verfasser und Protagonisten des CMM-I mit der Bezeichnung „Reifegradmodell“ doch auf eine etwas zu eindimensionale Vorstellung von „Reife“ festgelegt. Er scheint für die indische Kultur besser zu funktionieren, als für unsere.