Ein weiterer JAX-Talk diesmal von Eberhardt Wolff am 4. Tag. Seinen Vortrag findet Ihr auf seinem Blog. Der Vortrag selbst war inhaltlich gut (wenn auch nicht überraschend), aber vom Stil und den Folien gruselig. Ich hatte das Gefühl er ginge davon aus, das man auf den ersten Blick in einem Code-Schnipsel erkennt, welche Sünde er nun gerade ansprechen will.
Die 10 "üblichen" Fehler aus seiner Sicht sind:
#1 - Transaktionen so zu bauen, dass sie durch Exceptions verlassen werden können, ohne dass sie geschlossen werden. Seine Lösung ist die Verwendung von deklarativen annotierten Transaktionen oder die Verwendung von Transaktions-Templates. Dabei darf dann nur eine Transaktion in der Methode vorhanden sein.
#2 - Exception Design mit checked Exceptions. D.h. jede Exception muss behandelt werden, auch wenn das sinnvoll nicht möglich ist. Man sollte hier möglichst keine checked Exceptions verwenden und es vermeinden Exceptions zu wrappen und einfach weiterzuwerfen. Setze einen Aspect für das Logging ein, um die Informationen zu erhalten und im Code nur die Exceptions behandeln, mit denen man auch sinnvoll umgehen kann. Alle anderen Exceptions sollten in einem generischen Handler alle Runtime-Exceptions fangen. Eine weitere Variante ist über AOP alle Exceptions zu fangen und zu loggen.
#3 - falsches Exeption-Handling, z.B. kein Handling (leerer Catch-Block) oder Ausgabe des Stacktraces (ohne Logging). #2 führt dazu, das dieses Problem hier auftritt und damit Fehler sehr schwer zu finden sind, weil das Verhalten der Anwendung wirr wird. Die Lösung ist die gleiche wie zuvor: immer loggen, überlegen, ob die Exception sinnvoll bearbeitet oder ignoriert werden kann und auf jeden Fall generisch an den Außengrenzen des Systems abfangen.
#4 - Zirkuläre Paketabhängigkeiten, wodurch der Code wie klebrige Spaghetti verwoben ist und zusammenhängt. Eine sinnvolle Zerlegung des Codes ist somit nicht mehr möglich. Spaghetti muss im Vorfeld (!) durch saubere Architekturen vermieden werden. Zusätzlich sollte man regelmäßiges Refactoring einplanen. Allerdings kann man durch Refactoring nur schwer eine schlechte Architektur aufräumen.
#5 - Adaptor Layer, die in jeder Methode integriert werden müssen, z.B. Traceingausgaben bei Ein- und Austritt aus Methoden. Genauso Security-Checks und Null-Checks. Die Lösung hier ist natürlich AOP.
#6 - Keine DAO's zu verwenden - erschwert das Testen, da immer eine Datenbank verfügbar sein muss. Führt zu ungewollten SQL-Exceptions, u.s.w.
#7 - Keine oder schlechte Tests zu machen, wodurch die Code Qualität gering ist und man schwerlich feststellen kann, ob man durch eine Änderung andere Funktionalitäten verändert hat. Zudem immer positiv UND negativ Unit-Tests vorsehen. Mocks vereinfachen das Durchführen der Tests.
#8 - SQL-Statements schreiben und diese nicht manuell zu konkatenieren. Die Gefahr von SQL-Injektion muss an jeder Stelle geprüft werden. Es ist besser hier entsprechende Mapper oder Wrapper zu verwenden und Zeichen über Positivlisten (WhiteList für Character) zu filtern. Und Prepared Statements verwenden.
#9 - Man sollte sich Gedanken über das Mengengerüst und die Art der Anfragen machen und dieses auch frühzeitig testen. Je eher je besser. Wenn die Performanz Probleme später auftreten hat man keine Zeit für eine vernünftige Lösungssuche mehr. D.h. auch schon einzelne Module frühzeitig auf Performanz testen.
#10 - Nicht Threadsafe zu entwickeln, weil Fehler, die mit multiplen Threads und memory leaks verbunden sind während der Unit-Test nie auftreten werden und nur durch Code-Reviews und Analyse von Threaddumps zu finden sind. Man sollte lokale Variablen bevorzugt nutzen, Synchronisieren und WeakHashMaps einsetzen um Memoryleaks zu vermeiden.
Details und Codebeispiele findet Ihr in seinen Folien.
Posts mit dem Label JAX09 werden angezeigt. Alle Posts anzeigen
Posts mit dem Label JAX09 werden angezeigt. Alle Posts anzeigen
Mittwoch, 6. Mai 2009
Mittwoch, 22. April 2009
JAX 09 - Tag 3 - Retrospektive
Last- und Stresstest mit the Grinder 3
Andreas Spall stellte in seinem Short-Talk Grinder 3 als Lasttesttool und Alternative zu JMeter vor. Von einer Konsole aus steuert man über Agenten auf verschiedenen Rechnern diverse Worker die die Last erzeugen. Mit Grinder soll sich das Aufzeichnen und Abspielen gut durchführen lassen.
Keynote: JRuby Past, Present and Future
die Keynote zu JRuby von Charles Nutter hat Michael Johann (Chefredakteur des Magazins RailsWay) perfekt zusammengefasst: Artikel. Es war eine beeindruckende Präsentation, da sämtliche Beispiele "in Echtzeit" nachvollziehbar von Ihm gecoded wurden.
Komplex, oder doch nur kompliziert?
Der letzte Talk am 3. Tag drehte sich wieder um Projektmanagement. Guido Zockoll zog eine sehr interessanten Vergleich zum Schachspiel mit Start-, Mittel- und Endspiel. Zu Beginn des Schachspiels ist die Stellung bekannt und man hat ein einfaches Problem vorliegen, das man nach Katalog der Spieleröffnungen spielen kann. Beim Endspiel (z.B: König mit Pferdchen und Läufer gegen den verbliebenen gegnerischen König) ist es ein schwieriges bzw. kompliziertes Spiel, das aber auch mit Disziplin und Übung lösbar ist. Ganz anders sieht es im Mittelspiel aus, wenn die Figuren über das Spielbrett verteilt sind. Hierbei handelt es sich um ein komplexes Spiel, in dem sich der Schachspieler mit unüberschaubar vielen Möglichkeiten konfrontiert sieht, die er mit Bauchgefühl, Erfahrung und Heuristiken (Pferd am Rand bringt Kummer und Schand) angeht.
Übertragen auf die IT bzw. das Projektmanagement zeigt sich, das Projekte wesentlich komplexer sind als Schach, da die "Felder, Figuren und Zugmöglichkeiten" wesentlich umfangreicher bzw. Variantenreicher sind. Aber die Lösungsansätze können gut übernommen werden. Ein Schachspieler passt seine Vorgehensweise der Situation entsprechend an. Ein Projektleiter sollte das auch tun.
Andreas Spall stellte in seinem Short-Talk Grinder 3 als Lasttesttool und Alternative zu JMeter vor. Von einer Konsole aus steuert man über Agenten auf verschiedenen Rechnern diverse Worker die die Last erzeugen. Mit Grinder soll sich das Aufzeichnen und Abspielen gut durchführen lassen.
Keynote: JRuby Past, Present and Future
die Keynote zu JRuby von Charles Nutter hat Michael Johann (Chefredakteur des Magazins RailsWay) perfekt zusammengefasst: Artikel. Es war eine beeindruckende Präsentation, da sämtliche Beispiele "in Echtzeit" nachvollziehbar von Ihm gecoded wurden.
Komplex, oder doch nur kompliziert?
Der letzte Talk am 3. Tag drehte sich wieder um Projektmanagement. Guido Zockoll zog eine sehr interessanten Vergleich zum Schachspiel mit Start-, Mittel- und Endspiel. Zu Beginn des Schachspiels ist die Stellung bekannt und man hat ein einfaches Problem vorliegen, das man nach Katalog der Spieleröffnungen spielen kann. Beim Endspiel (z.B: König mit Pferdchen und Läufer gegen den verbliebenen gegnerischen König) ist es ein schwieriges bzw. kompliziertes Spiel, das aber auch mit Disziplin und Übung lösbar ist. Ganz anders sieht es im Mittelspiel aus, wenn die Figuren über das Spielbrett verteilt sind. Hierbei handelt es sich um ein komplexes Spiel, in dem sich der Schachspieler mit unüberschaubar vielen Möglichkeiten konfrontiert sieht, die er mit Bauchgefühl, Erfahrung und Heuristiken (Pferd am Rand bringt Kummer und Schand) angeht.
Übertragen auf die IT bzw. das Projektmanagement zeigt sich, das Projekte wesentlich komplexer sind als Schach, da die "Felder, Figuren und Zugmöglichkeiten" wesentlich umfangreicher bzw. Variantenreicher sind. Aber die Lösungsansätze können gut übernommen werden. Ein Schachspieler passt seine Vorgehensweise der Situation entsprechend an. Ein Projektleiter sollte das auch tun.
JAX 09 - Tag 3
Heute begann das Programm schon um 8:30 und in der Pause funktionierte das WLAN nur sehr unzuverlässig.
Who is BIRT? (BIRT Day)
Gestartet habe ich den Tag mit den ersten beiden Vorträgen des BIRT Day. D.h. mit der Einführungsfrage "Was ist BIRT eigentlich?" und wohin geht die Reise mit der nächsten Version. Geplant ist, die Versionsnummern mit denen von Eclipse zu synchronisieren, so das Eclipse 3.5 zusammen mit BIRT 2.5 im Juni erscheinen wird.
Es war nichts wirklich überraschendes dabei, da ich mich vorab schon mit BIRT, Pentaho und Jasper etwas auseinandergesetzt habe. Solides Werkzeug, das auch in kommerziellen Produkten eingesetzt wird. z.B. in IBM Tivoli
Java Best Practices mit aktuellen Frameworks
Arno Haase gab einen Praxiseinblick der üblichen Herausforderungen, die man bei Verwendung großer Frameworks wie Spring trotzdem noch hat, weil auch diese Frameworks natürlich noch Lücken aufweisen (müssen?):
Logging mittels Log4J bitte unter Beachtung der Bedürfnisse des Betriebs (keine 2 GB Log pro Tag trotz Info-Modus), einem sauberen Handling von Exceptions an den Systemgrenzen, der Beachtung von Parallelität von Threads (insb. in Sessions z.B. mit Ajax), dem Umgang mit Änderungen an Konfigurationsdateien im laufenden Betrieb und schließlich mit JUnit Tests, die möglichst nicht alle Komponenten des Systems zur Testzeit benötigen sollten.
Auch diese Aussagen sind eigentlich selbstverständlich, werden aber scheinbar in vielen Projekten nicht beachtet.
Keynote: Fette Maschinen brauchen schlanke Software
von Claus Alfert. Er führt ein in die Keynote mit einem Abriss über die Geschichte der Hardware-Entwicklung nach Moores Gesetz, nachdem sich die Zahl der Transistoren alle zwei Jahre verdoppelt (nicht die Taktfrequenz!). Aktuell stehen wir bekanntlich an der Schwelle, mit der dieses Gesetz zu einer Vervielfachung der Kerne führt, die aber von der Software nicht wirklich genutzt werden können. Supercomputer werden bald Millionen von CPUs haben und auch die Entwicklung im Enterprise Markt wird in diese Richtung gehen. Aber wie sollen die Kerne ausgenutzt werden, um weiterhin Leistungssteigerungen mitnehmen zu können?
Das Amdahlsche Gesetz zeigt den maximalen Speedup für Programme durch Parallelisierung mit mehreren CPUs. Bei einer Parallelisierbarkeit der Codeausführung von 50% kommt man danach gerade mal auf einen Speedup-Faktor von 2 bei beliebig vielen CPUs. Erst mit sehr hoher Parallelisierbarkeit über 99 % kommt man der 16fachen Geschwindigkeit nah. Aber das ist richtig schwer zu erreichen.
Mit Java ist automatisches Multithreading aufgrund der für diesen Zweck ungünstig gewählten Primitive schwierig umzusetzen (Ist z.B. die Reihenfolge von Zuweisungen relevant?). Dadurch kann der Compiler nicht optimieren und die meisten CPUs werden sich langweilen.
An 3 Beispielen zeigt Herr Alfert in seinem souveränen fesselnden Vortrag auf, wie das Problem angegangen werden könnte: Funktionale Programmierung (wie z.B. in Sprache Erlang), Transactional Memory und Actors.
So senden sich Actors gegenseitig asynchron Nachrichten auf die Sie reagieren können oder nicht und können auf diese Weise warten und anderweitig weiterarbeiten, bzw. Abhängigkeiten entkoppeln. Scala implementiert Actors. Es handelt sich um einen Hybrid aus Objekt-Orientierter-Programmierung und Funktionaler Programmierung. Dabei können über 1 Million Actors pro JVM aktiv sein, während Threads gerade mal auf 3000 bis 4000 gleichzeitig kommen können.
Das heißt dann wohl, dass über kurz oder lang neue Sprachen kommen werden, die mit mehr Wissen um die Abhängigkeiten der einzelnen Aktivitäten die Arbeitsschritte optimieren und auf die CPUs verteilen können, um die Hardware zu nutzen. Vorübergehend lässt sich mit mehreren virtuellen Systemen auf einem Blech noch etwas Zeit schinden.
S.O.S. - Mein Chef sagt, wir brauchen einen ESB
Nachdem auch wir schon vor der Frage standen "ESB oder nicht ESB" und uns gegen einen ESB entschieden haben, war es sehr interessant zu sehen, das wir damit nicht ganz alleine stehen. Bzgl. des Titels des Talks wünschen sich wahrscheinlich viele Architekten, das es den "Man-In-Black-Gedächtnis-Löscher" gäbe, wenn der Chef einen Vortrag einer Firma gesehen hat, die Ihren ESB als Komplexität reduzierende Wunderlösung dargestellt hat. Die Komplexität kann man nicht reduzieren. Sie wird nur in einer wilden Konfiguration des ESB versteckt.
Thilo Frotscher gab hierzu aber keine klare Richtlinie vor, das diese Entscheidung im Einzelfall entschieden werden muss. Ein kommerzieller ESB löst im Allgemeinen alle Probleme, aber auch die die man ohne nicht hätte. D.h. der Umfang und Overhead ist das Kriterium. Leider ist nicht genau festgelegt, was zu einem ESB gehört und so unterscheiden sich die Angebote stark: Messaging System, Binding Komponenten, Transformation, Filter, Routing, Mediation, ... . Zudem hat man oftr langwierige Einführungsphasen, bevor die ESB-gestützte Lösung lauffähig, währen neue Anforderungen verzögert werden, was die Fachbereiche nicht gerne sehen.
Es gibt aber auch die schlanke Variante, sich seinen ESB mit Open Source Produkten selbst nach seinen Anforderungen zusammenzubauen. So kann man klein anfangen und das System schrittweise ausbauen und hält sich trotzdem noch die Tür auf, irgendwann einen kommerziellen ESB einzusetzen.
Mit Active MQ als Messaging-Kern, Apache Camel fürs interne Routing und Apache Synapse als externer SOAP-Router hat man entsprechende Bausteine, die einen minimalen ESB nachbilden, dessen interne Struktur bekannt ist und dessen Einzelteile austauschbar sind. Dafür ist es aber fehlerträchtiger als eine Fertiglösung, weil man die Komponenten erstmal aufeinander abstimmen muss.
Schließlich gab es noch ein paar Weisheiten zum Ausklang des Themas, die gerne verbreitet werden:
"Point2Point ist nicht schlimm!" aber zunehmend gefährlich weil komplex!
"ESB-Konfiguration ist Spaghetti-Code" aber einfacher änderbar.
"ESB nur für große Unternehmen!" aber braucht man unbedingt ein System für alles? Insellösungen funktionieren auch oft.
"Anzugträger empfehlen SOA mit ESB, Jeans- und Turnschuh-Träger klären auf und sagen es geht auch ohne ESB." aber eigentlich geht beides, nur sind die Aufwände unterschiedlich und das führt wieder zum "Es kommt drauf an."
Am Ende gibt es also zu "SOA nur Meinungen aber kaum Fakten".
Keynote: Prozesskomposition in realen Unternehmensszenarien
Herr Thomas Volmering von SAP stellte in seiner Keynote das "ultimative Manager-Tool" vor, mit dem Geschäftsprozesse in BPMN modelliert und dann in Code und somit in die Tat umgesetzt werden könnten, wenn das System dereinst mal fertig sein wird. Auch wenn er (im auf Eclipse aufsetzenden Tool) schon einige Schritte demonstrierte, wird es wohl noch Jahre dauern, bis das in Produktion nutzbar sein wird (Aussage eines BPM Evangelisten: 10 Jahre).
Wer sich das aber mal ansehen möchte kann bei SAP eine Trial-Version herunterladen.
Wenn Scrum zu eng wird - agil in größeren Projekten
Ist das ein Widerspruch? Es entsteht der Eindruck, das Scrum und herkömmliches Vorgehen einander nicht vertragen. Bernd Österreich bezeichnet Scrum als die Anti-These zur starren alten "Wasserfall"-Vorgehensweise, die noch zeigen muss, ob sie den Wertewandel einleitet oder nur ein Hype ist.
Aber das alte System hat Schwächen. Kaum ein Projekt läuft Problemlos. Wer aber das Alte kennt und das Neue ausprobiert, kann aus der Kombination weiterkommen. Sein Vortrag läuft darauf hinaus, dass man zum Beispiel das Anforderungsmanagement (AM) in Scrum übernimmt um das Backlog zu befüllen. Prinzipiell funktioniert Scrum auch ohne AM durch die eigenen Mechanismen der Retrospektive, aber erst im Laufe der Iterationen und Realisierung. Einfacher und planbarer wird es aber durch eine vorgeschaltete AM.
Practical Polyglot Programming: Groovy, Scala, JRuby, Jython and Clojure
Dieser Vortrag klang sehr interessant, brachte mir aber leider nichts, da der Speaker ein sehr schwer verständliches gebrochenes Englisch sprach und viel zu schnell mittels Eclipse durch seine Sourcen sprang. Alle 30 Sekunden verabschiedete sich ein Zuhörer durch Verlassen des Raumes und schließlich habe auch ich nicht durchgehalten.
Nach soviel Input kam ich nicht mehr dazu alles sofort zusammenzufassen. Deshalb etwas verspätet die Infos im Blog.
Who is BIRT? (BIRT Day)
Gestartet habe ich den Tag mit den ersten beiden Vorträgen des BIRT Day. D.h. mit der Einführungsfrage "Was ist BIRT eigentlich?" und wohin geht die Reise mit der nächsten Version. Geplant ist, die Versionsnummern mit denen von Eclipse zu synchronisieren, so das Eclipse 3.5 zusammen mit BIRT 2.5 im Juni erscheinen wird.
Es war nichts wirklich überraschendes dabei, da ich mich vorab schon mit BIRT, Pentaho und Jasper etwas auseinandergesetzt habe. Solides Werkzeug, das auch in kommerziellen Produkten eingesetzt wird. z.B. in IBM Tivoli
Java Best Practices mit aktuellen Frameworks
Arno Haase gab einen Praxiseinblick der üblichen Herausforderungen, die man bei Verwendung großer Frameworks wie Spring trotzdem noch hat, weil auch diese Frameworks natürlich noch Lücken aufweisen (müssen?):
Logging mittels Log4J bitte unter Beachtung der Bedürfnisse des Betriebs (keine 2 GB Log pro Tag trotz Info-Modus), einem sauberen Handling von Exceptions an den Systemgrenzen, der Beachtung von Parallelität von Threads (insb. in Sessions z.B. mit Ajax), dem Umgang mit Änderungen an Konfigurationsdateien im laufenden Betrieb und schließlich mit JUnit Tests, die möglichst nicht alle Komponenten des Systems zur Testzeit benötigen sollten.
Auch diese Aussagen sind eigentlich selbstverständlich, werden aber scheinbar in vielen Projekten nicht beachtet.
Keynote: Fette Maschinen brauchen schlanke Software
von Claus Alfert. Er führt ein in die Keynote mit einem Abriss über die Geschichte der Hardware-Entwicklung nach Moores Gesetz, nachdem sich die Zahl der Transistoren alle zwei Jahre verdoppelt (nicht die Taktfrequenz!). Aktuell stehen wir bekanntlich an der Schwelle, mit der dieses Gesetz zu einer Vervielfachung der Kerne führt, die aber von der Software nicht wirklich genutzt werden können. Supercomputer werden bald Millionen von CPUs haben und auch die Entwicklung im Enterprise Markt wird in diese Richtung gehen. Aber wie sollen die Kerne ausgenutzt werden, um weiterhin Leistungssteigerungen mitnehmen zu können?
Das Amdahlsche Gesetz zeigt den maximalen Speedup für Programme durch Parallelisierung mit mehreren CPUs. Bei einer Parallelisierbarkeit der Codeausführung von 50% kommt man danach gerade mal auf einen Speedup-Faktor von 2 bei beliebig vielen CPUs. Erst mit sehr hoher Parallelisierbarkeit über 99 % kommt man der 16fachen Geschwindigkeit nah. Aber das ist richtig schwer zu erreichen.
Mit Java ist automatisches Multithreading aufgrund der für diesen Zweck ungünstig gewählten Primitive schwierig umzusetzen (Ist z.B. die Reihenfolge von Zuweisungen relevant?). Dadurch kann der Compiler nicht optimieren und die meisten CPUs werden sich langweilen.
An 3 Beispielen zeigt Herr Alfert in seinem souveränen fesselnden Vortrag auf, wie das Problem angegangen werden könnte: Funktionale Programmierung (wie z.B. in Sprache Erlang), Transactional Memory und Actors.
So senden sich Actors gegenseitig asynchron Nachrichten auf die Sie reagieren können oder nicht und können auf diese Weise warten und anderweitig weiterarbeiten, bzw. Abhängigkeiten entkoppeln. Scala implementiert Actors. Es handelt sich um einen Hybrid aus Objekt-Orientierter-Programmierung und Funktionaler Programmierung. Dabei können über 1 Million Actors pro JVM aktiv sein, während Threads gerade mal auf 3000 bis 4000 gleichzeitig kommen können.
Das heißt dann wohl, dass über kurz oder lang neue Sprachen kommen werden, die mit mehr Wissen um die Abhängigkeiten der einzelnen Aktivitäten die Arbeitsschritte optimieren und auf die CPUs verteilen können, um die Hardware zu nutzen. Vorübergehend lässt sich mit mehreren virtuellen Systemen auf einem Blech noch etwas Zeit schinden.
S.O.S. - Mein Chef sagt, wir brauchen einen ESB
Nachdem auch wir schon vor der Frage standen "ESB oder nicht ESB" und uns gegen einen ESB entschieden haben, war es sehr interessant zu sehen, das wir damit nicht ganz alleine stehen. Bzgl. des Titels des Talks wünschen sich wahrscheinlich viele Architekten, das es den "Man-In-Black-Gedächtnis-Löscher" gäbe, wenn der Chef einen Vortrag einer Firma gesehen hat, die Ihren ESB als Komplexität reduzierende Wunderlösung dargestellt hat. Die Komplexität kann man nicht reduzieren. Sie wird nur in einer wilden Konfiguration des ESB versteckt.
Thilo Frotscher gab hierzu aber keine klare Richtlinie vor, das diese Entscheidung im Einzelfall entschieden werden muss. Ein kommerzieller ESB löst im Allgemeinen alle Probleme, aber auch die die man ohne nicht hätte. D.h. der Umfang und Overhead ist das Kriterium. Leider ist nicht genau festgelegt, was zu einem ESB gehört und so unterscheiden sich die Angebote stark: Messaging System, Binding Komponenten, Transformation, Filter, Routing, Mediation, ... . Zudem hat man oftr langwierige Einführungsphasen, bevor die ESB-gestützte Lösung lauffähig, währen neue Anforderungen verzögert werden, was die Fachbereiche nicht gerne sehen.
Es gibt aber auch die schlanke Variante, sich seinen ESB mit Open Source Produkten selbst nach seinen Anforderungen zusammenzubauen. So kann man klein anfangen und das System schrittweise ausbauen und hält sich trotzdem noch die Tür auf, irgendwann einen kommerziellen ESB einzusetzen.
Mit Active MQ als Messaging-Kern, Apache Camel fürs interne Routing und Apache Synapse als externer SOAP-Router hat man entsprechende Bausteine, die einen minimalen ESB nachbilden, dessen interne Struktur bekannt ist und dessen Einzelteile austauschbar sind. Dafür ist es aber fehlerträchtiger als eine Fertiglösung, weil man die Komponenten erstmal aufeinander abstimmen muss.
Schließlich gab es noch ein paar Weisheiten zum Ausklang des Themas, die gerne verbreitet werden:
"Point2Point ist nicht schlimm!" aber zunehmend gefährlich weil komplex!
"ESB-Konfiguration ist Spaghetti-Code" aber einfacher änderbar.
"ESB nur für große Unternehmen!" aber braucht man unbedingt ein System für alles? Insellösungen funktionieren auch oft.
"Anzugträger empfehlen SOA mit ESB, Jeans- und Turnschuh-Träger klären auf und sagen es geht auch ohne ESB." aber eigentlich geht beides, nur sind die Aufwände unterschiedlich und das führt wieder zum "Es kommt drauf an."
Am Ende gibt es also zu "SOA nur Meinungen aber kaum Fakten".
Keynote: Prozesskomposition in realen Unternehmensszenarien
Herr Thomas Volmering von SAP stellte in seiner Keynote das "ultimative Manager-Tool" vor, mit dem Geschäftsprozesse in BPMN modelliert und dann in Code und somit in die Tat umgesetzt werden könnten, wenn das System dereinst mal fertig sein wird. Auch wenn er (im auf Eclipse aufsetzenden Tool) schon einige Schritte demonstrierte, wird es wohl noch Jahre dauern, bis das in Produktion nutzbar sein wird (Aussage eines BPM Evangelisten: 10 Jahre).
Wer sich das aber mal ansehen möchte kann bei SAP eine Trial-Version herunterladen.
Wenn Scrum zu eng wird - agil in größeren Projekten
Ist das ein Widerspruch? Es entsteht der Eindruck, das Scrum und herkömmliches Vorgehen einander nicht vertragen. Bernd Österreich bezeichnet Scrum als die Anti-These zur starren alten "Wasserfall"-Vorgehensweise, die noch zeigen muss, ob sie den Wertewandel einleitet oder nur ein Hype ist.
Aber das alte System hat Schwächen. Kaum ein Projekt läuft Problemlos. Wer aber das Alte kennt und das Neue ausprobiert, kann aus der Kombination weiterkommen. Sein Vortrag läuft darauf hinaus, dass man zum Beispiel das Anforderungsmanagement (AM) in Scrum übernimmt um das Backlog zu befüllen. Prinzipiell funktioniert Scrum auch ohne AM durch die eigenen Mechanismen der Retrospektive, aber erst im Laufe der Iterationen und Realisierung. Einfacher und planbarer wird es aber durch eine vorgeschaltete AM.
Practical Polyglot Programming: Groovy, Scala, JRuby, Jython and Clojure
Dieser Vortrag klang sehr interessant, brachte mir aber leider nichts, da der Speaker ein sehr schwer verständliches gebrochenes Englisch sprach und viel zu schnell mittels Eclipse durch seine Sourcen sprang. Alle 30 Sekunden verabschiedete sich ein Zuhörer durch Verlassen des Raumes und schließlich habe auch ich nicht durchgehalten.
Nach soviel Input kam ich nicht mehr dazu alles sofort zusammenzufassen. Deshalb etwas verspätet die Infos im Blog.
Dienstag, 21. April 2009
JAX 09 - Tag 2 - Retrospektive
Ein langer JAX-Tag geht zuende. Von 9 Uhr bis 21 Uhr Vorträge, Diskussionen, Eindrücke und kleine Pausen bei Nahrungsaufnahme und Retrospektive.
42 für Architekten
Verglichen mit Gebäude-Architekten haben es die Software-Architekten noch sehr schwer. Es gibt keine allgemeinen Standardisierten Notationen, die innerhalb geschweige denn außerhalb der Branche eindeutig verständlich sind. Bei Grundrissen z.B. ist das anders. Im Endeffekt schlägt Dr. Starke vor, sich an den von Ihm und seinem Kollegen erstellten Dokumentationsstandard Architektur 42 zu orientieren oder zu halten, da er in seinen Projekten gute Erfahrung mit dessen Verständlichkeit und Umfang gemacht hat. Auf der Website (arc42.de) finden sich weiterführende Unterlagen und ein Template für die Architekturbeschreibung.
Keynote Opensource und Rezession
Was können wir in der Rezession tun, um unseren Arbeitsplatz und unsere Arbeit zu sichern? Brian Kim legt die Vorteile von Open Source Software (OSS) dar. Firmen orientieren sich gerade jetzt noch stärker hin zu OSS um Kosten zu sparen. D.h. in der Konsequenz, das Entwickler mit OSS-Background bessere Chancen haben. Und wer gar als Contributor oder Committer für OSS aktiv ist, steigert seinen Wert umso mehr. Deshalb empfielt er kurzgesagt: "Gehet hin und werdet Committer für Open Source Projekte!".
Inbox Zero
Ein sehr gut gemachter und sehr kurzweiliger Vortrag war die Vorstellung der Inbox Zero Methode inklusive möglicher Anwendungen für die Softwareentwicklung von Stefan Roock. Da auch meine INBOX niemals leer wird, werde ich dieser Methode eine Chance geben und nach der JAX meine INBOX aufräumen. Über meine Erfahrungen mit diesem Selbstexperiment und Näheres zur Methode werdet Ihr hier sicher bald mehr lesen.
Aufschlussreich war im zweiten Teil seiner Vorstellung auch die Übertragung der Methode auf die Softwareentwicklung. D.h. dort die wachsenden Listen z.B. der Hindernisse bei SCRUM, der Refactoring-Bedarfe oder der gemeldeten Bugs reduzieren und klein zu halten.
JRuby goes Twitter in 50 Minuten
In einem viel zu klein geratenen Seminarraum stellte Michael Johann in einer Art Crash-Kurs JRuby dadurch vor, dass er den Twitterdienst in 50 Minuten rudimentär nachgebaut hat. Das kam nicht ganz so souverän rüber, wie der gleichgelagerte Grails-Anlauf, war aber sehr unterhaltsam. Insb. der intensive Einsatz von Textexpander war ein steter Quell der Heiterkeit.
Keynote: Neal Ford
Zum Abschluss des JAX-Tages gab es für alle anwesenden Entwickler einen eindringlichen und aufrüttelnden Appell von Neal Ford doch endlich aus der Vergangenheit zu lernen. Wir sollen die Fehler nicht wiederholen, sondern aufstehen und es besser machen. Sonst werden wir einfach von der nächsten Outsourcing Welle von China und Indien überannt. In Indien sind z.B. mehr hochbegabte Studenten in einem Semester, als in den USA insgesamt Studenten eingeschrieben sind, da die Zahl der Studenten einfach viel höher ist.
Der Vortrag war sehr beeindruckend und das Auditorium mucksmäuschen still.
42 für Architekten
Verglichen mit Gebäude-Architekten haben es die Software-Architekten noch sehr schwer. Es gibt keine allgemeinen Standardisierten Notationen, die innerhalb geschweige denn außerhalb der Branche eindeutig verständlich sind. Bei Grundrissen z.B. ist das anders. Im Endeffekt schlägt Dr. Starke vor, sich an den von Ihm und seinem Kollegen erstellten Dokumentationsstandard Architektur 42 zu orientieren oder zu halten, da er in seinen Projekten gute Erfahrung mit dessen Verständlichkeit und Umfang gemacht hat. Auf der Website (arc42.de) finden sich weiterführende Unterlagen und ein Template für die Architekturbeschreibung.
Keynote Opensource und Rezession
Was können wir in der Rezession tun, um unseren Arbeitsplatz und unsere Arbeit zu sichern? Brian Kim legt die Vorteile von Open Source Software (OSS) dar. Firmen orientieren sich gerade jetzt noch stärker hin zu OSS um Kosten zu sparen. D.h. in der Konsequenz, das Entwickler mit OSS-Background bessere Chancen haben. Und wer gar als Contributor oder Committer für OSS aktiv ist, steigert seinen Wert umso mehr. Deshalb empfielt er kurzgesagt: "Gehet hin und werdet Committer für Open Source Projekte!".
Inbox Zero
Ein sehr gut gemachter und sehr kurzweiliger Vortrag war die Vorstellung der Inbox Zero Methode inklusive möglicher Anwendungen für die Softwareentwicklung von Stefan Roock. Da auch meine INBOX niemals leer wird, werde ich dieser Methode eine Chance geben und nach der JAX meine INBOX aufräumen. Über meine Erfahrungen mit diesem Selbstexperiment und Näheres zur Methode werdet Ihr hier sicher bald mehr lesen.
Aufschlussreich war im zweiten Teil seiner Vorstellung auch die Übertragung der Methode auf die Softwareentwicklung. D.h. dort die wachsenden Listen z.B. der Hindernisse bei SCRUM, der Refactoring-Bedarfe oder der gemeldeten Bugs reduzieren und klein zu halten.
JRuby goes Twitter in 50 Minuten
In einem viel zu klein geratenen Seminarraum stellte Michael Johann in einer Art Crash-Kurs JRuby dadurch vor, dass er den Twitterdienst in 50 Minuten rudimentär nachgebaut hat. Das kam nicht ganz so souverän rüber, wie der gleichgelagerte Grails-Anlauf, war aber sehr unterhaltsam. Insb. der intensive Einsatz von Textexpander war ein steter Quell der Heiterkeit.
Keynote: Neal Ford
Zum Abschluss des JAX-Tages gab es für alle anwesenden Entwickler einen eindringlichen und aufrüttelnden Appell von Neal Ford doch endlich aus der Vergangenheit zu lernen. Wir sollen die Fehler nicht wiederholen, sondern aufstehen und es besser machen. Sonst werden wir einfach von der nächsten Outsourcing Welle von China und Indien überannt. In Indien sind z.B. mehr hochbegabte Studenten in einem Semester, als in den USA insgesamt Studenten eingeschrieben sind, da die Zahl der Studenten einfach viel höher ist.
Der Vortrag war sehr beeindruckend und das Auditorium mucksmäuschen still.
JAX 09 - Tag 2
Am heutigen Tag startet die JAX 09 offiziell mit der Keynote des Veranstalters. Und das gestern aufgekommene Thema Oracle kauft SUN war natürlich auch Thema Nummer 1.
Während der Keynote wurden einige spontan wirkende Interviews mit einigen Speakern mit entsprechenden Hinweisen auf deren Talks gemacht. Etwas überrascht wirkte der SUN Mitarbeiter, der ja jetzt eigentlich Oracle-Mitarbeiter ist.
Die Frage nach "Wer nutzt Twitter" führte zu einer nur sehr spärlichen Meldequote von unter 5 %. Ob sich das wohl im Laufe der JAX ändern wird? Wahrscheinlich ist die Anlaufzeit für neue Twitternutzer zu lang. mal abwarten. Jedenfalls Twittert das JAX-Team unter @jaxcon fleissig und hat das Tag #JAX09 zum offiziellen JAX-Tag erklärt.
Nach der Keynote, die gnadenlos 15 Minuten überzogen hat, habe ich mir den Vortrag von Dr. Starke und Markus Schärtel angesehen: Business Rules - Die Bandbreite des Einsatzes aus Architektursicht. Da wir selber BRM einsetzen war die Einleitung nichts Neues, aber eine gute Zusammenfassung und Bestätigung für die von uns getroffene Wahl JBoss Drools. Interessant waren die aufgeführten Beispiele für den Einsatz von BRM-Systemen.
Während der Keynote wurden einige spontan wirkende Interviews mit einigen Speakern mit entsprechenden Hinweisen auf deren Talks gemacht. Etwas überrascht wirkte der SUN Mitarbeiter, der ja jetzt eigentlich Oracle-Mitarbeiter ist.
Die Frage nach "Wer nutzt Twitter" führte zu einer nur sehr spärlichen Meldequote von unter 5 %. Ob sich das wohl im Laufe der JAX ändern wird? Wahrscheinlich ist die Anlaufzeit für neue Twitternutzer zu lang. mal abwarten. Jedenfalls Twittert das JAX-Team unter @jaxcon fleissig und hat das Tag #JAX09 zum offiziellen JAX-Tag erklärt.
Nach der Keynote, die gnadenlos 15 Minuten überzogen hat, habe ich mir den Vortrag von Dr. Starke und Markus Schärtel angesehen: Business Rules - Die Bandbreite des Einsatzes aus Architektursicht. Da wir selber BRM einsetzen war die Einleitung nichts Neues, aber eine gute Zusammenfassung und Bestätigung für die von uns getroffene Wahl JBoss Drools. Interessant waren die aufgeführten Beispiele für den Einsatz von BRM-Systemen.
JAX 09 - Agile Day - Retrospektive
Die verbleibenden Vorträge des Agile Day bin ich Euch noch schuldig:
Festpreisprojekt - Behörde - V-Modell: Agilität im Grenzbereich
Als Essenz dieses Vortrages nehme ich mit, das Agilität und V-Modell XT einen geringen Überdeckungsspielraum haben, den man nutzen kann und vielleicht auch nutzen sollte. Aber die Philosophien passen halt nicht wirklich zusammen. V-Modell z.B. gilt für alle Projektgrößen und die gesamte Lebensdauer eines Systems, während die Agilität "nur" für kleine Projekte und die Entwicklungsphase gedacht ist. Andererseits ist innovation der Stärke, die das monolithische V-Konstrukt nicht wirklich mit Leben füllen kann.
Generell sollte man beim Tailoring von V-Modell XT Projekten (als Tipp von Henning Wolf) eher mit der Kettensäge agieren, denn mit der Nagelschere. D.h. nach der Devise weniger ist mehr sollte man nur Produkte mit Leben füllen, die auch einen Stakeholder haben, der sie bezahlt/nutzt.
SCRUM in der Community Realität bei XING - Ein Erfahrungsbericht
Das Highlight des ersten Tages war eindeutig dieser Vortrag von Susanne Reppin und Dr. Johannes Mainusch von XING! Die Vortragsart war amüsant, dynamisch, agil, souverän und energiegeladen. Es hat schon allein Spass gemacht den beiden zuzusehen. Aber auch die Inhalte stimmten.
Eine Kurzvorstellung von XING gespickt mit Details und technischen Infos leitete den Vortrag ein. z.B. dass 45.000 Nutzer in Spitzenzeiten XING parallel nutzen, dass es komplett in Perl und Ruby umgesetzt ist, und dass sie die Seitenaufbauzeiten mittels Javascript beim Nutzer messen und zurückmelden. Herausheben möchte ich noch, dass bei XING die Kilobytes pro Pageview erfasst werden. Von anfänglich ca. 160 KB pro Pageview haben Sie sich auf 42 KB gearbeitet. Dabei ist Ihnen aufgefallen, das der Durchschnitt in der Woche bei 56 KB liegt, weil der IE 6.0 nicht mit HTTP 1.1 umgehen kann und so die Seite nicht gecached wird. Und das tritt nur während der Arbeitszeit auf, weil viele Großunternehmen hier keine Updates machen und somit immernoch IE 6.0 einsetzen.
XING setzt voll auf SCRUM. Mit 50 Releases im Jahr! Scherzhaft: "So wird die Angst pro Release kleiner!"
Ich muss ja zugeben, dass ich mich bisher nicht wirklich mit der agilen Softwareentwicklung beschäftigt habe, aber dieser Vortrag hat Lust darauf gemacht. Die Philosophie, dass immer nur eines fest steht, und zwar der Zeitrahmen oder das Feature klingt fremdartig. Und das muss erstmal im ganzen Unternehmen verdaut und akzeptiert werden, insb. auch im Management. Im Zentrum der Vorgehensweise steht das Team! Das Team ...
- ... hat die Antworten auf die meisten Fragen,
- ... entscheide, organisiert sich und äußert Wünsche
- ... ist 5-7 Personen groß (inkl. QA)
- ... lebt Pair Programming (auch in ungleichen Zusammensetzungen z.B. HTML'er und Ruby-Entwickler)
- ... Schätzt neue Aufgaben gemeinsam, bzw. jeder schätzt den Gesamtaufwand. Die Schätzer des höchsten und niedrigsten Wertes diskutieren Ihre Annahmen und dann schätzen alle erneut ... und dann kommt angeblich meist ein sehr einheitlicher Schätzwert heraus.
Es gibt einiges aus diesem Vortrag, das ich unbedingt mal in der Praxis ausprobieren muss.
Pecha Kucha zu agilen Vorgehensweisen
Der letzte Vortragsblock brachte dann nochmal ein interessantes Vortragskonzept mit - Pecha Kucha (Stimmengewirr): 6 Vorträge a 6 Minuten mit je 20 Folien die nach 20 Sekunden automatisch weiterspringen.
Der bestgemachte der Vorträge drehte sich um "Inkrementelles Design" von Bernd Schiffer. Er stellte Inkrementelles Design analog zur Evolution vor, mit z.B. vielen bunten Fischen, die jeweils ein Schlagwort der Phasen Spezifikation, Amplifikation, Selektion, Restabilisierung und Variaton anschaulich und kurzweilig verdeutlichten.
Einen Lacher und bleibende Erinnerung hinterliess der Vortrag "Everybody does Refactoring, right?" von Marko Schulz mit der Feststellung: "Refactoring ist ... ein Menü in Eclipse"! D.h. jeder spricht von Refeactoring, aber die meisten sehen nur das werkzeuggetriebene Refactoring, und nicht das eigentlich erforderliche viel Erfahrung benötigende Refactoring von Systemen z.B. zur Glättung von Sünden aus dem Projektgeschäft.
Schliesslich gab es im RUP Vortrag ein kleines Filmchen, das ich Euch nicht vorenthalten will: Piloten (Youtube sei Dank).
Somit ging dann der erste Tag der JAX '09 seinem Ende entgegen. Im Restaurantschiff auf der anderen Rheinseite haben wir denn Abend ausklingen lassen.
Festpreisprojekt - Behörde - V-Modell: Agilität im Grenzbereich
Als Essenz dieses Vortrages nehme ich mit, das Agilität und V-Modell XT einen geringen Überdeckungsspielraum haben, den man nutzen kann und vielleicht auch nutzen sollte. Aber die Philosophien passen halt nicht wirklich zusammen. V-Modell z.B. gilt für alle Projektgrößen und die gesamte Lebensdauer eines Systems, während die Agilität "nur" für kleine Projekte und die Entwicklungsphase gedacht ist. Andererseits ist innovation der Stärke, die das monolithische V-Konstrukt nicht wirklich mit Leben füllen kann.
Generell sollte man beim Tailoring von V-Modell XT Projekten (als Tipp von Henning Wolf) eher mit der Kettensäge agieren, denn mit der Nagelschere. D.h. nach der Devise weniger ist mehr sollte man nur Produkte mit Leben füllen, die auch einen Stakeholder haben, der sie bezahlt/nutzt.
SCRUM in der Community Realität bei XING - Ein Erfahrungsbericht
Das Highlight des ersten Tages war eindeutig dieser Vortrag von Susanne Reppin und Dr. Johannes Mainusch von XING! Die Vortragsart war amüsant, dynamisch, agil, souverän und energiegeladen. Es hat schon allein Spass gemacht den beiden zuzusehen. Aber auch die Inhalte stimmten.
Eine Kurzvorstellung von XING gespickt mit Details und technischen Infos leitete den Vortrag ein. z.B. dass 45.000 Nutzer in Spitzenzeiten XING parallel nutzen, dass es komplett in Perl und Ruby umgesetzt ist, und dass sie die Seitenaufbauzeiten mittels Javascript beim Nutzer messen und zurückmelden. Herausheben möchte ich noch, dass bei XING die Kilobytes pro Pageview erfasst werden. Von anfänglich ca. 160 KB pro Pageview haben Sie sich auf 42 KB gearbeitet. Dabei ist Ihnen aufgefallen, das der Durchschnitt in der Woche bei 56 KB liegt, weil der IE 6.0 nicht mit HTTP 1.1 umgehen kann und so die Seite nicht gecached wird. Und das tritt nur während der Arbeitszeit auf, weil viele Großunternehmen hier keine Updates machen und somit immernoch IE 6.0 einsetzen.
XING setzt voll auf SCRUM. Mit 50 Releases im Jahr! Scherzhaft: "So wird die Angst pro Release kleiner!"
Ich muss ja zugeben, dass ich mich bisher nicht wirklich mit der agilen Softwareentwicklung beschäftigt habe, aber dieser Vortrag hat Lust darauf gemacht. Die Philosophie, dass immer nur eines fest steht, und zwar der Zeitrahmen oder das Feature klingt fremdartig. Und das muss erstmal im ganzen Unternehmen verdaut und akzeptiert werden, insb. auch im Management. Im Zentrum der Vorgehensweise steht das Team! Das Team ...
- ... hat die Antworten auf die meisten Fragen,
- ... entscheide, organisiert sich und äußert Wünsche
- ... ist 5-7 Personen groß (inkl. QA)
- ... lebt Pair Programming (auch in ungleichen Zusammensetzungen z.B. HTML'er und Ruby-Entwickler)
- ... Schätzt neue Aufgaben gemeinsam, bzw. jeder schätzt den Gesamtaufwand. Die Schätzer des höchsten und niedrigsten Wertes diskutieren Ihre Annahmen und dann schätzen alle erneut ... und dann kommt angeblich meist ein sehr einheitlicher Schätzwert heraus.
Es gibt einiges aus diesem Vortrag, das ich unbedingt mal in der Praxis ausprobieren muss.
Pecha Kucha zu agilen Vorgehensweisen
Der letzte Vortragsblock brachte dann nochmal ein interessantes Vortragskonzept mit - Pecha Kucha (Stimmengewirr): 6 Vorträge a 6 Minuten mit je 20 Folien die nach 20 Sekunden automatisch weiterspringen.
Der bestgemachte der Vorträge drehte sich um "Inkrementelles Design" von Bernd Schiffer. Er stellte Inkrementelles Design analog zur Evolution vor, mit z.B. vielen bunten Fischen, die jeweils ein Schlagwort der Phasen Spezifikation, Amplifikation, Selektion, Restabilisierung und Variaton anschaulich und kurzweilig verdeutlichten.
Einen Lacher und bleibende Erinnerung hinterliess der Vortrag "Everybody does Refactoring, right?" von Marko Schulz mit der Feststellung: "Refactoring ist ... ein Menü in Eclipse"! D.h. jeder spricht von Refeactoring, aber die meisten sehen nur das werkzeuggetriebene Refactoring, und nicht das eigentlich erforderliche viel Erfahrung benötigende Refactoring von Systemen z.B. zur Glättung von Sünden aus dem Projektgeschäft.
Schliesslich gab es im RUP Vortrag ein kleines Filmchen, das ich Euch nicht vorenthalten will: Piloten (Youtube sei Dank).
Somit ging dann der erste Tag der JAX '09 seinem Ende entgegen. Im Restaurantschiff auf der anderen Rheinseite haben wir denn Abend ausklingen lassen.
Montag, 20. April 2009
JAX 09 - Agile Day
Die Rheingoldhalle hat natürlich schon vom Ausblick auf den Rhein ein ganz anderes Flair, als es die Wiesbadener Halle aufwies. Hinzu kommt noch das gute Wetter. Schade eigentlich, dass man dann den ganzen Tag drinnen verbringen muss.
Am ersten Tag der JAX besuche ich die Vorträge des Agile Day:
- Agile Systemdokumentation
- Einstieg in die agile Entwicklung: Großprojektentwicklung bei Otto
- Festpreisprojekt - Behörde - V-Modell: Agilität im Grenzbereich
- SCRUM in der Community Realität bei XING - Ein Erfahrungsbericht
- Pecha Kucha zu agilen Vorgehensweisen
Der erste Vortrag hat nicht ganz meine Erwartungen erfüllt. Jetzt mal abgesehen von den technischen Problemen. Die Rückkopplungen bekam die Technik nicht richtig in Griff. Ein leichtes Hintergrundpfeifen das gelegentlich in eine schrille Pfeiforgie ausartete war sehr unschön. Aber zurück zum Inhalt - Die Hauptaussagen des Vortrags würde ich mal als "Vertrauen schaffen" und "Reduktion auf das Wesentliche" bezeichnen. D.h. mit dem gewonnen Vertrauen den Kunden dazu zu bewegen, die angeforderte Dokumentation zu reduzieren, auf das was wirklich benötigt wird. Generell natürlich ein sinnvoller Tip, wenn der Kunde da mitspielt.
Vortrag 2 hätte genausogut von unserem Projekt erzählen können. Die Probleme und Schwierigkeiten im Projekt sind 1:1 bei uns vorhanden.
Und schon naht das Ende der Mittagspause ...
Am ersten Tag der JAX besuche ich die Vorträge des Agile Day:
- Agile Systemdokumentation
- Einstieg in die agile Entwicklung: Großprojektentwicklung bei Otto
- Festpreisprojekt - Behörde - V-Modell: Agilität im Grenzbereich
- SCRUM in der Community Realität bei XING - Ein Erfahrungsbericht
- Pecha Kucha zu agilen Vorgehensweisen
Der erste Vortrag hat nicht ganz meine Erwartungen erfüllt. Jetzt mal abgesehen von den technischen Problemen. Die Rückkopplungen bekam die Technik nicht richtig in Griff. Ein leichtes Hintergrundpfeifen das gelegentlich in eine schrille Pfeiforgie ausartete war sehr unschön. Aber zurück zum Inhalt - Die Hauptaussagen des Vortrags würde ich mal als "Vertrauen schaffen" und "Reduktion auf das Wesentliche" bezeichnen. D.h. mit dem gewonnen Vertrauen den Kunden dazu zu bewegen, die angeforderte Dokumentation zu reduzieren, auf das was wirklich benötigt wird. Generell natürlich ein sinnvoller Tip, wenn der Kunde da mitspielt.
Vortrag 2 hätte genausogut von unserem Projekt erzählen können. Die Probleme und Schwierigkeiten im Projekt sind 1:1 bei uns vorhanden.
Und schon naht das Ende der Mittagspause ...
Abonnieren
Posts (Atom)