Devoxx. Tag 3. Keynote und der agile Mythbuster.

Heute ging die devoxx in die nächste Runde: dem Conference-Teil – während die letzten zwei Tage tiefergehenden und längeren Sessions (drei Stunden) mit einzelnen Themen diente (University genannt – lesenswert hierzu auch die Blogposts vom ersten und vom zweiten Tag von Sandro Ruch), war der heutige Tage und sind die nächsten eineinhalb Tage voll gepackt mit einstündigen Vorträgen, Birds of Feather Sessions und vielen Diskussionen vorallem über Java und das Java Enterprise Ökosystem. Sehr oft werden die Vorträge von Spec-Leads und Leaddevelopern bestritten.

Gestartet wurde der heutige Konferenztag mit einer zweistündigen Keynote-Session – aufgeteilt in drei Beträge.

Steven Harris, Senior Vice President of Product Development bei Oracle (dem neuen Eigentümer von Sun und damit auch Java), eröffnete den Reigen mit einem Rückblick auf Java und der Vorstellung ihres neuen OSGi-basierten Application-Servers Weblogic dm – nicht nur der Name erinnerte hier an den von SpringSource vor fast einem Jahr gelaunchten dm Server.
Auch der nächste Talk von Roberto Chinnici brachte für Springentwickler viele bekannte Konzepte in Form der im Dezember endlich finalisierten JEE 6 Spezifikation: neben dem serverseitigen Webprofil (das eine deutlich reduzierte Runtime-Server Umgebung für Webapplikationen definiert) und der DI (dependency injection) Spezifikation wurde hier versucht viel umzusetzen, was sich dank Opensource-Einsatz schon seit Jahren in vielen Projekten bewährt hat („adopt what works“).

Der dritte Keynote-Talk hatte den stärksten Unterhaltungs-Charakter: Adobe hatte Christophe Coenraets aufgeboten, um den Java-Entwickler die neue Flex 10.1 Version (bzw. die gesamte Adobe Suite) schmackhaft zu machen, um so dynamische Frontends (RIA) zu bauen. Herauszuheben gilt es hier, dass die neue Version deutlich Resourcenschonender arbeitet und die Ausführung auf jeglichen mobilen Endgeräten keine Wunschvorstellung mehr ist: von Palm Pre über Rim’s Blackberry bis zum Android wurden Allianzen geschmiedet und teils auch schon laufende Applikationen präsentiert. Fehlt einzig allein Apple mit seinem iphone ;-)

Soweit die Keynote. Dann trat Scott W. Ambler an, der kein Unbekannter ist was Agile Softwarenentwicklung angeht, um aufzuräumen mit Mythen, die sich rund um die agile Entwicklung über die letzten Jahren gebildet haben. Im Stile von Mythbuster, einer amerikanischen TV Sendung des Discovery Channel, ging er (in einem irrsinns Tempo) Behauptung für Behauptung durch und bestätigte („confirmed“) oder widerlegte („busted“) sie mit Studien, die er über die Jahre gesammelte hatte und die jedem über http://www.ambysoft.com/surveys/ frei zugänglich sind.
So zeigte er etwa, dass die agile Entwicklung mittlerweile bei sehr vielen Organisationen Einzug gehalten hat (76%), dass bei diesen jedoch nur 44% aller Projekte agile durchgeführt werden. Für die Behauptung, dass sich agile Entwicklung nur für kleine Teams eignet, musste er keine Studien bemühen: als IBM-Mitarbeiter konnte er von einer Vielzahl von Projekten mit über 200 Entwicklern berichten, die agil aufgestellt sind.
Was wenig überraschend war, war die Aussage, dass auch agile Projekte eine Ramp-Up Phase von mindestens 4 Wochen haben bevor hier mit der Entwicklung gestartet wird. – Eine ganz klare Widerlegung des Mythos, dass durch den Einsatz des Agilen Vorgehens sofort mit dem Coding begonnen werden kann.
Dagegen sicher bejahen kann er die Behauptung, dass in agilen Projekten mehr getestet wird. Hier wird vorallem auch schon früher mit dem Testing begonnen im Vergleich zu traditionellen Ansätzen.

Keine Auseinandersetzung, bei der nicht beiden Seiten behaupten die bessere Lösung bzw. das bessere Konzept zu haben – so auch hier: die agile Fraktion behauptet von sich, dass Projekte, die ihrem Ansatz folgen (entgegen dem traditionellen Ansatz), erfolgreicher abgeschlossen werden. Wobei mit Erfolg vorallem die Software-Qualität, Kundenzufriedenheit mit der gelieferten Funktionalität, Budgeteinhaltung und Intime-Lieferung verbunden werden. Dies ist laut Ambler eine Marketingaussage der agilen Fraktion. Denn es gibt hierzu kaum Zahlen, die dies beweisen könnten. Interessant ist jedoch, dass Studien zu einzelnen Aspekten zeigen, dass der agile Ansatz fast gleich auf ist mit dem iterativen Ansatz.

