Sonntag, Januar 29, 2006

Agile Methoden unter Beschuss oder: Die Rache des Wasserfalls

siehe http://www.waterfall2006.com

Post bewerten

Dienstag, Januar 24, 2006

Blog zur Kundenrolle in Softwareprojekten

Jürgen Ahting hat jetzt auch einen Blog. Hier geht es um die Kundenrolle in Softwareprojekten sowie die Wirtschaftlichkeit von Softwareprojekten.

Post bewerten

Sonntag, Januar 22, 2006

Groovy kann Typen

Ich hatte mir in einem früheren Blog-Eintrag für dynamische Sprachen wie Ruby gewünscht, dass man optional einen Typ nennen kann, der dann dynamisch zur Laufzeit geprüft wird. So kann man meiner Meinung nach die Lesbarkeit von Quellcode erhöhen. Nehmen wir als Beispiel folgende Methode (Syntax ist informell):

def loescheKunden(kunde)

Dann muss man die Doku oder die Methodenimplementation lesen, um herauszufinden, was hier übergeben werden muss. Das Kundenobjekt, die Kundennummer oder der Kundenname?

Eine Deklaration mit Typ würde diese Frage sofort beantworten:

def loescheKunden(Kunde kunde)

Jetzt habe ich mich näher mit Groovy beschäftigt und festgestellt, dass das genau so in Groovy funktioniert. Man kann optional Typen angeben, die dann dynamisch geprüft werden. Wenn man keinen Typ angibt, verhält sich Groovy wie die anderen dynamischen Sprachen und prüft den Typ auch nicht.

Post bewerten

Donnerstag, Januar 12, 2006

XP und Software-Engineering

Vor ein paar Tagen hat mich Tammo Freese mit folgendem Argument infiziert:

Wikipedia definiert: Die Softwaretechnik (software engineering) als Teilgebiet der Informatik beschäftigt sich mit der standardisierten ingenieursmäßigen Herstellung von Software und den damit verbundenen Prozessen.

Die einzige Methode zur Softwareentwicklung, die sich wirklich Software Engineering auf die Fahnen schreiben darf, ist demnach eXtreme Programming. Schließlich definieren alle anderen Methoden nur grobe Blöcke für die weitere Arbeit. Wie diese Blöcke konkret mit Arbeit zu füllen sind, lassen sie offen. Nur eXtreme Programming definiert hinunter bis auf die Ebene von Minuten, wie vorzugehen ist: Test erweitern, bis er fehlschlägt. Code so ändern, dass der Test wieder durchläuft. Und dann geht es wieder von vorne los.

Das ist ein weiteres Indiz dafür, dass die Industrialisierung der Softwareentwicklung erst jetzt mit den agilen Methoden stattfindet.

Post bewerten

Seminar: Kundenrolle in agilen Projekten

Agile Projekte versprechen früh einsetzbare Software mit einem besonders günstigen Kosten-Nutzen-Verhältnis. Damit die Erfolge mit agilen Projekten auch realisiert werden können, muss der Kunde seiner geänderten Rolle auch gerecht werden. Am 20.02.2006 findet zum zweiten Mal das Seminar Aufgaben und Chancen des Kunden bei agiler Softwareentwicklung der Deutschen Informatik Akademie (DIA) in Köln statt.

Ich führe das Seminar zusammen mit Jürgen Ahting durch.

Auszug aus der Seminarankündigung: Agile Softwareentwicklung (z.B. mit dem Extreme Programming, XP) ist mehr als ein neues Schlagwort. In vielen Praxisprojekten wurde bereits die Leistungsfähigkeit agiler Ansätze nachgewiesen. Die konsequente Zusammenstellung erfolgreicher und bewährter Planungs-, Arbeits- und Programmiertechniken sowie die aufmerksame Beachtung und Nutzung ihrer gegenseitigen Einflüsse bietet neue Chancen zur erfolgreicheren und effektiveren Entwicklung von Software. Insbesondere ergeben sich zusätzliche Möglichkeiten, die Risiken und Kosten von Projekten zu steuern und zukünftige Kosten zu verringern.

