Kategorie: Live Blogging

Veröffentlicht am

Das Ergebnis der Blogparade von Bianca Gade: Das Ebook zu „Wie ist mein Arbeitsplatz der Zukunft“

Die Lese- und Recherche Ecke mit an meine grösse individuell angepasstem Lesepult und einem kleinen Ausschnitt meiner Bibliothek
Der Schreibtisch mit Miniserver für meine EBooks und Wetterstation (ja, mich interessiert auch Wetterkunde und Astronomie) und allem, was ich für die IT lastige Arbeit brauche. Ja, auch ein Mikroskop gehört dazu, schon, um mit den Kindern die Natur zu erforschen.

Wir erinnern uns: Bianca Gade, einer der kreativen Köpfe in meinem Umfeld, deren Ideen ich immer sehr schätze rief zur Blogparade. Wir sollten beschreiben, wie wir uns unseren Arbeitsplatz der Zukunft vorstellen.
Ich hab jetzt im Nachklang noch mal meinen privaten Arbeitsplatz als Blogger, Autor und Wissenschaftler abfotografiert. Denn ich denke, ich bin nicht nur Arbeitnehmer, sondern arbeite auch, wenn ich mich mit Themen auseinandersetze, die mich weiterbringen, mir neue Einsichten liefern oder zu Blogbeiträgen führen. Dazu gehört Recherche, Experimente und Analyse dazu. Und dazu brauche ich einen kreativen, inspirierenden Arbeitsplatz.

Insgesamt haben 23 Blogger haben mitgemacht und ihre Beiträge veröffentlicht.

Jetzt gibt es wie versprochen auch ein EBook von den Ergebnissen.

Danke Bianca für diese Aktion: Die passt perfekt zum Jamcamp, bei dem ich zu genau diesem Thema eine Breakout Session halten werde mit dem Titel: „Workplace of the future now“.

Hier das EBook:

 

E-Book zur Blog-Parade: Wie ist dein Arbeitsplatz der Zukunft?

Die Ergebnisse sind wirklich sehr lesenswert, bilden sie doch ein breites Spektrum an verschiedenen Sichten und Herangehensweisen ab. Blindee Euphorie ist bei dem Thema nicht zu finden aber sehr viele sehr differenzierte Sichten. Oder um es im Duktus von Twitter zu formulieren: #ilike

Veröffentlicht am

Barcamp Stuttgart ein Fazit in drei Tags: Klasse, informativ, lecker

Zurück vom Barcamp Stuttgart.

Bin immer noch komplett vollgeladen mit Information, Inspiration und Stoff zum Nachdenken. Wer hätte gedacht, dass es auf einem Barcamp eine Session „Wer bin ich wirklich?“ und das diese Session in mir ganz viele Gedanken, Emotionen und den Wunsch, mich wieder mit mir zu befassen und mich wieder weiterzuentwickeln auslösen würde. Tausend Dank alleine schon dafür.

We had joy, we had fun, we had sessions in the sun

 

Was ich auch mitgenommen habe, es gibt weit mehr Menschen, die sich Gedanken um ihren Konsum machen, und was er mit unserer Welt macht als ich annahm. Und nein, es war kein reines Geek Camp Beate, aber der zweite Tag hat ein paar ganz besondere Sessions gehabt. Und hmm, trotz „Collaborative Consumption“ und neuen Gedanken zum Konsumverzicht die AR Drone.. Hach, epic hach, die wird sich der Herr Papa wohl zum Geburtstag wünschen. Schliesslich beschwert sich meine Frau immer, mir Geek könne man doch eh nix schenken…. Arr, Arrr Arrrrrrrrr.

Jetzt bin ich wieder zu hause, mit einem Füllhorn neuer Eindrücke, und einer Menge an neuen Ideen fürs Blog, für Gadgets und Tests und ja, dank @emju bin ich auch wieder motiviert, eines meiner grössten Projekte aus der Kategorie, „will ich schon immer, aber trau mich nicht “ anzugehen, an einem Buch arbeiten, dessen Grundidee seit Jahren in meinem Kopf steckt, das ich aber nie wirklich begonnen habe.. aus Angst.. hmm. Ich glaube, da sollte ich mich noch mal mit dem „Wer bin ich wirklich“ Kreis kurzschließen 😉