Seine Konklusion kann ich nur unterschreiben: am Ende muss jeder schauen, was für ihn funktioniert. Jede Organisation ist anders. Die strikte Anwendung von agilen Methoden, welche religiöse Ausmasse annehmen kann, garantiert noch keinen Projekterfolg.

Nationale Suisse schafft mit SharePoint soziale und Mehr-Werte [Vortrag]

Ich bin Gast am „Swiss Intranet SUMMIT“ und verfloge einen Vortrag von Jürgen Kübler von National Suisse zu deren neuem Intranet. Disclaimer: Namics war der Dienstleister für Konzeption, Erstellung und Einführung. Und hier meine Mitschrift:

Das alte Intranet von National Suisse war auf Basis von Microsoft FrontPage gepflegt. Ein Zehntel der Firma waren n dem Modell (ausgebildete) Content-Master, die in der Summe über 12’000 Seiten erstellt und noch mehr PDF-Dokumente hochgeladen hatten. Einer der Kritikpunkte der alten Lösung war beispielsweise die Suche, worauf die Analyse ergab, dass die Schwäche auf veralteten Inhalten fusste. Alte Seiten und Dateien wurden in diesem Prozess kaum je gelöscht.

Das alte Intranet besass keine Zusammenarbeitsfunktionen ausser einem Flohmarkt und widerspiegelte im Kern die veraltete Organisation von 1999. Der Intranet-Frust war so ausgeprägt, dass es anstelle eines sozialen Werkzeuges eher ein asoziales Werkzeug war, dem gezielt mit E-Mail ausgewichen wurde.

Mit Blick auf die letzte Versionsnummer von FrontPage und der ersten Versionsnummer von SharePoint ist die neue, auf SharePoint basierte Intranet-Lösung sozusagen eine nahtlose Produktnachfolge ;-)

Ausschlaggebender Punkt für den Entscheid zu Gunsten von SharePoint war die gute Zusammenarbeit mit den Microsoft Office Produkten verbunden mit einer starken Ausrichtung an Microsoft-Produkten bei National Suisse.

In jedem Schritt im Projekt wurden Mitarbeiter einbezogen und damit auch schrittweise Akzeptanz geschaffen. So gab es rund 40 Einzelinterviews, Card Sorting mit 60 Leuten, eine öffentliche Abstimmung über den präferierten Design-Vorschlag, eine firmenweite Umfrage u.s.w.

Sehr viel Zeit wurde in die Erstellung der Informationsarchitektur investiert, wobei zusätzlich zu Personen mit Domänenwissen auch ein Psychologe beteiligt war, was sich als sehr wertvoll erwiesen hat.

Zudem stand beim neuen Intranet eine Enterprise Suche im Zentrum, die zahlreiche Quellen inklusive einem Personalverzeichnis, externer Quellen, Dateiserver etc. durchsucht. Zusätzlich prozessunterstützende Anwendungen wie beispielsweise der primäre Kommunikationskanal des zentralen Helpdesks.

Neu sind zahlreiche soziale Funktionen, wobei die Funktionen um das Mitarbeiterprofil von der Geschäftsleitung sehr aufmerksam („kritisch“) verfolgt wird, da im Rahmen der Einführung der Vergleich zu Facebook aufgetreten ist. Einige Funktionen des persönlichen Mitarbeiter-Bereichs (MySite) wurden für die erste Version daher zurückgestellt. Aus Gründen der Komplexität aus Sicht der User werden Wiki- und Blog-Funtktionalitäten nur sehr sparsam eingesetzt. Dies, da es nicht verständlich war, für Inhalte welches Gefäss genutzt werden sollte.

Ein gewichtiges Thema war die Migration bestehender Inhalte. Ziel war es die bestehenden 12’000 Seiten mitzunehmen. Nach einer Prüfung aller Seiten durch Mitarbeiter umfasste die Liste noch 6’000 Seiten und die Kritik an der bestehenden Suchfunktion verstummten plötzlich. Beim Start der Migration umfasste die manuelle Migration von 4’000 Seiten in zwei Sprachen durch 8 Personen während 7 Wochen. Wichtig war die dauernde Motivation der und das dauernde Feedback an diese Leute. Ein schwieriger Job!