Agile Softwareentwicklung zielt darauf ab, mit vorgegebenen Ressourcen so schnell wie möglich den maximalen Nutzen für den Kunden zu realisieren, ohne dabei die Qualität zu kompromittieren. Ein wesentlicher Erfolgsfaktor für diese Nutzenoptimierung ist die enge und flexible Zusammenarbeit zwischen Kunden und Entwicklungsteam. Kurze Releasezyklen führen zu frühem Return-On-Investment und geben schnelles Feedback über Angemessenheit und Qualität der Software.

Die Vorteile des agilen Vorgehens sind leichter zu verstehen als umzusetzen, weshalb auch agile Projekte scheitern können. Da der Kunde beim agilen Vorgehen eine zentrale Rolle einnimmt, kann er die Vorteile nur dann voll ausschöpfen, wenn er seine Rolle auch genau versteht und optimal ausfüllt. Deshalb ist es nicht nur für die Ausführenden sondern auch für die auf Kundenseite maßgeblich an agilen Softwareentwicklungsprojekten Beteiligten extrem wichtig, aus der praktischen Erfahrung in Projekten verschiedenster Größenordnungen zu lernen. So können sie die wirtschaftlichen Hintergründe der agilen Praktiken verstehen und ihre Rolle als Auftraggeber sinnvoll wahrnehmen und geschickt agieren. Nur dann wird es möglich sein, agile Entwicklungsprojekte optimal zu gestalten und zum Erfolg zu führen.

Nähere Informationen zu dem Seminar gibt es auf der Website der DIA oder über den Flyer zum Seminar.
Anmeldungen für das Seminar nimmt die DIA direkt entgegen.

Post bewerten

Sonntag, Januar 08, 2006

Codelängen

Bei meinen Recherchen zu Groovy bin ich über ein interessantes Beispiel gestoßen. Dasselbe kleine Programm einmal in C#, in Java und in Groovy sowie Ruby (Achtung: Der Ruby-Quellcode findet sich in den Kommentaren zu der Groovy-Seite. Man muss dort also nach unten scrollen. Leerzeilen habe ich nicht mitgezählt und ich habe bei Java und C# ein paar Zeilen abgezogen, die der Formatierung im Web geschuldet waren):

  • C#: 45 Zeilen Code

  • Java: 56 Zeilen Code

  • Groovy: 14 Zeilen Code

  • Ruby: 17 Zeilen Code



Von der unterschiedlichen Zeilenanzahl zwischen Groovy und Ruby sollte man sich nicht verwirren lassen. Im Groovy-Beispiel wurde eine Methode einfach in eine Zeile geschrieben, für die im Ruby-Beispiel drei Zeilen verwendet wurden. Man kann sagen, dass die Implementation in Groovy und Ruby identisch ist - abgesehen von syntaktischen Kleinigkeiten.

Bedeutet das jetzt einen relevanten Unterschied für die Praxis? Moderne IDEs helfen, auch den umfangreicheren Java- und C#-Code schnell zu erstellen. Der Autor der Java-Version hat mit IntellJ IDEA nur 10% des Codes wirklich eingetippt.

Ich meine, da ist sehr wohl ein Unterschied. Schließlich wird Quellcode viel häufig gelesen als geschrieben. Für die Produktivität der Entwicklung ist daher ausschlaggebed, wie aufwändig das Lesen und Verstehen existierenden Codes ist und nicht wie schnell man den Code tippen kann. Und die einschlägigen Statistiken sagen, dass die Anzahl der Zeilen Code, pro Personentag entstehen ebenso konstant ist, wie die Anzahl der Fehler, die man durchschnittlich je 1.000 Codezeilen macht. Ob man also 1.000 Zeilen Code mit Java oder Groovy schreibt: Man braucht gleich lang und programmiert die gleiche Anzahl Fehler in den Code. Nur, dass man in 1.000 Zeilen Groovy viel mehr Funktionalität programmieren kann als in 1.000 Zeilen Java.