Nächstes Projekt und Resultat aus einer Session des Barcamps über Collaborative Consumption. Das Thema wird möglichst bald ein viel stärkeres Gewicht in meinem Blog bekommen, da mich dieses Thema mit all seinen Facetten spätestens seit der re:publica 2011 intensiv beschäftigt und ich da auch schon ein paar lose Enden zusammenrecherchiert habe, die dank der Stuttgarter Session erste Knoten ausgebildet haben und die ich nun endgültig zu einem roten Faden verbinden möchte.

Das Barcamp bestand nicht nur aus "denkdenkdenk" sondern auch aus extrem "nomnomnom"

Ansonsten tausend Dank an alle Sponsoren. Ihr wisst hoffentlich, wie wichtig ihr wart und auch beim nächsen Barcamp sein werdet. Danke an Jan Theofel the brain behind all the action, an mfg innovation für die geniale Location (oh, das reimt sich, und was sich reimt ist gut!), an esskultur für extrem gutes #nomnomnom an den beiden Tagen und an alle, die in irgendeiner Form dazu beigetragen haben, dass wir barcamper uns willkommen, versorgt und umsorgt gefühlt haben. You ROCK, all of you!

Und allen Followern die ich wiedersehen durfte, die ich zum ersten Mal treffen durfte, oder die ich jetzt als neue Follower gewonnen habe. Vielen Dank für viele tolle Gespräche, Gedanken, Diskussionen. Und auch vielen Dank all jenen, die ich ganz neu kennenlernen durfte, und denen ich jetzt gerne und mit dem Wissen folge, da tickt ein kreativer Kopf!

Und last but not least meine Tweets, die von Herzen kamen:

Merke: Im Netz und auf Barcamps interessieren keine Jobbezeichnungen, Alter oder Geschlecht, sondern was du drauf hast

und: Follower aus barcamps sind besonders interessant. Sie folgen einem, OBWOHL sie dich live erlebt haben… #bcs4”

Und ganz zum Schluß: @windfeder Wow, Respekt für die Bilder, mach weiter, du hast Talent. VIEL Talent!

 

Veröffentlicht am

Barcamp Stuttgart 2011: Schon am ersten Tag sehr erkenntnisreich.

image

Wieder ein Barcamp, bei dem die spannendsten Sessions parallel laufen. Schon jetzt, nach erst einem Tag kann ich definitiv sagen, es hat sich gelohnt. Hab wieder mal meine GTD Kenntnisse aufgefrischt, neue Einsichten zum Thema Apps für Kinder bekommen und gelernt, dass man mittlerweile sehr gut qualitativ hochwertige Texte aus Datenbanken von Programmen extrahieren lassen kann.

Ansonsten einfach ein Spitzenumfeld, sehr leckeres Essen, super Getränkeversorgung und auch die Lokation ist Spitze, von meinem Hotel aus nur ein paar Schritte.
Jetzt bin ich noch auf das Abendprogramm gespannt und was uns morgen erwartet.

image

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 6

Vortrag 6: Restful API design
Warum REST mehr als HTTP mit XML ist

REST= Representational State Transfer

Representational State Transfer. Bunt.

Als Beispiel wird „ein Büchershop (guess which one)“ genutzt.

Das ganze soll jetzt auf Mobile Endgeräte, „wir brauchen eine App“
Also braucht man eine Api.
die zu implementierenden Schnittstellen sind aus dem „Legacy“ System vorgegeben.
REST möchte:

 

Für eine Web API
http bewusst nutzen

Bedenken, das Web ist ein verteiltes Medium

Vorkenntnisse über APIs sollten minimiert werden (einfache Einarbeitung).

1 Methode ergibt eine REssource
also Buch Nr Buch-ID —-> http://site/api/book/book-id

2 Methoden, eine Ressource

addToCart
getCartInfo

http://site/api/cart/cart-id

Man muss sich immer die Frage stellen, was kommt in die URI, was in die Parameter
Alles was ein „Ding“ ist in die Uri, der Rest in die Parameter
Aktionen entsprechen Methoden

Aktionen auf Ressourcen sind nicht Teil der URI sondern http-Methoden

Dies ist später in
der API Doku zu beschreiben
Übliche Verhaltensmuster sind
GET->Anzeigen
Post Anlegen oder Ergänzen
PUT Anlegen oder Schreiben

Es sind pro Entity mehrere URI möglich

Http Möglichkeiten nutzen, Error Meldungen, Last Sharing etc.

Caching kann im Header eingestellt werden, also nutzen, gerade auch für mobile Geräte.

ETags definieren den Zustand einer Ressource. Auch diese sind sinnvoll!

Links: Echtes REST

 

Link-Semantik definieren