Sehr wichtig war es möglichst viele und unterschiedliche Mitarbeiter zu einzubeziehen. Noch wichtiger als die Unterstützung der Geschäftsleitung im Boot zu haben, war das mittlere Management. Dies, damit die direkten Vorgesetzten der Content-Master Unterstützung boten.

Kommunikation inkl. Projektmarketing war sehr wichtig und wurde sehr aktiv betrieben, beispielsweise mit bis zu sechs Posts pro Monat auf einem Projekt-Blog. Dabei wurden die Meinungsmacher bewusst identifiziert und einbezogen. Im Extremfall galt es auch Personen, die gegen das Projekt schossen zu „behandeln“. Diese aktive Unterstützung erweiterte sich insb. auch auf die sorgfältige Schulung und Unterstützung von Schlüsselnutzer.

Danke Herr Kübler für die spannenden Einsichten und hier der Download: Nationale Suisse schafft mit SharePoint soziale und Mehr-Werte [pdf, 2,6MB]

Devoxx. Tag 2. Intelligence mit Facetten finden.

Der zweite Tag stand unter dem Motto „Facettensuche und Business Intelligence“.

Ein besonders gelungener Vortrag von Erik Hatcher von Lucid Imagination berichtet über Solr, sozusagen eine verbesserte Lucene-Suchengine. Warum verbessert? Nun, Solr basiert im Grunde genommen auf Lucene und erweitert diese in wesentlichen und in meinen Augen wichtigen Bereichen. Die wichtigsten sind hier aufgeführt:
– bietet ein HTTP-basiertes API für die Indexpflege
– eingebautet Caching- und Clustering-Funktionalitäten
– Master-Slave Replikation in sehr grossen Systemen (Americal Online repliziert weltweit solche Indexe und die sind nicht klein…)
– Facettensuche
– Verteilte Suche (für sehr grossen Implementationen)

Das Bauen einer guten Suchapplikation ist nach wie vor eine grosse Herausforderung. Obwohl viele Endanwender immer wieder „Es muss wie Google funktionieren“ sagen, ist es im Detail dann doch etwas komplexer und komplizierter. Erik propagiert in seinem Vortrag folgende Herangehensweise:

1. Gehe immer vom Benutzerfrontend aus

Was heisst das? Nun, zuerst muss klar sein, wie der Benutzer überhaupt die Suche bedienen soll/kann. Welche Möglichkeiten stehen ihm zur Verfügung? Dies hat schon mal einen grossen Einfluss auf die Grundkonfiguration eines Solr-Systems.

2. Anforderungen an den Index sammeln

Was soll denn indexiert werden? Binäre Dokumente wie PDF, Word, etc. Soll die Such case-sensitiv sein oder nicht? Müssen unterschiedliche Sprachen unterstützt werden (Stemming)? Wie oft ändern sich diese Daten?

3. Anforderungen an die Suche sammeln

Hier kommt einiges auch aus dem ersten Punkt dazu. Soll der Benutzer sich eher browsend (via Facetten) oder mit einer strukturierten Suche im System bewegen? Oder beides? Welche Anforderung bestehen bezüglich Sortierung und Filterung? Müssen gewisse Relevanzen (z.B. ältere vs. neuere Dokumente) berücksichtigt werden?

Diese Punkte haben einen enormen Einfluss auf das zu bauende System und sollten möglichst früh adressiert werden im Projekt.

Solr, aktuell in der Version 1.4, kann praktisch an allen Stellen erweitert werden. Das macht das System aus meiner Sicht sehr interessant und wird daher vermutlich längerfristig reine Lucene Implementierungen verdrängen.

Der zweite Vortrag handelt von Java Business Intelligence und dem OpenSource Tool Pentaho.
Matt Casters führt durch Pentaho, mit dem speziellen Fokus auf Pentaho’s Data Integration Komponente Kettle (ein von im initiiertes Open Source Project). Pentaho ist eine Open Source Business Intelligence Implementierung und besteht aus mehrere eigenständige Komponenten:
– Reporting,
– Analysis,
– Dashboards
– Data Integration
– Data Mining

