In der Kolumne "Perspektivenwechsel" im Javamagazin haben wir diverse Artikel veröffentlicht:

• Im Coding Dojo
• Der agile Festpreis
• Erzähl doch k(l)eine Geschichten!
• Singletasking
• Voll Retro!
• Schatz, was denkst du gerade?
• Auf die Plätzchen, fertig, los!
• Low-Tech-Tools
• Über Gelbe Säcke und die Qualität von Software
• Wahl ohne Kampf
• Schätz mich!
• Ja, ja, Chef - wird erledigt!
• Wer nicht fragt, bleibt dumm!
• Wie wir einmal Entwickler waren (aber keine Untertanen)
• Unverantwortliche Selbstorganisation?
• Aufklärung tut not: Nee zu TDD?
• Wie wir einmal Kunden waren (aber leider keine Könige)
• Chaos bei McBurger - Was Hamburger mit Lean Production zu tun haben
• Sackmann und Schneeohr - eine agile Weihnachtsgeschichte
• E-Mails - Fluch oder Nervensägen?
• Zwischen Selbstorganisation und Selbstillusion
• "Das haben wir doch schon immer so gemacht"

Erfahren Sie mehr über Software-Kanban, kurze Durchlaufzeiten, Qualität und kontinuierliche Prozessverbesserung.

• Einführung in Kanban
• Interview mit David Anderson

Der Artikel behandelt die Frage, wie man es schafft, dass bei fortgesetzten Änderungen am System der Aufwand für neue Anforderungen nicht übermäßig steigt.

Gemeinsam mit dem OBJEKTspektrum haben wir eine große agile Projektumfrage durchgeführt.
Das Fazit lautet: "Agile Softwareentwicklung wird Mainstream, dafür spricht nicht nur die hohe Bekanntheit und die Tatsache, dass viele Teilnehmer bereits erfolgreich agil vorgehen, sondern auch die Größe der Organisationen und die Zusammensetzung der Branchen."

Lean-Management in der Unternehmens-IT
Der Ruf der IT ist schlecht: Viele Manager meinen, dass IT-Projekten ständig der Misserfolg droht. IT sei überdies zu teuer und unflexibel. Auf der anderen Seite steigt die strategische Bedeutung der IT-Unterstützung in den meisten Organisationen. Lean-Management bietet leichtgewichtige Lösungen und Prinzipien, die in der Autoproduktion erfolgreich angewendet werden. Was verbirgt sich konkret dahiter und wie lassen sich diese Ideen in der Unternehmens-IT umsetzen?

Überblick über eXtreme Programming (XP)

eXtreme Programming (XP) ist die agile Entwicklungsmethodik, die einer ganzen Armada weiterer agiler Methoden den Weg ins Bewusstsein einer breiten Öffentlichkeit bereitet hat. Der Artikel stellt eXtreme Programming vor und zeigt Potenziale und Beschränkungen sowie die Beziehungen zu angrenzenden Methoden wie Scrum.

Dieser Artikel beschäftigt sich mit dem Management und dem Projektcontrolling
in einem FDD-Projekt. Parking Lot und Trend Charts veranschaulichen den Projektzustand und den voraussichtlichen weiteren Verlauf. Die Autoren stellen heraus, welche FDD-Techniken auch in Nicht-FDD-Projekten nutzbringend verwendet werden können.

Das erste und wichtigste Element beim Feature Driven Development ist das
Feature. Dieser Artikel beschäftigt sich mit Entwurf und Programmierung
der Features. Er zeigt das Mapping der Features auf Klassen und Methoden
und stellt Code-Inspektionen als Technik zur Qualitätssicherung in FDD vor.

Nach dem Überblick in der letzten Ausgabe wird nun der Featurebegriff aus Feature Driven Development (FDD) vorgestellt. Es wird gezeigt, wie Features definiert und wie entlang von Featurelisten geplant wird. Dabei stellen die Autoren heraus, welche FDD-Techniken auch in anderen Projekten nutzbringend verwendet werden können.

In dieser Artikelserie wird mit Feature Driven Development (FDD) eine agile Methode beschrieben, die explizit eine vorgelagerte Analyse- und Modellierungsphase vorsieht und für große sowie für Festpreisprojekte gut geeignet ist. Der erste Teil gibt einen Überblick über FDD.

Feature Driven Development (FDD) ist eine leichtgewichtige agile Entwicklungsmethode, die sich seit über zehn Jahren in kleinen und großen Softwareprojekten bewährt hat. Mit seiner vorgelagerten Modellierungsaktivität beantwortet FDD auch Fragen nach Gesamtaufwänden und bietet so eine belastbare Basis für Festpreisprojekte. Trotzdem ist FDD in Deutschland relativ unbekannt. Der Artikel gibt einen Überblick über das Thema.

Einfachheit von Technik ist in erster Linie ein Architekturkonzept, das Komplexität reduziert, indem überschaubare, leichtgewichtige Technik aus wenigen, aber gut harmonierenden Bausteinen eingesetzt wird. Zweitens sollen Architekturentscheidungen im Unternehmen explizit gemacht  werden. Und zum Dritten ist Einfachheit von Technik das Komplement zu agilen Methoden.

Als Entwickler ziehen wir uns gerne auf einen neutralen Standpunkt zurück:
Das Management entscheidet, und wir setzen um. Wir sind lediglich für die korrekte Realisierung der Managemententscheidungen verantwortlich, bei den restlichen Folgen waschen wir unsere Hände in Unschuld. Doch so einfach lassen uns die Autoren dieses Artikels nicht entkommen.

Technology First - am agilen Stammtisch
In einer Instant-Messaging-Konferenz wurde die Frage diskutiert: Warum setzen wir all die guten und Erfolg versprechenden Praktiken der Softwareentwicklung – von Unit-Tests bis Design Patterns – nur sehr sporadisch um? Tatsächlich wurden jedoch im Laufe der anderthalbstündigen Diskussion eine ganze Reihe weiterer, (hoffentlich) interessanter Themen gestreift.

Wir Entwickler beschäftigen uns gerne mit handfester Technik, obwohl vermutlich jedem mit ein wenig Projekterfahrung klar ist, dass Projekte an ganz anderen Problemen scheitern. Die Autoren dieses Artikels vertreten die These, unsere Technikverliebtheit sei zwar verständlich, schade dem Projekterfolg jedoch mehr, als sie nütze.

Das Eclipse-SDK bietet einen sehr umfangreichen Satz automatisierter Refactorings an. Dennoch werden die Möglichkeiten dieser Refactorings nur selten wirklich ausgenutzt. Stattdessen werden viele Refactorings immer noch „per Hand“ ausgeführt – obwohl man es sich deutlich einfacher machen könnte. Wie? Das zeigt dieser Artikel.

Die hinter Agilität stehenden Werte und auch die damit verbundenen Erwartungen an erfolgreiche Entwicklungsprojekte sind heute so weit anerkannt, dass sich immer mehr Teams und Methoden für agil erklären. Nur ein Teil von ihnen beansprucht dieses Etikett zu Recht. Agil zu sein, ist auch gar nicht so einfach. Der Artikel beschreibt die zwölf häufigsten Fehler, die die Autoren selbst gemacht oder in anderen Projekten beobachtet haben.