Heute erscheint die neue Ausgabe der Fachzeitschrift OBJEKTspektrum, diesmal mit dem Schwerpunktthema “Lean Development und Kanban”. Darin finden Sie auch einen Artikel von mir über agile Projektverträge. Hier die Zusammenfassung:
Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden “immer” oder “oft” benutzt, fast zwei Drittel hingegen “selten” oder “nie”. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Diese Situation stellt neue “Anforderungen an die Anforderungen”. Der Artikel zeigt, wie Anforderungen heute aussehen können, damit man mit ihnen sehr schlanke Projektverträge gestalten kann. “Money for nothing, changes for free” sind hier die zunächst unglaublich klingenden Stichworte. Auftrag geber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden.
Google App Engine ist eine massiv skalierbare Umgebung – schön, doch Google hat dafür einige Designentscheidungen getroffen (treffen müssen?), die das Leben für Applikationen u.U. etwas schwer machen können. Z.B. fehlen in GAE’s Persistenzschicht die Aggregatfunktionen (sum, avg, min, max, …), die jede übliche relationale Datenbank mitbringt.
In Marcel Overdijks Blog gibt es dazu eine interessante Diskussion.
Ted Naleid hat einen guten Artikel über Unit-Testing mit Soft Assertions geschrieben.
Stefan Tilkov hat mich auf dieses Diagramm von Bud Caddell aufmerksam gemacht. Großartig! Ich finde, es gibt die Essenz des Freiberufler-Seins exakt wieder.
Ab und zu schaue ich über den Tellerrand zu meinen Kollegen aus dem Bereich der Architektur – ich meine diesmal die Gebäude-Architektur, nicht die Software-Architektur. Und da fällt mir immer wieder einmal jemand auf, der mich beeindruckt. Diesmal sind es Christoph Ingenhoven und seine Kollegen. Nicht nur die Website ist cool (Kompliment, wer hat die gemacht?). Auch die Entwürfe selbst sind wegweisend.
Ingenhoven sagt, dass er bei seinen Entwürfen immer darauf schaut, wie der Ort, den er erschafft, benutzt werden soll. Der Entwurf muss diese Benutzung ermöglichen und fördern (Christopher Alexander argumentiert übrigens genauso).
Das ist es, was mich an klar denkenden Leuten fasziniert – die klare Zielsetzung und das Bestreben, dieses Ziel möglichst geradlinig zu erreichen. Ich habe für meine Entwürfe in der Software-Architektur dasselbe Ziel – den “Ort” für die angestrebte Funktion zu erschaffen, und dies so einfach, dass man durch Weglassen nichts mehr verbessern kann.
Alistair Cockburn zitiert einen unbekannten Autor mit einem schönen Text über spirituellen Lebensstil.
Wow, jemand findet Worte, die ich schon immer gesucht habe, um meinen bevorzugten Schreibstil für Dokumente zu beschreiben:
“Write clearly and unpretentiously. Favor a down-to-earth style rather than a stuffy academic one. People understand and appreciate a conversational tone, making them more receptive to the material… Make sure everything you write is something you could hear yourself saying to a friend.”
Das sind die Worte von John Vlissides, einem der vier Mitglieder der GoF. Sie stehen in seinem Buch Pattern Hatching.
Kent Beck fasst Extreme Programming in ein paar Zeilen zusammen, so dass Sie es Ihrem Manager erklären können.
Ralf Westphal hat einen wirklich guten Artikel zur Klassifizierung von verschiedenen Veränderungen in einer Softwareentwicklungsorganisation geschrieben.
Die BBC hat kürzlich zum 15. Geburtstag des WWW mehrere Experten interviewt, um herauszufinden, wie die Zukunft des WWW in 15 Jahren aussehen könnte. Wichtige Leute wie Tim Berners-Lee, der Erfinder des WWW selbst, sind dabei.
Nach dem Lesen des Artikels bin ich ein wenig schlauer, doch ich behaupte, wir wissen nicht wirklich, wohin es mit dem Web gehen wird.