Die Reportingkomponente (ehemals JFreeReport) dient der Erstellung von interaktiven und ad-hoc Reports in verschiedene Ziel-Formate (PDF, HTML, DOC, XSL). Ein Eclipse-basierender Report Designer vereinfacht die Erstellung von Reports. Die Analysis Komponent (mondrian) bietet OLAP (Relational OLAP) Funktionalität. Dashboards bietet eine Plattform für die Erstellung von Dashboards (auch Cockpits genannt), es lasen sich einfach interaktive Dashboards mit integriertem Monitoring of KPI’s erstellen. Sehr interessant ist die Data Integration Komponente Kettle, sie ist eine vollumfängliche ETL-Lösung (Extract Transform). Sie integriert und säubert Data von verschiedenen Quellen und Formate (35+ Datenbank Typen, Flat Files, XML, etc.), die dann in den anderen Tools zur Verfügung stehen. Die ETL Prozesse lassen sich mit Kettl Spoon graphisch erstellen und bearbeiten. Das Data Mining helft Muster in Daten zu erkennen, welche wiederum als Muster bei Kundensegmentierung verwendet werden kann. Alle Komponenten sind Open Source (Reporting und Data Integration LGPL) und lassen sich auch integriert in eigene Lösungen einsetzen.

Ach du schöne Open Source Welt…

Devoxx. Tag 1. Cloudcomputing.

Wie bereits im meinem früheren Post angekündigt, sind verschiedene Vertreter von Namics in Antwerpen an der devoxx. Dabei versuchen wir, die Schwerpunkte des jeweiligen Tages etwas zusammenzufassen und dies in einen Blogeintrag zu giessen. Der erste Tag stand – wie der Titel vielleicht verraten mag – unter dem Themenschwerpunkt Cloudcomputing.

Im ersten Vortrag von John M. Willis wurde das Thema aus historischer Sicht (wobei hier die Historie zum Glück nicht so lang ist) etwas aufgearbeitet. John hat die Geschichte von Gridcomputing zum Cloudcomputing sehr schön zusammengefasst, wobei hier noch angfügt werden muss, dass John ursprünglich aus dem IT Operation kommt. Aus seiner Sicht wurde bereits seit einger Zeit das Agile Manifesto auf die Entwicklung von Software angewandt, jedoch die IT Operation davon komplett aussen vor gelassen wurde. Agil entwicklen ja… aber agil betreiben… lieber nicht oder noch nicht. Agile Operation existiert in den Firmen eigentlich noch gar nicht. Ein witziges Beispiel hier war die eines Pharmakonzerns, in dem die Forschungsabteilung kurzfristig massive Rechenpower benötigt hätte, dessen Beschaffung intern jedoch 8 Wochen gedauert hätte. Was haben die Forscher gemacht? Sie haben sich die Rechenpower einfach bei Amazon EC2 mit ihrer persönlichen Kreditkarte innerhalb von 8 Minuten beschafft. Und dass der Markt dies fordert und wünscht, zeigen die Zahlen von Amazon auf eindrückliche Art und Weise (bis zu 200’000 neue Instanzen werden pro Tag eingerichtet und gestartet), alles vollautomatisch und via Webservices gesteuert. Agile Operation – dass soll jetzt Cloudcomputing richten. Wo nur bleibt dann da das Agile Budgeting?

Im zweiten Vortrag erklärte Chris Richardson, wie robuste Applikationen für die Amazon EC2 gebaut werden können. Er führte anhand eines Beispiels Applikation durch die unterschiedlichen Services der EC2. Elastic IP Addresses in Kombination mit Elastic Loadbalancer und Autoscaling und die verschiedene Zonen führen zu einem hochverfügbarem System (99.95%). Die S3 Datastore, die Simple Query Service (SQS) bietet mit dem Cloudfront eine effiziente globale Content Delivery Infrastruktur. Amazon implementiert die volle Pallette einer sogenannten Infrastructure as a Service (IaaS). Der nächste Layer wäre eine Platform as a Service (PaaS). Diese wird von cloudfoundry.com als Layer auf einer EC2 geboten. Es lassen sich Spring und Grails Applikationen direkt in der Amazon Cloud deployen. Aktuell wird dieser Layer auch auf die hauseigene vCloud portiert. Auch wenn es noch einige Einschränkungen in der Entwicklung von Cloud Applikationen gibt, sieht das ganze sehr erfolgversprechend aus. Die Preismodelle von EC2 sind jedoch genau so durchsichtig (oder eben nicht) wie die bei einem Mobiltelefon, was das Durchrechnen eines konkreten Business-Cases erschwert.

Es bleibt also spannend… über oder besser gesagt in den Wolken… :-)

Alles Gute zum Namicstag – oder – Führen durch Freiraum

Gestern sollen es 3650 Tage sein, an denen sich Jürg Stuker Namics verschrieben hat. 3650 x schätzungsweise je 12 Stunden, minus Wochenenden, wo er nur 50% seiner Leidenschaft den weiteren 279 Namicslern, Kunden und dem Internet widmet. Die Ferien müsste ich abziehen, aber Jürg scheint eh einen geheimen Time-Management-Plan zu haben, wodurch er über mehr Zeit verfügt, als der Rest der Welt.

