25.1.2008 von Jens Coldewey.

Zu den - neuen - Kerngedanken agiler Entwicklung gehört die Idee, den Prozess in die Verantwortung des Teams zu geben. Das entspricht zum einen dem agilen Manifest, das ja fordert, dass “Individuen und Interaktion wichtiger sind, als Prozesse und Werkzeuge”. Zum anderen wird hier einmal wieder ein Konzept aus dem “Lean Management” umgesetzt: Bei Toyota haben die Arbeiter in der Produktion erheblichen Einfluss auf die Produktionsprozesse. Schließlich wissen sie am besten, was gut funktioniert und was nicht.

Die Verantwortung für den Prozess zu bekommen bedeutet freilich nicht, dass jeder tun und lassen kann, was er will. Das Team muss vielmehr definieren, wie es arbeitet und diesen Prozess ständig verbessern. In seinen Crystal Methoden hat Alistair Cockburn die “Methodology Shaping Workshops” nach jeder Auslieferung als eine der wenigen bindenden Praktiken definiert. Seitdem vor sieben Jahren Norm Kerths Buch “Retrospectives” erschienen ist (siehe unten), haben sich Retrospektiven in allen agilen Verfahren als zentrale Praktik entwickelt: Regelmäßig stattfindende Workshops, auf denen alle Beteiligten reflektieren, wie das letzte Release gelaufen ist und beschließen, was in Zukunft anders gemacht werden soll. Es handelt sich dabei um eine Reflexion der gelebten Projektpraxis, also nicht um ein Review eines Prozessdokuments und auch nicht um einen Audit.
Den Rest des Eintrags lesen »

Geschrieben in it-agile-blog-planet, Praktiken, Buchtipp, Agilität | Drucken | 1 Kommentar »

9.1.2008 von Jens Coldewey.

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.

Geschrieben in Management, Buchtipp | Drucken | Keine Kommentare »

27.11.2007 von Jens Coldewey.

Programmiersprachen spielen keine wesentliche Rolle habe ich einst gelernt, es kommt vor allem auf die Qualität der Entwickler an. Diese Aussage stammt aus den frühen 80er Jahren, als Barry Boehm sein “Software Engineering Economics” veröffentlicht hat. Und tatsächlich kann die beste Programmiersprache der Welt wenig ausrichten, wenn das Team inkompetent ist - und ein kompetentes Team wird auch mit altertümlichen Programmiersprachen noch etwas ausrichten können. Also alles in Butter? Gebt mir eine turingvollständige Sprache und ich wuppe Euch das Projekt? Wohl kaum.

Nur in wenigen Bereichen hat sich so viel in den letzten 25 Jahren verändert, wie bei Programmiersprachen und ihren Entwicklungsumgebungen. In den frühen 80ern hatte man im Wesentlichen noch die Auswahl zwischen C, COBOL, Pascal, PL/I und Assembler und bei den Entwicklungsumgebungen die Wahl zwischen vi, emacs und dem Host-Editor. Heute führen die Unterschiede zwischen den verschiedenen Sprachen und Umgebungen durchaus zu Produktivitätsunterschieden von einer Größenordnung, also um den Faktor 10; beim gleichen Team, wohlgemerkt.

Besonders fallen mir diese Unterschiede auf, wenn ich - wie heute einmal wieder - einem Kunden beim Umbauen einer C++ Anwendung helfe. Zur Erinnerung: C++ war der Versuch, dem guten alten C einige Konzepte überzustülpen, die bei flüchtiger Betrachtung als objektorientiert verkauft werden konnten. “Die C-Programmierer müssen dann nicht umlernen” war die häufigste Begründung für diese Sprache. Ohne das belegen zu können, vermute ich, dass genau dieser Umstand - unreflektierter Einsatz objektorientierter Techniken von Programmierern, die nur in prozeduraler Programmierung ausgebildet sind - zu den häufigsten technischen Gründen für gescheiterte Projekte zählt.
Den Rest des Eintrags lesen »

Geschrieben in it-agile-blog-planet, Refactoring, Buchtipp, Agilität | Drucken | 4 Kommentare »

27.11.2007 von Jens Coldewey.

Hinweis: Die Links zu den Buchtipps in diesem Blog verweisen im Rahmen des Amazon.de Partnerprogramms auf die entsprechenden Bücher bei Amazon.de

Geschrieben in Buchtipp, Allgemein | Drucken | Keine Kommentare »