Ressourcen mit Referenzen verknüpfen

Wissen über die API also verlagern in die Link Annotation

Die Art des Links kann in einem Annotation type wie rel definiert werden.

 

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 5

Vortrag 5:
Safety First, Android sicher programmieren!

@elektrojunge on stage

Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.

Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC

Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.

Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen

Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.

Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees

Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme

Wo sind die Verantwortlichkeiten des Entwicklers?

Per Default kann eine App vom „Umfeld“ nichts sehen.

Component wird exportiert durch android:exported im Intentsfilter

Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter

Activities

Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“

Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.

Services

Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.

Achtung bei der Verwendung von Binder Interface.

Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.

Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen

Broadcast Receiver

Receiver: Wiederum eine Genehmigung erzwingen

Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.

Don’t user sticky broadcasts for sensitive data!

ContentProvider

Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission

TAg schränkt zur Compiletime uri Zugriffe ein.

Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.

Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.

Selection fields final machen um Kontaminierung aus Zufall zu vermeiden

Selektionen komplett vermeiden, Content_uris verwenden.

File I/O

Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden

Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.

IMMER DRAN DENKEN Nutzerdaten SICHER speichern.

So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 4

Vortrag 4:

Java in der Cloud – Aktuelle Möglichkeiten und Entwicklungen

Was ist die Cloud?
Infrastructure as Service
Virtuelle Server, vergleichbar mit Virtualisierung

Manage Everything yourself
Player sind z.B. Amazon Webservices
VMWare
Platform as a Service
Virtual App Server
werden meist von den Providern gemanagt.
Skalierung wird vom Anbieter gemanagt.
Beispiele Cloudfoundry oder Google App Engine

Software as a service

Software aus der Cloud meist ebenso relevant für User wie Entwickler
Beispiele: Salesforce
Google Mail

Cloud Modelle:

Public -> Für die Öffentlichkeit verfügbar

Private -> Nur für eine Organisation verfügbar

Community -> Für mehrere Organisationen verfügbar

Hybrid -> Kombination verschiedener Modelle

Warum Cloud überhaupt machen

Public Cloud: Zahl nur, was du brauchst
Billige Art, Lastspitzen zu behandeln
Transparentes Kostenmodell

Private Cloud:
Besser Verwendung der Ressourcen
Kosten können abgerechnet werden
Der nächste Schritt nach der Virtualisierung

Business Agility
Deployment von Anwendungen per Maus Klick
Testumgebungen sehr einfach und günstig. Zahlen nur beim Testen.
Die Anwendung skaliert automatisch

Werner Vogels (CTO Amazon) sagt: Ihre Ingenieure brauchen 70% der Zeit für Skalierbarkeit und Technologie-> Deshalb Cloud

Plattform der Zukunft
Ausfallsicherheit, Automatische Verteilung, neue Computer einzurichten wird trivial
Günstige Systeme mit hoher Verfügbarkeit und Datenhaltungssicherheit
Sieht so aus wie Google, Amazon, Facebook

Wie sieht das für den Java Entwickler aus

Wie gehe ich mit Lastspitzen um? Ich brauche mehr App Server Instancen
Nach dem Peak müssen sie auch wieder gestoppt werden
Elastic Scaling als Stichwort
Was der Entwickler am Ende hat:
Eine Werkzeug, das eine Anwendung nimmt und daraus eine VM erzugt, mit der gesamten nötigen Infrastruktur.
Diese kann dynamisch hoch und runter skalieren.

Wir benötigen Werkzeuge zur Installation der Software
Die Infrastruktur verwalten
Benutzer einrichten

Tools sind z.B. Puppet, Chef etc.
Quasi eine Factory für VMs
Für lokale Installationen existiert „Vagrant“
Vorteile: Sehr flexibel
Arbeitet für jetwede Infrastruktur und Anwendung
Arbeitet auf komplexen Installationen mit versch. Komponenten
Verschiedene Anwendungen können auf verschiedene Knoten deployt werden.

Aber noch besser geht es:

Anwendung auf einer PaaS Umgebung also Plattform as a Service deployen
Vorteil: Nützlicher, da ein Server sowieso installiert werden müssten
Automatische Skalierung
Zusätzliche Dienste im Angebot

Aber:
Weniger flexibel
Vordefiniertes Entwicklungsmodell
Lernkurve für das Programmiermodell
Existierender Code ggf. schwer zu migrieren.

Mogliche PaaS Plattformen
Google App Engine
Java Unterstützung aber sehr restriktive Umgebung mit Java Classes White List
Fokus auf NoSQL