Das ist aber nur eine seiner besonderen Begabungen, denen ich hier etwas auf die Spur kommen möchte. Die Herausragendste all jener ist wohl sein Führungsstil, den ich mal „Führen durch Freiraum“ betitelte. Ich bin nicht sicher, ob Jürg das Wort Führen im Wortschatz hat, jedenfalls tut er dies seit 5 Jahren als CEO indem er jedem Menschen seinen individuellen Raum gibt, auf gleicher Augenhöhe agiert. Er ist tolerant, offen für Ideen und unglaublich flexibel.

781-juerg_stuker-thumb-500x375-780.jpg

Ich bilde mir ein, für alle meine Kollegen zu sprechen und recherchiere ein wenig. Statt Beweisen finde ich viele weitere 10er Jubiläliare. Solches Durchhaltevermögen ist nicht etwa selbstverständlich in unserer Branche sondern ein Ergebnis des Wir-Gedankens, den ich besonders oft von Jürg höre und der ihn sekündlich repräsentiert. Solche „Senioren“ sind wie kleine Anker, die man gerne um Rat fragt und die sich nicht zu schade sind, die Spülmaschine auszuräumen und eben ein Stück Namics-Kultur mit prägen.

Ich erfuhr, dass Markus Wirrer, Marcel Albertin, Adrian Scherrer, Thomas Link, Thomas König, Bernd Langkau, Sandro Ruch, Markus Koller, Ernst Ammann, Dietmar Käppeli und Mischa Mundwiler auch längst 3650 Namics-Tage zählen und keiner von ihnen trägt dies zu Schau. Das ist eine Bescheidenheit, die man nur in einer wirklichen Team-Kultur findet. Klar ist das nicht diese eine Person, doch für mich ist Jürg nun mal ein Mentor, der nicht nur Internet-Wissen teilt.

Geht es um DIE Namics sind es immer die 280 Leute und nie er selbst. Jürg ist der aufrichtigste CEO den ich kenne und motiviert mehr als Vorbild als als Chef. Ein Vorreiter der sich dennoch immer hintenan stellt und der sucht, seine Ideen durch Andere zu ergänzen oder gar zu verwerfen.

Herzlichen Dank dafür.

World Usability Day Wiesbaden

Zwischen den Bäumen der nördlichen Hänge des Nerobergs liegen die etwas zusammengewürfelten Bauten der Hochschule RheinMain – „University of Applied Sciences“. Dort wurde am 12. 11. zum World Usability Day geladen, ausgerichtet von der German UPA.
Zwischen 15.30 und 19.00 Uhr gab es nach der Begrüßung durch Professor Thomas Steffen und Jürgen Mirbach von der ICOM vier Vorträge und reichlich Diskussion zwischen den Vortragenden, den Ausrichtenden und den etwa 50 Zuhörern (jeweils zur Hälfte Hochschulinterne und -externe, wie ein kurzes Handaufheben zu Beginn ergab).

Inwieweit der Gedanke der Usability die heutige Ausbildung der Wiesbadener (bzw. RheinMainer) Studenten prägt, hatte schon Prof. Steffen in seiner Einführung dargelegt: Martin van Wickeren, Student der Hochschule, stellte das in einer Präsentation am Beispiel des Redesigns des Interface einer Agentursoftware (QuoJob) vor. Kurze Ausschnitte aus den gefilmten internen Testings leiteten über zu einer kurzen, aber lebhaften Diskussion des Ergebnisses – Begeisterung für Usability und Lust an der stetigen Verbesserung lag in der Luft.

Wegen der krankheitsbedingten Absage von Frau Dr. Armbruster (Syzygy) sprang als nächstes Uwe Todoroff, Senior Conceptioner bei Scholz & Volkmer, ein: er stellte übersichtlich die verschiedenen Techniken vor, die in der Kreativagentur im täglichen Leben Anwendung finden. Auch nach diesem Vortrag wurde kurz diskutiert, vornehmlich über die „verschärften“ Formen der Testdurchführung hinter Einwegspiegeln (Download des Vortrags).

Nach der Pause kam meine Präsentation der Herangehensweise bei der Entwicklung von bahn.de im letzten Jahr, und zu Beginn fiel ich in einen richtig parademäßigen Blackout. Dann rappelte ich mich wieder auf und brachte den Anwesenden etwas vom „Spirit“ der Bahn-Entwicklung näher: Tests, Tests, Tests vom Beginn (im Pitch) bis zur Finalisierung. Vor allem die Freuden des Konzept-Testens mit Axure fanden interessierte Zuhörer, aber auch Accessibility-Standards im Rahmen der Entwicklung von bahn.de wurden diskutiert (Download des Vortrags: Vorgehen bei der Neuentwicklung von bahn.de) .