Post bewerten

Groovy

Dynamische Programmiersprachen a la Python und Ruby haben in den letzten Jahren viel Aufmerksamkeit erhalten. Ein wenig untergegangen ist da bisher Groovy. Groovy ist Bestandteil der Java-Platform und mit dem JSR-241 spezifiziert.

Groovy lehnt sich bei der Syntax an Java (Groovy-Syntax ist Java-Syntax mit weniger Regeln) an und ist von den Sprachkonstrukten ähnlich zu Python oder Ruby. Besonders interessant ist Groovy für Java-Programmierer, weil es insbesondere eine gute Integration mit Java gibt. Man kann Groovy-Code ganz einfach aus Java heraus aufrufen und umgekehrt auch Java-Code einfach aus Groovy. Damit hat man insbesondere gleich das ganze JDK in Groovy zur Verfügung.

Dadurch kann man z.B. Swing-Code mit Groovy schreiben und die Kernfunktionalität der Anwendung mit Java. Vorteil: Der Groovy-Swing-Code ist kürzer und verständlicher als derselbe Code in Java.

Und es gibt das Groovy-Äquivalent zu Ruby on Rails: Grails.

Weitere - gut strukturierte - Informationen zu Groovy gibt es hier.

Post bewerten

Donnerstag, Januar 05, 2006

Industrialisierung der Software

Seit Jahrzehnten wird immer wieder gefordert, die Softwareentwicklung müsste endlich aus der Produktion lernen. Insbesondere die Planbarkeit der Softwareentwicklung wurde als Ziel formuliert. Automatisierte Code-Generierung mit CASE-Tools, Software-Fabriken, vollständige Spezifikationen etc. haben versucht, diesen Anspruch einzulösen - mit allenfalls bescheidenem Erfolg.
Als Kontrapunkt dazu sind um die Jahrtausendwende (das hört sich doch mal monumental an :-) die agilen Methoden wie eXtreme Programming, SCRUM, Crystal etc. entstanden. Dabei hat sich immer deutlicher herausgestellt, dass sich in den agilen Methoden viele Ideen wiederfinden, die bereits das Produktiongewerbe revolutioniert hatten: Lean Production, Lean Manufacturing, Just In Time, Kaizen. Auf den Punkt gebracht haben das die Poppendiecks in ihrem empfehlenswerten Buch Lean Software Development.
Also kann man sagen, dass mit den agilen Methoden die Industrialisierung doch noch Einzug in die Softwareentwicklung gehalten hat - nur eben auf eine ganz andere Art als ursprünglich gefordert.

Post bewerten

Mittwoch, Januar 04, 2006

eXtreme Programming in der Financial Times Deutschland

In der Financial Times Deutschland ist gerade ein Artikel über eXtreme Programming erschienen. Interessanterweise wird die Sinnharftigkeit nicht mehr in Frage gestellt. Jetzt machen es die Firmen nicht, weil die die Entwickler nicht wollen oder können. Und gleichzeitig sagen die Entwickler überall, sie können XP nicht einführen, weil ihr Management nicht mitspielt...

Post bewerten

Kritik zu unserem XP-Buch

Hier gibt es eine Kritik zu Buch über eXtreme Programming, dass ich zusammen mit Henning Wolf und Martin Lippert geschrieben habe.

Post bewerten

Sonntag, Januar 01, 2006

Hibernate 3-Buch: Beispielcode und XDoclet-Kapitel online

Buch: Fit for Developing SoftwareIch habe an einem Buch über Hibernate 3 mitgeschrieben (zusammen mit Robert Beeger, Arno Haase und Sebastian Sanitz). Das Buch wird im Februar 2006 im dpunkt-Verlag erscheinen. Bereits jetzt gibt es Beispielcode aus dem Buch sowie ein Kapitel über XDoclet zur Generierung der Mapping-Dateien online zum Download.

Post bewerten