Agile Software Entwicklung mit Jira

Vor ungefähr einem Jahr habe ich in diesem Blog über die Vorteile der agilen Software Entwicklung berichtet. Erfreulicherweise scheint es immer mehr Entwicklungsprojekte zu geben, die erfolgreich agil durchgeführt werden.

Zur Unterstützung dieses Vorgehensmodells bietet sich die Software Jira der Firma Atlassian (http://www.atlassian.com) an. Jira ist eine Web-basierte Anwendung zur Verwaltung von neuen Features, Fehlern und Verbesserungsvorschlägen. Nach einer kurzen Einarbeitungszeit lässt sich Jira intuitiv bedienen und erfährt eine hohe Aktzeptanz in den Projekten. Sowohl Entwickler als auch Anwender, Anforderungsmanager und Projektleiter haben über die gesamte Projektlaufzeit hinweg einen Überblick über den aktuellen Stand. Jira wird von ca 14500 teils namenhaften Kunden eingesetzt (http://www.atlassian.com/software/jira/customers.jsp)

Ein großer Vorteil ist, dass die Software nicht teuer ist. Eine kommerzielle Lizenz kostet für die einjährige Nutzung 10 $ für bis zu 10 Benutzer. Es besteht auch die Möglichkeit, Jira hosten zu lassen, dann wird es teurer.

Jira basiert auf Servlet-Technologien und lässt sich daher in einem beliebigen Servlet-Container betreiben. (wie zum Beispiel dem Tomcat) Zur Speicherung der Daten kann z. B. das kostenlose DBMS MySQL verwendet werden.

Ein weiterer Vorteil von Jira ist die offene Plugin Architektur. Für die agile Software-Entwicklung gibt es z. B. das Greenhopper Plugin (http://www.atlassian.com/software/greenhopper) Mit Hilfe dieses Plugins wird die Verwaltung von Anforderungen für ein iteratives Vorgehen in der Entwicklung ermöglicht. Das Greenhopper Plugin bietet folgende Highlights:

• Iterationsplanung (bzw. Sprint-Planung) im Product Backlock
• Abbildung von Scrum-Elementen (Storys, Technical Tasks)
• Schlüssellung von Zeiten auf Tasks und dadurch effektives und ständiges Projekt-Controlling
• Erstellung von Burn-Down Charts und Reports zur Analyse des vergangenen Sprints

Insgesamt lassen sich agile Software Projekte (insbesondere auch Scrum oder Kanban-Projekte) sehr schön mit Jira und dem Greenhopper Plugin abbilden.

Auch weitere Produkte aus dem Hause Atlassian wissen zu überzeugen: Das Confluence Wiki (http://www.atlassian.com/de/software/confluence)
kann die Basis für eine immer aktuelle Projekt-Dokumentation bilden. An zentraler Stelle können die Projektbeteiligten zusammen daran arbeiten, dass die wichtigsten Informationen stets up-to-date und für alle zugänglich sind.

Artikel "Java meets Alfresco" im Java Magazin erschienen

In der Ausgabe 07/2011 des Java Magazins ist mein Artikel "Java meets Alfresco" erschienen.

Darin beschreibe ich, wie man aus einer Java Anwendung heraus auf das DMS Alfresco (www.alfresco.com) zugreift.

In vielen Projekten wird als Modell einer Anwendung eine relationale Datenbank eingesetzt. Sollen aber Dokumente verwaltet werden, lohnt sich oft der Einsatz eines DMS, da es viele Funktionalitäten bereits mitbringt, die der Entwickler sonst mühsam nachprogrammieren müsste. Zu diesen Features zählen:

• die Volltext-Indizierung von Dokumenten
• Vergabe von Meta-Daten
• Versionierung
• Einstellen von Zugriffsberechtigungen
• Protokollierung von Änderungen an Dokumenten

Alfresco bietet sich als Basis einer Java Anwendung an, da die Community-Edition kostenlos zu beziehen ist. Außerdem ist Alfresco eine Servlet-Anwendung, sodass die benötigte Infrastruktur bei Java Entwicklern bereits bekannt und vorhanden ist.

Um auf die Alfresco Services zuzgreifen, gibt es ein API namens Apache Chemistry (http://chemestry.apache.org). Im Artikel ist beschrieben, welche Schritte zum Verbindungsaufbau notwendig sind und wie mit wenigen Zeilen Code eine Volltext-Suche implementiert werden kann. Eine Beispielanwendung liegt der Heft-CD bei. Viel Spaß beim Lesen und Auprobieren!

Suchmaschinenoptimierung - lohnt es sich, viel Geld zu investieren?

Suchmaschinenoptimierung ist wie ich finde ein höchst interessantes Thema. Es gibt unzählige Meinungen, Vorgehensweisen und Falschinformationen zur optimalen Platzierung einer Web-Seite in den oberen Rängen von Google und Co. Viele schwarze Schafe tummeln sich mit unseriösen Angeboten und versprechen Top-Platzierungen innerhalb kürzester Zeit.

Kürzlich hatte ich ein längeres Gespräch mit einem seriösen und deutschlandweit führenden SEO-Anbieter. Möchte man die Dienste des Anbieters in Anspruch nehmen, muss man allerdings auch mit monatlichen Kosten von mindestens 500 Euro rechnen. Was bekommt man dann für das Geld?

Der Anbieter hat ein großes Netzwerk von Web-Hostern und Bloggern aufgebaut, die bereit sind, für Geld wertvolle Links (sog. Backlinks) auf ihre Web-Seite zu platzieren. Die platzierten Links sind zudem Themen-bezogen und daher aus Sicht von Google besonders wertvoll. Diese Art von Backlink-Platzierung ist mit einer gewissen Vorsicht zu genießen, da Google natürlich an einem fairen Wettbewerb interessiert ist und solche Praktiken grundsätzlich nicht mag. Von daher ist besonders vor kommerziellen "Linkfarmen" zu warnen, da diese sehr leicht zu durchschauen sind. Wohldosiert können aber solche Link-Kampagnen beachtliche Erfolge erzielen.

Es gibt allerdings Voraussetzungen, damit eine solche Kampagne überhaupt funktionieren kann, ohne größeres Aufsehen bei Google zu verursachen: Die Web-Seite muss eine gewisse Glaubhaftigkeit besitzen und bereits einige Zeit im Netz vorhanden sein. Eine "gesunde" Verlinkung mit themenrelevanten Seiten sollte existieren.

Und nicht zu vergessen: Die Web-Seite sollte suchmaschinenfreundlich aufgebaut sein, auf Keywords optimiert und für Crawler gut lesbar sein. (Stichwort Flash und Java Script). In diesem Zusammenhang gibt es eine Menge Ansatzpunkte, um schnell beachtliche Erfolge zu erzielen. Viel Geld ausgeben sollte man m. E. nach erst, wenn diese Möglichkeiten voll ausgeschöpft wurden.

REST Client in Java

In der ORDIX News habe ich vor längerer Zeit beschrieben, wie mit Hilfe der Referenz Implementierung Jersey ein REST Service bereitgestellt werden kann.

Nach wie vor gefällt mir der REST-Ansatz sehr gut, da er (im Gegensatz zu Web Services auf Basis von SOAP) schlank und verständlich ist. Mehr und mehr Anbieter, wie z. B. Alfresco, ein Open Source ECM-System, stellen einen Großteil ihrer Funktionalitäten über REST-Services bereit.

Glücklicherweise bietet die Referenzimplementierung Jersey neben der im o.g. Artikel beschriebenen Server API auch eine Client API an, um komfortabel auf REST Services zugreifen zu können. Wie zu erwarten, ist es nicht weiter kompliziert, einen Service zu konsumieren, ein schlanker Dreizeiler reicht aus:

Client client = Client.create();

WebResource webResource = client.resource(http://server/restService);

String response = webResource.get(String.class);

Schon kann die Antwort des Services ("response") verarbeitet werden. Ab und zu ist es notwendig, sich für einen Web Service zu authentifizieren. Nichts einfacher als das, bei Verwendung der HTTP Basic Authentifizierung vor dem Aufruf des Services:

client.addFilter(new HTTPBasicAuthFilter("nutzer", "passwort"));

Warum Software agil entwickelt werden sollte

In meinem Studium habe ich gelernt, dass Software-Entwicklung mit dem Bau eines Hauses vergleichbar sei. Die Anforderungen werden aufgenommen, das Haus wird bis ins Detail spezifiziert und nach den Vorgaben des Architekten gebaut. Komplexe Software ließe sich nach genau dieser Vorgehensweise implementieren.

Einige Unternehmen entwickeln Software genauso. Die vermeintlichen Vorteile liegen auf der Hand:

• Die für das Projekt notwendigen Resourcen und die damit verundenen Kosten lassen sich über Jahre hinweg planen und einteilen.

• Die Entwicklung kann als Paket an günstige Entwickler in anderen Ländern vergeben werden.
• Die Entwickler können die Software planen und anschließend nach Plan entwickeln; größere Refactoring-Maßnahmen sind vermeidbar

Bei diesen Vorteilen fällt eines sofort ins Auge: es sind Vorteile für den Verantwortlichen, der das Projekt bezahlt und für die Entwickler. Alle können sich bequem zurücklehnen und dem Kunden (bzw. der Fachabteilung)  sagen: "Na, genauso wolltet ihr es doch haben, es steht doch so in der Spezifikation. Lasst uns doch bitte in Ruhe weiterentwickeln." Der ITIL-Manager sagt dann: "Wir können gerne auf eure Wünsche eingehen. Aber dazu müsst ihr natürlich erstmal einen Change beantragen und diesen auch bezahlen. Ob der Change-Manager dies genehmigt, ist aber eine ganz andere Frage." Nach langer Zeit bekommt der Kunde dann genau das, was er spezifiziert hat - aber leider oftmals nicht das, was er wirklich braucht.

Dies hat m. E. nach hauptsächlich folgende Ursachen:

• Software ist sehr komplex und lässt sich nur sehr schwer von vornherein bis ins Detail planen
• Anforderungen und gute Ideen entstehen oft erst, wenn mit der Software tatsächlich gearbeitet wird
• Rahmenbedingungen ändern sich mit der Zeit

Die agile Software-Entwicklung hat diesen Sachverhalt erkannt und daraus eine Reihe von Konsequenzen gezogen. Eine wichtige Maßnahme ist die iterative Vorgehensweise. Iterativ meint den Zyklus von Anforderungsanalyse, Spezifikation, Implementierung und Test, der sich ständig wiederholt. Software wird nicht komplett geplant und dann Schicht für Schicht von der Datenbank bis zum UI entwickelt, sondern in einzelne Funktionen aufgeteilt. Diese Funktionen werden dem Anforderer dann nach und nach iterativ zur Verfügung gestellt. Aus dieser verblüffend einfachen Vorgehensweise ergeben sich eine ganze Reihe von Vorteilen:

• Der Anforderer bekommt ein schnelles Feedback und kann entscheiden, ob die Funktion seinen Vorstellungen entspricht
• Die am höchsten priorisierten Funktionen stehen am schnellsten zur Verfügung.
• Es kann ständig (nämlich vor jeder Iteration) auf veränderte Rahmenbedingungen eingegangen werden
• Die Planung wird vereinfacht, da die Komplexität innerhalb einer Iteration reduziert wird

Natürlich gehört zur agilen Software-Entwicklung noch einiges mehr. Um den iterativen und flexiblen Entwicklungsprozess zu optimieren wurden viele wichtige Vorschläge gemacht, wie z. B. die Verwendung von Unit Tests (oder gar die testgetriebene Entwicklung), ständige Refaktorisierungen und der Einsatz eines Vorgehensmodells wie beispielsweise SCRUM, worauf ich an dieser Stelle aber nicht weiter eingehen möchte.

Ich würde mir jedoch für die Zukunft wünschen, dass gerade die Entscheider in den Chef-Etagen der Unternehmen vermehrt die Vorteile der agilen Software-Entwicklung erkennen und nicht auf einer bürokratischen und wenig kundenorientierten, klassischen Software-Entwicklung bestehen.

Java Server Faces und HTTP-Get-Anfragen

JSF ist ein wunderbares Framework zur Erstellung von Rich-Client Anwendungen, die auf Web-Technologieen basieren. Die große Stärke von JSF ist die komponentenbasierte Architektur. Dritthersteller wie JBoss (www.jboss.org/richfaces) und Oracle (Oracle ADF) stellen mächtige Komponenten zur Erstellung von AJAX-unterstützten Web-Anwendungen bereit.

Leider jedoch ist es sehr schwierig, Get-Anfragen mit Hilfe von JSF zu implementieren. In Version 1.2 gibt es überhaut keine Unterstützung dafür. In JSF 2.0 werden endlich zwei Komponenten für Get-Anfragen eingeführt:

<h:link> und <h:button>

Zur Zeit ist JSF 2.0 jedoch oft noch nicht wirklich eine Alternative, da weder die finale Version des JBoss 6 draußen ist noch darauf basierende Bibliotheken wie Rich Faces 4.0 finalisiert wurden.

Aber warum sind denn Get-Anfragen überhaupt notwendig? Nun, die beiden wichtigsten HTTP-Anfragen sind Post und Get. Mit Post werden Daten üblicherweise an den Server gesendet (im HTTP-Body) und mit Get Daten abgerufen. Dass JSF nun ausschließlich über Post mit dem Server kommuniziert, hat hauptsächlich zwei Nachteile:

-Es lassen sich keine Bookmarks auf Post-Anfragen setzen
Dies ist jedoch oft eine wichtige Anforderung an Software. Ein Nutzer möchte sich bestimmte Artikel oder Informationen gerne als Bookmark merken oder einfach als Link verschicken.

-Die Browser Navigation funktioniert nicht wie gewünscht
Betätigt ein Nutzer den Zurück-Button des Browsers oder den Refresh-Button, kommt es zu einer Nachfrage des Browsers, z. B. im Firefox:

Um diese Seite anzuzeigen, müssen die von Firefox gesendeten Daten erneut gesendet werden, wodurch alle zuvor durchgeführten Aktionen wiederholt werden (wie eine Suche oder eine Bestellungsaufgabe)

Dieses Verhalten ist natürlich nach abgeschickten Formularen durchaus gewünscht, wer möchte zum Beispiel den gleichen Artikel mehrmals bestellen, nur weil der den Refresh Button betätigt? Bei einem reinen Abruf von Informationen ist diese Meldung aber eher verwirrend.

Letzerer Punkt lässt sich dadurch beheben, dass in der faces-config.xml ein <redirect> in die Navigation eingetragen wird. Somit wird nach der Post Anfrage über einen Redirect eine Get Anfrage abgeschickt. (mehr zu dem Thema gibts unter dem Schlagwort PRG-Pattern nachzulesen, z. B. hier: http://en.wikipedia.org/wiki/Post/Redirect/Get) Dies funktioniert allerdings auch nur vernünftig bei Managed-Beans, die in der Session liegen, sonst gehen nach dem Redirect die HTTP-Query Parameter verloren.

Ersterer Punkt lässt sich z. B. dadurch umgehen, dass über einen <h:outputLink> ein gewöhnlicher Link mit Get-Parametern aufgebaut wird, der auf eine JSF-View zeigt. (s. auch http://entwickler-forum.de/archive/index.php/t-41706.html) Nachteil an dieser Lösung: Es wird keine Action-Methode einer Managed-Bean aufgerufen. Das bedeutet, dass sämtliche Logik, die für die JSF-View benötigt wird, in die get-Methoden der Managed Bean untergebracht werden muss. Bei Seiten, die ausschließlich Informationen darstellen, ein Kompromiss der m. E. nach ok ist.

Es gibt also durchaus Möglichkeiten, auch mit JSF 1.2 GET-Anfragen zu berücksichtigen. Dennoch freue ich mich schon sehr auf Version 2.0, in der anscheinend honoriert wurde, dass Get-Anfragen einfach ein wichtiger Bestandteil einer Web-Anwendung sein können. Dies wird auch durch den Trend von Rest, s. hierzu auch mein Artikel bei ORDIX (http://www.ordix.de/ORDIXNews/1_2009/IT-Strategie/SOA_restful_web_services.html) untermauert wird.

An dieser Stelle möchte ich noch auf ein interessantes Framework hinweisen: http://ocpsoft.com/prettyfaces/. Wer bereit ist, ein weiteres Framework zur Lösung dieser Problematik einzubeziehen, wird hier fündig. Leider hatte ich so meine Probleme, Pretty Faces im aktuellen Projekt zum Laufen zu bekommen, aber das Feedback anderer Entwickler war durchaus positiv und in einem kleinen Testprojekt funktionierte es einwandfrei.

J2ME und Palm

Im Jahre 2005 habe ich mich intensiv mit der Java Micro Edition und dem Handheld Betriebssystem Palm OS beschäftigt.

Zu diesem Zeitpunkt war Google Android und Apple's Iphone noch kein Thema.

Und damals dachte ich: Java, das ist doch die optimale Sprache für die Handy-Welt. Einmal schreiben und überall läuft die Software. Gerade bei der Vielfalt an Betriebssystmen und Hardware war das eine tolle Sache.

Im Jahre 2005 war Palm noch relativ angesagt. (Ob das jemals wieder so sein wird, bezweifle ich trotz des ganz netten PalmPre und der Übernahme durch HP doch stark) Nichtsdestotrotz brachte die Java Entwicklung auf den Palm Geräten überhaupt keine Freude. Obwohl die Smartphones schon recht starke Prozessorleistung hatten, wurde nur die viel zu restriktive und stark abgespeckte CLDC-Konfiguration mit dem MIDP-Profil unterstützt. (diese Kombination war eigentlich für uralt Handys gedacht)

Trotz vieler Anfragen der Community bei Palm Source, war es anscheinend nicht möglich, das passenderer CDC-Profil, welches fast den Umfang einer Standard Java VM inne hatte, auf den Geräten zu unterstützen. Dennoch dachte ich mir immer, dass Java über kurz oder lang den Siegeszug auf mobilen Endgeräten antreten werde.

Und was geschah dann? Im Jahre 2007 kam das Iphone auf den Markt und revolutionierte die Smartphone-Welt. Die Konkurrenz wurde meilenweit in den Schatten gestellt. Apple brachte mit seinem App-Store und einem SDK die komplette Infrastruktur für Entwickler und Vertriebsmöglichkeiten gleich mit.

Nun ist Apple mit seinen geschlossenen Systemen nun wirklich nicht nach meinem Geschmack. Dennoch habe immer mal wieder überlegt, mal eine kleine App in Objective-C zu schreiben, wie sich doch die Zeiten ändern können.

Für die Zukunft darf man gespannt sein, ob Android weiter an Marktanteilen gewinnt. Denn auf Android wird ja wieder in Java implementiert. Auch wenn dies mit der Java Microedition wohl nur noch wenig zu tun hat.