Den Abschluss der Vortragsreihe machte Chris Bleuel der Agentur Fuenfwerken mit dem ausgesprochen anspruchsvollen, ausgesprochen nach Science Fiction anmutenden Projekt des „Intelligent Pipelining“; mobile Endgeräte dienen in der Vision als Steuergeräte und Monitore des anschließenden Verkehrsmittels und der sich demnächst ergebenden Situation in der Fortbewegung. Eine anspruchsvolle und kühne Idee vernetzter Informationssysteme, die viel Zeit und Stress sparen kann, wenn sie mal realisiert wird.

Die anschließende Lounge (mit Brezeln und Bionade) diente dann dem zwanglosen „Socialising“. Zwar wurde an diesem Tag nicht die Weltrevolution der Usability heraufbeschworen und verabredet, aber es war sehr ermutigend zu sehen, wieviel Usability heute ausmacht – welche Präsenz sie im Bewusstsein der Gestalter hat – und welche Dimensionen sich durch die Anwendung und Verfeinerung ihrer Prinzipien eröffnen.

Integrität (Integrity)

Integrität (Integrity) ist einer von 11 ethischen Grundsätzen von Namics. Ein seit 2000 existierende essenzielle und unumstössliche Norm für unser Arbeiten und Handeln.

Die Ausformulierung davon lautet:

Wir verpflichten uns höchsten Standards persönlicher und professioneller Integrität und Vertrauenswürdigkeit. Insbesondere erlangen wir kein Wissen oder anderen Vorteil durch Vorspielen falscher Tatsachen. Setzen wir in einem Kundenprojekt externe Unterstützung ein, so machen wir diesen Umstand unseren Kunden transparent.

Meine spontanen Gedanken: Den Punkt könnte man auch mit „Ehrlichkeit“ überschreiben resp. mit einem Umgang / einem Verhalten, wie wir es hoffentlich alle im privaten Leben pflegen. Die zwei Punkte bezüglich „Unterstützung“ und „Vorspielen“ sind exemplarisch für unser Geschäft, aber selbstverständich nicht abschliessend. Eigentlich „ganz normal“ ein integeres Verhalten, in unseren Grundsätzen aber explizit verbrieft.

Continuous Integration – aber nicht in SharePoint-Projekten… oder?

Aktuell bin ich auf dem Weg nach Antwerpen, wo jedes Jahr eine der wichtigsten Konferenzen im Java-Umfeld stattfindet. Die devoxx (f.k.a javapolis). Da die Wartezeiten auf so einer Reise nicht unerheblich sind, wollte ich diese Nutzen, um von einem weiteren Meilenstein bei Namics zu berichten.

Anlass dazu hat mir der Post von Markus bezüglich Maven gegeben. Wie Markus auch berichtet hat, ist Maven bei Namics nicht mehr aus den Projekten wegzudenken. Zu wichtig ist ein gut strukturierter Buildprozess in einem grösseren Projekt. Die Unabhängigkeit von einer Entwicklermaschine oder von einer Entwicklungsumgebung wie Eclipse ist unerlässlich.

Das ist jedoch nur ein Aspekt im gesamten Entwicklungszyklus. Ein anderer, ebenso wichtiger Aspekt ist die Buildfähigkeit eines Projektes über die Zeit. Wie kann die Dynamik in einer grossen Source-Code-Basis über Monate oder gar Jahre überwacht werden? Das Zauberwort hier heisst Continous Integration. Mit diesem Begriff wird eine Infrastruktur assoziiert, welche es erlaubt, ereignissgesteuert (z.B. zeitlich oder manuell) die gesamte Codebasis eines Projektes aus dem Sourcecodeverwaltungssystem auszuchecken und anschliessend zu bauen. Am Ende sollte hinten ein installationsfähiges Stück Software herausfallen.