Begrenzung der startbaren Applikationen
Limit auf Antwortzeit (30sec)
Kein Zugriff auf OS oder Server

Daher wurden spezielle Frameworks entwickelt
(Gaelyk for Groovy)

Aber besser laut Vortragendem

Amazon Elastic Beanstalk

Basierend auf der EC2 Infrastruktur
plus Auto Scaling und S3
Dazu Linux, OpenJDK und Tomcat

Zur Zeit im Betatest im Osten der USA
Es gibt Eclipse Plugin
Es unterstützt Versionsverwaltung für Applications, sowie Elastic Scaling
Einfaches Monitoring ist eingebaut
Detailierte Kontrolle über die Umgebung ist möglich.
Zugang aufs OS und Tomcat Logs

Spring basierte Demoanwendung ist vorhanden und es existiert ein Relational Database Service (RDS) für enterprise scale MySQL und andere Amazon Web Services
Skalierungseinheit 1 VM = 1 Server

Weiterer Ansatz
VMWare Cloud Foundry
Open Source Projekt bei GitHub unter der Apache2 Lizenz

Sehr neu, noch ohne kommerzielle Angebote

Kann Ruby, Java und Node.js laufen lassen
Verschiedene Frameworks werden unterstützt
Kann überall gehostet werden, wird von der Community erweitert, z.B. Support für Erlang, PHP, Python

Es existiert ein Eclipse Plugin
Es unterstützt elastic scaling…. Ok, man kann es bauen.
Aehnlich normalen EJB Umgebungen mit Tomcat und MySQL
Läuft auf ubuntu
es teilen sich n Server eine virtuelle Maschine, damit geht die Skalierung feingranularer.
Angebotene Dienste sind
RDB Service
Key Value Store
Document Store
Messaging Service
Mehr kommt
Es gibt auch eine API zum Erstellen der eigenen Services

Zusammenfassend
Cloud wird aus drei Gründen kommen: Kosten, Business Agility, Platform of the Future
Google App Engine Pionier aber veraltet

Amazon Beanstalks: Standing on the shoulde of Giants

Cloudbees: Für Entwickler

Spannend scheint CloudFoundry: Open Source mit einer grossen aktiven Community, lauffähig auf ubuntu!

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 3

Vortrag 3:

Das nächste große Ding
Programmiersprachen für die JVM

Java ist in gewissem Sinne bereits Legacy.

Was ist eine große Programmiersprache?

C, C++, Java sind groß -> Pascal eher nicht, Modula auch nicht
Große Sprachen erlauben große Projekte

Sprachen, die sich modernisieren werden nicht zwangsweise besser, eher komplexer.

Eine große Sprache ist wichtig, weit verbreitet, berufsentscheidend und etabliert.

Es kommt aber NICHT auf die Syntax an.
Wichtig ist auch die Community!

Das nächste große Ding läuft vermutlich auf der JVM.

Konkurriert mit Java.
Und ersetzt Java und macht möglicherweise noch andere überflüssig.

Die guten Seiten von Java sind heute nicht mehr relevant. Objektorientierung, Threads, Packages, Sandbox etc. sind zwar gut aber „old school“.

Bestimmte Probleme lassen sich mit Objektorientierung sehr gut lösen, aber nur die. Mit einem Löffel kann man auch eine Baugrube ausheben.

Auch sonst gute Aspekte wie: kein goto, Kein Überladen von Operatoren, kein typedef, kein Präprozessor
Schönes Zitat: „Die jungen Leute kennen keine Pointer mehr“

Technologie-Sprung
NICHT alles ist aber ein Objekt. Dinge, die wir für alle Datentypen machen müssen, müssen wir auch für alle Datentypen tun.

Die primäre Weisung es muss rückwärtskompatibel sein

Sekundäre Weisung
Das Java „Feeling“ sichern
Die konzeptuelle Integrität sichern.

Java hat Probleme mit Generics und Closures

Anderungswünsche
foreach auch für Maps
Switch-break-fix
Abfangen von unmoglichen Checked Exceptions
und diverse moderne Elemente anderer Sprachen.
Die Frage ist nicht die Menge an zu schreibendem Code, sondern wie lesbar ist der Code der „zukünftigen“ Sprache.

gewünscht:
Sprachorientierte Programmierung
Unveränderlichkeit
Funktionale Programmierung
Nebenläufigkeit und Parallelität

Auf jeden Fall eine Art Paradigmenwechsel

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 2

