Ich habe mich für die Session "Spring: Vom Framework zum Ökosystem entschieden". Damit hat Eberhard Wolff gewonnen vor Rod Johnson mit seiner Q&A-Session zur Keynote und ein paar anderen interessanten Sessions. Hoffentlich wird's so interessant wie ich mir das gerade erhoffe. Natürlich stellt sich gerade in dieser Session die Frage, ob Spring mit allem nicht mittlerweile zu groß wird und damit in die Falle tappt, in der Java EE jetzt schon steckt.
Wow, erst mal schmeißt Wolff viiiiele Blasen an die Wand: Die ganzen Spring-Teilprojekte. Eine der Blasen ist Spring Batch. Spring Batch ist die Unterstützung von Batch-Jobs für Java, und dass Batch Jobs in vielen Projekten wichtig sind. Typische Probleme von Batches (ich denke mal, die Unterstützung dafür kommt gleich) sind Wiederaufsetzen nach einem Fehler, Parallelisierung und die Optimierung von Datenbank-Operationen.
[...] (Anmerkung: Hier redet Eberhard Wolff ziemlich detailliert über Spring Batch) Und weiter, und mehr, und noch mehr Batch Details. Ja, ich weiß was ein Batch ist und wie man so was bauen würde. Die Details von Spring Batch kann ich mir anschauen, jetzt wo ich weiß, dass es das gibt. Ich fange gerade an, in meinen Unterlagen zu blättern und nach Alternativen zu suchen. Das ist nicht der Vortrag des Titels, sondern irgendwas anderes. Das ganze geht mir persönlich viel zu tief in Spring Batches, ein deutlich flacherer Überblick hätte mir hier definitiv gereicht. Mehr, unterschiedlicher. Was gibt es noch an Blasen.
Endlich geht's weiter zum nächsten Bubble: Spring Integration. Das löst typische EAI-Probleme, also Messages, Routing, Splitting, Transformation etc. Das Framework basiert auf einem Pipes & Filters Pattern und ist Event-driven. Das heißt, dass sich das Framework um das Message-Listening kümmert und dann die Service-Aufrufe regelt. Beispielsweise übernimmt das Spring Integration Framework das Thread-handling. Super, das ist jetzt mal auf dem korrekten Niveau. Jetzt nur nicht zu sehr abgleiten ins Detail. Wir gehen jetzt mal in den Code, es könnte schon zu detailliert werden. Jaaa, es wird zu detailliert. Gut, es interessiert mich auch, ich raschle nicht, aber es ist eigentlich zu detailliert. Ich tackere das jetzt nicht mit, sondern verweise einfach mal auf die entsprechenden Slides. Ich hoffe mal, dass ich die CD-ROM mit den Slides nachträglich bekomme. Kommt das Ding per Post oder muss man es holen? Worauf ich hier noch hinweisen möchte: Spring Integration hat eine klassische Java-API, man kann aber auch sehr gut und einfach mit Annotations arbeiten.
Spring Web Services ist das nächste Bubble, das Eberhard Wolff vorstellt. Interoperabilität ist das Ziel von Web Services und Contract First ist das Mittel zum Zweck. Wenn man schon mal WebServices hat, dann kann man mehr machen als nur request-response und man möchte ggf. auch direkt auf das XML durchgreifen können.
ContractFirst ist gesetzt, wie soll man sonst Interoperabilität gewährleisten. Eine WSDL von Hand schreiben macht keinen Spaß. Umgekehrt ist der Weg der Generierung der WSDL aus Java auch suboptimal - es ist contract last, die Java Klassen entsprechen nicht den WSDL/XSD-Möglichkeiten, man bindet sich ggf. an die einzelnen WebService-Stacks. Selbst schon erlebt - WebServices sind per se erst mal nicht wirklich interoperabel zwischen verschiedenen Stacks und Sprachen. Jetzt kommen wir wieder zu dem Punkt, dass die WSDL eigentlich nicht en bloc von Hand geschrieben werden sollte, sondern aus verschiedenen Artefakten zusammengeneriert werden sollte.
Spring verwendet ein XML Schema zur Definition der Datenbeschreibung und der Methoden. Die Komplexität des SOAP Stacks (Endpoints, Ports und so weiter und so fort) kann man dann an anderer Stelle machen.
Für das Mapping von Objekten auf XML und umgekehrt kann man die vorhandenen Techniken nehmen - JAXB 1 und 2, Castor, XMLBeans, JiBX, XStream oder was auch immer. Oder man mappt nicht, sondern geht direkt auf die XML-Struktur runter, beispielsweise mit JDOM oder SAX. Die dritte Alternative geht über Annotationen und XPath. Das sieht interessant aus.
In 1.5 ("was wir jetzt gerade shippen") gibt es neu auch JMS und Email Transport.
Weitere Bubbles werden noch nicht mal kurz vorgestellt, da es z.T. noch eigene Talks dafür gibt.
Spring Enterprise bundled verschiedene Dinge zusammen: Zum Beispiel das Advanced Pack for Oracle, die bestimmte Misfeatures des Oracle RAC "ausbügelt". Es gehört auch die SpringSource Tool Suite dazu und die SpringSource Application Management Suite.
Ok, wir haben gesehen, dass Spring mittlerweile auch ein ganzer Zoo von Frameworks ist, aber diese einzelnen Frameworks sind wesentlich loser aneinander gekoppelt als dies bei JEE der Fall ist.
Dienstag, 22. April 2008
Future of Java
In der Keynote erzählt Rod Johnson was über die Zukunft von Enterprise Java. In seiner typisch amerikanischen Art führt er erst mal aus, dass Java nicht mehr sexy ist: "No one will date a Java developer". Ruby sei doch so viel sexier für Web development. Ist natürlich nicht so, sonst stände Johnson ja nicht hier, sondern würde Ruby machen. Also, noch viel amerikanischer: Wir ziehen erst mal Statistiken raus - indeed.com job trends gibt ja die nötigen Daten ohne große Arbeit. Also der Vergleich mit Ruby, mit dot.net, alles in bunten Bildern. Fazit: Damit Java-Entwickler weiter gedated werden, muss sich Java ändern. Mal schauen, was Johnson als six plus two predictions präsentiert.
Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!
Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.
Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.
Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.
Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.
Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.
Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.
Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.
Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.
Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.
Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.
In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.
Auf zur nächsten Session.
Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!
Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.
Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.
Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.
Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.
Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.
Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.
Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.
Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.
Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.
Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.
In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.
Auf zur nächsten Session.
JAX Eröffnung
Tag 1 der JAX 08. Gestern war ich ja schon auf Tag 0, dem Agile Day vor der JAX. Sebastien Meyen -Chefredakteur bei S&S Media, dem Host der JAX - sagt es gerade, es waren ca. 400 Leute da. Jetzt erzählt er erst mal was über den aktuellen Kontext - welche Themen sind interessant (Architekturen, Agilität, Techniken), in welchem Marktumfeld sind wir hier alle unterwegs: Java EE, EJB 3, Alternative Stacks, Vom Web 2.0 zum Enterprise 2.0 und dynamische Sprachen und Scripting.
Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.
Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.
Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...
Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...
Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.
Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.
Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...
Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...
Montag, 21. April 2008
Agiles Projektmanagement bei Werkverträgen
Ok, es hat etwas gedauert, bis Dirk Sohn in Fahrt kam. Erst hat er sich mühevoll auf einen Life of Brian Witz hingearbeitet ("Ein Schuh"), der Vortrag drohte schon zäh zu werden. Aber kaum hatte er den Schuh umständlich erklärt fiel alle Zurückhaltung von ihm ab und er drehte richtig auf. Dieser Vortrag war definitiv der Höhepunkt. Humoristisch, aber auch inhaltlich.
Das Destillat der Projekterfahrungen, ich sage nur "bottom-up controlling" oder "ein Wiki ist es nicht", war ebenso informativ wie Dirk Sohns Ansichten zur Iteration 0, die - ich habe das auch schon erlebt - mitunter dogmatisch diskutiert wird.
Schön, dass Dirk Sohn am Ende seines Vortrags sogar noch auf die zu Beginn versprochenen Werkverträge kam. Aber eigentlich war das nur die Abrundung des Vortrags.
Das Destillat der Projekterfahrungen, ich sage nur "bottom-up controlling" oder "ein Wiki ist es nicht", war ebenso informativ wie Dirk Sohns Ansichten zur Iteration 0, die - ich habe das auch schon erlebt - mitunter dogmatisch diskutiert wird.
Schön, dass Dirk Sohn am Ende seines Vortrags sogar noch auf die zu Beginn versprochenen Werkverträge kam. Aber eigentlich war das nur die Abrundung des Vortrags.
Product Owner - eine Herausforderung
Das ganze Plenum voller Leute geschätzte zwei bis dreihundert und auf die Frage, ob jemand schon Product Owner ist oder noch werden will meldet sich kein einziger. Vielleicht geht es ja allen so wie mir... die Rolle "in Reinform" wird so wohl wirklich selten gelebt.
Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)
Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.
Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.
Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.
Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)
Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.
Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.
Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.
Kollaboration in IT-Projekten
Dr. Georg Molter und Torben Knerr reden jetzt über Team Kollaboration in Java Projekten, stellen Herausforderungen und Anforderungen vor und zeigen dann Kollaborationswerkzeuge auf drei Leveln: Level 1 als Zusammenstellung von Open Source Tools, Level 2 als spezielle Kollaborationstools und Level 3 als in die IDE integrierte Kollaborationsplattformen.
Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.
Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.
Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.
Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.
Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.
Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.
Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.
Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.
Einführung von agilen Prozessen
"Wie wird man agil?" ist die Frage, an der sich Jutta Eckstein in ihrem Talk entlanghangelt. Interessante Frage, weil die Einführung doch immer wieder ein schwieriger Prozess ist. Im übrigen: Veränderung ist immer ein schwieriger Prozess, warum sollte die Veränderung zu einem agilen Vorgehen also leichter gehen. Nach der "klassischen" Unterscheidung in bottom-up und top-down (heißt hier "guerilla tactics" und "command and control", aber die Begriffe sind mir persönlich zu kriegerisch) konstatiert Jutta Eckstein, dass idealerweise alle am gleichen Strang ziehen - Managment, Kunde, Entwickler... Naja, wann passiert das in der Realität schon? In meiner jedenfalls nicht. Aber genau darum geht es ja Jutta Eckstein. Wie führt man agiles Vorgehen trotzdem erfolgreich ein?
Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.
Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.
Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.
Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.
Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.
Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.
Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.
Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.
Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.
Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.
Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.
Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.
Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.
Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.
Neues von der JAX 08
So, es gibt mal wieder was neues in meinem Blog: Ich bin gerade auf der JAX, genauer auf dem Agile Day. Auf der Zugfahrt habe ich gerade noch den Tonabnehmer von Frank Westphal zum Thema gehört und dabei auch einige interessante Aspekte zu dem mittlerweile doch relativ "alten" Thema Agilität gehört, die sich auch mit meinem Erfahrungshorizont decken: Eine interessante Frage ist beispielsweise, wie man Agilität in das gesamte Unternehmen trägt, wie man agile Software-Entwicklung beispielsweise mit einem bestehenden Controlling integriert. Agiles Controlling, gibt's das? Mal sehen, was zu solchen Themen auf der JAX passiert.
Abonnieren
Posts (Atom)
Posts