Als Atlassian Partner setzten wir bei uns intern auf Bamboo, welcher genau diese Funktion ausübt. Bislang haben wir diese Infrastruktur allerdings ausschliesslich für Java-Projekte eingesetzt. Das wird sich jetzt jedoch künftig ändern, da seit der aktuellen Version von Bamboo auch eine Möglichkeit besteht, SharePoint-Projekte mittels MSBuild zu bauen und so über die Zeit zu überwachen. Jeder der schon mal grössere SharePoint-Projekte implementiert hat, weiss jedoch, dass sich hier viele Fallestricke und Tücken verstecken. Mit diesen setzen wir uns aktuell auseinander. Ziel ist es, künftig auch grosse SharePoint-Projekte mit dieser Infrastratur automatisiert zu bauen. Bei einem ersten Musterprojekt ist es uns auch bereits gelungen. Aber eben… wie gesagt, vielleicht haben wir auch noch nicht alle Falltüren geöffnet… :-) Aber es ist ein weiterer wichtiger Schritt aus Sicht der Qualitätssicherung…

So… bald geht der Flieger in Richtung Amsterdam… hoffe, ich habe keine Verspätung… sonst erwische ich den Zug nach Antwerpen dann nicht mehr… :-)

Maven von den Ketten befreit.

Auch dieses Jahr hat die W-JAX wieder in München stattgefunden. Am 12.11 habe ich einen Vortrag zu Maven gehalten. Der Titel: Maven von den Ketten befreit.
In großen Softwareentwicklungsprozessen ist Automatisierung ein wichtiges Element um reproduzierbare Ergebnisse zu erhalten. Besonders die Unabhängigkeit von der Entwicklungsumgebung ist für mich ein wichtiges Merkmal für professionelle Softwareentwicklung. Ein großes Riskio für den Erfolg eines Softwareprojektes ist, wenn ein Projekt nur aus der Entwicklungsumgebung heraus erzeugt werden kann. Da Systeme abstürzen, Festplatten kaputt gehen können braucht es hier die Reproduzierbarkeit. Unabhängig von Personen. Aus diesem Grund ist ein automatisierter Buildprozess unerlässlich.
Bei Namics ist Maven ein gesetztes Werkzeug. In dem Vortrag habe ich aus unserem Erfahrungsschatz berichtet.

Bei Maven wird der Entwickler mit drei Begriffen konfrontiert:

  • Goal: Kleinste Ausführungseinheit von Maven (vergleichbar mit Task von ANT); Beispiel: mvn compile:compile
  • Phase (Lebenszyklusphase): mehrere Goals; Beispiel: mvn package
  • Lebenszyklus (Lifecycle): Geordnete Folge von Phase; Beispiel: clean (pre-clean, clean, post-clean)

Wer noch auf Maven 2.0.x hantiert sollte zumindest den Wechsel zu Maven 2.1.x in Betracht ziehen. Neben der zusätzlichen Phase pre-package ist hervorzuheben das die Abhängigkeiten nun in Threads (Standardeinstellung:5) heruntergeladen werden.

Anhand eines Beispiels habe ich einen möglichen Migrationspfad von ANT zu Maven aufgeführt. Folgende Schritte sind in der Präsentation aufgeführt:

  • Schritt 1: Build Analyse
  • Schritt 2: Verzeichnisstruktur anpassen
  • Schritt 3: Dependency Management
  • Schritt 4: Migration kleinstes Modul
  • Schritt 5: Migration aller Moduln
  • Schritt 6: Mavenize
  • Schritt 7: CI

Der Umstieg von ANT zu Maven zieht eines an Änderungen nach. Dies liegt daran das Maven ein System mit dem Grundsatz Convention-over-Configuration ist. Wenn Sie den Konventionen folgen müssen Sie wenig anpassen. Sollte doch eine Anpassung erforderlich sein können eigene Plugins geschrieben werden. Auch der Lebenszyklus kann in der lifecycle.xml angepasst werden. Zusätzlich habe ich als Erweiterung zu Maven das Plugin Sonar gezeigt.

769-sonar_maven-thumb-500x297-768.png

Damit besteht die Möglichkeit die QS-Daten eines Projektes in einer ansprechenden GUI zu visualisieren. Hier lohnt sich der Einsatz wirklich.

Den Abschluss bildete ein kurzer Blick auf das kommende Maven 3. Mit Maven 3 wird die pom.xml auch für die polyglotte Welt der JVM geöffnet. Es wird z.B. möglich das POM mit Groovy zu schreiben. Es bleibt spannend.

Maven von den Ketten befreit [pdf, 610KB]

Bei Fragen zu Maven, Buildprozessen oder anderen Themen rund zum Softwareentwicklungsprozess sprechen Sie uns an.

User Centered Design – What’s in?

Ein klassisches Projektvorgehen ist in die Phasen Analyse, Konzeption, Umsetzung und Optimierung gegliedert. Entlang dieser Phasen sind aus unserer Sicht die zusätzlichen Elemente Performance (messbarer Erfolg), Innovation und User Centered Design für einen nachhaltigen Projekterfolg massgeblich verantwortlich.