Vortrag 2:

Funktionieren agile und dynamische Entwicklungsprozesse nur in dynamischen und agilen Unternehmen?

Entwicklungsprozess funktionieren, wenn die Ziele erreicht werden, das berühmte Dreieck Qualität, Kosten und Termin wird präsentiert.

Der Prozess bei Gebit ist iterativ, inkrementell, mehrfach paralleler Entwicklungsprozess, also Modell-Driven
Interpreter Framework, kein Generatorenframework, also interpretieren des Modells zur Laufzeit.

Gebit setzt agile Methoden wie
Parrprogrammierung, Testgetriebene Entwicklung und Refactoring

Auch hier fällt das Stichwort Continous Integration wieder.

Erstes Fallbeispiel: Projekt Entwicklung Kassensystem, Ablösung von Standardsoftware mit zahlreichen Schnittstellen zu Backend Systemen.
Bei GEBIT lag auch die Testverantwortung.
Die Beauftragung erfolgte immer in Monatssteps->Gefiel das Ergebnis bis dann->Nächster Step.
Die Entwicklung erfolgte alleine durch GEBIT.
Insgesamt 15 Monate bis zu ersten produktiven Implementierung.
Schlüssel zum Erfolg:
-Paarweise Spezifikation
-Volle Konzentration von Auftraggeber und Nehmer auf das Projekt
-Eskalierte Themen wurden ernst genommen
-Betroffene zu Beteiligten machen.

Zweites Fallbeispiel: Sachbearbeiteranwendung in einer Behörde.
Ablösung von 2 Altverfahren, 12,3kg Specs von mehr als 50 Autoren (Projekt lief bereits lange)

Testautomatisierung in hohem Mß durch MA des Kunden

Problem bei diesem Projekt, keine wirklichen ITler in der IT Abteilung der Behörde

Keine Projektleitung beim Kunden, da Mitarbeiter maximal 20-30% der Zeit für Projektleitung
Projekt für Einführung und Betrieb fehlte aber völlig.
Keiner der beteiligten Mitarbeiter war Vollzeit im Projekt, maximale Zuordnung war 50% im Projekt.
D.h. Oft laufen IT Projekte in IT fernen Unternehmen, ohne das Bewußtsein für die Bedürfnisse eines IT-Projektes.

Herausforderungen: Agile Methoden waren gesetzt
Es wurde sich am V-Modell orientiert
Umfangreiche Mitwirkungsleistungen des Auftraggebers wegen Budget

Hoher Headcount auf Kundenseite
aber Teilzeitkräfte, Tagesgeschäft, Altverfahren

Projektteams ohne Projekterfahrung. Das ist oft ein grosse Problem. Order by Mufti funktioniert hier nicht.

Die IT Affinität fehlte bei 90% des Projektteams, auch keine Seltenheit, leider oft sogar eine gewisse versteckte Aversion.

Es gab oft Spannungen zwischen den Linientätigkeiten und dem Projekt, oder wie ich immer sage, ENTWEDER Projekt ODER Linie, beides GEHT NICHT!
(Sorry, hier muss ich schreien)

Es wurde nur verwaltet, nicht proaktiv gesteuert. Auch dies kein seltenes Phänomen, meist wird mehr Wert auf Excel Schlachten und Statusberichte gelegt, als auf die aktive in Angriff Nahme der Entwicklungsherausforderungen. Der Entwickler ist meist das kleinste Rädchen, das das ganze einfache Programmierzeugs macht. Hierarchische Strukturen fressen gerade in grossen IT Projekten oft wichtige PT und Ressourcen.
Hier wurde die Agilität „ausgelagert“ zu den GEBIT Entwicklern.
Das Kernteam war mit dem Projektverlauf sehr zufrieden, aber die Mitwirkungsleistungen waren nicht in time. Es gibt immer noch Aufgaben, obwohl das Projekt zu Ende ist.

Kein Vorgehensmodell kann einen Erfolg erzwingen. Auch das Umfeld muss stimmen. Und da krankt es meist. IT Projekte ohne Mitarbeiter mit „Lust an der IT“ werden grausam!

Lessons learned:
Veränderung der Kommunikationskultur schwierig
Prozesse in Behörde dauern länger als lange.
Steuerung des Projektes notwendig
Spezifikationsänderungen nachvollziehbar dokumentieren
Stimmige Chemie kompensiert vieles
Betroffene zu Beteiligten machen
Spannungsfeld Fakten und Zahlen < -> Zweckoptimismus