763-Usability_UCD-thumb-500x389-762.jpg

User Centered Design ist eine Methodik, welche verschiedene Instrumente beinhaltet, die allesamt die Benutzerbedürfnisse in den Mittelpunkt stellen. Dadurch werden User Interfaces nachweislich erfolgreicher.
Damit dies funktioniert, ist es über alle Projektphasen hinweg wichtig, die Benutzer miteinzubeziehen. User Centered Design besteht also nicht nur aus einem punktuellen Usability Test, sondern aus einer Palette verschiedener Instrumente während des gesamten Projektablaufs.
Im Folgenden werde ich einige ausgewählte Instrumente kurz vorstellen und in den typischen Projektverlauf einordnen (vgl. Punkte 1-7 in der Grafik oben).
Vorab lässt sich grundsätzlich festhalten, dass es im Rahmen der Methode User Centered Design auch Instrumente gibt, die keinen direkten Einbezug der Nutzer vorsehen wie zum Beispiel Expert Reviews. Diese werden im Folgenden nicht näher behandelt.



Analysephase

  • (1) Durchführung von Nutzerbefragungen (Interviews, Fragebogen, etc.) als Basis für die Entwicklung eines mentalen Modells, Personas und User Stories (Bedürfnisse) zur Ableitung der konkreten Testfälle und -aufgaben für die Usability Tests.
  • (2) Usability Tests am Status quo. Hierfür dient das aktuelle, d.h. noch nicht überarbeitete User Interface (beispielsweise eine Web-Applikation oder eine ganze Website) als Ausgangslage und kann als Prototyp eingesetzt werden (falls vorhanden).

Phasenziele:

  • Benutzerzielgruppen und deren Bedürfnisse identifizieren
  • Benutzerhandlungen verstehen und abbilden
  • Ausgangslage mit ihren Stärken und Schwächen (Potentiale) greifbarer machen
  • Schaffung einer Grundlage zur Zielformulierung (Beispiel „Das Kernprodukt soll künftig mit 1 Klick erreicht werden…“)

Konzeptionsphase

  • (3) Entwicklung eines geeigneten Prototypen (klickbar oder papier-basierend).
  • (4) Durchführung des Usability Tests (Nutzerbeobachtung), welcher sowohl bei uns intern als auch in einem spezialisierten Labor bei Usability Partnerfirmen stattfinden kann (je nach Grad der Anforderungen an die Tests). Die daraus gewonnenen Erkenntnisse und Beobachtungen werden nachfolgend ausgewertet und priorisiert. Dadurch wird gemeinsam bestimmt, welche Punkte mit einer konzeptionellen Iterationsschlaufe für die nachfolgende Umsetzungsphase berücksichtigt oder für die Optimierungsphase ettappiert werden.

Phasenziele:

  • Früh-Identifizierung von Schwierigkeiten/Fehlern
  • Abbildung sämtlicher Testfälle/-aufgaben
  • Konzeptüberprüfung durch die Zielgruppenbenutzer
  • Konzeptverifizierung/-bestätigung, woraus eine gute Projektstandortbestimmung ableitbar wird
  • Potentialerkennung für nachfolgenden Phasen

Umsetzungsphase

  • (5) Fortwährendes Usability Controlling (d.h. Zielüberprüfung und Korrekturen) der gestalterischen und technischen Umsetzung anhand der priorisierten Ziele aus der Konzeptionsphase.

Phasenziele:

  • Qualitätssicherung
  • Umsetzung & Entwicklung entlang der Projektziele

Optimierungsphase

  • (6) Usability Tests (Kontrolltests) zur Messung des Zielerreichungsgrades gegenüber den Status quo-Usability Tests aus der Analysephase. Wenn diese mit denselben Testfällen nicht besser ausfallen als die Status quo-Usability Tests, hat man wahrscheinlich etwas falsch gemacht ;-)
  • (7) Finetuning, beispielsweise mit A/B-Tests oder multivariaten Tests.

Phasenziele:

  • Überprüfung der Projektzielerreichung
  • Ableiten von Argumentarien für weitere oder künftige Investitionen
  • Laufende Optimierungen – „Stillstand ist Rückschritt“
  • Umsetzung etappierter Module und Massnahmen

Dies sind die wichtigsten Instrumente, welche mit der Methode User Centered Design während eines Projektes und in dessen Betrieb eingesetzt werden können.
Bleibt nur noch zu sagen: «Erfolgreich ist, was vom Benutzer intuitiv bedient werden kann!»



Verwandte Themen: